From sip-bounces@ietf.org Fri Feb 03 08:18:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F50pS-0004ej-Dp; Fri, 03 Feb 2006 08:18:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F50fP-0001q3-QP for sip@megatron.ietf.org; Fri, 03 Feb 2006 08:07:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23846 for ; Fri, 3 Feb 2006 08:06:01 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F502d-0002aD-5D for sip@ietf.org; Fri, 03 Feb 2006 07:27:56 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id CC847194460 for ; Fri, 3 Feb 2006 13:15:38 +0100 (CET) Received: from [192.168.1.98] ([192.168.1.98]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Feb 2006 13:14:21 +0100 Mime-Version: 1.0 (Apple Message framework v623) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: "sip@ietf.org List" From: Hisham Khartabil Date: Fri, 3 Feb 2006 13:15:47 +0100 X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 03 Feb 2006 12:14:21.0914 (UTC) FILETIME=[5D7D83A0:01C628BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: [Sip] PUBLISH question X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Apologies if this has been discussed earlier. The scenario is that my UA send an initial PUBLISH request and I get a 200 response with a SIP-Etag header with a value. Now the UA can refresh and modify the state. What if my UA crashes and reboots? It will create a new initial PUBLISH request which *will not* replace the old publication that has not expired yet. I now have 2 states at the server. How do I remove the first one? Waiting for it to expire is not an option. The only answer I can think of is storing the e-tag persistantly. Any other opinions? 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 sip-bounces@ietf.org Fri Feb 03 08:40:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F51Ap-0000oG-03; Fri, 03 Feb 2006 08:40:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F51Am-0000mj-ML for sip@megatron.ietf.org; Fri, 03 Feb 2006 08:40:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27829 for ; Fri, 3 Feb 2006 08:38:35 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F51MA-00023H-0J for sip@ietf.org; Fri, 03 Feb 2006 08:52:11 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by mx2.foretec.com with esmtp (Exim 4.24) id 1F51AX-0007i9-K3 for sip@ietf.org; Fri, 03 Feb 2006 08:40:09 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k13DdxDu004154; Fri, 3 Feb 2006 15:40:03 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Feb 2006 15:39:56 +0200 Received: from [172.21.34.195] ([172.21.34.195]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 3 Feb 2006 15:39:57 +0200 Message-ID: <43E35D2B.202@nokia.com> Date: Fri, 03 Feb 2006 15:39:55 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Hisham Khartabil Subject: Re: [Sip] PUBLISH question References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Feb 2006 13:39:57.0217 (UTC) FILETIME=[525E9110:01C628C7] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org List" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org ext Hisham Khartabil wrote: > The scenario is that my UA send an initial PUBLISH request and I get a > 200 response with a SIP-Etag header with a value. Now the UA can refresh > and modify the state. What if my UA crashes and reboots? It will create > a new initial PUBLISH request which *will not* replace the old > publication that has not expired yet. I now have 2 states at the server. > How do I remove the first one? Waiting for it to expire is not an > option. The only answer I can think of is storing the e-tag > persistantly. Any other opinions? Storing the entity-tag locally is the best option at the moment in the absence of a GET method (or an event package that notifies of publications specifically). Cheers, Aki _______________________________________________ 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 sip-bounces@ietf.org Fri Feb 03 09:49:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F52Fb-0007Pt-6T; Fri, 03 Feb 2006 09:49:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F52FW-0007ND-Oa; Fri, 03 Feb 2006 09:49:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04696; Fri, 3 Feb 2006 09:47:44 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F52R8-0004nj-7o; Fri, 03 Feb 2006 10:01:22 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1F52FW-0006I7-7M; Fri, 03 Feb 2006 09:49:22 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Fri, 03 Feb 2006 09:49:22 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: sip@ietf.org Subject: [Sip] Last Call: 'Suppression of Session Initiation Protocol REFER Method Implicit Subscription' to Proposed Standard X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The IESG has received a request from the Session Initiation Protocol WG to consider the following document: - 'Suppression of Session Initiation Protocol REFER Method Implicit Subscription ' 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 2006-02-17. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-with-norefersub-04.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 sip-bounces@ietf.org Fri Feb 03 15:20:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F57Pq-0000Z3-AB; Fri, 03 Feb 2006 15:20:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F57Po-0000YP-HA for sip@megatron.ietf.org; Fri, 03 Feb 2006 15:20:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06810 for ; Fri, 3 Feb 2006 15:18:32 -0500 (EST) From: Shimshon.Lapushner@ecitele.com Received: from ilsmtp01.ecitele.com ([147.234.1.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F57bH-0002rE-Jz for sip@ietf.org; Fri, 03 Feb 2006 15:32:13 -0500 To: sip@ietf.org Message-ID: Date: Fri, 3 Feb 2006 22:20:02 +0200 X-MIMETrack: Serialize by Router on ILSMTP01/ECI Telecom(Release 6.5.3FP1 | December 22, 2004) at 02/03/2006 22:27:18 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.3 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [Sip] Shimshon Lapushner/ECI Telecom is out of the office. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I will be out of the office starting 02/02/2006 and will not return until 05/02/2006. I could be reached by Mobile: +972 54 578-8113 _______________________________________________ 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 sip-bounces@ietf.org Sun Feb 05 12:53:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5o4q-0004SM-Tg; Sun, 05 Feb 2006 12:53:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5o4o-0004Qw-1e for sip@megatron.ietf.org; Sun, 05 Feb 2006 12:53:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29527 for ; Sun, 5 Feb 2006 12:51:50 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5oGo-0003Y8-TR for sip@ietf.org; Sun, 05 Feb 2006 13:05:56 -0500 Received: from [10.11.0.122] (concorde301.adptelecom.net [212.180.41.212]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k15Hxl4p009509 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 5 Feb 2006 11:59:49 -0600 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <59D5680A-D7FF-491C-95C0-0D483215FFBD@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] PUBLISH question Date: Sun, 5 Feb 2006 11:53:27 -0600 To: Hisham Khartabil X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org List" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 3, 2006, at 6:15 AM, Hisham Khartabil wrote: > Apologies if this has been discussed earlier. > > The scenario is that my UA send an initial PUBLISH request and I > get a 200 response with a SIP-Etag header with a value. Now the UA > can refresh and modify the state. What if my UA crashes and > reboots? It will create a new initial PUBLISH request which *will > not* replace the old publication that has not expired yet. I now > have 2 states at the server. How do I remove the first one? Waiting > for it to expire is not an option. The only answer I can think of > is storing the e-tag persistantly. Any other opinions? Your procedure should be "get before publish if you don't have an etag". Then if you crash and lose the etag, on recovery you get the document (and its etag) before publishing a new document. -- 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 sip-bounces@ietf.org Sun Feb 05 21:59:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5wbF-000657-7a; Sun, 05 Feb 2006 21:59:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5wb3-00064N-73 for sip@megatron.ietf.org; Sun, 05 Feb 2006 21:59:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06476 for ; Sun, 5 Feb 2006 21:57:32 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5wn1-0004gM-2L for sip@ietf.org; Sun, 05 Feb 2006 22:11:44 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 05 Feb 2006 18:59:04 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,90,1139212800"; d="scan'208"; a="21241808:sNHT23224940" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k162ww6J019430; Sun, 5 Feb 2006 21:59:01 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 5 Feb 2006 21:58:59 -0500 Received: from [192.168.1.102] ([10.86.242.166]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 5 Feb 2006 21:58:58 -0500 Message-ID: <43E6BB72.8080405@cisco.com> Date: Sun, 05 Feb 2006 21:58:58 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] PUBLISH question References: <59D5680A-D7FF-491C-95C0-0D483215FFBD@softarmor.com> In-Reply-To: <59D5680A-D7FF-491C-95C0-0D483215FFBD@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Feb 2006 02:58:58.0821 (UTC) FILETIME=[469E4B50:01C62AC9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org List" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org inline. Dean Willis wrote: > > On Feb 3, 2006, at 6:15 AM, Hisham Khartabil wrote: > >> Apologies if this has been discussed earlier. >> >> The scenario is that my UA send an initial PUBLISH request and I get >> a 200 response with a SIP-Etag header with a value. Now the UA can >> refresh and modify the state. What if my UA crashes and reboots? It >> will create a new initial PUBLISH request which *will not* replace >> the old publication that has not expired yet. I now have 2 states at >> the server. How do I remove the first one? Waiting for it to expire >> is not an option. The only answer I can think of is storing the e-tag >> persistantly. Any other opinions? > > > Your procedure should be "get before publish if you don't have an > etag". Then if you crash and lose the etag, on recovery you get the > document (and its etag) before publishing a new document. The problem is, there is no 'get' mecahnism. You can subscribe the appropriate event state, but that isn't going to tell you the etags of the raw published event state. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.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 sip-bounces@ietf.org Mon Feb 06 05:21:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F63Uz-0003LX-QY; Mon, 06 Feb 2006 05:21:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F63Ux-0003LO-Ez for sip@megatron.ietf.org; Mon, 06 Feb 2006 05:21:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04447 for ; Mon, 6 Feb 2006 05:19:51 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F63h7-0003BW-48 for sip@ietf.org; Mon, 06 Feb 2006 05:34:06 -0500 Received: from [10.10.2.124] (expo111.palais-congres-paris.fr [212.155.202.111] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k16ARgcV019968 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 6 Feb 2006 04:27:50 -0600 In-Reply-To: <43E6BB72.8080405@cisco.com> References: <59D5680A-D7FF-491C-95C0-0D483215FFBD@softarmor.com> <43E6BB72.8080405@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2E17A70D-87E1-43B0-95A5-3D5E23741062@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] PUBLISH question Date: Mon, 6 Feb 2006 04:21:22 -0600 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org List" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 5, 2006, at 8:58 PM, Jonathan Rosenberg wrote: > inline. > > Dean Willis wrote: > >> On Feb 3, 2006, at 6:15 AM, Hisham Khartabil wrote: >>> Apologies if this has been discussed earlier. >>> >>> The scenario is that my UA send an initial PUBLISH request and I >>> get a 200 response with a SIP-Etag header with a value. Now the >>> UA can refresh and modify the state. What if my UA crashes and >>> reboots? It will create a new initial PUBLISH request which >>> *will not* replace the old publication that has not expired yet. >>> I now have 2 states at the server. How do I remove the first >>> one? Waiting for it to expire is not an option. The only answer >>> I can think of is storing the e-tag persistantly. Any other >>> opinions? >> Your procedure should be "get before publish if you don't have an >> etag". Then if you crash and lose the etag, on recovery you get >> the document (and its etag) before publishing a new document. > > The problem is, there is no 'get' mecahnism. You can subscribe the > appropriate event state, but that isn't going to tell you the etags > of the raw published event state. Doesn't that depend on which "side" of the compositor you're subscribing to? I seem to recall some discussion of subscribing to "inputs" as well as composited "outputs". Now, I do have to say I'm aware of an implementation that doesn't support this, although I seem to recall suggesting that it should. -- 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 sip-bounces@ietf.org Mon Feb 06 15:01:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6CYa-00015y-BI; Mon, 06 Feb 2006 15:01:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6CYY-00015X-SO for sip@megatron.ietf.org; Mon, 06 Feb 2006 15:01:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17396 for ; Mon, 6 Feb 2006 15:00:09 -0500 (EST) Received: from gate01.nexlink.ch ([80.86.198.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6Ckn-0002Gx-57 for sip@ietf.org; Mon, 06 Feb 2006 15:14:30 -0500 Received: from MAIL01.NEXLINK.CH ([10.51.9.1]) by GATE01.NEXLINK.CH (8.13.1/8.13.1) with ESMTP id k16K1lnH023425 for ; Mon, 6 Feb 2006 21:01:47 +0100 Message-Id: <200602062001.k16K1lnH023425@GATE01.NEXLINK.CH> MIME-Version: 1.0 From: =?ISO-8859-1?Q?Jo=EBl Repiquet?= To: sip@ietf.org Date: Mon, 06 Feb 2006 21:01:47 +0100 X-Uidl: 1139256107214168744 X-Mailer: AtMail 4.11 X-Spam-Score: 4.1 (++++) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Sip] sip-identity-06's compressed archive file X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: joel.repiquet@tech-invite.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1212282773==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1212282773== Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The compressed archive file in sip-identity-06 appendix B (examples) can= not be recovered. This is a known problem that has been pointed out in the = datatracker log. It is mentioned that it will be fixed just before the RFC = publication.

However, would it be possible to get the corrected base-= 64 encoded block now? 

 

By the way, on page 17, 'atl= anta.example.org' is to be replaced by 'atlanta.example.com'.

 <= /p>

Thanks

Joël 


--===============1212282773== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1212282773==-- From sip-bounces@ietf.org Mon Feb 06 22:09:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6JE6-0005zH-Hi; Mon, 06 Feb 2006 22:09:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6JE4-0005yI-8b for sip@megatron.ietf.org; Mon, 06 Feb 2006 22:09:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09997 for ; Mon, 6 Feb 2006 22:07:26 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6JQM-0002zp-V0 for sip@ietf.org; Mon, 06 Feb 2006 22:21:52 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUA00GCBRYUEB@szxga02-in.huawei.com> for sip@ietf.org; Tue, 07 Feb 2006 11:20:55 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUA00BIJRYUK9@szxga02-in.huawei.com> for sip@ietf.org; Tue, 07 Feb 2006 11:20:54 +0800 (CST) Received: from w26552 ([10.76.176.22]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IUA00IHUS4E9F@szxml01-in.huawei.com>; Tue, 07 Feb 2006 11:24:18 +0800 (CST) Date: Tue, 07 Feb 2006 11:08:49 +0800 From: Rocky Wang Subject: RE: [Sip] Re: Re-Invite before ACK In-reply-to: <072C5B76F7CEAB488172C6F64B30B5E30103155F@xmb-rtp-20b.amer.cisco.com> To: "'Michael Hammer (mhammer)'" , "'Benny Prijono'" Message-id: <000001c62b93$d13312d0$16b04c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, "'James Polk \(jmpolk\)'" , 'srinidhi n' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org In Section 14.2 UAS Behavior of RFC 3261, it says: If a UAS generates a 2xx response and never receives an ACK, it SHOULD generate a BYE to terminate the dialog. That is, the UAS SHOULD terminate the dialog. But because the misorder of the SIP messages, sometimes the UAS SHOULD NOT terminate the dialog as I considered. The UAS can have several choices to handle in this case: 1. Terminate the dialog as the specification. This is not reasonable in some cases and it is not a good idea. 2. UAS can accept the re-INVITE and wait for ACK. It can handle the re-INVITE before the ACK comes or after ACK comes. If before ACK, the case will becomes more complicated if maybe the ACK will take SDP answer back. But if after ACK comes, it must buffer it. This is not a good idea, I think. 3. UAS can ignore the re-INVITE because UAC will re-transmit again. UAS can accept it after ACK comes simply. 4. As Section 14.2 of RFC3261: A UAS that receives an INVITE on a dialog while an INVITE it had sent on that dialog is in progress MUST return a 491 (Request Pending) response to the received INVITE. UAS can reject the re-INVITE temporarily by 491 and UAC side will initiate another try several seconds later. I don't suggest taking Offer/Answer procedure into account because session is limited into RTP relationships nowadays and maybe it will be expanded into some other types of relationships, e.g. VPN session. If you make a decision based on OA state, you must change your formula. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Michael Hammer (mhammer) > Sent: 2006=C4=EA1=D4=C226=C8=D5 1:43 > To: Benny Prijono > Cc: sip@ietf.org; James Polk (jmpolk); srinidhi n > Subject: RE: [Sip] Re: Re-Invite before ACK >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Benny Prijono [mailto:lists@bulukucing.org] > > Sent: Wednesday, January 25, 2006 12:02 PM > > To: Michael Hammer (mhammer) > > Cc: Nataraju A B; srinidhi n; Xiao Wang; Jin, Haipeng; Manish=20 > > Joshi; James Polk (jmpolk); Miloslavsky Evgeny; sip@ietf.org > > Subject: Re: [Sip] Re: Re-Invite before ACK > >=20 > > Michael, > >=20 > > even after your lengthy explanation, I still think it wouldn't work. > > Perhaps it's because I didn't explain it clearly either.=20 > More inline. > >=20 > > Michael Hammer (mhammer) wrote: > > > Thanks. More inline. > > >=20 > > > You misunderstood the actual suggestion because it was not clearly > > > laid out. The idea was that the UAS is going to=20 > retransmit 200 OK=20 > > > according to a Timer G' behavior. Let us call what the=20 > UAC thinks=20 > > > this behavior is the Timer G". Assuming T1=3D500 ms, Timer=20 > G' at UAS=20 > > > will send 200 OK > > > at: > > >=20 > > > Interval: 0, .5, 1.0, 2.0, 4.0, 8.0, 16.0 > > > Times: 0, .5, 1.5, 3.5, 7.5, 15.5, 31.5 (Timer H' fires=20 > > at T1*64=3D32 > > > sec) > > >=20 > > > Timer G" at UAC can have identical behavior. Assume > > one-way transport > > > time is .1 second. > > > Interval: 0.0, .5, 1.0, 2.0, 4.0, 8.0, 16.0 > > > Times: 0.1, .6, 1.6, 3.6, 7.6, 15.6, 31.6 (Timer H'=20 > > fires at T1*64=3D32 > > > sec) > > >=20 > >=20 > > The problem is, you assumed that timer G" starts in UAC at > > the same time when timer G' starts in UAS. This is not=20 > > possible (I think).=20 > > Timer G" can only start at UAC when UAC receives the first=20 > > 2xx response. Is this correct, or am I missing something here? >=20 > Yes, Timer G" only gets started once the 200 OK is received=20 > and why I had to include the half RTT. >=20 > > If this is correct, then what if the first 2xx response > > received by UAC is actually the n-th retransmission (because=20 > > n-1 responses were lost). In this case, timer G' and G" won't=20 > > be synchronized. > >=20 > > Let me illustrate with a diagram. We'll ignore RTT time, for > > simplification. > >=20 > > Time UAC UAS > > 0.000 lost X <------ 200/OK -- > > 0.500 lost X <------ 200/OK -- > > 1.500 lost X <------ 200/OK -- > > 3.500 <------------------ 200/OK -- > > -- ACK -----------> X lost > > 7.500 <------------------ 200/OK -- > >=20 > > At time 3.500, UAC starts timer G". After 2*T1, at time > > 4.500, UAC thinks it's okay to send re-INVITE, because no 200=20 > > retransmission is received. But this is wrong, since the=20 > > retransmission WILL be received at time 7.500. > >=20 > > Am I missing something? > >=20 > > -benny >=20 > Yes, I see the problem now. The UAS is further out in its=20 > backoff interval than the UAC which started its backoff=20 > interval later, but more aggressive. Thus, the UAC would=20 > always beat the UAS to the punch. Of course once you have=20 > two 200 OKs, you would know where in this sequence you were,=20 > but that is too complex. >=20 > This suggested hypothetical behavior would work better (thinking out > loud) if Timer G' and G" were more like Timer E and retrans=20 > at MIN(2*T1, T2), that is at regular intervals. Or, even=20 > just define a T5 value say, 2 seconds, with no back off. =20 >=20 > Makes me wonder if INVITE response retransmissions in general=20 > should not exhibit a backoff. That is Timer G, G', G" should=20 > all be at some fixed interval. This would speed up comletion=20 > of the INVITE transaction. But, that would require a change=20 > to RFC-3261. Would have to think what the downside to that is. >=20 > The current alternative seems to be keep pounding the UAS=20 > with re-INVITEs until one gets through. That is more brute=20 > force and would seem to aggravate overload conditions. >=20 > BTW, I can't claim any credit for this Timer G" idea, I was=20 > only following through the thought introduced earlier by someone else. >=20 > Mike >=20 > >=20 > > > At time 0 the 200 OK is sent. At time 0.1 it is received > > at the UAC. > > >=20 > > > If the ACK is not received the UAS would send again at=20 > time 0.5 and > > > the UAC would receive it at time 0.6 > > >=20 > > > At time 0.6, if a second 200 OK is received, UAC > > retransmits the ACK > > > and sets Timer G"=3D1 so that it fires at time 1.6. > > >=20 > > > At time 1.6, if a third 200 OK is received, UAC=20 > retransmits the ACK > > > and sets Timer G"=3D2 so that it fires at time 3.6 and so on. > > >=20 > > > This is the theoretical minimum. The actual suggestion was > > to start > > > the Timer G" at 2*T1: > > > Interval: 0.0, 1.0, 2.0, 4.0, 8.0, 16.0 > > > Times: 0.1, 1.1, 3.1, 7.1, 16.1, 32.1 (Timer H" fires=20 > at T1*64=3D32 > > > sec) > > >=20 > > > Compare with the Timer G' behavior adjusted with .1 cross-network > > > transmit time. > > > Times: 0.1, .6, 1.6, 3.6, 7.6, 15.6, 31.6 (Timer H'=20 > > fires at T1*64=3D32 > > > sec) > > >=20 > > > Note that the "200 OK expected" times are increasingly larger than > > > what the actual 200 OK receipt times at the UAC should be. The=20 > > > end-game for Timer H" would need to be handled, but you get=20 > > the idea now, I hope. > > >=20 > > >=20 > > >>So in general, I think this type of solution will not=20 > work, because > > >>there is no way for UAC to know when the next response=20 > will arrive. > > >=20 > > >=20 > > > I would state this the other way. There is no way for the > > UAC to know > > > that the ACK was received and therefore that a 200 OK will not be > > > forthcoming. The issue still is answering the question=20 > > (rather than > > > waiting some very long time) when is the earliest it is > > reasonable to > > > try to send the re-INVITE with high probability of success? > > >=20 > > > If you send immediately and get a 491 in return, this=20 > just puts the > > > UAC in the same situation of needing to decide when to=20 > > retranmit. The > > > ACK could be received immediately after the 491 was sent. > > So, sending > > > the re-INVITE immediately after ACK has only postponed this > > decision > > > *IF* the network delivery and handling at the UAS is misordered. > > >=20 > > > Perhaps a compromise is to wait an RTT before sending the=20 > re-INVITE > > > and allow Timer A to take care of the rest. (Note Timer A=20 > > will fire > > > quicker than Timer G'.) > > >=20 > > > Mike > > >=20 > > >=20 > > >>Thus for UAC, the only thing that works is to handle 491 (Request > > >>Pending) response when it arrives. > > >> > > >>-benny > > >> > > >> > > >>>UAS: Reject any re-INVITE before ACK received with 491 Request > > >>>Pending, since Answer to Offer in 200 OK was not=20 > received. Accept=20 > > >>>re-INVITE with new offer only after ACK received. > > >>> > > >>>Where UAS wants to re-INVITE, wait for ACK with Answer=20 > to complete > > >>>Offer in 200 OK before sending re-INVITE. > > >>> > > >>>My only question is that Timer G starts with T1 not 2*T1, > > >> > > >>so is this > > >> > > >>>for margin of safety? Also, doesn't this assume that both > > >> > > >>UAC and UAS > > >> > > >>>use same T1 value? > > >>> > > >>>Mike > > >>> > > >>> > > >> > > >=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 sip-bounces@ietf.org Tue Feb 07 00:46:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Lfw-0005A7-Aw; Tue, 07 Feb 2006 00:46:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Lfi-00054r-Vt; Tue, 07 Feb 2006 00:45:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21484; Tue, 7 Feb 2006 00:44:02 -0500 (EST) Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6Lrt-0000Tt-Mh; Tue, 07 Feb 2006 00:58:28 -0500 Received: from [192.168.0.103] (pool-70-104-24-36.dllstx.fios.verizon.net [70.104.24.36]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k175gLQA031340 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 6 Feb 2006 23:42:22 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <0B23EA50-279C-4548-B7F1-4CB334ABF93E@nostrum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: "sip@ietf.org WG" , Sipping WG , "simple@ietf.org list" , sip-implementors@cs.columbia.edu From: Robert Sparks Date: Mon, 6 Feb 2006 23:42:23 -0600 X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (shaman.nostrum.com: 70.104.24.36 is authenticated by a trusted mechanism) X-Spam-Score: 3.0 (+++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: Subject: [Sip] SIPIT 18 Registration is open X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Registration for SIPit 18 is open. This event will be held April 17-21 in Akihabara, Tokyo, Japan. More information about the event is available at http://www.sipit.net and the host website at http://www.nic.ad.jp/en/sipit18/ Registration will close March 31. Please register early. You can register now using https://www.regonline.com/88905 This 18th SIPForum SIPit is Hosted by: - Japan Network Information Center (JPNIC) Co-hosted by: - WIDE Project - VoIP System Interoperability Task Force Supported by: - Ministry of Internal Affairs and Communications (MIC) - The Telecommunication Technology Committee (TTC) - Telecom Service Association (TELESA) - VoIP Forum Japan (VFJ) - IPv6 Promotion Council (v6PC) - ENUM Trial Japan (ETJP) Sponsors: - Cisco Systems, Inc. - Fractalist Inc. - Fusion Communications Corporation - Japan Telecom Co., Ltd. - KDDI Corporation - Mitsubishi Electric Information Network Corporation - Mitsubishi Research Institute, Inc. - NEC Corporation - Netmarks Inc. - Nippon Telegraph and Telephone Corporation - Nippon Telegraph and Telephone East Corporation - Nippon Telegraph and Telephone West Corporation - NTT Advanced Technology Corporation - Oki Electric Industry Co., Ltd. - SoftBank BB Corp. - Softfront _______________________________________________ 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 sip-bounces@ietf.org Tue Feb 07 03:08:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Ntt-0006Tq-EV; Tue, 07 Feb 2006 03:08:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Ntr-0006Sy-3J for sip@megatron.ietf.org; Tue, 07 Feb 2006 03:08:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01425 for ; Tue, 7 Feb 2006 03:06:53 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6O6C-0005OF-5E for sip@ietf.org; Tue, 07 Feb 2006 03:21:21 -0500 Received: from [10.10.2.124] (expo111.palais-congres-paris.fr [212.155.202.111] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k178Estv025730 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Tue, 7 Feb 2006 02:14:56 -0600 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <3D7E74A2-00CE-4DB4-8466-D02777817D18@softarmor.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: "sip@ietf.org List" From: Dean Willis Date: Tue, 7 Feb 2006 02:08:37 -0600 X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Subject: [Sip] Requested publication for REFER extensions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I've requested publication of: draft-ietf-sip-refer-with-norefersub-04 draft-ietf-sip-refer-feature-param-01 -- 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 sip-bounces@ietf.org Tue Feb 07 03:51:25 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6OZJ-0004t6-7X; Tue, 07 Feb 2006 03:51:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6OZH-0004q7-OY for sip@megatron.ietf.org; Tue, 07 Feb 2006 03:51:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04313 for ; Tue, 7 Feb 2006 03:49:34 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6OlV-0006x1-5S for sip@ietf.org; Tue, 07 Feb 2006 04:04:02 -0500 Received: from [10.10.2.124] (expo111.palais-congres-paris.fr [212.155.202.111] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k178veiE025919 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 7 Feb 2006 02:57:42 -0600 In-Reply-To: <200602062001.k16K1lnH023425@GATE01.NEXLINK.CH> References: <200602062001.k16K1lnH023425@GATE01.NEXLINK.CH> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <599E82D8-7CA6-4544-BF9F-1DDA0D234905@softarmor.com> Content-Transfer-Encoding: quoted-printable From: Dean Willis Subject: Re: [Sip] sip-identity-06's compressed archive file Date: Tue, 7 Feb 2006 02:51:22 -0600 To: joel.repiquet@tech-invite.com X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 6, 2006, at 2:01 PM, Jo=EBl Repiquet wrote: > > By the way, on page 17, 'atlanta.example.org' is to be replaced by =20 > 'atlanta.example.com'. > > I think there's a mixup that stems from page 16, which says: " A user of atlanta.example.com, Alice, wants to send an INVITE to bob@biloxi.example.org. She therefore creates the following INVITE request, which she forwards to the atlanta.example.org proxy server that instantiates the authentication service role:" If I'm reading the text right, the nodes involved are =20 "atlanta.example.com" and "biloxi.example.org". But the above text =20 introduces "atlanta.example.org", which is also used in the examples =20 on page 17. This is either an error, or more subtle than I can grasp. Personally, I find the domains "example.com" and "example.org" to be =20 hard to differentiate. Perhaps in this sort of context, =20 "atlanta.example" and "biloxi.example" would be more useful. Incidentally, if folks are curious about example.com and example.org =20 and other alternatives, this comes from RFC 2606, which says:: To safely satisfy these needs, four domain names are reserved as listed and described below. .test .example .invalid .localhost ".test" is recommended for use in testing of current or new DNS related code. ".example" is recommended for use in documentation or as =20 examples. ".invalid" is intended for use in online construction of domain names that are sure to be invalid and which it is obvious at a glance are invalid. The ".localhost" TLD has traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use. Any other use would conflict with widely deployed code which assumes this use. 3. Reserved Example Second Level Domain Names The Internet Assigned Numbers Authority (IANA) also currently has =20= the following second level domain names reserved which can be used as examples. example.com example.net example.org= _______________________________________________ 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 sip-bounces@ietf.org Tue Feb 07 07:22:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6RrT-0006K2-1L; Tue, 07 Feb 2006 07:22:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6RrQ-0006E4-SW for sip@megatron.ietf.org; Tue, 07 Feb 2006 07:22:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18469 for ; Tue, 7 Feb 2006 07:20:40 -0500 (EST) Received: from mailrelay.swisscom-eurospot.com ([83.97.120.60] helo=safetwo.sceur.ch) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6S3b-0005q8-TK for sip@ietf.org; Tue, 07 Feb 2006 07:35:09 -0500 Received: from Pavillonquatre (unknown [212.180.35.242]) by safetwo.sceur.ch (Postfix) with ESMTP id A0F838DCFC for ; Tue, 7 Feb 2006 12:21:52 +0000 (UTC) From: "Chantal Ladouce" To: Date: Tue, 7 Feb 2006 13:21:38 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYr4QpvqtxVSuBjS8yLc+M3mji51g== Message-Id: <20060207122152.A0F838DCFC@safetwo.sceur.ch> X-Spam-Score: 0.1 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Subject: [Sip] Wireless/WiFi Convergence Conference - Paris - France X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1835553528==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1835553528== Content-Type: multipart/alternative; boundary="----=_NextPart_000_006B_01C62BE9.6D62E590" This is a multi-part message in MIME format. ------=_NextPart_000_006B_01C62BE9.6D62E590 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit UMA how? IMS when? At the 2006 Wireless/WiFi Convergence Conference to be held in Paris on May 16 to May 19, distinguished experts and key players in the convergence field will address technical issues. Carriers like BT, Orange, Vonage (etc) will discuss their commercial experience and technological choices. Get all details at: http://www.upperside.fr/wirelessconvergence2006/wwconvergence2006intro.htm ------=_NextPart_000_006B_01C62BE9.6D62E590 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

UMA how? IMS when?

 

At the 2006 Wireless/WiFi Convergence Conference to be held in Paris on May 16 to May 19, = distinguished experts and key players in the convergence field will address technical issues. = Carriers like BT, Orange, Vonage (etc) will discuss their commercial experience and technological choices.

Get all details at:

 

http://www.upperside.fr/wirelessconvergence2006/wwconvergenc= e2006intro.htm

 

 

------=_NextPart_000_006B_01C62BE9.6D62E590-- --===============1835553528== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1835553528==-- From sip-bounces@ietf.org Wed Feb 08 06:01:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6n59-0000BM-MX; Wed, 08 Feb 2006 06:01:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6n57-00007Q-D4 for sip@megatron.ietf.org; Wed, 08 Feb 2006 06:01:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10819 for ; Wed, 8 Feb 2006 06:00:03 -0500 (EST) Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6nHZ-0007mN-9i for sip@ietf.org; Wed, 08 Feb 2006 06:14:46 -0500 Received: (qmail 7162 invoked by uid 0); 8 Feb 2006 11:01:23 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 8 Feb 2006 11:01:23 -0000 Message-ID: <004601c62c9e$ffcc6cc0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: Date: Wed, 8 Feb 2006 12:01:22 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.9 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Subject: [Sip] stateless forwarding UDP->TCP by proxy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0729202257==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0729202257== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0043_01C62CA7.613B13A0" This is a multi-part message in MIME format. ------=_NextPart_000_0043_01C62CA7.613B13A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Would a proxy be allowed to forward a request transaction statelessly = when switching from UDP to TCP (e.g. because the request becomes too big = for UDP)? RFC3261 16.1 states "[...] Requests forwarded between different types of = transports where the proxy's TU must take an active role in ensuring = reliable delivery on one of the transports MUST be forwarded transaction = statefully." However, for the UDP->TCP case it would seem that reliability is ensured = because retransmitted requests on UDP would be passed upstream again = (over TCP), and eventually trigger a retransmission of the response. = This would result in retransmissions over TCP - which the next hop = perhaps would not expect - but other than that, are there any problems = with this scenario? Regards, Jeroen van Bemmel ------=_NextPart_000_0043_01C62CA7.613B13A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Would a proxy be allowed to forward a = request=20 transaction statelessly when switching from UDP to TCP (e.g. because the = request=20 becomes too big for UDP)?
 
RFC3261 16.1 states "[...] Requests = forwarded=20 between different types of transports where the proxy's TU must take an = active=20 role in ensuring reliable delivery on one of the transports MUST be = forwarded=20 transaction statefully."
 
However, for the UDP->TCP case it = would seem=20 that reliability is ensured because retransmitted requests on UDP would = be=20 passed upstream again (over TCP), and eventually trigger a = retransmission of the=20 response. This would result in retransmissions over TCP - which the next = hop=20 perhaps would not expect - but other than that, are there any problems = with this=20 scenario?
 
Regards,
 
Jeroen van Bemmel
 
 
------=_NextPart_000_0043_01C62CA7.613B13A0-- --===============0729202257== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0729202257==-- From sip-bounces@ietf.org Wed Feb 08 08:04:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6ozl-0002g8-Q9; Wed, 08 Feb 2006 08:04:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6ozj-0002dv-7j for sip@megatron.ietf.org; Wed, 08 Feb 2006 08:04:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20011 for ; Wed, 8 Feb 2006 08:02:37 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6pCC-0003bh-5y for sip@ietf.org; Wed, 08 Feb 2006 08:17:20 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 08 Feb 2006 05:04:09 -0800 X-IronPort-AV: i="4.02,98,1139212800"; d="scan'208"; a="402261786:sNHT47347122" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k18D44WP019131; Wed, 8 Feb 2006 05:04:08 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Feb 2006 08:04:06 -0500 Received: from [64.102.206.201] ([64.102.206.201]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Feb 2006 08:04:06 -0500 Message-ID: <43E9EC46.8070604@cisco.com> Date: Wed, 08 Feb 2006 08:04:06 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] stateless forwarding UDP->TCP by proxy References: <004601c62c9e$ffcc6cc0$31713b51@BEMBUSTER> In-Reply-To: <004601c62c9e$ffcc6cc0$31713b51@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Feb 2006 13:04:06.0662 (UTC) FILETIME=[249AAA60:01C62CB0] X-Spam-Score: 2.2 (++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I think it will work. You'll need to make sure that all requests for the same transaction land on the same tcp connection, but this can be done statelessly. -Jonathan R. Jeroen van Bemmel wrote: > Would a proxy be allowed to forward a request transaction statelessly > when switching from UDP to TCP (e.g. because the request becomes too big > for UDP)? > > RFC3261 16.1 states "[...] Requests forwarded between different types of > transports where the proxy's TU must take an active role in ensuring > reliable delivery on one of the transports MUST be forwarded transaction > statefully." > > However, for the UDP->TCP case it would seem that reliability is ensured > because retransmitted requests on UDP would be passed upstream again > (over TCP), and eventually trigger a retransmission of the response. > This would result in retransmissions over TCP - which the next hop > perhaps would not expect - but other than that, are there any problems > with this scenario? > > Regards, > > Jeroen van Bemmel > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.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 sip-bounces@ietf.org Wed Feb 08 08:16:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6p7X-00073i-E6; Wed, 08 Feb 2006 08:12:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6p7U-0006wP-7x for sip@megatron.ietf.org; Wed, 08 Feb 2006 08:12:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20748 for ; Wed, 8 Feb 2006 08:10:33 -0500 (EST) Received: from mail.us.es ([193.147.175.20] helo=us.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6pJp-0003wW-Vl for sip@ietf.org; Wed, 08 Feb 2006 08:25:16 -0500 Received: (qmail 27400 invoked from network); 8 Feb 2006 14:11:54 +0100 Received: from unknown (HELO us.es) (192.168.2.11) by us.es with SMTP; 8 Feb 2006 14:11:54 +0100 Received: (qmail 29559 invoked from network); 8 Feb 2006 13:11:53 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on antivirus1 X-Spam-Status: No, score=0.0 required=7.5 tests=BAYES_50 autolearn=disabled version=3.1.0 Received: from localhost (HELO us.es) (127.0.0.1) by us.es with SMTP; 8 Feb 2006 14:11:53 +0100 Received: (qmail 15770 invoked from network); 8 Feb 2006 14:11:55 +0100 Received: from cartuja.us.es (193.147.161.37) by us.es with SMTP; 8 Feb 2006 14:11:55 +0100 Received: from [192.168.200.52] (ait04.us.es [193.147.162.165]) by cartuja.us.es (8.9.3/8.9.1) with ESMTP id OAA03739; Wed, 8 Feb 2006 14:11:16 GMT Message-ID: <43E9EDFE.8090304@yahoo.es> Date: Wed, 08 Feb 2006 14:11:26 +0100 From: =?ISO-8859-1?Q?=C1lvaro_Canivell_Garc=EDa_de_Paredes?= User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?=C1lvaro_Canivell_Garc=EDa_de_Paredes?= Subject: Re: [Sip] Solutions to NAT: STUN References: <20060112184633.24077.qmail@web52813.mail.yahoo.com> <43C7B02C.3080603@yahoo.es> In-Reply-To: <43C7B02C.3080603@yahoo.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Spam-Score: 3.0 (+++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA20748 Cc: sip@ietf.org, sipping@ietf.org, sip_protocol@yahoogroups.com, sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Found out the following: Sip-communcator makes use of stun4j implementation of STUN. This=20 implementation, at least the last CVS, can discover de NAT type=20 (Discovery Process in rfc3849)(i have port restricted cone NAT), and=20 also discover the public address of the client (Binding Acquisition in=20 rfc3849), from the client that is behind a NAT. However, it doesn't implement Binding Lifetime Discovery (rfc3849). That=20 is usefull if thje client needs to refresh the NAT bindings from time to=20 time. With the current implementation of stun4j, I can send out of the NAT=20 SIP messages with the public IP address in the contact, and media=20 specification (in case of SDP usage). But requests coming from outside=20 into the NAT, are NOT ALWAYS routed into the client. I guess this is=20 because the bindings in the NAT are deleted, after some time. Any idea on how to keep bindings alive, any roundabout method? =C1lvaro _______________________________________________ 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 sip-bounces@ietf.org Wed Feb 08 10:22:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6r91-0005Lh-5L; Wed, 08 Feb 2006 10:22:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6r8z-0005Jq-M7 for sip@megatron.ietf.org; Wed, 08 Feb 2006 10:22:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00830 for ; Wed, 8 Feb 2006 10:20:27 -0500 (EST) Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6rLZ-00005Y-1Y for sip@ietf.org; Wed, 08 Feb 2006 10:35:12 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k18FLcRT048559; Wed, 8 Feb 2006 10:21:42 -0500 (EST) From: "Brett Tate" To: "'Jonathan Rosenberg'" , "'Jeroen van Bemmel'" Subject: RE: [Sip] stateless forwarding UDP->TCP by proxy Date: Wed, 8 Feb 2006 10:22:28 -0500 Message-ID: <000301c62cc3$7c820b20$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <43E9EC46.8070604@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Unfortunately RFC 3261 removed retrying 3xx-6xx responses over reliable connections. Thus such responses might only be sent once over the udp portion when a 1xx was previously sent. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Jonathan Rosenberg > Sent: Wednesday, February 08, 2006 8:04 AM > To: Jeroen van Bemmel > Cc: sip@ietf.org > Subject: Re: [Sip] stateless forwarding UDP->TCP by proxy > > > I think it will work. You'll need to make sure that all > requests for the > same transaction land on the same tcp connection, but this > can be done > statelessly. > > -Jonathan R. > > Jeroen van Bemmel wrote: > > Would a proxy be allowed to forward a request transaction > statelessly > > when switching from UDP to TCP (e.g. because the request > becomes too big > > for UDP)? > > > > RFC3261 16.1 states "[...] Requests forwarded between > different types > > of > > transports where the proxy's TU must take an active role in > ensuring > > reliable delivery on one of the transports MUST be > forwarded transaction > > statefully." > > > > However, for the UDP->TCP case it would seem that reliability is > > ensured > > because retransmitted requests on UDP would be passed > upstream again > > (over TCP), and eventually trigger a retransmission of the > response. > > This would result in retransmissions over TCP - which the next hop > > perhaps would not expect - but other than that, are there > any problems > > with this scenario? > > > > Regards, > > > > Jeroen van Bemmel _______________________________________________ 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 sip-bounces@ietf.org Wed Feb 08 10:52:03 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6rbv-0000t8-CM; Wed, 08 Feb 2006 10:52:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6rbq-0000rc-SF; Wed, 08 Feb 2006 10:51:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02926; Wed, 8 Feb 2006 10:50:16 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6roT-00014d-Bk; Wed, 08 Feb 2006 11:05:01 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1F6rbp-0003E3-Sc; Wed, 08 Feb 2006 10:51:57 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 08 Feb 2006 10:51:57 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: sip@ietf.org Subject: [Sip] Last Call: 'Conveying Feature Tags with Session Initiation Protocol REFER Method' to Proposed Standard X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The IESG has received a request from the Session Initiation Protocol WG to consider the following document: - 'Conveying Feature Tags with Session Initiation Protocol REFER Method ' 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 2006-02-22. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-feature-param-01.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 sip-bounces@ietf.org Wed Feb 08 11:55:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6sbM-0007h9-Aa; Wed, 08 Feb 2006 11:55:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6sbK-0007gc-Iv for sip@megatron.ietf.org; Wed, 08 Feb 2006 11:55:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09181 for ; Wed, 8 Feb 2006 11:53:47 -0500 (EST) Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6snw-0003m5-AN for sip@ietf.org; Wed, 08 Feb 2006 12:08:34 -0500 Received: (qmail 31657 invoked by uid 0); 8 Feb 2006 16:55:12 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 8 Feb 2006 16:55:12 -0000 Message-ID: <00af01c62cd0$6d045ce0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Brett Tate" , "'Jonathan Rosenberg'" References: <000301c62cc3$7c820b20$2c28a8c0@brett1> Subject: Re: [Sip] stateless forwarding UDP->TCP by proxy Date: Wed, 8 Feb 2006 17:55:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Brett, Good point I suppose this could be a reason to state that when possible, implementations should not send any 1xx responses (including 100 Trying) before sending a 3xx-6xx response over TCP (or any reliable transport), since it may be that some proxy along the line made the transport switch. A valid case: INVITE becoming too large due to Via / Record-Route headers. Trouble is that INVITE -> ringing -> no answer is a common scenario... Alternatively, the 1300 byte limit for switching to TCP could be extended for proxies (say: 1300 for UAC, 1500 for proxies). Or - third option - UACs should use a smaller limit value for INVITEs, say 1000 bytes, and above that switch to TCP. Jeroen ----- Original Message ----- From: "Brett Tate" To: "'Jonathan Rosenberg'" ; "'Jeroen van Bemmel'" Cc: Sent: Wednesday, February 08, 2006 4:22 PM Subject: RE: [Sip] stateless forwarding UDP->TCP by proxy > Unfortunately RFC 3261 removed retrying 3xx-6xx responses over reliable > connections. Thus such responses might only be sent once over the udp > portion when a 1xx was previously sent. > > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >> Behalf Of Jonathan Rosenberg >> Sent: Wednesday, February 08, 2006 8:04 AM >> To: Jeroen van Bemmel >> Cc: sip@ietf.org >> Subject: Re: [Sip] stateless forwarding UDP->TCP by proxy >> >> >> I think it will work. You'll need to make sure that all >> requests for the >> same transaction land on the same tcp connection, but this >> can be done >> statelessly. >> >> -Jonathan R. >> >> Jeroen van Bemmel wrote: >> > Would a proxy be allowed to forward a request transaction >> statelessly >> > when switching from UDP to TCP (e.g. because the request >> becomes too big >> > for UDP)? >> > >> > RFC3261 16.1 states "[...] Requests forwarded between >> different types >> > of >> > transports where the proxy's TU must take an active role in >> ensuring >> > reliable delivery on one of the transports MUST be >> forwarded transaction >> > statefully." >> > >> > However, for the UDP->TCP case it would seem that reliability is >> > ensured >> > because retransmitted requests on UDP would be passed >> upstream again >> > (over TCP), and eventually trigger a retransmission of the >> response. >> > This would result in retransmissions over TCP - which the next hop >> > perhaps would not expect - but other than that, are there >> any problems >> > with this scenario? >> > >> > Regards, >> > >> > Jeroen van Bemmel > > _______________________________________________ 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 sip-bounces@ietf.org Wed Feb 08 11:57:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6sdg-0000L4-6U; Wed, 08 Feb 2006 11:57:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6sdd-0000Jy-9T for sip@megatron.ietf.org; Wed, 08 Feb 2006 11:57:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09464 for ; Wed, 8 Feb 2006 11:56:10 -0500 (EST) Received: from web8606.mail.in.yahoo.com ([202.43.219.81]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F6sqD-0003ti-00 for sip@ietf.org; Wed, 08 Feb 2006 12:10:56 -0500 Received: (qmail 86734 invoked by uid 60001); 8 Feb 2006 16:57:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5UWv9aG7W1fmx5SS78TNgWQohqz8/boIY+QNPzdx+QnoBEc1SqDvEm92YtTB2r2t7rf+FDo4qrU6zaGaNkI3MsEn2Ngekeb+bDByK4zq6/s9qfLxpmqCatsg5HC50XxKm1u/i+JKa+tTiCgFlP+hIeI/TWoMNN1CS7PM0U6ofrY= ; Message-ID: <20060208165743.86732.qmail@web8606.mail.in.yahoo.com> Received: from [210.214.40.59] by web8606.mail.in.yahoo.com via HTTP; Wed, 08 Feb 2006 16:57:43 GMT Date: Wed, 8 Feb 2006 16:57:43 +0000 (GMT) From: "Thejeswara Reddy.P" Subject: Re: [Sip] stateless forwarding UDP->TCP by proxy To: Jonathan Rosenberg , Jeroen van Bemmel In-Reply-To: <43E9EC46.8070604@cisco.com> MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1547540545==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1547540545== Content-Type: multipart/alternative; boundary="0-1680177384-1139417863=:85650" Content-Transfer-Encoding: 8bit --0-1680177384-1139417863=:85650 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I think Proxy has to maintain the state of converted (UDP---> TCP) transports. So that it will not forward the same UDP request (retransmitted ) over TCP for next hop. ---- theja reddy Jonathan Rosenberg wrote: I think it will work. You'll need to make sure that all requests for the same transaction land on the same tcp connection, but this can be done statelessly. -Jonathan R. Jeroen van Bemmel wrote: > Would a proxy be allowed to forward a request transaction statelessly > when switching from UDP to TCP (e.g. because the request becomes too big > for UDP)? > > RFC3261 16.1 states "[...] Requests forwarded between different types of > transports where the proxy's TU must take an active role in ensuring > reliable delivery on one of the transports MUST be forwarded transaction > statefully." > > However, for the UDP->TCP case it would seem that reliability is ensured > because retransmitted requests on UDP would be passed upstream again > (over TCP), and eventually trigger a retransmission of the response. > This would result in retransmissions over TCP - which the next hop > perhaps would not expect - but other than that, are there any problems > with this scenario? > > Regards, > > Jeroen van Bemmel > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.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 --------------------------------- Jiyo cricket on Yahoo! India cricket Yahoo! Messenger Mobile Stay in touch with your buddies all the time. --0-1680177384-1139417863=:85650 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit  I think Proxy has to maintain the state of converted (UDP---> TCP) transports.

So that it will not forward the same UDP request (retransmitted ) over TCP for next hop.



---- theja reddy

Jonathan Rosenberg <jdrosen@cisco.com> wrote:
I think it will work. You'll need to make sure that all requests for the
same transaction land on the same tcp connection, but this can be done
statelessly.

-Jonathan R.

Jeroen van Bemmel wrote:
> Would a proxy be allowed to forward a request transaction statelessly
> when switching from UDP to TCP (e.g. because the request becomes too big
> for UDP)?
>
> RFC3261 16.1 states "[...] Requests forwarded between different types of
> transports where the proxy's TU must take an active role in ensuring
> ! reliable delivery on one of the transports MUST be forwarded transaction
> statefully."
>
> However, for the UDP->TCP case it would seem that reliability is ensured
> because retransmitted requests on UDP would be passed upstream again
> (over TCP), and eventually trigger a retransmission of the response.
> This would result in retransmissions over TCP - which the next hop
> perhaps would not expect - but other than that, are there any problems
> with this scenario?
>
> Regards,
>
> Jeroen van Bemmel
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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
Cisco Fellow Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.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

Jiyo cricket on Yahoo! India cricket
Yahoo! Messenger Mobile Stay in touch with your buddies all the time. --0-1680177384-1139417863=:85650-- --===============1547540545== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1547540545==-- From sip-bounces@ietf.org Wed Feb 08 12:01:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6sgw-0001j9-Fb; Wed, 08 Feb 2006 12:01:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6sgt-0001h6-Cs for sip@megatron.ietf.org; Wed, 08 Feb 2006 12:01:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09768 for ; Wed, 8 Feb 2006 11:59:32 -0500 (EST) Received: from mail.us.es ([193.147.175.20] helo=us.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6stV-00043F-BB for sip@ietf.org; Wed, 08 Feb 2006 12:14:19 -0500 Received: (qmail 4733 invoked from network); 8 Feb 2006 18:00:58 +0100 Received: from unknown (HELO us.es) (192.168.2.12) by us.es with SMTP; 8 Feb 2006 18:00:58 +0100 Received: (qmail 24081 invoked from network); 8 Feb 2006 17:00:57 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on antivirus2 X-Spam-Level: * X-Spam-Status: No, score=1.8 required=7.5 tests=BAYES_50,SUSPICIOUS_RECIPS autolearn=disabled version=3.1.0 Received: from localhost (HELO us.es) (127.0.0.1) by us.es with SMTP; 8 Feb 2006 18:00:57 +0100 Received: (qmail 8799 invoked from network); 8 Feb 2006 18:00:59 +0100 Received: from cartuja.us.es (193.147.161.37) by us.es with SMTP; 8 Feb 2006 18:00:59 +0100 Received: from [192.168.200.52] (ait04.us.es [193.147.162.165]) by cartuja.us.es (8.9.3/8.9.1) with ESMTP id SAA05979; Wed, 8 Feb 2006 18:00:18 GMT Message-ID: <43EA23AD.1060103@yahoo.es> Date: Wed, 08 Feb 2006 18:00:29 +0100 From: =?ISO-8859-1?Q?=C1lvaro_Canivell_Garc=EDa_de_Paredes?= User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: [Sip] Solutions to NAT: STUN References: <20060112184633.24077.qmail@web52813.mail.yahoo.com> <43C7B02C.3080603@yahoo.es> <43E9EDFE.8090304@yahoo.es> In-Reply-To: <43E9EDFE.8090304@yahoo.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Spam-Score: 3.0 (+++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA09768 Cc: sip@ietf.org, sipping@ietf.org, sip_protocol@yahoogroups.com, sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Sorry, there was a typo in my message, the RFC is 3489, not 3849. =C1lvaro =C1lvaro Canivell Garc=EDa de Paredes wrote: > Found out the following: > > Sip-communcator makes use of stun4j implementation of STUN. This=20 > implementation, at least the last CVS, can discover de NAT type=20 > (Discovery Process in rfc3849)(i have port restricted cone NAT), and=20 > also discover the public address of the client (Binding Acquisition in=20 > rfc3849), from the client that is behind a NAT. > > However, it doesn't implement Binding Lifetime Discovery (rfc3849).=20 > That is usefull if thje client needs to refresh the NAT bindings from=20 > time to time. > > With the current implementation of stun4j, I can send out of the NAT=20 > SIP messages with the public IP address in the contact, and media=20 > specification (in case of SDP usage). But requests coming from outside=20 > into the NAT, are NOT ALWAYS routed into the client. I guess this is=20 > because the bindings in the NAT are deleted, after some time. > > Any idea on how to keep bindings alive, any roundabout method? > > =C1lvaro > > > __________ NOD32 1.1399 (20060208) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.nod32.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 sip-bounces@ietf.org Wed Feb 08 14:44:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6vEU-0006Zq-HR; Wed, 08 Feb 2006 14:44:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6vES-0006ZS-NT for sip@megatron.ietf.org; Wed, 08 Feb 2006 14:44:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25597 for ; Wed, 8 Feb 2006 14:42:22 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6vR6-0002Qp-Bz for sip@ietf.org; Wed, 08 Feb 2006 14:57:09 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 08 Feb 2006 11:43:54 -0800 X-IronPort-AV: i="4.02,98,1139212800"; d="scan'208,217"; a="402452276:sNHT42139992" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k18JhrWF028657 for ; Wed, 8 Feb 2006 11:43:54 -0800 (PST) Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Feb 2006 14:43:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 8 Feb 2006 14:43:49 -0500 Message-ID: <8983EC086A9D954BA74D9763E853CF3E01226CB4@xmb-rtp-215.amer.cisco.com> Thread-Topic: PUBLISH and PAI/PPI Thread-Index: AcYs5/uEr1gj/KZ3RW+GyCwTFBbo5Q== From: "Sanjay Sinha \(sanjsinh\)" To: X-OriginalArrivalTime: 08 Feb 2006 19:43:50.0552 (UTC) FILETIME=[FC1DD980:01C62CE7] X-Spam-Score: 0.5 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Sip] PUBLISH and PAI/PPI X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0237280249==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0237280249== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62CE7.FC1765D5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C62CE7.FC1765D5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RFC 3325 lists out SIP methods in which P-Asserted-Identity/P-Preferred-Identity header is applicable. But PUBLISH is missing from the list. Neither is this header support listed in PUBLISH RFC, 3903. Just wanted to confirm if these headers are applicable to PUBLISH or not? =20 Thanks. ------_=_NextPart_001_01C62CE7.FC1765D5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
RFC = 3325 lists out=20 SIP methods in which P-Asserted-Identity/P-Preferred-Identity header is = applicable.=20 But PUBLISH is missing from the list. Neither is this header support = listed in=20 PUBLISH RFC, 3903.
Just = wanted to=20 confirm if these headers are applicable to PUBLISH or = not?
 
Thanks.
------_=_NextPart_001_01C62CE7.FC1765D5-- --===============0237280249== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0237280249==-- From sip-bounces@ietf.org Wed Feb 08 15:56:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6wMf-00086T-4c; Wed, 08 Feb 2006 15:56:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6wMd-000853-5g for sip@megatron.ietf.org; Wed, 08 Feb 2006 15:56:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02261 for ; Wed, 8 Feb 2006 15:54:44 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6wZ9-0005P3-Gp for sip@ietf.org; Wed, 08 Feb 2006 16:09:32 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 08 Feb 2006 12:56:17 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k18KtjL3020460 for ; Wed, 8 Feb 2006 12:56:16 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Feb 2006 15:55:57 -0500 Received: from [64.102.206.201] ([64.102.206.201]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Feb 2006 15:55:57 -0500 Message-ID: <43EA5ADE.50503@cisco.com> Date: Wed, 08 Feb 2006 15:55:58 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Sanjay Sinha (sanjsinh)" Subject: Re: [Sip] PUBLISH and PAI/PPI References: <8983EC086A9D954BA74D9763E853CF3E01226CB4@xmb-rtp-215.amer.cisco.com> In-Reply-To: <8983EC086A9D954BA74D9763E853CF3E01226CB4@xmb-rtp-215.amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Feb 2006 20:55:57.0694 (UTC) FILETIME=[0F4B51E0:01C62CF2] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org It should be applicable. -Jonathan R. Sanjay Sinha (sanjsinh) wrote: > RFC 3325 lists out SIP methods in which > P-Asserted-Identity/P-Preferred-Identity header is applicable. But > PUBLISH is missing from the list. Neither is this header support listed > in PUBLISH RFC, 3903. > Just wanted to confirm if these headers are applicable to PUBLISH or not? > > 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 -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.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 sip-bounces@ietf.org Wed Feb 08 16:33:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6wwT-0000Xp-GO; Wed, 08 Feb 2006 16:33:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6wwR-0000Wu-Vo for sip@megatron.ietf.org; Wed, 08 Feb 2006 16:33:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05264 for ; Wed, 8 Feb 2006 16:31:45 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6x8y-0006kZ-Kg for sip@ietf.org; Wed, 08 Feb 2006 16:46:34 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 08 Feb 2006 13:33:00 -0800 X-IronPort-AV: i="4.02,98,1139212800"; d="scan'208"; a="402507407:sNHT8802436950" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k18LWujt011751; Wed, 8 Feb 2006 13:32:59 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Feb 2006 16:32:56 -0500 Received: from [64.102.206.201] ([64.102.206.201]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Feb 2006 16:32:55 -0500 Message-ID: <43EA6388.1050407@cisco.com> Date: Wed, 08 Feb 2006 16:32:56 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brett Tate Subject: Re: [Sip] stateless forwarding UDP->TCP by proxy References: <000301c62cc3$7c820b20$2c28a8c0@brett1> In-Reply-To: <000301c62cc3$7c820b20$2c28a8c0@brett1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Feb 2006 21:32:55.0973 (UTC) FILETIME=[397DD550:01C62CF7] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Ah yes - sorry about that. You're right. -Jonathan R. Brett Tate wrote: > Unfortunately RFC 3261 removed retrying 3xx-6xx responses over reliable > connections. Thus such responses might only be sent once over the udp > portion when a 1xx was previously sent. > > > >>-----Original Message----- >>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >>Behalf Of Jonathan Rosenberg >>Sent: Wednesday, February 08, 2006 8:04 AM >>To: Jeroen van Bemmel >>Cc: sip@ietf.org >>Subject: Re: [Sip] stateless forwarding UDP->TCP by proxy >> >> >>I think it will work. You'll need to make sure that all >>requests for the >>same transaction land on the same tcp connection, but this >>can be done >>statelessly. >> >>-Jonathan R. >> >>Jeroen van Bemmel wrote: >> >>>Would a proxy be allowed to forward a request transaction >> >>statelessly >> >>>when switching from UDP to TCP (e.g. because the request >> >>becomes too big >> >>>for UDP)? >>> >>>RFC3261 16.1 states "[...] Requests forwarded between >> >>different types >> >>>of >>>transports where the proxy's TU must take an active role in >> >>ensuring >> >>>reliable delivery on one of the transports MUST be >> >>forwarded transaction >> >>>statefully." >>> >>>However, for the UDP->TCP case it would seem that reliability is >>>ensured >>>because retransmitted requests on UDP would be passed >> >>upstream again >> >>>(over TCP), and eventually trigger a retransmission of the >> >>response. >> >>>This would result in retransmissions over TCP - which the next hop >>>perhaps would not expect - but other than that, are there >> >>any problems >> >>>with this scenario? >>> >>>Regards, >>> >>>Jeroen van Bemmel > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.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 sip-bounces@ietf.org Thu Feb 09 03:51:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F77W7-0001pz-Mb; Thu, 09 Feb 2006 03:51:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F77W5-0001lY-JF for sip@megatron.ietf.org; Thu, 09 Feb 2006 03:51:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00121 for ; Thu, 9 Feb 2006 03:49:22 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F77iq-0006bO-4g for sip@ietf.org; Thu, 09 Feb 2006 04:04:17 -0500 Received: from [10.10.2.124] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k198vPan010153 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 9 Feb 2006 02:57:27 -0600 In-Reply-To: <8983EC086A9D954BA74D9763E853CF3E01226CB4@xmb-rtp-215.amer.cisco.com> References: <8983EC086A9D954BA74D9763E853CF3E01226CB4@xmb-rtp-215.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] PUBLISH and PAI/PPI Date: Thu, 9 Feb 2006 02:51:10 -0600 To: Sanjay Sinha ((sanjsinh)) X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 8, 2006, at 1:43 PM, Sanjay Sinha ((sanjsinh)) wrote: > RFC 3325 lists out SIP methods in which P-Asserted-Identity/P- > Preferred-Identity header is applicable. But PUBLISH is missing > from the list. Neither is this header support listed in PUBLISH > RFC, 3903. > Just wanted to confirm if these headers are applicable to PUBLISH > or not? > I'm aware of no reason it would not work. I believe we discussed this on one of the lists about two years ago and decided this was simply an oversight in the RFC. I believe the IMS people are using p-aid with PUBLISH. -- 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 sip-bounces@ietf.org Thu Feb 09 04:38:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F78GP-0002T8-A2; Thu, 09 Feb 2006 04:38:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F78GM-0002Sp-VN for sip@megatron.ietf.org; Thu, 09 Feb 2006 04:38:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03404 for ; Thu, 9 Feb 2006 04:37:03 -0500 (EST) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F78Sw-0008AE-DQ for sip@ietf.org; Thu, 09 Feb 2006 04:51:59 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 67F264F0018; Thu, 9 Feb 2006 10:38:28 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Feb 2006 10:38:28 +0100 Received: from esealmw103.eemea.ericsson.se ([153.88.200.66]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Feb 2006 10:38:28 +0100 x-mimeole: Produced By Microsoft Exchange V6.5.7226.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] PUBLISH and PAI/PPI Date: Thu, 9 Feb 2006 10:38:22 +0100 Message-ID: <425A3BC99494A4409BEF99524478ED5201F63033@esealmw103.eemea.ericsson.se> Thread-Topic: [Sip] PUBLISH and PAI/PPI Thread-Index: AcYtVnsSKn0snCDHTdWV3ssEjzPZQwABO9HQ From: "Kristoffer Gronowski \(AL/EAB\)" To: "Dean Willis" , "Sanjay Sinha \(\(sanjsinh\)\)" X-OriginalArrivalTime: 09 Feb 2006 09:38:28.0143 (UTC) FILETIME=[94AFD3F0:01C62D5C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Yes it is used in IMS systems that run OMA PAG. In the 3GPP spec 24.229 there is a reference to that Publish has a P-Asserted-ID and then it refers to rfc3325 section 9.1 But in that section there is nothing about Publish but I think that it is a matter of oversight both in IETF and 3GPP. The 3325 can not point to PUBLISH rfc since it was released after. The RFC 3903 should have had PAI listed in section 11.1.1. BR Kristoffer -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean Willis Sent: den 9 februari 2006 09:51 To: Sanjay Sinha ((sanjsinh)) Cc: sip@ietf.org Subject: Re: [Sip] PUBLISH and PAI/PPI On Feb 8, 2006, at 1:43 PM, Sanjay Sinha ((sanjsinh)) wrote: > RFC 3325 lists out SIP methods in which P-Asserted-Identity/P-=20 > Preferred-Identity header is applicable. But PUBLISH is missing from=20 > the list. Neither is this header support listed in PUBLISH RFC, 3903. > Just wanted to confirm if these headers are applicable to PUBLISH or=20 > not? > I'm aware of no reason it would not work. I believe we discussed this on one of the lists about two years ago and decided this was simply an oversight in the RFC. I believe the IMS people are using p-aid with PUBLISH. -- 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 sip-bounces@ietf.org Thu Feb 09 04:48:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F78PM-0004dE-0O; Thu, 09 Feb 2006 04:48:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F78O8-0004HB-B1 for sip@megatron.ietf.org; Thu, 09 Feb 2006 04:46:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03905 for ; Thu, 9 Feb 2006 04:45:13 -0500 (EST) Received: from c243-111.rim.net ([216.9.243.111] helo=MHS02YKF.rim.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F78au-0008QJ-GI for sip@ietf.org; Thu, 09 Feb 2006 05:00:08 -0500 Received: from ngw02ykf.rim.net ([10.102.108.31]) by MHS02YKF.rim.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Feb 2006 04:46:48 -0500 Importance: normal Priority: normal Received: from XCH21YKF.rim.net ([10.102.100.36]) by ngw02ykf.rim.net (SAVSMTP 3.1.6.45) with SMTP id M2006020904464809547 ; Thu, 09 Feb 2006 04:46:48 -0500 Received: from XCH30YKF.rim.net ([10.102.100.42]) by XCH21YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 9 Feb 2006 04:46:48 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Sip] PUBLISH and PAI/PPI Date: Thu, 9 Feb 2006 04:46:47 -0500 Message-ID: Thread-Topic: [Sip] PUBLISH and PAI/PPI thread-index: AcYtVnsSKn0snCDHTdWV3ssEjzPZQwABO9HQAACVBpQ= From: "Andrew Allen" To: , , X-OriginalArrivalTime: 09 Feb 2006 09:46:48.0282 (UTC) FILETIME=[BECAFBA0:01C62D5D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Interesting dilemma. The P-Asserted-Identity is a "P-header" that is not a standards track = RFC. But RFC 3903 is standards track.=20 Should the table in standards track RFC include all headers that are not = standards track? Andrew -------------------------- Andrew Allen Manager Standards Research In Motion Ltd BlackBerry Mobile +1 847 809 8636 http://www.rim.com/ Sent from my BlackBerry Wireless Handheld ----- Original Message ----- From: sip-bounces@ietf.org To: Dean Willis; Sanjay Sinha ((sanjsinh)) Cc: sip@ietf.org Sent: Thu Feb 09 04:38:22 2006 Subject: RE: [Sip] PUBLISH and PAI/PPI Yes it is used in IMS systems that run OMA PAG. In the 3GPP spec 24.229 there is a reference to that Publish has a P-Asserted-ID and then it refers to rfc3325 section 9.1 But in that section there is nothing about Publish but I think that it is a matter of oversight both in IETF and 3GPP. The 3325 can not point to PUBLISH rfc since it was released after. The RFC 3903 should have had PAI listed in section 11.1.1. BR Kristoffer -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean Willis Sent: den 9 februari 2006 09:51 To: Sanjay Sinha ((sanjsinh)) Cc: sip@ietf.org Subject: Re: [Sip] PUBLISH and PAI/PPI On Feb 8, 2006, at 1:43 PM, Sanjay Sinha ((sanjsinh)) wrote: > RFC 3325 lists out SIP methods in which P-Asserted-Identity/P-=20 > Preferred-Identity header is applicable. But PUBLISH is missing from=20 > the list. Neither is this header support listed in PUBLISH RFC, 3903. > Just wanted to confirm if these headers are applicable to PUBLISH or=20 > not? > I'm aware of no reason it would not work. I believe we discussed this on one of the lists about two years ago and decided this was simply an oversight in the RFC. I believe the IMS people are using p-aid with PUBLISH. -- 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 --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this = transmission in error, please immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be unlawful. _______________________________________________ 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 sip-bounces@ietf.org Thu Feb 09 05:04:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F78et-0003Nq-Lf; Thu, 09 Feb 2006 05:04:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F78eo-0003M8-Pi for sip@megatron.ietf.org; Thu, 09 Feb 2006 05:04:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05161 for ; Thu, 9 Feb 2006 05:02:17 -0500 (EST) Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F78rN-0000aC-Fo for sip@ietf.org; Thu, 09 Feb 2006 05:17:13 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k19A3q0j008884; Thu, 9 Feb 2006 12:03:52 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Feb 2006 12:03:52 +0200 Received: from [172.21.39.133] ([172.21.39.133]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 9 Feb 2006 12:03:52 +0200 Message-ID: <43EB1386.7080409@nokia.com> Date: Thu, 09 Feb 2006 12:03:50 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Andrew Allen Subject: Re: [Sip] PUBLISH and PAI/PPI References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Feb 2006 10:03:52.0358 (UTC) FILETIME=[21309460:01C62D60] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: sanjsinh@cisco.com, sip@ietf.org, kristoffer.gronowski@ericsson.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I think it only makes sense to list applicability of a header field to specific methods if they are only supposed to be used with those methods alone. Outside of that, the IANA registry is the place to look for header fields and methods alike. The tables in individual RFCs only add to the confusion. Cheers, Aki ext Andrew Allen wrote: > Interesting dilemma. > > The P-Asserted-Identity is a "P-header" that is not a standards track > RFC. But RFC 3903 is standards track. > > Should the table in standards track RFC include all headers that are > not standards track? > > Andrew > > -------------------------- Andrew Allen Manager Standards Research In > Motion Ltd BlackBerry Mobile +1 847 809 8636 http://www.rim.com/ > > Sent from my BlackBerry Wireless Handheld > > > ----- Original Message ----- From: sip-bounces@ietf.org To: Dean > Willis; Sanjay Sinha ((sanjsinh)) Cc: sip@ietf.org Sent: Thu Feb 09 > 04:38:22 2006 Subject: RE: [Sip] PUBLISH and PAI/PPI > > Yes it is used in IMS systems that run OMA PAG. In the 3GPP spec > 24.229 there is a reference to that Publish has a P-Asserted-ID and > then it refers to rfc3325 section 9.1 But in that section there is > nothing about Publish but I think that it is a matter of oversight > both in IETF and 3GPP. The 3325 can not point to PUBLISH rfc since it > was released after. The RFC 3903 should have had PAI listed in > section 11.1.1. > > BR Kristoffer > > -----Original Message----- From: sip-bounces@ietf.org > [mailto:sip-bounces@ietf.org] On Behalf Of Dean Willis Sent: den 9 > februari 2006 09:51 To: Sanjay Sinha ((sanjsinh)) Cc: sip@ietf.org > Subject: Re: [Sip] PUBLISH and PAI/PPI > > > > On Feb 8, 2006, at 1:43 PM, Sanjay Sinha ((sanjsinh)) wrote: > > >> RFC 3325 lists out SIP methods in which P-Asserted-Identity/P- >> Preferred-Identity header is applicable. But PUBLISH is missing >> from the list. Neither is this header support listed in PUBLISH >> RFC, 3903. Just wanted to confirm if these headers are applicable >> to PUBLISH or not? >> > > > I'm aware of no reason it would not work. I believe we discussed this > on one of the lists about two years ago and decided this was simply > an oversight in the RFC. I believe the IMS people are using p-aid > with PUBLISH. > > -- 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 > > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain > confidential information, privileged material (including material > protected by the solicitor-client or other applicable privileges), or > constitute non-public information. Any use of this information by > anyone other than the intended recipient is prohibited. If you have > received this transmission in error, please immediately reply to the > sender and delete this information from your system. Use, > dissemination, distribution, or reproduction of this transmission by > unintended recipients is not authorized and may be unlawful. > > _______________________________________________ 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 sip-bounces@ietf.org Thu Feb 09 09:43:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7D1E-0005qr-54; Thu, 09 Feb 2006 09:43:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7D1B-0005pE-Qj for sip@megatron.ietf.org; Thu, 09 Feb 2006 09:43:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26973 for ; Thu, 9 Feb 2006 09:41:46 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7DDs-0001wk-EK for sip@ietf.org; Thu, 09 Feb 2006 09:56:43 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 09 Feb 2006 09:43:16 -0500 X-IronPort-AV: i="4.02,100,1139202000"; d="scan'208"; a="82043970:sNHT34657696" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k19Egs6R027408; Thu, 9 Feb 2006 09:43:13 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Feb 2006 09:43:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] PUBLISH and PAI/PPI Date: Thu, 9 Feb 2006 09:43:12 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3010FA1FA@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Sip] PUBLISH and PAI/PPI Thread-Index: AcYtYJFI/IGRRQRIR1uj4nhnbuQJkAAJg4Vw From: "Michael Hammer \(mhammer\)" To: "Aki Niemi" , "ext Andrew Allen" X-OriginalArrivalTime: 09 Feb 2006 14:43:13.0215 (UTC) FILETIME=[277064F0:01C62D87] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: quoted-printable Cc: "Sanjay Sinha \(sanjsinh\)" , sip@ietf.org, kristoffer.gronowski@ericsson.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Are you suggesting that such tables should no longer be embedded in each RFC? Or, are you suggesting it would be better to have an uber-table IANA registry that can be updated every time we discover a new header-method usage mapping. =20 But, that may require an uber-table RFC on which that IANA registry is based. Mike > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Aki Niemi > Sent: Thursday, February 09, 2006 5:04 AM > To: ext Andrew Allen > Cc: Sanjay Sinha (sanjsinh); sip@ietf.org;=20 > kristoffer.gronowski@ericsson.com; dean.willis@softarmor.com > Subject: Re: [Sip] PUBLISH and PAI/PPI >=20 > I think it only makes sense to list applicability of a header=20 > field to specific methods if they are only supposed to be=20 > used with those methods alone. >=20 > Outside of that, the IANA registry is the place to look for=20 > header fields and methods alike. The tables in individual=20 > RFCs only add to the confusion. >=20 > Cheers, > Aki >=20 > ext Andrew Allen wrote: > > Interesting dilemma. > >=20 > > The P-Asserted-Identity is a "P-header" that is not a=20 > standards track=20 > > RFC. But RFC 3903 is standards track. > >=20 > > Should the table in standards track RFC include all headers=20 > that are=20 > > not standards track? > >=20 > > Andrew > >=20 > > -------------------------- Andrew Allen Manager Standards=20 > Research In=20 > > Motion Ltd BlackBerry Mobile +1 847 809 8636 http://www.rim.com/ > >=20 > > Sent from my BlackBerry Wireless Handheld > >=20 > >=20 > > ----- Original Message ----- From: sip-bounces@ietf.org To: Dean=20 > > Willis; Sanjay Sinha ((sanjsinh)) Cc: sip@ietf.org Sent: Thu Feb 09 > > 04:38:22 2006 Subject: RE: [Sip] PUBLISH and PAI/PPI > >=20 > > Yes it is used in IMS systems that run OMA PAG. In the 3GPP spec > > 24.229 there is a reference to that Publish has a P-Asserted-ID and=20 > > then it refers to rfc3325 section 9.1 But in that section there is=20 > > nothing about Publish but I think that it is a matter of oversight=20 > > both in IETF and 3GPP. The 3325 can not point to PUBLISH=20 > rfc since it=20 > > was released after. The RFC 3903 should have had PAI listed=20 > in section=20 > > 11.1.1. > >=20 > > BR Kristoffer > >=20 > > -----Original Message----- From: sip-bounces@ietf.org=20 > > [mailto:sip-bounces@ietf.org] On Behalf Of Dean Willis Sent: den 9=20 > > februari 2006 09:51 To: Sanjay Sinha ((sanjsinh)) Cc: sip@ietf.org > > Subject: Re: [Sip] PUBLISH and PAI/PPI > >=20 > >=20 > >=20 > > On Feb 8, 2006, at 1:43 PM, Sanjay Sinha ((sanjsinh)) wrote: > >=20 > >=20 > >> RFC 3325 lists out SIP methods in which P-Asserted-Identity/P-=20 > >> Preferred-Identity header is applicable. But PUBLISH is=20 > missing from=20 > >> the list. Neither is this header support listed in PUBLISH=20 > RFC, 3903.=20 > >> Just wanted to confirm if these headers are applicable to=20 > PUBLISH or=20 > >> not? > >>=20 > >=20 > >=20 > > I'm aware of no reason it would not work. I believe we=20 > discussed this=20 > > on one of the lists about two years ago and decided this=20 > was simply an=20 > > oversight in the RFC. I believe the IMS people are using p-aid with=20 > > PUBLISH. > >=20 > > -- Dean > >=20 > >=20 > >=20 > > _______________________________________________ Sip mailing list=20 > > https://www1.ietf.org/mailman/listinfo/sip This list is for NEW=20 > > development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 > > _______________________________________________ Sip mailing list=20 > > https://www1.ietf.org/mailman/listinfo/sip This list is for NEW=20 > > development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 > >=20 > >=20 > >=20 > --------------------------------------------------------------------- > > This transmission (including any attachments) may contain=20 > > confidential information, privileged material (including material=20 > > protected by the solicitor-client or other applicable=20 > privileges), or=20 > > constitute non-public information. Any use of this information by=20 > > anyone other than the intended recipient is prohibited. If you have=20 > > received this transmission in error, please immediately=20 > reply to the=20 > > sender and delete this information from your system. Use,=20 > > dissemination, distribution, or reproduction of this=20 > transmission by=20 > > unintended recipients is not authorized and may be unlawful. > >=20 > > _______________________________________________ Sip mailing list=20 > > https://www1.ietf.org/mailman/listinfo/sip This list is for NEW=20 > > development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > 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 sip-bounces@ietf.org Thu Feb 09 10:12:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7DSi-00007G-Ep; Thu, 09 Feb 2006 10:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7DSg-00006M-Lr for sip@megatron.ietf.org; Thu, 09 Feb 2006 10:11:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29147 for ; Thu, 9 Feb 2006 10:10:15 -0500 (EST) Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7DfU-0002uR-1q for sip@ietf.org; Thu, 09 Feb 2006 10:25:13 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k19FBjTq002115; Thu, 9 Feb 2006 17:11:49 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Feb 2006 17:11:47 +0200 Received: from [172.21.39.133] ([172.21.39.133]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 9 Feb 2006 17:11:47 +0200 Message-ID: <43EB5BB3.5090303@nokia.com> Date: Thu, 09 Feb 2006 17:11:47 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ext Michael Hammer (mhammer)" Subject: Re: [Sip] PUBLISH and PAI/PPI References: <072C5B76F7CEAB488172C6F64B30B5E3010FA1FA@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3010FA1FA@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Feb 2006 15:11:47.0044 (UTC) FILETIME=[24F5F240:01C62D8B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: "Sanjay Sinha \(sanjsinh\)" , sip@ietf.org, kristoffer.gronowski@ericsson.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Michael, ext Michael Hammer (mhammer) wrote: > Are you suggesting that such tables should no longer be embedded in each > RFC? Yes; I'm suggesting we quit copy-pasting and augmenting tables 2 and 3 of RFC 3261. It will simply never produce tables that are complete. It will only produce questions like the one that started the thread. > Or, are you suggesting it would be better to have an uber-table IANA > registry that can be updated every time we discover a new header-method > usage mapping. No, I'm not proposing any new registry. Instead of saying that header field H is "o" (as in optional) for methods X, Y, and Z, we could simply say that H can be used in any method. Then again for header fields like Refer-To, it should be sufficient to say that it is only allowed in REFER, instead of marking it as "-" (as in not applicable) for every known method there is at the time of writing. PAI is a good example of a header field whose entire reason for existance is that it can indicate the asserted identity of the sender of any method. So it really makes no sense to specifically create a "usage" of PAI with, say, PUBLISH. Then again, SIP-ETag is another good example of a header field that will be meaningless in a method, unless it is specifically written down somewhere what it means there. > But, that may require an uber-table RFC on which that IANA registry is > based. I'm also not suggesting anything like that. I'm suggesting we forget about tables altogether. Cheers, Aki _______________________________________________ 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 sip-bounces@ietf.org Thu Feb 09 11:03:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7EGE-0000Pg-Im; Thu, 09 Feb 2006 11:03:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7EG8-0000O4-Ks for sip@megatron.ietf.org; Thu, 09 Feb 2006 11:03:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAB04440 for ; Thu, 9 Feb 2006 11:01:11 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7ESm-0005Cm-UP for sip@ietf.org; Thu, 09 Feb 2006 11:16:10 -0500 Received: from [10.10.2.124] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k19G2f3Y013132 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 9 Feb 2006 10:02:44 -0600 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3010FA1FA@xmb-rtp-20b.amer.cisco.com> References: <072C5B76F7CEAB488172C6F64B30B5E3010FA1FA@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] PUBLISH and PAI/PPI Date: Thu, 9 Feb 2006 10:02:58 -0600 To: Michael Hammer ((mhammer)) X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: "Sanjay Sinha \(sanjsinh\)" , sip@ietf.org, Aki Niemi , kristoffer.gronowski@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 9, 2006, at 8:43 AM, Michael Hammer ((mhammer)) wrote: > Are you suggesting that such tables should no longer be embedded in > each > RFC? That's what I think. This part of the documentation has caused far more headpain than the rest of the specification family, and that's a lot! -- 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 sip-bounces@ietf.org Thu Feb 09 11:28:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Eeb-0004yK-3I; Thu, 09 Feb 2006 11:28:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7EeS-0004xO-MA for sip@megatron.ietf.org; Thu, 09 Feb 2006 11:28:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06454 for ; Thu, 9 Feb 2006 11:26:21 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7Er8-00067s-8p for sip@ietf.org; Thu, 09 Feb 2006 11:41:20 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 09 Feb 2006 08:27:52 -0800 X-IronPort-AV: i="4.02,100,1139212800"; d="scan'208"; a="254512403:sNHT32416600" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k19GRgcL019346; Thu, 9 Feb 2006 08:27:50 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Feb 2006 11:27:48 -0500 Received: from [161.44.79.51] ([161.44.79.51]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Feb 2006 11:27:47 -0500 Message-ID: <43EB6D83.3060301@cisco.com> Date: Thu, 09 Feb 2006 11:27:47 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Sip] PUBLISH and PAI/PPI References: <072C5B76F7CEAB488172C6F64B30B5E3010FA1FA@xmb-rtp-20b.amer.cisco.com> <43EB5BB3.5090303@nokia.com> In-Reply-To: <43EB5BB3.5090303@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Feb 2006 16:27:47.0605 (UTC) FILETIME=[C3445450:01C62D95] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: "Sanjay Sinha \(sanjsinh\)" , sip@ietf.org, kristoffer.gronowski@ericsson.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org While the existing tables are a mess, I think there is considerable value in having a well defined way to determine where things are allowed to be used. It should be possible to come up with a formal way to say things like: "H can be used in any method", or "H may only be used in methods X,Y,Z". Then this formalized language can be included in the IANA header registry. From it, anyone could construct their own table. Paul Aki Niemi wrote: > Hi Michael, > > ext Michael Hammer (mhammer) wrote: > >> Are you suggesting that such tables should no longer be embedded in each >> RFC? > > > Yes; I'm suggesting we quit copy-pasting and augmenting tables 2 and 3 > of RFC 3261. It will simply never produce tables that are complete. It > will only produce questions like the one that started the thread. > >> Or, are you suggesting it would be better to have an uber-table IANA >> registry that can be updated every time we discover a new header-method >> usage mapping. > > > No, I'm not proposing any new registry. > > Instead of saying that header field H is "o" (as in optional) for > methods X, Y, and Z, we could simply say that H can be used in any > method. Then again for header fields like Refer-To, it should be > sufficient to say that it is only allowed in REFER, instead of marking > it as "-" (as in not applicable) for every known method there is at the > time of writing. > > PAI is a good example of a header field whose entire reason for > existance is that it can indicate the asserted identity of the sender of > any method. So it really makes no sense to specifically create a "usage" > of PAI with, say, PUBLISH. > > Then again, SIP-ETag is another good example of a header field that will > be meaningless in a method, unless it is specifically written down > somewhere what it means there. > >> But, that may require an uber-table RFC on which that IANA registry is >> based. > > > I'm also not suggesting anything like that. I'm suggesting we forget > about tables altogether. > > Cheers, > Aki > > _______________________________________________ > 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 sip-bounces@ietf.org Thu Feb 09 12:22:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7FUc-0002OD-1p; Thu, 09 Feb 2006 12:22:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7FUZ-0002MV-6f for sip@megatron.ietf.org; Thu, 09 Feb 2006 12:22:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10517 for ; Thu, 9 Feb 2006 12:20:17 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7FhM-00080m-4U for sip@ietf.org; Thu, 09 Feb 2006 12:35:17 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k19HLj3g022667; Thu, 9 Feb 2006 11:21:46 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 9 Feb 2006 17:21:44 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB01205F721@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Paul Kyzivat'" , "'Aki Niemi'" Subject: RE: [Sip] PUBLISH and PAI/PPI Date: Thu, 9 Feb 2006 17:21:42 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: "'Sanjay Sinha \(sanjsinh\)'" , "'sip@ietf.org'" , "'kristoffer.gronowski@ericsson.com'" , "'dean.willis@softarmor.com'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I have suggested in the past that rather than putting method names in this table, we would be better off using columns like "method outside dialog", "method used within an existing dialog", "method used to initiate a dialog", "target refresh request". However any such suggestion always seems to get lost in noise from Jonathan about how these tables cannot be relied upon, therefore it is not worth maintaining them. regards Keith > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > Paul Kyzivat > Sent: 09 February 2006 16:28 > To: Aki Niemi > Cc: Sanjay Sinha (sanjsinh); sip@ietf.org; > kristoffer.gronowski@ericsson.com; dean.willis@softarmor.com > Subject: Re: [Sip] PUBLISH and PAI/PPI > > > While the existing tables are a mess, I think there is considerable > value in having a well defined way to determine where things > are allowed > to be used. It should be possible to come up with a formal way to say > things like: "H can be used in any method", or "H may only be used in > methods X,Y,Z". Then this formalized language can be included in the > IANA header registry. From it, anyone could construct their own table. > > Paul > > Aki Niemi wrote: > > Hi Michael, > > > > ext Michael Hammer (mhammer) wrote: > > > >> Are you suggesting that such tables should no longer be > embedded in each > >> RFC? > > > > > > Yes; I'm suggesting we quit copy-pasting and augmenting > tables 2 and 3 > > of RFC 3261. It will simply never produce tables that are > complete. It > > will only produce questions like the one that started the thread. > > > >> Or, are you suggesting it would be better to have an > uber-table IANA > >> registry that can be updated every time we discover a new > header-method > >> usage mapping. > > > > > > No, I'm not proposing any new registry. > > > > Instead of saying that header field H is "o" (as in optional) for > > methods X, Y, and Z, we could simply say that H can be used in any > > method. Then again for header fields like Refer-To, it should be > > sufficient to say that it is only allowed in REFER, instead > of marking > > it as "-" (as in not applicable) for every known method > there is at the > > time of writing. > > > > PAI is a good example of a header field whose entire reason for > > existance is that it can indicate the asserted identity of > the sender of > > any method. So it really makes no sense to specifically > create a "usage" > > of PAI with, say, PUBLISH. > > > > Then again, SIP-ETag is another good example of a header > field that will > > be meaningless in a method, unless it is specifically written down > > somewhere what it means there. > > > >> But, that may require an uber-table RFC on which that IANA > registry is > >> based. > > > > > > I'm also not suggesting anything like that. I'm suggesting > we forget > > about tables altogether. > > > > Cheers, > > Aki > > > > _______________________________________________ > > 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 sip-bounces@ietf.org Thu Feb 09 13:09:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7GET-0002Lq-JS; Thu, 09 Feb 2006 13:09:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7GEP-0002Hj-1w for sip@megatron.ietf.org; Thu, 09 Feb 2006 13:09:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15339 for ; Thu, 9 Feb 2006 13:07:42 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7GRC-0001QI-3y for sip@ietf.org; Thu, 09 Feb 2006 13:22:41 -0500 Received: from [10.10.2.124] (expo112.palais-congres-paris.fr [212.155.202.112] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k19I9AZu013842 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 9 Feb 2006 12:09:12 -0600 In-Reply-To: <475FF955A05DD411980D00508B6D5FB01205F721@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB01205F721@en0033exch001u.uk.lucent.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <357DB2E3-E702-4E8D-92F0-37AFA6130F92@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] PUBLISH and PAI/PPI Date: Thu, 9 Feb 2006 12:09:27 -0600 To: "Drage, Keith (Keith)" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: "'Sanjay Sinha \(sanjsinh\)'" , "'sip@ietf.org'" , 'Paul Kyzivat' , 'Aki Niemi' , "'kristoffer.gronowski@ericsson.com'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 9, 2006, at 11:21 AM, Drage, Keith (Keith) wrote: > I have suggested in the past that rather than putting method names > in this table, we would be better off using columns like "method > outside dialog", "method used within an existing dialog", "method > used to initiate a dialog", "target refresh request". That's basically the approach we took in draft-ietf-sip- answermode-00.txt, which does not have the offending table. However, the representation is not concise enough to be able to populate an IANA registry, if we think we need something like that. Do we? -- 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 sip-bounces@ietf.org Thu Feb 09 15:12:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7I9i-000502-Ji; Thu, 09 Feb 2006 15:12:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7I9f-0004we-UC for sip@megatron.ietf.org; Thu, 09 Feb 2006 15:12:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25976 for ; Thu, 9 Feb 2006 15:10:57 -0500 (EST) Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7IMW-0005k3-Az for sip@ietf.org; Thu, 09 Feb 2006 15:25:57 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k19KCFH7053011; Thu, 9 Feb 2006 15:12:19 -0500 (EST) From: "Brett Tate" To: "'Jeroen van Bemmel'" Subject: RE: [Sip] stateless forwarding UDP->TCP by proxy Date: Thu, 9 Feb 2006 15:13:06 -0500 Message-ID: <001c01c62db5$405e7320$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <00af01c62cd0$6d045ce0$31713b51@BEMBUSTER> X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org It isn't just a problem when switching to use TCP because of message = size. The situation can occur anytime the stateless proxy receives a request = over UDP and proxies it using a reliable transport. The only way I know to fix problem is to get the community to start = retrying INVITE 3xx-6xx responses over reliable transports again if they are concerned by the potential problem. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Jeroen van Bemmel > Sent: Wednesday, February 08, 2006 11:55 AM > To: Brett Tate; 'Jonathan Rosenberg' > Cc: sip@ietf.org > Subject: Re: [Sip] stateless forwarding UDP->TCP by proxy >=20 >=20 > Brett, >=20 > Good point >=20 > I suppose this could be a reason to state that when possible,=20 > implementations should not send any 1xx responses (including=20 > 100 Trying)=20 > before sending a 3xx-6xx response over TCP (or any reliable=20 > transport),=20 > since it may be that some proxy along the line made the=20 > transport switch. A=20 > valid case: INVITE becoming too large due to Via /=20 > Record-Route headers.=20 > Trouble is that INVITE -> ringing -> no answer is a common scenario... >=20 > Alternatively, the 1300 byte limit for switching to TCP could=20 > be extended=20 > for proxies (say: 1300 for UAC, 1500 for proxies). Or - third=20 > option - UACs=20 > should use a smaller limit value for INVITEs, say 1000 bytes,=20 > and above that=20 > switch to TCP. >=20 > Jeroen >=20 > ----- Original Message -----=20 > From: "Brett Tate" > To: "'Jonathan Rosenberg'" ; "'Jeroen van Bemmel'"=20 > > Cc: > Sent: Wednesday, February 08, 2006 4:22 PM > Subject: RE: [Sip] stateless forwarding UDP->TCP by proxy >=20 >=20 > > Unfortunately RFC 3261 removed retrying 3xx-6xx responses over=20 > > reliable connections. Thus such responses might only be sent once=20 > > over the udp portion when a 1xx was previously sent. > > _______________________________________________ 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 sip-bounces@ietf.org Fri Feb 10 01:35:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Rsf-0002mv-QO; Fri, 10 Feb 2006 01:35:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Rsd-0002mb-UN for sip@megatron.ietf.org; Fri, 10 Feb 2006 01:35:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18037 for ; Fri, 10 Feb 2006 01:33:51 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7S5P-0003ew-Pj for sip@ietf.org; Fri, 10 Feb 2006 01:48:57 -0500 Received: by wproxy.gmail.com with SMTP id i22so284848wra for ; Thu, 09 Feb 2006 22:35:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=aGqfxcLXfD0vpdOwmcMOO+n3Gd+Y56VuVfQJY6+2Dzgl/DBr57VVWyhKiSYe+NejofHuWM4XS6fMmd1ac88ifx2oO9Xe1J1u7mMZAg5kdvDwgh+/XnIrKbM0YvYvDy+Ei/rODrLlwCs/MGIVaQYqftsOS2DpvwZAIhzvYl3Qlhg= Received: by 10.65.180.18 with SMTP id h18mr348606qbp; Thu, 09 Feb 2006 22:35:29 -0800 (PST) Received: by 10.65.192.12 with HTTP; Thu, 9 Feb 2006 22:35:29 -0800 (PST) Message-ID: <3fe6b8640602092235o249eeab4ibdafd6ea03b228cf@mail.gmail.com> Date: Fri, 10 Feb 2006 12:05:29 +0530 From: Malleswara Rao Ankem To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: [Sip] order of m lines in answer SDP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1773153152==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1773153152== Content-Type: multipart/alternative; boundary="----=_Part_5952_26314944.1139553329213" ------=_Part_5952_26314944.1139553329213 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, just wondering whether the following SDP in answer is valid or not. It can be observed that the order of the m lines in the answer has been changed. Is there any section in 3264 that disallows the behavior? thanks Mallesh Offer: v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.anywhere.com s=3D c=3DIN IP4 host.anywhere.com t=3D0 0 m=3Daudio 49170 RTP/AVP 0 a=3Drtpmap:0 PCMU/8000 m=3Dvideo 51372 RTP/AVP 31 a=3Drtpmap:31 H261/90000 m=3Dvideo 53000 RTP/AVP 32 a=3Drtpmap:32 MPV/90000 Answer: v=3D0 o=3Dbob 2890844730 2890844730 IN IP4 host.example.com s=3D c=3DIN IP4 host.example.com t=3D0 0 m=3Daudio 49920 RTP/AVP 0 a=3Drtpmap:0 PCMU/8000 m=3Dvideo 53000 RTP/AVP 32 a=3Drtpmap:32 MPV/90000 m=3Dvideo 51372 RTP/AVP 31 a=3Drtpmap:31 H261/90000 ------=_Part_5952_26314944.1139553329213 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
Hello,
 just wondering whether the following SDP in ans= wer is valid or not. It can be observed that the order of the
 m lines in the answer has been changed. Is ther= e any section in 3264 that disallows the behavior?
thanks
Mallesh
 
Offer:
v=3D0
o=3Dalice 289084452= 6 2890844526 IN IP4 host.anywhere.com
s=3D<= /font>
c=3DIN IP4 host.anywhere.com
t=3D0= 0
m=3Daudio 49170 RTP/AVP = 0
a=3Drtpmap:0 PCMU/8000
m=3Dvideo 51372 RTP/AVP 31
= a=3Drtpmap:31 H261/90000
m= =3Dvideo 53000 RTP/AVP 32
a= =3Drtpmap:32 MPV/90000=20

Answer:
v=3D0
o=3Dbob 2890844730 2890844730 IN IP4 host.example.com
s=3D
c=3DIN IP4 host.example.com
t=3D0 = 0
m=3Daudio 49920 RTP/AVP 0 =
a=3Drtpmap:0 PCMU/8000
= m=3Dvideo 53000 RTP/AVP 32
= a=3Drtpmap:32 MPV/90000
m=3Dvideo 51372 RTP/AVP 31 a=3Drtpmap:31 H261/90000
 
------=_Part_5952_26314944.1139553329213-- --===============1773153152== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1773153152==-- From sip-bounces@ietf.org Fri Feb 10 02:25:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Sel-0002JH-Nb; Fri, 10 Feb 2006 02:25:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Sek-0002Ij-At for sip@megatron.ietf.org; Fri, 10 Feb 2006 02:25:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22436 for ; Fri, 10 Feb 2006 02:23:34 -0500 (EST) Received: from s1.mailresponder.info ([193.24.237.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7SrS-0005PM-Si for sip@ietf.org; Fri, 10 Feb 2006 02:38:40 -0500 Received: from moonfish.nero.com (82.98.209.31) by s1.mailresponder.info with MERCUR Mailserver (v4.02.30 ODAtMjQzOS03MTc5) for ; Fri, 10 Feb 2006 08:24:46 +0100 Received: from smtp.ahead.de (unknown [192.168.1.222]) by moonfish.nero.com (Postfix) with ESMTP id B02C316130B; Fri, 10 Feb 2006 08:24:44 +0100 (CET) Received: from [192.168.10.31] (unknown [192.168.10.31]) by smtp.ahead.de (Postfix) with ESMTP id 02F632DE92D; Fri, 10 Feb 2006 08:24:45 +0100 (CET) Message-ID: <43EC3FBC.1010909@nero.com> Date: Fri, 10 Feb 2006 08:24:44 +0100 From: Markus Hofmann User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brett Tate Subject: Re: [Sip] stateless forwarding UDP->TCP by proxy References: <001c01c62db5$405e7320$2c28a8c0@brett1> In-Reply-To: <001c01c62db5$405e7320$2c28a8c0@brett1> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Brett, I'm sorry but I can't follow the discussion anymore. So far I understand it is possible that a proxy can switch from UDP to TCP if the message size is too big. There I do not see any problems because the proxy can put a Via header with TCP transport. Which I do not understand if a UAC decides to send its request through UDP and gets back a TCP response is this not a source of trouble because in the Via header stands UDP as transport kind. The client will expect on its UDP port the response. The next point is: Why should only non-successful response have problems with the packet size? If the answer is 3xx - 6xx no route set will be set and every proxy will remove its Via header which make the size smaller. Is there really a reason to switch to TCP? 2xx responses have a Contact header where you have the possiblity to signal that you will switch from UDP to TCP. But the UAC could be first prepared to use TCP if it evaluates the successful response. Did I understand everything right? Thank you in advance Markus Brett Tate wrote: >It isn't just a problem when switching to use TCP because of message size. > >The situation can occur anytime the stateless proxy receives a request over >UDP and proxies it using a reliable transport. > >The only way I know to fix problem is to get the community to start retrying >INVITE 3xx-6xx responses over reliable transports again if they are >concerned by the potential problem. > > > > >>-----Original Message----- >>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >>Behalf Of Jeroen van Bemmel >>Sent: Wednesday, February 08, 2006 11:55 AM >>To: Brett Tate; 'Jonathan Rosenberg' >>Cc: sip@ietf.org >>Subject: Re: [Sip] stateless forwarding UDP->TCP by proxy >> >> >>Brett, >> >>Good point >> >>I suppose this could be a reason to state that when possible, >>implementations should not send any 1xx responses (including >>100 Trying) >>before sending a 3xx-6xx response over TCP (or any reliable >>transport), >>since it may be that some proxy along the line made the >>transport switch. A >>valid case: INVITE becoming too large due to Via / >>Record-Route headers. >>Trouble is that INVITE -> ringing -> no answer is a common scenario... >> >>Alternatively, the 1300 byte limit for switching to TCP could >>be extended >>for proxies (say: 1300 for UAC, 1500 for proxies). Or - third >>option - UACs >>should use a smaller limit value for INVITEs, say 1000 bytes, >>and above that >>switch to TCP. >> >>Jeroen >> >>----- Original Message ----- >>From: "Brett Tate" >>To: "'Jonathan Rosenberg'" ; "'Jeroen van Bemmel'" >> >>Cc: >>Sent: Wednesday, February 08, 2006 4:22 PM >>Subject: RE: [Sip] stateless forwarding UDP->TCP by proxy >> >> >> >> >>>Unfortunately RFC 3261 removed retrying 3xx-6xx responses over >>>reliable connections. Thus such responses might only be sent once >>>over the udp portion when a 1xx was previously sent. >>> >>> >>> > > > >_______________________________________________ >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 sip-bounces@ietf.org Fri Feb 10 02:40:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Ssv-0008JS-Nh; Fri, 10 Feb 2006 02:40:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Sss-0008IA-1P for sip@megatron.ietf.org; Fri, 10 Feb 2006 02:40:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24012 for ; Fri, 10 Feb 2006 02:38:09 -0500 (EST) Received: from mx0.aculab.com ([213.249.233.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7T5e-0005vw-Dl for sip@ietf.org; Fri, 10 Feb 2006 02:53:15 -0500 Received: from localhost (localhost [127.0.0.1]) by mx0.aculab.com (Postfix) with ESMTP id 1C7168734C; Fri, 10 Feb 2006 07:39:14 +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 12041-03; Fri, 10 Feb 2006 07:38:59 +0000 (GMT) Received: from saturn.Aculab.com (saturn [10.202.163.6]) by mx0.aculab.com (Postfix) with ESMTP id 0D06A87350; Fri, 10 Feb 2006 07:38:59 +0000 (GMT) Received: by saturn.aculab.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Feb 2006 07:39:01 -0000 Message-ID: <826EB38238D76947BE8A865F645C7BC7026C262F@saturn.aculab.com> From: Matthew Gardiner To: "'Malleswara Rao Ankem'" , sip@ietf.org Subject: RE: [Sip] order of m lines in answer SDP Date: Fri, 10 Feb 2006 07:39:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Aculab-Com-Scanned: by amavisd-new-20030616-p10 (Debian) at aculab.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0384563506==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org 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. --===============0384563506== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62E14.CA890B03" 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_01C62E14.CA890B03 Content-Type: text/plain; charset="iso-8859-1" The exemplified behaviour is invalid. The ordering of the m= is significant, since no unique key field is provided by SDP to differentiate individual m= lines. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Malleswara Rao Ankem Sent: 10 February 2006 06:35 To: sip@ietf.org Subject: [Sip] order of m lines in answer SDP Hello, just wondering whether the following SDP in answer is valid or not. It can be observed that the order of the m lines in the answer has been changed. Is there any section in 3264 that disallows the behavior? thanks Mallesh Offer: v=0 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com s= c=IN IP4 host.anywhere.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 51372 RTP/AVP 31 a=rtpmap:31 H261/90000 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000 Answer: v=0 o=bob 2890844730 2890844730 IN IP4 host.example.com s= c=IN IP4 host.example.com t=0 0 m=audio 49920 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000 m=video 51372 RTP/AVP 31 a=rtpmap:31 H261/90000 ------_=_NextPart_001_01C62E14.CA890B03 Content-Type: text/html; charset="iso-8859-1"
The exemplified behaviour is invalid. The ordering of the m= is significant, since no unique key field is provided by SDP to differentiate individual m= lines.
-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Malleswara Rao Ankem
Sent: 10 February 2006 06:35
To: sip@ietf.org
Subject: [Sip] order of m lines in answer SDP

Hello,
 just wondering whether the following SDP in answer is valid or not. It can be observed that the order of the
 m lines in the answer has been changed. Is there any section in 3264 that disallows the behavior?
thanks
Mallesh
 
Offer:
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000

Answer:
v=0
o=bob 2890844730 2890844730 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 49920 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
 
------_=_NextPart_001_01C62E14.CA890B03-- --===============0384563506== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0384563506==-- From sip-bounces@ietf.org Fri Feb 10 02:50:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7T2p-0003Xw-Ho; Fri, 10 Feb 2006 02:50:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Dg1-00027Z-Hx for sip@megatron.ietf.org; Thu, 09 Feb 2006 10:25:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00197 for ; Thu, 9 Feb 2006 10:24:02 -0500 (EST) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7Dsp-0003LX-F1 for sip@ietf.org; Thu, 09 Feb 2006 10:39:00 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k19FLNB17294; Thu, 9 Feb 2006 10:21:24 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] PUBLISH and PAI/PPI Date: Thu, 9 Feb 2006 09:25:18 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43710CD443D4@zrc2hxm2.corp.nortel.com> Thread-Topic: [Sip] PUBLISH and PAI/PPI Thread-Index: AcYtjDoMblREbSaPRpuAMrakuuDoawAAGorQ From: "Brian Stucker" To: "Aki Niemi" , "ext Michael Hammer \(mhammer\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 10 Feb 2006 02:50:15 -0500 Cc: "Sanjay Sinha \(sanjsinh\)" , sip@ietf.org, kristoffer.gronowski@ericsson.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I generally support your point Aki, however wouldn't we essentially wind = up with a "table-like" design detail in any new methods to describe = which headers are valid or invalid for that particular method? I would = expect that any draft building off of existing RFCs would need to = explain how existing headers interact with a new method introduced in = the draft... It could get messy either way. Regards, Brian -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Aki Niemi Sent: Thursday, February 09, 2006 9:12 AM To: ext Michael Hammer (mhammer) Cc: Sanjay Sinha (sanjsinh); sip@ietf.org; kristoffer.gronowski@ericsson.com; dean.willis@softarmor.com Subject: Re: [Sip] PUBLISH and PAI/PPI Hi Michael, ext Michael Hammer (mhammer) wrote: > Are you suggesting that such tables should no longer be embedded in = each > RFC? Yes; I'm suggesting we quit copy-pasting and augmenting tables 2 and 3=20 of RFC 3261. It will simply never produce tables that are complete. It=20 will only produce questions like the one that started the thread. > Or, are you suggesting it would be better to have an uber-table IANA > registry that can be updated every time we discover a new = header-method > usage mapping. =20 No, I'm not proposing any new registry. Instead of saying that header field H is "o" (as in optional) for=20 methods X, Y, and Z, we could simply say that H can be used in any=20 method. Then again for header fields like Refer-To, it should be=20 sufficient to say that it is only allowed in REFER, instead of marking=20 it as "-" (as in not applicable) for every known method there is at the=20 time of writing. PAI is a good example of a header field whose entire reason for=20 existance is that it can indicate the asserted identity of the sender of = any method. So it really makes no sense to specifically create a "usage" = of PAI with, say, PUBLISH. Then again, SIP-ETag is another good example of a header field that will = be meaningless in a method, unless it is specifically written down=20 somewhere what it means there. > But, that may require an uber-table RFC on which that IANA registry is > based. I'm also not suggesting anything like that. I'm suggesting we forget=20 about tables altogether. Cheers, Aki _______________________________________________ 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 sip-bounces@ietf.org Fri Feb 10 07:17:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7XDA-0003CR-Sb; Fri, 10 Feb 2006 07:17:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7XD9-00030p-3G for sip@megatron.ietf.org; Fri, 10 Feb 2006 07:17:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14208 for ; Fri, 10 Feb 2006 07:15:25 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7XQ3-0006hc-CP for sip@ietf.org; Fri, 10 Feb 2006 07:30:36 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 10 Feb 2006 04:17:00 -0800 X-IronPort-AV: i="4.02,102,1139212800"; d="scan'208"; a="254719048:sNHT35248608" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k1ACGwc1001480; Fri, 10 Feb 2006 04:16:58 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Feb 2006 04:16:58 -0800 Received: from [172.17.154.148] ([10.89.20.23]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Feb 2006 04:16:57 -0800 Message-ID: <43EC8439.2010600@cisco.com> Date: Fri, 10 Feb 2006 07:16:57 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" Subject: Re: [Sip] PUBLISH and PAI/PPI References: <475FF955A05DD411980D00508B6D5FB01205F721@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB01205F721@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Feb 2006 12:16:57.0961 (UTC) FILETIME=[E364A590:01C62E3B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Content-Transfer-Encoding: 7bit Cc: "'Sanjay Sinha \(sanjsinh\)'" , 'Aki Niemi' , "'dean.willis@softarmor.com'" , "'sip@ietf.org'" , 'Paul Kyzivat' , "'kristoffer.gronowski@ericsson.com'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The problem with the tables is that they assume an easily enumerable and consistent approach across documents of defining what methods a request go in. The problem is, it sometimes depends on other factors. Content-Type for example reuqires a special value in the table in 3261 to indicate why it needs to be there. Another problem is that you need to worry about consistency of the tables with normative text that appears elsewhere in the document about where the headers are used. And, of course, the problem that the tables become incomplete as new methods and headers get added in other specifications. The main benefit of the tables is, in principal, to provide clear guidance on construction of requests and responses. The tables force you to think about applicability of extensions. Another way to do that is to simply require that specifications of new methods include text that clearly discusses, using normative terms, applicability of various headers, and furthermore, for new header specs, defines applicability to methods. -Jonathan R. Drage, Keith (Keith) wrote: > I have suggested in the past that rather than putting method names in > this table, we would be better off using columns like "method outside > dialog", "method used within an existing dialog", "method used to > initiate a dialog", "target refresh request". > > However any such suggestion always seems to get lost in noise from > Jonathan about how these tables cannot be relied upon, therefore it > is not worth maintaining them. > > regards > > Keith > > >> -----Original Message----- From: sip-bounces@ietf.org >> [mailto:sip-bounces@ietf.org]On Behalf Of Paul Kyzivat Sent: 09 >> February 2006 16:28 To: Aki Niemi Cc: Sanjay Sinha (sanjsinh); >> sip@ietf.org; kristoffer.gronowski@ericsson.com; >> dean.willis@softarmor.com Subject: Re: [Sip] PUBLISH and PAI/PPI >> >> >> While the existing tables are a mess, I think there is considerable >> value in having a well defined way to determine where things are >> allowed to be used. It should be possible to come up with a formal >> way to say things like: "H can be used in any method", or "H may >> only be used in methods X,Y,Z". Then this formalized language can >> be included in the IANA header registry. From it, anyone could >> construct their own table. >> >> Paul >> >> Aki Niemi wrote: >> >>> Hi Michael, >>> >>> ext Michael Hammer (mhammer) wrote: >>> >>> >>>> Are you suggesting that such tables should no longer be >> >> embedded in each >> >>>> RFC? >>> >>> >>> Yes; I'm suggesting we quit copy-pasting and augmenting >> >> tables 2 and 3 >> >>> of RFC 3261. It will simply never produce tables that are >> >> complete. It >> >>> will only produce questions like the one that started the thread. >>> >>> >>> >>>> Or, are you suggesting it would be better to have an >> >> uber-table IANA >> >>>> registry that can be updated every time we discover a new >> >> header-method >> >>>> usage mapping. >>> >>> >>> No, I'm not proposing any new registry. >>> >>> Instead of saying that header field H is "o" (as in optional) for >>> methods X, Y, and Z, we could simply say that H can be used in >>> any method. Then again for header fields like Refer-To, it should >>> be sufficient to say that it is only allowed in REFER, instead >> >> of marking >> >>> it as "-" (as in not applicable) for every known method >> >> there is at the >> >>> time of writing. >>> >>> PAI is a good example of a header field whose entire reason for >>> existance is that it can indicate the asserted identity of >> >> the sender of >> >>> any method. So it really makes no sense to specifically >> >> create a "usage" >> >>> of PAI with, say, PUBLISH. >>> >>> Then again, SIP-ETag is another good example of a header >> >> field that will >> >>> be meaningless in a method, unless it is specifically written >>> down somewhere what it means there. >>> >>> >>>> But, that may require an uber-table RFC on which that IANA >> >> registry is >> >>>> based. >>> >>> >>> I'm also not suggesting anything like that. I'm suggesting >> >> we forget >> >>> about tables altogether. >>> >>> Cheers, Aki >>> >>> _______________________________________________ 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.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 sip-bounces@ietf.org Fri Feb 10 09:40:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7ZRX-0004ym-Jd; Fri, 10 Feb 2006 09:40:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7ZRV-0004vz-Jm for sip@megatron.ietf.org; Fri, 10 Feb 2006 09:40:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24320 for ; Fri, 10 Feb 2006 09:38:30 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7ZeU-0002qd-8w for sip@ietf.org; Fri, 10 Feb 2006 09:53:41 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 10 Feb 2006 06:40:00 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1AEe0KT024452; Fri, 10 Feb 2006 06:40:00 -0800 (PST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Feb 2006 09:39:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] PUBLISH and PAI/PPI Date: Fri, 10 Feb 2006 09:39:58 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30115C47C@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Sip] PUBLISH and PAI/PPI Thread-Index: AcYuPTvNezXl13eCTWaGp4azLIJxsgAEWCig From: "Michael Hammer \(mhammer\)" To: "Jonathan Rosenberg \(jdrosen\)" , "Drage, Keith \(Keith\)" X-OriginalArrivalTime: 10 Feb 2006 14:39:59.0636 (UTC) FILETIME=[DE785540:01C62E4F] X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Content-Transfer-Encoding: quoted-printable Cc: "Sanjay Sinha \(sanjsinh\)" , Aki Niemi , dean.willis@softarmor.com, sip@ietf.org, "Paul Kyzivat \(pkyzivat\)" , kristoffer.gronowski@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Jonathan, Re: incompleteness. If an RFC defining a new header addresses all known methods, and if an RFC defining a new method addresses all known headers, then the table should never be incomplete. The question is what should an RFC author define for headers/methods that were not the main focus of their draft? Say it is undefined? Say it is optional? Say it is disallowed? It seems the latter choice is what trips us up. =20 I guess this is an extensibility process question. Mike > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Jonathan Rosenberg (jdrosen) > Sent: Friday, February 10, 2006 7:17 AM > To: Drage, Keith (Keith) > Cc: Sanjay Sinha (sanjsinh); 'Aki Niemi';=20 > 'dean.willis@softarmor.com'; 'sip@ietf.org'; Paul Kyzivat=20 > (pkyzivat); 'kristoffer.gronowski@ericsson.com' > Subject: Re: [Sip] PUBLISH and PAI/PPI >=20 > The problem with the tables is that they assume an easily=20 > enumerable and consistent approach across documents of=20 > defining what methods a request go in. The problem is, it=20 > sometimes depends on other factors.=20 > Content-Type for example reuqires a special value in the=20 > table in 3261 to indicate why it needs to be there. >=20 > Another problem is that you need to worry about consistency=20 > of the tables with normative text that appears elsewhere in=20 > the document about where the headers are used. >=20 > And, of course, the problem that the tables become incomplete=20 > as new methods and headers get added in other specifications. >=20 > The main benefit of the tables is, in principal, to provide=20 > clear guidance on construction of requests and responses. The=20 > tables force you to think about applicability of extensions.=20 > Another way to do that is to simply require that=20 > specifications of new methods include text that clearly=20 > discusses, using normative terms, applicability of various=20 > headers, and furthermore, for new header specs, defines=20 > applicability to methods. >=20 > -Jonathan R. >=20 > Drage, Keith (Keith) wrote: >=20 > > I have suggested in the past that rather than putting=20 > method names in=20 > > this table, we would be better off using columns like=20 > "method outside=20 > > dialog", "method used within an existing dialog", "method used to=20 > > initiate a dialog", "target refresh request". > >=20 > > However any such suggestion always seems to get lost in noise from=20 > > Jonathan about how these tables cannot be relied upon,=20 > therefore it is=20 > > not worth maintaining them. > >=20 > > regards > >=20 > > Keith > >=20 > >=20 > >> -----Original Message----- From: sip-bounces@ietf.org=20 > >> [mailto:sip-bounces@ietf.org]On Behalf Of Paul Kyzivat Sent: 09=20 > >> February 2006 16:28 To: Aki Niemi Cc: Sanjay Sinha (sanjsinh);=20 > >> sip@ietf.org; kristoffer.gronowski@ericsson.com; > >> dean.willis@softarmor.com Subject: Re: [Sip] PUBLISH and PAI/PPI > >>=20 > >>=20 > >> While the existing tables are a mess, I think there is=20 > considerable =20 > >> value in having a well defined way to determine where things are=20 > >> allowed to be used. It should be possible to come up with a formal=20 > >> way to say things like: "H can be used in any method", or=20 > "H may only=20 > >> be used in methods X,Y,Z". Then this formalized language can be=20 > >> included in the IANA header registry. From it, anyone=20 > could construct=20 > >> their own table. > >>=20 > >> Paul > >>=20 > >> Aki Niemi wrote: > >>=20 > >>> Hi Michael, > >>>=20 > >>> ext Michael Hammer (mhammer) wrote: > >>>=20 > >>>=20 > >>>> Are you suggesting that such tables should no longer be > >>=20 > >> embedded in each > >>=20 > >>>> RFC? > >>>=20 > >>>=20 > >>> Yes; I'm suggesting we quit copy-pasting and augmenting > >>=20 > >> tables 2 and 3 > >>=20 > >>> of RFC 3261. It will simply never produce tables that are > >>=20 > >> complete. It > >>=20 > >>> will only produce questions like the one that started the thread. > >>>=20 > >>>=20 > >>>=20 > >>>> Or, are you suggesting it would be better to have an > >>=20 > >> uber-table IANA > >>=20 > >>>> registry that can be updated every time we discover a new > >>=20 > >> header-method > >>=20 > >>>> usage mapping. > >>>=20 > >>>=20 > >>> No, I'm not proposing any new registry. > >>>=20 > >>> Instead of saying that header field H is "o" (as in=20 > optional) for =20 > >>> methods X, Y, and Z, we could simply say that H can be=20 > used in any=20 > >>> method. Then again for header fields like Refer-To, it should be=20 > >>> sufficient to say that it is only allowed in REFER, instead > >>=20 > >> of marking > >>=20 > >>> it as "-" (as in not applicable) for every known method > >>=20 > >> there is at the > >>=20 > >>> time of writing. > >>>=20 > >>> PAI is a good example of a header field whose entire reason for=20 > >>> existance is that it can indicate the asserted identity of > >>=20 > >> the sender of > >>=20 > >>> any method. So it really makes no sense to specifically > >>=20 > >> create a "usage" > >>=20 > >>> of PAI with, say, PUBLISH. > >>>=20 > >>> Then again, SIP-ETag is another good example of a header > >>=20 > >> field that will > >>=20 > >>> be meaningless in a method, unless it is specifically=20 > written down=20 > >>> somewhere what it means there. > >>>=20 > >>>=20 > >>>> But, that may require an uber-table RFC on which that IANA > >>=20 > >> registry is > >>=20 > >>>> based. > >>>=20 > >>>=20 > >>> I'm also not suggesting anything like that. I'm suggesting > >>=20 > >> we forget > >>=20 > >>> about tables altogether. > >>>=20 > >>> Cheers, Aki > >>>=20 > >>> _______________________________________________ Sip mailing list=20 > >>> https://www1.ietf.org/mailman/listinfo/sip This list is for NEW=20 > >>> development of the core SIP Protocol Use=20 > >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>> sipping@ietf.org for new developments on the application of sip > >>>=20 > >>=20 > >> _______________________________________________ Sip mailing list=20 > >> https://www1.ietf.org/mailman/listinfo/sip This list is for NEW=20 > >> development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >>=20 > >=20 > >=20 > > _______________________________________________ Sip mailing list=20 > > https://www1.ietf.org/mailman/listinfo/sip This list is for NEW=20 > > development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > 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 sip-bounces@ietf.org Fri Feb 10 10:59:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7afu-0001fP-Gu; Fri, 10 Feb 2006 10:59:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7afo-0001eb-Av for sip@megatron.ietf.org; Fri, 10 Feb 2006 10:59:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01343 for ; Fri, 10 Feb 2006 10:57:12 -0500 (EST) Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7asf-0005rc-BN for sip@ietf.org; Fri, 10 Feb 2006 11:12:24 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k1AFwWlp013594; Fri, 10 Feb 2006 10:58:36 -0500 (EST) From: "Brett Tate" To: "'Markus Hofmann'" Subject: RE: [Sip] stateless forwarding UDP->TCP by proxy Date: Fri, 10 Feb 2006 10:59:23 -0500 Message-ID: <000601c62e5a$f9391580$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <43EC3FBC.1010909@nero.com> X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > Which I do not understand if a UAC decides to send its=20 > request through UDP and gets back a TCP response is=20 > this not a source of trouble because in the Via header=20 > stands UDP as transport kind. The client will expect=20 > on its UDP port the response. Responses currently must use the same transport used within the request. And I was not attempting to address this topic. > The next point is: Why should only non-successful response=20 > have problems with the packet size?=20 The 1xx and 2xx responses are retried when necessary per rfc3261 and rfc3262. However the periodic retrying of 3xx-6xx has been removed by rfc3261. > If the answer is 3xx - 6xx no route set will be=20 > set and every proxy will remove its Via header which=20 > make the size smaller. Is there really a reason to=20 > switch to TCP? Responses must use the same transport used within the request. This was = not the topic of the thread. =20 However to answer your question, responses can be larger than a request because of the potential for extra headers, extra parameters, and a body within such responses. > 2xx responses have a Contact header where you have the=20 > possibility to signal that you will switch from UDP to=20 > TCP. But the UAC could be first prepared to use TCP if=20 > it evaluates the successful response. I'm not sure that I understand your comment; responses must use the same transport used within the request. However since rfc3261 and rfc3262 provides for retrying 1xx and 2xx responses, there is no issue when the used transport was reliable and = the subsequent transport for PRACK or ACK is non reliable. > Did I understand everything right? I was trying to communicate that the mentioned problem concerning = stateless proxies was not unique to situations related to message size.=20 The problem can surface anytime a stateless proxy receives an INVITE non reliably and proxies it over a reliable transport. In the following example, the 486 and ACK only get sent once over UDP. A P B INVITE (udp) -> INVITE (tcp) -> <- 100 (udp) <- 100 (tcp) <- 486 (udp) <- 486 (tcp) ACK (udp) -> ACK (tcp) -> _______________________________________________ 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 sip-bounces@ietf.org Fri Feb 10 11:20:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7b0Q-00009N-SO; Fri, 10 Feb 2006 11:20:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7b0J-000084-Fx for sip@megatron.ietf.org; Fri, 10 Feb 2006 11:20:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAB04483 for ; Fri, 10 Feb 2006 11:18:23 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7bDB-0007Bi-4g for sip@ietf.org; Fri, 10 Feb 2006 11:33:35 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 10 Feb 2006 08:19:57 -0800 X-IronPort-AV: i="4.02,103,1139212800"; d="scan'208"; a="1775281013:sNHT37036996" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k1AGJfc7022117; Fri, 10 Feb 2006 08:19:54 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Feb 2006 11:19:54 -0500 Received: from [161.44.79.51] ([161.44.79.51]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Feb 2006 11:19:53 -0500 Message-ID: <43ECBD29.5070909@cisco.com> Date: Fri, 10 Feb 2006 11:19:53 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Sip] PUBLISH and PAI/PPI References: <072C5B76F7CEAB488172C6F64B30B5E30115C47C@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E30115C47C@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Feb 2006 16:19:53.0609 (UTC) FILETIME=[D3280790:01C62E5D] X-Spam-Score: 0.0 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Content-Transfer-Encoding: 7bit Cc: "Sanjay Sinha \(sanjsinh\)" , Aki Niemi , dean.willis@softarmor.com, sip@ietf.org, "Drage, Keith \(Keith\)" , kristoffer.gronowski@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Michael Hammer (mhammer) wrote: > Jonathan, > > Re: incompleteness. > > If an RFC defining a new header addresses all known methods, and > if an RFC defining a new method addresses all known headers, then > the table should never be incomplete. In theory that would cover it. But in practice it would introduce dependencies that would serialize the progression to rfc of all drafts that define headers or methods. That cure seems worse than the disease. > The question is what should an RFC author define for headers/methods > that were not the main focus of their draft? > > Say it is undefined? Say it is optional? Say it is disallowed? I think all of these are possibilities. > It seems the latter choice is what trips us up. Yeah, that is the ugly case. > I guess this is an extensibility process question. > > Mike > > > >>-----Original Message----- >>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >>Behalf Of Jonathan Rosenberg (jdrosen) >>Sent: Friday, February 10, 2006 7:17 AM >>To: Drage, Keith (Keith) >>Cc: Sanjay Sinha (sanjsinh); 'Aki Niemi'; >>'dean.willis@softarmor.com'; 'sip@ietf.org'; Paul Kyzivat >>(pkyzivat); 'kristoffer.gronowski@ericsson.com' >>Subject: Re: [Sip] PUBLISH and PAI/PPI >> >>The problem with the tables is that they assume an easily >>enumerable and consistent approach across documents of >>defining what methods a request go in. The problem is, it >>sometimes depends on other factors. >>Content-Type for example reuqires a special value in the >>table in 3261 to indicate why it needs to be there. >> >>Another problem is that you need to worry about consistency >>of the tables with normative text that appears elsewhere in >>the document about where the headers are used. >> >>And, of course, the problem that the tables become incomplete >>as new methods and headers get added in other specifications. >> >>The main benefit of the tables is, in principal, to provide >>clear guidance on construction of requests and responses. The >>tables force you to think about applicability of extensions. >>Another way to do that is to simply require that >>specifications of new methods include text that clearly >>discusses, using normative terms, applicability of various >>headers, and furthermore, for new header specs, defines >>applicability to methods. >> >>-Jonathan R. >> >>Drage, Keith (Keith) wrote: >> >> >>>I have suggested in the past that rather than putting >> >>method names in >> >>>this table, we would be better off using columns like >> >>"method outside >> >>>dialog", "method used within an existing dialog", "method used to >>>initiate a dialog", "target refresh request". >>> >>>However any such suggestion always seems to get lost in noise from >>>Jonathan about how these tables cannot be relied upon, >> >>therefore it is >> >>>not worth maintaining them. >>> >>>regards >>> >>>Keith >>> >>> >>> >>>>-----Original Message----- From: sip-bounces@ietf.org >>>>[mailto:sip-bounces@ietf.org]On Behalf Of Paul Kyzivat Sent: 09 >>>>February 2006 16:28 To: Aki Niemi Cc: Sanjay Sinha (sanjsinh); >>>>sip@ietf.org; kristoffer.gronowski@ericsson.com; >>>>dean.willis@softarmor.com Subject: Re: [Sip] PUBLISH and PAI/PPI >>>> >>>> >>>>While the existing tables are a mess, I think there is >> >>considerable >> >>>>value in having a well defined way to determine where things are >>>>allowed to be used. It should be possible to come up with a formal >>>>way to say things like: "H can be used in any method", or >> >>"H may only >> >>>>be used in methods X,Y,Z". Then this formalized language can be >>>>included in the IANA header registry. From it, anyone >> >>could construct >> >>>>their own table. >>>> >>>>Paul >>>> >>>>Aki Niemi wrote: >>>> >>>> >>>>>Hi Michael, >>>>> >>>>>ext Michael Hammer (mhammer) wrote: >>>>> >>>>> >>>>> >>>>>>Are you suggesting that such tables should no longer be >>>> >>>>embedded in each >>>> >>>> >>>>>>RFC? >>>>> >>>>> >>>>>Yes; I'm suggesting we quit copy-pasting and augmenting >>>> >>>>tables 2 and 3 >>>> >>>> >>>>>of RFC 3261. It will simply never produce tables that are >>>> >>>>complete. It >>>> >>>> >>>>>will only produce questions like the one that started the thread. >>>>> >>>>> >>>>> >>>>> >>>>>>Or, are you suggesting it would be better to have an >>>> >>>>uber-table IANA >>>> >>>> >>>>>>registry that can be updated every time we discover a new >>>> >>>>header-method >>>> >>>> >>>>>>usage mapping. >>>>> >>>>> >>>>>No, I'm not proposing any new registry. >>>>> >>>>>Instead of saying that header field H is "o" (as in >> >>optional) for >> >>>>>methods X, Y, and Z, we could simply say that H can be >> >>used in any >> >>>>>method. Then again for header fields like Refer-To, it should be >>>>>sufficient to say that it is only allowed in REFER, instead >>>> >>>>of marking >>>> >>>> >>>>>it as "-" (as in not applicable) for every known method >>>> >>>>there is at the >>>> >>>> >>>>>time of writing. >>>>> >>>>>PAI is a good example of a header field whose entire reason for >>>>>existance is that it can indicate the asserted identity of >>>> >>>>the sender of >>>> >>>> >>>>>any method. So it really makes no sense to specifically >>>> >>>>create a "usage" >>>> >>>> >>>>>of PAI with, say, PUBLISH. >>>>> >>>>>Then again, SIP-ETag is another good example of a header >>>> >>>>field that will >>>> >>>> >>>>>be meaningless in a method, unless it is specifically >> >>written down >> >>>>>somewhere what it means there. >>>>> >>>>> >>>>> >>>>>>But, that may require an uber-table RFC on which that IANA >>>> >>>>registry is >>>> >>>> >>>>>>based. >>>>> >>>>> >>>>>I'm also not suggesting anything like that. I'm suggesting >>>> >>>>we forget >>>> >>>> >>>>>about tables altogether. >>>>> >>>>>Cheers, Aki >>>>> >>>>>_______________________________________________ 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 >>> >> >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Cisco Fellow Parsippany, NJ >>07054-2711 >>Cisco Systems >>jdrosen@cisco.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.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 >> > > _______________________________________________ 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 sip-bounces@ietf.org Fri Feb 10 14:46:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7eE9-0006dD-Sa; Fri, 10 Feb 2006 14:46:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7eE1-0006br-Ux for sip@megatron.ietf.org; Fri, 10 Feb 2006 14:46:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22548 for ; Fri, 10 Feb 2006 14:44:47 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7eQx-0005m9-Pp for sip@ietf.org; Fri, 10 Feb 2006 15:00:00 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 10 Feb 2006 11:46:20 -0800 X-IronPort-AV: i="4.02,103,1139212800"; d="scan'208"; a="1775359934:sNHT37069662" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k1AJkIc1012807; Fri, 10 Feb 2006 11:46:18 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Feb 2006 11:46:18 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.83.15]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Feb 2006 11:46:17 -0800 Message-Id: <4.3.2.7.2.20060210134307.0352e6d0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 10 Feb 2006 13:46:15 -0600 To: Jonathan Rosenberg , "Drage, Keith (Keith)" From: "James M. Polk" Subject: Re: [Sip] PUBLISH and PAI/PPI In-Reply-To: <43EC8439.2010600@cisco.com> References: <475FF955A05DD411980D00508B6D5FB01205F721@en0033exch001u.uk.lucent.com> <475FF955A05DD411980D00508B6D5FB01205F721@en0033exch001u.uk.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 10 Feb 2006 19:46:18.0023 (UTC) FILETIME=[A8D7A370:01C62E7A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: "'Sanjay Sinha \(sanjsinh\)'" , 'Aki Niemi' , "'dean.willis@softarmor.com'" , "'sip@ietf.org'" , 'Paul Kyzivat' , "'kristoffer.gronowski@ericsson.com'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At 07:16 AM 2/10/2006 -0500, Jonathan Rosenberg wrote: >Another way to do that is to simply require that specifications of new >methods include text that clearly discusses, using normative terms, >applicability of various headers, and furthermore, for new header specs, >defines applicability to methods. bingo! ... and someone(s), say the WG or the WG chairs, ought to ensure this text is in each ID prior to passing WGLC. But this is just my opinion... and I'm always wrong wrt SIP ;-) >-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 sip-bounces@ietf.org Fri Feb 10 15:00:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7eR6-0002Ef-0A; Fri, 10 Feb 2006 15:00:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7eR0-0002C2-ME for sip@megatron.ietf.org; Fri, 10 Feb 2006 15:00:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23465 for ; Fri, 10 Feb 2006 14:58:11 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7edu-0006FM-3l for sip@ietf.org; Fri, 10 Feb 2006 15:13:24 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 10 Feb 2006 11:59:42 -0800 X-IronPort-AV: i="4.02,103,1139212800"; d="scan'208"; a="403524710:sNHT36604060" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1AJxRKb024058; Fri, 10 Feb 2006 11:59:38 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Feb 2006 11:59:36 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.83.15]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Feb 2006 11:59:36 -0800 Message-Id: <4.3.2.7.2.20060210134637.03061ef8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 10 Feb 2006 13:59:34 -0600 To: "Michael Hammer \(mhammer\)" , "Jonathan Rosenberg \(jdrosen\)" , "Drage, Keith \(Keith\)" From: "James M. Polk" Subject: RE: [Sip] PUBLISH and PAI/PPI In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E30115C47C@xmb-rtp-20b.amer. cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 10 Feb 2006 19:59:36.0132 (UTC) FILETIME=[848D6840:01C62E7C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Cc: "Sanjay Sinha \(sanjsinh\)" , Aki Niemi , dean.willis@softarmor.com, sip@ietf.org, "Paul Kyzivat \(pkyzivat\)" , kristoffer.gronowski@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Mike When was the last Method defined? (hint: PUBLISH in RFC 3903) What year? (Oct 2004) When was the Method before that defined (hint: REFER)? What year? (April 2003) Will we have one in the next 2 years? Will we have two in the next 4 years? We do *not* define several Methods per year. We aren't even at 1 new Method a year. We do define new Headers every once in a while, but only a couple a year. This race condition you talk of isn't going to be that overlapping IMO. I think we're past that scenario - which was present between 3261 and 3515 At 09:39 AM 2/10/2006 -0500, Michael Hammer \(mhammer\) wrote: >Jonathan, > >Re: incompleteness. > >If an RFC defining a new header addresses all known methods, and >if an RFC defining a new method addresses all known headers, then >the table should never be incomplete. > >The question is what should an RFC author define for headers/methods >that were not the main focus of their draft? > >Say it is undefined? Say it is optional? Say it is disallowed? > >It seems the latter choice is what trips us up. >I guess this is an extensibility process question. > >Mike > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of Jonathan Rosenberg (jdrosen) > > Sent: Friday, February 10, 2006 7:17 AM > > To: Drage, Keith (Keith) > > Cc: Sanjay Sinha (sanjsinh); 'Aki Niemi'; > > 'dean.willis@softarmor.com'; 'sip@ietf.org'; Paul Kyzivat > > (pkyzivat); 'kristoffer.gronowski@ericsson.com' > > Subject: Re: [Sip] PUBLISH and PAI/PPI > > > > The problem with the tables is that they assume an easily > > enumerable and consistent approach across documents of > > defining what methods a request go in. The problem is, it > > sometimes depends on other factors. > > Content-Type for example reuqires a special value in the > > table in 3261 to indicate why it needs to be there. > > > > Another problem is that you need to worry about consistency > > of the tables with normative text that appears elsewhere in > > the document about where the headers are used. > > > > And, of course, the problem that the tables become incomplete > > as new methods and headers get added in other specifications. > > > > The main benefit of the tables is, in principal, to provide > > clear guidance on construction of requests and responses. The > > tables force you to think about applicability of extensions. > > Another way to do that is to simply require that > > specifications of new methods include text that clearly > > discusses, using normative terms, applicability of various > > headers, and furthermore, for new header specs, defines > > applicability to methods. > > > > -Jonathan R. > > > > Drage, Keith (Keith) wrote: > > > > > I have suggested in the past that rather than putting > > method names in > > > this table, we would be better off using columns like > > "method outside > > > dialog", "method used within an existing dialog", "method used to > > > initiate a dialog", "target refresh request". > > > > > > However any such suggestion always seems to get lost in noise from > > > Jonathan about how these tables cannot be relied upon, > > therefore it is > > > not worth maintaining them. > > > > > > regards > > > > > > Keith > > > > > > > > >> -----Original Message----- From: sip-bounces@ietf.org > > >> [mailto:sip-bounces@ietf.org]On Behalf Of Paul Kyzivat Sent: 09 > > >> February 2006 16:28 To: Aki Niemi Cc: Sanjay Sinha (sanjsinh); > > >> sip@ietf.org; kristoffer.gronowski@ericsson.com; > > >> dean.willis@softarmor.com Subject: Re: [Sip] PUBLISH and PAI/PPI > > >> > > >> > > >> While the existing tables are a mess, I think there is > > considerable > > >> value in having a well defined way to determine where things are > > >> allowed to be used. It should be possible to come up with a formal > > >> way to say things like: "H can be used in any method", or > > "H may only > > >> be used in methods X,Y,Z". Then this formalized language can be > > >> included in the IANA header registry. From it, anyone > > could construct > > >> their own table. > > >> > > >> Paul > > >> > > >> Aki Niemi wrote: > > >> > > >>> Hi Michael, > > >>> > > >>> ext Michael Hammer (mhammer) wrote: > > >>> > > >>> > > >>>> Are you suggesting that such tables should no longer be > > >> > > >> embedded in each > > >> > > >>>> RFC? > > >>> > > >>> > > >>> Yes; I'm suggesting we quit copy-pasting and augmenting > > >> > > >> tables 2 and 3 > > >> > > >>> of RFC 3261. It will simply never produce tables that are > > >> > > >> complete. It > > >> > > >>> will only produce questions like the one that started the thread. > > >>> > > >>> > > >>> > > >>>> Or, are you suggesting it would be better to have an > > >> > > >> uber-table IANA > > >> > > >>>> registry that can be updated every time we discover a new > > >> > > >> header-method > > >> > > >>>> usage mapping. > > >>> > > >>> > > >>> No, I'm not proposing any new registry. > > >>> > > >>> Instead of saying that header field H is "o" (as in > > optional) for > > >>> methods X, Y, and Z, we could simply say that H can be > > used in any > > >>> method. Then again for header fields like Refer-To, it should be > > >>> sufficient to say that it is only allowed in REFER, instead > > >> > > >> of marking > > >> > > >>> it as "-" (as in not applicable) for every known method > > >> > > >> there is at the > > >> > > >>> time of writing. > > >>> > > >>> PAI is a good example of a header field whose entire reason for > > >>> existance is that it can indicate the asserted identity of > > >> > > >> the sender of > > >> > > >>> any method. So it really makes no sense to specifically > > >> > > >> create a "usage" > > >> > > >>> of PAI with, say, PUBLISH. > > >>> > > >>> Then again, SIP-ETag is another good example of a header > > >> > > >> field that will > > >> > > >>> be meaningless in a method, unless it is specifically > > written down > > >>> somewhere what it means there. > > >>> > > >>> > > >>>> But, that may require an uber-table RFC on which that IANA > > >> > > >> registry is > > >> > > >>>> based. > > >>> > > >>> > > >>> I'm also not suggesting anything like that. I'm suggesting > > >> > > >> we forget > > >> > > >>> about tables altogether. > > >>> > > >>> Cheers, Aki > > >>> > > >>> _______________________________________________ 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 > > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ > > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.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 > > > >_______________________________________________ >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 sip-bounces@ietf.org Fri Feb 10 18:28:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7hgb-00050x-D8; Fri, 10 Feb 2006 18:28:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7hgT-0004yt-D7 for sip@megatron.ietf.org; Fri, 10 Feb 2006 18:28:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12700 for ; Fri, 10 Feb 2006 18:26:21 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7htQ-0006Cl-V6 for sip@ietf.org; Fri, 10 Feb 2006 18:41:37 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 10 Feb 2006 15:27:56 -0800 X-IronPort-AV: i="4.02,104,1139212800"; d="scan'208"; a="254889805:sNHT38679648" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1ANRsjv003411; Fri, 10 Feb 2006 15:27:55 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Feb 2006 15:27:54 -0800 Received: from [10.224.143.164] ([10.89.16.80]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Feb 2006 15:27:53 -0800 Message-ID: <43ED2177.6040406@cisco.com> Date: Fri, 10 Feb 2006 18:27:51 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Sip] PUBLISH and PAI/PPI References: <4.3.2.7.2.20060210134637.03061ef8@email.cisco.com> In-Reply-To: <4.3.2.7.2.20060210134637.03061ef8@email.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Feb 2006 23:27:54.0082 (UTC) FILETIME=[9DE93C20:01C62E99] X-Spam-Score: 0.0 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Content-Transfer-Encoding: 7bit Cc: "Sanjay Sinha \(sanjsinh\)" , Aki Niemi , dean.willis@softarmor.com, sip@ietf.org, "Paul Kyzivat \(pkyzivat\)" , "Drage, Keith \(Keith\)" , kristoffer.gronowski@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Well, we all know that we have few new headers since INFO or MESSAGE appear to do the job for everything ;) I'll take this opportunity to remind folks of an old draft I wrote on that topic: http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt -Jonathan R. James M. Polk wrote: > Mike > > When was the last Method defined? (hint: PUBLISH in RFC 3903) What year? > (Oct 2004) > > When was the Method before that defined (hint: REFER)? What year? (April > 2003) > > Will we have one in the next 2 years? > > Will we have two in the next 4 years? > > We do *not* define several Methods per year. > > We aren't even at 1 new Method a year. > > We do define new Headers every once in a while, but only a couple a > year. This race condition you talk of isn't going to be that > overlapping IMO. I think we're past that scenario - which was present > between 3261 and 3515 > > At 09:39 AM 2/10/2006 -0500, Michael Hammer \(mhammer\) wrote: > >> Jonathan, >> >> Re: incompleteness. >> >> If an RFC defining a new header addresses all known methods, and >> if an RFC defining a new method addresses all known headers, then >> the table should never be incomplete. >> >> The question is what should an RFC author define for headers/methods >> that were not the main focus of their draft? >> >> Say it is undefined? Say it is optional? Say it is disallowed? >> >> It seems the latter choice is what trips us up. >> I guess this is an extensibility process question. >> >> Mike >> >> >> > -----Original Message----- >> > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >> > Behalf Of Jonathan Rosenberg (jdrosen) >> > Sent: Friday, February 10, 2006 7:17 AM >> > To: Drage, Keith (Keith) >> > Cc: Sanjay Sinha (sanjsinh); 'Aki Niemi'; >> > 'dean.willis@softarmor.com'; 'sip@ietf.org'; Paul Kyzivat >> > (pkyzivat); 'kristoffer.gronowski@ericsson.com' >> > Subject: Re: [Sip] PUBLISH and PAI/PPI >> > >> > The problem with the tables is that they assume an easily >> > enumerable and consistent approach across documents of >> > defining what methods a request go in. The problem is, it >> > sometimes depends on other factors. >> > Content-Type for example reuqires a special value in the >> > table in 3261 to indicate why it needs to be there. >> > >> > Another problem is that you need to worry about consistency >> > of the tables with normative text that appears elsewhere in >> > the document about where the headers are used. >> > >> > And, of course, the problem that the tables become incomplete >> > as new methods and headers get added in other specifications. >> > >> > The main benefit of the tables is, in principal, to provide >> > clear guidance on construction of requests and responses. The >> > tables force you to think about applicability of extensions. >> > Another way to do that is to simply require that >> > specifications of new methods include text that clearly >> > discusses, using normative terms, applicability of various >> > headers, and furthermore, for new header specs, defines >> > applicability to methods. >> > >> > -Jonathan R. >> > >> > Drage, Keith (Keith) wrote: >> > >> > > I have suggested in the past that rather than putting >> > method names in >> > > this table, we would be better off using columns like >> > "method outside >> > > dialog", "method used within an existing dialog", "method used to >> > > initiate a dialog", "target refresh request". >> > > >> > > However any such suggestion always seems to get lost in noise from >> > > Jonathan about how these tables cannot be relied upon, >> > therefore it is >> > > not worth maintaining them. >> > > >> > > regards >> > > >> > > Keith >> > > >> > > >> > >> -----Original Message----- From: sip-bounces@ietf.org >> > >> [mailto:sip-bounces@ietf.org]On Behalf Of Paul Kyzivat Sent: 09 >> > >> February 2006 16:28 To: Aki Niemi Cc: Sanjay Sinha (sanjsinh); >> > >> sip@ietf.org; kristoffer.gronowski@ericsson.com; >> > >> dean.willis@softarmor.com Subject: Re: [Sip] PUBLISH and PAI/PPI >> > >> >> > >> >> > >> While the existing tables are a mess, I think there is >> > considerable >> > >> value in having a well defined way to determine where things are >> > >> allowed to be used. It should be possible to come up with a formal >> > >> way to say things like: "H can be used in any method", or >> > "H may only >> > >> be used in methods X,Y,Z". Then this formalized language can be >> > >> included in the IANA header registry. From it, anyone >> > could construct >> > >> their own table. >> > >> >> > >> Paul >> > >> >> > >> Aki Niemi wrote: >> > >> >> > >>> Hi Michael, >> > >>> >> > >>> ext Michael Hammer (mhammer) wrote: >> > >>> >> > >>> >> > >>>> Are you suggesting that such tables should no longer be >> > >> >> > >> embedded in each >> > >> >> > >>>> RFC? >> > >>> >> > >>> >> > >>> Yes; I'm suggesting we quit copy-pasting and augmenting >> > >> >> > >> tables 2 and 3 >> > >> >> > >>> of RFC 3261. It will simply never produce tables that are >> > >> >> > >> complete. It >> > >> >> > >>> will only produce questions like the one that started the thread. >> > >>> >> > >>> >> > >>> >> > >>>> Or, are you suggesting it would be better to have an >> > >> >> > >> uber-table IANA >> > >> >> > >>>> registry that can be updated every time we discover a new >> > >> >> > >> header-method >> > >> >> > >>>> usage mapping. >> > >>> >> > >>> >> > >>> No, I'm not proposing any new registry. >> > >>> >> > >>> Instead of saying that header field H is "o" (as in >> > optional) for >> > >>> methods X, Y, and Z, we could simply say that H can be >> > used in any >> > >>> method. Then again for header fields like Refer-To, it should be >> > >>> sufficient to say that it is only allowed in REFER, instead >> > >> >> > >> of marking >> > >> >> > >>> it as "-" (as in not applicable) for every known method >> > >> >> > >> there is at the >> > >> >> > >>> time of writing. >> > >>> >> > >>> PAI is a good example of a header field whose entire reason for >> > >>> existance is that it can indicate the asserted identity of >> > >> >> > >> the sender of >> > >> >> > >>> any method. So it really makes no sense to specifically >> > >> >> > >> create a "usage" >> > >> >> > >>> of PAI with, say, PUBLISH. >> > >>> >> > >>> Then again, SIP-ETag is another good example of a header >> > >> >> > >> field that will >> > >> >> > >>> be meaningless in a method, unless it is specifically >> > written down >> > >>> somewhere what it means there. >> > >>> >> > >>> >> > >>>> But, that may require an uber-table RFC on which that IANA >> > >> >> > >> registry is >> > >> >> > >>>> based. >> > >>> >> > >>> >> > >>> I'm also not suggesting anything like that. I'm suggesting >> > >> >> > >> we forget >> > >> >> > >>> about tables altogether. >> > >>> >> > >>> Cheers, Aki >> > >>> >> > >>> _______________________________________________ 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 >> > > >> > >> > -- >> > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> > Cisco Fellow Parsippany, NJ >> > 07054-2711 >> > Cisco Systems >> > jdrosen@cisco.com FAX: (973) 952-5050 >> > http://www.jdrosen.net PHONE: (973) 952-5000 >> > http://www.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 >> > >> >> _______________________________________________ >> 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 Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.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 sip-bounces@ietf.org Sun Feb 12 18:34:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8QjX-0000uW-Kc; Sun, 12 Feb 2006 18:34:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8QjV-0000uR-Sk for sip@megatron.ietf.org; Sun, 12 Feb 2006 18:34:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23767 for ; Sun, 12 Feb 2006 18:32:36 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8Qx0-0001pL-4H for sip@ietf.org; Sun, 12 Feb 2006 18:48:19 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 12 Feb 2006 15:34:12 -0800 X-IronPort-AV: i="4.02,105,1139212800"; d="scan'208"; a="255018723:sNHT27986732" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k1CNYBc1002661 for ; Sun, 12 Feb 2006 15:34:11 -0800 (PST) Received: from 10.21.144.181 ([10.21.144.181]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sun, 12 Feb 2006 23:34:11 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sun, 12 Feb 2006 15:34:31 -0800 From: Cullen Jennings To: "sip@ietf.org" Message-ID: Thread-Topic: Outbound and STUN Keep Alive Thread-Index: AcYwLN9RHd1qNZwgEdqprQARJEEJ/A== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Subject: [Sip] Outbound and STUN Keep Alive X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org There has been a few threads about keep alives in outbound.... I will start a thread here. For UDP, I think STUN is clearly the best choice. It's the only thing that is quick and works when the NAT reboots. For TCP, there is the the option to use STUN the same as UDP. There might be another solution for TCP. I'll call it the Double CRLF. Basically the UA sends a CRLF, when the proxy receives this, it must sends a CRLF within 1 second. If the UA does not get back the CRLF within 6 seconds of sending the first one, it considers the connection dead. First questions is, does Double CRLF work? Second questions is, given we have to do STUN for UDP, would we want to do something different for TCP? _______________________________________________ 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 sip-bounces@ietf.org Mon Feb 13 06:16:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8bgX-00016D-EB; Mon, 13 Feb 2006 06:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8bgV-000165-EW for sip@megatron.ietf.org; Mon, 13 Feb 2006 06:15:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10034 for ; Mon, 13 Feb 2006 06:14:13 -0500 (EST) Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8btt-0004Or-8J for sip@ietf.org; Mon, 13 Feb 2006 06:30:02 -0500 Received: from rly12b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly12b.srv.mailcontrol.com (MailControl) with ESMTP id k1DBFZ2L015338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 13 Feb 2006 11:15:35 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly12b.srv.mailcontrol.com (MailControl) id k1DBEgv6013452 for sip@ietf.org; Mon, 13 Feb 2006 11:14:42 GMT Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly12b-eth0.srv.mailcontrol.com (envelope-sender cboulton@ubiquity.net) (MIMEDefang) with ESMTP id k1DBEfAk013428; Mon, 13 Feb 2006 11:14:42 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Mon, 13 Feb 2006 11:14:41 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE04E78B08@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcYwLN9RHd1qNZwgEdqprQARJEEJ/AAYZU+A From: "Chris Boulton" To: "Cullen Jennings" , X-Scanned-By: MailControl A-06-00-02 (www.mailcontrol.com) on 10.66.1.122 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org First questions is, does Double CRLF work? [Chris Boulton] The fact that you need to ask that questions makes me a little uneasy :-). Second questions is, given we have to do STUN for UDP, would we want to do something different for TCP? [Chris Boulton] If it works for UDP then lets just use it and keep it consistent. _______________________________________________ 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 Information contained in this e-mail and any attachments are intended for t= he use of the addressee only, and may contain confidential information of U= biquity Software Corporation. All unauthorized use, disclosure or distribu= tion is strictly prohibited. If you are not the addressee, please notify t= he sender immediately and destroy all copies of this email. Unless otherwi= se expressly agreed in writing signed by an officer of Ubiquity Software Co= rporation, nothing in this communication shall be deemed to be legally bind= ing. 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 sip-bounces@ietf.org Mon Feb 13 10:24:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8fYW-0003Zd-J1; Mon, 13 Feb 2006 10:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8fYV-0003ZU-Ad for sip@megatron.ietf.org; Mon, 13 Feb 2006 10:23:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29987 for ; Mon, 13 Feb 2006 10:22:14 -0500 (EST) Received: from firewall.objectworld.com ([72.1.207.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8fm4-0003xj-Jx for sip@ietf.org; Mon, 13 Feb 2006 10:38:05 -0500 Received: from photon.objectworld.com (photon.objectworld.com [192.168.1.2]) by firewall.objectworld.com (8.12.11/8.12.11) with ESMTP id k1DFNaVX025196 for ; Mon, 13 Feb 2006 10:23:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Mon, 13 Feb 2006 10:23:35 -0500 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C5062F6F@photon.objectworld.com> Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcYwLN9RHd1qNZwgEdqprQARJEEJ/AAYZU+AAAi2RCA= From: "Michael Slavitch" To: "Chris Boulton" , "Cullen Jennings" , X-Spam-Score: 0.00 () [Tag at 15.00] X-CanItPRO-Stream: outgoing Content-Disposition: inline X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.1.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org It depends on the hardware abstraction layer. In other words: not=0A= always, so probably not enough.=0A= =0A= =20=20=0A= It is amazing what you can accomplish if you do not care who gets the=0A= credit.=20=0A= =20=0A= - Harry S Truman=0A= =0A= -----Original Message-----=0A= From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of=0A= Chris Boulton=0A= Sent: February 13, 2006 6:15 AM=0A= To: Cullen Jennings; sip@ietf.org=0A= Subject: RE: [Sip] Outbound and STUN Keep Alive=0A= =0A= =0A= First questions is, does Double CRLF work?=0A= =0A= [Chris Boulton] The fact that you need to ask that questions makes me a=0A= little uneasy :-).=0A= =0A= Second questions is, given we have to do STUN for UDP, would we want to=0A= do something different for TCP?=0A= =0A= [Chris Boulton] If it works for UDP then lets just use it and keep it=0A= consistent.=0A= =0A= _______________________________________________=0A= Sip mailing list https://www1.ietf.org/mailman/listinfo/sip=0A= This list is for NEW development of the core SIP Protocol Use=0A= sip-implementors@cs.columbia.edu for questions on current sip Use=0A= sipping@ietf.org for new developments on the application of sip=0A= =0A= =0A= Information contained in this e-mail and any attachments are intended=0A= for the use of the addressee only, and may contain confidential=0A= information of Ubiquity Software Corporation. All unauthorized use,=0A= disclosure or distribution is strictly prohibited. If you are not the=0A= addressee, please notify the sender immediately and destroy all copies=0A= of this email. Unless otherwise expressly agreed in writing signed by=0A= an officer of Ubiquity Software Corporation, nothing in this=0A= communication shall be deemed to be legally binding. Thank you.=0A= =0A= =0A= _______________________________________________=0A= Sip mailing list https://www1.ietf.org/mailman/listinfo/sip=0A= This list is for NEW development of the core SIP Protocol Use=0A= sip-implementors@cs.columbia.edu for questions on current sip Use=0A= sipping@ietf.org for new developments on the application of sip=0A= =0A= =0A= --=0A= =0A= =0A= -----------------------------------------------=0D=0A= =0D=0A= This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. =0D=0A= =0D=0A= Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp= .=20=0A= _______________________________________________ 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 sip-bounces@ietf.org Mon Feb 13 10:36:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8fkI-0007rS-UL; Mon, 13 Feb 2006 10:36:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8fkF-0007qy-4q for sip@megatron.ietf.org; Mon, 13 Feb 2006 10:36:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01192 for ; Mon, 13 Feb 2006 10:34:22 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8fxn-0004S3-IP for sip@ietf.org; Mon, 13 Feb 2006 10:50:12 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k1DFZxPs009109; Mon, 13 Feb 2006 09:35:59 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k1DFZxW29637; Mon, 13 Feb 2006 09:35:59 -0600 (CST) Message-ID: <43F0A75E.9030300@lucent.com> Date: Mon, 13 Feb 2006 09:35:58 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] Outbound and STUN Keep Alive References: In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1003301399==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1003301399== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080202040201040307000101" This is a cryptographically signed message in MIME format. --------------ms080202040201040307000101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > There has been a few threads about keep alives in outbound.... I will > start a thread here. > > For UDP, I think STUN is clearly the best choice. It's the only thing > that is quick and works when the NAT reboots. > > For TCP, there is the the option to use STUN the same as UDP. > > There might be another solution for TCP. I'll call it the Double > CRLF. Basically the UA sends a CRLF, when the proxy receives this, it > must sends a CRLF within 1 second. If the UA does not get back the > CRLF within 6 seconds of sending the first one, it considers the > connection dead. > > First questions is, does Double CRLF work? Cullen: The purpose of the CRLF is to keep the NAT binding alive by having the NAT periodically see traffic traversing through it, yes? If so, the binding is kept alive by the CRLF going from the UA->Proxy. I am not sure what the CRLF from Proxy->UA accomplishes. Furthermore, existing proxies may ignore incoming CRLF, but they certainly do not generate one in the upstream direction when they get a CRLF... Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) --------------ms080202040201040307000101 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAyMTMxNTM1NThaMCMGCSqGSIb3DQEJ BDEWBBSRr4kdiYfwtyDP8aD6ZRM3YsPGpjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGAaTAqJ0r1zplwyqVr65msFPxOdYMJYm/FawullZxfWoIqU8VYA6cs qhdUGA3kwFWkCKMlHg8ChdVL0AV5tkEGIz9UjKN4Q32695JAZMWXpWNpNb+nF2vd+acdvKED 9FvFx8Vtn1S7heFHs2DMLhbE09e47JfnXS0eaYPtbh5cIMUAAAAAAAA= --------------ms080202040201040307000101-- --===============1003301399== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1003301399==-- From sip-bounces@ietf.org Mon Feb 13 11:11:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8gIs-0003Ff-CY; Mon, 13 Feb 2006 11:11:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8gIq-0003Ef-MQ for sip@megatron.ietf.org; Mon, 13 Feb 2006 11:11:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03710 for ; Mon, 13 Feb 2006 11:10:07 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8gWS-0005Yx-Ig for sip@ietf.org; Mon, 13 Feb 2006 11:25:59 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 13 Feb 2006 11:11:41 -0500 X-IronPort-AV: i="4.02,108,1139202000"; d="scan'208"; a="82286338:sNHT1370955128" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1DGBX6L025439 for ; Mon, 13 Feb 2006 11:11:38 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Feb 2006 11:11:38 -0500 Received: from [192.168.1.101] ([10.86.242.244]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Feb 2006 11:11:37 -0500 Message-ID: <43F0AFB9.60107@cisco.com> Date: Mon, 13 Feb 2006 11:11:37 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] Outbound and STUN Keep Alive References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Feb 2006 16:11:37.0827 (UTC) FILETIME=[2AE2F330:01C630B8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I do think the double CRLF will work. However, the transaction ID in stun makes it easier to correlate requests and responses. After all, whether you choose to call it that or not, the double CR/LF is a transaction, and you are setting times on transaction timeouts here. Thats all easier with a proper transaction. The double CRLF lacks the MAPPED-ADDRESS from stun, which is needed for UDP only. It is needed there to detect nat reboots. If a nat reboots, tcp data transmissions (i.e, the STUN keepalives or CRLF) will be discarded since there is no matching context. But, for UDP, they create a new binding and are passed through. The MAPPED-ADDRESs is needed in UDP to detect this case. That said, there is no benefit to the double CRLF over STUN. Its not backwards compatible in that the server still has to know how to do it. I think having one solution is easier than two. -Jonathan R. Cullen Jennings wrote: > There has been a few threads about keep alives in outbound.... I will start > a thread here. > > For UDP, I think STUN is clearly the best choice. It's the only thing that > is quick and works when the NAT reboots. > > For TCP, there is the the option to use STUN the same as UDP. > > There might be another solution for TCP. I'll call it the Double CRLF. > Basically the UA sends a CRLF, when the proxy receives this, it must sends a > CRLF within 1 second. If the UA does not get back the CRLF within 6 seconds > of sending the first one, it considers the connection dead. > > First questions is, does Double CRLF work? > > Second questions is, given we have to do STUN for UDP, would we want to do > something different for TCP? > > _______________________________________________ > 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 Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.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 sip-bounces@ietf.org Mon Feb 13 12:01:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8h50-0002yh-8e; Mon, 13 Feb 2006 12:01:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8h4y-0002yR-GG for sip@megatron.ietf.org; Mon, 13 Feb 2006 12:01:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07384 for ; Mon, 13 Feb 2006 11:59:50 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8hIb-00079Z-V8 for sip@ietf.org; Mon, 13 Feb 2006 12:15:42 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id A8C5E194477 for ; Mon, 13 Feb 2006 18:01:25 +0100 (CET) Received: from [192.168.1.39] ([192.168.1.39]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Feb 2006 18:00:03 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Mon, 13 Feb 2006 18:01:41 +0100 To: Cullen Jennings X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 13 Feb 2006 17:00:03.0565 (UTC) FILETIME=[EED761D0:01C630BE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The advantages of using STUN for this is that it works for all application layer protocols that need a keepalive mechanism for NAT bindings (thats why I suggested privately to Cullen to move this part of the I-D into a separate draft and submit it in BEHAVE). If we want a SIP specific solution, then I would suggest (well, not entirely my idea. It has been suggested before) a new SIP method that achieves what STUN achieves for those NATs that reboot. Something like NATKEEPALIVE The contact in the 200 OK returns the new external port (and IP address) assigned. The only advantage to this is that we do not use the same port for both SIP and STUN and we avoid having to extend parsers to support that and create a link between SIP parsers and STUN parsers. Regards, Hisham On Feb 13, 2006, at 12:34 AM, Cullen Jennings wrote: > There has been a few threads about keep alives in outbound.... I will > start > a thread here. > > For UDP, I think STUN is clearly the best choice. It's the only thing > that > is quick and works when the NAT reboots. > > For TCP, there is the the option to use STUN the same as UDP. > > There might be another solution for TCP. I'll call it the Double CRLF. > Basically the UA sends a CRLF, when the proxy receives this, it must > sends a > CRLF within 1 second. If the UA does not get back the CRLF within 6 > seconds > of sending the first one, it considers the connection dead. > > First questions is, does Double CRLF work? > > Second questions is, given we have to do STUN for UDP, would we want > to do > something different for TCP? > > _______________________________________________ > 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 sip-bounces@ietf.org Mon Feb 13 12:08:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8hBk-0004Fw-D7; Mon, 13 Feb 2006 12:08:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8hBh-0004FA-VU for sip@megatron.ietf.org; Mon, 13 Feb 2006 12:08:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07987 for ; Mon, 13 Feb 2006 12:06:48 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8hPL-0007QM-DR for sip@ietf.org; Mon, 13 Feb 2006 12:22:40 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 13 Feb 2006 09:08:23 -0800 Received: from tuk-hub-02.redmond.corp.microsoft.com ([157.54.70.28]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Feb 2006 09:08:22 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by tuk-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Feb 2006 09:08:21 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Feb 2006 09:08:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Mon, 13 Feb 2006 09:06:51 -0800 Message-ID: In-Reply-To: Thread-Topic: [Sip] Outbound and STUN Keep Alive thread-index: AcYwLN9RHd1qNZwgEdqprQARJEEJ/AAkvUlA From: "Sean Olson" To: "Cullen Jennings" , X-OriginalArrivalTime: 13 Feb 2006 17:08:21.0653 (UTC) FILETIME=[17B99450:01C630C0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org =20 First questions is, does Double CRLF work? [Sean] Yes, quite well _______________________________________________ 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 sip-bounces@ietf.org Mon Feb 13 16:18:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8kzn-0007Wo-HE; Mon, 13 Feb 2006 16:12:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8kzl-0007Wd-Mf for sip@megatron.ietf.org; Mon, 13 Feb 2006 16:12:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23979 for ; Mon, 13 Feb 2006 16:10:44 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8lDR-0006Bk-5l for sip@ietf.org; Mon, 13 Feb 2006 16:26:38 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 13 Feb 2006 13:12:19 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,109,1139212800"; d="scan'208"; a="21796098:sNHT24159348" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1DLBs6b020113; Mon, 13 Feb 2006 16:12:17 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Feb 2006 16:12:12 -0500 Received: from [192.168.1.101] ([10.86.242.244]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Feb 2006 16:12:11 -0500 Message-ID: <43F0F62B.2080902@cisco.com> Date: Mon, 13 Feb 2006 16:12:11 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hisham Khartabil Subject: Re: [Sip] Outbound and STUN Keep Alive References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Feb 2006 21:12:11.0786 (UTC) FILETIME=[27F6B6A0:01C630E2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The problem is, once you say its a SIP method, you nede to do ALL of the processing associated with any SIP transaction - the parsing, state machinery, authentication, proxy-require checks, max-forward checks, and so on. Given the frequency with which this message comes, you really, really, really want to optimize this. -Jonathan R. Hisham Khartabil wrote: > The advantages of using STUN for this is that it works for all > application layer protocols that need a keepalive mechanism for NAT > bindings (thats why I suggested privately to Cullen to move this part of > the I-D into a separate draft and submit it in BEHAVE). > > If we want a SIP specific solution, then I would suggest (well, not > entirely my idea. It has been suggested before) a new SIP method that > achieves what STUN achieves for those NATs that reboot. Something like > > NATKEEPALIVE > > The contact in the 200 OK returns the new external port (and IP address) > assigned. The only advantage to this is that we do not use the same port > for both SIP and STUN and we avoid having to extend parsers to support > that and create a link between SIP parsers and STUN parsers. > > Regards, > Hisham > > On Feb 13, 2006, at 12:34 AM, Cullen Jennings wrote: > >> There has been a few threads about keep alives in outbound.... I will >> start >> a thread here. >> >> For UDP, I think STUN is clearly the best choice. It's the only thing >> that >> is quick and works when the NAT reboots. >> >> For TCP, there is the the option to use STUN the same as UDP. >> >> There might be another solution for TCP. I'll call it the Double CRLF. >> Basically the UA sends a CRLF, when the proxy receives this, it must >> sends a >> CRLF within 1 second. If the UA does not get back the CRLF within 6 >> seconds >> of sending the first one, it considers the connection dead. >> >> First questions is, does Double CRLF work? >> >> Second questions is, given we have to do STUN for UDP, would we want >> to do >> something different for TCP? >> >> _______________________________________________ >> 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. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.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 sip-bounces@ietf.org Mon Feb 13 18:25:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8n4o-0001jQ-R3; Mon, 13 Feb 2006 18:25:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8n4n-0001jF-D1 for sip@megatron.ietf.org; Mon, 13 Feb 2006 18:25:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01592 for ; Mon, 13 Feb 2006 18:24:03 -0500 (EST) Received: from celine.siteprotect.com ([64.41.122.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8nIQ-0001Ds-Ez for sip@ietf.org; Mon, 13 Feb 2006 18:39:59 -0500 Received: from [192.168.1.4] (pool-70-17-194-54.balt.east.verizon.net [70.17.194.54]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id k1DNPSt19733; Mon, 13 Feb 2006 17:25:28 -0600 Subject: Re: [Sip] Outbound and STUN Keep Alive From: "Frank W. Miller" To: Jonathan Rosenberg In-Reply-To: <43F0F62B.2080902@cisco.com> References: <43F0F62B.2080902@cisco.com> Content-Type: text/plain Organization: Cornfed Systems, LLC Date: Mon, 13 Feb 2006 18:25:25 -0500 Message-Id: <1139873125.2635.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fwmiller@cornfed.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Actually, I would make the opposite argument. Given the frequency with which you are going to do this, you basically don't care how much overhead there is associated with it. If its treated like just another end-to-end NIT, most implementations will have a very simple time adding it. All the machinery to do it is already there. Double CRLF sounds like a hack to me. We all know there are long periods of time in which signaling traffic might not be flowing. We also know that there is at least one very good reason to have periodic signaling traffic occur. I would propose that we just add a PING message to handle that. Maybe I'll even throw together a strawman proposal for it, it should be fairly trivial to do. FM On Mon, 2006-02-13 at 16:12 -0500, Jonathan Rosenberg wrote: > The problem is, once you say its a SIP method, you nede to do ALL of the > processing associated with any SIP transaction - the parsing, state > machinery, authentication, proxy-require checks, max-forward checks, and > so on. Given the frequency with which this message comes, you really, > really, really want to optimize this. > > -Jonathan R. > > Hisham Khartabil wrote: > > > The advantages of using STUN for this is that it works for all > > application layer protocols that need a keepalive mechanism for NAT > > bindings (thats why I suggested privately to Cullen to move this part of > > the I-D into a separate draft and submit it in BEHAVE). > > > > If we want a SIP specific solution, then I would suggest (well, not > > entirely my idea. It has been suggested before) a new SIP method that > > achieves what STUN achieves for those NATs that reboot. Something like > > > > NATKEEPALIVE > > > > The contact in the 200 OK returns the new external port (and IP address) > > assigned. The only advantage to this is that we do not use the same port > > for both SIP and STUN and we avoid having to extend parsers to support > > that and create a link between SIP parsers and STUN parsers. > > > > Regards, > > Hisham > > > > On Feb 13, 2006, at 12:34 AM, Cullen Jennings wrote: > > > >> There has been a few threads about keep alives in outbound.... I will > >> start > >> a thread here. > >> > >> For UDP, I think STUN is clearly the best choice. It's the only thing > >> that > >> is quick and works when the NAT reboots. > >> > >> For TCP, there is the the option to use STUN the same as UDP. > >> > >> There might be another solution for TCP. I'll call it the Double CRLF. > >> Basically the UA sends a CRLF, when the proxy receives this, it must > >> sends a > >> CRLF within 1 second. If the UA does not get back the CRLF within 6 > >> seconds > >> of sending the first one, it considers the connection dead. > >> > >> First questions is, does Double CRLF work? > >> > >> Second questions is, given we have to do STUN for UDP, would we want > >> to do > >> something different for TCP? > >> > >> _______________________________________________ > >> 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 sip-bounces@ietf.org Mon Feb 13 20:30:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8p1n-0000DP-7p; Mon, 13 Feb 2006 20:30:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8p1k-0000CU-IY for sip@megatron.ietf.org; Mon, 13 Feb 2006 20:30:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09059 for ; Mon, 13 Feb 2006 20:29:02 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8pFT-0005YP-GF for sip@ietf.org; Mon, 13 Feb 2006 20:44:59 -0500 Received: from [192.168.2.101] (c-24-1-177-214.hsd1.tx.comcast.net [24.1.177.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1E1Unaw013838 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 13 Feb 2006 19:30:50 -0600 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Mon, 13 Feb 2006 19:31:12 -0600 To: Cullen Jennings X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 12, 2006, at 5:34 PM, Cullen Jennings wrote: > First questions is, does Double CRLF work? > Sortof, maybe. Lacking a transaction code or sequence number, It doesn't tell the UA whether the response being seen is for the most recent probe, an older probe, a duplicate response to an older probe, or just a completely unrelated CRLF being sent because the server is having hiccups. And you have to mod the "server" to echo CRLF, which it would currently silently discard. Retrofitting onto older SIP stacks would be hard, because the APIs don't let you send null strings, nor do the inform the app when such are received. > Second questions is, given we have to do STUN for UDP, would we > want to do > something different for TCP? Well, there's still the question of reliably demuxing STUN from SIP over TCP, and the question of API refitting. Both can be solved. Is there enough here to suggest that a very-lightweight SIP transaction (like OPTIONS with less overhead) would have benefits over STUN in the keepalive capacity? It might be easier to implement on old stacks, but I can't imagine it would scale as well for large installations. A SIP transaction would provide the option of forcing a re- authentication on keepalive, which might be of interest to some people. -- 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 sip-bounces@ietf.org Mon Feb 13 20:45:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8pGO-0004za-4Q; Mon, 13 Feb 2006 20:45:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8pGI-0004yO-I1 for sip@megatron.ietf.org; Mon, 13 Feb 2006 20:45:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09976 for ; Mon, 13 Feb 2006 20:44:04 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8pU1-0005yS-Bv for sip@ietf.org; Mon, 13 Feb 2006 21:00:01 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 13 Feb 2006 17:45:43 -0800 X-IronPort-AV: i="4.02,110,1139212800"; d="scan'208"; a="1776087149:sNHT31308380" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k1E1jgQJ020522; Mon, 13 Feb 2006 17:45:43 -0800 (PST) Received: from 10.21.82.67 ([10.21.82.67]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 14 Feb 2006 01:45:42 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Mon, 13 Feb 2006 16:39:52 -0800 Subject: Re: [Sip] Outbound and STUN Keep Alive From: Cullen Jennings To: Hisham Khartabil Message-ID: Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcYw/yrUaaqmwJzyEdqdmAARJEEJ/A== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I'm think that double CRLF or STUN will work better than a new SIP method. The problem is performance. I think the STUN requests will be 10 to 100 times faster than a SIP method. Given the frequency of these we are talking about, using a SIP method would require deployments to have way more edge proxies. On 2/13/06 9:01 AM, "Hisham Khartabil" wrote: > The advantages of using STUN for this is that it works for all > application layer protocols that need a keepalive mechanism for NAT > bindings (thats why I suggested privately to Cullen to move this part > of the I-D into a separate draft and submit it in BEHAVE). > > If we want a SIP specific solution, then I would suggest (well, not > entirely my idea. It has been suggested before) a new SIP method that > achieves what STUN achieves for those NATs that reboot. Something like > > NATKEEPALIVE > > The contact in the 200 OK returns the new external port (and IP > address) assigned. The only advantage to this is that we do not use the > same port for both SIP and STUN and we avoid having to extend parsers > to support that and create a link between SIP parsers and STUN parsers. > > Regards, > Hisham > > On Feb 13, 2006, at 12:34 AM, Cullen Jennings wrote: > >> There has been a few threads about keep alives in outbound.... I will >> start >> a thread here. >> >> For UDP, I think STUN is clearly the best choice. It's the only thing >> that >> is quick and works when the NAT reboots. >> >> For TCP, there is the the option to use STUN the same as UDP. >> >> There might be another solution for TCP. I'll call it the Double CRLF. >> Basically the UA sends a CRLF, when the proxy receives this, it must >> sends a >> CRLF within 1 second. If the UA does not get back the CRLF within 6 >> seconds >> of sending the first one, it considers the connection dead. >> >> First questions is, does Double CRLF work? >> >> Second questions is, given we have to do STUN for UDP, would we want >> to do >> something different for TCP? >> >> _______________________________________________ >> 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 sip-bounces@ietf.org Mon Feb 13 20:45:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8pGQ-00050U-Ok; Mon, 13 Feb 2006 20:45:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8pGJ-0004yU-WF for sip@megatron.ietf.org; Mon, 13 Feb 2006 20:45:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09982 for ; Mon, 13 Feb 2006 20:44:05 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8pU1-0005yS-UD for sip@ietf.org; Mon, 13 Feb 2006 21:00:03 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 13 Feb 2006 17:45:44 -0800 X-IronPort-AV: i="4.02,110,1139212800"; d="scan'208"; a="1776087153:sNHT31160952" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k1E1jhQJ020528; Mon, 13 Feb 2006 17:45:43 -0800 (PST) Received: from 10.21.82.67 ([10.21.82.67]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 14 Feb 2006 01:45:43 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Mon, 13 Feb 2006 16:42:28 -0800 Subject: Re: [Sip] Outbound and STUN Keep Alive From: Cullen Jennings To: "Vijay K. Gurbani" Message-ID: Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcYw/4fQxoBlOpzyEdqdmAARJEEJ/A== In-Reply-To: <43F0A75E.9030300@lucent.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On 2/13/06 7:35 AM, "Vijay K. Gurbani" wrote: > Cullen Jennings wrote: >> There might be another solution for TCP. I'll call it the Double >> CRLF. Basically the UA sends a CRLF, when the proxy receives this, it >> must sends a CRLF within 1 second. If the UA does not get back the >> CRLF within 6 seconds of sending the first one, it considers the >> connection dead. >> >> First questions is, does Double CRLF work? > > Cullen: The purpose of the CRLF is to keep the NAT binding alive by > having the NAT periodically see traffic traversing through it, yes? > If so, the binding is kept alive by the CRLF going from the UA->Proxy. > I am not sure what the CRLF from Proxy->UA accomplishes. The point of the CRLF from Proxy to UA was only to allow the UA to know that it's connection to the Proxy was lost and that incoming phone calls would not work unless it when and registered again. > Furthermore, > existing proxies may ignore incoming CRLF, but they certainly do not > generate one in the upstream direction when they get a CRLF... Yes - agree - all of these require changes on both UA and Proxy side. _______________________________________________ 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 sip-bounces@ietf.org Mon Feb 13 21:06:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8paO-0003w6-Om; Mon, 13 Feb 2006 21:06:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8paM-0003w1-U0 for sip@megatron.ietf.org; Mon, 13 Feb 2006 21:06:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11435 for ; Mon, 13 Feb 2006 21:04:48 -0500 (EST) Received: from celine.siteprotect.com ([64.41.122.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8po5-0006eY-9J for sip@ietf.org; Mon, 13 Feb 2006 21:20:46 -0500 Received: from [192.168.1.4] (pool-70-17-194-54.balt.east.verizon.net [70.17.194.54]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id k1E26Nt26665; Mon, 13 Feb 2006 20:06:23 -0600 Subject: Re: [Sip] Outbound and STUN Keep Alive From: "Frank W. Miller" To: Dean Willis In-Reply-To: References: Content-Type: text/plain Organization: Cornfed Systems, LLC Date: Mon, 13 Feb 2006 21:06:19 -0500 Message-Id: <1139882779.2635.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fwmiller@cornfed.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I took the liberty of putting together a new draft that proposes the PING method. The draft is at http://www.cornfed.com/ping.txt. Comments welcome! 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 sip-bounces@ietf.org Tue Feb 14 00:17:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8sVJ-0007Yr-LV; Tue, 14 Feb 2006 00:13:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8sVE-0007XQ-Gy; Tue, 14 Feb 2006 00:13:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26634; Tue, 14 Feb 2006 00:11:42 -0500 (EST) From: vikram.agarwal@flextronicssoftware.com Received: from delta.hssblr.co.in ([203.145.155.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8siq-0004ep-L8; Tue, 14 Feb 2006 00:27:41 -0500 Received: from espion.blr.hss.hns.com (espion.blr.hss.hns.com [10.203.193.21]) by delta.hssblr.co.in (8.11.6/8.11.6) with ESMTP id k1E5CsP12179; Tue, 14 Feb 2006 10:42:56 +0530 In-Reply-To: <1139873125.2635.6.camel@localhost.localdomain> Subject: Re: [Sip] Outbound and STUN Keep Alive To: fwmiller@cornfed.com X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: Date: Tue, 14 Feb 2006 10:42:44 +0530 X-MIMETrack: Serialize by Router on Espion/BLR/HSS(Release 6.5.5|November 30, 2005) at 02/14/2006 10:46:08 AM MIME-Version: 1.0 X-Spam-Score: 1.2 (+) X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb Cc: Cullen Jennings , "sip@ietf.org" , sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0583220163==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0583220163== Content-type: multipart/related; Boundary="0__=EABBFB86DF88EEDD8f9e8a93df938690918cEABBFB86DF88EEDD" Content-Disposition: inline --0__=EABBFB86DF88EEDD8f9e8a93df938690918cEABBFB86DF88EEDD Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

will OPTIONS method not work for the same? Instead of sending an CRL= F we can also send an OPTIONS method to refresh the NAT binding. If i a= m not wrong then OPTIONS method was discared because of the processing = of the SIP message for keeeping the NAT binding alive. Hence, CRLF was = considered. But CRLF is not backward compatible i.e. it does not provid= e MAPPED ADDRESS. Now bringing in the PING method would again be introd= ucing a SIP message based processing which would lead to poor performan= ce.

Regards,
--Vikram

3D"Inactive"Frank W. Miller" <= fwmiller@cornfed.com>


=
          "Frank W. Miller" <fwmiller@cornfe= d.com>
          Sent by: sip-bounces@ietf.org

          02/14/2006 04:55 AM

          Please respond to
          fwmiller@cornfed.com

 =
3D""
To
3D""
Jonathan Rosenberg <jdrosen@cisco.com>
3D""
cc
3D""
Cullen Jennings <fluffy@cisco.com>, "sip@ie= tf.org" <sip@ietf.org>
3D""
Subject
3D""
Re: [Sip] Outbound and STUN Keep Alive
=3D""3D""<= /td>



Actually, I would make the opposite argument.  Given the frequency= with
which you are going to do this, you basically don't care how much
overhead there is associated with it.

If its treated like just another end-to-end NIT, most implementations will have a very simple time adding it.  All the machinery to do i= t is
already there.

Double CRLF sounds like a hack to me.  We all know there are long<= br> periods of time in which signaling traffic might not be flowing.  = We
also know that there is at least one very good reason to have periodic<= br> signaling traffic occur.  I would propose that we just add a PING<= br> message to handle that.  Maybe I'll even throw together a strawman=
proposal for it, it should be fairly trivial to do.

FM


On Mon, 2006-02-13 at 16:12 -0500, Jonathan Rosenberg wrote:
> The problem is, once you say its a SIP method, you nede to do ALL = of the
> processing associated with any SIP transaction - the parsing, stat= e
> machinery, authentication, proxy-require checks, max-forward check= s, and
> so on. Given the frequency with which this message comes, you real= ly,
> really, really want to optimize this.
>
> -Jonathan R.
>
> Hisham Khartabil wrote:
>
> > The advantages of using STUN for this is that it works for al= l
> > application layer protocols that need a keepalive mechanism f= or NAT
> > bindings (thats why I suggested privately to Cullen to move t= his part of
> > the I-D into a separate draft and submit it in BEHAVE).
> >
> > If we want a SIP specific solution, then I would suggest (wel= l, not
> > entirely my idea. It has been suggested before) a new SIP met= hod that
> > achieves what STUN achieves for those NATs that reboot. Somet= hing like
> >
> > NATKEEPALIVE
> >
> > The contact in the 200 OK returns the new external port (and = IP address)
> > assigned. The only advantage to this is that we do not use th= e same port
> > for both SIP and STUN and we avoid having to extend parsers t= o support
> > that and create a link between SIP parsers and STUN parsers.<= br> > >
> > Regards,
> > Hisham
> >
> > On Feb 13, 2006, at 12:34 AM, Cullen Jennings wrote:
> >
> >> There has been a few threads about keep alives in outboun= d.... I will
> >> start
> >> a thread here.
> >>
> >> For UDP, I think STUN is clearly the best choice. It's th= e only thing
> >> that
> >> is quick and works when the NAT reboots.
> >>
> >> For TCP, there is the the option to use STUN the same as = UDP.
> >>
> >> There might be another solution for TCP. I'll call it the= Double CRLF.
> >> Basically the UA sends a CRLF, when the proxy receives th= is, it must
> >> sends a
> >> CRLF within 1 second.  If the UA does not get back t= he CRLF within 6
> >> seconds
> >> of sending the first one, it considers the connection dea= d.
> >>
> >> First questions is, does Double CRLF work?
> >>
> >> Second questions is, given we have to do STUN for UDP, wo= uld we want
> >> to do
> >> something different for TCP?
> >>
> >> _______________________________________________
> >> Sip mailing list  https://www1.ietf.org/mailman/listinfo/si= p
> >> This list is for NEW development of the core SIP Protocol=
> >> Use sip-implementors@cs.columbia.edu for questions on cur= rent sip
> >> Use sipping@ietf.org for new developments on the applicat= ion 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
=


*********************** FSS-Unclassified ***********************= --0__=EABBFB86DF88EEDD8f9e8a93df938690918cEABBFB86DF88EEDD Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <00__=EABBFB86DF88EEDD@flextronicssoftware.com> Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=EABBFB86DF88EEDD8f9e8a93df938690918cEABBFB86DF88EEDD Content-type: image/gif; name="pic29415.gif" Content-Disposition: inline; filename="pic29415.gif" Content-ID: <10__=EABBFB86DF88EEDD@flextronicssoftware.com> Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=EABBFB86DF88EEDD8f9e8a93df938690918cEABBFB86DF88EEDD Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=EABBFB86DF88EEDD@flextronicssoftware.com> Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=EABBFB86DF88EEDD8f9e8a93df938690918cEABBFB86DF88EEDD-- --===============0583220163== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0583220163==-- From sip-bounces@ietf.org Tue Feb 14 02:10:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8uKd-0001AD-EW; Tue, 14 Feb 2006 02:10:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8uKb-0001A5-JC; Tue, 14 Feb 2006 02:10:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02534; Tue, 14 Feb 2006 02:08:51 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8uYG-0007MT-4A; Tue, 14 Feb 2006 02:24:48 -0500 Received: from [192.168.2.106] (c-24-1-177-214.hsd1.tx.comcast.net [24.1.177.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1E79biS016317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Feb 2006 01:09:37 -0600 Message-ID: <43F18268.60402@softarmor.com> Date: Tue, 14 Feb 2006 01:10:32 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: vikram.agarwal@flextronicssoftware.com Subject: Re: [Sip] Outbound and STUN Keep Alive References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , "sip@ietf.org" , fwmiller@cornfed.com, sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org vikram.agarwal@flextronicssoftware.com wrote: > will OPTIONS method not work for the same? Instead of sending an CRLF we > can also send an OPTIONS method to refresh the NAT binding. If i am not > wrong then OPTIONS method was discared because of the processing of the > SIP message for keeeping the NAT binding alive. Hence, CRLF was > considered. But CRLF is not backward compatible i.e. it does not provide > MAPPED ADDRESS. Now bringing in the PING method would again be > introducing a SIP message based processing which would lead to poor > performance. We've demonstrated successfully slaying proxies by bombing them with OPTIONS requests. Back in the "early days" of dynamicsoft, our first proxies were processing 7 INVITE/200/ACK/BYE/200 non-authenticated transaction sequences or about 20 OPTIONS transactions per second. They've of course gotten much faster, but the proportions have stayed pretty much the same. So you can see that in models where a typical SIP transaction load might be 5 transactions per hour per node, adding another 60 OPTIONS transactions per hour per node might reduce your edge-proxy scalability by on the order of 13-1, or roughly a 93% performance hit. That's a big hit. Cullen thinks that stun transactions have substantially less impact on the proxy. I haven't seen real-world benchmarks comparing a proxy doing "normal" SIP to a proxy demuxing SIP and STUN and interleaving requests one a 1-12 interleave. If anybody has done this and has numbers, I'd be thrilled to see them. I'm guessing a stripped down SIP "PING" might take 1/2 the CPU of an OPTIONS, at the very best. That would still give us something like an 80% performance penalty. If Cullen is right and the STUN work takes 1/10th of OPTIONS (or less), then we'd clearly have an advantage in favor of STUN. Using my numbers above, that would be just over a 50% performance hit on the proxy versus not doing keepalives, which I think is tolerable given the benefits of keepalive. -- 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 sip-bounces@ietf.org Tue Feb 14 05:30:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8xSK-0004Hn-AL; Tue, 14 Feb 2006 05:30:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8xSH-0004HY-R2; Tue, 14 Feb 2006 05:30:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14471; Tue, 14 Feb 2006 05:29:00 -0500 (EST) Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8xg2-0004a6-1W; Tue, 14 Feb 2006 05:45:01 -0500 Received: from rly07b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly07b.srv.mailcontrol.com (MailControl) with ESMTP id k1EAUUWC024704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Feb 2006 10:30:32 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly07b.srv.mailcontrol.com (MailControl) id k1EATiX5021860; Tue, 14 Feb 2006 10:29:44 GMT Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly07b-eth0.srv.mailcontrol.com (envelope-sender cboulton@ubiquity.net) (MIMEDefang) with ESMTP id k1EAThFZ021819; Tue, 14 Feb 2006 10:29:44 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Tue, 14 Feb 2006 10:29:43 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE0311892B@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcYxNjbetQj2GKRKSgGr6NRWvAf6QAAGr75Q From: "Chris Boulton" To: "Dean Willis" , X-Scanned-By: MailControl A-06-00-02 (www.mailcontrol.com) on 10.66.1.117 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , sip@ietf.org, fwmiller@cornfed.com, sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org If Cullen is right [Chris Boulton]Dean - what do you mean if :-).=20 and the STUN work takes 1/10th of OPTIONS (or less),=20 then we'd clearly have an advantage in favor of STUN.=20 [Chris Boulton] I also feel that anything that helps promote the use and deployment of STUN in out networks is a good thing and should be encouraged. IMHO it fits and is far more elegant than the other solutions + has all the benefits previously mentioned. Why hack SIP? Why double CRLF when we have a suitably sensible probing protocol.=20 Information contained in this e-mail and any attachments are intended for t= he use of the addressee only, and may contain confidential information of U= biquity Software Corporation. All unauthorized use, disclosure or distribu= tion is strictly prohibited. If you are not the addressee, please notify t= he sender immediately and destroy all copies of this email. Unless otherwi= se expressly agreed in writing signed by an officer of Ubiquity Software Co= rporation, nothing in this communication shall be deemed to be legally bind= ing. 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 sip-bounces@ietf.org Tue Feb 14 07:53:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8zgW-0006uL-3O; Tue, 14 Feb 2006 07:53:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8zgU-0006uG-Ls for sip@megatron.ietf.org; Tue, 14 Feb 2006 07:53:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22530 for ; Tue, 14 Feb 2006 07:51:48 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8zuI-0000OM-3m for sip@ietf.org; Tue, 14 Feb 2006 08:07:51 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 619FC194480 for ; Tue, 14 Feb 2006 13:53:23 +0100 (CET) Received: from [192.168.1.39] ([192.168.1.39]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Feb 2006 13:52:00 +0100 In-Reply-To: <45730E094814E44488F789C1CDED27AE0311892B@gbnewp0758m.eu.ubiquity.net> References: <45730E094814E44488F789C1CDED27AE0311892B@gbnewp0758m.eu.ubiquity.net> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <508ee40d792d339b591181b95c554297@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Tue, 14 Feb 2006 13:53:39 +0100 To: "Chris Boulton" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 14 Feb 2006 12:52:00.0252 (UTC) FILETIME=[721BCBC0:01C63165] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org List" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 14, 2006, at 11:29 AM, Chris Boulton wrote: > > If Cullen is right > > [Chris Boulton]Dean - what do you mean if :-). > > and the STUN work takes 1/10th of OPTIONS (or less), > then we'd clearly have an advantage in favor of STUN. > > [Chris Boulton] I also feel that anything that helps promote the use > and > deployment of STUN in out networks is a good thing and should be > encouraged. IMHO it fits and is far more elegant than the other > solutions + has all the benefits previously mentioned. Why hack SIP? Because it is not a good design to have 2 protocols run on the same port. You will have to hack your SIP parser to distinguish between SIP and STUN messages. You will also need to create a horizontal link between your SIP stack and STUN module. Hisham > Why double CRLF when we have a suitably sensible probing protocol. > > > Information contained in this e-mail and any attachments are intended > for the use of the addressee only, and may contain confidential > information of Ubiquity Software Corporation. All unauthorized use, > disclosure or distribution is strictly prohibited. If you are not the > addressee, please notify the sender immediately and destroy all copies > of this email. Unless otherwise expressly agreed in writing signed by > an officer of Ubiquity Software Corporation, nothing in this > communication shall be deemed to be legally binding. 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 > _______________________________________________ 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 sip-bounces@ietf.org Tue Feb 14 08:07:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8ztv-0001GY-Pl; Tue, 14 Feb 2006 08:07:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8ztt-0001G2-Lj for sip@megatron.ietf.org; Tue, 14 Feb 2006 08:07:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23936 for ; Tue, 14 Feb 2006 08:05:39 -0500 (EST) Received: from 26.mail-out.ovh.net ([213.186.42.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F907e-0000v7-D0 for sip@ietf.org; Tue, 14 Feb 2006 08:21:43 -0500 Received: (qmail 27250 invoked by uid 503); 14 Feb 2006 13:07:33 -0000 Received: (QMFILT: 1.0); 14 Feb 2006 13:07:33 -0000 Received: from b6.ovh.net (HELO mail49.ha.ovh.net) (213.186.33.56) by 26.mail-out.ovh.net with SMTP; 14 Feb 2006 13:07:33 -0000 Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 14 Feb 2006 13:07:17 -0000 Received: from mail49.ha.ovh.net (10.0.50.49) by mail49.ha.ovh.net with SMTP; 14 Feb 2006 13:07:14 -0000 Received: from b0.ovh.net (HELO queue-pre) (213.186.33.50) by b0.ovh.net with SMTP; 14 Feb 2006 13:07:14 -0000 Received: from lneuilly-152-23-101-57.w217-128.abo.wanadoo.fr (HELO ?127.0.0.1?) (217.128.240.57) by ns0.ovh.net with SMTP; 14 Feb 2006 13:07:14 -0000 Message-ID: <43F1D603.4000901@nexcom.fr> Date: Tue, 14 Feb 2006 14:07:15 +0100 From: Thomas Leseney User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "sip@ietf.org List" Subject: Re: [Sip] Outbound and STUN Keep Alive References: <45730E094814E44488F789C1CDED27AE0311892B@gbnewp0758m.eu.ubiquity.net> <508ee40d792d339b591181b95c554297@telio.no> In-Reply-To: <508ee40d792d339b591181b95c554297@telio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0607-0, 13/02/2006), Outbound message X-Antivirus-Status: Clean X-Ovh-Remote: 217.128.240.57 (lneuilly-152-23-101-57.w217-128.abo.wanadoo.fr) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-Spam-Check: fait|type 1&3|0.0|H 0.505984 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dear Hisham, STUN usually run on port 3478. http://www.iana.org/assignments/port-numbers Regards, Thomas Hisham Khartabil wrote: > > On Feb 14, 2006, at 11:29 AM, Chris Boulton wrote: > >> >> If Cullen is right >> >> [Chris Boulton]Dean - what do you mean if :-). >> >> and the STUN work takes 1/10th of OPTIONS (or less), >> then we'd clearly have an advantage in favor of STUN. >> >> [Chris Boulton] I also feel that anything that helps promote the use and >> deployment of STUN in out networks is a good thing and should be >> encouraged. IMHO it fits and is far more elegant than the other >> solutions + has all the benefits previously mentioned. Why hack SIP? > > > Because it is not a good design to have 2 protocols run on the same > port. You will have to hack your SIP parser to distinguish between SIP > and STUN messages. You will also need to create a horizontal link > between your SIP stack and STUN module. > > Hisham > >> Why double CRLF when we have a suitably sensible probing protocol. >> >> >> Information contained in this e-mail and any attachments are intended >> for the use of the addressee only, and may contain confidential >> information of Ubiquity Software Corporation. All unauthorized use, >> disclosure or distribution is strictly prohibited. If you are not >> the addressee, please notify the sender immediately and destroy all >> copies of this email. Unless otherwise expressly agreed in writing >> signed by an officer of Ubiquity Software Corporation, nothing in >> this communication shall be deemed to be legally binding. 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 >> > > > _______________________________________________ > 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 sip-bounces@ietf.org Tue Feb 14 08:24:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F90Ah-0001cp-3F; Tue, 14 Feb 2006 08:24:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F90Ae-0001ca-EL for sip@megatron.ietf.org; Tue, 14 Feb 2006 08:24:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25401 for ; Tue, 14 Feb 2006 08:22:57 -0500 (EST) Received: from smail3.alcatel.fr ([64.208.49.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F90OT-0001W3-9R for sip@ietf.org; Tue, 14 Feb 2006 08:39:01 -0500 Received: from missrv1.nextenso.alcatel.fr (proxy.nextenso.alcatel.fr [139.54.130.250]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id k1EDOUT4017625; Tue, 14 Feb 2006 14:24:31 +0100 Received: from [139.54.131.75] (nx1075.nextenso.alcatel.fr [139.54.131.75]) by missrv1.nextenso.alcatel.fr (8.12.8/8.12.8) with ESMTP id k1EDORsY022850; Tue, 14 Feb 2006 14:24:27 +0100 Message-ID: <43F1DA2E.8040504@alcatel.fr> Date: Tue, 14 Feb 2006 14:25:02 +0100 From: Thomas Froment Organization: Alcatel User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "sip@ietf.org List" Subject: Re: [Sip] Outbound and STUN Keep Alive References: <45730E094814E44488F789C1CDED27AE0311892B@gbnewp0758m.eu.ubiquity.net> <508ee40d792d339b591181b95c554297@telio.no> <43F1D603.4000901@nexcom.fr> In-Reply-To: <43F1D603.4000901@nexcom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Thomas Leseney wrote: >>> >>> >>> [Chris Boulton] I also feel that anything that helps promote the use >>> and >>> deployment of STUN in out networks is a good thing and should be >>> encouraged. IMHO it fits and is far more elegant than the other >>> solutions + has all the benefits previously mentioned. Why hack SIP? >> >> >> >> Because it is not a good design to have 2 protocols run on the same >> port. You will have to hack your SIP parser to distinguish between >> SIP and STUN messages. You will also need to create a horizontal link >> between your SIP stack and STUN module. > In order to support double CR/LF, you will also have to hack your SIP stack, otherwise it will, for sure, raise some kind of parse exception ;-)... _______________________________________________ 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 sip-bounces@ietf.org Tue Feb 14 08:38:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F90Nj-0007TP-En; Tue, 14 Feb 2006 08:38:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F90Nh-0007TK-5a for sip@megatron.ietf.org; Tue, 14 Feb 2006 08:38:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26436 for ; Tue, 14 Feb 2006 08:36:26 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F90bV-0001wn-4E for sip@ietf.org; Tue, 14 Feb 2006 08:52:30 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id EC56B194474 for ; Tue, 14 Feb 2006 14:38:01 +0100 (CET) Received: from [192.168.1.39] ([192.168.1.39]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Feb 2006 14:36:38 +0100 In-Reply-To: <43F1D603.4000901@nexcom.fr> References: <45730E094814E44488F789C1CDED27AE0311892B@gbnewp0758m.eu.ubiquity.net> <508ee40d792d339b591181b95c554297@telio.no> <43F1D603.4000901@nexcom.fr> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3fc26ddf5f60729d97812dbc8040b71b@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Tue, 14 Feb 2006 14:38:17 +0100 To: Thomas Leseney X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 14 Feb 2006 13:36:38.0665 (UTC) FILETIME=[AE912F90:01C6316B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org List" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 14, 2006, at 2:07 PM, Thomas Leseney wrote: > Dear Hisham, > > STUN usually run on port 3478. Not in this case :) You are using stun to keep sip port bindings open. Hisham > http://www.iana.org/assignments/port-numbers > > Regards, > > Thomas > > > Hisham Khartabil wrote: > >> >> On Feb 14, 2006, at 11:29 AM, Chris Boulton wrote: >> >>> >>> If Cullen is right >>> >>> [Chris Boulton]Dean - what do you mean if :-). >>> >>> and the STUN work takes 1/10th of OPTIONS (or less), >>> then we'd clearly have an advantage in favor of STUN. >>> >>> [Chris Boulton] I also feel that anything that helps promote the use >>> and >>> deployment of STUN in out networks is a good thing and should be >>> encouraged. IMHO it fits and is far more elegant than the other >>> solutions + has all the benefits previously mentioned. Why hack SIP? >> >> >> Because it is not a good design to have 2 protocols run on the same >> port. You will have to hack your SIP parser to distinguish between >> SIP and STUN messages. You will also need to create a horizontal link >> between your SIP stack and STUN module. >> >> Hisham >> >>> Why double CRLF when we have a suitably sensible probing protocol. >>> >>> >>> Information contained in this e-mail and any attachments are >>> intended for the use of the addressee only, and may contain >>> confidential information of Ubiquity Software Corporation. All >>> unauthorized use, disclosure or distribution is strictly prohibited. >>> If you are not the addressee, please notify the sender immediately >>> and destroy all copies of this email. Unless otherwise expressly >>> agreed in writing signed by an officer of Ubiquity Software >>> Corporation, nothing in this communication shall be deemed to be >>> legally binding. 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 >>> >> >> >> _______________________________________________ >> 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 sip-bounces@ietf.org Tue Feb 14 08:51:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F90aE-0003dG-Ja; Tue, 14 Feb 2006 08:51:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F90aB-0003d5-P2; Tue, 14 Feb 2006 08:51:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27096; Tue, 14 Feb 2006 08:49:20 -0500 (EST) From: vikram.agarwal@flextronicssoftware.com Received: from delta.hssblr.co.in ([203.145.155.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F90nz-0002HH-Qi; Tue, 14 Feb 2006 09:05:25 -0500 Received: from espion.blr.hss.hns.com (espion.blr.hss.hns.com [10.203.193.21]) by delta.hssblr.co.in (8.11.6/8.11.6) with ESMTP id k1EDot031338; Tue, 14 Feb 2006 19:20:55 +0530 In-Reply-To: <3fc26ddf5f60729d97812dbc8040b71b@telio.no> Subject: Re: [Sip] Outbound and STUN Keep Alive To: Hisham Khartabil X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: Date: Tue, 14 Feb 2006 19:20:37 +0530 X-MIMETrack: Serialize by Router on Espion/BLR/HSS(Release 6.5.5|November 30, 2005) at 02/14/2006 07:24:12 PM MIME-Version: 1.0 X-Spam-Score: 0.9 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 Cc: "sip@ietf.org List" , sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1527584488==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1527584488== Content-type: multipart/related; Boundary="0__=EABBFB86DFD805D18f9e8a93df938690918cEABBFB86DFD805D1" Content-Disposition: inline --0__=EABBFB86DFD805D18f9e8a93df938690918cEABBFB86DFD805D1 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

assume that the stun server is the next hop after the NAT to support= the symmetric NAT.

UA - > NAT -> STUN SERVER -> PROXY.

Now, if a SIP message arrives then the STUN Server has to distinguish = between a STUN or a SIP request and then has to send the sip message to= the Proxy. i.e. do we also want STUN to act as a proxy for sip request= s? Any message from UA will traverse thru NAT and then STUN and then P= roxy ( if sip message). Ortherwise, as hisham has pointed we need to ha= ve to hack your SIP parser to distinguish between SIP and STUN messages= . Both, the sip message and Proxy stack has to be listening on the same= port.

Regards,
--Vikram.

3D"InactiveHisham Khartabil <hisham.khartabil@= telio.no>


=
          Hisham Khartabil <hisham.khartabil@telio.no&= gt;
          Sent by: sip-bounces@ietf.org

          02/14/2006 07:08 PM

 =
3D""
To
3D""
Thomas Leseney <thomas.leseney@nexcom.fr>=
3D""
cc
3D""
"sip@ietf.org List" <sip@ietf.org>
3D""
Subject
3D""
Re: [Sip] Outbound and STUN Keep Alive
=3D""3D""<= /td>


On Feb 14, 2006, at 2:07 PM, Thomas Leseney wrote:

> Dear Hisham,
>
> STUN usually run on port 3478.

Not in this case :) You are using stun to keep sip port bindings open.<= br>
Hisham

> = http://www.iana.org/assignments/port-numbers
>
> Regards,
>
> Thomas
>
>
> Hisham Khartabil wrote:
>
>>
>> On Feb 14, 2006, at 11:29 AM, Chris Boulton wrote:
>>
>>>
>>> If Cullen is right
>>>
>>> [Chris Boulton]Dean - what do you mean if :-).
>>>
>>>  and the STUN work takes 1/10th of OPTIONS (or less),=
>>> then we'd clearly have an advantage in favor of STUN.
>>>
>>> [Chris Boulton] I also feel that anything that helps promo= te the use
>>> and
>>> deployment of STUN in out networks is a good thing and sho= uld be
>>> encouraged.  IMHO it fits and is far more elegant tha= n the other
>>> solutions + has all the benefits previously mentioned. &nb= sp;Why hack SIP?
>>
>>
>> Because it is not a good design to have 2 protocols run on the= same
>> port. You will have to hack your SIP parser to distinguish bet= ween
>> SIP and STUN messages. You will also need to create a horizont= al link
>> between your SIP stack and STUN module.
>>
>> Hisham
>>
>>> Why double CRLF when we have a suitably sensible probing p= rotocol.
>>>
>>>
>>> Information contained in this e-mail and any attachments a= re
>>> intended for the use of the addressee only, and may contai= n
>>> confidential information of Ubiquity Software Corporation.=  All
>>> unauthorized use, disclosure or distribution is strictly p= rohibited.
>>>  If you are not the addressee, please notify the send= er immediately
>>> and destroy all copies of this email.  Unless otherwi= se expressly
>>> agreed in writing signed by an officer of Ubiquity Softwar= e
>>> Corporation, nothing in this communication shall be deemed= to be
>>> legally binding.  Thank you.
>>>
>>>
>>> _______________________________________________
>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip=
>>> This list is for NEW development of the core SIP Protocol<= br> >>> Use sip-implementors@cs.columbia.edu for questions on curr= ent sip
>>> Use sipping@ietf.org for new developments on the applicati= on 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 o= f 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<= br> > Use sipping@ietf.org for new developments on the application of si= p
>


_______________________________________________
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
=


*********************** FSS-Unclassified ***********************= --0__=EABBFB86DFD805D18f9e8a93df938690918cEABBFB86DFD805D1 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <00__=EABBFB86DFD805D1@flextronicssoftware.com> Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=EABBFB86DFD805D18f9e8a93df938690918cEABBFB86DFD805D1 Content-type: image/gif; name="pic55940.gif" Content-Disposition: inline; filename="pic55940.gif" Content-ID: <10__=EABBFB86DFD805D1@flextronicssoftware.com> Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=EABBFB86DFD805D18f9e8a93df938690918cEABBFB86DFD805D1 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=EABBFB86DFD805D1@flextronicssoftware.com> Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=EABBFB86DFD805D18f9e8a93df938690918cEABBFB86DFD805D1-- --===============1527584488== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1527584488==-- From sip-bounces@ietf.org Tue Feb 14 09:02:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F90kx-0006dW-6o; Tue, 14 Feb 2006 09:02:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F90kv-0006cf-RV; Tue, 14 Feb 2006 09:02:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27795; Tue, 14 Feb 2006 09:00:27 -0500 (EST) Received: from smail3.alcatel.fr ([64.208.49.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F90yj-0002ZN-34; Tue, 14 Feb 2006 09:16:31 -0500 Received: from missrv1.nextenso.alcatel.fr (proxy.nextenso.alcatel.fr [139.54.130.250]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id k1EE1uT4014411; Tue, 14 Feb 2006 15:01:56 +0100 Received: from [139.54.131.75] (nx1075.nextenso.alcatel.fr [139.54.131.75]) by missrv1.nextenso.alcatel.fr (8.12.8/8.12.8) with ESMTP id k1EE1qsY023026; Tue, 14 Feb 2006 15:01:52 +0100 Message-ID: <43F1E2F3.1040406@alcatel.fr> Date: Tue, 14 Feb 2006 15:02:27 +0100 From: Thomas Froment Organization: Alcatel User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) X-Accept-Language: en-us, en MIME-Version: 1.0 To: vikram.agarwal@flextronicssoftware.com Subject: Re: [Sip] Outbound and STUN Keep Alive References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org List" , sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org vikram.agarwal@flextronicssoftware.com wrote: > assume that the stun server is the next hop after the NAT to support > the symmetric NAT. > > UA - > NAT -> STUN SERVER -> PROXY. > > Now, if a SIP message arrives then the STUN Server has to distinguish > between a STUN or a SIP request and then has to send the sip message > to the Proxy. i.e. do we also want STUN to act as a proxy for sip > requests? Any message from UA will traverse thru NAT and then STUN and > then Proxy ( if sip message). > This is not the question here... Of course, a STUN server does not act as a SIP proxy, this is just a redirection switch problem: do we prefer: if (STUN_PAYLOAD) then handleStunMessage(Message) else handleSIPMessage(Message) OR if (double CR/LF) then handlePingMessage(Message) else handleSIPMessage(Message) This is quite the same thing, the only question is, does double CR/LF work (Cullen's question) ? seems yes OR is it better to make STUN, because it is more consistent with UDP case ? I would prefer to make STUN, since it will actually be more consistent to have the same kind of procedure for UDP and TCP, but if CR/LF works, I don't have any objection... > Ortherwise, as hisham has pointed we need to have to hack your SIP > parser to distinguish between SIP and STUN messages. Both, the sip > message and Proxy stack has to be listening on the same port. > > Regards, > --Vikram. > > Inactive hide details for Hisham Khartabil > Hisham Khartabil > > > *Hisham Khartabil * > Sent by: sip-bounces@ietf.org > > 02/14/2006 07:08 PM > > > > To > > Thomas Leseney > > cc > > "sip@ietf.org List" > > Subject > > Re: [Sip] Outbound and STUN Keep Alive > > > > > > On Feb 14, 2006, at 2:07 PM, Thomas Leseney wrote: > > > Dear Hisham, > > > > STUN usually run on port 3478. > > Not in this case :) You are using stun to keep sip port bindings open. > > Hisham > > > http://www.iana.org/assignments/port-numbers > > > > Regards, > > > > Thomas > > > > > > Hisham Khartabil wrote: > > > >> > >> On Feb 14, 2006, at 11:29 AM, Chris Boulton wrote: > >> > >>> > >>> If Cullen is right > >>> > >>> [Chris Boulton]Dean - what do you mean if :-). > >>> > >>> and the STUN work takes 1/10th of OPTIONS (or less), > >>> then we'd clearly have an advantage in favor of STUN. > >>> > >>> [Chris Boulton] I also feel that anything that helps promote the use > >>> and > >>> deployment of STUN in out networks is a good thing and should be > >>> encouraged. IMHO it fits and is far more elegant than the other > >>> solutions + has all the benefits previously mentioned. Why hack SIP? > >> > >> > >> Because it is not a good design to have 2 protocols run on the same > >> port. You will have to hack your SIP parser to distinguish between > >> SIP and STUN messages. You will also need to create a horizontal link > >> between your SIP stack and STUN module. > >> > >> Hisham > >> > >>> Why double CRLF when we have a suitably sensible probing protocol. > >>> > >>> > >>> Information contained in this e-mail and any attachments are > >>> intended for the use of the addressee only, and may contain > >>> confidential information of Ubiquity Software Corporation. All > >>> unauthorized use, disclosure or distribution is strictly prohibited. > >>> If you are not the addressee, please notify the sender immediately > >>> and destroy all copies of this email. Unless otherwise expressly > >>> agreed in writing signed by an officer of Ubiquity Software > >>> Corporation, nothing in this communication shall be deemed to be > >>> legally binding. 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 > >>> > >> > >> > >> _______________________________________________ > >> 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 > > > > *********************** FSS-Unclassified *********************** > >------------------------------------------------------------------------ > >_______________________________________________ >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 sip-bounces@ietf.org Tue Feb 14 09:09:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F90rj-0000ZC-Mh; Tue, 14 Feb 2006 09:09:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F90ri-0000Yp-6L for sip@megatron.ietf.org; Tue, 14 Feb 2006 09:09:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28330 for ; Tue, 14 Feb 2006 09:07:27 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F915X-0002mH-Ec for sip@ietf.org; Tue, 14 Feb 2006 09:23:32 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 14 Feb 2006 06:09:04 -0800 X-IronPort-AV: i="4.02,113,1139212800"; d="scan'208"; a="255401757:sNHT35464500" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1EE90KZ009217; Tue, 14 Feb 2006 06:09:04 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Feb 2006 09:09:03 -0500 Received: from [192.168.1.101] ([10.86.242.244]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Feb 2006 09:09:03 -0500 Message-ID: <43F1E47E.3030902@cisco.com> Date: Tue, 14 Feb 2006 09:09:02 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: vikram.agarwal@flextronicssoftware.com Subject: Re: [Sip] Outbound and STUN Keep Alive References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Feb 2006 14:09:03.0197 (UTC) FILETIME=[359938D0:01C63170] X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org List" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The model that is described in sip-outbound is that the proxy listens on port 5060 for messages. Messages can arrive formatted either as SIP, or as STUN. It is essential for the nat traversal properties that the keepalives be sent to the same port as the SIP signaling; without that, you will not get traversal through symmetric NAT or similar firewalls. This does in fact mean that your parser needs to be modified so that it first detects whether the message is sip or stun, and then sends it to the right code module appropriately. This is easily doable, and not that complicated. It is not beautiful, but engineering is about making tradeoffs. Here, the ENORMOUS cost of SIP message processing relative to stun, combined with the frequency of the keepalives, argues in favor of this tradeoff. I will further note that a "modified PING message", or any other kind of SIP message processing that does not follow SIP semantics as defined in RFC 3261, is effectively identical to the multiple-protocol mechanism of running STUN and SIP on the same port. You'll need to figure out which protocol it is (SIP or modified SIP), and send the request to the right code path appropirately. Another thing to note on disambiguation. A fairly major revision of stun is coming which is going to make it much clearer about how it is applicable to these types of problems. One of the changes that will be in the draft is the usage of a "magic cookie", similar to the via branch cookie, that occupies some of the bits in the STUN transaction ID. This means that there is a well known sequence of characters in a fixed position in every single stun message. This makes it trivial to differentiate stun from anything else. Thanks, Jonathan R. vikram.agarwal@flextronicssoftware.com wrote: > assume that the stun server is the next hop after the NAT to support the > symmetric NAT. > > UA - > NAT -> STUN SERVER -> PROXY. > > Now, if a SIP message arrives then the STUN Server has to distinguish > between a STUN or a SIP request and then has to send the sip message to > the Proxy. i.e. do we also want STUN to act as a proxy for sip requests? > Any message from UA will traverse thru NAT and then STUN and then Proxy > ( if sip message). Ortherwise, as hisham has pointed we need to have to > hack your SIP parser to distinguish between SIP and STUN messages. Both, > the sip message and Proxy stack has to be listening on the same port. > > Regards, > --Vikram. > > Inactive hide details for Hisham Khartabil > Hisham Khartabil > > > *Hisham Khartabil * > Sent by: sip-bounces@ietf.org > > 02/14/2006 07:08 PM > > > > To > > Thomas Leseney > > cc > > "sip@ietf.org List" > > Subject > > Re: [Sip] Outbound and STUN Keep Alive > > > > > > On Feb 14, 2006, at 2:07 PM, Thomas Leseney wrote: > > > Dear Hisham, > > > > STUN usually run on port 3478. > > Not in this case :) You are using stun to keep sip port bindings open. > > Hisham > > > http://www.iana.org/assignments/port-numbers > > > > Regards, > > > > Thomas > > > > > > Hisham Khartabil wrote: > > > >> > >> On Feb 14, 2006, at 11:29 AM, Chris Boulton wrote: > >> > >>> > >>> If Cullen is right > >>> > >>> [Chris Boulton]Dean - what do you mean if :-). > >>> > >>> and the STUN work takes 1/10th of OPTIONS (or less), > >>> then we'd clearly have an advantage in favor of STUN. > >>> > >>> [Chris Boulton] I also feel that anything that helps promote the use > >>> and > >>> deployment of STUN in out networks is a good thing and should be > >>> encouraged. IMHO it fits and is far more elegant than the other > >>> solutions + has all the benefits previously mentioned. Why hack SIP? > >> > >> > >> Because it is not a good design to have 2 protocols run on the same > >> port. You will have to hack your SIP parser to distinguish between > >> SIP and STUN messages. You will also need to create a horizontal link > >> between your SIP stack and STUN module. > >> > >> Hisham > >> > >>> Why double CRLF when we have a suitably sensible probing protocol. > >>> > >>> > >>> Information contained in this e-mail and any attachments are > >>> intended for the use of the addressee only, and may contain > >>> confidential information of Ubiquity Software Corporation. All > >>> unauthorized use, disclosure or distribution is strictly prohibited. > >>> If you are not the addressee, please notify the sender immediately > >>> and destroy all copies of this email. Unless otherwise expressly > >>> agreed in writing signed by an officer of Ubiquity Software > >>> Corporation, nothing in this communication shall be deemed to be > >>> legally binding. 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 > >>> > >> > >> > >> _______________________________________________ > >> 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 > > > > *********************** FSS-Unclassified *********************** > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.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 sip-bounces@ietf.org Tue Feb 14 09:36:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F91IV-0001y8-TU; Tue, 14 Feb 2006 09:36:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F91IU-0001wz-51 for sip@megatron.ietf.org; Tue, 14 Feb 2006 09:36:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01032 for ; Tue, 14 Feb 2006 09:35:06 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F91WJ-0003wl-IO for sip@ietf.org; Tue, 14 Feb 2006 09:51:12 -0500 Received: from ihemail2.lucent.com (h192-11-222-163.lucent.com [192.11.222.163]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k1EEae34001852; Tue, 14 Feb 2006 08:36:41 -0600 (CST) Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k1EEaahA029925; Tue, 14 Feb 2006 08:36:36 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k1EEaZ708293; Tue, 14 Feb 2006 08:36:35 -0600 (CST) Message-ID: <43F1EAF3.3010307@lucent.com> Date: Tue, 14 Feb 2006 08:36:35 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] Outbound and STUN Keep Alive References: In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Cc: SIP LIST X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0026039859==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0026039859== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010000020501000707090606" This is a cryptographically signed message in MIME format. --------------ms010000020501000707090606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cullen Jennings wrote: >> Cullen: The purpose of the CRLF is to keep the NAT binding alive by >> having the NAT periodically see traffic traversing through it, >> yes? If so, the binding is kept alive by the CRLF going from the >> UA->Proxy. I am not sure what the CRLF from Proxy->UA accomplishes. >> > > The point of the CRLF from Proxy to UA was only to allow the UA to > know that it's connection to the Proxy was lost and that incoming > phone calls would not work unless it when and registered again. OK; so we are essentially doing two things with the double CRLF: keep the NAT bindings alive and implement some sort of heartbeat mechanism. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) --------------ms010000020501000707090606 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAyMTQxNDM2MzVaMCMGCSqGSIb3DQEJ BDEWBBRy5TvL05CiFuiHGV/Viy5O3N6+CzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGAHTMfi41q8JoSTMe/NQMXZ+4zU/4OkCw4WrL8aYk6YVdwAjcvzD55 jUSlDnEgrYVO0x+xLYmqXNCm/AFvf00LGNwdWvjlCdVeBVMwJrCxhQgkPcG9V5xu8kptmodY SO26DP+9QLvdxB8NeiS5sL/QezXH1W9zJ+SyVw7uZGyq5l8AAAAAAAA= --------------ms010000020501000707090606-- --===============0026039859== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0026039859==-- From sip-bounces@ietf.org Tue Feb 14 10:02:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F91hI-0005yK-M9; Tue, 14 Feb 2006 10:02:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F91hF-0005x7-A5 for sip@megatron.ietf.org; Tue, 14 Feb 2006 10:02:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02519 for ; Tue, 14 Feb 2006 10:00:44 -0500 (EST) Received: from celine.siteprotect.com ([64.41.122.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F91v1-0004hT-1F for sip@ietf.org; Tue, 14 Feb 2006 10:16:47 -0500 Received: from [192.168.1.4] (pool-141-157-81-211.balt.east.verizon.net [141.157.81.211]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id k1EF1tb24789; Tue, 14 Feb 2006 09:01:55 -0600 Subject: Re: [Sip] Outbound and STUN Keep Alive From: "Frank W. Miller" To: Jonathan Rosenberg In-Reply-To: <43F1E47E.3030902@cisco.com> References: <43F1E47E.3030902@cisco.com> Content-Type: text/plain Organization: Cornfed Systems, LLC Date: Tue, 14 Feb 2006 10:01:53 -0500 Message-Id: <1139929313.2638.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org List" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fwmiller@cornfed.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Why would we use STUN to keep SIP port bindings alive? What are we going to do when the next protocol that communicates ports other than the ones it uses comes along, do multiplexing of multiple ports after the demultiplexing of each has occurred? IMHO, STUN should be used to discover NATs and thats it. It should be the responsibility of the protocols using the ports to make sure their ports stay alive at the NAT. I thought double CRLF was a hack. Merging two protocols onto the same port is a hack worthy of a ring of hell. The problem here is keeping the SIP port open, and thats a SIP problem, not a STUN problem. While I'm sympathetic to Dean's and Cullen's comments about performance, I just can't buy it (besides, the hardware vendors will luv it since the will get to sell bigger iron). We can limit the use of these things so that these performance issues are minimized. I guess my bottom line is that this seems to be a SIP problem and a proper design approach would be to solve it in SIP. FM On Tue, 2006-02-14 at 09:09 -0500, Jonathan Rosenberg wrote: > The model that is described in sip-outbound is that the proxy listens on > port 5060 for messages. Messages can arrive formatted either as SIP, or > as STUN. It is essential for the nat traversal properties that the > keepalives be sent to the same port as the SIP signaling; without that, > you will not get traversal through symmetric NAT or similar firewalls. > > This does in fact mean that your parser needs to be modified so that it > first detects whether the message is sip or stun, and then sends it to > the right code module appropriately. This is easily doable, and not that > complicated. It is not beautiful, but engineering is about making > tradeoffs. Here, the ENORMOUS cost of SIP message processing relative to > stun, combined with the frequency of the keepalives, argues in favor of > this tradeoff. > > I will further note that a "modified PING message", or any other kind of > SIP message processing that does not follow SIP semantics as defined in > RFC 3261, is effectively identical to the multiple-protocol mechanism of > running STUN and SIP on the same port. You'll need to figure out which > protocol it is (SIP or modified SIP), and send the request to the right > code path appropirately. > > Another thing to note on disambiguation. A fairly major revision of stun > is coming which is going to make it much clearer about how it is > applicable to these types of problems. One of the changes that will be > in the draft is the usage of a "magic cookie", similar to the via branch > cookie, that occupies some of the bits in the STUN transaction ID. This > means that there is a well known sequence of characters in a fixed > position in every single stun message. This makes it trivial to > differentiate stun from anything else. > > Thanks, > Jonathan R. > > > vikram.agarwal@flextronicssoftware.com wrote: > > > assume that the stun server is the next hop after the NAT to support the > > symmetric NAT. > > > > UA - > NAT -> STUN SERVER -> PROXY. > > > > Now, if a SIP message arrives then the STUN Server has to distinguish > > between a STUN or a SIP request and then has to send the sip message to > > the Proxy. i.e. do we also want STUN to act as a proxy for sip requests? > > Any message from UA will traverse thru NAT and then STUN and then Proxy > > ( if sip message). Ortherwise, as hisham has pointed we need to have to > > hack your SIP parser to distinguish between SIP and STUN messages. Both, > > the sip message and Proxy stack has to be listening on the same port. > > > > Regards, > > --Vikram. > > > > Inactive hide details for Hisham Khartabil > > Hisham Khartabil > > > > > > *Hisham Khartabil * > > Sent by: sip-bounces@ietf.org > > > > 02/14/2006 07:08 PM > > > > > > > > To > > > > Thomas Leseney > > > > cc > > > > "sip@ietf.org List" > > > > Subject > > > > Re: [Sip] Outbound and STUN Keep Alive > > > > > > > > > > > > On Feb 14, 2006, at 2:07 PM, Thomas Leseney wrote: > > > > > Dear Hisham, > > > > > > STUN usually run on port 3478. > > > > Not in this case :) You are using stun to keep sip port bindings open. > > > > Hisham > > > > > http://www.iana.org/assignments/port-numbers > > > > > > Regards, > > > > > > Thomas > > > > > > > > > Hisham Khartabil wrote: > > > > > >> > > >> On Feb 14, 2006, at 11:29 AM, Chris Boulton wrote: > > >> > > >>> > > >>> If Cullen is right > > >>> > > >>> [Chris Boulton]Dean - what do you mean if :-). > > >>> > > >>> and the STUN work takes 1/10th of OPTIONS (or less), > > >>> then we'd clearly have an advantage in favor of STUN. > > >>> > > >>> [Chris Boulton] I also feel that anything that helps promote the use > > >>> and > > >>> deployment of STUN in out networks is a good thing and should be > > >>> encouraged. IMHO it fits and is far more elegant than the other > > >>> solutions + has all the benefits previously mentioned. Why hack SIP? > > >> > > >> > > >> Because it is not a good design to have 2 protocols run on the same > > >> port. You will have to hack your SIP parser to distinguish between > > >> SIP and STUN messages. You will also need to create a horizontal link > > >> between your SIP stack and STUN module. > > >> > > >> Hisham > > >> > > >>> Why double CRLF when we have a suitably sensible probing protocol. > > >>> > > >>> > > >>> Information contained in this e-mail and any attachments are > > >>> intended for the use of the addressee only, and may contain > > >>> confidential information of Ubiquity Software Corporation. All > > >>> unauthorized use, disclosure or distribution is strictly prohibited. > > >>> If you are not the addressee, please notify the sender immediately > > >>> and destroy all copies of this email. Unless otherwise expressly > > >>> agreed in writing signed by an officer of Ubiquity Software > > >>> Corporation, nothing in this communication shall be deemed to be > > >>> legally binding. 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 > > >>> > > >> > > >> > > >> _______________________________________________ > > >> 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 > > > > > > > > *********************** FSS-Unclassified *********************** > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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 sip-bounces@ietf.org Tue Feb 14 10:21:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F91ze-0005Uh-AH; Tue, 14 Feb 2006 10:21:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F91zc-0005Ub-Oz for sip@megatron.ietf.org; Tue, 14 Feb 2006 10:21:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03780 for ; Tue, 14 Feb 2006 10:19:43 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F92DQ-0005Hh-SS for sip@ietf.org; Tue, 14 Feb 2006 10:35:47 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 14 Feb 2006 07:21:18 -0800 X-IronPort-AV: i="4.02,114,1139212800"; d="scan'208"; a="1776264445:sNHT29040318" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k1EFLGc1019173; Tue, 14 Feb 2006 07:21:16 -0800 (PST) Received: from 10.21.98.95 ([10.21.98.95]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 14 Feb 2006 15:21:16 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Tue, 14 Feb 2006 07:21:37 -0800 Subject: Re: [Sip] Outbound and STUN Keep Alive From: Cullen Jennings To: "sip@ietf.org" Message-ID: Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcYxeliqlxyMgJ1tEdqXIgARJEEJ/A== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I think that Dean brings up some very good points below - it's not clear that double CRLF will work. It could very well detect the connection was "live" when really it just had some old CRLF junk that got backlogged. Unless someone has a compelling argument that double CRLF will work, I don't think I am going to bother to write it up. Cullen On 2/13/06 5:31 PM, "Dean Willis" wrote: > > On Feb 12, 2006, at 5:34 PM, Cullen Jennings wrote: > >> First questions is, does Double CRLF work? >> > > Sortof, maybe. Lacking a transaction code or sequence number, It > doesn't tell the UA whether the response being seen is for the most > recent probe, an older probe, a duplicate response to an older probe, > or just a completely unrelated CRLF being sent because the server is > having hiccups. > > And you have to mod the "server" to echo CRLF, which it would > currently silently discard. > > Retrofitting onto older SIP stacks would be hard, because the APIs > don't let you send null strings, nor do the inform the app when such > are received. _______________________________________________ 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 sip-bounces@ietf.org Tue Feb 14 10:24:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F922s-00062i-5q; Tue, 14 Feb 2006 10:24:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F922p-00062d-2i for sip@megatron.ietf.org; Tue, 14 Feb 2006 10:24:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04099 for ; Tue, 14 Feb 2006 10:23:01 -0500 (EST) Received: from smail3.alcatel.fr ([64.208.49.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F92Gd-0005RJ-Sw for sip@ietf.org; Tue, 14 Feb 2006 10:39:05 -0500 Received: from missrv1.nextenso.alcatel.fr (proxy.nextenso.alcatel.fr [139.54.130.250]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id k1EFOTT4010494; Tue, 14 Feb 2006 16:24:29 +0100 Received: from [139.54.131.75] (nx1075.nextenso.alcatel.fr [139.54.131.75]) by missrv1.nextenso.alcatel.fr (8.12.8/8.12.8) with ESMTP id k1EFORsY023377; Tue, 14 Feb 2006 16:24:28 +0100 Message-ID: <43F1F64F.9030205@alcatel.fr> Date: Tue, 14 Feb 2006 16:25:03 +0100 From: Thomas Froment Organization: Alcatel User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) X-Accept-Language: en-us, en MIME-Version: 1.0 To: fwmiller@cornfed.com Subject: Re: [Sip] Outbound and STUN Keep Alive References: <43F1E47E.3030902@cisco.com> <1139929313.2638.6.camel@localhost.localdomain> In-Reply-To: <1139929313.2638.6.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org List" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Frank W. Miller wrote: >Why would we use STUN to keep SIP port bindings alive? What are we >going to do when the next protocol that communicates ports other than >the ones it uses comes along, do multiplexing of multiple ports after >the demultiplexing of each has occurred? > >IMHO, STUN should be used to discover NATs and thats it. It should be >the responsibility of the protocols using the ports to make sure their >ports stay alive at the NAT. > >I thought double CRLF was a hack. Merging two protocols onto the same >port is a hack worthy of a ring of hell. The problem here is keeping >the SIP port open, and thats a SIP problem, not a STUN problem. > >While I'm sympathetic to Dean's and Cullen's comments about performance, >I just can't buy it (besides, the hardware vendors will luv it since the >will get to sell bigger iron). We can limit the use of these things so >that these performance issues are minimized. I guess my bottom line is >that this seems to be a SIP problem and a proper design approach would >be to solve it in SIP. > > The point I would like to notice is that accepting STUN requests on the same port as SIP is already common practice for many implementations willing to support NAT traversal... The problem this draft is addressing is a NAT traversal problem (more than a "SIP problem"), so, reusing what is already existing to pass NATS seems fair.. Following your points, double CR/LF and STUN are "hacks", so you would prefer to solve a SIP problem with SIP: that means, for instance, using OPTION request. Seems fine, but that's really a concern because OPTION would have a *much* more bigger impact on performances, since it mandates to parse completely a message, it creates a SIP Message in memory and a SIP transaction... From the implementation point of view, this is in fact very common to make a "protocol switch" looking at few bytes of a received message: as an illustration, when handling SIP compressed messages with SIGCOMP, we are just looking at the SIGCOMP prefix at the beginning of the message to decide if we should try to decompress it... >FM > > >On Tue, 2006-02-14 at 09:09 -0500, Jonathan Rosenberg wrote: > > >>The model that is described in sip-outbound is that the proxy listens on >>port 5060 for messages. Messages can arrive formatted either as SIP, or >>as STUN. It is essential for the nat traversal properties that the >>keepalives be sent to the same port as the SIP signaling; without that, >>you will not get traversal through symmetric NAT or similar firewalls. >> >>This does in fact mean that your parser needs to be modified so that it >>first detects whether the message is sip or stun, and then sends it to >>the right code module appropriately. This is easily doable, and not that >>complicated. It is not beautiful, but engineering is about making >>tradeoffs. Here, the ENORMOUS cost of SIP message processing relative to >>stun, combined with the frequency of the keepalives, argues in favor of >>this tradeoff. >> >>I will further note that a "modified PING message", or any other kind of >>SIP message processing that does not follow SIP semantics as defined in >>RFC 3261, is effectively identical to the multiple-protocol mechanism of >>running STUN and SIP on the same port. You'll need to figure out which >>protocol it is (SIP or modified SIP), and send the request to the right >>code path appropirately. >> >>Another thing to note on disambiguation. A fairly major revision of stun >>is coming which is going to make it much clearer about how it is >>applicable to these types of problems. One of the changes that will be >>in the draft is the usage of a "magic cookie", similar to the via branch >>cookie, that occupies some of the bits in the STUN transaction ID. This >>means that there is a well known sequence of characters in a fixed >>position in every single stun message. This makes it trivial to >>differentiate stun from anything else. >> >>Thanks, >>Jonathan R. >> >> >>vikram.agarwal@flextronicssoftware.com wrote: >> >> >> >>>assume that the stun server is the next hop after the NAT to support the >>>symmetric NAT. >>> >>>UA - > NAT -> STUN SERVER -> PROXY. >>> >>>Now, if a SIP message arrives then the STUN Server has to distinguish >>>between a STUN or a SIP request and then has to send the sip message to >>>the Proxy. i.e. do we also want STUN to act as a proxy for sip requests? >>>Any message from UA will traverse thru NAT and then STUN and then Proxy >>>( if sip message). Ortherwise, as hisham has pointed we need to have to >>>hack your SIP parser to distinguish between SIP and STUN messages. Both, >>>the sip message and Proxy stack has to be listening on the same port. >>> >>>Regards, >>>--Vikram. >>> >>>Inactive hide details for Hisham Khartabil >>>Hisham Khartabil >>> >>> >>> *Hisham Khartabil * >>> Sent by: sip-bounces@ietf.org >>> >>> 02/14/2006 07:08 PM >>> >>> >>> >>>To >>> >>>Thomas Leseney >>> >>>cc >>> >>>"sip@ietf.org List" >>> >>>Subject >>> >>>Re: [Sip] Outbound and STUN Keep Alive >>> >>> >>> >>> >>> >>>On Feb 14, 2006, at 2:07 PM, Thomas Leseney wrote: >>> >>> > Dear Hisham, >>> > >>> > STUN usually run on port 3478. >>> >>>Not in this case :) You are using stun to keep sip port bindings open. >>> >>>Hisham >>> >>> > http://www.iana.org/assignments/port-numbers >>> > >>> > Regards, >>> > >>> > Thomas >>> > >>> > >>> > Hisham Khartabil wrote: >>> > >>> >> >>> >> On Feb 14, 2006, at 11:29 AM, Chris Boulton wrote: >>> >> >>> >>> >>> >>> If Cullen is right >>> >>> >>> >>> [Chris Boulton]Dean - what do you mean if :-). >>> >>> >>> >>> and the STUN work takes 1/10th of OPTIONS (or less), >>> >>> then we'd clearly have an advantage in favor of STUN. >>> >>> >>> >>> [Chris Boulton] I also feel that anything that helps promote the use >>> >>> and >>> >>> deployment of STUN in out networks is a good thing and should be >>> >>> encouraged. IMHO it fits and is far more elegant than the other >>> >>> solutions + has all the benefits previously mentioned. Why hack SIP? >>> >> >>> >> >>> >> Because it is not a good design to have 2 protocols run on the same >>> >> port. You will have to hack your SIP parser to distinguish between >>> >> SIP and STUN messages. You will also need to create a horizontal link >>> >> between your SIP stack and STUN module. >>> >> >>> >> Hisham >>> >> >>> >>> Why double CRLF when we have a suitably sensible probing protocol. >>> >>> >>> >>> >>> >>> Information contained in this e-mail and any attachments are >>> >>> intended for the use of the addressee only, and may contain >>> >>> confidential information of Ubiquity Software Corporation. All >>> >>> unauthorized use, disclosure or distribution is strictly prohibited. >>> >>> If you are not the addressee, please notify the sender immediately >>> >>> and destroy all copies of this email. Unless otherwise expressly >>> >>> agreed in writing signed by an officer of Ubiquity Software >>> >>> Corporation, nothing in this communication shall be deemed to be >>> >>> legally binding. 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 >>> >>> >>> >> >>> >> >>> >> _______________________________________________ >>> >> 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 >>> >>> >>> >>>*********************** FSS-Unclassified *********************** >>> >>> >>>------------------------------------------------------------------------ >>> >>>_______________________________________________ >>>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 sip-bounces@ietf.org Tue Feb 14 10:29:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9271-0006mM-M1; Tue, 14 Feb 2006 10:29:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F926y-0006m0-PJ for sip@megatron.ietf.org; Tue, 14 Feb 2006 10:29:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04682 for ; Tue, 14 Feb 2006 10:27:18 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F92Ko-0005eO-7D for sip@ietf.org; Tue, 14 Feb 2006 10:43:22 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 14 Feb 2006 07:28:54 -0800 X-IronPort-AV: i="4.02,114,1139212800"; d="scan'208"; a="1776266573:sNHT114663414" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k1EFSsc1021373; Tue, 14 Feb 2006 07:28:54 -0800 (PST) Received: from 10.21.98.95 ([10.21.98.95]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 14 Feb 2006 15:28:53 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Tue, 14 Feb 2006 07:29:14 -0800 Subject: Re: [Sip] Outbound and STUN Keep Alive From: Cullen Jennings To: , Jonathan Rosenberg Message-ID: Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcYxe2kPp6oWHp1uEdqXIgARJEEJ/A== In-Reply-To: <1139873125.2635.6.camel@localhost.localdomain> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Just to be clear on how often we are doing this ... At the last IETF folks said we needed to do the ping every 15 seconds. So for a relatively small deployment with 2 million users, we are looking at like 130 thousand transactions per second. This is achievable with one or two STUN servers but is going to take a rack full of proxies to do it with full SIP requests. On 2/13/06 3:25 PM, "Frank W. Miller" wrote: > > > Actually, I would make the opposite argument. Given the frequency with > which you are going to do this, you basically don't care how much > overhead there is associated with it. > > If its treated like just another end-to-end NIT, most implementations > will have a very simple time adding it. All the machinery to do it is > already there. > > Double CRLF sounds like a hack to me. We all know there are long > periods of time in which signaling traffic might not be flowing. We > also know that there is at least one very good reason to have periodic > signaling traffic occur. I would propose that we just add a PING > message to handle that. Maybe I'll even throw together a strawman > proposal for it, it should be fairly trivial to do. > > FM > > > On Mon, 2006-02-13 at 16:12 -0500, Jonathan Rosenberg wrote: >> The problem is, once you say its a SIP method, you nede to do ALL of the >> processing associated with any SIP transaction - the parsing, state >> machinery, authentication, proxy-require checks, max-forward checks, and >> so on. Given the frequency with which this message comes, you really, >> really, really want to optimize this. >> >> -Jonathan R. >> >> Hisham Khartabil wrote: >> >>> The advantages of using STUN for this is that it works for all >>> application layer protocols that need a keepalive mechanism for NAT >>> bindings (thats why I suggested privately to Cullen to move this part of >>> the I-D into a separate draft and submit it in BEHAVE). >>> >>> If we want a SIP specific solution, then I would suggest (well, not >>> entirely my idea. It has been suggested before) a new SIP method that >>> achieves what STUN achieves for those NATs that reboot. Something like >>> >>> NATKEEPALIVE >>> >>> The contact in the 200 OK returns the new external port (and IP address) >>> assigned. The only advantage to this is that we do not use the same port >>> for both SIP and STUN and we avoid having to extend parsers to support >>> that and create a link between SIP parsers and STUN parsers. >>> >>> Regards, >>> Hisham >>> >>> On Feb 13, 2006, at 12:34 AM, Cullen Jennings wrote: >>> >>>> There has been a few threads about keep alives in outbound.... I will >>>> start >>>> a thread here. >>>> >>>> For UDP, I think STUN is clearly the best choice. It's the only thing >>>> that >>>> is quick and works when the NAT reboots. >>>> >>>> For TCP, there is the the option to use STUN the same as UDP. >>>> >>>> There might be another solution for TCP. I'll call it the Double CRLF. >>>> Basically the UA sends a CRLF, when the proxy receives this, it must >>>> sends a >>>> CRLF within 1 second. If the UA does not get back the CRLF within 6 >>>> seconds >>>> of sending the first one, it considers the connection dead. >>>> >>>> First questions is, does Double CRLF work? >>>> >>>> Second questions is, given we have to do STUN for UDP, would we want >>>> to do >>>> something different for TCP? >>>> >>>> _______________________________________________ >>>> 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 sip-bounces@ietf.org Tue Feb 14 11:24:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F92ya-0002Eo-TT; Tue, 14 Feb 2006 11:24:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F92yZ-0002Ej-Cn for sip@megatron.ietf.org; Tue, 14 Feb 2006 11:24:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08250 for ; Tue, 14 Feb 2006 11:22:41 -0500 (EST) Received: from celine.siteprotect.com ([64.41.122.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F93CO-0007MM-85 for sip@ietf.org; Tue, 14 Feb 2006 11:38:46 -0500 Received: from [192.168.1.4] (pool-141-157-81-211.balt.east.verizon.net [141.157.81.211]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id k1EGO7b28492; Tue, 14 Feb 2006 10:24:07 -0600 Subject: Re: [Sip] Outbound and STUN Keep Alive From: "Frank W. Miller" To: Cullen Jennings In-Reply-To: References: Content-Type: text/plain Organization: Cornfed Systems, LLC Date: Tue, 14 Feb 2006 11:24:04 -0500 Message-Id: <1139934244.2501.13.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fwmiller@cornfed.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Tue, 2006-02-14 at 07:29 -0800, Cullen Jennings wrote: > Just to be clear on how often we are doing this ... At the last IETF folks > said we needed to do the ping every 15 seconds. So for a relatively small > deployment with 2 million users, we are looking at like 130 thousand > transactions per second. This is achievable with one or two STUN servers but > is going to take a rack full of proxies to do it with full SIP requests. > I've not heard these numbers and they are interesting. However, lets assume that a "rack full of proxies" is 8-10 4U servers. Your at approximately 4x-5x the hardware cost. If we're talking Sparc or PC servers of reasonable quality, we're probably talking an additional $10K, maybe $15K, of server hardware which in a 2 million user deployment is very likely in the noise. The other option of course is to spend some time optimizing your implementation. For example, it seems reasonable to put in a fast path for OPTIONS and/or PING parsing and turnaround. My point here is, double CRLF and port sharing are expedient solutions. The "right thing to do" is to have the protocol that is having the problem solve the problem. IMHO, STUN is for NAT discovery, the protocols that traverse the NAT should be responsible for dealing with the NAT traversal. 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 sip-bounces@ietf.org Tue Feb 14 15:31:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F96q2-0003rP-My; Tue, 14 Feb 2006 15:31:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F96q0-0003qS-BH for sip@megatron.ietf.org; Tue, 14 Feb 2006 15:31:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24733 for ; Tue, 14 Feb 2006 15:30:05 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F973t-00078W-8z for sip@ietf.org; Tue, 14 Feb 2006 15:46:13 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 14 Feb 2006 12:31:44 -0800 X-IronPort-AV: i="4.02,114,1139212800"; d="scan'208"; a="255512568:sNHT35105806" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k1EKVgc1002493; Tue, 14 Feb 2006 12:31:42 -0800 (PST) Received: from 10.21.80.1 ([10.21.80.1]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 14 Feb 2006 20:31:42 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Tue, 14 Feb 2006 12:32:01 -0800 Subject: Re: [Sip] Outbound and STUN Keep Alive From: Cullen Jennings To: Message-ID: Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcYxpbVv9ErXBp2YEdqXIgARJEEJ/A== In-Reply-To: <1139934244.2501.13.camel@localhost.localdomain> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On 2/14/06 8:24 AM, "Frank W. Miller" wrote: > On Tue, 2006-02-14 at 07:29 -0800, Cullen Jennings wrote: >> Just to be clear on how often we are doing this ... At the last IETF folks >> said we needed to do the ping every 15 seconds. So for a relatively small >> deployment with 2 million users, we are looking at like 130 thousand >> transactions per second. This is achievable with one or two STUN servers but >> is going to take a rack full of proxies to do it with full SIP requests. >> > > > I've not heard these numbers and they are interesting. However, lets > assume that a "rack full of proxies" is 8-10 4U servers. Your at > approximately 4x-5x the hardware cost. If we're talking Sparc or PC > servers of reasonable quality, we're probably talking an additional > $10K, maybe $15K, of server hardware which in a 2 million user > deployment is very likely in the noise. I usually mean some crappy low end 1U Linux box with a processor that is about 75% the speed of whatever the fast thing Intel makes is so, to your point, much cheaper than 10k. However, the costs seems to all be operationally not capital - I'm not a service provider but I'm sure some will be willing to comment. When you are talking about 10s of million IM users that all pay exactly zero for the service, people seem to get fairly concerned about the number of servers. I'm generally not a fan of arguments of the form "we could not do the right thing because we had to optimize it to run on a 4Mhz 386 with 160 octets of memory" but in this case, I'm doubtful that protocol elegance is going to win over significant operation const reductions. > > The other option of course is to spend some time optimizing your > implementation. For example, it seems reasonable to put in a fast path > for OPTIONS and/or PING parsing and turnaround. Right - once we decide that we are going to have to optimize something, we start looking at what and what protocol designs could make it easier. Way back a bunch of us when down this path. We firt noted that in a proxy, it looks like over 80% of time processing anything is in SIP stack. So doing anything was going to have to happen underneath the SIP parser. This was a bummer - it means we have to change the SIP stacks. We then considered what would we want that we could parse really fast at the bottom of the stack. A binary encoded TLV record looked really appealing. Not surprisingly, STUN had selected exactly that for more or less the same reasons. > > My point here is, double CRLF and port sharing are expedient solutions. > The "right thing to do" is to have the protocol that is having the > problem solve the problem. IMHO, STUN is for NAT discovery, the > protocols that traverse the NAT should be responsible for dealing with > the NAT traversal. I think I am with you about doing the right thing and making SIP work through NATs. So we go and add a shim underneath the typical SIP parser that can deal with the NAT stuff. It needs to have a PING/PONG style liveness test for TCP and UDP. For UDP it also needs to report the perceived public address and port. It needs to be fast and deal with high volume of requests. If you go and design something to meet these requirements, would you come back with anything that was different (in a way that was better) that STUN? _______________________________________________ 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 sip-bounces@ietf.org Tue Feb 14 16:16:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F97UL-0003TL-0k; Tue, 14 Feb 2006 16:13:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F97UI-0003T6-KZ for sip@megatron.ietf.org; Tue, 14 Feb 2006 16:13:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02128 for ; Tue, 14 Feb 2006 16:11:44 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F97iA-0001qY-Gz for sip@ietf.org; Tue, 14 Feb 2006 16:27:51 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 14 Feb 2006 13:13:20 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1ELDBjt010604; Tue, 14 Feb 2006 13:13:19 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Feb 2006 16:13:10 -0500 Received: from [192.168.1.101] ([10.86.242.244]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Feb 2006 16:13:10 -0500 Message-ID: <43F247E5.7040708@cisco.com> Date: Tue, 14 Feb 2006 16:13:09 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: fwmiller@cornfed.com Subject: Re: [Sip] Outbound and STUN Keep Alive References: <1139934244.2501.13.camel@localhost.localdomain> In-Reply-To: <1139934244.2501.13.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Feb 2006 21:13:10.0601 (UTC) FILETIME=[756EEB90:01C631AB] X-Spam-Score: 2.2 (++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Actually, STUN is for everything BUT NAT discovery these days. As you may know, a revision of RFC3489 has been under development in behave for some time. One of the major changes we made almost a year back was to remove the entire NAT discovery and NAT type classification from STUN. It has been found to be unreliable, brittle, and a poor solution for many reasons that are well documented. As such, the draft is now focusing on a toolkit-like approach for nat traversal. We have been using STUN in ways that are a bit different than its original nat-type detection, including with ICE (where its muxed with RTP for the same reasons we mux with SIP here), and for address allocation from servers without the type detection. -Jonathan R. Frank W. Miller wrote: > My point here is, double CRLF and port sharing are expedient solutions. > The "right thing to do" is to have the protocol that is having the > problem solve the problem. IMHO, STUN is for NAT discovery, the > protocols that traverse the NAT should be responsible for dealing with > the NAT traversal. > > FM > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.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 sip-bounces@ietf.org Tue Feb 14 16:18:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F97Z0-0002BZ-RY; Tue, 14 Feb 2006 16:18:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F97Yz-0002BS-3S for sip@megatron.ietf.org; Tue, 14 Feb 2006 16:18:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02846 for ; Tue, 14 Feb 2006 16:16:35 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F97mn-00029l-TM for sip@ietf.org; Tue, 14 Feb 2006 16:32:42 -0500 Received: from [192.168.2.101] (ams3-dmznat-ext1.cisco.com [64.103.37.2]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1ELIEZt021125 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 14 Feb 2006 15:18:16 -0600 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5931F50E-B733-44F4-BBC8-9F6DD9A13DB3@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Tue, 14 Feb 2006 15:18:37 -0600 To: Cullen Jennings X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , fwmiller@cornfed.com Subject: [Sip] Outbound and STUN -- READ THE DRAFT PLEASE X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I've noticed a common thread in this discussion about SIP and STUN. Lots of people commenting on it don't understand WHY we're talking about it, so it sounds strange to them. It might well BE strange, but it helps to have the background. That's ok. It's why we write drafts. And why we read them. The topic under discussion is in the "Outbound" draft: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-01.txt Keepalive requirements are discussed in section 3.5. Detecting flow failures is discussed in section 4.2 Processing of STUN requests in parallel with SIP is discussed in section 7.1 -- 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 sip-bounces@ietf.org Tue Feb 14 18:06:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F99Fc-0007QG-3O; Tue, 14 Feb 2006 18:06:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F99Fa-0007PE-Dh for sip@megatron.ietf.org; Tue, 14 Feb 2006 18:06:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10446 for ; Tue, 14 Feb 2006 18:04:40 -0500 (EST) From: fwmiller@cornfed.com Received: from [66.113.136.12] (helo=smapp01.siteprotect.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F99TO-0005m5-NH for sip@ietf.org; Tue, 14 Feb 2006 18:20:49 -0500 Received: from smapp01.siteprotect.com (localhost [127.0.0.1]) by smapp01.siteprotect.com (8.11.6/8.11.6) with ESMTP id k1EN63n07040; Tue, 14 Feb 2006 17:06:03 -0600 Date: Tue, 14 Feb 2006 17:06:03 -0600 Message-Id: <200602142306.k1EN63n07040@smapp01.siteprotect.com> To: "Dean Willis" , "Cullen Jennings" X-Spam-Score: 0.3 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: "sip@ietf.org" , fwmiller@cornfed.com Subject: [Sip] RE: Outbound and STUN -- READ THE DRAFT PLEASE X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Well, I'll throw this out for fun. I've read the draft as commanded! Awhile ago, I was involved in writing up the IAX2 draft. One of the really interesting things about IAX2 is that it multiplexes the media and the signaling on a single UDP port (in this way its basically ISDN for IP, where port number == T-1 timeslot). If we're going to open Pandora's box here and run multiple protocols through the same port, why not assemble RTP and SIP on the same port? It would basically do away with all this NAT traversal nonsense. We could make the first octet of the message a "call number" where there was one reserved for signaling. That way you could multiplex lots of different media streams through it as well. FM ------------------------------------------------ On Tue, 14 Feb 2006 15:18:37 -0600, Dean Willis wrote: > > I've noticed a common thread in this discussion about SIP and STUN. > Lots of people commenting on it don't understand WHY we're talking > about it, so it sounds strange to them. It might well BE strange, but > it helps to have the background. > > That's ok. It's why we write drafts. And why we read them. > > The topic under discussion is in the "Outbound" draft: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-01.txt > > Keepalive requirements are discussed in section 3.5. > > Detecting flow failures is discussed in section 4.2 > > Processing of STUN requests in parallel with SIP is discussed in > section 7.1 > > -- > 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 sip-bounces@ietf.org Tue Feb 14 20:46:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Bkh-0008Rn-J4; Tue, 14 Feb 2006 20:46:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Bke-0008Qd-Oz for sip@megatron.ietf.org; Tue, 14 Feb 2006 20:46:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25074 for ; Tue, 14 Feb 2006 20:44:53 -0500 (EST) Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9ByY-000450-MS for sip@ietf.org; Tue, 14 Feb 2006 21:01:04 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUP00MOWH48FL@szxga03-in.huawei.com> for sip@ietf.org; Wed, 15 Feb 2006 09:50:32 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUP00L63H47CO@szxga03-in.huawei.com> for sip@ietf.org; Wed, 15 Feb 2006 09:50:32 +0800 (CST) Received: from w39649a ([10.76.176.178]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IUP001HMHCT0G@szxml02-in.huawei.com> for sip@ietf.org; Wed, 15 Feb 2006 09:55:49 +0800 (CST) Date: Wed, 15 Feb 2006 09:43:29 +0800 From: Xiao Wang Subject: [SIP] New I-D: A method to Batch Subscriptions Refreshment To: sip@ietf.org Message-id: <014b01c631d1$3b9bf400$b2b04c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: 746e7c8096e71e3815c27253c4c3edc6 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0606361789==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0606361789== Content-type: multipart/alternative; boundary="Boundary_(ID_l5lPi/JgjvZzLXWRlmwPgw)" This is a multi-part message in MIME format. --Boundary_(ID_l5lPi/JgjvZzLXWRlmwPgw) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi, all A new ID about A method to Batch Subscriptions Refreshment in SIP is available now. Please kindly give your comments. I'm really appreciation your comments. Best regards, Xiao ---------------------------------------------------------------------------- ----------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A method to Batch Subscriptions Refreshment Author(s) : X. Wang Filename : draft-wang-sip-brs-00.txt Pages : 20 Date : 2006-2-14 This document presents an extension to the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for refreshing batch subscriptions by a message. Subscriber send a message to refresh many subscriptions, and these subscriptions may be in a dialog or in several different dialogs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-wang-sip-brs-00.txt --Boundary_(ID_l5lPi/JgjvZzLXWRlmwPgw) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

Hi, all

         A new ID about  A method to Batch Subscriptions Refreshment

    in SIP is available now.

 

    Please kindly give your comments. I'm really appreciation your comments.

 

Best regards,

 

Xiao

 

 ---------------------------------------------------------------------------------------------

A New Internet-Draft is available from the on-line Internet-Drafts directories.

 

 

         Title           : A method to Batch Subscriptions Refreshment

 

         Author(s)  : X. Wang

         Filename : draft-wang-sip-brs-00.txt

         Pages                : 20

         Date          : 2006-2-14

        

   This document presents an extension to the Session Initiation

   Protocol (SIP)-Specific Event Notification mechanism for refreshing

   batch subscriptions by a message.  Subscriber send a message to

   refresh many subscriptions, and these subscriptions may be in a

   dialog or in several different dialogs.

 

 

A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-wang-sip-brs-00.txt

 

--Boundary_(ID_l5lPi/JgjvZzLXWRlmwPgw)-- --===============0606361789== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0606361789==-- From sip-bounces@ietf.org Wed Feb 15 08:16:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9MVl-0007Hc-OQ; Wed, 15 Feb 2006 08:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9MVj-0007HX-Gp for sip@megatron.ietf.org; Wed, 15 Feb 2006 08:15:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07754 for ; Wed, 15 Feb 2006 08:14:12 -0500 (EST) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9Mjk-0001C5-Fn for sip@ietf.org; Wed, 15 Feb 2006 08:30:29 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 0540A194480 for ; Wed, 15 Feb 2006 14:15:49 +0100 (CET) Received: from [192.168.1.58] ([192.168.1.58]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Feb 2006 14:14:34 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <96836819307c1d7df95db2a8b8035aea@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Wed, 15 Feb 2006 14:16:05 +0100 To: Cullen Jennings X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 15 Feb 2006 13:14:34.0063 (UTC) FILETIME=[C374B5F0:01C63231] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is all theory and guesstimates. We'll try to prototype these things and get back to the list with hard numbers to prove or disprove the 2 theories. If anyone willing to co-operate on this, please contact me. Regards, Hisham On Feb 14, 2006, at 9:32 PM, Cullen Jennings wrote: > On 2/14/06 8:24 AM, "Frank W. Miller" wrote: > >> On Tue, 2006-02-14 at 07:29 -0800, Cullen Jennings wrote: >>> Just to be clear on how often we are doing this ... At the last IETF >>> folks >>> said we needed to do the ping every 15 seconds. So for a relatively >>> small >>> deployment with 2 million users, we are looking at like 130 thousand >>> transactions per second. This is achievable with one or two STUN >>> servers but >>> is going to take a rack full of proxies to do it with full SIP >>> requests. >>> >> >> >> I've not heard these numbers and they are interesting. However, lets >> assume that a "rack full of proxies" is 8-10 4U servers. Your at >> approximately 4x-5x the hardware cost. If we're talking Sparc or PC >> servers of reasonable quality, we're probably talking an additional >> $10K, maybe $15K, of server hardware which in a 2 million user >> deployment is very likely in the noise. > > I usually mean some crappy low end 1U Linux box with a processor that > is > about 75% the speed of whatever the fast thing Intel makes is so, to > your > point, much cheaper than 10k. > > However, the costs seems to all be operationally not capital - I'm not > a > service provider but I'm sure some will be willing to comment. When > you are > talking about 10s of million IM users that all pay exactly zero for the > service, people seem to get fairly concerned about the number of > servers. > I'm generally not a fan of arguments of the form "we could not do the > right > thing because we had to optimize it to run on a 4Mhz 386 with 160 > octets of > memory" but in this case, I'm doubtful that protocol elegance is going > to > win over significant operation const reductions. > >> >> The other option of course is to spend some time optimizing your >> implementation. For example, it seems reasonable to put in a fast >> path >> for OPTIONS and/or PING parsing and turnaround. > > Right - once we decide that we are going to have to optimize > something, we > start looking at what and what protocol designs could make it easier. > Way > back a bunch of us when down this path. We firt noted that in a proxy, > it > looks like over 80% of time processing anything is in SIP stack. So > doing > anything was going to have to happen underneath the SIP parser. This > was a > bummer - it means we have to change the SIP stacks. We then considered > what > would we want that we could parse really fast at the bottom of the > stack. A > binary encoded TLV record looked really appealing. Not surprisingly, > STUN > had selected exactly that for more or less the same reasons. > >> >> My point here is, double CRLF and port sharing are expedient >> solutions. >> The "right thing to do" is to have the protocol that is having the >> problem solve the problem. IMHO, STUN is for NAT discovery, the >> protocols that traverse the NAT should be responsible for dealing with >> the NAT traversal. > > I think I am with you about doing the right thing and making SIP work > through NATs. So we go and add a shim underneath the typical SIP parser > that can deal with the NAT stuff. It needs to have a PING/PONG style > liveness test for TCP and UDP. For UDP it also needs to report the > perceived > public address and port. It needs to be fast and deal with high volume > of > requests. > > If you go and design something to meet these requirements, would you > come > back with anything that was different (in a way that was better) that > STUN? > _______________________________________________ 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 sip-bounces@ietf.org Wed Feb 15 09:51:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Nzo-0003LG-K9; Wed, 15 Feb 2006 09:51:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Nzg-00037N-4O; Wed, 15 Feb 2006 09:51:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14700; Wed, 15 Feb 2006 09:49:12 -0500 (EST) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9ODh-0004n1-J4; Wed, 15 Feb 2006 10:05:31 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k1FEoKbp026995; Wed, 15 Feb 2006 16:50:23 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Feb 2006 16:50:25 +0200 Received: from localhost.localdomain ([172.21.50.42]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 15 Feb 2006 16:50:25 +0200 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id k1FCoJ0T003169; Wed, 15 Feb 2006 14:50:19 +0200 Received: (from ppessi@localhost) by localhost.localdomain (8.13.1/8.13.1/Submit) id k1FCoBg9003168; Wed, 15 Feb 2006 14:50:11 +0200 X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Dean Willis Subject: Re: [Sip] Outbound and STUN Keep Alive 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: <43F18268.60402@softarmor.com> (Dean Willis's message of "Tue, 14 Feb 2006 01:10:32 -0600") References: <43F18268.60402@softarmor.com> Date: Wed, 15 Feb 2006 14:50:11 +0200 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 15 Feb 2006 14:50:25.0125 (UTC) FILETIME=[275B2150:01C6323F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Cullen Jennings , "sip@ietf.org" , sip-bounces@ietf.org, fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean Willis writes: >vikram.agarwal@flextronicssoftware.com wrote: >> will OPTIONS method not work for the same? Instead of sending an CRLF we >> can also send an OPTIONS method to refresh the NAT binding. If i am not >> wrong then OPTIONS method was discared because of the processing of the >> SIP message for keeeping the NAT binding alive. Hence, CRLF was >> considered. But CRLF is not backward compatible i.e. it does not provide >> MAPPED ADDRESS. Now bringing in the PING method would again be introducing >> a SIP message based processing which would lead to poor performance. >We've demonstrated successfully slaying proxies by bombing them with OPTIONS >requests. >Back in the "early days" of dynamicsoft, our first proxies were processing 7 >INVITE/200/ACK/BYE/200 non-authenticated transaction sequences or about 20 >OPTIONS transactions per second. They've of course gotten much faster, but >the proportions have stayed pretty much the same. >So you can see that in models where a typical SIP transaction load might be >5 transactions per hour per node, adding another 60 OPTIONS transactions per >hour per node might reduce your edge-proxy scalability by on the order of >13-1, or roughly a 93% performance hit. That's a big hit. Of course, that is the relative performance hit that you will see on a 100 Mb/s ethernet, which I think is the bottleneck on most SIP servers. You do lot of OPTIONS, you use all you bandwidth receiving OPTIONS, right? ;-) On more serious discussion, you use roughly the same number of packets and system calls to process a STUN request as when processing OPTIONS, The bottleneck is not in the CPU doing SIP or STUN parsing but (hopefully) somewhere else, like your memory bus or network I/O. Both SIP and STUN parser and processing code fit nicely in your cache nowadays, mixed STUN/SIP server losing because it has to fit both SIP and STUN parser code in its cache. Of course, a hypothetical SIP server implemented in Perl and heavily relying in shell scripting might be a different story. --Pekka -- http://sofia-sip.sf.net _______________________________________________ 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 sip-bounces@ietf.org Wed Feb 15 12:05:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Q5a-0004Sn-PJ; Wed, 15 Feb 2006 12:05:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Q5Y-0004ST-Vl for sip@megatron.ietf.org; Wed, 15 Feb 2006 12:05:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12308 for ; Wed, 15 Feb 2006 12:03:26 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9QJb-0007mS-Mp for sip@ietf.org; Wed, 15 Feb 2006 12:19:45 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 15 Feb 2006 09:05:02 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1FH50WF010861; Wed, 15 Feb 2006 09:05:01 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Feb 2006 12:05:00 -0500 Received: from [161.44.55.99] ([161.44.55.99]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Feb 2006 12:05:00 -0500 Message-ID: <43F35F3B.2010306@cisco.com> Date: Wed, 15 Feb 2006 12:04:59 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Pessi Subject: Re: [Sip] Outbound and STUN Keep Alive References: <43F18268.60402@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Feb 2006 17:05:00.0160 (UTC) FILETIME=[F473B000:01C63251] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , "sip@ietf.org" , fwmiller@cornfed.com, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The bandwidth aspect of this is important too. The STUN request in question here is 20 bytes, and the response is 36. A SIP OPTIONS request and response is probably around 300-400 bytes. At a rate of a keepalive every 15 seconds, you end up with 320 bps per subscriber for OPTIONS, and 3.8 bps for STUN (not counting IP/UDP overheads). Its interesting to compare this to 'useful' traffic. Assuming .1 erlangs and a hold time of 3m during the busy hour, you get 5.5e-4 calls per second per subscriber. With a INV/200/ACK BYE/200 sequence, and assuming 1kB for INV/200 and 300B for the others, thats 2.9 kB total per call, and thus 12.76 bps per subscriber. As a consequence, with the OPTIONS approach, you have a bandwidth overhead of 320/12.76 which is 25, or 2500%!!!! WIth STUN, this is a still painful but palatable 3.8/12.76 = 30%. To put that in perspective, a server supporting 100k subscribers would require 1.2 Mbps access for useful signaling, and an additional 32 Mbps just for the useless OPTIONS message. To make sure you are nowhere near (i.e. not within 50%) of link saturation, this comes close enough to the limit of 100M ethernet that you'd probably need to jump to GiGE, whereas 10M ethernet would suffice with STUN keepalives. -Jonathan R. Pekka Pessi wrote: > Dean Willis writes: > >>vikram.agarwal@flextronicssoftware.com wrote: >> >>>will OPTIONS method not work for the same? Instead of sending an CRLF we >>>can also send an OPTIONS method to refresh the NAT binding. If i am not >>>wrong then OPTIONS method was discared because of the processing of the >>>SIP message for keeeping the NAT binding alive. Hence, CRLF was >>>considered. But CRLF is not backward compatible i.e. it does not provide >>>MAPPED ADDRESS. Now bringing in the PING method would again be introducing >>>a SIP message based processing which would lead to poor performance. > > >>We've demonstrated successfully slaying proxies by bombing them with OPTIONS >>requests. > > >>Back in the "early days" of dynamicsoft, our first proxies were processing 7 >>INVITE/200/ACK/BYE/200 non-authenticated transaction sequences or about 20 >>OPTIONS transactions per second. They've of course gotten much faster, but >>the proportions have stayed pretty much the same. > > >>So you can see that in models where a typical SIP transaction load might be >>5 transactions per hour per node, adding another 60 OPTIONS transactions per >>hour per node might reduce your edge-proxy scalability by on the order of >>13-1, or roughly a 93% performance hit. That's a big hit. > > > Of course, that is the relative performance hit that you will see > on a 100 Mb/s ethernet, which I think is the bottleneck on most > SIP servers. You do lot of OPTIONS, you use all you bandwidth > receiving OPTIONS, right? ;-) > > On more serious discussion, you use roughly the same number of > packets and system calls to process a STUN request as when > processing OPTIONS, The bottleneck is not in the CPU doing SIP or > STUN parsing but (hopefully) somewhere else, like your memory bus > or network I/O. Both SIP and STUN parser and processing code fit > nicely in your cache nowadays, mixed STUN/SIP server losing > because it has to fit both SIP and STUN parser code in its cache. > > Of course, a hypothetical SIP server implemented in Perl and > heavily relying in shell scripting might be a different story. > > --Pekka > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.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 sip-bounces@ietf.org Wed Feb 15 17:48:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9VRp-0007KP-5a; Wed, 15 Feb 2006 17:48:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9VRn-0007JG-C0 for sip@megatron.ietf.org; Wed, 15 Feb 2006 17:48:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15358 for ; Wed, 15 Feb 2006 17:46:44 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56] helo=zrtps0kp.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9Vfp-0005eM-IX for sip@ietf.org; Wed, 15 Feb 2006 18:03:06 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k1FMm9X01934; Wed, 15 Feb 2006 17:48:10 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Outbound and STUN Keep Alive Date: Wed, 15 Feb 2006 16:48:08 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF06CE3879@zrc2hxm0.corp.nortel.com> Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcYwv55rlkOF7blVRXa6Litp22FNWABwgc8g From: "Francois Audet" To: "Hisham Khartabil" , "Cullen Jennings" X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Well, not really. It only works with protocols that magically can be demultiplexed from running on the same port as STUN... > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Hisham Khartabil > Sent: Monday, February 13, 2006 09:02 > To: Cullen Jennings > Cc: sip@ietf.org > Subject: Re: [Sip] Outbound and STUN Keep Alive >=20 >=20 > The advantages of using STUN for this is that it works for all=20 > application layer protocols that need a keepalive mechanism for NAT=20 > bindings (thats why I suggested privately to Cullen to move this part=20 > of the I-D into a separate draft and submit it in BEHAVE). >=20 > If we want a SIP specific solution, then I would suggest (well, not=20 > entirely my idea. It has been suggested before) a new SIP method that=20 > achieves what STUN achieves for those NATs that reboot. Something like >=20 > NATKEEPALIVE >=20 > The contact in the 200 OK returns the new external port (and IP=20 > address) assigned. The only advantage to this is that we do=20 > not use the=20 > same port for both SIP and STUN and we avoid having to extend parsers=20 > to support that and create a link between SIP parsers and=20 > STUN parsers. >=20 > Regards, > Hisham >=20 > On Feb 13, 2006, at 12:34 AM, Cullen Jennings wrote: >=20 > > There has been a few threads about keep alives in=20 > outbound.... I will > > start > > a thread here. > > > > For UDP, I think STUN is clearly the best choice. It's the=20 > only thing > > that > > is quick and works when the NAT reboots. > > > > For TCP, there is the the option to use STUN the same as UDP. > > > > There might be another solution for TCP. I'll call it the=20 > Double CRLF.=20 > > Basically the UA sends a CRLF, when the proxy receives=20 > this, it must=20 > > sends a CRLF within 1 second. If the UA does not get back the CRLF=20 > > within 6 seconds > > of sending the first one, it considers the connection dead. > > > > First questions is, does Double CRLF work? > > > > Second questions is, given we have to do STUN for UDP, would we want > > to do > > something different for TCP? > > > > _______________________________________________ > > 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 > _______________________________________________ > 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 _______________________________________________ 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 sip-bounces@ietf.org Wed Feb 15 18:12:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Vom-0007G4-EJ; Wed, 15 Feb 2006 18:12:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Vok-0007DS-Dk for sip@megatron.ietf.org; Wed, 15 Feb 2006 18:12:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16967 for ; Wed, 15 Feb 2006 18:10:27 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9W2q-0006Tz-C8 for sip@ietf.org; Wed, 15 Feb 2006 18:26:49 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 15 Feb 2006 18:12:04 -0500 X-IronPort-AV: i="4.02,118,1139202000"; d="scan'208"; a="82492627:sNHT32407604" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1FNBqPU018360; Wed, 15 Feb 2006 18:12:01 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Feb 2006 18:11:57 -0500 Received: from [161.44.55.149] ([161.44.55.149]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Feb 2006 18:11:56 -0500 Message-ID: <43F3B53C.9090204@cisco.com> Date: Wed, 15 Feb 2006 18:11:56 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] Outbound and STUN Keep Alive References: <1ECE0EB50388174790F9694F77522CCF06CE3879@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF06CE3879@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Feb 2006 23:11:56.0657 (UTC) FILETIME=[374E8610:01C63285] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Given the presence of the magic cookie in each stun request, can you give an example of a protocol where such demuxing could not be done? -Jonathan R. Francois Audet wrote: > Well, not really. > > It only works with protocols that magically can be demultiplexed > from running on the same port as STUN... > > >>-----Original Message----- >>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >>Behalf Of Hisham Khartabil >>Sent: Monday, February 13, 2006 09:02 >>To: Cullen Jennings >>Cc: sip@ietf.org >>Subject: Re: [Sip] Outbound and STUN Keep Alive >> >> >>The advantages of using STUN for this is that it works for all >>application layer protocols that need a keepalive mechanism for NAT >>bindings (thats why I suggested privately to Cullen to move this part >>of the I-D into a separate draft and submit it in BEHAVE). >> >>If we want a SIP specific solution, then I would suggest (well, not >>entirely my idea. It has been suggested before) a new SIP method that >>achieves what STUN achieves for those NATs that reboot. Something like >> >>NATKEEPALIVE >> >>The contact in the 200 OK returns the new external port (and IP >>address) assigned. The only advantage to this is that we do >>not use the >>same port for both SIP and STUN and we avoid having to extend parsers >>to support that and create a link between SIP parsers and >>STUN parsers. >> >>Regards, >>Hisham >> >>On Feb 13, 2006, at 12:34 AM, Cullen Jennings wrote: >> >> >>>There has been a few threads about keep alives in >> >>outbound.... I will >> >>>start >>>a thread here. >>> >>>For UDP, I think STUN is clearly the best choice. It's the >> >>only thing >> >>>that >>>is quick and works when the NAT reboots. >>> >>>For TCP, there is the the option to use STUN the same as UDP. >>> >>>There might be another solution for TCP. I'll call it the >> >>Double CRLF. >> >>>Basically the UA sends a CRLF, when the proxy receives >> >>this, it must >> >>>sends a CRLF within 1 second. If the UA does not get back the CRLF >>>within 6 seconds >>>of sending the first one, it considers the connection dead. >>> >>>First questions is, does Double CRLF work? >>> >>>Second questions is, given we have to do STUN for UDP, would we want >>>to do >>>something different for TCP? >>> >>>_______________________________________________ >>>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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.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 sip-bounces@ietf.org Wed Feb 15 18:51:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9WR7-0003Gy-BD; Wed, 15 Feb 2006 18:51:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9WR4-0003Fc-RR for sip@megatron.ietf.org; Wed, 15 Feb 2006 18:51:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19039 for ; Wed, 15 Feb 2006 18:50:03 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9Wf7-0007eX-Mp for sip@ietf.org; Wed, 15 Feb 2006 19:06:26 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1FNplR2028070 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 15 Feb 2006 17:51:48 -0600 In-Reply-To: <43F3B53C.9090204@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF06CE3879@zrc2hxm0.corp.nortel.com> <43F3B53C.9090204@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Wed, 15 Feb 2006 17:51:41 -0600 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , sip@ietf.org, Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 15, 2006, at 5:11 PM, Jonathan Rosenberg wrote: > Given the presence of the magic cookie in each stun request, can > you give an example of a protocol where such demuxing could not be > done? Any protocol where the magic cookie could be valid application data. Somewhere down in here is a requirement for a "NAT Traversing Protocol" that provides arbitrary demux over a shared channel. Oh wait, that's called a TLS VPN. -- 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 sip-bounces@ietf.org Wed Feb 15 20:23:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Xrc-0006GR-VZ; Wed, 15 Feb 2006 20:23:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Xra-0006Be-IC for sip@megatron.ietf.org; Wed, 15 Feb 2006 20:23:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02170 for ; Wed, 15 Feb 2006 20:21:30 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9Y5d-0004Zb-Vj for sip@ietf.org; Wed, 15 Feb 2006 20:37:54 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k1G1MpV26386; Wed, 15 Feb 2006 20:22:51 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Outbound and STUN Keep Alive Date: Wed, 15 Feb 2006 19:22:34 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF06CE3A51@zrc2hxm0.corp.nortel.com> Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcYyMtQQFhCJuPVRTMaN4Qdhsi9uagAYfslQ From: "Francois Audet" To: "Hisham Khartabil" , "Cullen Jennings" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Exactly my view. I really don't see why processing a PING method would be any more resource-intensive because of "parsing" or whatever than processing a STUN message (binary) that happens to run on the same port the rest of the SIP protocol runs on. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Hisham Khartabil > Sent: Wednesday, February 15, 2006 05:16 > To: Cullen Jennings > Cc: sip@ietf.org; fwmiller@cornfed.com > Subject: Re: [Sip] Outbound and STUN Keep Alive >=20 >=20 > This is all theory and guesstimates. We'll try to prototype these=20 > things and get back to the list with hard numbers to prove or=20 > disprove=20 > the 2 theories. If anyone willing to co-operate on this,=20 > please contact=20 > me. >=20 > Regards, > 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 sip-bounces@ietf.org Wed Feb 15 20:52:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9YJr-0000BO-Av; Wed, 15 Feb 2006 20:52:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9YJp-0000Ah-QR for sip@megatron.ietf.org; Wed, 15 Feb 2006 20:52:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03697 for ; Wed, 15 Feb 2006 20:50:42 -0500 (EST) From: fwmiller@cornfed.com Received: from [66.113.136.12] (helo=smapp01.siteprotect.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9YXw-0005OU-WC for sip@ietf.org; Wed, 15 Feb 2006 21:07:06 -0500 Received: from smapp01.siteprotect.com (localhost [127.0.0.1]) by smapp01.siteprotect.com (8.11.6/8.11.6) with ESMTP id k1G1qCn00509; Wed, 15 Feb 2006 19:52:12 -0600 Date: Wed, 15 Feb 2006 19:52:12 -0600 Message-Id: <200602160152.k1G1qCn00509@smapp01.siteprotect.com> To: "Francois Audet" , "Hisham Khartabil" Subject: RE: [Sip] Outbound and STUN Keep Alive X-Spam-Score: 0.3 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sip@ietf.org, fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I posted the PING draft to the IETF site for posterity. I mailed it tonite, not sure when it will show up on the site. FM ------------------------------------------------ On Wed, 15 Feb 2006 19:22:34 -0600, "Francois Audet" wrote: > Exactly my view. > > I really don't see why processing a PING method would be any more > resource-intensive because of "parsing" or whatever than processing > a STUN message (binary) that happens to run on the same port > the rest of the SIP protocol runs on. > > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of Hisham Khartabil > > Sent: Wednesday, February 15, 2006 05:16 > > To: Cullen Jennings > > Cc: sip@ietf.org; fwmiller@cornfed.com > > Subject: Re: [Sip] Outbound and STUN Keep Alive > > > > > > This is all theory and guesstimates. We'll try to prototype these > > things and get back to the list with hard numbers to prove or > > disprove > > the 2 theories. If anyone willing to co-operate on this, > > please contact > > me. > > > > Regards, > > 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 > _______________________________________________ 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 sip-bounces@ietf.org Wed Feb 15 21:19:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9YkO-00080x-E1; Wed, 15 Feb 2006 21:19:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9YkM-0007yZ-Im for sip@megatron.ietf.org; Wed, 15 Feb 2006 21:19:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06391 for ; Wed, 15 Feb 2006 21:18:06 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9YyQ-0006yJ-Vx for sip@ietf.org; Wed, 15 Feb 2006 21:34:31 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1G2JnvV028623 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 15 Feb 2006 20:19:51 -0600 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF06CE3A51@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF06CE3A51@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Wed, 15 Feb 2006 20:19:42 -0600 To: Francois Audet X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , sip@ietf.org, fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 15, 2006, at 7:22 PM, Francois Audet wrote: > I really don't see why processing a PING method would be any more > resource-intensive because of "parsing" or whatever than processing > a STUN message (binary) that happens to run on the same port > the rest of the SIP protocol runs on. Well, I'm sure there's at least SOME difference. How much remains to be determined. I have a preliminary report from one of the performance people who's working with Jonathan. He did some saturation testing comparing the STUN operation to receiving, discarding, and 200oking a short MESSAGE request (roughly analogous to how PING processing would work if it were heavily optimized). These initial results show at least a 3x difference, much of which is attributable to the parsing overhead. Once the MESSAGE request is liberated from its framing, it still has to be parsed enough to recognize it as a discardable message and figure out where to send the 200 OK response (which requires parsing Via header fields). Then the 200 OK response has to be constructed, which is pretty straightforward but still requires several times more string operations than the STUN response does. This testing was done on a very mature Java stack implementation, the SIP part of which has been highly optimized. Now I'll also have to say I don't completely trust these results -- they're preliminary, I have doubts about the STUN optimization, and I think we were hitting interface saturation on a 100 M ethernet. My gut feel is that the gap will widen above 3x as the testing (and implementation) gets better. Is 3x significant? I suppose that depends on your business model and per-box overhead. It also changes the inflection points at which one has to go from single or paired-box models to high-availability clustering approaches with state replication, and THAT is a significant delta, if you;re not already past it. -- 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 sip-bounces@ietf.org Wed Feb 15 22:07:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9ZUf-0007qs-FO; Wed, 15 Feb 2006 22:07:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9ZUc-0007n6-JR for sip@megatron.ietf.org; Wed, 15 Feb 2006 22:07:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09573 for ; Wed, 15 Feb 2006 22:05:54 -0500 (EST) From: fwmiller@cornfed.com Received: from [66.113.136.12] (helo=smapp01.siteprotect.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9Zik-00005q-AZ for sip@ietf.org; Wed, 15 Feb 2006 22:22:19 -0500 Received: from smapp01.siteprotect.com (localhost [127.0.0.1]) by smapp01.siteprotect.com (8.11.6/8.11.6) with ESMTP id k1G37Pn04347; Wed, 15 Feb 2006 21:07:25 -0600 Date: Wed, 15 Feb 2006 21:07:25 -0600 Message-Id: <200602160307.k1G37Pn04347@smapp01.siteprotect.com> To: "Dean Willis" , "Francois Audet" Subject: Re: [Sip] Outbound and STUN Keep Alive X-Spam-Score: 0.3 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Cullen Jennings , sip@ietf.org, fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Couple questions inline... ------------------------------------------------ On Wed, 15 Feb 2006 20:19:42 -0600, Dean Willis wrote: > These initial results show at least a 3x difference, much of which is > attributable to the parsing overhead. Once the MESSAGE request is > liberated from its framing, it still has to be parsed enough to > recognize it as a discardable message and figure out where to send Was a full parser used or on-demand parsing, i.e. did the parser breakup the entire message into all its various fields or was the message parsed piecemeal as necessary to determine what the message was? > very mature Java stack implementation, the SIP part of which has been > highly optimized. May I assume that the Java implementation was run on a Sun JVM? I would be interested in numbers for a C and C++ implementation (I called them out separately on purpose), e.g. a reSIProcate measurement would be interesting for the C++ case. Also, I am assuming that both the SIP and STUN implementations were done in Java and both were run on the same VM? Thanks, 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 sip-bounces@ietf.org Thu Feb 16 00:20:03 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9bYg-0001QW-Rx; Thu, 16 Feb 2006 00:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9bIa-0000Ff-3X for sip@megatron.ietf.org; Thu, 16 Feb 2006 00:03:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14478 for ; Wed, 15 Feb 2006 23:59:56 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9bUv-0003QD-N0 for sip@ietf.org; Thu, 16 Feb 2006 00:16:11 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1G50QUn029175 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 15 Feb 2006 23:00:28 -0600 In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43710CF5372C@zrc2hxm2.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA43710CF5372C@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9E27C426-9C5B-481D-B193-5A391343D968@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Wed, 15 Feb 2006 23:00:19 -0600 To: Brian Stucker X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , sip@ietf.org, Francois Audet , fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 15, 2006, at 10:10 PM, Brian Stucker wrote: > Dean, et. al- > > Keep in mind one thing in your calculations... Parsing a MESSAGE > that is short (which may or may not be a message that needs further > processing) cannot be separated from "service" traffic as easily as > PING. Once I've parsed the request type I immediately know that I'm > dealing with a special case and can shunt processing over to a > separate chunk of code that can ignore much of the message. > This implementation modified the SIP UA for immediate handling of the MESSAGE request. It wasn't being shunted off to an application via the api -- the UA was immediately doing a 200-and-discard sequence. > For instance, here would be a very simple way of parsing a PING: > > 1. Is the request type of the message "PING". If so, then shunt... > 2. In the shunt parser take the original packet the PING came in on > and do the following: > Replace the top of the buffer from "PING sip:xxxyyyzzz... SIP/2.0" > to "SIP/2.0 200". Pad the remainder with white space until you hit > the CRLF that terminates the request URI. > 3. Append the correct header information to bottom of the packet to > identify the source of the request. > 4. Send the packet back from whence it came. > > (Potentially) no data that needs to be copied and nothing other > than the first five characters of the message needs to be parsed. > How can you send a 200 OK without parsing out the Via header fields? How do you get the cseq without parsing that out? -- 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 sip-bounces@ietf.org Thu Feb 16 00:21:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9bIo-0000IR-Ua; Thu, 16 Feb 2006 00:03:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9bIY-0000E7-7c for sip@megatron.ietf.org; Thu, 16 Feb 2006 00:03:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14467 for ; Wed, 15 Feb 2006 23:59:47 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9bUl-0003Pg-Kq for sip@ietf.org; Thu, 16 Feb 2006 00:16:02 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 15 Feb 2006 21:00:08 -0800 X-IronPort-AV: i="4.02,118,1139212800"; d="scan'208"; a="255802273:sNHT31621384" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k1G507QJ002926; Wed, 15 Feb 2006 21:00:07 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Feb 2006 00:00:06 -0500 Received: from [192.168.1.101] ([10.86.242.163]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Feb 2006 00:00:06 -0500 Message-ID: <43F406D6.1070501@cisco.com> Date: Thu, 16 Feb 2006 00:00:06 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: fwmiller@cornfed.com Subject: Re: [Sip] Outbound and STUN Keep Alive References: <200602160307.k1G37Pn04347@smapp01.siteprotect.com> In-Reply-To: <200602160307.k1G37Pn04347@smapp01.siteprotect.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Feb 2006 05:00:06.0384 (UTC) FILETIME=[DA8DE700:01C632B5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , sip@ietf.org, Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The message was parsed piecemeal, and it was on a Sun machine. Both stun and sip in java. It would be good to see some results for resiprocate. I would argue that 3x is already good enough to make this worthwhile. -Jonathan R. fwmiller@cornfed.com wrote: > Couple questions inline... > > ------------------------------------------------ > On Wed, 15 Feb 2006 20:19:42 -0600, Dean Willis wrote: > > >>These initial results show at least a 3x difference, much of which is >>attributable to the parsing overhead. Once the MESSAGE request is >>liberated from its framing, it still has to be parsed enough to >>recognize it as a discardable message and figure out where to send > > > Was a full parser used or on-demand parsing, i.e. did the parser breakup the entire message into all its various fields or was the message parsed piecemeal as necessary to determine what the message was? > > > >>very mature Java stack implementation, the SIP part of which has been >>highly optimized. > > > May I assume that the Java implementation was run on a Sun JVM? I would be interested in numbers for a C and C++ implementation (I called them out separately on purpose), e.g. a reSIProcate measurement would be interesting for the C++ case. > > Also, I am assuming that both the SIP and STUN implementations were done in Java and both were run on the same VM? > > > Thanks, > 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.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 sip-bounces@ietf.org Thu Feb 16 00:50:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9c26-0004KB-Pa; Thu, 16 Feb 2006 00:50:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9c1e-0004I0-Ve for sip@megatron.ietf.org; Thu, 16 Feb 2006 00:49:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14363 for ; Wed, 15 Feb 2006 23:57:58 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9bT1-0003La-TS for sip@ietf.org; Thu, 16 Feb 2006 00:14:13 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 15 Feb 2006 23:58:23 -0500 X-IronPort-AV: i="4.02,118,1139202000"; d="scan'208"; a="82508180:sNHT31226048" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1G4wK6H011310; Wed, 15 Feb 2006 23:58:20 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Feb 2006 23:58:20 -0500 Received: from [192.168.1.101] ([10.86.242.163]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Feb 2006 23:58:19 -0500 Message-ID: <43F4066B.6080005@cisco.com> Date: Wed, 15 Feb 2006 23:58:19 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Outbound and STUN Keep Alive References: <1ECE0EB50388174790F9694F77522CCF06CE3879@zrc2hxm0.corp.nortel.com> <43F3B53C.9090204@cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Feb 2006 04:58:19.0522 (UTC) FILETIME=[9ADC0E20:01C632B5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , sip@ietf.org, Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org It comes down to probabilities. You can make the probability of collision arbitrarily low by increasing the number of bits. Assuming random data in an application protocol, 16 bits is already 1.5e-5 probability of collision. Not good enough? Throw a few more bits in. -Jonathan R. Dean Willis wrote: > > On Feb 15, 2006, at 5:11 PM, Jonathan Rosenberg wrote: > >> Given the presence of the magic cookie in each stun request, can you >> give an example of a protocol where such demuxing could not be done? > > > Any protocol where the magic cookie could be valid application data. > > > Somewhere down in here is a requirement for a "NAT Traversing Protocol" > that provides arbitrary demux over a shared channel. > > Oh wait, that's called a TLS VPN. > > > -- > Dean > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.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 sip-bounces@ietf.org Thu Feb 16 00:52:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9c3s-0004yz-7p; Thu, 16 Feb 2006 00:52:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9c1s-0004I0-VT for sip@megatron.ietf.org; Thu, 16 Feb 2006 00:50:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14326 for ; Wed, 15 Feb 2006 23:57:09 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9bSF-0003KL-RV for sip@ietf.org; Thu, 16 Feb 2006 00:13:24 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1G4ve3E029159 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 15 Feb 2006 22:57:41 -0600 In-Reply-To: <200602160307.k1G37Pn04347@smapp01.siteprotect.com> References: <200602160307.k1G37Pn04347@smapp01.siteprotect.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <88481B91-8CFA-41D0-AC93-EB552F7E8017@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Wed, 15 Feb 2006 22:57:33 -0600 To: fwmiller@cornfed.com X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , sip@ietf.org, Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 15, 2006, at 9:07 PM, fwmiller@cornfed.com wrote: > > > Couple questions inline... > > ------------------------------------------------ > On Wed, 15 Feb 2006 20:19:42 -0600, Dean Willis > wrote: > >> These initial results show at least a 3x difference, much of which is >> attributable to the parsing overhead. Once the MESSAGE request is >> liberated from its framing, it still has to be parsed enough to >> recognize it as a discardable message and figure out where to send > > Was a full parser used or on-demand parsing, i.e. did the parser > breakup the entire message into all its various fields or was the > message parsed piecemeal as necessary to determine what the message > was? > I believe this stuff uses a partial pre-parse followed by demand parsing. Just finding the Vias is an expensive operation. > >> very mature Java stack implementation, the SIP part of which has been >> highly optimized. > > May I assume that the Java implementation was run on a Sun JVM? I > would be interested in numbers for a C and C++ implementation (I > called them out separately on purpose), e.g. a reSIProcate > measurement would be interesting for the C++ case. > Me too. > Also, I am assuming that both the SIP and STUN implementations were > done in Java and both were run on the same VM? I believe so. -- 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 sip-bounces@ietf.org Thu Feb 16 07:48:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9iYZ-0004UJ-BJ; Thu, 16 Feb 2006 07:48:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9iYX-0004UE-IR for sip@megatron.ietf.org; Thu, 16 Feb 2006 07:48:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19030 for ; Thu, 16 Feb 2006 07:46:34 -0500 (EST) Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9imh-0003M7-Mu for sip@ietf.org; Thu, 16 Feb 2006 08:03:04 -0500 Received: from sonusmail02.sonusnet.com (sonusmail02.sonusnet.com [10.128.32.96]) by sonussf1.sonusnet.com (8.13.3/8.13.3) with ESMTP id k1GCm60x018304; Thu, 16 Feb 2006 07:48:06 -0500 x-mimeole: Produced By Microsoft Exchange V6.0.6603.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] Outbound and STUN Keep Alive Date: Thu, 16 Feb 2006 07:48:01 -0500 Message-ID: <05AE95C39E8E2642AF9C04526EDAC414B49A22@sonusmail02.sonusnet.com> Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcYyMtQQFhCJuPVRTMaN4Qdhsi9uagAYfslQABgFlRA= From: "Bharrat, Shaun" To: "Francois Audet" , "Hisham Khartabil" , "Cullen Jennings" X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Audet, Frank: We have in the recent past implemented three refresh variants=20 on an embedded platform: 1. Full parse of REGISTER with an immediate 200 (C stack) 2. "Fast parse" of a REGISTER looking only for To/From/Via/CSeq and sending a register using those fields (again C code) 3. STUN server which only supported the requests without port or address change subrequests (again C code). #3 was almost an order of magnitude better than #1 and about 3 times as fast as #2.=20 So why is #2 slower at all -- unless you have really nifty pattern matching h/w, you have to go through byte-by-byte (at least once) to find the To/From/Via/CSeq. A STUN packet is both tiny and you can quickly skip over irrelevant data. If you do ever end up declaring "you SHOULD use REGISTER, PING, OPTIONS=20 or some other SIP message to do refresh", please don't take away=20 the STUN option from those for whom 3x is a _big_ deal. Thanks and cheers, Shaun Sonus Networks www.sonusnet.com > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > Francois Audet > Sent: Wednesday, February 15, 2006 8:23 PM > To: Hisham Khartabil; Cullen Jennings > Cc: sip@ietf.org; fwmiller@cornfed.com > Subject: RE: [Sip] Outbound and STUN Keep Alive >=20 >=20 > Exactly my view. >=20 > I really don't see why processing a PING method would be any more > resource-intensive because of "parsing" or whatever than processing > a STUN message (binary) that happens to run on the same port > the rest of the SIP protocol runs on. >=20 >=20 >=20 > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > > Behalf Of Hisham Khartabil > > Sent: Wednesday, February 15, 2006 05:16 > > To: Cullen Jennings > > Cc: sip@ietf.org; fwmiller@cornfed.com > > Subject: Re: [Sip] Outbound and STUN Keep Alive > >=20 > >=20 > > This is all theory and guesstimates. We'll try to prototype these=20 > > things and get back to the list with hard numbers to prove or=20 > > disprove=20 > > the 2 theories. If anyone willing to co-operate on this,=20 > > please contact=20 > > me. > >=20 > > Regards, > > Hisham >=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 sip-bounces@ietf.org Thu Feb 16 08:06:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9ipm-00042u-NY; Thu, 16 Feb 2006 08:06:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9ipk-00042k-UE for sip@megatron.ietf.org; Thu, 16 Feb 2006 08:06:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20776 for ; Thu, 16 Feb 2006 08:04:21 -0500 (EST) Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9j3y-00045X-91 for sip@ietf.org; Thu, 16 Feb 2006 08:20:51 -0500 Received: from sonusmail02.sonusnet.com (sonusmail02.sonusnet.com [10.128.32.96]) by sonussf1.sonusnet.com (8.13.3/8.13.3) with ESMTP id k1GD5uKq024434; Thu, 16 Feb 2006 08:05:56 -0500 x-mimeole: Produced By Microsoft Exchange V6.0.6603.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] Outbound and STUN Keep Alive Date: Thu, 16 Feb 2006 08:05:56 -0500 Message-ID: <05AE95C39E8E2642AF9C04526EDAC414C7299E@sonusmail02.sonusnet.com> Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcYyMtQQFhCJuPVRTMaN4Qdhsi9uagAYfslQABgFlRAAASfdUA== From: "Bharrat, Shaun" To: "Bharrat, Shaun" , "Francois Audet" , "Hisham Khartabil" , "Cullen Jennings" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org One slight correction. In #1, the application got involved so it is not an immediate 200. A 200 from directly in the stack was not measured. The useful comparison, IMO, is #3 to #2. Thanks and cheers, Shaun Bharrat Sonus Networks www.sonusnet.com > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > Bharrat, Shaun > Sent: Thursday, February 16, 2006 7:48 AM > To: Francois Audet; Hisham Khartabil; Cullen Jennings > Cc: sip@ietf.org; fwmiller@cornfed.com > Subject: RE: [Sip] Outbound and STUN Keep Alive >=20 >=20 > Audet, Frank: >=20 > We have in the recent past implemented three refresh variants=20 > on an embedded platform: > 1. Full parse of REGISTER with an immediate 200 (C stack) > 2. "Fast parse" of a REGISTER looking only for To/From/Via/CSeq > and sending a register using those fields (again C code) > 3. STUN server which only supported the requests without port or > address change subrequests (again C code). >=20 > #3 was almost an order of magnitude better than #1 and about 3 times > as fast as #2.=20 >=20 > So why is #2 slower at all -- unless you have really nifty pattern > matching h/w, you have to go through byte-by-byte (at least once) > to find the To/From/Via/CSeq. A STUN packet is both tiny and you can > quickly skip over irrelevant data. >=20 > If you do ever end up declaring "you SHOULD use REGISTER,=20 > PING, OPTIONS=20 > or some other SIP message to do refresh", please don't take away=20 > the STUN option from those for whom 3x is a _big_ deal. >=20 > Thanks and cheers, > Shaun >=20 > Sonus Networks > www.sonusnet.com >=20 > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > > Francois Audet > > Sent: Wednesday, February 15, 2006 8:23 PM > > To: Hisham Khartabil; Cullen Jennings > > Cc: sip@ietf.org; fwmiller@cornfed.com > > Subject: RE: [Sip] Outbound and STUN Keep Alive > >=20 > >=20 > > Exactly my view. > >=20 > > I really don't see why processing a PING method would be any more > > resource-intensive because of "parsing" or whatever than processing > > a STUN message (binary) that happens to run on the same port > > the rest of the SIP protocol runs on. > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > > > Behalf Of Hisham Khartabil > > > Sent: Wednesday, February 15, 2006 05:16 > > > To: Cullen Jennings > > > Cc: sip@ietf.org; fwmiller@cornfed.com > > > Subject: Re: [Sip] Outbound and STUN Keep Alive > > >=20 > > >=20 > > > This is all theory and guesstimates. We'll try to prototype these=20 > > > things and get back to the list with hard numbers to prove or=20 > > > disprove=20 > > > the 2 theories. If anyone willing to co-operate on this,=20 > > > please contact=20 > > > me. > > >=20 > > > Regards, > > > Hisham > >=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 >=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 sip-bounces@ietf.org Thu Feb 16 08:23:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9j6U-0003EE-Mi; Thu, 16 Feb 2006 08:23:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9j6S-0003Dn-68 for sip@megatron.ietf.org; Thu, 16 Feb 2006 08:23:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22217 for ; Thu, 16 Feb 2006 08:21:36 -0500 (EST) Received: from not01-fw01.citel.com ([62.190.107.50] ident=daemon) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9jKb-0004kt-U9 for sip@ietf.org; Thu, 16 Feb 2006 08:38:06 -0500 Received: from [10.7.1.3] (helo=not01-mxc01.citel.com) by not01-fw01.citel.com with esmtp (Exim 4.43) id 1F9j6I-0003kR-Tw; Thu, 16 Feb 2006 13:23:14 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Thu, 16 Feb 2006 13:23:14 -0000 Message-ID: <592CA2F7E2BFBD4088AC87ECFF34BECE1F3CF9@not01-mxc01.citel.com> Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcYyUzMioconJGv7TRSgxVHfiCpdkgAqDFvw From: "Steve Langstaff" To: "Jonathan Rosenberg" , "Pekka Pessi" X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , sip@ietf.org, fwmiller@cornfed.com, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Isn't that figure of 3.8bps more like: (20 + 36) * 8 / 15 (=3D 30bps) for STUN vs (300 + 300) * 8 / 15 (=3D320bps) for OPTIONS [i.e. approximately 9% of the bandwidth] or does STUN use a different timeout to OPTIONS? If we *do* take IP/UDP overheads into account, but not link headers, we = get: (20 + 36 + 28 + 28) * 8 / 15 (~=3D 60bps) for STUN vs (300 + 300 + 28 + 28) * 8 / 15 (~=3D 350bps) for OPTIONS [i.e. approximately 17% of the bandwidth] -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Jonathan Rosenberg Sent: 15 February 2006 17:05 To: Pekka Pessi Cc: Cullen Jennings; sip@ietf.org; fwmiller@cornfed.com; Dean Willis Subject: Re: [Sip] Outbound and STUN Keep Alive The bandwidth aspect of this is important too. The STUN request in=20 question here is 20 bytes, and the response is 36. A SIP OPTIONS request = and response is probably around 300-400 bytes. At a rate of a keepalive=20 every 15 seconds, you end up with 320 bps per subscriber for OPTIONS,=20 and 3.8 bps for STUN (not counting IP/UDP overheads). Its interesting to = compare this to 'useful' traffic. Assuming .1 erlangs and a hold time of = 3m during the busy hour, you get 5.5e-4 calls per second per subscriber. = With a INV/200/ACK BYE/200 sequence, and assuming 1kB for INV/200 and=20 300B for the others, thats 2.9 kB total per call, and thus 12.76 bps per = subscriber. As a consequence, with the OPTIONS approach, you have a=20 bandwidth overhead of 320/12.76 which is 25, or 2500%!!!! WIth STUN,=20 this is a still painful but palatable 3.8/12.76 =3D 30%. To put that in perspective, a server supporting 100k subscribers would=20 require 1.2 Mbps access for useful signaling, and an additional 32 Mbps=20 just for the useless OPTIONS message. To make sure you are nowhere near=20 (i.e. not within 50%) of link saturation, this comes close enough to the = limit of 100M ethernet that you'd probably need to jump to GiGE, whereas = 10M ethernet would suffice with STUN keepalives. -Jonathan R. Pekka Pessi wrote: > Dean Willis writes: >=20 >>vikram.agarwal@flextronicssoftware.com wrote: >> >>>will OPTIONS method not work for the same? Instead of sending an CRLF = we >>>can also send an OPTIONS method to refresh the NAT binding. If i am = not >>>wrong then OPTIONS method was discared because of the processing of = the >>>SIP message for keeeping the NAT binding alive. Hence, CRLF was >>>considered. But CRLF is not backward compatible i.e. it does not = provide >>>MAPPED ADDRESS. Now bringing in the PING method would again be = introducing >>>a SIP message based processing which would lead to poor performance. >=20 >=20 >>We've demonstrated successfully slaying proxies by bombing them with = OPTIONS >>requests. >=20 >=20 >>Back in the "early days" of dynamicsoft, our first proxies were = processing 7 >>INVITE/200/ACK/BYE/200 non-authenticated transaction sequences or = about 20 >>OPTIONS transactions per second. They've of course gotten much faster, = but >>the proportions have stayed pretty much the same. >=20 >=20 >>So you can see that in models where a typical SIP transaction load = might be >>5 transactions per hour per node, adding another 60 OPTIONS = transactions per >>hour per node might reduce your edge-proxy scalability by on the order = of >>13-1, or roughly a 93% performance hit. That's a big hit. >=20 >=20 > Of course, that is the relative performance hit that you will see > on a 100 Mb/s ethernet, which I think is the bottleneck on most > SIP servers. You do lot of OPTIONS, you use all you bandwidth > receiving OPTIONS, right? ;-) >=20 > On more serious discussion, you use roughly the same number of > packets and system calls to process a STUN request as when > processing OPTIONS, The bottleneck is not in the CPU doing SIP or > STUN parsing but (hopefully) somewhere else, like your memory bus > or network I/O. Both SIP and STUN parser and processing code fit > nicely in your cache nowadays, mixed STUN/SIP server losing > because it has to fit both SIP and STUN parser code in its cache. >=20 > Of course, a hypothetical SIP server implemented in Perl and > heavily relying in shell scripting might be a different story. >=20 > --Pekka >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.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 _______________________________________________ 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 sip-bounces@ietf.org Thu Feb 16 12:20:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9mo9-0002uA-F4; Thu, 16 Feb 2006 12:20:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9mo7-0002tu-RN for sip@megatron.ietf.org; Thu, 16 Feb 2006 12:20:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13354 for ; Thu, 16 Feb 2006 12:18:56 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9n2O-0005rO-8k for sip@ietf.org; Thu, 16 Feb 2006 12:35:28 -0500 Received: from az33exr03.mot.com ([10.64.251.233]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k1GHZdUH015258 for ; Thu, 16 Feb 2006 10:35:39 -0700 (MST) Received: from de01exm65.ds.mot.com (de01exm65.am.mot.com [10.176.8.16]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k1GHYbeh001010 for ; Thu, 16 Feb 2006 11:34:38 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 16 Feb 2006 12:20:39 -0500 Message-ID: <8F8F331B2441814ABC221BD3B4C7C3597188CF@de01exm65.ds.mot.com> Thread-Topic: Record-Route Thread-Index: AcYzHU7+ppF7kGghQ9y/e1Mmj2K0vQ== From: "Marqui Peter-E50322" To: , X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.2 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: Subject: [Sip] Record-Route X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1683092961==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1683092961== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6331D.4F60E01B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6331D.4F60E01B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Should the Record-Route fields between the calling and called party be symmetrical ? Or the same for each direction ? =20 U1->P1->P2->P3->P4->U2 The INVITE arriving at U2 contains: =20 INVITE sip:callee@u2.domain.com SIP/2.0 Contact: sip:caller@u1.example.com Record-Route: Record-Route: Record-Route: Record-Route: =20 While subsequent messages arriving at U1 from U2 would take the following path: U2->P4->P3->P2->P1>U1 And the Record-Route header would be as follows =20 SIP/2.0 200 OK Contact: sip:callee@u2.domain.com=20 Record-Route: Record-Route: Record-Route: Record-Route: Peter Marqui Motorola MDB, Libertyville Email: peter.marqui@motorola.com =20 Phone: 847-523-0584 Mobile: 847- =20 ------_=_NextPart_001_01C6331D.4F60E01B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Should = the=20 Record-Route fields between the calling and called party be symmetrical=20 ?
Or the = same for each=20 direction ?
 
   =20 U1->P1->P2->P3->P4->U2
The = INVITE arriving=20 at U2 contains:
 
      INVITE sip:callee@u2.domain.com=20 SIP/2.0
      Contact:=20 sip:caller@u1.example.com
      = Record-Route:=20 <sip:p4.domain.com;lr>
      = Record-Route:=20 <sip:p3.middle.com>
      = Record-Route:=20 <sip:p2.example.com;lr>
      = Record-Route:=20 <sip:p1.example.com;lr>
 
And = the Record-Route=20 header would be as follows
 
      SIP/2.0 200 = OK
      Contact:=20 sip:callee@u2.domain.com 
      = Record-Route:=20 <sip:p1.example.com;lr>
      Record-Route:=20 <sip:p2.example.com;lr>
      = Record-Route:=20 <sip:p3.middle.com>
      = Record-Route:=20 <sip:p4.domain.com;lr>
Peter Marqui
Motorola MDB,=20 Libertyville
Email:   peter.marqui@motorola.com
Phone: =20 847-523-0584
While = subsequent=20 messages arriving at U1 from U2 would take the following=20 path:     U2->P4->P3->P2->P1>U1
Mobile:  = 847-
 
------_=_NextPart_001_01C6331D.4F60E01B-- --===============1683092961== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1683092961==-- From sip-bounces@ietf.org Thu Feb 16 12:50:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9nHD-0007CP-Ve; Thu, 16 Feb 2006 12:50:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9nHC-0007BH-9r for sip@megatron.ietf.org; Thu, 16 Feb 2006 12:50:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15463 for ; Thu, 16 Feb 2006 12:48:59 -0500 (EST) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9nVO-0006lu-LZ for sip@ietf.org; Thu, 16 Feb 2006 13:05:31 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id k1GI2Pd9018527 for ; Thu, 16 Feb 2006 11:02:25 -0700 (MST) Received: from de01exm65.ds.mot.com (de01exm65.am.mot.com [10.176.8.16]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k1GI0Wgk003791 for ; Thu, 16 Feb 2006 12:00:32 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Record-Route Date: Thu, 16 Feb 2006 12:50:37 -0500 Message-ID: <8F8F331B2441814ABC221BD3B4C7C359718906@de01exm65.ds.mot.com> Thread-Topic: [Sip] Record-Route Thread-Index: AcYzH1S10JrcJ2RwRBCEQ2tYwCAKgwAAXdlg From: "Marqui Peter-E50322" To: "Rayees Khan" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 1.1 (+) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 Cc: sip@ietf.org, sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0563840347==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0563840347== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63321.7EA62B73" This is a multi-part message in MIME format. ------_=_NextPart_001_01C63321.7EA62B73 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rayees, =20 I'm not sure I follow you=20 Do you mean my example is correct or that the Record-Route sent in the response is exactly what was received by the callee in the INVITE request ? It is not built as the response traversew the path from U2 to U1 =20 ________________________________ From: Rayees Khan [mailto:rayees.khan@flextronicssoftware.com]=20 Sent: Thursday, February 16, 2006 11:32 AM To: Marqui Peter-E50322 Cc: sip-implementors@cs.columbia.edu; sip@ietf.org Subject: Re: [Sip] Record-Route Hi Peter, If we go by Section 16.12.1.1 of RFC 3261 the Record-Route stack of response seems to be inverted. The record-route stack in response is maintained as it is build along traversal of request. regards Rayees -----sip-bounces@ietf.org wrote: ----- To: , From: "Marqui Peter-E50322" Sent by: sip-bounces@ietf.org Date: 02/16/2006 05:20PM Subject: [Sip] Record-Route =09 =09 Should the Record-Route fields between the calling and called party be symmetrical ?=20 Or the same for each direction ?=20 =09 U1->P1->P2->P3->P4->U2 =09 The INVITE arriving at U2 contains:=20 INVITE sip:callee@u2.domain.com SIP/2.0 Contact: sip:caller@u1.example.com Record-Route: Record-Route: Record-Route: Record-Route: =20 =09 While subsequent messages arriving at U1 from U2 would take the following path: U2->P4->P3->P2->P1>U1=20 And the Record-Route header would be as follows=20 =09 SIP/2.0 200 OK=20 Contact: sip:callee@u2.domain.com=20 Record-Route: =20 Record-Route: Record-Route: Record-Route: =09 Peter Marqui=20 Motorola MDB, Libertyville=20 Email: peter.marqui@motorola.com =20 Phone: 847-523-0584=20 Mobile: 847-=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 *****FSS-Private *****" DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." ------_=_NextPart_001_01C63321.7EA62B73 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Rayees,
 
I'm not sure I follow you
Do you mean my example is correct&= nbsp;or that the Record-Route sent in the response is = exactly what=20 was received by the callee in the INVITE request=20 ?
It is not built as the response traversew the = path from=20 U2 to U1

 
From: Rayees Khan=20 [mailto:rayees.khan@flextronicssoftware.com]
Sent: Thursday, = February=20 16, 2006 11:32 AM
To: Marqui Peter-E50322
Cc:=20 sip-implementors@cs.columbia.edu; sip@ietf.org
Subject: Re: = [Sip]=20 Record-Route

Hi Peter,

If we go by Section 16.12.1.1 of RFC 3261 the = Record-Route=20 stack of response seems to be inverted. The record-route stack in = response is=20 maintained as it is build along traversal of=20 request.


regards
Rayees




-----sip-bounces@ietf.org wrote: -----

To:=20 <sip-implementors@cs.columbia.edu>, = <sip@ietf.org>
From:=20 "Marqui Peter-E50322" <peter.marqui@motorola.com>
Sent by:=20 sip-bounces@ietf.org
Date: 02/16/2006 05:20PM
Subject: [Sip]=20 Record-Route

Should the=20 Record-Route fields between the calling and called party be = symmetrical ?=20
Or = the same for=20 each direction ?
=20
   =20 U1->P1->P2->P3->P4->U2
The = INVITE=20 arriving at U2 contains:
      INVITE = sip:callee@u2.domain.com=20 SIP/2.0
      Contact:=20 sip:caller@u1.example.com
      = Record-Route:=20 <sip:p4.domain.com;lr>
      = Record-Route:=20 <sip:p3.middle.com>
      = Record-Route:=20 <sip:p2.example.com;lr>
      = Record-Route:=20 <sip:p1.example.com;lr>
=20
While subsequent=20 messages arriving at U1 from U2 would take the following path: =20     = U2->P4->P3->P2->P1>U1 =
And = the=20 Record-Route header would be as follows
=20
      SIP/2.0 200 OK =
      Contact:=20 sip:callee@u2.domain.com 
      = Record-Route:=20 <sip:p1.example.com;lr>
      Record-Route:=20 <sip:p2.example.com;lr>
      = Record-Route:=20 <sip:p3.middle.com>
      = Record-Route:=20 <sip:p4.domain.com;lr>
Peter Marqui =
Motorola MDB, = Libertyville=20
Email:    = peter.marqui@motorola.com
Phone:  = 847-523-0584=20
Mobile:  847- =
_______________________________________________
Sip = mailing list=20  https://www1.ietf.org= /mailman/listinfo/sip
This=20 list is for NEW development of the core SIP Protocol
Use=20 sip-implementors@cs.columbia.edu for questions on current sip
Use=20 sipping@ietf.org for new developments on the application of=20 sip

*****FSS-Private *****" DISCLAIMER: This = message=20 is proprietary to Flextronics Software Systems Limited (FSS) and is = intended=20 solely for the use of the individual to whom it is addressed. It may = contain=20 privileged or confidential information and should not be circulated or = used for=20 any purpose other than for what it is intended. If you have received = this=20 message in error, please notify the originator immediately. If you are = not the=20 intended recipient, you are notified that you are strictly prohibited = from=20 using, copying, altering, or disclosing the contents of this message. = FSS=20 accepts no responsibility for loss or damage arising from the use of the = information transmitted by this email including damage from=20 virus."
------_=_NextPart_001_01C63321.7EA62B73-- --===============0563840347== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0563840347==-- From sip-bounces@ietf.org Thu Feb 16 13:41:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9o3y-00038D-KZ; Thu, 16 Feb 2006 13:41:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9o3w-00034i-0v for sip@megatron.ietf.org; Thu, 16 Feb 2006 13:41:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20518 for ; Thu, 16 Feb 2006 13:39:20 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9oI8-0000Na-UO for sip@ietf.org; Thu, 16 Feb 2006 13:55:53 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k1GIemL22421; Thu, 16 Feb 2006 13:40:48 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Outbound and STUN Keep Alive Date: Thu, 16 Feb 2006 12:40:44 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF06CE4268@zrc2hxm0.corp.nortel.com> Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcYytia5IIwVrxNHR8SbjzEJCxr7xAAbAYTw From: "Francois Audet" To: "Jonathan Rosenberg" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , sip@ietf.org, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Wednesday, February 15, 2006 21:00 > To: fwmiller@cornfed.com > Cc: Dean Willis; Audet, Francois [SC100:9T51:EXCH]; Cullen=20 > Jennings; sip@ietf.org > Subject: Re: [Sip] Outbound and STUN Keep Alive > I would argue that 3x is already good enough to make this worthwhile. I can't really comment on the 3x claim. However, assuming that it is true, I am still not sure that in the total scheme of things that the proxy needs to do, that it would make a significant difference. The 3x assertion is comparing just the STUN-in-SIP vs. PING=20 keep-alive process. How big of a fraction of the overall load on "real-life" proxy is=20 keep-alive is the more important question. I find it quite bizarre that we are so worried about using a binary protocol for keep-alive, while we went complete the other way for everything else in SIP (increasing amount of subscribtions to various complex XML packages as a example). Our experience with an (optimized) PING mechanism on large scale=20 deployment and PING for keep alive is not seen as affecting=20 significantly overall processing requirements on proxies. Of course, I understand that all SIP proxies are not equal, and that it could be much different on other types of proxies (e.g., where the ratio of idle calls to active calls is extremely big, or where the proxy is extremely lightweight).=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 sip-bounces@ietf.org Thu Feb 16 14:24:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9ojT-0006mO-OU; Thu, 16 Feb 2006 14:24:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9ojR-0006hI-K1 for sip@megatron.ietf.org; Thu, 16 Feb 2006 14:24:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24233 for ; Thu, 16 Feb 2006 14:22:14 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9oxd-0001xQ-5F for sip@ietf.org; Thu, 16 Feb 2006 14:38:47 -0500 Received: from [64.101.173.155] ([64.101.173.155]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1GJNrN6000807 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 16 Feb 2006 13:23:54 -0600 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF06CE4268@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF06CE4268@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8E36C0DE-89B0-4F0B-BE1A-B7BEDAB2B4B9@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Thu, 16 Feb 2006 13:23:46 -0600 To: Francois Audet X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , sip@ietf.org, fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 16, 2006, at 12:40 PM, Francois Audet wrote: > How big of a fraction of the overall load on "real-life" proxy is > keep-alive is the more important question. It's potentially a dominate proportion. An average phone might place less than 5 calls per hour (actually, less than 1 per hour is common) but do 120 keepalive operations per hour, or even 240 if we adopt the 15-second suggestion. So, keepalive could represent more than 98% of the transaction load on an edge proxy, in terms of SIP transactions. Reducing 98% of the load by 1/3 represents a more than 30% overall performance boost. That may be worth talking about. Reducing it by 90% would be worth celebrating with fireworks and free beer. -- 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 sip-bounces@ietf.org Thu Feb 16 16:23:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9qay-0001Mb-7Q; Thu, 16 Feb 2006 16:23:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9qav-0001LC-WD for sip@megatron.ietf.org; Thu, 16 Feb 2006 16:23:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11197 for ; Thu, 16 Feb 2006 16:21:33 -0500 (EST) Received: from [66.155.254.250] (helo=isdmail1.inovsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9qp4-0003hA-1g for sip@ietf.org; Thu, 16 Feb 2006 16:38:08 -0500 Received: from greatwall ([12.181.128.3]) by isdmail1.inovsys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 16 Feb 2006 16:23:01 -0500 From: "Gary Gan" To: "'Dean Willis'" , "'Francois Audet'" Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Thu, 16 Feb 2006 16:23:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <8E36C0DE-89B0-4F0B-BE1A-B7BEDAB2B4B9@softarmor.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYzLvZHBivjiDJiTd6ndigw/JWn8wADPeCw Message-ID: X-OriginalArrivalTime: 16 Feb 2006 21:23:02.0031 (UTC) FILETIME=[2AC779F0:01C6333F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: 'Cullen Jennings' , sip@ietf.org, fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I don't know why the double CRLF is not enough for keep-alive. 1. It doesn't need the response from the server to keep the NAT binding alive. Am I wrong on this? 2. It is small, not much network traffic is introduced. 3. Little CPU is required, for the SIP server just simply ignores it, because it is considered as an invalid SIP message. 4. The SIP binding is refreshed by the keep-alive SIP Register message. The only problem I can think of is that the UA doesn't know if the server is down between now and the next SIP REGISTER is sent. Gary Gan Sr. Software Developer Clique Communications, LLC 205 Rockingham Row Princeton Forrestal Village Princeton, NJ 08540 Phone: 609-564-0206 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean Willis Sent: Thursday, February 16, 2006 2:24 PM To: Francois Audet Cc: Cullen Jennings; sip@ietf.org; fwmiller@cornfed.com Subject: Re: [Sip] Outbound and STUN Keep Alive On Feb 16, 2006, at 12:40 PM, Francois Audet wrote: > How big of a fraction of the overall load on "real-life" proxy is > keep-alive is the more important question. It's potentially a dominate proportion. An average phone might place less than 5 calls per hour (actually, less than 1 per hour is common) but do 120 keepalive operations per hour, or even 240 if we adopt the 15-second suggestion. So, keepalive could represent more than 98% of the transaction load on an edge proxy, in terms of SIP transactions. Reducing 98% of the load by 1/3 represents a more than 30% overall performance boost. That may be worth talking about. Reducing it by 90% would be worth celebrating with fireworks and free beer. -- 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 sip-bounces@ietf.org Thu Feb 16 17:02:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9rD9-00078E-Ld; Thu, 16 Feb 2006 17:02:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9rD7-00076i-Ce for sip@megatron.ietf.org; Thu, 16 Feb 2006 17:02:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15855 for ; Thu, 16 Feb 2006 17:01:00 -0500 (EST) Received: from www.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9rRP-0006Y5-8D for sip@ietf.org; Thu, 16 Feb 2006 17:17:36 -0500 Received: by www.implementers.org (Postfix, from userid 1006) id 796F036C481; Thu, 16 Feb 2006 14:02:46 -0800 (PST) Received: from [10.1.28.4] (unknown [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id AA58536C47B; Thu, 16 Feb 2006 14:02:44 -0800 (PST) Message-ID: <43F4F683.1020103@acm.org> Date: Thu, 16 Feb 2006 14:02:43 -0800 From: Marc Petit-Huguenin User-Agent: Debian Thunderbird 1.0.7 (X11/20051019) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gary Gan Subject: Re: [Sip] Outbound and STUN Keep Alive References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: 'Cullen Jennings' , sip@ietf.org, 'Francois Audet' , fwmiller@cornfed.com, 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Gary Gan wrote: > I don't know why the double CRLF is not enough for keep-alive. > > 1. It doesn't need the response from the server to keep the NAT binding > alive. Am I wrong on this? > 2. It is small, not much network traffic is introduced. > 3. Little CPU is required, for the SIP server just simply ignores it, > because it is considered as an invalid SIP message. > 4. The SIP binding is refreshed by the keep-alive SIP Register message. > > The only problem I can think of is that the UA doesn't know if the server is > down between now and the next SIP REGISTER is sent. But it is important to know this. When it happens, no INVITE or NOTIFY can be received until the next REGISTER/SUBSCRIBE. This was already bad when the INVITE was not received, but there is more and more services using SUB/NOT - presence, mwi, ua-profile, etc... We also saw this problem with some ADSL providers, especialy in Europe, that are changing the DHCP IP address each nigh (server reboot?) > > Gary Gan > Sr. Software Developer > > Clique Communications, LLC > 205 Rockingham Row > Princeton Forrestal Village > Princeton, NJ 08540 > Phone: 609-564-0206 > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean > Willis > Sent: Thursday, February 16, 2006 2:24 PM > To: Francois Audet > Cc: Cullen Jennings; sip@ietf.org; fwmiller@cornfed.com > Subject: Re: [Sip] Outbound and STUN Keep Alive > > > On Feb 16, 2006, at 12:40 PM, Francois Audet wrote: > >>How big of a fraction of the overall load on "real-life" proxy is >>keep-alive is the more important question. > > > It's potentially a dominate proportion. An average phone might place > less than 5 calls per hour (actually, less than 1 per hour is common) > but do 120 keepalive operations per hour, or even 240 if we adopt the > 15-second suggestion. > > So, keepalive could represent more than 98% of the transaction load > on an edge proxy, in terms of SIP transactions. > > Reducing 98% of the load by 1/3 represents a more than 30% overall > performance boost. That may be worth talking about. Reducing it by > 90% would be worth celebrating with fireworks and free beer. > > -- > Dean > -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Professional: petithug@acm.org Work: marc@8x8.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 sip-bounces@ietf.org Thu Feb 16 17:20:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9rTr-0007cS-Sm; Thu, 16 Feb 2006 17:20:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9rTq-0007aj-8O for sip@megatron.ietf.org; Thu, 16 Feb 2006 17:20:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16814 for ; Thu, 16 Feb 2006 17:18:17 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9ri4-0007QA-6o for sip@ietf.org; Thu, 16 Feb 2006 17:34:53 -0500 Received: from [64.101.173.155] ([64.101.173.155]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1GMJwLY001637 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 16 Feb 2006 16:20:00 -0600 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7ABB49B7-EBA2-404A-9F4B-1A886B5CCAF0@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Thu, 16 Feb 2006 16:19:51 -0600 To: Gary Gan X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: 'Cullen Jennings' , sip@ietf.org, 'Francois Audet' , fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 16, 2006, at 3:23 PM, Gary Gan wrote: > The only problem I can think of is that the UA doesn't know if the > server is > down between now and the next SIP REGISTER is sent. Right, that's exactly the problem we're trying to solve. Keeping the NAT alive is only half the problem -- knowing when it has died and we need to renegotiate is the other half. Sure, we could REGISTER every 15 seconds, but I'm POSITIVE that's going to slow things down . . . -- 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 sip-bounces@ietf.org Fri Feb 17 08:57:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA66W-0004Aw-Ub; Fri, 17 Feb 2006 08:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA66T-00049a-Ec for sip@megatron.ietf.org; Fri, 17 Feb 2006 08:56:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27828 for ; Fri, 17 Feb 2006 08:54:39 -0500 (EST) Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA3Xx-0001Gz-5y for sip@ietf.org; Fri, 17 Feb 2006 06:13:15 -0500 Received: from rly26b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly26b.srv.mailcontrol.com (MailControl) with ESMTP id k1HAw3lv024332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 17 Feb 2006 10:58:04 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly26b.srv.mailcontrol.com (MailControl) id k1HAviPw023566 for sip@ietf.org; Fri, 17 Feb 2006 10:57:44 GMT Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly26b-eth0.srv.mailcontrol.com (envelope-sender cboulton@ubiquity.net) (MIMEDefang) with ESMTP id k1HAvNBx022655; Fri, 17 Feb 2006 10:57:44 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Fri, 17 Feb 2006 10:22:30 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE04E78B50@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcYzLvZHBivjiDJiTd6ndigw/JWn8wADPeCwABvzi+A= From: "Chris Boulton" To: "Gary Gan" , "Dean Willis" , "Francois Audet" X-Scanned-By: MailControl A-06-00-03 (www.mailcontrol.com) on 10.66.1.136 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , sip@ietf.org, fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I don't know why the double CRLF is not enough for keep-alive. [Chris Boulton] Equally why is STUN not enough? It is already specified for UDP in the Outbound draft and would provide consistency across the board for keep-alive + the savings previously mentioned over a SIP mechanism - so why not use it for TCP?=20 Information contained in this e-mail and any attachments are intended for t= he use of the addressee only, and may contain confidential information of U= biquity Software Corporation. All unauthorized use, disclosure or distribu= tion is strictly prohibited. If you are not the addressee, please notify t= he sender immediately and destroy all copies of this email. Unless otherwi= se expressly agreed in writing signed by an officer of Ubiquity Software Co= rporation, nothing in this communication shall be deemed to be legally bind= ing. 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 sip-bounces@ietf.org Fri Feb 17 09:08:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA646-0003F0-7Z; Fri, 17 Feb 2006 08:54:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA642-0003DU-G3 for sip@megatron.ietf.org; Fri, 17 Feb 2006 08:54:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26517 for ; Fri, 17 Feb 2006 08:52:27 -0500 (EST) Received: from usaga01-in.huawei.com ([12.129.211.51] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA4JY-0003Ie-CP for sip@ietf.org; Fri, 17 Feb 2006 07:02:26 -0500 Received: from huawei.com ([172.24.2.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUT00ESUXEX3V@usaga01-in.huawei.com> for sip@ietf.org; Fri, 17 Feb 2006 03:32:58 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUT008UYY4WTJ@szxga02-in.huawei.com> for sip@ietf.org; Fri, 17 Feb 2006 19:48:32 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUT00ADPY3VR1@szxga02-in.huawei.com> for sip@ietf.org; Fri, 17 Feb 2006 19:48:32 +0800 (CST) Received: from darshan1143 ([10.18.3.138]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IUT004D3XFSE7@szxml01-in.huawei.com> for sip@ietf.org; Fri, 17 Feb 2006 19:33:30 +0800 (CST) Date: Fri, 17 Feb 2006 16:47:36 +0530 From: Darshan Bildikar Subject: RE: [Sip] Outbound and STUN Keep Alive In-reply-to: <7ABB49B7-EBA2-404A-9F4B-1A886B5CCAF0@softarmor.com> To: sip@ietf.org Message-id: <000001c633b3$c2b0d850$8a03120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7BIT X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: darshanb@huawei.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Couldn't this problem also be solved using some kind of multicast mechanism? All SIP UA's registered to a proxy form a multicast group and express an interest in receiving keep alive multicast packets.. The proxy sends out keep alive packets to a multicast IP... The UA's have a timeout mechanism ... say they don't receive keep alive packets for a pre defined duration (say one minute) then they consider the link broken. Load on the proxy is also greatly reduced. Am thinking only from the point of view of a keep alive mechanism... not refreshing NAT bindings. Just a thought. Darshan -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean Willis Sent: Friday, February 17, 2006 3:50 AM To: Gary Gan Cc: 'Cullen Jennings'; sip@ietf.org; 'Francois Audet'; fwmiller@cornfed.com Subject: Re: [Sip] Outbound and STUN Keep Alive On Feb 16, 2006, at 3:23 PM, Gary Gan wrote: > The only problem I can think of is that the UA doesn't know if the > server is > down between now and the next SIP REGISTER is sent. Right, that's exactly the problem we're trying to solve. Keeping the NAT alive is only half the problem -- knowing when it has died and we need to renegotiate is the other half. Sure, we could REGISTER every 15 seconds, but I'm POSITIVE that's going to slow things down . . . -- 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 sip-bounces@ietf.org Fri Feb 17 09:41:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA6ns-000746-D2; Fri, 17 Feb 2006 09:41:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8iZ2-0004CX-Ra for sip@megatron.ietf.org; Mon, 13 Feb 2006 13:36:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13718 for ; Mon, 13 Feb 2006 13:34:58 -0500 (EST) Received: from [200.123.145.66] (helo=ad01.voipgroup.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8imY-0001cv-A3 for sip@ietf.org; Mon, 13 Feb 2006 13:50:52 -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.5 Date: Mon, 13 Feb 2006 15:35:28 -0300 Message-ID: <1553FEFFDAE48E45B2D0AB20777EB57B2E1832@ad01.voipgroup.com> Thread-Topic: SIP - SS7 / PSTN Interworking Thread-Index: AcYwLN9RHd1qNZwgEdqprQARJEEJ/AAkvUlAAALuNdA= From: "Fernando BERRETTA" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 17 Feb 2006 09:41:46 -0500 Subject: [Sip] SIP - SS7 / PSTN Interworking X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hello, Could someone tell me which RFC/s / Draft/s should be consulted to implement properly SIP / SS7-PSTN Interworking ? Is there any new draft replacing RFC 3372 and RFC 3398 ? Best Regards, Fernando _______________________________________________ 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 sip-bounces@ietf.org Fri Feb 17 09:41:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA6nt-000754-NC; Fri, 17 Feb 2006 09:41:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F93HR-0000KH-I9 for sip@megatron.ietf.org; Tue, 14 Feb 2006 11:43:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10157 for ; Tue, 14 Feb 2006 11:42:11 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F93VF-00081R-Id for sip@ietf.org; Tue, 14 Feb 2006 11:58:16 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 14 Feb 2006 08:43:38 -0800 X-IronPort-AV: i="4.02,114,1139212800"; d="scan'208"; a="1776286328:sNHT1304884610" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k1EGhbQJ014976; Tue, 14 Feb 2006 08:43:37 -0800 (PST) Received: from 10.21.123.127 ([10.21.123.127]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 14 Feb 2006 16:43:37 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Tue, 14 Feb 2006 08:00:34 -0800 Subject: Re: [Sip] Outbound and STUN Keep Alive From: Cullen Jennings To: , Dean Willis Message-ID: Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcYxf8mgCB8XjZ1zEdqXIgARJEEJ/A== In-Reply-To: <1139882779.2635.7.camel@localhost.localdomain> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 17 Feb 2006 09:41:46 -0500 Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I don't see any reason that the PING will work better than just sending OPTIONS On 2/13/06 6:06 PM, "Frank W. Miller" wrote: > > I took the liberty of putting together a new draft that proposes the > PING method. The draft is at http://www.cornfed.com/ping.txt. Comments > welcome! > > 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 sip-bounces@ietf.org Fri Feb 17 09:41:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA6nv-00075p-8K; Fri, 17 Feb 2006 09:41:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9bMD-0000Jw-44 for sip@megatron.ietf.org; Thu, 16 Feb 2006 00:07:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12671 for ; Wed, 15 Feb 2006 23:12:26 -0500 (EST) Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9aky-00021N-Br for sip@ietf.org; Wed, 15 Feb 2006 23:28:40 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k1G46vZ20353; Wed, 15 Feb 2006 23:06:57 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Outbound and STUN Keep Alive Date: Wed, 15 Feb 2006 22:10:56 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43710CF5372C@zrc2hxm2.corp.nortel.com> Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcYyoA8mYSefjnGZSyaaWttEBbXOYAADcSyw From: "Brian Stucker" To: "Dean Willis" , "Francois Audet" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 17 Feb 2006 09:41:46 -0500 Cc: Cullen Jennings , sip@ietf.org, fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean, et. al- Keep in mind one thing in your calculations... Parsing a MESSAGE that is = short (which may or may not be a message that needs further processing) = cannot be separated from "service" traffic as easily as PING. Once I've = parsed the request type I immediately know that I'm dealing with a = special case and can shunt processing over to a separate chunk of code = that can ignore much of the message. For instance, here would be a very simple way of parsing a PING: 1. Is the request type of the message "PING". If so, then shunt... 2. In the shunt parser take the original packet the PING came in on and = do the following: Replace the top of the buffer from "PING sip:xxxyyyzzz... SIP/2.0" to = "SIP/2.0 200". Pad the remainder with white space until you hit the CRLF = that terminates the request URI. 3. Append the correct header information to bottom of the packet to = identify the source of the request. 4. Send the packet back from whence it came. (Potentially) no data that needs to be copied and nothing other than the = first five characters of the message needs to be parsed. Regards, Brian -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Dean Willis Sent: Wednesday, February 15, 2006 8:20 PM To: Audet, Francois [SC100:9T51:EXCH] Cc: Cullen Jennings; sip@ietf.org; fwmiller@cornfed.com Subject: Re: [Sip] Outbound and STUN Keep Alive On Feb 15, 2006, at 7:22 PM, Francois Audet wrote: > I really don't see why processing a PING method would be any more > resource-intensive because of "parsing" or whatever than processing > a STUN message (binary) that happens to run on the same port > the rest of the SIP protocol runs on. Well, I'm sure there's at least SOME difference. How much remains to =20 be determined. I have a preliminary report from one of the performance people who's =20 working with Jonathan. He did some saturation testing comparing the =20 STUN operation to receiving, discarding, and 200oking a short MESSAGE =20 request (roughly analogous to how PING processing would work if it =20 were heavily optimized). These initial results show at least a 3x difference, much of which is =20 attributable to the parsing overhead. Once the MESSAGE request is =20 liberated from its framing, it still has to be parsed enough to =20 recognize it as a discardable message and figure out where to send =20 the 200 OK response (which requires parsing Via header fields). Then =20 the 200 OK response has to be constructed, which is pretty =20 straightforward but still requires several times more string =20 operations than the STUN response does. This testing was done on a =20 very mature Java stack implementation, the SIP part of which has been =20 highly optimized. Now I'll also have to say I don't completely trust these results -- =20 they're preliminary, I have doubts about the STUN optimization, and I =20 think we were hitting interface saturation on a 100 M ethernet. My =20 gut feel is that the gap will widen above 3x as the testing (and =20 implementation) gets better. Is 3x significant? I suppose that depends on your business model and =20 per-box overhead. It also changes the inflection points at which one =20 has to go from single or paired-box models to high-availability =20 clustering approaches with state replication, and THAT is a =20 significant delta, if you;re not already past it. -- 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 sip-bounces@ietf.org Fri Feb 17 09:41:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA6nw-00076V-CC; Fri, 17 Feb 2006 09:41:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9nxm-00039b-2q for sip@megatron.ietf.org; Thu, 16 Feb 2006 13:34:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19793 for ; Thu, 16 Feb 2006 13:32:58 -0500 (EST) Received: from ns.siphub.net ([213.239.210.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9oBm-000054-Cf for sip@ietf.org; Thu, 16 Feb 2006 13:49:31 -0500 Received: from [81.180.83.75] (helo=[192.168.2.27]) by ns.siphub.net with asmtp (TLS-1.0:DHE_RSA_AES_128_CBC_SHA:16) (Exim 4.34) id 1F9nx2-0004ES-I3; Thu, 16 Feb 2006 19:34:00 +0100 Message-ID: <43F4C5B0.70903@voice-system.ro> Date: Thu, 16 Feb 2006 20:34:24 +0200 From: Daniel-Constantin Mierla User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Marqui Peter-E50322 References: <8F8F331B2441814ABC221BD3B4C7C3597188CF@de01exm65.ds.mot.com> In-Reply-To: <8F8F331B2441814ABC221BD3B4C7C3597188CF@de01exm65.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Broken-Reverse-DNS: no host name found for IP address 81.180.83.75 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 17 Feb 2006 09:41:46 -0500 Cc: sip@ietf.org, sip-implementors@cs.columbia.edu Subject: [Sip] Re: [Sip-implementors] Record-Route X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: daniel@voice-system.ro List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The U2 must put the Record-Route headers in 200OK reply in the same order as in INVITE. See section 12.1.1 UAS behavior in RFC3261. Cheers, Daniel On 02/16/06 19:20, Marqui Peter-E50322 wrote: > Should the Record-Route fields between the calling and called party be > symmetrical ? > Or the same for each direction ? > > U1->P1->P2->P3->P4->U2 > > The INVITE arriving at U2 contains: > > INVITE sip:callee@u2.domain.com SIP/2.0 > Contact: sip:caller@u1.example.com > Record-Route: > Record-Route: > Record-Route: > Record-Route: > > While subsequent messages arriving at U1 from U2 would take the > following path: U2->P4->P3->P2->P1>U1 > And the Record-Route header would be as follows > > SIP/2.0 200 OK > Contact: sip:callee@u2.domain.com > Record-Route: > Record-Route: > Record-Route: > Record-Route: > > Peter Marqui > Motorola MDB, Libertyville > Email: peter.marqui@motorola.com > Phone: 847-523-0584 > Mobile: 847- > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > _______________________________________________ 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 sip-bounces@ietf.org Fri Feb 17 09:41:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA6nx-000782-Mu; Fri, 17 Feb 2006 09:41:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9pKP-0003g0-VD for sip@megatron.ietf.org; Thu, 16 Feb 2006 15:02:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28678 for ; Thu, 16 Feb 2006 15:00:20 -0500 (EST) Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9pR0-0004ay-9t for sip@ietf.org; Thu, 16 Feb 2006 15:09:06 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k1GJs0t16146; Thu, 16 Feb 2006 14:54:00 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Outbound and STUN Keep Alive Date: Thu, 16 Feb 2006 13:53:55 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43710CF540FE@zrc2hxm2.corp.nortel.com> Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcYytlwaVIhz+Ot2RC6T9+UDW15tvAAe99YA From: "Brian Stucker" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 17 Feb 2006 09:41:46 -0500 Cc: Cullen Jennings , sip@ietf.org, Francois Audet , fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org How can you send a 200 OK without parsing out the Via header fields? How do you get the cseq without parsing that out? -- Don't. Send the message back where it came from using the transport = information in the packet and reuse the existing information in the = request to form a valid response. You only need to add information to = the end of the packet (in the form of a message body or header) to = report what you saw from the UA in terms of their observed network = address. Very fast. Of course the UA gets to eat it's own dog food if it sends = something bad in the request. Regards, Brian -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Wednesday, February 15, 2006 11:00 PM To: Stucker, Brian [RICH1:B620:EXCH] Cc: Audet, Francois [SC100:9T51:EXCH]; Cullen Jennings; sip@ietf.org; fwmiller@cornfed.com Subject: Re: [Sip] Outbound and STUN Keep Alive On Feb 15, 2006, at 10:10 PM, Brian Stucker wrote: > Dean, et. al- > > Keep in mind one thing in your calculations... Parsing a MESSAGE =20 > that is short (which may or may not be a message that needs further =20 > processing) cannot be separated from "service" traffic as easily as =20 > PING. Once I've parsed the request type I immediately know that I'm =20 > dealing with a special case and can shunt processing over to a =20 > separate chunk of code that can ignore much of the message. > This implementation modified the SIP UA for immediate handling of the =20 MESSAGE request. It wasn't being shunted off to an application via =20 the api -- the UA was immediately doing a 200-and-discard sequence. > For instance, here would be a very simple way of parsing a PING: > > 1. Is the request type of the message "PING". If so, then shunt... > 2. In the shunt parser take the original packet the PING came in on =20 > and do the following: > Replace the top of the buffer from "PING sip:xxxyyyzzz... SIP/2.0" =20 > to "SIP/2.0 200". Pad the remainder with white space until you hit =20 > the CRLF that terminates the request URI. > 3. Append the correct header information to bottom of the packet to =20 > identify the source of the request. > 4. Send the packet back from whence it came. > > (Potentially) no data that needs to be copied and nothing other =20 > than the first five characters of the message needs to be parsed. > How can you send a 200 OK without parsing out the Via header fields? How do you get the cseq without parsing that out? -- 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 sip-bounces@ietf.org Fri Feb 17 09:45:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA6rO-0000FC-4A; Fri, 17 Feb 2006 09:45:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA6pA-0007Vt-1v for sip@megatron.ietf.org; Fri, 17 Feb 2006 09:43:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11194 for ; Fri, 17 Feb 2006 09:26:58 -0500 (EST) Received: from nproxy.gmail.com ([64.233.182.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9shC-0005rr-Ul for sip@ietf.org; Thu, 16 Feb 2006 18:38:02 -0500 Received: by nproxy.gmail.com with SMTP id x37so190331nfc for ; Thu, 16 Feb 2006 15:23:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=KZnzz+j3x7JQHurnjeszYoMOZEXo6NqrW8YZL2FK6xYKInLLOZ25MrnL6XdTuJ2dY5A6E8l8bT9PSBfcOYx6shSXiXEGMFHFCZm+xvVolmK8pe/lhmqP1rxPYrEY6RZGBrsMBldxWDpK+aR9A5z0xPRTcuQ4EmpFGLfbsVKLH0o= Received: by 10.49.10.15 with SMTP id n15mr12599nfi; Thu, 16 Feb 2006 15:23:07 -0800 (PST) Received: by 10.49.34.4 with HTTP; Thu, 16 Feb 2006 15:23:07 -0800 (PST) Message-ID: <6affd5140602161523y4e475432wdaf4f65bc99332b8@mail.gmail.com> Date: Thu, 16 Feb 2006 15:23:07 -0800 From: Raja Chilla To: sip@ietf.org In-Reply-To: <6affd5140602161139j838afa4qe292d4e84dac53c9@mail.gmail.com> MIME-Version: 1.0 References: <6affd5140602161139j838afa4qe292d4e84dac53c9@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Sip] Re: REGISTRAR behavior X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2012746503==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============2012746503== Content-Type: multipart/alternative; boundary="----=_Part_15714_28500199.1140132187869" ------=_Part_15714_28500199.1140132187869 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > > Guess this has been asked before. Can REGISTRAR lower the expiration > interval in expires field (from one requested by client originally) in it= s > 200 OK response? Note there is no 423 response to client's REGISTER reque= st > just 200OK with lowered expiration value. RFC3261 referring section would > help in any case. > -Raja ------=_Part_15714_28500199.1140132187869 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
Guess this has been asked before= . Can REGISTRAR lower the expiration interval in expires field (from one re= quested by client originally) in its 200 OK response? Note there is no 423 = response to client's REGISTER request just 200OK with lowered expiration va= lue. RFC3261 referring section would help in any case.
-Raja

------=_Part_15714_28500199.1140132187869-- --===============2012746503== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============2012746503==-- From sip-bounces@ietf.org Fri Feb 17 09:55:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA719-0004Gv-Mk; Fri, 17 Feb 2006 09:55:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA716-0004Ep-Ju for sip@megatron.ietf.org; Fri, 17 Feb 2006 09:55:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15476 for ; Fri, 17 Feb 2006 09:53:39 -0500 (EST) Received: from smail3.alcatel.fr ([64.208.49.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA7FW-00032z-0K for sip@ietf.org; Fri, 17 Feb 2006 10:10:24 -0500 Received: from missrv1.nextenso.alcatel.fr (proxy.nextenso.alcatel.fr [139.54.130.250]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id k1HEtET4015627; Fri, 17 Feb 2006 15:55:14 +0100 Received: from [139.54.131.75] (nx1075.nextenso.alcatel.fr [139.54.131.75]) by missrv1.nextenso.alcatel.fr (8.12.8/8.12.8) with ESMTP id k1HEtCsY006757; Fri, 17 Feb 2006 15:55:12 +0100 Message-ID: <43F5E3D2.1080807@alcatel.fr> Date: Fri, 17 Feb 2006 15:55:14 +0100 From: Thomas Froment Organization: Alcatel User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Stucker Subject: Re: [Sip] Outbound and STUN Keep Alive References: <6FC4416DDE56C44DA0AEE67BC7CA43710CF540FE@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43710CF540FE@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Brian Stucker wrote: >How can you send a 200 OK without parsing out the Via header fields? >How do you get the cseq without parsing that out? > >-- Don't. Send the message back where it came from using the transport information in the packet and reuse the existing information in the request to form a valid response. You only need to add information to the end of the packet (in the form of a message body or header) to report what you saw from the UA in terms of their observed network address. > >Very fast. Of course the UA gets to eat it's own dog food if it sends something bad in the request. > > If you don't look at Via header to answer a SIP request, and just send a "packet" back to the source IP Address/port, you are not doing SIP anymore, you are doing a "hack". In this case, this is no more "clean" than double CR/LF or STUN. Just to insist a last time on this topic: the most important point for me is *consistency* with other parts of sip-outbound draft, as Chris mentionned: "It is already specified for UDP in the Outbound draft", so why not use the same thing for TCP? _______________________________________________ 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 sip-bounces@ietf.org Fri Feb 17 09:58:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA74O-0005kN-HR; Fri, 17 Feb 2006 09:58:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA6rd-0007rm-U4 for sip@megatron.ietf.org; Fri, 17 Feb 2006 09:45:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10551 for ; Fri, 17 Feb 2006 09:24:27 -0500 (EST) Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9t5p-000434-69 for sip@ietf.org; Thu, 16 Feb 2006 19:03:25 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k1GNmWMP014889 for ; Thu, 16 Feb 2006 18:48:36 -0500 (EST) From: "Brett Tate" To: "sip-ietf" Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Thu, 16 Feb 2006 18:49:25 -0500 Message-ID: <003201c63353$a14a96c0$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <9E27C426-9C5B-481D-B193-5A391343D968@softarmor.com> X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > How can you send a 200 OK without parsing out > the Via header fields? >=20 > How do you get the cseq without parsing that out? If it is acceptable to define the SIP request so the receiver processes = as a request for echo instead of applying the typical SIP processing rules, = the parsing requirement would be minimal for devices which understand the request. For udp, the receiver of request would just need to partially decode the Request-Line and first Via entry (if rport type functionality not = assumed). It could then echo back everything except Request-Line as the contents within the 200 response. For tcp, the receiver of request would just need to partially decode the Request-Line and deal with content-length header. It could then echo = back everything except Request-Line as the contents within the 200 response. The sender of the request would need to decode enough of the response = (first Via entry) to match it to the request. I currently have no strong opinion between STUN, the "double CRLF", and = a new SIP method. All are better than the overhead of using REGISTER or OPTIONS to produce a similar result. One disadvantage of STUN and the "double CRLF" (echoing extraneous = CRLFs) is that they require both devices to support the functionality for it to = work. And I assume the device would need to fallback/use another mechanism = when not supported or support unknown by other. Thus defining a new SIP = method might still be beneficial for use in these situations. Additionally, devices unable or unwilling to implement the STUN approach might at = least be willing to implement a new SIP method which is better than the ones currently common. Because the "double CRLF" has the least capacity hit on connection = oriented transports, I have to ask. Is the limitation concerning the lack of transaction ID a showstopper? Would late CRLF "responses" really be = common enough and the consequence really be considered harsh enough so that = this is not a reasonable alternative? I can't really imagine late data = trickling in at intervals to confuse the mechanism more than three times in a row. = And for those (hopefully nobody) desiring even quicker knowledge of = connection closure, the capacity improvement of this mechanism actually allows the check to occur more frequently than the other alternatives. _______________________________________________ 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 sip-bounces@ietf.org Fri Feb 17 10:08:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA78H-00086y-1v; Fri, 17 Feb 2006 10:02:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA6sH-0007rm-PS for sip@megatron.ietf.org; Fri, 17 Feb 2006 09:46:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08192 for ; Fri, 17 Feb 2006 09:17:23 -0500 (EST) Received: from [66.155.254.250] (helo=isdmail1.inovsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9vIS-0003uP-9J for sip@ietf.org; Thu, 16 Feb 2006 21:24:37 -0500 Received: from greatwall ([68.39.6.223]) by isdmail1.inovsys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 16 Feb 2006 21:09:37 -0500 From: "Gary Gan" To: "'Dean Willis'" Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Thu, 16 Feb 2006 21:09:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <7ABB49B7-EBA2-404A-9F4B-1A886B5CCAF0@softarmor.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYzRx5CtxgxWgW2Sgm43eFDXOqdnAAHENTQ Message-ID: X-OriginalArrivalTime: 17 Feb 2006 02:09:37.0857 (UTC) FILETIME=[344A4B10:01C63367] X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: 'Cullen Jennings' , sip@ietf.org, 'Francois Audet' , fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Are we overkilling this issue by inventing a new keep-alive mechanism that could potentially overload the server by 90% more, just to resolve a down-time situation, which can be automatically recovered anyway but just delayed for a few minutes? But I have to agree that some UA implementation defaults the SIP REGISTER expiry time to 1 hour, in which case the problem would be more severe. So the problem becomes the UA polling for the healthy of the server, probably the healthy of the logical UDP binding. To let the server echo the simple keep-alive, such as CRLF, probably is enough for this issue. It doesn't introduce too much overhead to the server and network. Theoretically, the echo back CRLF can get lost, but it can be handled in the UA side by retransmitting the keep-alive polling when it can not find the response. If it fails a few times, the UA can declare the server down, out of service. By introducing the multiplexing of STUN server with SIP server for the purpose of keep-alive, I don't see obvious more benefits than a simple PING/PONG mechanism. I agree to use STUN, ICE on the side to solve the firewall traversal. But it would be only per restart of UA or per call basis. Not constant polling even when it is idle. Some IP service provider may change the NAT IP address on the daily basis, but I don't believe it would change it when there is a keep-alive message going on in a period of like 15 seconds, even though the message is short. Gary Gan Sr. Software Developer Clique Communications, LLC 205 Rockingham Row Princeton Forrestal Village Princeton, NJ 08540 Phone: 609-564-0206 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Thursday, February 16, 2006 5:20 PM To: Gary Gan Cc: 'Francois Audet'; 'Cullen Jennings'; sip@ietf.org; fwmiller@cornfed.com Subject: Re: [Sip] Outbound and STUN Keep Alive On Feb 16, 2006, at 3:23 PM, Gary Gan wrote: > The only problem I can think of is that the UA doesn't know if the > server is > down between now and the next SIP REGISTER is sent. Right, that's exactly the problem we're trying to solve. Keeping the NAT alive is only half the problem -- knowing when it has died and we need to renegotiate is the other half. Sure, we could REGISTER every 15 seconds, but I'm POSITIVE that's going to slow things down . . . -- 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 sip-bounces@ietf.org Fri Feb 17 10:10:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA7Fp-0004vl-Li; Fri, 17 Feb 2006 10:10:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA6re-0007rm-2m for sip@megatron.ietf.org; Fri, 17 Feb 2006 09:45:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05985 for ; Fri, 17 Feb 2006 09:10:54 -0500 (EST) Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9x7k-0001AT-Q2 for sip@ietf.org; Thu, 16 Feb 2006 23:21:42 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUT007DID2M2S@szxga03-in.huawei.com> for sip@ietf.org; Fri, 17 Feb 2006 12:13:35 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUT00K7KD2MV1@szxga03-in.huawei.com> for sip@ietf.org; Fri, 17 Feb 2006 12:13:34 +0800 (CST) Received: from darshan1143 ([10.18.3.138]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IUT00NGFDBH40@szxml02-in.huawei.com>; Fri, 17 Feb 2006 12:18:55 +0800 (CST) Date: Fri, 17 Feb 2006 09:36:35 +0530 From: Darshan Bildikar Subject: RE: [Sip] Outbound and STUN Keep Alive In-reply-to: <7ABB49B7-EBA2-404A-9F4B-1A886B5CCAF0@softarmor.com> To: "'Dean Willis'" , "'Gary Gan'" Message-id: <000001c63377$8cdbfcf0$8a03120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7BIT Cc: 'Cullen Jennings' , sip@ietf.org, 'Francois Audet' , fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: darshanb@huawei.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Couldn't this problem also be solved using some kind of multicast mechanism? All SIP UA's registered to a proxy form a multicast group and express an interest in receiving keep alive multicast packets.. The proxy sends out keep alive packets to a multicast IP... The UA's have a timeout mechanism ... say they don't receive keep alive packets for a pre defined duration (say one minute) then they consider the link broken. Load on the proxy is also greatly reduced. Am thinking only from the point of view of a keep alive mechanism... not refreshing NAT bindings. Just a thought. Darshan -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean Willis Sent: Friday, February 17, 2006 3:50 AM To: Gary Gan Cc: 'Cullen Jennings'; sip@ietf.org; 'Francois Audet'; fwmiller@cornfed.com Subject: Re: [Sip] Outbound and STUN Keep Alive On Feb 16, 2006, at 3:23 PM, Gary Gan wrote: > The only problem I can think of is that the UA doesn't know if the > server is > down between now and the next SIP REGISTER is sent. Right, that's exactly the problem we're trying to solve. Keeping the NAT alive is only half the problem -- knowing when it has died and we need to renegotiate is the other half. Sure, we could REGISTER every 15 seconds, but I'm POSITIVE that's going to slow things down . . . -- 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 sip-bounces@ietf.org Fri Feb 17 10:10:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA7Fr-0004x8-Gd; Fri, 17 Feb 2006 10:10:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA72D-0004it-C8 for sip@megatron.ietf.org; Fri, 17 Feb 2006 09:56:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04145 for ; Fri, 17 Feb 2006 09:06:46 -0500 (EST) Received: from defender.ccpu.com ([216.54.134.34] helo=smtp.ccpu.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9yjr-0000oh-CF for sip@ietf.org; Fri, 17 Feb 2006 01:05:09 -0500 Received: from smtp.ccpu.com (localhost.localdomain [127.0.0.1]) by localhost.ccpu.com (Postfix) with ESMTP id 4CDB234691B; Thu, 16 Feb 2006 21:50:06 -0800 (PST) Received: from sd-exchange.ccsd.ccpu.com (sd-exchange.ccpu.com [172.16.0.203]) by smtp.ccpu.com (Postfix) with ESMTP id 3DFF2346705; Thu, 16 Feb 2006 21:50:06 -0800 (PST) Received: from IN-EXCHANGE.ccin.ccpu.com ([172.25.0.16]) by sd-exchange.ccsd.ccpu.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Feb 2006 21:50:03 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Record-Route X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Fri, 17 Feb 2006 11:19:58 +0530 Message-ID: <22F058C3ED9D784E90CE473F2A9847F03E36F5@in-exchange> Thread-Topic: [Sip] Record-Route Thread-Index: AcYzH1S10JrcJ2RwRBCEQ2tYwCAKgwAAXdlgABieqWA= From: "Atul kumar Jha" To: "Marqui Peter-E50322" , "Rayees Khan" X-OriginalArrivalTime: 17 Feb 2006 05:50:03.0847 (UTC) FILETIME=[FF983570:01C63385] X-Spam-Score: 0.5 (/) X-Scan-Signature: 94375f06b91351a23b2e62bbf6b5a18c Cc: sip@ietf.org, sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1142305705==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1142305705== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63385.FD11630D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C63385.FD11630D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hi Peter, =20 In your example, Record-Route header is getting reverted in the response. But as we go by section 16.12.1.1 of RFC 3261 and section 3.2 of the RFC 3665 (see the F12 message) we should maintain the same order of Record-Route in the response.=20 It should not be reverted in the response.=20 It should be same as you got in your INVITE.=20 =20 Regards, Atul =20 =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Marqui Peter-E50322 Sent: Thursday, February 16, 2006 11:21 PM To: Rayees Khan Cc: sip@ietf.org; sip-implementors@cs.columbia.edu Subject: RE: [Sip] Record-Route =20 Hi Rayees, =20 I'm not sure I follow you=20 Do you mean my example is correct or that the Record-Route sent in the response is exactly what was received by the callee in the INVITE request ? It is not built as the response traversew the path from U2 to U1 =20 ________________________________ From: Rayees Khan [mailto:rayees.khan@flextronicssoftware.com]=20 Sent: Thursday, February 16, 2006 11:32 AM To: Marqui Peter-E50322 Cc: sip-implementors@cs.columbia.edu; sip@ietf.org Subject: Re: [Sip] Record-Route Hi Peter, If we go by Section 16.12.1.1 of RFC 3261 the Record-Route stack of response seems to be inverted. The record-route stack in response is maintained as it is build along traversal of request. regards Rayees -----sip-bounces@ietf.org wrote: ----- To: , From: "Marqui Peter-E50322" Sent by: sip-bounces@ietf.org Date: 02/16/2006 05:20PM Subject: [Sip] Record-Route Should the Record-Route fields between the calling and called party be symmetrical ?=20 Or the same for each direction ?=20 U1->P1->P2->P3->P4->U2 The INVITE arriving at U2 contains:=20 INVITE sip:callee@u2.domain.com SIP/2.0 Contact: sip:caller@u1.example.com Record-Route: Record-Route: Record-Route: Record-Route: =20 While subsequent messages arriving at U1 from U2 would take the following path: U2->P4->P3->P2->P1>U1=20 And the Record-Route header would be as follows=20 SIP/2.0 200 OK=20 Contact: sip:callee@u2.domain.com=20 Record-Route: =20 Record-Route: Record-Route: Record-Route: Peter Marqui=20 Motorola MDB, Libertyville=20 Email: peter.marqui@motorola.com =20 Phone: 847-523-0584=20 Mobile: 847-=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 *****FSS-Private *****" DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." ------_=_NextPart_001_01C63385.FD11630D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi = Peter,

 

In your example, Record-Route = header is getting reverted in the response.

But as we go by section 16.12.1.1 = of RFC 3261 and section 3.2 of the RFC 3665 (see the F12 message) we should = maintain the same order of Record-Route in the response. =

It should not be reverted in the = response.

It should be same as you got in = your INVITE.

 

Regards,

Atul

 

 

From: = sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On = Behalf Of Marqui Peter-E50322
Sent: Thursday, February = 16, 2006 11:21 PM
To: Rayees Khan
Cc: sip@ietf.org; sip-implementors@cs.columbia.edu
Subject: RE: [Sip] = Record-Route

 

Hi = Rayees,

 

I'm not sure I follow you =

Do you mean my e= xample is correct or that the Record-Route sent in the response is exactly what was received by the callee in = the INVITE request ?

It is not built as the response = traversew the path from U2 to U1


 

From: Rayees Khan [mailto:rayees.khan@flextronicssoftware.com]
Sent: Thursday, February = 16, 2006 11:32 AM
To: Marqui = Peter-E50322
Cc: sip-implementors@cs.columbia.edu; sip@ietf.org
Subject: Re: [Sip] = Record-Route

Hi Peter,

If we go by Section 16.12.1.1 of RFC 3261 the Record-Route stack of = response seems to be inverted. The record-route stack in response is maintained = as it is build along traversal of request.


regards
Rayees



-----sip-bounces@ietf.org wrote: -----

To: <sip-implementors@cs.columbia.edu>, <sip@ietf.org>
From: "Marqui Peter-E50322" = <peter.marqui@motorola.com>
Sent by: sip-bounces@ietf.org
Date: 02/16/2006 05:20PM
Subject: [Sip] Record-Route

Should the Record-Route fields between the calling = and called party be symmetrical ?

Or the same for each direction ? =

    = U1->P1->P2->P3->P4->U2

The INVITE arriving at U2 contains: =

      INVITE sip:callee@u2.domain.com SIP/2.0
      Contact: sip:caller@u1.example.com
      Record-Route: = <sip:p4.domain.com;lr>
      Record-Route: = <sip:p3.middle.com>
      Record-Route: = <sip:p2.example.com;lr>
      Record-Route: = <sip:p1.example.com;lr>

While subsequent messages arriving at U1 from U2 = would take the following path:      U2->P4->P3->P2->= P1>U1

And the Record-Route header would be as follows =

      SIP/2.0 200 OK =

      Contact: sip:callee@u2.domain.com 
      Record-Route: = <sip:p1.example.com;lr>

      Record-Route: <sip:p2.example.com;lr>
      Record-Route: = <sip:p3.middle.com>
      Record-Route: = <sip:p4.domain.com;lr>

Peter Marqui

Motorola MDB, Libertyville =

Email:    peter.marqui@motorola.com =

Phone:  847-523-0584 =

Mobile:  847- =

_______________________________________________ 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



*****FSS-Private *****" DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for = the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any = purpose other than for what it is intended. If you have received this message in = error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS = accepts no responsibility for loss or damage arising from the use of the = information transmitted by this email including damage from = virus."

------_=_NextPart_001_01C63385.FD11630D-- --===============1142305705== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1142305705==-- From sip-bounces@ietf.org Fri Feb 17 10:39:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA7hy-00032v-7G; Fri, 17 Feb 2006 10:39:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA7hv-000317-SY for sip@megatron.ietf.org; Fri, 17 Feb 2006 10:39:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27426 for ; Fri, 17 Feb 2006 10:37:54 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA7wM-0007zZ-7Z for sip@ietf.org; Fri, 17 Feb 2006 10:54:39 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 17 Feb 2006 07:39:32 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1HFdWWF016659; Fri, 17 Feb 2006 07:39:32 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Feb 2006 07:39:32 -0800 Received: from [10.21.146.81] ([10.21.146.81]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Feb 2006 07:39:31 -0800 Message-ID: <43F5EE33.5010508@cisco.com> Date: Fri, 17 Feb 2006 10:39:31 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Stucker Subject: Re: [Sip] Outbound and STUN Keep Alive References: <6FC4416DDE56C44DA0AEE67BC7CA43710CF5372C@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43710CF5372C@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Feb 2006 15:39:31.0928 (UTC) FILETIME=[589D1580:01C633D8] X-Spam-Score: 2.2 (++) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , sip@ietf.org, Francois Audet , fwmiller@cornfed.com, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Brian, You still have to frame the message, at least if it arrives over TCP. That means hunting for the Content-Length header, parsing it, hunting for the CRLF, and then pulling the (presumably empty) body off. I know you are going to say that the PING message can't have a body. But in that case it isn't really a normal extension to sip messages. Paul Brian Stucker wrote: > Dean, et. al- > > Keep in mind one thing in your calculations... Parsing a MESSAGE that is short (which may or may not be a message that needs further processing) cannot be separated from "service" traffic as easily as PING. Once I've parsed the request type I immediately know that I'm dealing with a special case and can shunt processing over to a separate chunk of code that can ignore much of the message. > > For instance, here would be a very simple way of parsing a PING: > > 1. Is the request type of the message "PING". If so, then shunt... > 2. In the shunt parser take the original packet the PING came in on and do the following: > Replace the top of the buffer from "PING sip:xxxyyyzzz... SIP/2.0" to "SIP/2.0 200". Pad the remainder with white space until you hit the CRLF that terminates the request URI. > 3. Append the correct header information to bottom of the packet to identify the source of the request. > 4. Send the packet back from whence it came. > > (Potentially) no data that needs to be copied and nothing other than the first five characters of the message needs to be parsed. > > Regards, > Brian > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > Dean Willis > Sent: Wednesday, February 15, 2006 8:20 PM > To: Audet, Francois [SC100:9T51:EXCH] > Cc: Cullen Jennings; sip@ietf.org; fwmiller@cornfed.com > Subject: Re: [Sip] Outbound and STUN Keep Alive > > > > On Feb 15, 2006, at 7:22 PM, Francois Audet wrote: > > >>I really don't see why processing a PING method would be any more >>resource-intensive because of "parsing" or whatever than processing >>a STUN message (binary) that happens to run on the same port >>the rest of the SIP protocol runs on. > > > Well, I'm sure there's at least SOME difference. How much remains to > be determined. > > I have a preliminary report from one of the performance people who's > working with Jonathan. He did some saturation testing comparing the > STUN operation to receiving, discarding, and 200oking a short MESSAGE > request (roughly analogous to how PING processing would work if it > were heavily optimized). > > These initial results show at least a 3x difference, much of which is > attributable to the parsing overhead. Once the MESSAGE request is > liberated from its framing, it still has to be parsed enough to > recognize it as a discardable message and figure out where to send > the 200 OK response (which requires parsing Via header fields). Then > the 200 OK response has to be constructed, which is pretty > straightforward but still requires several times more string > operations than the STUN response does. This testing was done on a > very mature Java stack implementation, the SIP part of which has been > highly optimized. > > Now I'll also have to say I don't completely trust these results -- > they're preliminary, I have doubts about the STUN optimization, and I > think we were hitting interface saturation on a 100 M ethernet. My > gut feel is that the gap will widen above 3x as the testing (and > implementation) gets better. > > Is 3x significant? I suppose that depends on your business model and > per-box overhead. It also changes the inflection points at which one > has to go from single or paired-box models to high-availability > clustering approaches with state replication, and THAT is a > significant delta, if you;re not already past it. > > -- > 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 > _______________________________________________ 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 sip-bounces@ietf.org Fri Feb 17 10:41:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA7Cc-0002hv-6N; Fri, 17 Feb 2006 10:07:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA6uZ-00017g-N1 for sip@megatron.ietf.org; Fri, 17 Feb 2006 09:48:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10774 for ; Fri, 17 Feb 2006 09:25:31 -0500 (EST) Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9sxb-0000Y3-Ar for sip@ietf.org; Thu, 16 Feb 2006 18:55:00 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k1GNdkt02760; Thu, 16 Feb 2006 18:39:46 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Outbound and STUN Keep Alive Date: Thu, 16 Feb 2006 17:39:40 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF06D89EF2@zrc2hxm0.corp.nortel.com> Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcYzLo45JrqG9LWIQZK0ZMIPzfG1tQAH/vPg From: "Francois Audet" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , fwmiller@cornfed.com, sip@ietf.org, Trip Ingle , Brian Stucker X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Those numbers are flawed. Processing a PING request is (if you optimize it properly) a lot less intensive then processing, say, an INVITE request or any other normal request. For one thing, PING is not forwarded anywhere. It is analogous to STUN if you want to optimize it to the extreme (i.e., you just send a=20 200 every time you see it). There is no DNS resolution, no forking, no complex check for the message itself since it is not going to impact the far end.=20 Furthermore, the vast majority of SIP calls will be much more than just INVITE/100/200 or whatever your model used for the calculation. You need to add 180, PRACK/200, the re-INVITE as per STUN,=20 pre-condition, also add the re-INVITE/200s or UPDATE/200 that=20 occurs as per session-timer (which is dependent on the duration of a call). Then there is all the NOTIFYs for various packages flying from everywhere (config framework, dialog package, regevent, and of=20 course, the biggest one, your presence info from all your buddies). Oh yeah, and IM too... Then maybe you proxy need to record call traces that include=20 everything except PINGs? Then you need to account for reality... For example, what if the=20 originator of the session is, say, not very SIP compliant, and the proxy needs to spend some time fixing the protocol? I could name some SIP phones in that category. A side benefit is that if you are a "smaller" SIP proxy where this=20 optimization is not an issue, then you don't have to worry about it. Same thing for a UAC. Simple to implement. If you really want to optimize PING, you could use some of the same techniques talked about earlier for STUN: look for the=20 magic cookie (in this case, binary-equivent of ASCII-PING as the first bytes. You can precompute the answer (inserting the via field). You really don't have to process PING the same way you process everything else. > On Feb 16, 2006, at 12:40 PM, Francois Audet wrote: > > How big of a fraction of the overall load on "real-life" proxy is=20 > > keep-alive is the more important question. >=20 > It's potentially a dominate proportion. An average phone might place =20 > less than 5 calls per hour (actually, less than 1 per hour is=20 > common) =20 > but do 120 keepalive operations per hour, or even 240 if we=20 > adopt the =20 > 15-second suggestion. >=20 > So, keepalive could represent more than 98% of the transaction load =20 > on an edge proxy, in terms of SIP transactions. >=20 > Reducing 98% of the load by 1/3 represents a more than 30% overall =20 > performance boost. That may be worth talking about. Reducing it by =20 > 90% would be worth celebrating with fireworks and free beer. >=20 > -- > Dean >=20 >=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 sip-bounces@ietf.org Fri Feb 17 11:40:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA8ep-00086D-FV; Fri, 17 Feb 2006 11:40:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA8en-00085j-JL for sip@megatron.ietf.org; Fri, 17 Feb 2006 11:40:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08425 for ; Fri, 17 Feb 2006 11:38:44 -0500 (EST) From: Erkki.Koivusalo@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA8tG-0003ty-A3 for sip@ietf.org; Fri, 17 Feb 2006 11:55:30 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k1HGdj9t014505; Fri, 17 Feb 2006 18:39:48 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Feb 2006 18:40:25 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Feb 2006 18:40:24 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Fri, 17 Feb 2006 18:40:20 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F01FB605E@esebe103.NOE.Nokia.com> Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcYz331NlvvEygmkR4CCN7PQ+2rVxAAAUX5A To: X-OriginalArrivalTime: 17 Feb 2006 16:40:24.0882 (UTC) FILETIME=[D9F1A120:01C633E0] X-Spam-Score: 0.3 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Brian, et. al- Please excuse me a stupid question: how much does the approach suggested below really differ from multiplexing two different protocols (like SIP and STUN) to the same port ? To me it would look like that this PING would already introduce its own protocol with its own parsing and processing rules, at least for the server receiving PING requests. On Feb 15, 2006, at 10:10 PM, Brian Stucker wrote: > Dean, et. al- > > Keep in mind one thing in your calculations...=20 > Parsing a MESSAGE that is short (which may or may=20 > not be a message that needs further processing)=20 > cannot be separated from "service" traffic as easily=20 > as PING. Once I've parsed the request type I immediately=20 > know that I'm dealing with a special case and can shunt=20 > processing over to a separate chunk of code that can=20 > ignore much of the message. > > > For instance, here would be a very simple way of parsing a PING: >=20 > 1. Is the request type of the message "PING". If so, then shunt... > 2. In the shunt parser take the original packet the PING came in on=20 > and do the following: > Replace the top of the buffer from "PING sip:xxxyyyzzz... SIP/2.0"=20 > to "SIP/2.0 200". Pad the remainder with white space until you hit=20 > the CRLF that terminates the request URI. > 3. Append the correct header information to bottom of the packet=20 > to identify the source of the request. > 4. Send the packet back from whence it came. > > (Potentially) no data that needs to be copied and nothing other=20 > than the first five characters of the message needs to be parsed. Regards, Erkki=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 sip-bounces@ietf.org Fri Feb 17 11:53:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA8rg-0003Zr-6U; Fri, 17 Feb 2006 11:53:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA8re-0003ZG-IT for sip@megatron.ietf.org; Fri, 17 Feb 2006 11:53:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09597 for ; Fri, 17 Feb 2006 11:52:01 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA966-0004SV-Gu for sip@ietf.org; Fri, 17 Feb 2006 12:08:47 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 17 Feb 2006 08:53:40 -0800 X-IronPort-AV: i="4.02,124,1139212800"; d="scan'208"; a="406613963:sNHT34074692" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1HGrdWF005311; Fri, 17 Feb 2006 08:53:40 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Feb 2006 11:53:39 -0500 Received: from [192.168.1.101] ([10.86.242.129]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Feb 2006 11:53:38 -0500 Message-ID: <43F5FF91.8010200@cisco.com> Date: Fri, 17 Feb 2006 11:53:37 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: darshanb@huawei.com Subject: Re: [Sip] Outbound and STUN Keep Alive References: <000001c63377$8cdbfcf0$8a03120a@china.huawei.com> In-Reply-To: <000001c63377$8cdbfcf0$8a03120a@china.huawei.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Feb 2006 16:53:38.0991 (UTC) FILETIME=[B3450BF0:01C633E2] X-Spam-Score: 2.2 (++) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: 'Cullen Jennings' , fwmiller@cornfed.com, 'Dean Willis' , sip@ietf.org, 'Francois Audet' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org No, multicast does not help. The NAT bindings must be kept alive by a packet that has the same 5-tuple information as later SIP packets to be delivered by the SIP proxy. -Jonathan R. Darshan Bildikar wrote: > Couldn't this problem also be solved using some kind of multicast mechanism? > > All SIP UA's registered to a proxy form a multicast group and express an > interest in receiving keep alive multicast packets.. The proxy sends out > keep alive packets to a multicast IP... > > The UA's have a timeout mechanism ... say they don't receive keep alive > packets for a pre defined duration (say one minute) then they consider the > link broken. Load on the proxy is also greatly reduced. > > Am thinking only from the point of view of a keep alive mechanism... not > refreshing NAT bindings. > > Just a thought. > > Darshan > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean > Willis > Sent: Friday, February 17, 2006 3:50 AM > To: Gary Gan > Cc: 'Cullen Jennings'; sip@ietf.org; 'Francois Audet'; fwmiller@cornfed.com > Subject: Re: [Sip] Outbound and STUN Keep Alive > > On Feb 16, 2006, at 3:23 PM, Gary Gan wrote: > >>The only problem I can think of is that the UA doesn't know if the >>server is >>down between now and the next SIP REGISTER is sent. > > > Right, that's exactly the problem we're trying to solve. Keeping the > NAT alive is only half the problem -- knowing when it has died and we > need to renegotiate is the other half. > > Sure, we could REGISTER every 15 seconds, but I'm POSITIVE that's > going to slow things down . . . > > -- > 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.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 sip-bounces@ietf.org Fri Feb 17 11:57:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA8v5-0004bl-7d; Fri, 17 Feb 2006 11:57:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA8v2-0004bd-BS for sip@megatron.ietf.org; Fri, 17 Feb 2006 11:57:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09959 for ; Fri, 17 Feb 2006 11:55:31 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA99U-0004cG-DA for sip@ietf.org; Fri, 17 Feb 2006 12:12:17 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 17 Feb 2006 08:57:11 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,124,1139212800"; d="scan'208"; a="22118789:sNHT24822528" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1HGurPY003017; Fri, 17 Feb 2006 11:57:08 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Feb 2006 11:57:04 -0500 Received: from [192.168.1.101] ([10.86.242.129]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Feb 2006 11:57:04 -0500 Message-ID: <43F6005F.9030202@cisco.com> Date: Fri, 17 Feb 2006 11:57:03 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Froment Subject: Re: [Sip] Outbound and STUN Keep Alive References: <6FC4416DDE56C44DA0AEE67BC7CA43710CF540FE@zrc2hxm2.corp.nortel.com> <43F5E3D2.1080807@alcatel.fr> In-Reply-To: <43F5E3D2.1080807@alcatel.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Feb 2006 16:57:04.0464 (UTC) FILETIME=[2DBDBD00:01C633E3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Brian Stucker X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Actually, having a special code path that processes this SIP PING in a fundamentally different way is worse, IMHO. You are not only basically muxing a separate protocol on the same port anyway, you are breaking SIP by applying non-standard processing to it. I think you stand a much worse chance of interop failures with an implementation that processes SIP in a non-standard way. A client might send a PING, assuming it gets processed correctly, and then gets surprised when its basically being treated like a STUN request formatted as a sip mesage. How about we just send that stun request in the first place. -Jonathan R. Thomas Froment wrote: > Brian Stucker wrote: > >> How can you send a 200 OK without parsing out the Via header fields? >> How do you get the cseq without parsing that out? >> >> -- Don't. Send the message back where it came from using the transport >> information in the packet and reuse the existing information in the >> request to form a valid response. You only need to add information to >> the end of the packet (in the form of a message body or header) to >> report what you saw from the UA in terms of their observed network >> address. >> >> Very fast. Of course the UA gets to eat it's own dog food if it sends >> something bad in the request. >> >> > If you don't look at Via header to answer a SIP request, and just send a > "packet" back to the source IP Address/port, you are not doing SIP anymore, > you are doing a "hack". In this case, this is no more "clean" than > double CR/LF or STUN. > Just to insist a last time on this topic: the most important point for > me is *consistency* with other parts of sip-outbound draft, as Chris > mentionned: "It is already specified for UDP in the Outbound draft", so > why not use the same thing for TCP? > > > > > _______________________________________________ > 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 Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.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 sip-bounces@ietf.org Fri Feb 17 11:57:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA8vE-0004cv-4A; Fri, 17 Feb 2006 11:57:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA8vC-0004cZ-DH for sip@megatron.ietf.org; Fri, 17 Feb 2006 11:57:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09964 for ; Fri, 17 Feb 2006 11:55:41 -0500 (EST) Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA99e-0004cc-B4 for sip@ietf.org; Fri, 17 Feb 2006 12:12:27 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k1HGvJWq068072; Fri, 17 Feb 2006 11:57:23 -0500 (EST) From: "Brett Tate" To: "'Thomas Froment'" Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Fri, 17 Feb 2006 11:58:11 -0500 Message-ID: <001a01c633e3$59651f70$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <43F5E3D2.1080807@alcatel.fr> Importance: Normal X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > If you don't look at Via header to answer a SIP request, > and just send a "packet" back to the source IP Address/port, > you are not doing SIP anymore, you are doing a "hack". How is it a hack to define a new SIP request which by definition requires rport added to Via (or similar mechanism to request source only) and Max-Forwards is 0 (or something similar mechanism to avoid it being proxied)? _______________________________________________ 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 sip-bounces@ietf.org Fri Feb 17 11:57:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA8vV-0004hQ-GR; Fri, 17 Feb 2006 11:57:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA8vU-0004h1-1N for sip@megatron.ietf.org; Fri, 17 Feb 2006 11:57:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09987 for ; Fri, 17 Feb 2006 11:55:58 -0500 (EST) Received: from web8601.mail.in.yahoo.com ([202.43.219.76]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FA99v-0004cq-6H for sip@ietf.org; Fri, 17 Feb 2006 12:12:45 -0500 Received: (qmail 55262 invoked by uid 60001); 17 Feb 2006 16:57:34 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ugmb3t6GWiaPThykYIWr4d/us5KgQq0+Z8wD3dup3jnGSDcmQWjPRSbB3cX3SJi8kK7wnEJLBPWp3eCEVYWyOmgik93xMsDqIFJl/1a5gPRLh7OVW/+iguwu24QIwKik7OrHRKhOV7OmWdkI9XnwHPWfBN3i60EVNo7np9kRP5c= ; Message-ID: <20060217165734.55260.qmail@web8601.mail.in.yahoo.com> Received: from [210.214.40.200] by web8601.mail.in.yahoo.com via HTTP; Fri, 17 Feb 2006 16:57:34 GMT Date: Fri, 17 Feb 2006 16:57:34 +0000 (GMT) From: "Thejeswara Reddy.P" Subject: RE: [Sip] Record-Route To: Atul kumar Jha , Marqui Peter-E50322 , Rayees Khan In-Reply-To: <22F058C3ED9D784E90CE473F2A9847F03E36F5@in-exchange> MIME-Version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: sip@ietf.org, sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1968997670==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1968997670== Content-Type: multipart/alternative; boundary="0-646399050-1140195454=:55253" Content-Transfer-Encoding: 8bit --0-646399050-1140195454=:55253 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit to add more, because endpoint has nothing to do with Record-route header. regards theja Atul kumar Jha wrote: v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} st1\:*{behavior:url(#default#ieooui) } Hi Peter, In your example, Record-Route header is getting reverted in the response. But as we go by section 16.12.1.1 of RFC 3261 and section 3.2 of the RFC 3665 (see the F12 message) we should maintain the same order of Record-Route in the response. It should not be reverted in the response. It should be same as you got in your INVITE. Regards, Atul --------------------------------- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Marqui Peter-E50322 Sent: Thursday, February 16, 2006 11:21 PM To: Rayees Khan Cc: sip@ietf.org; sip-implementors@cs.columbia.edu Subject: RE: [Sip] Record-Route Hi Rayees, I'm not sure I follow you Do you mean my example is correct or that the Record-Route sent in the response is exactly what was received by the callee in the INVITE request ? It is not built as the response traversew the path from U2 to U1 --------------------------------- From: Rayees Khan [mailto:rayees.khan@flextronicssoftware.com] Sent: Thursday, February 16, 2006 11:32 AM To: Marqui Peter-E50322 Cc: sip-implementors@cs.columbia.edu; sip@ietf.org Subject: Re: [Sip] Record-Route Hi Peter, If we go by Section 16.12.1.1 of RFC 3261 the Record-Route stack of response seems to be inverted. The record-route stack in response is maintained as it is build along traversal of request. regards Rayees -----sip-bounces@ietf.org wrote: ----- To: , From: "Marqui Peter-E50322" Sent by: sip-bounces@ietf.org Date: 02/16/2006 05:20PM Subject: [Sip] Record-Route Should the Record-Route fields between the calling and called party be symmetrical ? Or the same for each direction ? U1->P1->P2->P3->P4->U2 The INVITE arriving at U2 contains: INVITE sip:callee@u2.domain.com SIP/2.0 Contact: sip:caller@u1.example.com Record-Route: Record-Route: Record-Route: Record-Route: While subsequent messages arriving at U1 from U2 would take the following path: U2->P4->P3->P2->P1>U1 And the Record-Route header would be as follows SIP/2.0 200 OK Contact: sip:callee@u2.domain.com Record-Route: Record-Route: Record-Route: Record-Route: Peter Marqui Motorola MDB, Libertyville Email: peter.marqui@motorola.com Phone: 847-523-0584 Mobile: 847- _______________________________________________ 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 *****FSS-Private *****" DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from 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 --------------------------------- Jiyo cricket on Yahoo! India cricket Yahoo! Messenger Mobile Stay in touch with your buddies all the time. --0-646399050-1140195454=:55253 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit to add more,
because endpoint has nothing to do with Record-route header.

regards
theja

Atul kumar Jha <atulkumar.jha@ccpu.com> wrote:
 
Hi Peter,
 
In your example, Record-Route header is getting reverted in the response.
But as we go by section 16.12.1.1 of RFC 3261 and section 3.2 of the RFC 3665 (see the F12 message) we should maintain the same order of Record-Route in the response.
It should not be reverted in the response.
It should be same as you got in your INVITE.
 
Regards,
Atul
 
 
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Marqui Peter-E50322
Sent: Thursday, February 16, 2006 11:21 PM
To: Rayees Khan
Cc: sip@ietf.org; sip-implementors@cs.columbia.edu
Subject: RE: [Sip] Record-Route
 
Hi Rayees,
 
I'm not sure I follow you
Do you mean my example is correct or that the Record-Route sent in the response is exactly what was received b! y the callee in the INVITE request ?
It is not built as the response traversew the path from U2 to U1

 
From: Rayees Khan [mailto:rayees.khan@flextronicssoftware.com]
Sent: Thursday, February 16, 2006 11:32 AM
To: Marqui Peter-E50322
Cc: sip-implementors@cs.columbia.edu; sip@ietf.org
Subject: Re: [Sip] Record-Route
Hi Peter,

If we go by Section 16.12.1.1 of RFC 3261 the Record-Route stack of response seems to be inverted. The record-route stack in response is maintained as it is build along traversal of request.


regards
Rayees



-----sip-bounces@ietf.org wrote: -----
To: <sip-implementors@cs.columbia.edu>, <sip@ietf.org>
From: "Marqui Peter-E50322" <peter.marqui@motorola.com>
Sent by: sip-bounces@ietf.org
Date: 02/16/2006 05:20PM
Subject: [Sip] Record-Route
Should the Record-Route fields between the calling and called party be symmetrical ?
Or the same for each direction ?
    U1->P1->P2->P3->P4->U2
The INVITE arriving at U2 contains:
      INVITE sip:callee@u2.domain.com SIP/2.0
      Contact: sip:caller@u1.example.com
      Record-Route: <sip:p4.domain.com;lr>
      Record-Route: <sip:p3.middle.com>
      Record-Route: <sip:p2.example.com;lr>
      Record-Route: <sip:p1.example.com;lr>
!
While subsequent messages arriving at U1 from U2 would take the following path:      U2->P4->P3->P2->P1>U1
And the Record-Route header would be as follows
      SIP/2.0 200 OK
      Contact: sip:callee@u2.domain.com 
      Record-Route: <sip:p1.example.com;lr>
      Record-Route: <sip:p2.example.com;lr>
      Record-Route: <sip:p3.middle.com>
      Record-Route: <sip:p4.domain.com;lr>
Peter Marqui
Motorola MDB, Libertyville
Email: &nbs! p;  peter.marqui@motorola.com
Phone:  847-523-0584
Mobile:  847-
_______________________________________________
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


*****FSS-Private *****" DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the inf! ormation transmitted by this email including damage from 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

Jiyo cricket on Yahoo! India cricket
Yahoo! Messenger Mobile Stay in touch with your buddies all the time. --0-646399050-1140195454=:55253-- --===============1968997670== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1968997670==-- From sip-bounces@ietf.org Fri Feb 17 12:00:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA8xy-0005WY-Iv; Fri, 17 Feb 2006 12:00:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA8xw-0005W3-Fd for sip@megatron.ietf.org; Fri, 17 Feb 2006 12:00:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10189 for ; Fri, 17 Feb 2006 11:58:31 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA9CM-0004ig-2A for sip@ietf.org; Fri, 17 Feb 2006 12:15:17 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 17 Feb 2006 09:00:07 -0800 X-IronPort-AV: i="4.02,124,1139212800"; d="scan'208"; a="406617697:sNHT34617200" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1HH02WH010037; Fri, 17 Feb 2006 09:00:04 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Feb 2006 12:00:03 -0500 Received: from [192.168.1.101] ([10.86.242.129]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Feb 2006 12:00:02 -0500 Message-ID: <43F60111.1080202@cisco.com> Date: Fri, 17 Feb 2006 12:00:01 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gary Gan Subject: Re: [Sip] Outbound and STUN Keep Alive References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Feb 2006 17:00:02.0697 (UTC) FILETIME=[97F9EF90:01C633E3] X-Spam-Score: 2.2 (++) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Cc: 'Cullen Jennings' , sip@ietf.org, 'Francois Audet' , fwmiller@cornfed.com, 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The functional benefit of STUN over CRLF is two things: 1. a clear transaction ID that makes it EASIER to do timeouts. Its possible without it, just more difficult. 2. more importantly, it allows you, for UDP, to detect a reboot of the NAT. STUN will echo back the source port in MAPPED_ADDRESS. The UA can look at this and detect nat reboot. Without this, you won't notice it for an entire registration interval and thus effectively have a service outage. Imagine this happening at an enterprise with SIP phones and the server provided by a service provider on the public side of the nat. Basically, a reboot of the enterprise nat would result in a total system outage for an entire hour. There needs to be a way to avoid this. -Jonathan R. Gary Gan wrote: > Are we overkilling this issue by inventing a new keep-alive mechanism that > could potentially overload the server by 90% more, just to resolve a > down-time situation, which can be automatically recovered anyway but just > delayed for a few minutes? But I have to agree that some UA implementation > defaults the SIP REGISTER expiry time to 1 hour, in which case the problem > would be more severe. > > So the problem becomes the UA polling for the healthy of the server, > probably the healthy of the logical UDP binding. To let the server echo the > simple keep-alive, such as CRLF, probably is enough for this issue. It > doesn't introduce too much overhead to the server and network. > Theoretically, the echo back CRLF can get lost, but it can be handled in the > UA side by retransmitting the keep-alive polling when it can not find the > response. If it fails a few times, the UA can declare the server down, out > of service. > > By introducing the multiplexing of STUN server with SIP server for the > purpose of keep-alive, I don't see obvious more benefits than a simple > PING/PONG mechanism. I agree to use STUN, ICE on the side to solve the > firewall traversal. But it would be only per restart of UA or per call > basis. Not constant polling even when it is idle. > > Some IP service provider may change the NAT IP address on the daily basis, > but I don't believe it would change it when there is a keep-alive message > going on in a period of like 15 seconds, even though the message is short. > > Gary Gan > Sr. Software Developer > > Clique Communications, LLC > 205 Rockingham Row > Princeton Forrestal Village > Princeton, NJ 08540 > Phone: 609-564-0206 > > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Thursday, February 16, 2006 5:20 PM > To: Gary Gan > Cc: 'Francois Audet'; 'Cullen Jennings'; sip@ietf.org; fwmiller@cornfed.com > Subject: Re: [Sip] Outbound and STUN Keep Alive > > On Feb 16, 2006, at 3:23 PM, Gary Gan wrote: > >>The only problem I can think of is that the UA doesn't know if the >>server is >>down between now and the next SIP REGISTER is sent. > > > Right, that's exactly the problem we're trying to solve. Keeping the > NAT alive is only half the problem -- knowing when it has died and we > need to renegotiate is the other half. > > Sure, we could REGISTER every 15 seconds, but I'm POSITIVE that's > going to slow things down . . . > > -- > 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.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 sip-bounces@ietf.org Fri Feb 17 12:19:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA9CI-0000lS-GJ; Fri, 17 Feb 2006 12:15:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA9CF-0000iQ-Fw for sip@megatron.ietf.org; Fri, 17 Feb 2006 12:15:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11748 for ; Fri, 17 Feb 2006 12:13:20 -0500 (EST) Received: from smail3.alcatel.fr ([62.23.212.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA9Qh-0005Nu-Dt for sip@ietf.org; Fri, 17 Feb 2006 12:30:04 -0500 Received: from missrv1.nextenso.alcatel.fr (proxy.nextenso.alcatel.fr [139.54.130.250]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id k1HHEnT4032631; Fri, 17 Feb 2006 18:14:49 +0100 Received: from [139.54.131.75] (nx1075.nextenso.alcatel.fr [139.54.131.75]) by missrv1.nextenso.alcatel.fr (8.12.8/8.12.8) with ESMTP id k1HHEjsY007352; Fri, 17 Feb 2006 18:14:45 +0100 Message-ID: <43F60487.9060605@alcatel.fr> Date: Fri, 17 Feb 2006 18:14:47 +0100 From: Thomas Froment Organization: Alcatel User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brett Tate Subject: Re: [Sip] Outbound and STUN Keep Alive References: <001a01c633e3$59651f70$2c28a8c0@brett1> In-Reply-To: <001a01c633e3$59651f70$2c28a8c0@brett1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Brett Tate wrote: >>If you don't look at Via header to answer a SIP request, >>and just send a "packet" back to the source IP Address/port, >>you are not doing SIP anymore, you are doing a "hack". >> >> > >How is it a hack to define a new SIP request which by definition requires >rport added to Via (or similar mechanism to request source only) and >Max-Forwards is 0 (or something similar mechanism to avoid it being >proxied)? > > rport does not modify the way you handle the request, from RFC 3261 point of view, you still create a Server Transaction to answer and to handle retransmissions (parsing via and using branch parameter + sent-by of Via as transaction ID)... If I understood well, your suggestion was to completely skip these steps and just answer to the transport source port/ip... thus, that's why I say this is no more a SIP response... _______________________________________________ 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 sip-bounces@ietf.org Fri Feb 17 12:50:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA9k1-0002pS-Vj; Fri, 17 Feb 2006 12:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA9k0-0002oz-DG for sip@megatron.ietf.org; Fri, 17 Feb 2006 12:50:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16076 for ; Fri, 17 Feb 2006 12:48:12 -0500 (EST) Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA9yS-0007Pb-Us for sip@ietf.org; Fri, 17 Feb 2006 13:04:58 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k1HHnpPj073067; Fri, 17 Feb 2006 12:49:55 -0500 (EST) From: "Brett Tate" To: "'Thomas Froment'" Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Fri, 17 Feb 2006 12:50:43 -0500 Message-ID: <002001c633ea$b03c6630$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <43F60487.9060605@alcatel.fr> Importance: Normal X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > > How is it a hack to define a new SIP request which > > by definition requires rport added to Via (or similar > > mechanism to request source only) and Max-Forwards > > is 0 (or something similar mechanism to avoid it > > being proxied)? > > > > > rport does not modify the way you handle the request, > from RFC 3261 point of view, you still create a > Server Transaction to answer and to handle > retransmissions (parsing via and using branch > parameter + sent-by of Via as transaction ID)... > If I understood well, your suggestion was to > completely skip these steps and just answer to > the transport source port/ip... thus, > that's why I say this is no more a SIP response... RFC 3261 does not limit how vendors optimize their stacks. And draft-ietf-sip-guidelines does not preclude extensions which do not require full parsing and analysis of a received request and response. Thus if vendor doesn't want to optimize their stack for the SIP extension, they don't have to do so. _______________________________________________ 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 sip-bounces@ietf.org Fri Feb 17 12:52:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA9mn-0003lt-BA; Fri, 17 Feb 2006 12:52:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA9ml-0003lj-RE for sip@megatron.ietf.org; Fri, 17 Feb 2006 12:52:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16374 for ; Fri, 17 Feb 2006 12:51:04 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAA1F-0007Wy-Bf for sip@ietf.org; Fri, 17 Feb 2006 13:07:49 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1HHqqn8015281 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 17 Feb 2006 11:52:54 -0600 In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43710CF5372C@zrc2hxm2.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA43710CF5372C@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <755B46A2-76CF-4494-8D25-CBC41ABA783C@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Fri, 17 Feb 2006 11:52:46 -0600 To: Brian Stucker X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , sip@ietf.org, Francois Audet , fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 15, 2006, at 10:10 PM, Brian Stucker wrote: > Dean, et. al- > > Keep in mind one thing in your calculations... Parsing a MESSAGE > that is short (which may or may not be a message that needs further > processing) cannot be separated from "service" traffic as easily as > PING. Once I've parsed the request type I immediately know that I'm > dealing with a special case and can shunt processing over to a > separate chunk of code that can ignore much of the message. > > For instance, here would be a very simple way of parsing a PING: > > 1. Is the request type of the message "PING". If so, then shunt... > 2. In the shunt parser take the original packet the PING came in on > and do the following: > Replace the top of the buffer from "PING sip:xxxyyyzzz... SIP/2.0" > to "SIP/2.0 200". Pad the remainder with white space until you hit > the CRLF that terminates the request URI. > 3. Append the correct header information to bottom of the packet to > identify the source of the request. > 4. Send the packet back from whence it came. > > (Potentially) no data that needs to be copied and nothing other > than the first five characters of the message needs to be parsed. I believe in the test case that I'm reporting that the MESSAGE response processing was short-circuited, and the test stack wouldn't have processed any MESSAGE request correctly. So I think the 3-1 ratio would apply to PING, even though the typical "full request processing" number may be more like 10-1. But where are you assuming you send your response to if you don't parse Via? rport? What about asymmetric nodes and semitransparent proxies? -- 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 sip-bounces@ietf.org Fri Feb 17 12:54:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA9oR-00049d-TW; Fri, 17 Feb 2006 12:54:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA9oP-00049I-Pj for sip@megatron.ietf.org; Fri, 17 Feb 2006 12:54:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16538 for ; Fri, 17 Feb 2006 12:52:46 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAA2t-0007aq-86 for sip@ietf.org; Fri, 17 Feb 2006 13:09:31 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1HHsYoJ015304 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 17 Feb 2006 11:54:36 -0600 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF06D89EF2@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF06D89EF2@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Fri, 17 Feb 2006 11:54:28 -0600 To: Francois Audet X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , sip@ietf.org, fwmiller@cornfed.com, Trip Ingle , Brian Stucker X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 16, 2006, at 5:39 PM, Francois Audet wrote: > Those numbers are flawed. > > Processing a PING request is (if you optimize it properly) a lot > less intensive then processing, say, an INVITE request or any other > normal request. The 3-1 number was based on a short-circuited stack that did no processing of the MESSAGE request and just responded as quickly as possible. Now, maybe it could be optimized a little bit more, but I suspect not much. -- 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 sip-bounces@ietf.org Fri Feb 17 13:49:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAAfc-0006M6-7d; Fri, 17 Feb 2006 13:49:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAAfa-0006L2-GO for sip@megatron.ietf.org; Fri, 17 Feb 2006 13:49:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21282 for ; Fri, 17 Feb 2006 13:47:42 -0500 (EST) Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAAu0-0001jt-Ic for sip@ietf.org; Fri, 17 Feb 2006 14:04:28 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k1HInLGM078310; Fri, 17 Feb 2006 13:49:25 -0500 (EST) From: "Brett Tate" To: "'Dean Willis'" Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Fri, 17 Feb 2006 13:50:14 -0500 Message-ID: <002101c633f3$00000a70$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <755B46A2-76CF-4494-8D25-CBC41ABA783C@softarmor.com> Importance: Normal X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > But where are you assuming you send your response to > if you don't parse Via? rport? What about asymmetric > nodes and semitransparent proxies? Concerning the where, I discuss an option within http://www1.ietf.org/mail-archive/web/sip/current/msg12882.html and http://www1.ietf.org/mail-archive/web/sip/current/msg12873.html What aspects of a semitransparent proxy do you foresee a problem? What should be sent until both devices finally support STUN as suggested? _______________________________________________ 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 sip-bounces@ietf.org Fri Feb 17 14:05:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAAv1-000274-Qk; Fri, 17 Feb 2006 14:05:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAAuz-000259-L6 for sip@megatron.ietf.org; Fri, 17 Feb 2006 14:05:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22389 for ; Fri, 17 Feb 2006 14:03:37 -0500 (EST) Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAB9P-0002KT-DK for sip@ietf.org; Fri, 17 Feb 2006 14:20:24 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id AD0686C01D for ; Fri, 17 Feb 2006 14:05:17 -0500 (EST) Subject: Re: [Sip] Re: REGISTRAR behavior From: "Dale R. Worley" To: Sip In-Reply-To: <6affd5140602161523y4e475432wdaf4f65bc99332b8@mail.gmail.com> References: <6affd5140602161139j838afa4qe292d4e84dac53c9@mail.gmail.com> <6affd5140602161523y4e475432wdaf4f65bc99332b8@mail.gmail.com> Content-Type: text/plain Date: Fri, 17 Feb 2006 14:03:32 -0500 Message-Id: <1140203013.4428.28.camel@maine.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Thu, 2006-02-16 at 15:23 -0800, Raja Chilla wrote: > Guess this has been asked before. Can REGISTRAR lower the > expiration interval in expires field (from one requested by > client originally) in its 200 OK response? RFC 3261 section 10.3 item 7: "The registrar MAY choose an expiration less than the requested expiration interval. If and only if the requested expiration interval is greater than zero AND smaller than one hour AND less than a registrar-configured minimum, the registrar MAY reject the registration with a response of 423 (Interval Too Brief)." Dale _______________________________________________ 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 sip-bounces@ietf.org Fri Feb 17 14:13:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAB2z-0004eH-D1; Fri, 17 Feb 2006 14:13:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAB2y-0004eB-3T for sip@megatron.ietf.org; Fri, 17 Feb 2006 14:13:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22943 for ; Fri, 17 Feb 2006 14:11:52 -0500 (EST) Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FABHR-0002dq-E4 for sip@ietf.org; Fri, 17 Feb 2006 14:28:38 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k1HJDXSM080503; Fri, 17 Feb 2006 14:13:37 -0500 (EST) From: "Brett Tate" To: "'Cullen Jennings'" Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Fri, 17 Feb 2006 14:14:26 -0500 Message-ID: <002201c633f6$617f4560$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Importance: Normal X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > I don't see any reason that the PING will work > better than just sending OPTIONS It doesn't have to be PING or PING as currently defined. It could be any new SIP method which by definition indicates that parsing the rest of the message is ok but not really needed. The problem with OPTIONS is that it requires the typical full processing to identify the target, identify a willing to produce a successful response, produce the full successful OPTIONS data, and adhere to potential forking concerns. _______________________________________________ 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 sip-bounces@ietf.org Fri Feb 17 14:25:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FABEJ-0007cd-4H; Fri, 17 Feb 2006 14:25:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FABEG-0007cP-Rs for sip@megatron.ietf.org; Fri, 17 Feb 2006 14:25:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23880 for ; Fri, 17 Feb 2006 14:23:32 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FABSg-0003D8-SV for sip@ietf.org; Fri, 17 Feb 2006 14:40:19 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1HJPJlY015796 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 17 Feb 2006 13:25:20 -0600 In-Reply-To: <002101c633f3$00000a70$2c28a8c0@brett1> References: <002101c633f3$00000a70$2c28a8c0@brett1> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Fri, 17 Feb 2006 13:25:12 -0600 To: "Brett Tate" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 17, 2006, at 12:50 PM, Brett Tate wrote: >> But where are you assuming you send your response to >> if you don't parse Via? rport? What about asymmetric >> nodes and semitransparent proxies? > > Concerning the where, I discuss an option within > > http://www1.ietf.org/mail-archive/web/sip/current/msg12882.html > > and > > http://www1.ietf.org/mail-archive/web/sip/current/msg12873.html > > > What aspects of a semitransparent proxy do you foresee a problem? > I believe it's possible to get a request for which the response cannot be routed back to the IP address and port it was received from. That is, you'd have to obey the Via. > What should be sent until both devices finally support STUN as > suggested? OPTIONS, I believe. -- 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 sip-bounces@ietf.org Fri Feb 17 15:03:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FABpA-00030m-Ez; Fri, 17 Feb 2006 15:03:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FABp8-00030X-VA for sip@megatron.ietf.org; Fri, 17 Feb 2006 15:03:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29685 for ; Fri, 17 Feb 2006 15:01:38 -0500 (EST) Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAC3c-0005og-NK for sip@ietf.org; Fri, 17 Feb 2006 15:18:25 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k1HK3KAO094130; Fri, 17 Feb 2006 15:03:24 -0500 (EST) From: "Brett Tate" To: "'Dean Willis'" Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Fri, 17 Feb 2006 15:04:13 -0500 Message-ID: <002701c633fd$561c8550$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Importance: Normal X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > I believe it's possible to get a request for which=20 > the response cannot be routed back to the IP address=20 > and port it was received from. That is, you'd have=20 > to obey the Via. For the intended use over connection oriented protocols, the source port = and source address are only really desired. For UPD, I potentially agree. However the need could be clearly = indicated by definition of the request. For instance ECHO could be defined to = process Via as usual. And ECHOSRC could be defined so that sending to more than source address and source port is not needed. > > What should be sent until both devices finally=20 > > support STUN as suggested? >=20 > OPTIONS, I believe. Because some vendors would likely be slow to implement or never = implement it, would it be beneficial to define a new easily optimized SIP request = for this purpose? _______________________________________________ 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 sip-bounces@ietf.org Fri Feb 17 15:06:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FABrn-0003yj-M7; Fri, 17 Feb 2006 15:06:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FABrk-0003xb-0r for sip@megatron.ietf.org; Fri, 17 Feb 2006 15:06:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29908 for ; Fri, 17 Feb 2006 15:04:19 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAC6D-0005xS-Hq for sip@ietf.org; Fri, 17 Feb 2006 15:21:07 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1HK6AFa015995 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 17 Feb 2006 14:06:11 -0600 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <22291FAB-987C-4AE6-8B14-D5622E2C9D6B@softarmor.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "sip@ietf.org List" From: Dean Willis Date: Fri, 17 Feb 2006 14:06:03 -0600 X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Subject: [Sip] Any more WG -00 drafts before cutoff X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I'm expecting Jonathan to submit a draft on route construction and Robert to submit a draft on avoiding the cascade problem from hell discussed at the last meeting. Are there any other new -00 drafts we're expecting? If so, let's remind the chairs, as we need to pre-approve publication. -- 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 sip-bounces@ietf.org Fri Feb 17 15:08:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FABuP-0004ly-AZ; Fri, 17 Feb 2006 15:08:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FABuM-0004le-ND for sip@megatron.ietf.org; Fri, 17 Feb 2006 15:08:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00244 for ; Fri, 17 Feb 2006 15:07:02 -0500 (EST) Received: from [66.155.254.250] (helo=isdmail1.inovsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAC8q-000680-Ao for sip@ietf.org; Fri, 17 Feb 2006 15:23:49 -0500 Received: from greatwall ([12.181.128.3]) by isdmail1.inovsys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 17 Feb 2006 15:08:38 -0500 From: "Gary Gan" To: "'Dean Willis'" , "'Brett Tate'" Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Fri, 17 Feb 2006 15:08:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYz+Axs1Tqo+J3eQSOaXUs3ll2tFQAA/KYQ Message-ID: X-OriginalArrivalTime: 17 Feb 2006 20:08:39.0038 (UTC) FILETIME=[F10A89E0:01C633FD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org We tried to use OPTIONS as keep-alive, but found not very practical. It ends up on the server side you will see almost all traffics are OPTIONS, as each client is sending its own keep-alive (in 15-30 seconds interval). In case like Vonage server, it doesn't response to SIP OPTION message, the UA would trigger retransmission which further jams the server. You would see each OPTION actually being sent 5-6 times within 10 seconds for the SIP stack just trying to get the OPTION request go through. Currently we use double CRLF, it keeps the NAT binding alive, but in case of NAT reboot, it is still a problem. The UA wouldn't know if the NAT is rebooted (the addr/port mapping may be changed), until the next time it re-registers to SIP registrar. Gary Gan Sr. Software Developer Clique Communications, LLC 205 Rockingham Row Princeton Forrestal Village Princeton, NJ 08540 Phone: 609-564-0206 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean Willis Sent: Friday, February 17, 2006 2:25 PM To: Brett Tate Cc: sip@ietf.org Subject: Re: [Sip] Outbound and STUN Keep Alive On Feb 17, 2006, at 12:50 PM, Brett Tate wrote: >> But where are you assuming you send your response to >> if you don't parse Via? rport? What about asymmetric >> nodes and semitransparent proxies? > > Concerning the where, I discuss an option within > > http://www1.ietf.org/mail-archive/web/sip/current/msg12882.html > > and > > http://www1.ietf.org/mail-archive/web/sip/current/msg12873.html > > > What aspects of a semitransparent proxy do you foresee a problem? > I believe it's possible to get a request for which the response cannot be routed back to the IP address and port it was received from. That is, you'd have to obey the Via. > What should be sent until both devices finally support STUN as > suggested? OPTIONS, I believe. -- 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 sip-bounces@ietf.org Fri Feb 17 15:12:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FABxX-0005Zk-KR; Fri, 17 Feb 2006 15:12:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FABxV-0005Y1-Lf for sip@megatron.ietf.org; Fri, 17 Feb 2006 15:12:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00536 for ; Fri, 17 Feb 2006 15:10:14 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FACBw-0006Ho-D4 for sip@ietf.org; Fri, 17 Feb 2006 15:27:01 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1HKC3md016011 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 17 Feb 2006 14:12:05 -0600 In-Reply-To: <002701c633fd$561c8550$2c28a8c0@brett1> References: <002701c633fd$561c8550$2c28a8c0@brett1> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2C7213DE-C04F-4DC9-8840-790C14C4401A@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Fri, 17 Feb 2006 14:11:57 -0600 To: "Brett Tate" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 17, 2006, at 2:04 PM, Brett Tate wrote: > > >>> What should be sent until both devices finally >>> support STUN as suggested? >> >> OPTIONS, I believe. > > Because some vendors would likely be slow to implement or never > implement > it, would it be beneficial to define a new easily optimized SIP > request for > this purpose? My guess is that if we have consensus on something like coaxial STUN that we would be better-served by pushing new development that way instead of adding another stepping-stone. If they aren't going to implement the preferred solution, having a less-optimal second choice available is probably not going to result in much more compliance, and will cause a fair amount of sustained divergence. Would it be reasonable to give guidance on use of OPTIONS as a keepalive and on optimization of OPTIONS request processing in UAs? -- 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 sip-bounces@ietf.org Fri Feb 17 15:16:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAC25-00071i-E3; Fri, 17 Feb 2006 15:16:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAC23-00071G-4C for sip@megatron.ietf.org; Fri, 17 Feb 2006 15:16:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00999 for ; Fri, 17 Feb 2006 15:14:54 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56] helo=zrtps0kp.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FACGP-0006VE-GZ for sip@ietf.org; Fri, 17 Feb 2006 15:31:42 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k1HKGMT10456; Fri, 17 Feb 2006 15:16:23 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Outbound and STUN Keep Alive Date: Fri, 17 Feb 2006 14:16:20 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF06D8A9A1@zrc2hxm0.corp.nortel.com> Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcYxf8mgCB8XjZ1zEdqXIgARJEEJ/ACfxrew From: "Francois Audet" To: "Cullen Jennings" , , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org You can key on the "PING" at the begining of the packet (in=20 a fixed location, just like the STUN alternative), and bypass all the normal SIP processing IF you need to "optimize". > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Cullen Jennings > Sent: Tuesday, February 14, 2006 08:01 > To: fwmiller@cornfed.com; Dean Willis > Cc: sip@ietf.org > Subject: Re: [Sip] Outbound and STUN Keep Alive >=20 >=20 >=20 > I don't see any reason that the PING will work better than=20 > just sending OPTIONS >=20 > On 2/13/06 6:06 PM, "Frank W. Miller" wrote: >=20 > >=20 > > I took the liberty of putting together a new draft that=20 > proposes the=20 > > PING method. The draft is at http://www.cornfed.com/ping.txt. =20 > > Comments welcome! > >=20 > > FM >=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 >=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 sip-bounces@ietf.org Fri Feb 17 15:41:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FACPe-0004GW-VR; Fri, 17 Feb 2006 15:41:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FACPb-0004Dy-Nz for sip@megatron.ietf.org; Fri, 17 Feb 2006 15:41:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02851 for ; Fri, 17 Feb 2006 15:39:19 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FACe6-0007dP-Ju for sip@ietf.org; Fri, 17 Feb 2006 15:56:07 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 17 Feb 2006 15:40:58 -0500 X-IronPort-AV: i="4.02,124,1139202000"; d="scan'208"; a="82651968:sNHT33299504" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1HKefPW011892; Fri, 17 Feb 2006 15:40:55 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Feb 2006 15:40:49 -0500 Received: from [192.168.1.101] ([10.86.240.43]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Feb 2006 15:40:48 -0500 Message-ID: <43F634D0.90104@cisco.com> Date: Fri, 17 Feb 2006 15:40:48 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Stucker Subject: Re: [Sip] Outbound and STUN Keep Alive References: <6FC4416DDE56C44DA0AEE67BC7CA43710CFAAFF2@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43710CFAAFF2@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Feb 2006 20:40:48.0677 (UTC) FILETIME=[6F321550:01C63402] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org No, of course not. It becomes a different protocol when you make exceptions to normal SIP processing rules because of the method. I believe it would be contrary to the intent of the spec, for example, to specify that, for a particular new method, Proxy-Require is not permitted. -Jonathan R. Brian Stucker wrote: > I don't follow... > > Lazy parsing a SIP message turns the message into a different protocol from SIP? > > Regards, > Brian > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Friday, February 17, 2006 10:57 AM > To: Thomas Froment > Cc: Stucker, Brian [RICH1:B620:EXCH]; sip@ietf.org > Subject: Re: [Sip] Outbound and STUN Keep Alive > > > Actually, having a special code path that processes this SIP PING in a > fundamentally different way is worse, IMHO. You are not only basically > muxing a separate protocol on the same port anyway, you are breaking SIP > by applying non-standard processing to it. I think you stand a much > worse chance of interop failures with an implementation that processes > SIP in a non-standard way. A client might send a PING, assuming it gets > processed correctly, and then gets surprised when its basically being > treated like a STUN request formatted as a sip mesage. How about we just > send that stun request in the first place. > > -Jonathan R. > > Thomas Froment wrote: > > >>Brian Stucker wrote: >> >> >>>How can you send a 200 OK without parsing out the Via header fields? >>>How do you get the cseq without parsing that out? >>> >>>-- Don't. Send the message back where it came from using the transport >>>information in the packet and reuse the existing information in the >>>request to form a valid response. You only need to add information to >>>the end of the packet (in the form of a message body or header) to >>>report what you saw from the UA in terms of their observed network >>>address. >>> >>>Very fast. Of course the UA gets to eat it's own dog food if it sends >>>something bad in the request. >>> >>> >> >>If you don't look at Via header to answer a SIP request, and just send a >>"packet" back to the source IP Address/port, you are not doing SIP anymore, >>you are doing a "hack". In this case, this is no more "clean" than >>double CR/LF or STUN. >>Just to insist a last time on this topic: the most important point for >>me is *consistency* with other parts of sip-outbound draft, as Chris >>mentionned: "It is already specified for UDP in the Outbound draft", so >>why not use the same thing for TCP? >> >> >> >> >>_______________________________________________ >>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 Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.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 sip-bounces@ietf.org Fri Feb 17 15:41:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FACQN-0004SC-Qa; Fri, 17 Feb 2006 15:41:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FACQM-0004S2-Ps for sip@megatron.ietf.org; Fri, 17 Feb 2006 15:41:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02917 for ; Fri, 17 Feb 2006 15:40:06 -0500 (EST) Received: from [66.155.254.250] (helo=isdmail1.inovsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FACeo-0007el-Hi for sip@ietf.org; Fri, 17 Feb 2006 15:56:53 -0500 Received: from greatwall ([12.181.128.3]) by isdmail1.inovsys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 17 Feb 2006 15:41:42 -0500 From: "Gary Gan" To: "'Jonathan Rosenberg'" Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Fri, 17 Feb 2006 15:41:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <43F60111.1080202@cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYz45/n8CKDpaCPScuaQQqOptD/VQAHpEEw Message-ID: X-OriginalArrivalTime: 17 Feb 2006 20:41:42.0213 (UTC) FILETIME=[8F1B0750:01C63402] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 7bit Cc: 'Cullen Jennings' , sip@ietf.org, 'Francois Audet' , fwmiller@cornfed.com, 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Why most SIP UA uses UDP protocol in first place. If it uses TCP, the UA will get notified by the TCP stack automatically if the server or NAT is down. Gary Gan Sr. Software Developer Clique Communications, LLC 205 Rockingham Row Princeton Forrestal Village Princeton, NJ 08540 Phone: 609-564-0206 -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] Sent: Friday, February 17, 2006 12:00 PM To: Gary Gan Cc: 'Dean Willis'; 'Cullen Jennings'; sip@ietf.org; 'Francois Audet'; fwmiller@cornfed.com Subject: Re: [Sip] Outbound and STUN Keep Alive The functional benefit of STUN over CRLF is two things: 1. a clear transaction ID that makes it EASIER to do timeouts. Its possible without it, just more difficult. 2. more importantly, it allows you, for UDP, to detect a reboot of the NAT. STUN will echo back the source port in MAPPED_ADDRESS. The UA can look at this and detect nat reboot. Without this, you won't notice it for an entire registration interval and thus effectively have a service outage. Imagine this happening at an enterprise with SIP phones and the server provided by a service provider on the public side of the nat. Basically, a reboot of the enterprise nat would result in a total system outage for an entire hour. There needs to be a way to avoid this. -Jonathan R. Gary Gan wrote: > Are we overkilling this issue by inventing a new keep-alive mechanism that > could potentially overload the server by 90% more, just to resolve a > down-time situation, which can be automatically recovered anyway but just > delayed for a few minutes? But I have to agree that some UA implementation > defaults the SIP REGISTER expiry time to 1 hour, in which case the problem > would be more severe. > > So the problem becomes the UA polling for the healthy of the server, > probably the healthy of the logical UDP binding. To let the server echo the > simple keep-alive, such as CRLF, probably is enough for this issue. It > doesn't introduce too much overhead to the server and network. > Theoretically, the echo back CRLF can get lost, but it can be handled in the > UA side by retransmitting the keep-alive polling when it can not find the > response. If it fails a few times, the UA can declare the server down, out > of service. > > By introducing the multiplexing of STUN server with SIP server for the > purpose of keep-alive, I don't see obvious more benefits than a simple > PING/PONG mechanism. I agree to use STUN, ICE on the side to solve the > firewall traversal. But it would be only per restart of UA or per call > basis. Not constant polling even when it is idle. > > Some IP service provider may change the NAT IP address on the daily basis, > but I don't believe it would change it when there is a keep-alive message > going on in a period of like 15 seconds, even though the message is short. > > Gary Gan > Sr. Software Developer > > Clique Communications, LLC > 205 Rockingham Row > Princeton Forrestal Village > Princeton, NJ 08540 > Phone: 609-564-0206 > > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Thursday, February 16, 2006 5:20 PM > To: Gary Gan > Cc: 'Francois Audet'; 'Cullen Jennings'; sip@ietf.org; fwmiller@cornfed.com > Subject: Re: [Sip] Outbound and STUN Keep Alive > > On Feb 16, 2006, at 3:23 PM, Gary Gan wrote: > >>The only problem I can think of is that the UA doesn't know if the >>server is >>down between now and the next SIP REGISTER is sent. > > > Right, that's exactly the problem we're trying to solve. Keeping the > NAT alive is only half the problem -- knowing when it has died and we > need to renegotiate is the other half. > > Sure, we could REGISTER every 15 seconds, but I'm POSITIVE that's > going to slow things down . . . > > -- > 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.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 sip-bounces@ietf.org Fri Feb 17 15:51:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FACZr-0006cO-L8; Fri, 17 Feb 2006 15:51:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FACZp-0006c9-UC for sip@megatron.ietf.org; Fri, 17 Feb 2006 15:51:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03841 for ; Fri, 17 Feb 2006 15:49:53 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FACoK-0008Fa-PA for sip@ietf.org; Fri, 17 Feb 2006 16:06:41 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k1HKpQH24410; Fri, 17 Feb 2006 15:51:26 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Outbound and STUN Keep Alive Date: Fri, 17 Feb 2006 14:51:08 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60A709751@zrc2hxm2.corp.nortel.com> Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcYz5MFO8er4dfAkRxy1jM0OhzV/5wAFx4mw From: "Samir Srivastava" To: "Jonathan Rosenberg" , "Thomas Froment" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, Brian Stucker X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org If client gets the response it is expecting, there is no issue. What else it is expecting on the PING, pl Clarify. Server is free to optimize.=20 If client does some non-standard thing to PING, it's problem of the client. If we fix this in SIP, we can optimize the Keep alive traffic too. If chatty IM session is going on there is no need to send keep alive. There will be some SIP traffic induced from session timers during the media only sessions.=20 To be more precise, if there is no SIP traffic for a configured interval, then send keep alive.=20 To achive this, with STUN we need more co-operation between STUN and SIP protocol application modules. Thx Samir =20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Friday, February 17, 2006 8:57 AM To: Thomas Froment Cc: sip@ietf.org; Stucker, Brian [RICH1:B620:EXCH] Subject: Re: [Sip] Outbound and STUN Keep Alive Actually, having a special code path that processes this SIP PING in a fundamentally different way is worse, IMHO. You are not only basically muxing a separate protocol on the same port anyway, you are breaking SIP by applying non-standard processing to it. I think you stand a much worse chance of interop failures with an implementation that processes SIP in a non-standard way. A client might send a PING, assuming it gets processed correctly, and then gets surprised when its basically being treated like a STUN request formatted as a sip mesage. How about we just send that stun request in the first place. -Jonathan R. Thomas Froment wrote: > Brian Stucker wrote: >=20 >> How can you send a 200 OK without parsing out the Via header fields? >> How do you get the cseq without parsing that out? >> >> -- Don't. Send the message back where it came from using the=20 >> transport information in the packet and reuse the existing=20 >> information in the request to form a valid response. You only need to >> add information to the end of the packet (in the form of a message=20 >> body or header) to report what you saw from the UA in terms of their=20 >> observed network address. >> >> Very fast. Of course the UA gets to eat it's own dog food if it sends >> something bad in the request. >> =20 >> > If you don't look at Via header to answer a SIP request, and just send > a "packet" back to the source IP Address/port, you are not doing SIP=20 > anymore, you are doing a "hack". In this case, this is no more "clean" > than double CR/LF or STUN. > Just to insist a last time on this topic: the most important point for > me is *consistency* with other parts of sip-outbound draft, as Chris > mentionned: "It is already specified for UDP in the Outbound draft",=20 > so why not use the same thing for TCP? >=20 >=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=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.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 _______________________________________________ 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 sip-bounces@ietf.org Fri Feb 17 15:59:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAChc-0000Ej-G4; Fri, 17 Feb 2006 15:59:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAChb-0000EB-Cu for sip@megatron.ietf.org; Fri, 17 Feb 2006 15:59:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05244 for ; Fri, 17 Feb 2006 15:57:54 -0500 (EST) Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FACw3-0000MA-HK for sip@ietf.org; Fri, 17 Feb 2006 16:14:41 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k1HKxY2k098828; Fri, 17 Feb 2006 15:59:38 -0500 (EST) From: "Brett Tate" To: "'Jonathan Rosenberg'" Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Fri, 17 Feb 2006 16:00:27 -0500 Message-ID: <002a01c63405$312c1050$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <43F6005F.9030202@cisco.com> Importance: Normal X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > Actually, having a special code path that processes > this SIP PING in a fundamentally different way is > worse, IMHO. You are not only basically muxing a > separate protocol on the same port anyway, you are > breaking SIP by applying non-standard processing to it. How is it not non standard? Vendors currently make optimizations to their stacks. The potential new request just allows for some extra optimization. Nobody is actually required to make the optimization. > A client might send a PING, > assuming it gets processed correctly, and then gets > surprised when its basically being treated like > a STUN request formatted as a sip message. How > about we just send that stun request in the first place. STUN has more of a capacity hit than echoing CRLFs over connection oriented protocols. That is why I currently prefer STUN be limited to UDP. And for UDP, many access devices are currently flooding the network with REGISTERs and/or OPTIONS. And STUN is potentially better than a new optimized SIP message; however I'm not sure how soon or how many devices would implement it. Thus until STUN (if chosen) and echoing CRLFs (if chosen) are widely supported and deployed, a new easily optimized SIP message might be beneficial. _______________________________________________ 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 sip-bounces@ietf.org Fri Feb 17 16:20:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAD0z-0005Nz-1J; Fri, 17 Feb 2006 16:19:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAD0x-0005No-2q for sip@megatron.ietf.org; Fri, 17 Feb 2006 16:19:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12160 for ; Fri, 17 Feb 2006 16:17:54 -0500 (EST) Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FADFR-0003BV-BU for sip@ietf.org; Fri, 17 Feb 2006 16:34:42 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k1HLJaxt000476; Fri, 17 Feb 2006 16:19:40 -0500 (EST) From: "Brett Tate" To: "'Jonathan Rosenberg'" Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Fri, 17 Feb 2006 16:20:28 -0500 Message-ID: <002b01c63407$fd657ce0$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <002a01c63405$312c1050$2c28a8c0@brett1> Importance: Normal X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Sorry about the repost... I intend to ask "How is it non standard?" :) > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Brett Tate > Sent: Friday, February 17, 2006 4:00 PM > To: 'Jonathan Rosenberg' > Cc: sip@ietf.org > Subject: RE: [Sip] Outbound and STUN Keep Alive > > > > Actually, having a special code path that processes > > this SIP PING in a fundamentally different way is > > worse, IMHO. You are not only basically muxing a > > separate protocol on the same port anyway, you are > > breaking SIP by applying non-standard processing to it. > > How is it non standard? Vendors currently make > optimizations to their stacks. The potential new request > just allows for some extra optimization. Nobody is actually > required to make the optimization. > > > > A client might send a PING, > > assuming it gets processed correctly, and then gets > > surprised when its basically being treated like > > a STUN request formatted as a sip message. How > > about we just send that stun request in the first place. > > STUN has more of a capacity hit than echoing CRLFs over > connection oriented protocols. That is why I currently > prefer STUN be limited to UDP. > > And for UDP, many access devices are currently flooding the > network with REGISTERs and/or OPTIONS. And STUN is > potentially better than a new optimized SIP message; however > I'm not sure how soon or how many devices would implement it. > > Thus until STUN (if chosen) and echoing CRLFs (if chosen) are > widely supported and deployed, a new easily optimized SIP > message might be beneficial. > > > > _______________________________________________ > 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 sip-bounces@ietf.org Fri Feb 17 16:20:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FACz1-0004kT-52; Fri, 17 Feb 2006 16:17:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FACyx-0004iq-KB for sip@megatron.ietf.org; Fri, 17 Feb 2006 16:17:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11762 for ; Fri, 17 Feb 2006 16:15:50 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FADDN-000316-GL for sip@ietf.org; Fri, 17 Feb 2006 16:32:38 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k1HLHIH21653; Fri, 17 Feb 2006 16:17:18 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Outbound and STUN Keep Alive Date: Fri, 17 Feb 2006 15:17:12 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60A7097ED@zrc2hxm2.corp.nortel.com> Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcYxf8mgCB8XjZ1zEdqXIgARJEEJ/ACfxrewAAHRRwA= From: "Samir Srivastava" To: "Francois Audet" , "Cullen Jennings" , , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org =20 SIP Message grammar insures that method name is at the fixed location in the transport payload. SIP-message =3D Request / Response=20 Request =3D Request-Line *( message-header ) CRLF [ message-body ]=20 Request-Line =3D Method SP Request-URI SP SIP-Version CRLF=20 No other characters, Optimization works well with RFC compliant clients. Thx Samir -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Audet, Francois [SC100:9T51:EXCH] Sent: Friday, February 17, 2006 12:16 PM To: Cullen Jennings; fwmiller@cornfed.com; Dean Willis Cc: sip@ietf.org Subject: RE: [Sip] Outbound and STUN Keep Alive You can key on the "PING" at the begining of the packet (in a fixed location, just like the STUN alternative), and bypass all the normal SIP processing IF you need to "optimize". > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of=20 > Cullen Jennings > Sent: Tuesday, February 14, 2006 08:01 > To: fwmiller@cornfed.com; Dean Willis > Cc: sip@ietf.org > Subject: Re: [Sip] Outbound and STUN Keep Alive >=20 >=20 >=20 > I don't see any reason that the PING will work better than just=20 > sending OPTIONS >=20 > On 2/13/06 6:06 PM, "Frank W. Miller" wrote: >=20 > >=20 > > I took the liberty of putting together a new draft that > proposes the > > PING method. The draft is at http://www.cornfed.com/ping.txt. =20 > > Comments welcome! > >=20 > > FM >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip >=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 _______________________________________________ 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 sip-bounces@ietf.org Fri Feb 17 16:22:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAD46-0006wa-9i; Fri, 17 Feb 2006 16:22:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAD44-0006vy-IO for sip@megatron.ietf.org; Fri, 17 Feb 2006 16:22:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12681 for ; Fri, 17 Feb 2006 16:21:07 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FADIY-0003NA-Rn for sip@ietf.org; Fri, 17 Feb 2006 16:37:56 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1HLMx9C016512 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 17 Feb 2006 15:23:00 -0600 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Fri, 17 Feb 2006 15:22:53 -0600 To: "sip@ietf.org List" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: Orit Levin Subject: [Sip] draft-ietf-sip-refer-with-norefersub-04.txt approved X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Congratulations, we've gotten another RFC launched -- draft-ietf-sip- refer-with-norefersub-04.txt has been approved by the IESG. Auth48 will follow in due course. -- 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 sip-bounces@ietf.org Fri Feb 17 16:37:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FADHw-00044X-S9; Fri, 17 Feb 2006 16:37:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FADHv-000440-C7 for sip@megatron.ietf.org; Fri, 17 Feb 2006 16:37:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15308 for ; Fri, 17 Feb 2006 16:35:26 -0500 (EST) Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FADWP-0003vz-Ls for sip@ietf.org; Fri, 17 Feb 2006 16:52:14 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k1HLb1nC001869; Fri, 17 Feb 2006 16:37:05 -0500 (EST) From: "Brett Tate" To: "'Gary Gan'" Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Fri, 17 Feb 2006 16:37:54 -0500 Message-ID: <002c01c6340a$6c7f7ed0$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Importance: Normal X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > it doesn't respond to SIP OPTION message, the UA=20 > would trigger retransmission which further jams=20 > the server.=20 That is one concern I have about trying to define/use a new SIP message = for the keep alive. Because of security reasons or poor implementations, = some servers might ignore the unknown request instead of producing an = appropriate failure response. However STUN has the same limitation. _______________________________________________ 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 sip-bounces@ietf.org Fri Feb 17 16:37:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FADIM-0004DI-5L; Fri, 17 Feb 2006 16:37:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FADIK-0004Ch-BB for sip@megatron.ietf.org; Fri, 17 Feb 2006 16:37:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15376 for ; Fri, 17 Feb 2006 16:35:47 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FADWh-0003wU-9Q for sip@ietf.org; Fri, 17 Feb 2006 16:52:35 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1HLbScA016596 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 17 Feb 2006 15:37:29 -0600 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <33DFEF06-329D-4578-9907-46BE7D94F7A0@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Fri, 17 Feb 2006 15:37:21 -0600 To: "Gary Gan" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: 'Cullen Jennings' , sip@ietf.org, 'Francois Audet' , fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 17, 2006, at 2:41 PM, Gary Gan wrote: > Why most SIP UA uses UDP protocol in first place. If it uses TCP, > the UA > will get notified by the TCP stack automatically if the server or > NAT is > down. Well, we found that its was sometimes more like 20 minutes before TCP notices. -- 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 sip-bounces@ietf.org Fri Feb 17 16:42:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FADMx-00060o-Q2; Fri, 17 Feb 2006 16:42:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FADMv-0005wz-VJ for sip@megatron.ietf.org; Fri, 17 Feb 2006 16:42:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15827 for ; Fri, 17 Feb 2006 16:40:37 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FADbQ-0004A0-8K for sip@ietf.org; Fri, 17 Feb 2006 16:57:25 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1HLgKAi016631 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 17 Feb 2006 15:42:21 -0600 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60A709751@zrc2hxm2.corp.nortel.com> References: <62B9B0847CC47543B6B3B5E26BD268E60A709751@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Fri, 17 Feb 2006 15:42:13 -0600 To: "Samir Srivastava" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Brian Stucker X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Feb 17, 2006, at 2:51 PM, Samir Srivastava wrote: > If client gets the response it is expecting, there is no issue. What > else it is expecting on the PING, pl > Clarify. Server is free to optimize. And what if some future extension uses a Proxy-Require or such to enforce some other extension behavior, but we don't process the new Proxy-Require because we're not parsing the whole SIP message? Breaks the SIP feature-negotiation model. Danger, Will Robinson! -- 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 sip-bounces@ietf.org Fri Feb 17 17:05:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FADjP-00031H-I2; Fri, 17 Feb 2006 17:05:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FADjN-000311-Hc for sip@megatron.ietf.org; Fri, 17 Feb 2006 17:05:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18032 for ; Fri, 17 Feb 2006 17:03:48 -0500 (EST) Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FADxp-0005Mb-0r for sip@ietf.org; Fri, 17 Feb 2006 17:20:37 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k1HM1AQ25585; Fri, 17 Feb 2006 17:01:11 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Outbound and STUN Keep Alive Date: Fri, 17 Feb 2006 16:05:08 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60A7098E9@zrc2hxm2.corp.nortel.com> Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcY0Cw+4Tmt8BDyERQmbdGLpQorNqgAAclsQ From: "Samir Srivastava" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, Brian Stucker X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org =20 In-line. -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Friday, February 17, 2006 1:42 PM To: Srivastava, Samir [SC100:8826:EXCH] Cc: Jonathan Rosenberg; Thomas Froment; sip@ietf.org; Stucker, Brian [RICH1:B620:EXCH] Subject: Re: [Sip] Outbound and STUN Keep Alive On Feb 17, 2006, at 2:51 PM, Samir Srivastava wrote: > If client gets the response it is expecting, there is no issue. What=20 > else it is expecting on the PING, pl Clarify. Server is free to=20 > optimize. And what if some future extension uses a Proxy-Require or such to enforce some other extension behavior, but we don't process the new Proxy-Require because we're not parsing the whole SIP message? SS>> PING is special purpose method intended for KEEP-ALIVE only. It should not be having any other feature=20 negotitation embedded in. PING should not be having these proxy-require etc. All headers are not applicable=20 to all methods. This is new method to be defined, we have a control over the headers that are applicable to it. To find the features set/extensions use the existing OPTIONS. Breaks the SIP feature-negotiation model. Danger, Will Robinson! -- 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 sip-bounces@ietf.org Fri Feb 17 17:10:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FADoC-00058l-Gq; Fri, 17 Feb 2006 17:10:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FADoA-00058g-9c for sip@megatron.ietf.org; Fri, 17 Feb 2006 17:10:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18338 for ; Fri, 17 Feb 2006 17:08:45 -0500 (EST) Received: from [66.155.254.250] (helo=isdmail1.inovsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAE2U-0005WE-H5 for sip@ietf.org; Fri, 17 Feb 2006 17:25:34 -0500 Received: from greatwall ([12.181.128.3]) by isdmail1.inovsys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 17 Feb 2006 17:10:13 -0500 From: "Gary Gan" To: "'Dean Willis'" Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Fri, 17 Feb 2006 17:10:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <33DFEF06-329D-4578-9907-46BE7D94F7A0@softarmor.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcY0CllZRP8P//u6SoiHxn0eZM3TwgAAezBw Message-ID: X-OriginalArrivalTime: 17 Feb 2006 22:10:13.0210 (UTC) FILETIME=[ECB4DBA0:01C6340E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: 'Cullen Jennings' , sip@ietf.org, 'Francois Audet' , fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org How about if each UA maintain a TCP connection to the server just SKINNY protocol in Cisco CallMananger? The client gets notified immediately when the server is down. If you unplug the cable, it may take a while, but not long, I would say in the matter of a minute, for the TCP will give it a try to recover. I don't know if the SIP TCP maintains a constant connection or not. It may use TCP as per request basis, just like web requests. If it doesn't maintain a connection, it will face the same problem as UDP in terms of keep-alive. Gary Gan On Feb 17, 2006, at 2:41 PM, Gary Gan wrote: > Why most SIP UA uses UDP protocol in first place. If it uses TCP, > the UA > will get notified by the TCP stack automatically if the server or > NAT is > down. Well, we found that its was sometimes more like 20 minutes before TCP notices. -- 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 sip-bounces@ietf.org Fri Feb 17 17:52:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAESx-0000K0-LX; Fri, 17 Feb 2006 17:52:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAESw-0000Js-8i for sip@megatron.ietf.org; Fri, 17 Feb 2006 17:52:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21620 for ; Fri, 17 Feb 2006 17:50:52 -0500 (EST) Received: from [66.155.254.250] (helo=isdmail1.inovsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAEhS-0007MV-GR for sip@ietf.org; Fri, 17 Feb 2006 18:07:42 -0500 Received: from greatwall ([68.39.6.223]) by isdmail1.inovsys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 17 Feb 2006 17:52:33 -0500 From: "Gary Gan" To: "'Gary Gan'" , "'Dean Willis'" Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Fri, 17 Feb 2006 17:52:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcY0CllZRP8P//u6SoiHxn0eZM3TwgAAezBwAAHz3yA= Message-ID: X-OriginalArrivalTime: 17 Feb 2006 22:52:33.0413 (UTC) FILETIME=[D6C91350:01C63414] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: 'Cullen Jennings' , sip@ietf.org, 'Francois Audet' , fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I reviewed the SKINNY protocol in Cisco CallManager, it is TCP connection based. But it also has defined a keep-alive echoing message. So that there must be cases that even in TCP, a transport layer keep-alive is still required in order for a UA to know the server's health. Gary Gan -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Gary Gan Sent: Friday, February 17, 2006 5:10 PM To: 'Dean Willis' Cc: 'Cullen Jennings'; sip@ietf.org; 'Francois Audet'; fwmiller@cornfed.com Subject: RE: [Sip] Outbound and STUN Keep Alive How about if each UA maintain a TCP connection to the server just SKINNY protocol in Cisco CallMananger? The client gets notified immediately when the server is down. If you unplug the cable, it may take a while, but not long, I would say in the matter of a minute, for the TCP will give it a try to recover. I don't know if the SIP TCP maintains a constant connection or not. It may use TCP as per request basis, just like web requests. If it doesn't maintain a connection, it will face the same problem as UDP in terms of keep-alive. Gary Gan On Feb 17, 2006, at 2:41 PM, Gary Gan wrote: > Why most SIP UA uses UDP protocol in first place. If it uses TCP, > the UA > will get notified by the TCP stack automatically if the server or > NAT is > down. Well, we found that its was sometimes more like 20 minutes before TCP notices. -- 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 sip-bounces@ietf.org Fri Feb 17 21:08:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAHWS-0002fm-VX; Fri, 17 Feb 2006 21:08:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAHWQ-0002dx-Dm for sip@megatron.ietf.org; Fri, 17 Feb 2006 21:08:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11825 for ; Fri, 17 Feb 2006 21:06:41 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAHkx-0000l6-95 for sip@ietf.org; Fri, 17 Feb 2006 21:23:32 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 17 Feb 2006 18:08:21 -0800 X-IronPort-AV: i="4.02,126,1139212800"; d="scan'208"; a="1777474301:sNHT33125000" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k1I28HZC001098; Fri, 17 Feb 2006 18:08:17 -0800 (PST) Received: from 10.21.147.54 ([10.21.147.54]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sat, 18 Feb 2006 02:08:17 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Fri, 17 Feb 2006 18:08:37 -0800 Subject: Re: [Sip] Outbound and STUN Keep Alive From: Cullen Jennings To: Chris Boulton , Gary Gan , Dean Willis , Francois Audet Message-ID: Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcYzLvZHBivjiDJiTd6ndigw/JWn8wADPeCwABvzi+AAIR+ezQ== In-Reply-To: <45730E094814E44488F789C1CDED27AE04E78B50@gbnewp0758m.eu.ubiquity.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On 2/17/06 2:22 AM, "Chris Boulton" wrote: > I don't know why the double CRLF is not enough for keep-alive. There have been a few people (Sean and Gary) that posted on the list pointing out that they use double CRLF (with TCP) and it works. Clearly the double CRLF does not work with UDP and we will need STUN there. Dean pointed out that with double CRLF, because there is no transaction identifier there might be a problem. The UA sends a CRLF, then the UA waits to get one back and if it does not receive one in a reasonable time, it considered the connection dead. The issue is, you might not get a CRLF back to the same thing you sent - there might have just been a CRLF lying around for no good reason. I don't know if this would turn out to be a problem or not but it certainly is worth thinking about. _______________________________________________ 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 sip-bounces@ietf.org Fri Feb 17 22:36:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAIt7-0000hy-Pv; Fri, 17 Feb 2006 22:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAIt6-0000gz-70 for sip@megatron.ietf.org; Fri, 17 Feb 2006 22:36:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16187 for ; Fri, 17 Feb 2006 22:34:10 -0500 (EST) From: shi.hao2@zte.com.cn Received: from [202.103.147.144] (helo=mail2.zte.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FAJ7Y-0003yr-OE for sip@ietf.org; Fri, 17 Feb 2006 22:51:02 -0500 Received: from [10.30.1.239] by 10.30.2.249 with StormMail ESMTP id 70900.1112621526; Sat, 18 Feb 2006 12:49:26 +0800 (CST) In-Reply-To: To: sip@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 Message-ID: Date: Sat, 18 Feb 2006 11:35:45 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.3|September 14, 2004) at 2006-02-18 11:38:30, Serialize complete at 2006-02-18 11:38:30 X-Spam-Score: 0.8 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Subject: [Sip] one question for timeout processing in RFC3398 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1178405981==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1178405981== Content-Type: multipart/alternative; boundary="=_alternative 0014381F48257119_=" This is a multipart message in MIME format. --=_alternative 0014381F48257119_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 X-MIME-Autoconverted: from 8bit to base64 by ietf.org id WAA16187 SGksDQoNCg0KSW4gUkZDMzM5OCBwYWdlIDMzLCBzZWN0aW9uIDguMS4zIFNJUCBUaW1lb3V0 LCBNR0Mgc2VuZHMgQ0FOQ0VMIHJlcXVlc3QgdG8gDQpVQVMgd2hlbiB0aGUgb3JpZ2luYWwg SU5WSVRFIHJldHJhbnNtaXNzaW9uIHRpbWVzIG91dCwgd2hpbGUgVUFDIE1VU1QgTk9UIA0K c2VuZCBDQU5DRUwgcmVxdWVzdCBpZiBubyByZXNwb25zZSBpcyByZWNlaXZlZCBhcyBSRkMz MjYxIHBhZ2UgNTQsIHNlY3Rpb24gDQo5LjEgQ2xpZW50IEJlaGF2aW9yLCBkZXNjcmliZWQ6 DQoNCiAgIklmIG5vIHByb3Zpc2lvbmFsIHJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkLCB0 aGUgQ0FOQ0VMIHJlcXVlc3QgTVVTVA0KICAgTk9UIGJlIHNlbnQ7IHJhdGhlciwgdGhlIGNs aWVudCBNVVNUIHdhaXQgZm9yIHRoZSBhcnJpdmFsIG9mIGENCiAgIHByb3Zpc2lvbmFsIHJl c3BvbnNlIGJlZm9yZSBzZW5kaW5nIHRoZSByZXF1ZXN0LiINCg0KSXMgaXQgYSBidWcgZm9y IFJGQzMzOTg/DQoNCg0KQmVzdCBSZWdhcmRzDQpMaW9uRWFnbGUNCg0KDQoNCioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQrkv6Hmga/lronlhajl o7DmmI7vvJrmnKzpgq7ku7bljIXlkKvkv6Hmga/lvZLlj5Hku7bkurrmiYDlnKjnu4Tnu4fm iYDmnInvvIwNCuWPkeS7tuS6uuaJgOWcqOe7hOe7h+WvueivpemCruS7tuaLpeacieaJgOac ieadg+WIqeOAguivt+aOpeaUtuiAheazqOaEjw0K5L+d5a+G77yM5pyq57uP5Y+R5Lu25Lq6 5Lmm6Z2i6K645Y+v77yM5LiN5b6X5ZCR5Lu75L2V56ysDQrkuInmlrnnu4Tnu4flkozkuKrk urrpgI/pnLLmnKzpgq7ku7bmiYDlkKvkv6Hmga/nmoTlhajpg6gNCuaIlumDqOWIhuOAguS7 peS4iuWjsOaYjuS7hemAgueUqOS6juW3peS9nOmCruS7tuOAgg0KSW5mb3JtYXRpb24gU2Vj dXJpdHkgIE5vdGljZe+8mg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1h aWwgaXMNCnNvbGVseSBwcm9wZXJ0eSBvZiAgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4g DQpUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuDQpSZWNpcGllbnRz IG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8NCm1haW50YWluIHNlY3JlY3kgYW5kIGFy ZSBub3QgcGVybWl0dGVkIHRvDQpkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21t dW5pY2F0aW9uDQp0byBvdGhlcnMuDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKg0KDQo= --=_alternative 0014381F48257119_= Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: base64 X-MIME-Autoconverted: from 8bit to base64 by ietf.org id WAA16187 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SW4gUkZDMzM5OCBw YWdlIDMzLCBzZWN0aW9uIDguMS4zIFNJUA0KVGltZW91dCwgTUdDIHNlbmRzIENBTkNFTCBy ZXF1ZXN0IHRvIFVBUyB3aGVuIHRoZSBvcmlnaW5hbCBJTlZJVEUgcmV0cmFuc21pc3Npb24N CnRpbWVzIG91dCwgd2hpbGUgVUFDIE1VU1QgTk9UIHNlbmQgQ0FOQ0VMIHJlcXVlc3QgaWYg bm8gcmVzcG9uc2UgaXMgcmVjZWl2ZWQNCmFzIFJGQzMyNjEgcGFnZSA1NCwgc2VjdGlvbiA5 LjEgQ2xpZW50IEJlaGF2aW9yLCBkZXNjcmliZWQ6PC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJnF1b3Q7SWYgbm8gcHJvdmlzaW9u YWwgcmVzcG9uc2UNCmhhcyBiZWVuIHJlY2VpdmVkLCB0aGUgQ0FOQ0VMIHJlcXVlc3QgTVVT VDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZu YnNwO05PVCBiZSBzZW50OyByYXRoZXIsIHRoZQ0KY2xpZW50IE1VU1Qgd2FpdCBmb3IgdGhl IGFycml2YWwgb2YgYTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+Jm5ic3A7ICZuYnNwO3Byb3Zpc2lvbmFsIHJlc3BvbnNlIGJlZm9yZQ0Kc2VuZGluZyB0 aGUgcmVxdWVzdC4mcXVvdDs8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPklzIGl0IGEgYnVnIGZvciBSRkMzMzk4PzwvZm9udD4NCjxicj4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QmVzdCBSZWdhcmRzPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5MaW9uRWFnbGU8L2Zv bnQ+DQo8YnI+PGJyPjxicj48YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKg0KPGJyPg0K5L+h5oGv5a6J5YWo5aOw5piO77ya5pys6YKu5Lu2 5YyF5ZCr5L+h5oGv5b2S5Y+R5Lu25Lq65omA5Zyo57uE57uH5omA5pyJ77yMDQo8YnI+DQrl j5Hku7bkurrmiYDlnKjnu4Tnu4flr7nor6Xpgq7ku7bmi6XmnInmiYDmnInmnYPliKnjgILo r7fmjqXmlLbogIXms6jmhI8NCjxicj4NCuS/neWvhu+8jOacque7j+WPkeS7tuS6uuS5pumd ouiuuOWPr++8jOS4jeW+l+WQkeS7u+S9leesrA0KPGJyPg0K5LiJ5pa557uE57uH5ZKM5Liq 5Lq66YCP6Zyy5pys6YKu5Lu25omA5ZCr5L+h5oGv55qE5YWo6YOoDQo8YnI+DQrmiJbpg6jl iIbjgILku6XkuIrlo7DmmI7ku4XpgILnlKjkuo7lt6XkvZzpgq7ku7bjgIINCjxicj4NCklu Zm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDsmbmJzcDtOb3RpY2XvvJoNCjxicj4NClRo ZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5i c3A7bWFpbCZuYnNwO2lzDQo8YnI+DQpzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5i c3A7Jm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7DQo8 YnI+DQpUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2Nv bmZpZGVudGlhbC4NCjxicj4NClJlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5i c3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8NCjxicj4NCm1haW50YWluJm5ic3A7c2Vj cmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3Rv DQo8YnI+DQpkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0 aGlzJm5ic3A7Y29tbXVuaWNhdGlvbg0KPGJyPg0KdG8mbmJzcDtvdGhlcnMuDQo8YnI+DQoq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPGJyPg0K PGJyPg0K --=_alternative 0014381F48257119_=-- --===============1178405981== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1178405981==-- From sip-bounces@ietf.org Sat Feb 18 00:24:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAKaM-0007za-Eg; Sat, 18 Feb 2006 00:24:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAKaK-0007z4-2P for sip@megatron.ietf.org; Sat, 18 Feb 2006 00:24:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21184 for ; Sat, 18 Feb 2006 00:22:54 -0500 (EST) Received: from [66.155.254.250] (helo=isdmail1.inovsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAKos-0007c8-8y for sip@ietf.org; Sat, 18 Feb 2006 00:39:47 -0500 Received: from greatwall ([68.37.154.46]) by isdmail1.inovsys.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 18 Feb 2006 00:24:33 -0500 From: "Gary Gan" To: "'Cullen Jennings'" , "'Chris Boulton'" , "'Dean Willis'" , "'Francois Audet'" Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Sat, 18 Feb 2006 00:24:33 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcYzLvZHBivjiDJiTd6ndigw/JWn8wADPeCwABvzi+AAIR+ezQAGFQgg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 18 Feb 2006 05:24:33.0275 (UTC) FILETIME=[99B734B0:01C6344B] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I don't think the transaction ID is required for the purpose of the keep-alive as it is in the full STUN protocol. Isn't it true that the receiver UDP socket always know where the sender is by the UDP stack itself? A multiplexing STUN and SIP server in the same port is a good idea. A single simplified STUN binding request may be required, a normal STUN binding request is about 70 bytes with the all the header overhead, 28 bytes are real data, which is little bit too long. The transaction ID takes 16 bytes in one of the implementation, for me it can be removed, but I don't know if it is still STUN compliant with a NULL transaction ID field. Gary Gan -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Friday, February 17, 2006 9:09 PM To: Chris Boulton; Gary Gan; Dean Willis; Francois Audet Cc: sip@ietf.org; fwmiller@cornfed.com Subject: Re: [Sip] Outbound and STUN Keep Alive On 2/17/06 2:22 AM, "Chris Boulton" wrote: > I don't know why the double CRLF is not enough for keep-alive. There have been a few people (Sean and Gary) that posted on the list pointing out that they use double CRLF (with TCP) and it works. Clearly the double CRLF does not work with UDP and we will need STUN there. Dean pointed out that with double CRLF, because there is no transaction identifier there might be a problem. The UA sends a CRLF, then the UA waits to get one back and if it does not receive one in a reasonable time, it considered the connection dead. The issue is, you might not get a CRLF back to the same thing you sent - there might have just been a CRLF lying around for no good reason. I don't know if this would turn out to be a problem or not but it certainly is worth thinking about. _______________________________________________ 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 sip-bounces@ietf.org Sat Feb 18 06:05:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAPuE-0008Gu-S1; Sat, 18 Feb 2006 06:05:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAPuC-0008DD-FA for sip@megatron.ietf.org; Sat, 18 Feb 2006 06:05:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08370 for ; Sat, 18 Feb 2006 06:03:46 -0500 (EST) Received: from web8613.mail.in.yahoo.com ([202.43.219.182]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FAQ8o-0006MF-6N for sip@ietf.org; Sat, 18 Feb 2006 06:20:43 -0500 Received: (qmail 71716 invoked by uid 60001); 18 Feb 2006 11:05:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Hg16MEBWkC7le7Ew3YxAy/WB2UyVNOZFgYpGPseE7WN6XCMjk7pcBIVZRSULiOYmDAz02gChLC6fMELFH79yBpYMj3kjqOSLuUVbAPmmP3WNMNVPgOviFoSPlEGl3F23wsISxNe8QmJLkHEBdZgTBBfvvuXnRfQo37dfhTo4+QM= ; Message-ID: <20060218110523.71714.qmail@web8613.mail.in.yahoo.com> Received: from [210.214.40.117] by web8613.mail.in.yahoo.com via HTTP; Sat, 18 Feb 2006 11:05:23 GMT Date: Sat, 18 Feb 2006 11:05:23 +0000 (GMT) From: Thejeswara Reddy Subject: Re: [Sip] one question for timeout processing in RFC3398 To: shi.hao2@zte.com.cn, sip@ietf.org In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2067868518==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============2067868518== Content-Type: multipart/alternative; boundary="0-406979349-1140260723=:70059" --0-406979349-1140260723=:70059 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 X-MIME-Autoconverted: from 8bit to base64 by ietf.org id GAA08370 cGxlYXNlIGNvcnJlY3QgbWUgaWYgaSBhbSB3cm9uZy4NCiAgU2luY2UgTUdDIGl0IHNlbGYg aGFzIGFiaWxpdHkgdG8gc2VuZCAxMDAgdHJ5aW5nIChwcm92aXNpb25hbCAgcmVzcG9uc2Up LCBzbyB0aGVyZSBpcyBubyBwcm9ibGVtIG9mIHNlbmRpbmcgQ0FOQ0VMIGJlZm9yZSBwcm92 aXNpb25hbCAgcmVzcG9uc2VzIHRvIFVBUy4NCg0KICByZWdhcmRzDQogIHRoZWphDQpzaGku aGFvMkB6dGUuY29tLmNuIHdyb3RlOiAgICANCkhpLCAgDQogIA0KICANCkluIFJGQzMzOTgg cGFnZSAzMywgc2VjdGlvbiA4LjEuMyBTSVAgIFRpbWVvdXQsIE1HQyBzZW5kcyBDQU5DRUwg cmVxdWVzdCB0byBVQVMgd2hlbiB0aGUgb3JpZ2luYWwgSU5WSVRFIHJldHJhbnNtaXNzaW9u ICB0aW1lcyBvdXQsIHdoaWxlIFVBQyBNVVNUIE5PVCBzZW5kIENBTkNFTCByZXF1ZXN0IGlm IG5vIHJlc3BvbnNlIGlzIHJlY2VpdmVkICBhcyBSRkMzMjYxIHBhZ2UgNTQsIHNlY3Rpb24g OS4xIENsaWVudCBCZWhhdmlvciwgZGVzY3JpYmVkOiAgDQogIA0KICAiSWYgbm8gcHJvdmlz aW9uYWwgcmVzcG9uc2UgIGhhcyBiZWVuIHJlY2VpdmVkLCB0aGUgQ0FOQ0VMIHJlcXVlc3Qg TVVTVCAgDQogICBOT1QgYmUgc2VudDsgcmF0aGVyLCB0aGUgIGNsaWVudCBNVVNUIHdhaXQg Zm9yIHRoZSBhcnJpdmFsIG9mIGEgIA0KICAgcHJvdmlzaW9uYWwgcmVzcG9uc2UgYmVmb3Jl ICBzZW5kaW5nIHRoZSByZXF1ZXN0LiIgIA0KICANCklzIGl0IGEgYnVnIGZvciBSRkMzMzk4 PyAgDQogIA0KICANCkJlc3QgUmVnYXJkcyAgDQpMaW9uRWFnbGUgIA0KDQoNCg0KICAqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiAgDQogIOS/oeaB r+WuieWFqOWjsOaYju+8muacrOmCruS7tuWMheWQq+S/oeaBr+W9kuWPkeS7tuS6uuaJgOWc qOe7hOe7h+aJgOacie+8jCAgDQogIOWPkeS7tuS6uuaJgOWcqOe7hOe7h+WvueivpemCruS7 tuaLpeacieaJgOacieadg+WIqeOAguivt+aOpeaUtuiAheazqOaEjyAgDQogIOS/neWvhu+8 jOacque7j+WPkeS7tuS6uuS5pumdouiuuOWPr++8jOS4jeW+l+WQkeS7u+S9leesrCAgDQog IOS4ieaWuee7hOe7h+WSjOS4quS6uumAj+mcsuacrOmCruS7tuaJgOWQq+S/oeaBr+eahOWF qOmDqCAgDQogIOaIlumDqOWIhuOAguS7peS4iuWjsOaYjuS7hemAgueUqOS6juW3peS9nOmC ruS7tuOAgiAgDQogIEluZm9ybWF0aW9uIFNlY3VyaXR5ICBOb3RpY2XvvJogIA0KICBUaGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyAgDQogIHNvbGVseSBwcm9w ZXJ0eSBvZiAgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gICANCiAgVGhpcyBtYWlsIGNv bW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiAgDQogIFJlY2lwaWVudHMgbmFtZWQgYWJv dmUgYXJlIG9ibGlnYXRlZCB0byAgDQogIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3Qg cGVybWl0dGVkIHRvICANCiAgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVu aWNhdGlvbiAgDQogIHRvIG90aGVycy4gIA0KICAqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKiAgDQogIA0KICBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KU2lwIG1haWxpbmcgbGlzdCAgaHR0cHM6Ly93 d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwDQpUaGlzIGxpc3QgaXMgZm9yIE5F VyBkZXZlbG9wbWVudCBvZiB0aGUgY29yZSBTSVAgUHJvdG9jb2wNClVzZSBzaXAtaW1wbGVt ZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rpb25zIG9uIGN1cnJlbnQgc2lwDQpV c2Ugc2lwcGluZ0BpZXRmLm9yZyBmb3IgbmV3IGRldmVsb3BtZW50cyBvbiB0aGUgYXBwbGlj YXRpb24gb2Ygc2lwDQoNCgkJCQkNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KIEppeW8gY3JpY2tldCBvbiBZYWhvbyEgSW5kaWEgY3JpY2tldA0KWWFob28hIE1lc3Nl bmdlciBNb2JpbGUgU3RheSBpbiB0b3VjaCB3aXRoIHlvdXIgYnVkZGllcyBhbGwgdGhlIHRp bWUu --0-406979349-1140260723=:70059 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA08370 please correct me if i am wrong.
Since MGC it self has ability to se= nd 100 trying (provisional response), so there is no problem of sending = CANCEL before provisional responses to UAS.

regards
theja<= br>shi.hao2@zte.com.cn wrote:

Hi,

In RFC3398 page 33, se= ction 8.1.3 SIP Timeout, MGC sends CANCEL request to UAS when the origin= al INVITE retransmission times out, while UAC MUST NOT send CANCEL reque= st if no response is received as RFC3261 page 54, section 9.1 Client Beh= avior, described:

=   "If no provisional response has been received, the CANCEL request= MUST
   NOT b= e sent; rather, the client MUST wait for the arrival of a=20
   provisional respon= se before sending the request."

Is it a bug for RFC3398?


Best Regards
LionEagle



********************= ***************************
=E4=BF=A1=E6=81=AF=E5=AE=89=E5=85=A8=E5= =A3=B0=E6=98=8E=EF=BC=9A=E6=9C=AC=E9=82=AE=E4=BB=B6=E5=8C=85=E5=90=AB=E4=BF= =A1=E6=81=AF=E5=BD=92=E5=8F=91=E4=BB=B6=E4=BA=BA=E6=89=80=E5=9C=A8=E7=BB=84= =E7=BB=87=E6=89=80=E6=9C=89=EF=BC=8C
=E5=8F=91=E4=BB=B6=E4=BA=BA=E6= =89=80=E5=9C=A8=E7=BB=84=E7=BB=87=E5=AF=B9=E8=AF=A5=E9=82=AE=E4=BB=B6=E6=8B= =A5=E6=9C=89=E6=89=80=E6=9C=89=E6=9D=83=E5=88=A9=E3=80=82=E8=AF=B7=E6=8E=A5= =E6=94=B6=E8=80=85=E6=B3=A8=E6=84=8F
=E4=BF=9D=E5=AF=86=EF=BC=8C=E6= =9C=AA=E7=BB=8F=E5=8F=91=E4=BB=B6=E4=BA=BA=E4=B9=A6=E9=9D=A2=E8=AE=B8=E5=8F= =AF=EF=BC=8C=E4=B8=8D=E5=BE=97=E5=90=91=E4=BB=BB=E4=BD=95=E7=AC=AC
= =E4=B8=89=E6=96=B9=E7=BB=84=E7=BB=87=E5=92=8C=E4=B8=AA=E4=BA=BA=E9=80=8F= =E9=9C=B2=E6=9C=AC=E9=82=AE=E4=BB=B6=E6=89=80=E5=90=AB=E4=BF=A1=E6=81=AF=E7= =9A=84=E5=85=A8=E9=83=A8
=E6=88=96=E9=83=A8=E5=88=86=E3=80=82=E4=BB= =A5=E4=B8=8A=E5=A3=B0=E6=98=8E=E4=BB=85=E9=80=82=E7=94=A8=E4=BA=8E=E5=B7=A5= =E4=BD=9C=E9=82=AE=E4=BB=B6=E3=80=82
Information Security&nbs= p; Notice=EF=BC=9A
The information contained i= n this mail is
solely property of &n= bsp;the sender's organization. 
=20 This mail communication is confidential.
Reci= pients named above are obligated to
maint= ain secrecy and are not permitted to
= disclose the contents of this communication to others.
**********************************************= *

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

=09 =09

=20 Jiyo cricket on Yahoo! India cricket
Yahoo! Messenger Mobile Stay in touc= h with your buddies all the time. --0-406979349-1140260723=:70059-- --===============2067868518== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============2067868518==-- From sip-bounces@ietf.org Sat Feb 18 12:06:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAVUo-0002b5-Ds; Sat, 18 Feb 2006 12:03:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAVUm-0002as-N9 for sip@ietf.org; Sat, 18 Feb 2006 12:03:44 -0500 Received: from [66.155.254.250] (helo=isdmail1.inovsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAVUm-0003VY-FF for sip@ietf.org; Sat, 18 Feb 2006 12:03:44 -0500 Received: from greatwall ([68.37.154.46]) by isdmail1.inovsys.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 18 Feb 2006 12:03:43 -0500 From: "Gary Gan" To: "'Cullen Jennings'" , "'Chris Boulton'" , "'Dean Willis'" , "'Francois Audet'" Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Sat, 18 Feb 2006 12:03:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcYzLvZHBivjiDJiTd6ndigw/JWn8wADPeCwABvzi+AAIR+ezQAeu4Ig In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 18 Feb 2006 17:03:43.0997 (UTC) FILETIME=[464B62D0:01C634AD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sip@ietf.org, fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org There might be a problem if just simply multiplexing STUN and SIP server in the same port. New clients would not be backwards compatible with old servers. They will declare server-down when they find no response. I believe to have the keep-alive adopted in the SIP standard may be a better approach. The client can query if the server supports the keep-alive message first before it even tries to send it. Directly sending the STUN to the SIP server may not a good idea for keeping alive the NAT binding of the SIP session. I don't know how it can handle situations if the client is configured to use outbound proxy behind a firewall that forwards all SIP messages to the SIP server. Gary Gan Clique Communications, LLC -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Friday, February 17, 2006 9:09 PM To: Chris Boulton; Gary Gan; Dean Willis; Francois Audet Cc: sip@ietf.org; fwmiller@cornfed.com Subject: Re: [Sip] Outbound and STUN Keep Alive On 2/17/06 2:22 AM, "Chris Boulton" wrote: > I don't know why the double CRLF is not enough for keep-alive. There have been a few people (Sean and Gary) that posted on the list pointing out that they use double CRLF (with TCP) and it works. Clearly the double CRLF does not work with UDP and we will need STUN there. Dean pointed out that with double CRLF, because there is no transaction identifier there might be a problem. The UA sends a CRLF, then the UA waits to get one back and if it does not receive one in a reasonable time, it considered the connection dead. The issue is, you might not get a CRLF back to the same thing you sent - there might have just been a CRLF lying around for no good reason. I don't know if this would turn out to be a problem or not but it certainly is worth thinking about. _______________________________________________ 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 sip-bounces@ietf.org Sat Feb 18 12:10:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAVZ5-0004AS-AH; Sat, 18 Feb 2006 12:08:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAUzq-0002AL-PP for sip@ietf.org; Sat, 18 Feb 2006 11:31:46 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAUY5-0002Vo-OR for sip@ietf.org; Sat, 18 Feb 2006 11:03:05 -0500 Received: from celine.siteprotect.com ([64.41.122.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FATmg-0000nO-Cm for sip@ietf.org; Sat, 18 Feb 2006 10:14:07 -0500 Received: from [192.168.1.4] (pool-141-157-104-69.balt.east.verizon.net [141.157.104.69]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id k1IFE5S12645 for ; Sat, 18 Feb 2006 09:14:05 -0600 From: "Frank W. Miller" To: sip@ietf.org In-Reply-To: References: Content-Type: text/plain Organization: Cornfed Systems, LLC Date: Sat, 18 Feb 2006 10:14:03 -0500 Message-Id: <1140275643.2503.4.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Sip] PING draft update X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fwmiller@cornfed.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I've updated the draft to remove the restriction that it be sent only during a session and added the ability to treat a 405 coming back from a UAS that does not support PING as a valid response. http://www.cornfed.com/ping.txt 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 sip-bounces@ietf.org Sat Feb 18 20:39:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAdVs-0006vS-SG; Sat, 18 Feb 2006 20:37:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAdVr-0006vM-Az for sip@ietf.org; Sat, 18 Feb 2006 20:37:23 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAdVq-0003F9-1s for sip@ietf.org; Sat, 18 Feb 2006 20:37:23 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 18 Feb 2006 17:37:23 -0800 X-IronPort-AV: i="4.02,127,1139212800"; d="scan'208"; a="256390206:sNHT32771636" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k1J1bIub017029; Sat, 18 Feb 2006 17:37:18 -0800 (PST) Received: from 10.21.97.248 ([10.21.97.248]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sun, 19 Feb 2006 01:37:18 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sat, 18 Feb 2006 17:37:39 -0800 Subject: Re: [Sip] Outbound and STUN Keep Alive From: Cullen Jennings To: Gary Gan , Chris Boulton , Dean Willis , Francois Audet Message-ID: Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcYzLvZHBivjiDJiTd6ndigw/JWn8wADPeCwABvzi+AAIR+ezQAeu4IgABJ6PFg= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: "sip@ietf.org" , fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 2/18/06 9:03 AM, "Gary Gan" wrote: > There might be a problem if just simply multiplexing STUN and SIP server in > the same port. > > New clients would not be backwards compatible with old servers. They will > declare server-down when they find no response. The draft define a way for the client to find out if the server supports this or not to solve this problem. > > I believe to have the keep-alive adopted in the SIP standard may be a better > approach. The client can query if the server supports the keep-alive message > first before it even tries to send it. > > Directly sending the STUN to the SIP server may not a good idea for keeping > alive the NAT binding of the SIP session. I don't know how it can handle > situations if the client is configured to use outbound proxy behind a > firewall that forwards all SIP messages to the SIP server. > > > Gary Gan > Clique Communications, LLC > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Friday, February 17, 2006 9:09 PM > To: Chris Boulton; Gary Gan; Dean Willis; Francois Audet > Cc: sip@ietf.org; fwmiller@cornfed.com > Subject: Re: [Sip] Outbound and STUN Keep Alive > > On 2/17/06 2:22 AM, "Chris Boulton" wrote: > >> I don't know why the double CRLF is not enough for keep-alive. > > There have been a few people (Sean and Gary) that posted on the list > pointing out that they use double CRLF (with TCP) and it works. > > Clearly the double CRLF does not work with UDP and we will need STUN there. > Dean pointed out that with double CRLF, because there is no transaction > identifier there might be a problem. The UA sends a CRLF, then the UA waits > to get one back and if it does not receive one in a reasonable time, it > considered the connection dead. The issue is, you might not get a CRLF back > to the same thing you sent - there might have just been a CRLF lying around > for no good reason. I don't know if this would turn out to be a problem or > not but it certainly is worth thinking about. > > _______________________________________________ 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 sip-bounces@ietf.org Sun Feb 19 07:12:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAnO3-0004rG-29; Sun, 19 Feb 2006 07:09:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAnO1-0004r5-Oh for sip@ietf.org; Sun, 19 Feb 2006 07:09:57 -0500 Received: from spark.hss.co.in ([203.145.155.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAnNy-00022j-N9 for sip@ietf.org; Sun, 19 Feb 2006 07:09:57 -0500 Received: from ultra.hss.co.in (ultra [192.168.100.5]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id k1JC3FGK020716; Sun, 19 Feb 2006 17:33:16 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id k1JCAkw18940; Sun, 19 Feb 2006 17:40:46 +0530 (IST) Importance: Normal X-Priority: 3 (Normal) Subject: Re: [Sip] Re: REGISTRAR behavior MIME-Version: 1.0 From: Rayees Khan To: Raja Chilla Date: Sun, 19 Feb 2006 17:36:39 +0530 Message-ID: X-MIMETrack: Serialize by Notes Server on Zarf/HSS(Release 6.5.1|January 21, 2004) at 02/19/2006 05:36:39 PM, Serialize complete at 02/19/2006 05:36:39 PM, Itemize by Notes Server on Zarf/HSS(Release 6.5.1|January 21, 2004) at 02/19/2006 05:36:39 PM, Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 19/02/2006 05:39:41 PM, Serialize complete at 19/02/2006 05:39:41 PM MIME-Version: 1.0 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0945819911==" Errors-To: sip-bounces@ietf.org --===============0945819911== Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Section 10.3 mentions

"The registrar MAY choose an expiration =
less than the requested expiration interval"

I hope that this clarif=
ies the doubt.


regards
Rayees

-----sip-bounces@ietf.org wrote: -----

To: sip@iet= f.org
From: Raja Chilla <rajachilla@gmail.com>
Sent by: sip-bou= nces@ietf.org
Date: 02/16/2006 11:23PM
Subject: [Sip] Re: REGISTRAR b= ehavior

Guess this has been asked before. Can REGISTRAR lower the expiration i= nterval in expires field (from one requested by client originally) in its 2= 00 OK response? Note there is no 423 response to client's REGISTER request = just 200OK with lowered expiration value. RFC3261 referring section would h= elp in any case.
-Raja=20

=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Sip mailing li= st  https://www= 1.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 applica= tion of sip


*****FSS-Private *****" DISCLAIMER: = This message is proprietary to Flextronics Software Systems Limited (FSS) a= nd is intended solely for the use of the individual to whom it is addressed= . It may contain privileged or confidential information and should not be = circulated or used for any purpose other than for what it is intended. If y= ou have received this message in error, please notify the originator im= mediately. If you are not the intended recipient, you are notified that= you are strictly prohibited from using, copying, altering, or = disclosing the contents of this message. FSS accepts no responsibility for = loss or damage arising from the use of the information transmitted by this = email including damage from virus."
= --===============0945819911== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0945819911==-- From sip-bounces@ietf.org Sun Feb 19 07:20:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAnW1-0005j3-FH; Sun, 19 Feb 2006 07:18:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAnW0-0005iu-KX for sip@ietf.org; Sun, 19 Feb 2006 07:18:12 -0500 Received: from spark.hss.co.in ([203.145.155.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAnVz-0002NB-H6 for sip@ietf.org; Sun, 19 Feb 2006 07:18:12 -0500 Received: from ultra.hss.co.in (ultra [192.168.100.5]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id k1JCBcGK020857; Sun, 19 Feb 2006 17:41:38 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id k1JCJ8U19059; Sun, 19 Feb 2006 17:49:08 +0530 (IST) Importance: Normal X-Priority: 3 (Normal) Subject: Re: [Sip] one question for timeout processing in RFC3398 MIME-Version: 1.0 From: Rayees Khan To: shi.hao2@zte.com.cn Date: Sun, 19 Feb 2006 17:45:01 +0530 Message-ID: X-MIMETrack: Serialize by Notes Server on Zarf/HSS(Release 6.5.1|January 21, 2004) at 02/19/2006 05:45:01 PM, Serialize complete at 02/19/2006 05:45:01 PM, Itemize by Notes Server on Zarf/HSS(Release 6.5.1|January 21, 2004) at 02/19/2006 05:45:01 PM, Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 19/02/2006 05:48:04 PM, Serialize complete at 19/02/2006 05:48:04 PM MIME-Version: 1.0 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0750894988==" Errors-To: sip-bounces@ietf.org --===============0750894988== Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
I think it is a bug. It needs to be explicit in the fact that CANCEL i= s sent only if provisional resopnse is received and transaction terminated = internally if not. Additionally it needs to clarify what need to be done if= a final response is received.


regards
Rayees


-----sip-bounces@ietf.org wrote: -----

To: sip@iet= f.org
From: shi.hao2@zte.com.cn
Sent by: sip-bounces@ietf.org
Date= : 02/18/2006 03:35AM
Subject: [Sip] one question for timeout processing = in RFC3398


Hi,


In RFC3398 page 33,= section 8.1.3 SIP Timeout, MGC sends CANCEL request to UAS when the original INVITE retransmi= ssion times out, while UAC MUST NOT send CANCEL request if no response is received as RFC3261 page 54, section 9.1 Client Behavior, described:

  "If no provision= al response has been received, the CANCEL request MUST
   NOT be sent; r= ather, the client MUST wait for the arrival of a
   provisional re= sponse before sending the request."

Is it a bug for RFC3398?


Best Regards
LionEagle



***********************************************
= =E4=BF=A1=E6=81=AF=E5=AE?=E5?=A8=E5=A3=B0=E6??=EF=BC?=E6?=AC=E9?=AE=E4=BB= =B6=E5??=E5=90=AB=E4=BF=A1=E6=81=AF=E5=BD?=E5=8F?=E4=BB=B6=E4=BA=BA=E6??=E5= ?=A8=E7=BB?=E7=BB?=E6??=E6??=EF=BC?
=E5=8F?=E4=BB=B6=E4=BA=BA=E6??=E5?= =A8=E7=BB?=E7=BB?=E5=AF=B9=E8=AF=A5=E9?=AE=E4=BB=B6=E6?=A5=E6??=E6??=E6??= =E6=9D?=E5?=A9=E3??=E8=AF=B7=E6?=A5=E6?=B6=E8??=E6=B3=A8=E6?=8F
=E4=BF= =9D=E5=AF?=EF=BC?=E6?=AA=E7=BB=8F=E5=8F?=E4=BB=B6=E4=BA=BA=E4=B9=A6=E9=9D= =A2=E8=AE=B8=E5=8F=AF=EF=BC?=E4=B8=8D=E5=BE?=E5=90?=E4=BB=BB=E4=BD?=E7=AC= =AC
=E4=B8?=E6?=B9=E7=BB?=E7=BB?=E5??=E4=B8=AA=E4=BA=BA=E9?=8F=E9?=B2=E6= ?=AC=E9?=AE=E4=BB=B6=E6??=E5=90=AB=E4=BF=A1=E6=81=AF=E7??=E5?=A8=E9?=A8
= =E6??=E9?=A8=E5??=E3??=E4=BB=A5=E4=B8?=E5=A3=B0=E6??=E4=BB?=E9??=E7?=A8=E4= =BA?=E5=B7=A5=E4=BD?=E9?=AE=E4=BB=B6=E3??
Information Security = ; Notice=EF=BC?
The information contained in th= is mail is
solely property of  the se= nder's organization. 
This mail communication i= s confidential.
Recipients named above are obli= gated to
maintain secrecy and are not perm= itted to
disclose the contents of this com= munication
to others.
******************************************= *****

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


*****FSS-Private *****" DISCLAIMER: This message is= proprietary to Flextronics Software Systems Limited (FSS) and is intended = solely for the use of the individual to whom it is addressed. It may contai= n privileged or confidential information and should not be circulated or u= sed for any purpose other than for what it is intended. If you have receive= d this message in error, please notify the originator immediately. If y= ou are not the intended recipient, you are notified that you are strict= ly prohibited from using, copying, altering, or disclosing the = contents of this message. FSS accepts no responsibility for loss or damage = arising from the use of the information transmitted by this email including= damage from virus."
= --===============0750894988== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0750894988==-- From sip-bounces@ietf.org Sun Feb 19 12:22:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1-ext.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAsDz-0003iO-QT; Sun, 19 Feb 2006 12:19:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAsDy-0003iJ-QG for sip@ietf.org; Sun, 19 Feb 2006 12:19:54 -0500 Received: from smtp3.versatel.nl ([62.58.50.90]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAsDx-0007V0-DO for sip@ietf.org; Sun, 19 Feb 2006 12:19:54 -0500 Received: (qmail 19537 invoked by uid 0); 19 Feb 2006 17:19:49 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp3.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 19 Feb 2006 17:19:49 -0000 Message-ID: <001c01c63578$adc081e0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: , References: <1140275643.2503.4.camel@localhost.localdomain> Subject: Re: [Sip] PING draft update Date: Sun, 19 Feb 2006 18:19:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Frank, A UAS not recognizing PING would send back a 501 response, not a 405 (see RFC3261 section 21.5.2) Regards, Jeroen ----- Original Message ----- From: "Frank W. Miller" To: Sent: Saturday, February 18, 2006 4:14 PM Subject: [Sip] PING draft update > > I've updated the draft to remove the restriction that it be sent only > during a session and added the ability to treat a 405 coming back from a > UAS that does not support PING as a valid response. > > http://www.cornfed.com/ping.txt > > 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 _______________________________________________ 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 sip-bounces@ietf.org Sun Feb 19 13:35:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1-ext.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAtNE-00055J-IT; Sun, 19 Feb 2006 13:33:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAtND-00055E-77 for sip@ietf.org; Sun, 19 Feb 2006 13:33:31 -0500 Received: from celine.siteprotect.com ([64.41.122.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAtN9-0001GQ-Rp for sip@ietf.org; Sun, 19 Feb 2006 13:33:31 -0500 Received: from [192.168.1.4] (pool-141-157-104-69.balt.east.verizon.net [141.157.104.69]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id k1JIXOg21892; Sun, 19 Feb 2006 12:33:24 -0600 Subject: Re: [Sip] PING draft update From: "Frank W. Miller" To: Jeroen van Bemmel In-Reply-To: <001c01c63578$adc081e0$31713b51@BEMBUSTER> References: <1140275643.2503.4.camel@localhost.localdomain> <001c01c63578$adc081e0$31713b51@BEMBUSTER> Content-Type: text/plain Organization: Cornfed Systems, LLC Date: Sun, 19 Feb 2006 13:33:23 -0500 Message-Id: <1140374003.2635.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fwmiller@cornfed.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org You're correct. I overlooked the 405 being used for methods that are recognized, which would clearly not be the case for older implementations. I'll make this change. FM On Sun, 2006-02-19 at 18:19 +0100, Jeroen van Bemmel wrote: > Frank, > > A UAS not recognizing PING would send back a 501 response, not a 405 (see > RFC3261 section 21.5.2) > > Regards, > > Jeroen > > ----- Original Message ----- > From: "Frank W. Miller" > To: > Sent: Saturday, February 18, 2006 4:14 PM > Subject: [Sip] PING draft update > > > > > > I've updated the draft to remove the restriction that it be sent only > > during a session and added the ability to treat a 405 coming back from a > > UAS that does not support PING as a valid response. > > > > http://www.cornfed.com/ping.txt > > > > 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 > > > _______________________________________________ > 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 sip-bounces@ietf.org Sun Feb 19 17:11:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1-ext.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAwkM-0001i3-MR; Sun, 19 Feb 2006 17:09:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAwkL-0001hy-3s for sip@ietf.org; Sun, 19 Feb 2006 17:09:37 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAwkK-0006w0-PU for sip@ietf.org; Sun, 19 Feb 2006 17:09:37 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IUY00I01G3GIP@siemenscomms.co.uk> for sip@ietf.org; Sun, 19 Feb 2006 22:06:52 +0000 (GMT) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IUY00DA1G3G6N@siemenscomms.co.uk>; Sun, 19 Feb 2006 22:06:52 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <1TP9FHXQ>; Sun, 19 Feb 2006 22:09:35 +0000 Content-return: allowed Date: Sun, 19 Feb 2006 22:09:27 +0000 From: "Elwell, John" Subject: RE: [Sip] Outbound and STUN Keep Alive To: Cullen Jennings , Chris Boulton , Gary Gan , Dean Willis , Francois Audet Message-id: <50B1CBA96870A34799A506B2313F266708184689@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: sip@ietf.org, fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org It seems that the double CRLF solution is the most efficient and least likely to impact scalability. It suffers from the problem Cullen points out below. STUN has the advantage of commonality with UDP (although I am doubtful about the value of this, because it is solving different problems), but it is never going to be quite as scaleable as the CRLF approach. (By the way, I agree with those who say SIP OPTIONS, SIP PING etc. are not scalable.) What about something between the CRLF approach and the STUN approach, just sufficient to give a rudimentary transaction capability? It could involve as little as 2 bytes in each direction, where one byte is used to distinguish the message from SIP and the second byte is used as a cyclic sequence number. When you get the same sequence number back you know that connectivity is still in place. It is still two protocols on one port, so doubtless those who don't like STUN and SIP on one port will not like this proposal either. The question is, whether this would be more scalable than STUN. To me, the scalability issue is the biggest issue we have to solve, and I think this solution is pretty well as efficient as you can get while still having the concept of a transaction. John > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: 18 February 2006 02:09 > To: Chris Boulton; Gary Gan; Dean Willis; Francois Audet > Cc: sip@ietf.org; fwmiller@cornfed.com > Subject: Re: [Sip] Outbound and STUN Keep Alive > > On 2/17/06 2:22 AM, "Chris Boulton" wrote: > > > I don't know why the double CRLF is not enough for keep-alive. > > There have been a few people (Sean and Gary) that posted on the list > pointing out that they use double CRLF (with TCP) and it works. > > Clearly the double CRLF does not work with UDP and we will > need STUN there. > Dean pointed out that with double CRLF, because there is no > transaction > identifier there might be a problem. The UA sends a CRLF, > then the UA waits > to get one back and if it does not receive one in a > reasonable time, it > considered the connection dead. The issue is, you might not > get a CRLF back > to the same thing you sent - there might have just been a > CRLF lying around > for no good reason. I don't know if this would turn out to be > a problem or > not but it certainly is worth thinking about. > > > > _______________________________________________ > 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 sip-bounces@ietf.org Sun Feb 19 17:31:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1-ext.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAx3c-0002c4-JK; Sun, 19 Feb 2006 17:29:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAx3b-0002bw-Pe for sip@ietf.org; Sun, 19 Feb 2006 17:29:31 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAx3b-0007sg-E4 for sip@ietf.org; Sun, 19 Feb 2006 17:29:31 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 19 Feb 2006 14:29:31 -0800 X-IronPort-AV: i="4.02,128,1139212800"; d="scan'208"; a="1777695235:sNHT34460776" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k1JMTSZC010846; Sun, 19 Feb 2006 14:29:28 -0800 (PST) Received: from 10.21.144.14 ([10.21.144.14]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sun, 19 Feb 2006 22:29:27 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sun, 19 Feb 2006 14:29:49 -0800 Subject: Re: [Sip] Outbound and STUN Keep Alive From: Cullen Jennings To: John Elwell , Chris Boulton , Gary Gan , Dean Willis , Francois Audet Message-ID: Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcY1o/5bPMNWf6GXEdqJWQARJEEJ/A== In-Reply-To: <50B1CBA96870A34799A506B2313F266708184689@ntht201e.siemenscomms.co.uk> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: "sip@ietf.org" , fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Agree with John. I've been trying to think about the details of the double CRLF. It's hard to construct and exact case (that does not involve buggy software) that would results in double CRLF with no transaction identifier getting messed up due to lack of transaction identifier. I can't decide if the lack of transaction id is a real problem or a theoretical one. We will need STUN for UDP so also have to deal with the do we want one or two things (but agree with your comments below. On 2/19/06 2:09 PM, "Elwell, John" wrote: > It seems that the double CRLF solution is the most efficient and least > likely to impact scalability. It suffers from the problem Cullen points out > below. STUN has the advantage of commonality with UDP (although I am > doubtful about the value of this, because it is solving different problems), > but it is never going to be quite as scaleable as the CRLF approach. (By the > way, I agree with those who say SIP OPTIONS, SIP PING etc. are not > scalable.) > > What about something between the CRLF approach and the STUN approach, just > sufficient to give a rudimentary transaction capability? It could involve as > little as 2 bytes in each direction, where one byte is used to distinguish > the message from SIP and the second byte is used as a cyclic sequence > number. When you get the same sequence number back you know that > connectivity is still in place. It is still two protocols on one port, so > doubtless those who don't like STUN and SIP on one port will not like this > proposal either. The question is, whether this would be more scalable than > STUN. To me, the scalability issue is the biggest issue we have to solve, > and I think this solution is pretty well as efficient as you can get while > still having the concept of a transaction. > > John > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: 18 February 2006 02:09 >> To: Chris Boulton; Gary Gan; Dean Willis; Francois Audet >> Cc: sip@ietf.org; fwmiller@cornfed.com >> Subject: Re: [Sip] Outbound and STUN Keep Alive >> >> On 2/17/06 2:22 AM, "Chris Boulton" wrote: >> >>> I don't know why the double CRLF is not enough for keep-alive. >> >> There have been a few people (Sean and Gary) that posted on the list >> pointing out that they use double CRLF (with TCP) and it works. >> >> Clearly the double CRLF does not work with UDP and we will >> need STUN there. >> Dean pointed out that with double CRLF, because there is no >> transaction >> identifier there might be a problem. The UA sends a CRLF, >> then the UA waits >> to get one back and if it does not receive one in a >> reasonable time, it >> considered the connection dead. The issue is, you might not >> get a CRLF back >> to the same thing you sent - there might have just been a >> CRLF lying around >> for no good reason. I don't know if this would turn out to be >> a problem or >> not but it certainly is worth thinking about. >> >> >> >> _______________________________________________ >> 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 sip-bounces@ietf.org Sun Feb 19 22:35:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB1o6-0008Ck-D6; Sun, 19 Feb 2006 22:33:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB1o5-0008Cf-84 for sip@ietf.org; Sun, 19 Feb 2006 22:33:49 -0500 Received: from [202.103.147.144] (helo=mail2.zte.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FB1o2-0007ch-Kb for sip@ietf.org; Sun, 19 Feb 2006 22:33:49 -0500 Received: from [10.30.1.239] by 10.30.2.249 with StormMail ESMTP id 70900.2063653853; Mon, 20 Feb 2006 12:47:46 +0800 (CST) In-Reply-To: <20060218110523.71714.qmail@web8613.mail.in.yahoo.com> To: Thejeswara Reddy Subject: =?GB2312?B?tPC4tDogUmU6IFtTaXBdIG9uZSBxdWVzdGlvbiBmb3IgdGltZW91dA==?= =?GB2312?B?IHByb2Nlc3NpbmcgaW4gUkZDMzM5OA==?= MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 Message-ID: From: shi.hao2@zte.com.cn Date: Mon, 20 Feb 2006 11:33:42 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.3|September 14, 2004) at 2006-02-20 11:36:50, Serialize complete at 2006-02-20 11:36:50 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1069152326==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1069152326== Content-Type: multipart/alternative; boundary="=_alternative 0014078D4825711B_=" This is a multipart message in MIME format. --=_alternative 0014078D4825711B_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 IEhp77yMdGhlamENCg0KIElmIE1HQyBzZW5kIGEgMTAwIHRyeWluZywgdGhlcmUgaXMgbm8gb3Jp Z2luYWwgSU5WSVRFIHJldHJhbnNtaXNzaW9uIA0KdGltZXMgb3V0Lg0KDQpCZXN0IFJlZ2FyZHMg DQpMaW9uRWFnbGUgDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0NCuWunui0qOaAp+eahOS4nOilv++8jOeUqOecvOedm+aYr+eci+S4jeingeea hO+8jOWPquacieeUqOW/g+aJjeiDveeci+W+l+a4hQ0KPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KICAgICAgICAgICAgICDmlr3mtakxMTE1NDMN CiAgICAg5Lit5b+D56CU56m26ZmiICDlm7rnvZHova/ku7blvIDlj5Hpg6gNClRlbDogICAgKzg2 LTI1LTUyODcxMzYxDQpFLW1haWw6IHNoaS5oYW8yQG1haWwuenRlLmNvbS5jbg0KTVNOOiAgICBM aW9uRWFnbGU3NEBob3RtYWlsLmNvbQ0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KDQoNCg0KDQpUaGVqZXN3YXJhIFJlZGR5IDx0aGVqYV9yZWRk eV9wQHlhaG9vLmNvLmluPg0KDQoyMDA2LTAyLTE4IDE5OjA1DQogDQogICAgICAgIOaUtuS7tuS6 uu+8miAgICAgICAgc2hpLmhhbzJAenRlLmNvbS5jbiwgc2lwQGlldGYub3JnDQogICAgICAgIOaK hOmAge+8miANCiAgICAgICAg5Li76aKY77yaICBSZTogW1NpcF0gb25lIHF1ZXN0aW9uIGZvciB0 aW1lb3V0IHByb2Nlc3NpbmcgaW4gUkZDMzM5OA0KDQoNCnBsZWFzZSBjb3JyZWN0IG1lIGlmIGkg YW0gd3JvbmcuDQpTaW5jZSBNR0MgaXQgc2VsZiBoYXMgYWJpbGl0eSB0byBzZW5kIDEwMCB0cnlp bmcgKHByb3Zpc2lvbmFsIHJlc3BvbnNlKSwgDQpzbyB0aGVyZSBpcyBubyBwcm9ibGVtIG9mIHNl bmRpbmcgQ0FOQ0VMIGJlZm9yZSBwcm92aXNpb25hbCByZXNwb25zZXMgdG8gDQpVQVMuDQoNCnJl Z2FyZHMNCnRoZWphDQpzaGkuaGFvMkB6dGUuY29tLmNuIHdyb3RlOg0KDQpIaSwgDQoNCg0KSW4g UkZDMzM5OCBwYWdlIDMzLCBzZWN0aW9uIDguMS4zIFNJUCBUaW1lb3V0LCBNR0Mgc2VuZHMgQ0FO Q0VMIHJlcXVlc3QgdG8gDQpVQVMgd2hlbiB0aGUgb3JpZ2luYWwgSU5WSVRFIHJldHJhbnNtaXNz aW9uIHRpbWVzIG91dCwgd2hpbGUgVUFDIE1VU1QgTk9UIA0Kc2VuZCBDQU5DRUwgcmVxdWVzdCBp ZiBubyByZXNwb25zZSBpcyByZWNlaXZlZCBhcyBSRkMzMjYxIHBhZ2UgNTQsIHNlY3Rpb24gDQo5 LjEgQ2xpZW50IEJlaGF2aW9yLCBkZXNjcmliZWQ6IA0KDQogICJJZiBubyBwcm92aXNpb25hbCBy ZXNwb25zZSBoYXMgYmVlbiByZWNlaXZlZCwgdGhlIENBTkNFTCByZXF1ZXN0IE1VU1QgDQogICBO T1QgYmUgc2VudDsgcmF0aGVyLCB0aGUgY2xpZW50IE1VU1Qgd2FpdCBmb3IgdGhlIGFycml2YWwg b2YgYSANCiAgIHByb3Zpc2lvbmFsIHJlc3BvbnNlIGJlZm9yZSBzZW5kaW5nIHRoZSByZXF1ZXN0 LiIgDQoNCklzIGl0IGEgYnVnIGZvciBSRkMzMzk4PyANCg0KDQpCZXN0IFJlZ2FyZHMgDQpMaW9u RWFnbGUgDQoNCg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKiANCua3h+KEg+S8heeAueWkiuWPj+a+ueeJiOankemUm+awrea5sOmWre6Gu+asoumNluWR reaDiOa3h+KEg+S8heiksOaOkeW9gua1oOacteaxiemOteKCrOmNpuOEp+eyjee8geWbqOWijemP iOWkmw0K57SdIA0K6Y2Z5oic5qyi5rWc54OY5aKN6Y2m44Sn57KN57yB5Zun7oeu55KH44Op5YGW 5rWg6Ii15aui6Y+I5aSL5aKN6Y+I5aSL5r2I6Y2S4pS/4oKs5YKd7oes6Y6644Om5pW56ZGw5ZGu 5pWe6Y6wPyANCua3h+a/hueYkemUm+Wxvua5ree8geW/k+W9gua1oOacteaxiea2lO+5gua9sOeS geeov+W9sumUm+WxvOesieWvsOalgOaCnOa1oOius+e2jee7lz8gDQrmtpPlpIvmn5/nvIHli63n spDpjZzlsbzph5zmtZzmtKrigqzlv5vmubbpj4juhITlgZbmtaDoiLXloo3pjZrugqHkv4rpjq3u iJzmrpHpjY/jhKnlhLQgDQrpjrTmoK3lhLTpjZLll5DigqzlgpnkupLmtpPlqYLvvJDpj4Tlup3n so7plqvlgpzmlaTmtZzluqHkvJDmtaPmu4jlgZbmtaDourLigqw/IA0KSW5mb3JtYXRpb24gU2Vj dXJpdHkgIE5vdGljZemUmz8gDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFp bCBpcyANCnNvbGVseSBwcm9wZXJ0eSBvZiAgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gDQpU aGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIA0KUmVjaXBpZW50cyBuYW1l ZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIA0KbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBw ZXJtaXR0ZWQgdG8gDQpkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9u IA0KdG8gb3RoZXJzLiANCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqIA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KU2lwIG1haWxpbmcgbGlzdCBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zaXANClRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJUCBQ cm90b2NvbA0KVXNlIHNpcC1pbXBsZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1IGZvciBxdWVzdGlv bnMgb24gY3VycmVudCBzaXANClVzZSBzaXBwaW5nQGlldGYub3JnIGZvciBuZXcgZGV2ZWxvcG1l bnRzIG9uIHRoZSBhcHBsaWNhdGlvbiBvZiBzaXANCg0KSml5byBjcmlja2V0IG9uIFlhaG9vISBJ bmRpYSBjcmlja2V0DQpZYWhvbyEgTWVzc2VuZ2VyIE1vYmlsZSBTdGF5IGluIHRvdWNoIHdpdGgg eW91ciBidWRkaWVzIGFsbCB0aGUgdGltZS4NCg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKiogDQpUaGUgZW1haWwgaGFzICBiZWVuIHNjYW5uZWQgYnkg QW50aS1TcGFtIA0Kc3lzdGVtLCAgaWYgeW91IGZpbmQgU3BhbSBvciBWaXJ1cyBpbiB0aGlzIG1h aWwsIA0KcGxlYXNlIGZvcndhcmQgaXQgdG8gSVQgaGVscGRlc2suIA0KKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqIA0KDQoNCgoKCioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQrQxc+isLLIq8n5w/ejurG+08q8/rD8 uqzQxc+iuem3orz+yMvL+dTa1+nWr8v509CjrA0Kt6K8/sjLy/nU2tfp1q+21LjD08q8/tO109DL +dPQyKjA+6Gjx+u908rV1d/XotLiDQqxo8Pco6zOtL6tt6K8/sjLyunD5tDtv8mjrLK7tcPP8sjO us612g0KyP23vdfp1q+6zbj2yMvNuMK2sb7Tyrz+y/m6rNDFz6K1xMirsr8NCrvysr+31qGj0tTJ z8n5w/e99srK08PT2rmk1/fTyrz+oaMNCkluZm9ybWF0aW9uIFNlY3VyaXR5ICBOb3RpY2Wjug0K VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMNCnNvbGVseSBwcm9wZXJ0 eSBvZiAgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gDQpUaGlzIG1haWwgY29tbXVuaWNhdGlv biBpcyBjb25maWRlbnRpYWwuDQpSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQg dG8NCm1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvDQpkaXNjbG9zZSB0 aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uDQp0byBvdGhlcnMuDQoqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KCg== --=_alternative 0014078D4825711B_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwO0hp77yMPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj50aGVqYTwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7SWYgTUdDIHNlbmQgYSAxMDAgdHJ5aW5n LCB0aGVyZQ0KaXMgbm8gb3JpZ2luYWwgSU5WSVRFIHJldHJhbnNtaXNzaW9uIHRpbWVzIG91dC48 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJlc3QgUmVn YXJkczwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkxpb25FYWdsZTwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PTxicj4NCuWunui0qOaAp+eahOS4nOilv++8jOeUqOecvOedm+aYr+eci+S4jein geeahO+8jOWPquacieeUqOW/g+aJjeiDveeci+W+l+a4hTxicj4NCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQogJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A75pa95rWpMTExNTQzPGJyPg0KICZuYnNw OyAmbmJzcDsg5Lit5b+D56CU56m26ZmiICZuYnNwO+Wbuue9kei9r+S7tuW8gOWPkemDqDxicj4N ClRlbDogJm5ic3A7ICZuYnNwOys4Ni0yNS01Mjg3MTM2MTxicj4NCkUtbWFpbDogc2hpLmhhbzJA bWFpbC56dGUuY29tLmNuPGJyPg0KTVNOOiAmbmJzcDsgJm5ic3A7TGlvbkVhZ2xlNzRAaG90bWFp bC5jb208YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+ VGhlamVzd2FyYSBSZWRkeSAmbHQ7dGhlamFfcmVkZHlfcEB5YWhvby5jby5pbiZndDs8L2I+PC9m b250Pg0KPGJyPg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMDYtMDItMTgg MTk6MDU8L2ZvbnQ+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg5pS25Lu25Lq677yaDQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtzaGkuaGFvMkB6dGUuY29tLmNuLCBzaXBAaWV0Zi5vcmc8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyDmioTpgIHvvJoNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvZm9udD4NCjxicj48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IOS4u+mimO+8mg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UmU6IFtTaXBdIG9uZSBxdWVz dGlvbiBmb3IgdGltZW91dCBwcm9jZXNzaW5nDQppbiBSRkMzMzk4PC9mb250PjwvdGFibGU+DQo8 YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPnBsZWFzZSBjb3Jy ZWN0IG1lIGlmIGkgYW0gd3JvbmcuPGJyPg0KU2luY2UgTUdDIGl0IHNlbGYgaGFzIGFiaWxpdHkg dG8gc2VuZCAxMDAgdHJ5aW5nIChwcm92aXNpb25hbCByZXNwb25zZSksDQpzbyB0aGVyZSBpcyBu byBwcm9ibGVtIG9mIHNlbmRpbmcgQ0FOQ0VMIGJlZm9yZSBwcm92aXNpb25hbCByZXNwb25zZXMg dG8NClVBUy48YnI+DQo8YnI+DQpyZWdhcmRzPGJyPg0KdGhlamE8Yj48aT48YnI+DQpzaGkuaGFv MkB6dGUuY29tLmNuPC9pPjwvYj4gd3JvdGU6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj48YnI+DQpIaSw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPiA8YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxi cj4NCkluIFJGQzMzOTggcGFnZSAzMywgc2VjdGlvbiA4LjEuMyBTSVAgVGltZW91dCwgTUdDIHNl bmRzIENBTkNFTCByZXF1ZXN0DQp0byBVQVMgd2hlbiB0aGUgb3JpZ2luYWwgSU5WSVRFIHJldHJh bnNtaXNzaW9uIHRpbWVzIG91dCwgd2hpbGUgVUFDIE1VU1QNCk5PVCBzZW5kIENBTkNFTCByZXF1 ZXN0IGlmIG5vIHJlc3BvbnNlIGlzIHJlY2VpdmVkIGFzIFJGQzMyNjEgcGFnZSA1NCwNCnNlY3Rp b24gOS4xIENsaWVudCBCZWhhdmlvciwgZGVzY3JpYmVkOjwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPjxicj4NCiAmbmJzcDsmcXVvdDtJZiBubyBwcm92aXNpb25hbCByZXNwb25zZSBoYXMgYmVl biByZWNlaXZlZCwgdGhlIENBTkNFTCByZXF1ZXN0DQpNVVNUPC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48 YnI+DQogJm5ic3A7IE5PVCBiZSBzZW50OyByYXRoZXIsIHRoZSBjbGllbnQgTVVTVCB3YWl0IGZv ciB0aGUgYXJyaXZhbCBvZiBhPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4N CjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KICZuYnNwOyBwcm92 aXNpb25hbCByZXNwb25zZSBiZWZvcmUgc2VuZGluZyB0aGUgcmVxdWVzdC4mcXVvdDs8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpJcyBpdCBhIGJ1ZyBmb3IgUkZDMzM5OD88L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkJlc3QgUmVnYXJkczwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+PGJyPg0KTGlvbkVhZ2xlPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij4gPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKiogPGJyPg0K5reH4oSD5LyF54C55aSK5Y+P5r6554mI5qeR6ZSb5rCt 5rmw6Zat7oa75qyi6Y2W5ZGt5oOI5reH4oSD5LyF6KSw5o6R5b2C5rWg5py15rGJ6Y614oKs6Y2m 44Sn57KN57yB5Zuo5aKN6Y+I5aSb57SdDQo8YnI+DQrpjZnmiJzmrKLmtZzng5jloo3pjabjhKfn so3nvIHlm6fuh67nkofjg6nlgZbmtaDoiLXlq6Lpj4jlpIvloo3pj4jlpIvmvYjpjZLilL/igqzl gp3uh6zpjrrjg6bmlbnpkbDlka7mlZ7pjrA/DQo8YnI+DQrmt4fmv4bnmJHplJvlsb7mua3nvIHl v5PlvYLmtaDmnLXmsYnmtpTvuYLmvbDnkoHnqL/lvbLplJvlsbznrInlr7DmpYDmgpzmtaDorrPn to3nu5c/DQo8YnI+DQrmtpPlpIvmn5/nvIHli63nspDpjZzlsbzph5zmtZzmtKrigqzlv5vmubbp j4juhITlgZbmtaDoiLXloo3pjZrugqHkv4rpjq3uiJzmrpHpjY/jhKnlhLQNCjxicj4NCumOtOag reWEtOmNkuWXkOKCrOWCmeS6kua2k+Wpgu+8kOmPhOW6neeyjumWq+WCnOaVpOa1nOW6oeS8kOa1 o+a7iOWBlua1oOi6suKCrD8NCjxicj4NCkluZm9ybWF0aW9uIFNlY3VyaXR5ICZuYnNwO05vdGlj ZemUmz8gPGJyPg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgPGJy Pg0Kc29sZWx5IHByb3BlcnR5IG9mICZuYnNwO3RoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uICZu YnNwOzxicj4NClRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gPGJyPg0K UmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIDxicj4NCm1haW50YWluIHNl Y3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIDxicj4NCmRpc2Nsb3NlIHRoZSBjb250ZW50 cyBvZiB0aGlzIGNvbW11bmljYXRpb24gPGJyPg0KdG8gb3RoZXJzLiA8YnI+DQoqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiA8YnI+DQo8YnI+DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClNpcCBtYWlsaW5n IGxpc3QgaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwPGJyPg0KVGhp cyBsaXN0IGlzIGZvciBORVcgZGV2ZWxvcG1lbnQgb2YgdGhlIGNvcmUgU0lQIFByb3RvY29sPGJy Pg0KVXNlIHNpcC1pbXBsZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1IGZvciBxdWVzdGlvbnMgb24g Y3VycmVudCBzaXA8YnI+DQpVc2Ugc2lwcGluZ0BpZXRmLm9yZyBmb3IgbmV3IGRldmVsb3BtZW50 cyBvbiB0aGUgYXBwbGljYXRpb24gb2Ygc2lwPC9mb250Pg0KPGJyPg0KPHA+DQo8aHI+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkppeW8gY3JpY2tldCBvbiA8L2ZvbnQ+PGEgaHJlZj1o dHRwOi8vdXMucmQueWFob28uY29tL21haWwvaW4vbWFpbGNyaWNrZXQvKmh0dHA6Ly9pbi5zcG9y dHMueWFob28uY29tL2NyaWNrZXQvPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMt c2VyaWYiPjx1PllhaG9vIQ0KSW5kaWEgY3JpY2tldDwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9 MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJl Zj1odHRwOi8vdXMucmQueWFob28uY29tL21haWwvaW4vbWFpbG1vYmlsZW1lc3Nlbmdlci8qaHR0 cDovL2luLm1vYmlsZS55YWhvby5jb20vbmV3L21lc3Nlbmdlci8+PGZvbnQgc2l6ZT0zIGNvbG9y PWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+WWFob28hDQpNZXNzZW5nZXIgTW9iaWxlPC91Pjwv Zm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiBTdGF5IGluIHRvdWNoDQp3 aXRoIHlvdXIgYnVkZGllcyBhbGwgdGhlIHRpbWUuPGJyPg0KPGJyPg0KPGJyPg0KKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqIDxicj4NClRoZSBlbWFpbCBo YXMgJm5ic3A7YmVlbiBzY2FubmVkIGJ5IEFudGktU3BhbSA8YnI+DQpzeXN0ZW0sICZuYnNwO2lm IHlvdSBmaW5kIFNwYW0gb3IgVmlydXMgaW4gdGhpcyBtYWlsLCA8YnI+DQpwbGVhc2UgZm9yd2Fy ZCBpdCB0byBJVCBoZWxwZGVzay4gJm5ic3A7PGJyPg0KKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqIDxicj4NCjwvZm9udD4NCjxwPg0KPGJyPjxicj48YnI+ CioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDTxicj4K0MXP orCyyKvJ+cP3o7qxvtPKvP6w/Lqs0MXPornpt6K8/sjLy/nU2tfp1q/L+dPQo6wNPGJyPgq3orz+ yMvL+dTa1+nWr7bUuMPTyrz+07XT0Mv509DIqMD7oaPH673TytXV39ei0uINPGJyPgqxo8Pco6zO tL6tt6K8/sjLyunD5tDtv8mjrLK7tcPP8sjOus612g08YnI+Csj9t73X6davus249sjLzbjCtrG+ 08q8/sv5uqzQxc+itcTIq7K/DTxicj4Ku/Kyv7fWoaPS1MnPyfnD9732ysrTw9PauaTX99PKvP6h ow08YnI+CkluZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDsmbmJzcDtOb3RpY2Wjug08YnI+ ClRoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5i c3A7bWFpbCZuYnNwO2lzDTxicj4Kc29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwOyZu YnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwOw08YnI+ClRoaXMm bmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLg08 YnI+ClJlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdh dGVkJm5ic3A7dG8NPGJyPgptYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUm bmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0bw08YnI+CmRpc2Nsb3NlJm5ic3A7dGhlJm5i c3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uDTxicj4KdG8m bmJzcDtvdGhlcnMuDTxicj4KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioNPGJyPgo8YnI+Cg== --=_alternative 0014078D4825711B_=-- --===============1069152326== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1069152326==-- From sip-bounces@ietf.org Mon Feb 20 03:28:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB6Mx-0000JO-G8; Mon, 20 Feb 2006 03:26:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB6Mv-0000JJ-QP for sip@ietf.org; Mon, 20 Feb 2006 03:26:05 -0500 Received: from lhrga01-in.huawei.com ([57.66.76.5] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FB6Mv-0006c0-Bm for sip@ietf.org; Mon, 20 Feb 2006 03:26:05 -0500 Received: from huawei.com ([172.24.2.9]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUZ00B1M7EJUQ@lhrga01-in.huawei.com> for sip@ietf.org; Mon, 20 Feb 2006 07:56:44 +0000 (GMT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUZ00C1P8FPTW@szxga03-in.huawei.com> for sip@ietf.org; Mon, 20 Feb 2006 16:19:01 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUZ00A738FA0D@szxga03-in.huawei.com> for sip@ietf.org; Mon, 20 Feb 2006 16:19:01 +0800 (CST) Received: from w39649a ([10.76.176.178]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IUZ00ADK8O3UV@szxml02-in.huawei.com> for sip@ietf.org; Mon, 20 Feb 2006 16:24:11 +0800 (CST) Date: Mon, 20 Feb 2006 16:11:41 +0800 From: Xiao Wang To: sip@ietf.org Message-id: <01d601c635f5$4aefffa0$b2b04c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 9178bae9f85419fdc08e9f2c86e345d0 Subject: [Sip] A thread about problem of SIP event framework X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1296034741==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1296034741== Content-type: multipart/alternative; boundary="Boundary_(ID_1rXhrQ1wxCkgc9fsuyZ6mg)" This is a multi-part message in MIME format. --Boundary_(ID_1rXhrQ1wxCkgc9fsuyZ6mg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, all As we all know that SIP event framework RFC3265 define one method (SUBSCRIBE) to implement two functions, One is initial subscription, another is refresh subscription. According to RFC3265, the refresh SUBSCRIBE request not only refresh subscription, but also get a full state of last resource in NOTIFY request. It is overloaded to refresh SUBSCRIBE request, in some cases, the functions of refresh subscription and get resource full state must not provided together. User can choose to refresh subscription alone or get full state of last resource alone. The draft "draft-niemi-sip-subnot-etags-00" try to solve this problem, but it did not completely solve, it only restrain to contain the full state in NOTIFY that refresh SUBSCRIBE request make, but NOTIFY request is always sent after refresh SUBSCRIBE request. There have been a few threads about it. I will start a thread here. Define a parameter in Event header field, called "nonotify", like this Event: presence; nonotify If subscriber did not want to get full state of last resource , then include "nonotify" in the Event header field of refresh SUBSCRIBE request, otherwise did not include. The notifier received refresh SUBSCRIBE request, check Event header field, if notifier supported "nonotify" parameter, then it did not send NOTIFY, otherwise according to RFC3265 to do. Xiao --Boundary_(ID_1rXhrQ1wxCkgc9fsuyZ6mg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi, all

         As we all know that SIP event framework RFC3265 define one method (SUBSCRIBE) to implement two functions,

One is initial subscription, another is refresh subscription. According to RFC3265, the refresh SUBSCRIBE request not only

refresh subscription, but also get a full state of last resource in NOTIFY request. It is overloaded to refresh SUBSCRIBE request,

in some cases, the functions of refresh subscription and get resource full state must not provided together. User can choose to refresh

subscription alone or get full state of last resource alone.

 

         The draft ”draft-niemi-sip-subnot-etags-00” try to solve this problem, but it did not completely solve, it only restrain to contain the full

state in NOTIFY that refresh SUBSCRIBE request make, but NOTIFY request is always sent after refresh SUBSCRIBE request.

 

         There have been a few threads about it. I will start a thread here.

         Define a parameter in Event header field, called “nonotify”, like this   

Event: presence; nonotify

 

         If subscriber did not want to get full state of last resource , then include “nonotify” in the Event header field of refresh SUBSCRIBE request, otherwise did not include.

     The notifier received refresh SUBSCRIBE request, check Event header field, if notifier supported  “nonotify” parameter, then it did not

send NOTIFY, otherwise according to RFC3265 to do.

 

 

Xiao

--Boundary_(ID_1rXhrQ1wxCkgc9fsuyZ6mg)-- --===============1296034741== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1296034741==-- From sip-bounces@ietf.org Mon Feb 20 03:48:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB6gW-0001Sl-W9; Mon, 20 Feb 2006 03:46:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB6gV-0001Sg-Vr for sip@ietf.org; Mon, 20 Feb 2006 03:46:19 -0500 Received: from lhrga01-in.huawei.com ([57.66.76.5] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FB6gV-00075r-Nf for sip@ietf.org; Mon, 20 Feb 2006 03:46:19 -0500 Received: from huawei.com ([172.24.2.3]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUZ00BUA8H6UQ@lhrga01-in.huawei.com> for sip@ietf.org; Mon, 20 Feb 2006 08:19:54 +0000 (GMT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUZ005AS9NQ64@szxga01-in.huawei.com> for sip@ietf.org; Mon, 20 Feb 2006 16:45:26 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUZ004D99NP9T@szxga01-in.huawei.com> for sip@ietf.org; Mon, 20 Feb 2006 16:45:26 +0800 (CST) Received: from w39649a ([10.76.176.178]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IUZ00AHF9R2UV@szxml02-in.huawei.com> for sip@ietf.org; Mon, 20 Feb 2006 16:47:34 +0800 (CST) Date: Mon, 20 Feb 2006 16:35:04 +0800 From: Xiao Wang To: sip@ietf.org Message-id: <01e301c635f8$8f52fd20$b2b04c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Sip] A thread about problem of SIP event framework X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, all As we all know that SIP event framework RFC3265 define one method (SUBSCRIBE) to implement two functions, One is initial subscription, another is refresh subscription. According to RFC3265, the refresh SUBSCRIBE request not only refresh subscription, but also get a full state of last resource in NOTIFY request. It is overloaded to refresh SUBSCRIBE request, in some cases, the functions of refresh subscription and get resource full state must not provided together. User can choose to refresh subscription alone or get full state of last resource alone. The draft "draft-niemi-sip-subnot-etags-00" try to solve this problem, but it did not completely solve, it only restrain to contain the full state in NOTIFY that refresh SUBSCRIBE request make, but NOTIFY request is always sent after refresh SUBSCRIBE request. There have been a few threads about it. I will start a thread here. Define a parameter in Event header field, called "nonotify", like this Event: presence; nonotify If subscriber did not want to get full state of last resource , then include "nonotify" in the Event header field of refresh SUBSCRIBE request, otherwise did not include. The notifier received refresh SUBSCRIBE request, check Event header field, if notifier supported "nonotify" parameter, then it did not send NOTIFY, otherwise according to RFC3265 to do. Xiao _______________________________________________ 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 sip-bounces@ietf.org Mon Feb 20 04:49:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB7dT-0003ar-QV; Mon, 20 Feb 2006 04:47:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB7dS-0003am-Vj for sip@ietf.org; Mon, 20 Feb 2006 04:47:14 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FB7dR-0000Y6-37 for sip@ietf.org; Mon, 20 Feb 2006 04:47:14 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id B8B3E194476 for ; Mon, 20 Feb 2006 10:47:11 +0100 (CET) Received: from [192.168.1.78] ([192.168.1.78]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Feb 2006 10:45:47 +0100 In-Reply-To: <43F60111.1080202@cisco.com> References: <43F60111.1080202@cisco.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2eaccb818d151d9cfc5df3873a99a294@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Mon, 20 Feb 2006 10:47:30 +0100 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 20 Feb 2006 09:45:47.0648 (UTC) FILETIME=[6D323800:01C63602] X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: 'Cullen Jennings' , sip@ietf.org, 'Francois Audet' , fwmiller@cornfed.com, 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan, On Feb 17, 2006, at 6:00 PM, Jonathan Rosenberg wrote: > The functional benefit of STUN over CRLF is two things: > > 1. a clear transaction ID that makes it EASIER to do timeouts. Its > possible without it, just more difficult. > > 2. more importantly, it allows you, for UDP, to detect a reboot of the > NAT. STUN will echo back the source port in MAPPED_ADDRESS. The UA can > look at this and detect nat reboot. Without this, you won't notice it > for an entire registration interval and thus effectively have a > service outage. Imagine this happening at an enterprise with SIP > phones and the server provided by a service provider on the public > side of the nat. Basically, a reboot of the enterprise nat would > result in a total system outage for an entire hour. There needs to be > a way to avoid this. I agree this specific feature is very useful and necessary. We experience such problems of rebooting NATs with our customers today. What we are not taking into account the overhead of having 2 protocol stacks talk to each other. We need to do the following: - modify the sip parser to recognise the message is a stun message (replicating code in the stun stack) - modify the stun stack to accept stun messages from an adjacent protocol stack - modify stun stack to enable it to send stun messages through another protocol stack instead of tcp/ip sockets - modify the sip stack to talk to the stun stack for sending an receiving stun messages - build an application on top of both stacks that watches stun responses to keepalive stun requests and triggers SIP REGISTER requests whenever the external ip-address/port of a binding has changed. The last point above requires some processing as well that is not being taken into considerations by the statistics being presented on this thread. I have earlier suggested a similar sip method to PING, called it NATKEEPALIVE that the server responds to with a 200 Ok and adding a contact header reflecting the source IP address and port, effectively achieving what we are trying to achieve with stun. Hisham > > -Jonathan R. > > Gary Gan wrote: > >> Are we overkilling this issue by inventing a new keep-alive mechanism >> that >> could potentially overload the server by 90% more, just to resolve a >> down-time situation, which can be automatically recovered anyway but >> just >> delayed for a few minutes? But I have to agree that some UA >> implementation >> defaults the SIP REGISTER expiry time to 1 hour, in which case the >> problem >> would be more severe. So the problem becomes the UA polling for the >> healthy of the server, >> probably the healthy of the logical UDP binding. To let the server >> echo the >> simple keep-alive, such as CRLF, probably is enough for this issue. It >> doesn't introduce too much overhead to the server and network. >> Theoretically, the echo back CRLF can get lost, but it can be handled >> in the >> UA side by retransmitting the keep-alive polling when it can not find >> the >> response. If it fails a few times, the UA can declare the server >> down, out >> of service. By introducing the multiplexing of STUN server with SIP >> server for the >> purpose of keep-alive, I don't see obvious more benefits than a simple >> PING/PONG mechanism. I agree to use STUN, ICE on the side to solve the >> firewall traversal. But it would be only per restart of UA or per call >> basis. Not constant polling even when it is idle. >> Some IP service provider may change the NAT IP address on the daily >> basis, >> but I don't believe it would change it when there is a keep-alive >> message >> going on in a period of like 15 seconds, even though the message is >> short. >> Gary Gan >> Sr. Software Developer >> Clique Communications, LLC >> 205 Rockingham Row >> Princeton Forrestal Village >> Princeton, NJ 08540 >> Phone: 609-564-0206 >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Thursday, >> February 16, 2006 5:20 PM >> To: Gary Gan >> Cc: 'Francois Audet'; 'Cullen Jennings'; sip@ietf.org; >> fwmiller@cornfed.com >> Subject: Re: [Sip] Outbound and STUN Keep Alive >> On Feb 16, 2006, at 3:23 PM, Gary Gan wrote: >>> The only problem I can think of is that the UA doesn't know if the >>> server is >>> down between now and the next SIP REGISTER is sent. >> Right, that's exactly the problem we're trying to solve. Keeping the >> NAT alive is only half the problem -- knowing when it has died and we >> need to renegotiate is the other half. >> Sure, we could REGISTER every 15 seconds, but I'm POSITIVE that's >> going to slow things down . . . >> -- >> 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 > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.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 > _______________________________________________ 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 sip-bounces@ietf.org Mon Feb 20 04:51:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB7fS-0003mR-9L; Mon, 20 Feb 2006 04:49:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB7Bm-0002fe-QU for sip@ietf.org; Mon, 20 Feb 2006 04:18:38 -0500 Received: from not01-fw01.citel.com ([62.190.107.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FB6zu-0007UR-70 for sip@ietf.org; Mon, 20 Feb 2006 04:06:23 -0500 Received: from [10.7.1.3] (helo=not01-mxc01.citel.com) by not01-fw01.citel.com with esmtp (Exim 4.43) id 1FB6zm-0008NO-Jx; Mon, 20 Feb 2006 09:06:14 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Mon, 20 Feb 2006 09:06:14 -0000 Message-ID: <592CA2F7E2BFBD4088AC87ECFF34BECE2D6CD7@not01-mxc01.citel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcY1o/5bPMNWf6GXEdqJWQARJEEJ/AAV+lvw From: "Michael Procter" To: "Cullen Jennings" , "John Elwell" , "Chris Boulton" , "Gary Gan" , "Dean Willis" , "Francois Audet" X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: sip@ietf.org, fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen Jennings wrote: > Agree with John.=20 >=20 > I've been trying to think about the details of the double=20 > CRLF. It's hard to > construct and exact case (that does not involve buggy=20 > software) that would > results in double CRLF with no transaction identifier getting=20 > messed up due > to lack of transaction identifier. I can't decide if the lack=20 > of transaction > id is a real problem or a theoretical one. What about a compromise? Use double CRLFs. If there is any doubt about the response (either no response within expected timeframe, or unexpected response etc.), then generate an OPTIONS. This means that almost all keepalive traffic uses the lightweight double CRLF approach, but that in the event of a network anomaly, a normal SIP method (no new methods required) can be used to confirm the path. If by some chance, a rogue double CRLF was dropped or inserted into the stream, this normal method would also flush it out, returning the stream to a known state. This seems to combine the best of both worlds - a lightweight approach for normal use, and a more robust system when you need it. Regards, Michael Procter _______________________________________________ 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 sip-bounces@ietf.org Mon Feb 20 04:52:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB7gH-0003uL-6v; Mon, 20 Feb 2006 04:50:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB7gG-0003uC-6n for sip@ietf.org; Mon, 20 Feb 2006 04:50:08 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FB7gF-0000bf-NC for sip@ietf.org; Mon, 20 Feb 2006 04:50:08 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 2585A194473 for ; Mon, 20 Feb 2006 10:50:07 +0100 (CET) Received: from [192.168.1.78] ([192.168.1.78]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Feb 2006 10:48:43 +0100 In-Reply-To: <002201c633f6$617f4560$2c28a8c0@brett1> References: <002201c633f6$617f4560$2c28a8c0@brett1> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Mon, 20 Feb 2006 10:50:26 +0100 To: "Brett Tate" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 20 Feb 2006 09:48:43.0158 (UTC) FILETIME=[D5CEEB60:01C63602] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: 'Cullen Jennings' , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Forget about OPTIONS as an option for nat keepalives. It has a specific job to do and proxies/UAs have code already built in to handle it. It is a bad idea to try to optimise OPTIONS for the purpose of keepalives, imo. Hisham On Feb 17, 2006, at 8:14 PM, Brett Tate wrote: >> I don't see any reason that the PING will work >> better than just sending OPTIONS > > It doesn't have to be PING or PING as currently defined. It could be > any > new SIP method which by definition indicates that parsing the rest of > the > message is ok but not really needed. > > The problem with OPTIONS is that it requires the typical full > processing to > identify the target, identify a willing to produce a successful > response, > produce the full successful OPTIONS data, and adhere to potential > forking > concerns. > > > > _______________________________________________ > 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 sip-bounces@ietf.org Mon Feb 20 04:54:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB7j2-0004SD-Ag; Mon, 20 Feb 2006 04:53:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB7j1-0004Ry-8r for sip@ietf.org; Mon, 20 Feb 2006 04:52:59 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FB7j0-0000gB-NX for sip@ietf.org; Mon, 20 Feb 2006 04:52:59 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 12DAB194473 for ; Mon, 20 Feb 2006 10:52:58 +0100 (CET) Received: from [192.168.1.78] ([192.168.1.78]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Feb 2006 10:51:34 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <11a5e085ff2381fdfc834c81c31e36c7@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Mon, 20 Feb 2006 10:53:17 +0100 To: "Gary Gan" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 20 Feb 2006 09:51:34.0042 (UTC) FILETIME=[3BA9BFA0:01C63603] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: 'Cullen Jennings' , sip@ietf.org, 'Francois Audet' , fwmiller@cornfed.com, 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Feb 17, 2006, at 3:09 AM, Gary Gan wrote: > Are we overkilling this issue by inventing a new keep-alive mechanism > that > could potentially overload the server by 90% more, just to resolve a > down-time situation, which can be automatically recovered anyway but > just > delayed for a few minutes? But I have to agree that some UA > implementation > defaults the SIP REGISTER expiry time to 1 hour, in which case the > problem > would be more severe. > > So the problem becomes the UA polling for the healthy of the server, > probably the healthy of the logical UDP binding. To let the server > echo the > simple keep-alive, such as CRLF, probably is enough for this issue. It > doesn't introduce too much overhead to the server and network. > Theoretically, the echo back CRLF can get lost, but it can be handled > in the > UA side by retransmitting the keep-alive polling when it can not find > the > response. If it fails a few times, the UA can declare the server down, > out > of service. Forget about the CRLF for UDP as well. It does not have the feature that solves the rebooting NAT problem. Hisham > > By introducing the multiplexing of STUN server with SIP server for the > purpose of keep-alive, I don't see obvious more benefits than a simple > PING/PONG mechanism. I agree to use STUN, ICE on the side to solve the > firewall traversal. But it would be only per restart of UA or per call > basis. Not constant polling even when it is idle. > > Some IP service provider may change the NAT IP address on the daily > basis, > but I don't believe it would change it when there is a keep-alive > message > going on in a period of like 15 seconds, even though the message is > short. > > Gary Gan > Sr. Software Developer > > Clique Communications, LLC > 205 Rockingham Row > Princeton Forrestal Village > Princeton, NJ 08540 > Phone: 609-564-0206 > > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Thursday, February 16, 2006 5:20 PM > To: Gary Gan > Cc: 'Francois Audet'; 'Cullen Jennings'; sip@ietf.org; > fwmiller@cornfed.com > Subject: Re: [Sip] Outbound and STUN Keep Alive > > On Feb 16, 2006, at 3:23 PM, Gary Gan wrote: >> The only problem I can think of is that the UA doesn't know if the >> server is >> down between now and the next SIP REGISTER is sent. > > Right, that's exactly the problem we're trying to solve. Keeping the > NAT alive is only half the problem -- knowing when it has died and we > need to renegotiate is the other half. > > Sure, we could REGISTER every 15 seconds, but I'm POSITIVE that's > going to slow things down . . . > > -- > 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 sip-bounces@ietf.org Mon Feb 20 04:58:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB7mT-0005GO-5e; Mon, 20 Feb 2006 04:56:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB7mR-0005GC-Lu for sip@ietf.org; Mon, 20 Feb 2006 04:56:31 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FB7mR-0000m5-BS for sip@ietf.org; Mon, 20 Feb 2006 04:56:31 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id C0CBA194472 for ; Mon, 20 Feb 2006 10:56:30 +0100 (CET) Received: from [192.168.1.78] ([192.168.1.78]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Feb 2006 10:55:06 +0100 In-Reply-To: <002c01c6340a$6c7f7ed0$2c28a8c0@brett1> References: <002c01c6340a$6c7f7ed0$2c28a8c0@brett1> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7ddeb881adc6147f4fffb9c9baa564a4@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Mon, 20 Feb 2006 10:56:50 +0100 To: "Brett Tate" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 20 Feb 2006 09:55:06.0708 (UTC) FILETIME=[BA6C0140:01C63603] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org That is hardly a concern. You need to implement something to solve the problem. If we chose stun and proxy vendors don't implement it, then we have the same problem. Hisham On Feb 17, 2006, at 10:37 PM, Brett Tate wrote: >> it doesn't respond to SIP OPTION message, the UA >> would trigger retransmission which further jams >> the server. > > That is one concern I have about trying to define/use a new SIP > message for > the keep alive. Because of security reasons or poor implementations, > some > servers might ignore the unknown request instead of producing an > appropriate > failure response. However STUN has the same limitation. > > > > _______________________________________________ > 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 sip-bounces@ietf.org Mon Feb 20 05:00:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB7of-0005e4-FZ; Mon, 20 Feb 2006 04:58:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB7oe-0005dh-2e for sip@ietf.org; Mon, 20 Feb 2006 04:58:48 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FB7od-0000ot-IT for sip@ietf.org; Mon, 20 Feb 2006 04:58:48 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 998BB194473 for ; Mon, 20 Feb 2006 10:58:46 +0100 (CET) Received: from [192.168.1.78] ([192.168.1.78]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Feb 2006 10:57:22 +0100 In-Reply-To: References: <62B9B0847CC47543B6B3B5E26BD268E60A709751@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6aac51f0fdfacbe3e2ddf2d0f68ed008@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Mon, 20 Feb 2006 10:59:06 +0100 To: Dean Willis X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 20 Feb 2006 09:57:22.0562 (UTC) FILETIME=[0B65AE20:01C63604] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: sip@ietf.org, Brian Stucker X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Feb 17, 2006, at 10:42 PM, Dean Willis wrote: > > On Feb 17, 2006, at 2:51 PM, Samir Srivastava wrote: > >> If client gets the response it is expecting, there is no issue. What >> else it is expecting on the PING, pl >> Clarify. Server is free to optimize. > > And what if some future extension uses a Proxy-Require or such to > enforce some other extension behavior, but we don't process the new > Proxy-Require because we're not parsing the whole SIP message? > > Breaks the SIP feature-negotiation model. How future proof does the mechanism need to be? I don't see any extension to such SIP method in the near future. Hisham > > Danger, Will Robinson! > > -- > 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 sip-bounces@ietf.org Mon Feb 20 05:09:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB7ws-0006i7-Ac; Mon, 20 Feb 2006 05:07:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB7wq-0006hx-Ph for sip@ietf.org; Mon, 20 Feb 2006 05:07:16 -0500 Received: from web8613.mail.in.yahoo.com ([202.43.219.182]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FB7wp-000114-5g for sip@ietf.org; Mon, 20 Feb 2006 05:07:16 -0500 Received: (qmail 35985 invoked by uid 60001); 20 Feb 2006 10:07:12 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Fu6q5B44Rt0MwUUdgtK0TJT6nqr76/jYm2hkmd/eAVH/+9U99v1Ya74rhd0TZXyu53hV8IipsExoJEY3lQSF8S0vO5EacsfmxuIgMurXUpMP4AvVAZkhqhwV89+u8OZd9mRhOtb9MORa7kgRN8YzpLrjR9yg1K0BoIxMup4Ev+s= ; Message-ID: <20060220100712.35983.qmail@web8613.mail.in.yahoo.com> Received: from [203.145.155.11] by web8613.mail.in.yahoo.com via HTTP; Mon, 20 Feb 2006 10:07:12 GMT Date: Mon, 20 Feb 2006 10:07:12 +0000 (GMT) From: Thejeswara Reddy Subject: =?iso-8859-1?q?Re:=20=B4=F0=B8=B4:=20Re:=20[Sip]=20one=20question=20for?= =?iso-8859-1?q?=20timeout=20processing=20in=20RFC3398?= To: shi.hao2@zte.com.cn In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2072057482==" Errors-To: sip-bounces@ietf.org --===============2072057482== Content-Type: multipart/alternative; boundary="0-28353618-1140430032=:35419" Content-Transfer-Encoding: 8bit --0-28353618-1140430032=:35419 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Shi, MGC sends 100 Trying to UAC, but it sent as unreliably, so there is no gurentee that UAC received it. so MGC sends cancel if it not receive any provisional response from next level entity (another MGC or proxyor UAS) shi.hao2@zte.com.cn wrote: Hi，theja If MGC send a 100 trying, there is no original INVITE retransmission times out. Best Regards LionEagle ==================================================== 实质性的东西，用眼ç›æ˜¯çœ‹ä¸è§çš„，åªæœ‰ç”¨å¿ƒæ‰èƒ½çœ‹å¾—清 ==================================================== 施浩111543 ä¸­å¿ƒç ”ç©¶é™¢ 固网软件开å‘部 Tel: +86-25-52871361 E-mail: shi.hao2@mail.zte.com.cn MSN: LionEagle74@hotmail.com ==================================================== Thejeswara Reddy 2006-02-18 19:05 收件人： shi.hao2@zte.com.cn, sip@ietf.org 抄é€ï¼š 主题： Re: [Sip] one question for timeout processing in RFC3398 please correct me if i am wrong. Since MGC it self has ability to send 100 trying (provisional response), so there is no problem of sending CANCEL before provisional responses to UAS. regards theja shi.hao2@zte.com.cn wrote: Hi, In RFC3398 page 33, section 8.1.3 SIP Timeout, MGC sends CANCEL request to UAS when the original INVITE retransmission times out, while UAC MUST NOT send CANCEL request if no response is received as RFC3261 page 54, section 9.1 Client Behavior, described: "If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request." Is it a bug for RFC3398? Best Regards LionEagle *********************************************** 淇℃伅瀹夊å澹版槑锛氭湰閭欢é–å‘­æƒˆæ·‡â„ƒä¼…è¤°æŽ‘å½‚æµ æœµæ±‰éŽµâ‚¬é¦ã„§ç²ç¼å›¨å¢éˆå¤›ç´ é™æˆœæ¬¢æµœçƒ˜å¢é¦ã„§ç²ç¼å›§î‡®ç’‡ãƒ©å–æµ èˆµå«¢éˆå¤‹å¢éˆå¤‹æ½ˆé’┿€å‚鎺ユ敹鑰呮敞鎰? 淇濆瘑锛屾湭ç¼å¿“å½‚æµ æœµæ±‰æ¶”ï¹‚æ½°ç’ç¨¿å½²é”›å±¼ç¬‰å¯°æ¥€æ‚œæµ è®³ç¶ç»—? 涓夋柟ç¼å‹­ç²éœå±¼é‡œæµœæ´ªâ‚¬å¿›æ¹¶éˆî„„å–æµ èˆµå¢éšî‚¡ä¿ŠéŽ­îˆœæ®‘éã„©å„´ éŽ´æ ­å„´é’å—€備互涓婂ï¼é„åºç²Žé–«å‚œæ•¤æµœåº¡ä¼æµ£æ»ˆå–æµ èº²â‚¬? Information Security Noticeé”›? The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. *********************************************** _______________________________________________ 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 --------------------------------- Jiyo cricket on Yahoo! India cricket Yahoo! Messenger Mobile Stay in touch with your buddies all the time. ************************************************ The email has been scanned by Anti-Spam system, if you find Spam or Virus in this mail, please forward it to IT helpdesk. ************************************************ *********************************************** ÐÅÏ¢°²È«ÉùÃ÷£º±¾Óʼþ°üº¬ÐÅÏ¢¹é·¢¼þÈËËùÔÚ×éÖ¯ËùÓУ¬ ·¢¼þÈËËùÔÚ×éÖ¯¶Ô¸ÃÓʼþÓµÓÐËùÓÐȨÀû¡£Çë½ÓÊÕÕß×¢Òâ ±£ÃÜ£¬Î´¾­·¢¼þÈËÊéÃæÐí¿É£¬²»µÃÏòÈÎºÎµÚ Èý·½×éÖ¯ºÍ¸öÈË͸¶±¾ÓʼþËùº¬ÐÅÏ¢µÄÈ«²¿ »ò²¿·Ö¡£ÒÔÉÏÉùÃ÷½öÊÊÓÃÓÚ¹¤×÷Óʼþ¡£ Information Security Notice£º The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. *********************************************** --------------------------------- Jiyo cricket on Yahoo! India cricket Yahoo! Messenger Mobile Stay in touch with your buddies all the time. --0-28353618-1140430032=:35419 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Shi,

MGC sends 100 Trying to UAC, but it sent as unreliably, so there is no gurentee that UAC received it. so MGC sends cancel if it not receive any provisional response from next level entity (another MGC or proxyor UAS)

shi.hao2@zte.com.cn wrote:

 Hi，theja

 If MGC send a 100 trying, there is no original INVITE retransmission times out.

Best Regards
LionEagle

====================================================
实质性的东西，用眼ç›æ˜¯çœ‹ä¸è§çš„，åªæœ‰ç”¨å¿ƒæ‰èƒ½çœ‹å¾—清
====================================================
             æ–½æµ©111543
    中心研究院  å›ºç½‘软件开å‘部
Tel:    +86-25-52871361
E-mail: shi.hao2@mail.zte.com.cn
MSN:    LionEagle74@hotmail.com
====================================================



Thejeswara Reddy <theja_reddy_p@yahoo.co.in>
2006-02-18 19:05
       
        收件人：        shi.hao2@zte.com.cn, sip@ietf.org
        抄é€ï¼š        
        主题：        Re: [Sip] one question for timeout processing in RFC3398



please correct me if i am wrong.
Since MGC it self has ability to send 100 trying (provisional response), so there is no problem of sending CANCEL before provisional responses to UAS.

regards
theja
shi.hao2@zte.com.cn wrote:

Hi,


In RFC3398 page 33, section 8.1.3 SIP Timeout, MGC sends CANCEL request to UAS when the original INVITE retransmission times out, while UAC MUST NOT send CANCEL request if no response is received as RFC3261 page 54, section 9.1 Client Behavior, described:

 "If no provisional response has been received, the CANCEL request MUST
  NOT be sent; rather, the client MUST wait for the arrival of a
  provisional response before sending the request."

Is it a bug for RFC3398?


Best Regards
LionEagle



***********************************************
淇℃伅瀹夊å澹版槑锛氭湰閭欢é–呭惈淇℃伅褰掑彂浠朵汉鎵€é¦ã„§ç²ç¼å›¨å¢éˆå¤›ç´
é™æˆœæ¬¢æµœçƒ˜å¢é¦ã„§ç²ç¼å›§î‡®ç’‡ãƒ©å–浠舵嫢éˆå¤‹å¢éˆå¤‹æ½ˆé’┿€å‚鎺ユ敹鑰呮敞鎰?
淇濆瘑锛屾湭ç¼å¿“彂浠朵汉涔﹂潰ç’稿彲锛屼笉寰楀悜浠讳ç¶ç»—?
涓夋柟ç¼å‹­ç²éœå±¼é‡œæµœæ´ªâ‚¬å¿›æ¹¶éˆî„„å–浠舵å¢éšî‚¡ä¿ŠéŽ­îˆœæ®‘éã„©å„´
鎴栭儴é’å—€備互涓婂ï¼é„åºç²Žé–«å‚œæ•¤æµœåº¡ä¼æµ£æ»ˆå–浠躲€?
Information Security  Noticeé”›?
The information contained in this mail is
solely property of  the sender's organization.  
This mail communication is confidential.
Recipients named above are obligated to
maintain secrecy and are not permitted to
disclose the contents of this communication
to others.
***********************************************

_______________________________________________
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
Jiyo cricket on Yahoo! India cricket
Yahoo! Messenger Mobile Stay in touch with your buddies all the time.


************************************************
The email has  been scanned by Anti-Spam
system,  if you find Spam or Virus in this mail,
please forward it to IT helpdesk.  
************************************************



***********************************************
ÐÅÏ¢°²È«ÉùÃ÷£º±¾Óʼþ°üº¬ÐÅÏ¢¹é·¢¼þÈËËùÔÚ×éÖ¯ËùÓУ¬
·¢¼þÈËËùÔÚ×éÖ¯¶Ô¸ÃÓʼþÓµÓÐËùÓÐȨÀû¡£Çë½ÓÊÕÕß×¢Òâ
±£ÃÜ£¬Î´¾­·¢¼þÈËÊéÃæÐí¿É£¬²»µÃÏòÈκεÚ
Èý·½×éÖ¯ºÍ¸öÈË͸¶±¾ÓʼþËùº¬ÐÅÏ¢µÄÈ«²¿
»ò²¿·Ö¡£ÒÔÉÏÉùÃ÷½öÊÊÓÃÓÚ¹¤×÷Óʼþ¡£
Information Security  Notice£º
The information contained in this mail is
solely property of  the sender's organization. 
This mail communication is confidential.
Recipients named above are obligated to
maintain secrecy and are not permitted to
disclose the contents of this communication
to others.
***********************************************


Jiyo cricket on Yahoo! India cricket
Yahoo! Messenger Mobile Stay in touch with your buddies all the time. --0-28353618-1140430032=:35419-- --===============2072057482== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============2072057482==-- From sip-bounces@ietf.org Mon Feb 20 05:17:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB85F-0007GH-3d; Mon, 20 Feb 2006 05:15:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB85D-0007G8-FP for sip@ietf.org; Mon, 20 Feb 2006 05:15:55 -0500 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FB85C-0001Le-Pa for sip@ietf.org; Mon, 20 Feb 2006 05:15:55 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id k1KAFsVV197466 for ; Mon, 20 Feb 2006 10:15:54 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k1KAG2RE241706 for ; Mon, 20 Feb 2006 11:16:02 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k1KAFrs9022163 for ; Mon, 20 Feb 2006 11:15:53 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k1KAFrNt022158; Mon, 20 Feb 2006 11:15:53 +0100 In-Reply-To: <01e301c635f8$8f52fd20$b2b04c0a@china.huawei.com> To: Xiao Wang Subject: Re: [Sip] A thread about problem of SIP event framework MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Avshalom Houri Message-ID: Date: Mon, 20 Feb 2006 12:16:01 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0HF90 | November 16, 2005) at 20/02/2006 12:16:01, Serialize complete at 20/02/2006 12:16:01 X-Spam-Score: 0.1 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1305529354==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1305529354== Content-Type: multipart/alternative; boundary="=_alternative 003835FFC225711B_=" This is a multipart message in MIME format. --=_alternative 003835FFC225711B_= Content-Type: text/plain; charset="US-ASCII" Xiao, I raised the issue several times in the simple list and in the sip-implementors list and got very small attention. The direction that you suggest seems as a good approach. I think that not sending the NOTIFY for SUBSCRIBE refreshes should have been the default behaviour in RFC 3265 but now your suggestion seem good to me. Thanks Avshalom Xiao Wang 20-02-06 10:35 AM To sip@ietf.org cc Subject [Sip] A thread about problem of SIP event framework Hi, all As we all know that SIP event framework RFC3265 define one method (SUBSCRIBE) to implement two functions, One is initial subscription, another is refresh subscription. According to RFC3265, the refresh SUBSCRIBE request not only refresh subscription, but also get a full state of last resource in NOTIFY request. It is overloaded to refresh SUBSCRIBE request, in some cases, the functions of refresh subscription and get resource full state must not provided together. User can choose to refresh subscription alone or get full state of last resource alone. The draft "draft-niemi-sip-subnot-etags-00" try to solve this problem, but it did not completely solve, it only restrain to contain the full state in NOTIFY that refresh SUBSCRIBE request make, but NOTIFY request is always sent after refresh SUBSCRIBE request. There have been a few threads about it. I will start a thread here. Define a parameter in Event header field, called "nonotify", like this Event: presence; nonotify If subscriber did not want to get full state of last resource , then include "nonotify" in the Event header field of refresh SUBSCRIBE request, otherwise did not include. The notifier received refresh SUBSCRIBE request, check Event header field, if notifier supported "nonotify" parameter, then it did not send NOTIFY, otherwise according to RFC3265 to do. Xiao _______________________________________________ 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 --=_alternative 003835FFC225711B_= Content-Type: text/html; charset="US-ASCII"
Xiao,

I raised the issue several times in the simple list and in the sip-implementors list and got very small attention.
The direction that you suggest seems as a good approach. I think that not sending the NOTIFY for
SUBSCRIBE refreshes should have been the default behaviour in RFC 3265 but now your suggestion seem
good to me.

Thanks
Avshalom


Xiao Wang <wangsmile@huawei.com>

20-02-06 10:35 AM

To
sip@ietf.org
cc
Subject
[Sip] A thread about problem of SIP event framework





Hi, all

        As we all know that SIP event framework RFC3265 define one method
(SUBSCRIBE) to implement two functions,

One is initial subscription, another is refresh subscription. According to
RFC3265, the refresh SUBSCRIBE request not only

refresh subscription, but also get a full state of last resource in NOTIFY
request. It is overloaded to refresh SUBSCRIBE request,

in some cases, the functions of refresh subscription and get resource full
state must not provided together. User can choose to refresh

subscription alone or get full state of last resource alone.



        The draft "draft-niemi-sip-subnot-etags-00" try to solve this
problem, but it did not completely solve, it only restrain to contain the
full state in NOTIFY that refresh SUBSCRIBE request make, but NOTIFY request
is always sent after refresh SUBSCRIBE request.



        There have been a few threads about it. I will start a thread here.

        Define a parameter in Event header field, called "nonotify", like
this  

Event: presence; nonotify



        If subscriber did not want to get full state of last resource ,
then include "nonotify" in the Event header field of refresh SUBSCRIBE
request, otherwise did not include.

       The notifier received refresh SUBSCRIBE request, check Event header
field, if notifier supported  "nonotify" parameter, then it did not send
NOTIFY, otherwise according to RFC3265 to do.

 

Xiao




_______________________________________________
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
--=_alternative 003835FFC225711B_=-- --===============1305529354== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1305529354==-- From sip-bounces@ietf.org Mon Feb 20 05:45:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB8Vi-0000CO-KU; Mon, 20 Feb 2006 05:43:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB7ZC-0003LY-DU for sip@ietf.org; Mon, 20 Feb 2006 04:42:50 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FB7T7-0000Az-IJ for sip@ietf.org; Mon, 20 Feb 2006 04:36:34 -0500 Received: from huawei.com ([172.24.2.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUZ00E1JBATF9@usaga01-in.huawei.com> for sip@ietf.org; Mon, 20 Feb 2006 01:20:54 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUZ009PCC0XZO@szxga02-in.huawei.com> for sip@ietf.org; Mon, 20 Feb 2006 17:36:33 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUZ00M2WC0XO5@szxga02-in.huawei.com> for sip@ietf.org; Mon, 20 Feb 2006 17:36:33 +0800 (CST) Received: from w39649a ([10.76.176.178]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IUZ005PYC6HQ2@szxml01-in.huawei.com> for sip@ietf.org; Mon, 20 Feb 2006 17:40:00 +0800 (CST) Date: Mon, 20 Feb 2006 17:23:55 +0800 From: Xiao Wang To: sip@ietf.org Message-id: <000801c635ff$6262c2d0$b2b04c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Sip] A thread about problem of SIP event framework X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, all As we all know that SIP event framework RFC3265 define one method (SUBSCRIBE) to implement two functions, One is initial subscription, another is refresh subscription. According to RFC3265, the refresh SUBSCRIBE request not only refresh subscription, but also get a full state of last resource in NOTIFY request. It is overloaded to refresh SUBSCRIBE request, in some cases, the functions of refresh subscription and get resource full state must not provided together. User can choose to refresh subscription alone or get full state of last resource alone. The draft "draft-niemi-sip-subnot-etags-00" try to solve this problem, but it did not completely solve, it only restrain to contain the full state in NOTIFY that refresh SUBSCRIBE request make, but NOTIFY request is always sent after refresh SUBSCRIBE request. There have been a few threads about it. I will start a thread here. Define a parameter in Event header field, called "nonotify", like this Event: presence; nonotify If subscriber did not want to get full state of last resource , then include "nonotify" in the Event header field of refresh SUBSCRIBE request, otherwise did not include. The notifier received refresh SUBSCRIBE request, check Event header field, if notifier supported "nonotify" parameter, then it did not send NOTIFY, otherwise according to RFC3265 to do. Xiao _______________________________________________ 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 sip-bounces@ietf.org Mon Feb 20 07:24:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBA3h-0004rP-El; Mon, 20 Feb 2006 07:22:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBA3g-0004rG-19 for sip@ietf.org; Mon, 20 Feb 2006 07:22:28 -0500 Received: from lhrga01-in.huawei.com ([57.66.76.5] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBA3f-0004uy-N2 for sip@ietf.org; Mon, 20 Feb 2006 07:22:28 -0500 Received: from huawei.com ([172.24.2.9]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUZ00F1YICP5M@lhrga01-in.huawei.com> for sip@ietf.org; Mon, 20 Feb 2006 11:53:13 +0000 (GMT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUZ00EKTJDUMG@szxga03-in.huawei.com> for sip@ietf.org; Mon, 20 Feb 2006 20:15:30 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUZ00GMSJDUKX@szxga03-in.huawei.com> for sip@ietf.org; Mon, 20 Feb 2006 20:15:30 +0800 (CST) Received: from w39649a ([10.76.176.178]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IUZ00EGXJMPGI@szxml02-in.huawei.com>; Mon, 20 Feb 2006 20:20:52 +0800 (CST) Date: Mon, 20 Feb 2006 20:08:27 +0800 From: Xiao Wang Subject: RE: [Sip] A thread about problem of SIP event framework In-reply-to: To: 'Avshalom Houri' Message-id: <000f01c63616$5b191a30$b2b04c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AcY2BqfT80N3dKMdQcCHWkUclb6VXAADUQnA X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Avshalom, Thanks. I think that this problem is although inappreciable, but in = fact take a trouble for developers in some scenario. Because there have many implementations according to RFC3265, so we had better find a good way to have least modify to implementations.=20 Folks, if have some new ideas? Xiao ________________________________________ From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com]=20 Sent: Monday, February 20, 2006 6:16 PM To: Xiao Wang Cc: sip@ietf.org Subject: Re: [Sip] A thread about problem of SIP event framework Xiao,=20 I raised the issue several times in the simple list and in the sip-implementors list and got very small attention.=20 The direction that you suggest seems as a good approach. I think that = not sending the NOTIFY for=20 SUBSCRIBE refreshes should have been the default behaviour in RFC 3265 = but now your suggestion seem=20 good to me.=20 Thanks=20 Avshalom Xiao Wang =20 20-02-06 10:35 AM=20 To sip@ietf.org=20 cc Subject [Sip] A thread about problem of SIP event framework Hi, all =A0 =A0 =A0 =A0 As we all know that SIP event framework RFC3265 define = one method (SUBSCRIBE) to implement two functions, One is initial subscription, another is refresh subscription. According = to RFC3265, the refresh SUBSCRIBE request not only refresh subscription, but also get a full state of last resource in = NOTIFY request. It is overloaded to refresh SUBSCRIBE request, in some cases, the functions of refresh subscription and get resource = full state must not provided together. User can choose to refresh subscription alone or get full state of last resource alone. =A0 =A0 =A0 =A0 The draft "draft-niemi-sip-subnot-etags-00" try to solve = this problem, but it did not completely solve, it only restrain to contain = the full state in NOTIFY that refresh SUBSCRIBE request make, but NOTIFY = request is always sent after refresh SUBSCRIBE request. =A0 =A0 =A0 =A0 There have been a few threads about it. I will start a = thread here. =A0 =A0 =A0 =A0 Define a parameter in Event header field, called = "nonotify", like this =A0=20 Event: presence; nonotify =A0 =A0 =A0 =A0 If subscriber did not want to get full state of last = resource , then include "nonotify" in the Event header field of refresh SUBSCRIBE request, otherwise did not include. =A0 =A0 =A0 =A0The notifier received refresh SUBSCRIBE request, check = Event header field, if notifier supported =A0"nonotify" parameter, then it did not = send NOTIFY, otherwise according to RFC3265 to do. =A0 Xiao _______________________________________________ Sip mailing list =A0https://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 sip-bounces@ietf.org Mon Feb 20 07:51:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBAUB-0005uA-9J; Mon, 20 Feb 2006 07:49:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBAUA-0005u4-3q for sip@ietf.org; Mon, 20 Feb 2006 07:49:50 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBAU8-0005uL-Mc for sip@ietf.org; Mon, 20 Feb 2006 07:49:50 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k1KCn6nm005026; Mon, 20 Feb 2006 14:49:07 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Feb 2006 14:49:39 +0200 Received: from [172.21.36.202] ([172.21.36.202]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 20 Feb 2006 14:49:38 +0200 Message-ID: <43F9BAE2.6020001@nokia.com> Date: Mon, 20 Feb 2006 14:49:38 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Xiao Wang Subject: Re: [Sip] A thread about problem of SIP event framework References: <01e301c635f8$8f52fd20$b2b04c0a@china.huawei.com> In-Reply-To: <01e301c635f8$8f52fd20$b2b04c0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Feb 2006 12:49:38.0995 (UTC) FILETIME=[1C643030:01C6361C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ext Xiao Wang wrote: > The draft "draft-niemi-sip-subnot-etags-00" try to solve this > problem, but it did not completely solve, it only restrain to contain the > full state in NOTIFY that refresh SUBSCRIBE request make, but NOTIFY request > is always sent after refresh SUBSCRIBE request. As I mentioned in some other thread, what's described in the draft is, in the scale of conservative-to-hackish, clearly on the conservative end. The draft also discusses the reasons for the choice. If consensus determines it is OK to break some of the RFC 3265 rules, then subnot-etags could simply be defined to always suppress the NOTIFY instead and, say, return a new 2xx response to the SUBSCRIBE for when the refresh succeeds, expiry is extended, but NOTIFY is suppressed. I still don't think following HTTP's and SIP PUBLISH's model and returning a 412 will work. > There have been a few threads about it. I will start a thread here. > > Define a parameter in Event header field, called "nonotify", like > this > > Event: presence; nonotify Sure, but I still prefer the subnot-etags mechanism, since this doesn't work with polls or fetches. And I'd like whatever mechanism we define to work for both cases. Cheers, Aki _______________________________________________ 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 sip-bounces@ietf.org Mon Feb 20 08:15:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBAoP-0007xb-DP; Mon, 20 Feb 2006 08:10:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBAoN-0007xR-US for sip@ietf.org; Mon, 20 Feb 2006 08:10:43 -0500 Received: from lhrga01-in.huawei.com ([57.66.76.5] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBAoN-0006Z3-M0 for sip@ietf.org; Mon, 20 Feb 2006 08:10:43 -0500 Received: from huawei.com ([172.24.2.9]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUZ007MWKZ4Q9@lhrga01-in.huawei.com> for sip@ietf.org; Mon, 20 Feb 2006 12:49:53 +0000 (GMT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUZ00EUYM0AMG@szxga03-in.huawei.com> for sip@ietf.org; Mon, 20 Feb 2006 21:12:10 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUZ009VVM09FT@szxga03-in.huawei.com> for sip@ietf.org; Mon, 20 Feb 2006 21:12:10 +0800 (CST) Received: from w39649a ([10.76.176.178]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IUZ00ESVM95GI@szxml02-in.huawei.com>; Mon, 20 Feb 2006 21:17:32 +0800 (CST) Date: Mon, 20 Feb 2006 21:05:07 +0800 From: Xiao Wang Subject: RE: [Sip] A thread about problem of SIP event framework In-reply-to: <43F9BAE2.6020001@nokia.com> To: 'Aki Niemi' Message-id: <001901c6361e$45bf94e0$b2b04c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcY2HCS977Cdv4qzSSGsWJCkeR56CgAAK3xw X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Aki, Your thread is right. But I want to make it more simple to solve this problem, and I prefer to split the SUBSCRIBE method to two single functions. If only suppress NOTIFY to be sent, subnot-etags wastes it's talent on a petty job. I think that subnot-etags must have more sufficient reason to use. Thanks. Xiao > -----Original Message----- > From: Aki Niemi [mailto:aki.niemi@nokia.com] > Sent: Monday, February 20, 2006 8:50 PM > To: ext Xiao Wang > Cc: sip@ietf.org > Subject: Re: [Sip] A thread about problem of SIP event framework > > > ext Xiao Wang wrote: > > The draft "draft-niemi-sip-subnot-etags-00" try to solve this > > problem, but it did not completely solve, it only restrain to contain the > > full state in NOTIFY that refresh SUBSCRIBE request make, but NOTIFY request > > is always sent after refresh SUBSCRIBE request. > > As I mentioned in some other thread, what's described in the draft is, > in the scale of conservative-to-hackish, clearly on the conservative > end. The draft also discusses the reasons for the choice. > > If consensus determines it is OK to break some of the RFC 3265 rules, > then subnot-etags could simply be defined to always suppress the NOTIFY > instead and, say, return a new 2xx response to the SUBSCRIBE for when > the refresh succeeds, expiry is extended, but NOTIFY is suppressed. > > I still don't think following HTTP's and SIP PUBLISH's model and > returning a 412 will work. > > > There have been a few threads about it. I will start a thread here. > > > > Define a parameter in Event header field, called "nonotify", like > > this > > > > Event: presence; nonotify > > Sure, but I still prefer the subnot-etags mechanism, since this doesn't > work with polls or fetches. And I'd like whatever mechanism we define to > work for both cases. > > Cheers, > Aki _______________________________________________ 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 sip-bounces@ietf.org Mon Feb 20 14:29:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBGgV-0004Bf-2p; Mon, 20 Feb 2006 14:26:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBGgT-0004BM-N5 for sip@ietf.org; Mon, 20 Feb 2006 14:26:57 -0500 Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBGgS-0001xZ-FR for sip@ietf.org; Mon, 20 Feb 2006 14:26:57 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k1KJQo6i043997; Mon, 20 Feb 2006 14:26:54 -0500 (EST) From: "Brett Tate" To: "'Dean Willis'" Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Mon, 20 Feb 2006 14:27:44 -0500 Message-ID: <001d01c63653$bc9d51d0$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > And what if some future extension uses a Proxy-Require or such to > enforce some other extension behavior, but we don't process the new=20 > Proxy-Require because we're not parsing the whole SIP message? >=20 > Breaks the SIP feature-negotiation model. Agreed. However the ECHOSRC request I mentioned is a 1 hop single = purpose request indicating that the headers do not need to be parsed (beyond potentially content-length). Thus the request is not intend to be = extended. And ECHODEFAULT could be similarly defined to request response delivery = to default port. And ECHOVIA could be similarly defined but require full processing on first Via entry. =20 I envision it to be something like the following. However this is an extreme example trying to ensure request not proxied. Thus if the = working group is overly concerned about some of these headers being echoed back, some could obviously be removed. Ip-addresses for From, To, and = request-uri could be sent instead of invalid. And devices which don't support = ECHOSRC can return their favorite response based upon what they dislike first: = 501, 405, 483, 420, 403, 603, 401, 407, etcetera. >ECHOSRC sip:invalid. SIP/2.0 >Via:SIP/2.0/tcp ip-address;branch=3Dz9hG4bKunique >f:sip:invalid.;tag=3Dunique =20 >t:sip:invalid. >i:unique >CSeq:1 ECHOSRC >Require:echo >Proxy-Require:echo >Max-Forwards:0 >l:0 Concerning security, devices would likely also want to validate the CSeq method name. Otherwise, it could make the device vulnerable to spoofing interference with other transactions. _______________________________________________ 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 sip-bounces@ietf.org Tue Feb 21 04:43:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBU1D-0002md-EU; Tue, 21 Feb 2006 04:41:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBU1C-0002mW-4t for sip@ietf.org; Tue, 21 Feb 2006 04:41:14 -0500 Received: from spark.hss.co.in ([203.145.155.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBU0u-0002k0-BN for sip@ietf.org; Tue, 21 Feb 2006 04:41:14 -0500 Received: from sandesh.hss.hns.com (sandesh [10.203.142.21]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id k1L9VQkR016523; Tue, 21 Feb 2006 15:04:05 +0530 (IST) Importance: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 From: Rayees Khan To: fwmiller@cornfed.com Date: Tue, 21 Feb 2006 14:48:04 +0530 Message-ID: X-MIMETrack: Serialize by Notes Server on Zarf/HSS(Release 6.5.1|January 21, 2004) at 02/21/2006 02:48:04 PM, Serialize complete at 02/21/2006 02:48:04 PM, Itemize by Notes Server on Zarf/HSS(Release 6.5.1|January 21, 2004) at 02/21/2006 02:48:04 PM, Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 21/02/2006 03:10:34 PM, Serialize complete at 21/02/2006 03:10:34 PM MIME-Version: 1.0 X-Spam-Score: 2.6 (++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: sip@ietf.org Subject: [Sip] draft-fwmiller-ping-00 comments X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1079346044==" Errors-To: sip-bounces@ietf.org --===============1079346044== Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Frank,

Section 2 of the draft mentions that signaling path of the= PING method is established as a result of a call setup. Now what I underst= and is that main purpose the method is to keep the signaling path alive or = to check the validity of the signaling path. This means that it would mostl= y be sent outside the context of a session. In such context I guess it has = to follow path of a dialog establishing request.

Section 2.1 lists t= he headers that are expected in the PING method. Well, I have come across d= evices using Require and Proxy-Require header in PING messages.

Sec= tion 2.2 mentions the responses that are expected for a PING request. I was= wondering that it is very well possible that if a server receives a PING r= equest which is addressed to something that Server does not know about it i= s most likely to send a 404 response.


regards
Rayees

<= br>*****FSS-Private *****" DISCLAIMER: This message is proprietary to Flext= ronics Software Systems Limited (FSS) and is intended solely for the use of= the individual to whom it is addressed. It may contain privileged or conf= idential information and should not be circulated or used for any purpose o= ther than for what it is intended. If you have received this message in err= or, please notify the originator immediately. If you are not the intend= ed recipient, you are notified that you are strictly prohibited from us= ing, copying, altering, or disclosing the contents of this mess= age. FSS accepts no responsibility for loss or damage arising from the use = of the information transmitted by this email including damage from virus."<= br />= --===============1079346044== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1079346044==-- From sip-bounces@ietf.org Tue Feb 21 08:46:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBXoM-0006bh-1W; Tue, 21 Feb 2006 08:44:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBXoL-0006bb-1G for sip@ietf.org; Tue, 21 Feb 2006 08:44:13 -0500 Received: from [66.113.136.12] (helo=smapp01.siteprotect.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBXoJ-0002zE-Q3 for sip@ietf.org; Tue, 21 Feb 2006 08:44:13 -0500 Received: from smapp01.siteprotect.com (localhost [127.0.0.1]) by smapp01.siteprotect.com (8.11.6/8.11.6) with ESMTP id k1LDhZn18587; Tue, 21 Feb 2006 07:43:36 -0600 Date: Tue, 21 Feb 2006 07:43:36 -0600 Message-Id: <200602211343.k1LDhZn18587@smapp01.siteprotect.com> From: fwmiller@cornfed.com To: "Rayees Khan" , fwmiller@cornfed.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: sip@ietf.org Subject: [Sip] RE: draft-fwmiller-ping-00 comments X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks for the comments. Discussion inline... ------------------------------------------------ On Tue, 21 Feb 2006 14:48:04 +0530, Rayees Khan wrote: > >Section 2 of the draft mentions that signaling path of the PING >method is established as a result of a call setup. Now what I >understand is that main purpose the method is to keep the >signaling path alive or to check the validity of the signaling >path. This means that it would mostly be sent outside the >context of a session. In such context I guess it has to follow >path of a dialog establishing request. The wording here should probably be changed. The intent is to have PINGs travel through the normal proxy sequence that any other request would take, thereby refreshing the entire path. I know we're talking mainly about the NAT traversal problem but if we're coming up with a general method, it should address keepalive all the way along whether there a forseen problems or not. When I changed it from in-session only to being able to send anytime, I didn't do any rewording here. I will do that now. >Section 2.1 lists the headers that are expected in the PING >method. Well, I have come across devices using Require and >Proxy-Require header in PING messages. Hmm. I'd be interested in any other discussion on this point. It would be nice to keep these out if possible to keep the message simple. >Section 2.2 mentions the responses that are expected for a PING >request. I was wondering that it is very well possible that if >a server receives a PING request which is addressed to >something that Server does not know about it is most likely to >send a 404 response. I'm wondering if it shouldnt just be any response except for a 1xx and 3xx class response. 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 sip-bounces@ietf.org Tue Feb 21 10:54:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBZod-00077i-0l; Tue, 21 Feb 2006 10:52:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBZoc-00077c-5K for sip@ietf.org; Tue, 21 Feb 2006 10:52:38 -0500 Received: from hostr51.alcatel.com ([143.209.5.1] helo=aurfsy.aur.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBZoa-00016q-Oh for sip@ietf.org; Tue, 21 Feb 2006 10:52:38 -0500 Received: from usrald00141 (localhost [127.0.0.1]) by aurfsy.aur.alcatel.com (8.11.6+Sun/8.11.3) with ESMTP id k1LFqZJ26110 for ; Tue, 21 Feb 2006 10:52:35 -0500 (EST) From: "Jim Li" To: Date: Tue, 21 Feb 2006 10:52:35 -0500 Message-ID: <004f01c636fe$d5869d40$8f0cd18f@ad3.ad.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcY2/rzW59wr9RlyQvi60JMmwa9mDg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Sip] Sip NAT Support Test Setup X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi there, I need help on how to set up a test bed to support Sip NAT with symmetric UDP and RTP ports. I have the following two proposals: 1. IAD (Sip capable) <===> Outbound Proxy Server <===> Sip Softswitch 2. IAD (Sip capable) <===> NAT <===> Outbound Proxy Server <===> Sip Softswitch Which one is the correct (or better) approach? If none is correct, could you tell me how to set up a proper one for testing Sip NAT traversal? Thanks in advance. Jim _______________________________________________ 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 sip-bounces@ietf.org Tue Feb 21 13:39:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBcOb-0001i3-7A; Tue, 21 Feb 2006 13:37:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBcOZ-0001hq-99 for sip@ietf.org; Tue, 21 Feb 2006 13:37:55 -0500 Received: from spark.hss.co.in ([203.145.155.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBcOY-0000fc-92 for sip@ietf.org; Tue, 21 Feb 2006 13:37:55 -0500 Received: from ultra.hss.co.in (ultra [192.168.100.5]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id k1LIV4wr004351; Wed, 22 Feb 2006 00:01:05 +0530 (IST) Received: from sandesh.hss.hns.com (sandesh [10.203.142.21]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id k1LIcat24455; Wed, 22 Feb 2006 00:08:37 +0530 (IST) Importance: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 From: Rayees Khan To: fwmiller@cornfed.com Date: Wed, 22 Feb 2006 00:04:20 +0530 Message-ID: X-MIMETrack: Serialize by Notes Server on Zarf/HSS(Release 6.5.1|January 21, 2004) at 02/22/2006 12:04:20 AM, Serialize complete at 02/22/2006 12:04:20 AM, Itemize by Notes Server on Zarf/HSS(Release 6.5.1|January 21, 2004) at 02/22/2006 12:04:20 AM, Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 22/02/2006 12:07:33 AM, Serialize complete at 22/02/2006 12:07:33 AM MIME-Version: 1.0 X-Spam-Score: 3.2 (+++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: sip@ietf.org, fwmiller@cornfed.com Subject: [Sip] RE: draft-fwmiller-ping-00 comments X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1020776892==" Errors-To: sip-bounces@ietf.org --===============1020776892== Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Hi Frank,

We can keep the message simple = if we make the Requires and Proxy-Require header optional.


regar= ds
Rayees

-----fwmiller@corn= fed.com wrote: -----

To: Rayees Khan/HSS@HSS, fwmiller@cornfed.com
From: = fwmiller@cornfed.com
Date: 02/21/2006 01:43PM
cc: sip@ietf.org
Sub= ject: RE: draft-fwmiller-ping-00 comments


Thanks for the comments.  Discussion inline...

--= ----------------------------------------------
On Tue, 21 Feb 2006 14:48= :04 +0530, Rayees Khan wrote:

= >
>Section 2 of the draft mentions that signaling path of the PIN= G >method is established as a result of a call setup. Now what I >und= erstand is that main purpose the method is to keep the >signaling path a= live or to check the validity of the signaling >path. This means that it= would mostly be sent outside the >context of a session. In such context= I guess it has to follow >path of a dialog establishing request.
The wording here should probably be changed.  The intent is to have P= INGs travel through the normal proxy sequence that any other request would = take, thereby refreshing the entire path.  I know we're talking mainly= about the NAT traversal problem but if we're coming up with a general meth= od, it should address keepalive all the way along whether there a forseen p= roblems or not.  When I changed it from in-session only to being able = to send anytime, I didn't do any rewording here.  I will do that now.<= br>

>Section 2.1 lists the headers that are expected in the PING = >method. Well, I have come across devices using Require and >Proxy-Re= quire header in PING messages.

Hmm.  I'd be interested in any o= ther discussion on this point.  It would be nice to keep these out if = possible to keep the message simple.


>Section 2.2 mentions th= e responses that are expected for a PING >request. I was wondering that = it is very well possible that if >a server receives a PING request which= is addressed to >something that Server does not know about it is most l= ikely to >send a 404 response.

I'm wondering if it shouldnt just = be any response except for a 1xx and 3xx class response.

FM


*****FSS-Priva= te *****" DISCLAIMER: This message is proprietary to Flextronics Software S= ystems Limited (FSS) and is intended solely for the use of the individual t= o whom it is addressed. It may contain privileged or confidential informat= ion and should not be circulated or used for any purpose other than for wha= t it is intended. If you have received this message in error, please no= tify the originator immediately. If you are not the intended recipient,= you are notified that you are strictly prohibited from using, copying&= #44; altering, or disclosing the contents of this message. FSS accepts = no responsibility for loss or damage arising from the use of the informatio= n transmitted by this email including damage from virus."
= --===============1020776892== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1020776892==-- From sip-bounces@ietf.org Tue Feb 21 13:48:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBcXA-0002T9-MQ; Tue, 21 Feb 2006 13:46:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBcX9-0002T3-Ge for sip@ietf.org; Tue, 21 Feb 2006 13:46:47 -0500 Received: from spark.hss.co.in ([203.145.155.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBcX8-00011S-6r for sip@ietf.org; Tue, 21 Feb 2006 13:46:47 -0500 Received: from ultra.hss.co.in (ultra [192.168.100.5]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id k1LIeCwr004708 for ; Wed, 22 Feb 2006 00:10:13 +0530 (IST) Received: from sandesh.hss.hns.com (sandesh [10.203.142.21]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id k1LIljt24837 for ; Wed, 22 Feb 2006 00:17:46 +0530 (IST) Importance: Normal X-Priority: 3 (Normal) Subject: Re: [Sip] Sip NAT Support Test Setup MIME-Version: 1.0 From: Rayees Khan To: "Jim Li" Date: Wed, 22 Feb 2006 00:13:29 +0530 Message-ID: X-MIMETrack: Serialize by Notes Server on Zarf/HSS(Release 6.5.1|January 21, 2004) at 02/22/2006 12:13:29 AM, Serialize complete at 02/22/2006 12:13:29 AM, Itemize by Notes Server on Zarf/HSS(Release 6.5.1|January 21, 2004) at 02/22/2006 12:13:29 AM, Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 22/02/2006 12:16:41 AM, Serialize complete at 22/02/2006 12:16:41 AM MIME-Version: 1.0 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0069059480==" Errors-To: sip-bounces@ietf.org --===============0069059480== Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Hi Jim,

If we are testing the SIP Device for NAT traversal = i guess option 2 is the setup that is correct. All the messages from the De= vice would have to traverse through NAT to reach the SIP Server and vice-ve= rsa.


regards
Rayees




-----"Jim Li" <jim.li@alcatel.com> wrote: -----

To: <sip@ie= tf.org>
From: "Jim Li" <jim.li@alcatel.com>
Date: 02/21/2006= 03:52PM
Subject: [Sip] Sip NAT Support Test Setup

Hi there,

I need help on how to set up a test = bed to support Sip NAT with symmetric
UDP and RTP ports. I have the foll= owing two proposals:

1. IAD (Sip capable) <=3D=3D=3D> Outbound= Proxy Server <=3D=3D=3D> Sip Softswitch

2. IAD (Sip capable) = <=3D=3D=3D> NAT <=3D=3D=3D> Outbound Proxy Server <=3D=3D=3D= > Sip
Softswitch

Which one is the correct (or better) approach= ? If none is correct, could you
tell me how to set up a proper one for t= esting Sip NAT traversal?

Thanks in advance.

Jim


<= br>=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Si= p mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW dev= elopment of the core SIP Protocol
Use sip-implementors@cs.columbia.edu f= or questions on current sip
Use sipping@ietf.org for new developments on= the application of sip


*****FSS-Private ***= **" DISCLAIMER: This message is proprietary to Flextronics Software Systems= Limited (FSS) and is intended solely for the use of the individual to whom= it is addressed. It may contain privileged or confidential information an= d should not be circulated or used for any purpose other than for what it i= s intended. If you have received this message in error, please notify t= he originator immediately. If you are not the intended recipient, you a= re notified that you are strictly prohibited from using, copying, a= ltering, or disclosing the contents of this message. FSS accepts no res= ponsibility for loss or damage arising from the use of the information tran= smitted by this email including damage from virus."
= --===============0069059480== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0069059480==-- From sip-bounces@ietf.org Tue Feb 21 14:38:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBdIs-0004Kp-JS; Tue, 21 Feb 2006 14:36:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBdIq-0004Ke-As for sip@ietf.org; Tue, 21 Feb 2006 14:36:04 -0500 Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBdIp-0004iZ-4j for sip@ietf.org; Tue, 21 Feb 2006 14:36:04 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k1LJZwXj036412; Tue, 21 Feb 2006 14:36:02 -0500 (EST) From: "Brett Tate" To: "'Dean Willis'" Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Tue, 21 Feb 2006 14:36:52 -0500 Message-ID: <002701c6371e$2dcf6170$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <2C7213DE-C04F-4DC9-8840-790C14C4401A@softarmor.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > Because some vendors would likely be slow to implement > > or never implement it, would it be beneficial to define > > a new easily optimized SIP request for this purpose? > > My guess is that if we have consensus on something like > coaxial STUN that we would be better-served by pushing > new development that way instead of adding another > stepping-stone. It would not necessarily just be a stepping stone. A version of it would likely allow a proxy chain to be checked. > Would it be reasonable to give guidance on use > of OPTIONS as a keepalive and on optimization > of OPTIONS request processing in UAs? It might help; and it is definitely better than some devices registering every 15 seconds. However it might be a little controversial trying to standardize a "best common practice" concerning how to misuse OPTIONS and REGISTER for this type of functionality. Because of the frequency of OPTIONS outside of a dialog being used explicitly for this type of functionality, some have already overly optimized/broke it for capacity/security reasons to receive OPTIONS but not provide useful data within the response. _______________________________________________ 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 sip-bounces@ietf.org Tue Feb 21 14:44:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBdPF-0004rS-94; Tue, 21 Feb 2006 14:42:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBdPD-0004rA-PY for sip@ietf.org; Tue, 21 Feb 2006 14:42:39 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBdPB-0004zP-EU for sip@ietf.org; Tue, 21 Feb 2006 14:42:39 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1LJgfwZ008124 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 21 Feb 2006 13:42:43 -0600 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Tue, 21 Feb 2006 13:42:37 -0600 To: "sip@ietf.org List" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Rohan Mahy Subject: [Sip] Agenda requests for SIP at IETF 65 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org WARNING: Please send me slides by 0800 on the day of the meeting. Sometimes the nets don't work well enough for last-minute posting. It looks like we'll have 4 hours of meeting time in Dallas. Clearly we'll need to talk about our chartered deliverables, including: Oct 2005 -- Mechanism for obtaining globally routable unique URIs (GRUU) Nov 2005 -- Connection reuse mechanism Dec 2005 -- Mechanism for Target-Dialog Jan 2006 -- Answering/Alerting Modes Feb 2006 -- Mechanism and guidelines for outbound connections Feb 2006 -- Guidelines for Using Certificates with SIP Mar 2006 -- Location Conveyance with SIP to IESG Apr 2006 -- Mechanism for End-to-Middle Requests to IESG Apr 2006 -- Mechanism for Response Identity to IESG Jul 2006 -- Using SAML for SIP TBD 2006 -- Route Construction Clearly the dates for some of these have not been met or are not going to be met. Perhaps we should be asking ourselves if we're really committed to doing all of these -- while some are basically trivial (and/or mostly done), others are really complex problems and we might should think about them in the longer-term if at all. Think about it. Note that we really need to prioritize meeting time to topics that require face-to-face discussion and are (in priority order): 1) Chartered 2) Critical to WG function 3) Actively being discussed by the WG on-list 4) Critical to external organizations with which we have relations 5) Entertaining to the capricious whims of the chairs, who clearly have no other opportunity for amusement. Note that the bar for this category is exceptionally high. If you have additional topics that need meeting time and fit into the above priority list, please respond to me with: 1) The topic 2) Name of person to be responsible for leading the discussion (and making slides) 3) Name(s) of the relevant drafts(s) 4) How much time you think you need to actually have a real discussion. Feel free to use the following template, replacing the placeholder text: TopicPlaceholder LeaderPlaceholder To: Rayees Khan In-Reply-To: References: Content-Type: text/plain Organization: Cornfed Systems, LLC Date: Tue, 21 Feb 2006 21:02:32 -0500 Message-Id: <1140573752.2638.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: sip@ietf.org Subject: [Sip] Re: draft-fwmiller-ping-00 comments X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fwmiller@cornfed.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Tue, 2006-02-21 at 14:48 +0530, Rayees Khan wrote: > Section 2 of the draft mentions that signaling path of the PING method > is established as a result of a call setup. Now what I understand is > that main purpose the method is to keep the signaling path alive or to > check the validity of the signaling path. This means that it would > mostly be sent outside the context of a session. In such context I > guess it has to follow path of a dialog establishing request. > Did some cleanup of wording here to make it more general. > Section 2.1 lists the headers that are expected in the PING method. > Well, I have come across devices using Require and Proxy-Require > header in PING messages. > I saw your other email. I'd still like to hear some other opinions before I add this. > Section 2.2 mentions the responses that are expected for a PING > request. I was wondering that it is very well possible that if a > server receives a PING request which is addressed to something that > Server does not know about it is most likely to send a 404 response. > > Changed the text to allow for any response other than a 1xx or 3xx to be interpreted as a 200 OK New version on the website: http://www.cornfed.com/ping.html and http://www.cornfed.com/ping.txt 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 sip-bounces@ietf.org Tue Feb 21 23:07:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBlFr-0006hh-Dz; Tue, 21 Feb 2006 23:05:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBlFp-0006hb-NF for sip@ietf.org; Tue, 21 Feb 2006 23:05:29 -0500 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBlFl-00047p-3t for sip@ietf.org; Tue, 21 Feb 2006 23:05:29 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 2A8E46C017 for ; Tue, 21 Feb 2006 23:05:22 -0500 (EST) From: "Dale R. Worley" To: Sip Content-Type: text/plain Date: Tue, 21 Feb 2006 23:05:21 -0500 Message-Id: <1140581121.25492.10.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Sip] What is going on with GRUU? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I am revising my I-D on implementing GRUU in UAs, and I'd like to make sure that I'm up to date on various details. Can people fill me in on the following? The last revision I see of draft-ietf-sip-gruu is 06, submitted on 2005-10-21. Is there an 07 revision in the works? Has the "edge router" problem been brought to a satisfactory conclusion? Or at least from the UA's point of view, can I assume that the routers will take care of the problem, so that the UAs don't have to make explicit accommodations for the edge router problem? I personally prefer that the Supported and Require headers describe only properties of the UAs, and not properties of the messages per se. (Although that a UA conforms to an extension may imply something about all messages it handles.) draft-ietf-sip-gruu-06 uses these headers to mark properties of messages, in that a UA must apply "Supported: gruu" to some requests and not to others. But I heard a considerable amount of support on the mailing lists for my attitude. Does draft-ietf-sip- gruu-06 still express the consensus of the WG? Thanks for any information, Dale _______________________________________________ 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 sip-bounces@ietf.org Wed Feb 22 00:45:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBmme-0002Yb-Jh; Wed, 22 Feb 2006 00:43:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBmmc-0002Xy-Pq for sip@ietf.org; Wed, 22 Feb 2006 00:43:26 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBmmb-0008O1-H3 for sip@ietf.org; Wed, 22 Feb 2006 00:43:26 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 21 Feb 2006 21:43:25 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,135,1139212800"; d="scan'208"; a="22379230:sNHT23656616" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1M5hMPO011055; Wed, 22 Feb 2006 00:43:23 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Feb 2006 00:43:22 -0500 Received: from [192.168.1.104] ([10.86.240.221]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Feb 2006 00:43:21 -0500 Message-ID: <43FBF9F9.3010806@cisco.com> Date: Wed, 22 Feb 2006 00:43:21 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Dale R. Worley" Subject: Re: [Sip] What is going on with GRUU? References: <1140581121.25492.10.camel@cdhcp139.pingtel.com> In-Reply-To: <1140581121.25492.10.camel@cdhcp139.pingtel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Feb 2006 05:43:21.0698 (UTC) FILETIME=[E3F5E420:01C63772] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dale R. Worley wrote: > I am revising my I-D on implementing GRUU in UAs, and I'd like to make > sure that I'm up to date on various details. Can people fill me in on > the following? > > The last revision I see of draft-ietf-sip-gruu is 06, submitted on > 2005-10-21. Is there an 07 revision in the works? Indeed it is. At the last meeting, we had a group of volunteers meet to try and come to conclusion on the whole sip-outbound/gruu/route-construct mess that seemed all intertwined again. No conclusion was reached there. We had some mail threads shortly thereafter, which died down without conclusion. These fired up again a few weeks back. There has been some progress, in that at least amongst the subset of those still posting on the thread, there has been agreement on a general path forward. This would impact gruu-07 and sip-outbound, and also route-construct which I will be submitting as a wg doc per consensus from last ietf. > > Has the "edge router" problem been brought to a satisfactory conclusion? > Or at least from the UA's point of view, can I assume that the routers > will take care of the problem, so that the UAs don't have to make > explicit accommodations for the edge router problem? With the solution we've come up with, yes. The basic idea is that the home proxy fixes this up. It does that by, in a mid-dialog request, rewriting the r-uri (which will contain the gruu) to the registered contact. This has the dual-effect of eliminating the spiraling, while preserving the record-routes for usage in all mid-dialog requests. The endpoint behavior is unchanged - clients include gruu in their contact, thats it. No endpoint record-routing (though I like this idea still, I think its premature to couple the entire solution to this significant change - its still something we can do later). Edge proxies don't do anything special either - just record-routing as normal. > > I personally prefer that the Supported and Require headers describe only > properties of the UAs, and not properties of the messages per se. > (Although that a UA conforms to an extension may imply something about > all messages it handles.) draft-ietf-sip-gruu-06 uses these headers to > mark properties of messages, in that a UA must apply "Supported: gruu" > to some requests and not to others. But I heard a considerable amount > of support on the mailing lists for my attitude. Does draft-ietf-sip- > gruu-06 still express the consensus of the WG? With the above solution, there is no requirement for the home proxy to know whether the contents of the contact are a gruu. As such, the spec will relax this constraint around usage in the contact and Supported: gruu. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.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 sip-bounces@ietf.org Wed Feb 22 01:17:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBnGe-0004PR-4E; Wed, 22 Feb 2006 01:14:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBnGc-0004PL-U5 for sip@ietf.org; Wed, 22 Feb 2006 01:14:26 -0500 Received: from nproxy.gmail.com ([64.233.182.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBnGb-0001Tz-LC for sip@ietf.org; Wed, 22 Feb 2006 01:14:26 -0500 Received: by nproxy.gmail.com with SMTP id l36so877780nfa for ; Tue, 21 Feb 2006 22:14:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=GSU8Wf6aJHm7/wFElJOxsJ3b8O5P0w1XVtrKm55knSfTX+E3RRaiRKozckF3EMSO7bYwHzi7XaUX6Gwsy/+ppnP9eB55jtVu6HM+xTtE3Y84Djmu1xTmbGGgHcCzAUDUrW2PmC9uVKkajLwFydXvTDjChF4jAHDDzYvBvX/G9Sg= Received: by 10.48.243.18 with SMTP id q18mr1730718nfh; Tue, 21 Feb 2006 22:14:24 -0800 (PST) Received: by 10.49.35.18 with HTTP; Tue, 21 Feb 2006 22:14:24 -0800 (PST) Message-ID: <52db68bc0602212214w7e34cf6i8e9c11ef362585fc@mail.gmail.com> Date: Wed, 22 Feb 2006 11:44:24 +0530 From: "Sudhir Kumar Reddy" To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Sip] Query about Notify Body X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0898374906==" Errors-To: sip-bounces@ietf.org --===============0898374906== Content-Type: multipart/alternative; boundary="----=_Part_11301_9453296.1140588864361" ------=_Part_11301_9453296.1140588864361 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi All, I would like to what are the important elements in message body for sending and receivcing the Notifies. is there any draft or RFC. any feedback is appericated Thanks in advance Sudhir ------=_Part_11301_9453296.1140588864361 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi All,
 
I would like to what are the important elements in message body f= or sending and receivcing the Notifies.
 
is there any draft or RFC.
 
any feedback is appericated
 
Thanks in advance
Sudhir
------=_Part_11301_9453296.1140588864361-- --===============0898374906== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0898374906==-- From sip-bounces@ietf.org Wed Feb 22 02:13:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBo9o-0006mM-86; Wed, 22 Feb 2006 02:11:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBo9m-0006m9-JL for sip@ietf.org; Wed, 22 Feb 2006 02:11:26 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBo9i-0003H4-Bk for sip@ietf.org; Wed, 22 Feb 2006 02:11:26 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k1M7QNG8004396 for ; Wed, 22 Feb 2006 00:26:23 -0700 (MST) Received: from ZMY16EXF63.ds.mot.com (zmy16exf63.ap.mot.com [10.179.4.22]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k1M7NAvI012565 for ; Wed, 22 Feb 2006 01:23:11 -0600 (CST) Received: from motorola.com ([10.232.117.39]) by ZMY16EXF63.ds.mot.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Feb 2006 15:11:14 +0800 Message-ID: <43FC0FAF.3020804@motorola.com> Date: Wed, 22 Feb 2006 12:45:59 +0530 From: Priti User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sudhir Kumar Reddy Subject: Re: [Sip] Query about Notify Body References: <52db68bc0602212214w7e34cf6i8e9c11ef362585fc@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Feb 2006 07:11:14.0823 (UTC) FILETIME=[2AFCE970:01C6377F] X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.5 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, You can refer RFC 3265 , 3856 & also draft-ietf-simple-event-list-06. ( For presence Notification; Not sure whether you are looking for the same ). /Priti Sudhir Kumar Reddy wrote: > Hi All, > > I would like to what are the important elements in message body for > sending and receivcing the Notifies. > > is there any draft or RFC. > > any feedback is appericated > > Thanks in advance > Sudhir > >------------------------------------------------------------------------ > >_______________________________________________ >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 sip-bounces@ietf.org Wed Feb 22 02:35:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBoUA-0007RK-Tk; Wed, 22 Feb 2006 02:32:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBoU9-0007QU-2M for sip@ietf.org; Wed, 22 Feb 2006 02:32:29 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBoLv-0003ov-Sm for sip@ietf.org; Wed, 22 Feb 2006 02:24:00 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k1M7Mq5Q029794; Wed, 22 Feb 2006 09:22:53 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Feb 2006 09:23:47 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Feb 2006 09:23:47 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Wed, 22 Feb 2006 09:23:46 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F01FE7E96@esebe103.NOE.Nokia.com> In-Reply-To: <11a5e085ff2381fdfc834c81c31e36c7@telio.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcY2BST5ychGJsR7SJ+gQTmsc9kfBgBeOzKw From: To: , X-OriginalArrivalTime: 22 Feb 2006 07:23:47.0060 (UTC) FILETIME=[EB5B2B40:01C63780] X-Spam-Score: 0.2 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: fluffy@cisco.com, sip@ietf.org, audet@nortel.com, fwmiller@cornfed.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi !=20 >Forget about the CRLF for UDP as well. It does not have=20 >the feature that solves the rebooting NAT problem. What about the following approach (at least as a short term solution while the ultimate solution will not yet be defined or supported by the deployed servers): - Send CRLF to SIP proxy for NAT binding keepalve - Simultaneously send STUN binding requests to a separate STUN server discovered in the domain of registered SIP AOR, in order to detect NAT reboots=20 Yes it will add overhead (not good for an ultimate solution) but can you point out any other profound flaw with this=20 approach ? E.g. SIP server and STUN server located in=20 different address spaces so that the NAT reboot detection would possibly not work etc. ? Regards, Erkki >-----Original Message----- >From: ext Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 >Sent: 20.February.2006 11:53 >To: Gary Gan >Cc: 'Cullen Jennings'; sip@ietf.org; 'Francois Audet';=20 >fwmiller@cornfed.com; 'Dean Willis' >Subject: Re: [Sip] Outbound and STUN Keep Alive > > >On Feb 17, 2006, at 3:09 AM, Gary Gan wrote: > >> Are we overkilling this issue by inventing a new keep-alive=20 >mechanism=20 >> that >> could potentially overload the server by 90% more, just to resolve a >> down-time situation, which can be automatically recovered anyway but=20 >> just >> delayed for a few minutes? But I have to agree that some UA=20 >> implementation >> defaults the SIP REGISTER expiry time to 1 hour, in which case the=20 >> problem >> would be more severe. >> >> So the problem becomes the UA polling for the healthy of the server, >> probably the healthy of the logical UDP binding. To let the server=20 >> echo the >> simple keep-alive, such as CRLF, probably is enough for this=20 >issue. It >> doesn't introduce too much overhead to the server and network. >> Theoretically, the echo back CRLF can get lost, but it can=20 >be handled=20 >> in the >> UA side by retransmitting the keep-alive polling when it can=20 >not find=20 >> the >> response. If it fails a few times, the UA can declare the=20 >server down,=20 >> out >> of service. > >Forget about the CRLF for UDP as well. It does not have the feature=20 >that solves the rebooting NAT problem. > >Hisham > >> >> By introducing the multiplexing of STUN server with SIP=20 >server for the >> purpose of keep-alive, I don't see obvious more benefits=20 >than a simple >> PING/PONG mechanism. I agree to use STUN, ICE on the side to=20 >solve the >> firewall traversal. But it would be only per restart of UA=20 >or per call >> basis. Not constant polling even when it is idle. >> >> Some IP service provider may change the NAT IP address on the daily=20 >> basis, >> but I don't believe it would change it when there is a keep-alive=20 >> message >> going on in a period of like 15 seconds, even though the message is=20 >> short. >> >> Gary Gan >> Sr. Software Developer >> >> Clique Communications, LLC >> 205 Rockingham Row >> Princeton Forrestal Village >> Princeton, NJ 08540 >> Phone: 609-564-0206 >> >> >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Thursday, February 16, 2006 5:20 PM >> To: Gary Gan >> Cc: 'Francois Audet'; 'Cullen Jennings'; sip@ietf.org;=20 >> fwmiller@cornfed.com >> Subject: Re: [Sip] Outbound and STUN Keep Alive >> >> On Feb 16, 2006, at 3:23 PM, Gary Gan wrote: >>> The only problem I can think of is that the UA doesn't know if the >>> server is >>> down between now and the next SIP REGISTER is sent. >> >> Right, that's exactly the problem we're trying to solve. Keeping the >> NAT alive is only half the problem -- knowing when it has died and we >> need to renegotiate is the other half. >> >> Sure, we could REGISTER every 15 seconds, but I'm POSITIVE that's >> going to slow things down . . . >> >> -- >> 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 > _______________________________________________ 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 sip-bounces@ietf.org Wed Feb 22 02:38:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBoY1-0007jE-MO; Wed, 22 Feb 2006 02:36:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBoXz-0007j5-Ux for sip@ietf.org; Wed, 22 Feb 2006 02:36:27 -0500 Received: from lhrga01-in.huawei.com ([57.66.76.5] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBoXv-0004jP-LY for sip@ietf.org; Wed, 22 Feb 2006 02:36:27 -0500 Received: from huawei.com ([172.24.2.9]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV200BOYUGK35@lhrga01-in.huawei.com> for sip@ietf.org; Wed, 22 Feb 2006 07:07:33 +0000 (GMT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV200AWYVHR7P@szxga03-in.huawei.com> for sip@ietf.org; Wed, 22 Feb 2006 15:29:51 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV200M4AVHRID@szxga03-in.huawei.com> for sip@ietf.org; Wed, 22 Feb 2006 15:29:51 +0800 (CST) Received: from w39649a ([10.76.176.178]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IV200HR7VWNRG@szxml01-in.huawei.com> for sip@ietf.org; Wed, 22 Feb 2006 15:38:50 +0800 (CST) Date: Wed, 22 Feb 2006 15:22:46 +0800 From: Xiao Wang To: sip@ietf.org Message-id: <016101c63780$c74160d0$b2b04c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcY3gMcPhxVUbCaiS5eSJVp9Mw1CXQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Sip] A problem of refresh SUBSCRIBE request between servers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, all In some cases, there may exist a lot of subscriptions between servers. In other words, a server act as subscriber to subscribe resource from another server which act as notifier, and the subscriber can build a lot of subscriptions with the notifier. My question is a lot of subscriptions between servers can bring a lot of refresh SUBSCRIBE request for each subscription, I think the mechanism of refresh subscription of RFC3265 is low efficiency in this case. Is my view right? Xiao _______________________________________________ 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 sip-bounces@ietf.org Wed Feb 22 03:26:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBpI8-00021y-U2; Wed, 22 Feb 2006 03:24:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBpI6-00021p-Sy for sip@ietf.org; Wed, 22 Feb 2006 03:24:06 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBpI5-0006wv-LU for sip@ietf.org; Wed, 22 Feb 2006 03:24:06 -0500 Received: from huawei.com ([172.24.2.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV200JS8WJOZB@usaga01-in.huawei.com> for sip@ietf.org; Tue, 21 Feb 2006 23:52:36 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV2008H1X9VDO@szxga02-in.huawei.com> for sip@ietf.org; Wed, 22 Feb 2006 16:08:19 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV200LFAX9UMN@szxga02-in.huawei.com> for sip@ietf.org; Wed, 22 Feb 2006 16:08:19 +0800 (CST) Received: from w39649a ([10.76.176.178]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IV200K7LX9LDG@szxml02-in.huawei.com> for sip@ietf.org; Wed, 22 Feb 2006 16:08:12 +0800 (CST) Date: Wed, 22 Feb 2006 15:55:43 +0800 From: Xiao Wang To: sip@ietf.org Message-id: <000201c63785$61c953c0$b2b04c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcY3hWGzIHucT8wzRT2qz3daGf56/w== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Sip] A problem of refresh SUBSCRIBE request between servers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, all In some cases, there may exist a lot of subscriptions between servers. In other words, a server act as subscriber to subscribe resource from another server which act as notifier, and the subscriber can build a lot of subscriptions with the notifier. My question is a lot of subscriptions between servers can bring a lot of refresh SUBSCRIBE request for each subscription, I think the mechanism of refresh subscription of RFC3265 is low efficiency in this case. Is my view right? Xiao _______________________________________________ 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 sip-bounces@ietf.org Wed Feb 22 07:06:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBsjS-0006WE-Ah; Wed, 22 Feb 2006 07:04:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBsjQ-0006W6-L4 for sip@ietf.org; Wed, 22 Feb 2006 07:04:32 -0500 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBsjP-0006mI-9X for sip@ietf.org; Wed, 22 Feb 2006 07:04:32 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id k1MCOV0x006101 for ; Wed, 22 Feb 2006 05:24:31 -0700 (MST) Received: from ZMY16EXF63.ds.mot.com (zmy16exf63.ap.mot.com [10.179.4.22]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k1MCFqaP016097 for ; Wed, 22 Feb 2006 06:15:53 -0600 (CST) Received: from motorola.com ([10.232.117.39]) by ZMY16EXF63.ds.mot.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Feb 2006 20:04:27 +0800 Message-ID: <43FC546B.9030501@motorola.com> Date: Wed, 22 Feb 2006 17:39:15 +0530 From: Priti User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: sip@ietf.org References: <200602211343.k1LDhZn18587@smapp01.siteprotect.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Feb 2006 12:04:27.0545 (UTC) FILETIME=[21114090:01C637A8] X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.5 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Sip] Certification cources X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi All, Please let me know what are the certifications can be done on Telecom (i.g. Certification on SIP etc). Ald also how to apply for the same if anybody has the idea. Thanks, Priti _______________________________________________ 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 sip-bounces@ietf.org Wed Feb 22 11:40:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBx10-0005by-SO; Wed, 22 Feb 2006 11:38:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBx0z-0005bq-1e for sip@ietf.org; Wed, 22 Feb 2006 11:38:57 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBx0y-0003FY-PK for sip@ietf.org; Wed, 22 Feb 2006 11:38:57 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 22 Feb 2006 08:38:56 -0800 X-IronPort-AV: i="4.02,137,1139212800"; d="scan'208"; a="1778699231:sNHT34403640" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k1MGcqub014586; Wed, 22 Feb 2006 08:38:53 -0800 (PST) Received: from 10.21.114.255 ([10.21.114.255]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Wed, 22 Feb 2006 16:38:51 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 22 Feb 2006 08:39:14 -0800 Subject: Re: [Sip] Outbound and STUN Keep Alive From: Cullen Jennings To: Michael Procter , John Elwell , Chris Boulton , Gary Gan , Dean Willis , Francois Audet Message-ID: Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcY1o/5bPMNWf6GXEdqJWQARJEEJ/AAV+lvwAHSm/m0= In-Reply-To: <592CA2F7E2BFBD4088AC87ECFF34BECE2D6CD7@not01-mxc01.citel.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: "sip@ietf.org" , fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 2/20/06 1:06 AM, "Michael Procter" wrote: > Cullen Jennings wrote: >> Agree with John. >> >> I've been trying to think about the details of the double >> CRLF. It's hard to >> construct and exact case (that does not involve buggy >> software) that would >> results in double CRLF with no transaction identifier getting >> messed up due >> to lack of transaction identifier. I can't decide if the lack >> of transaction >> id is a real problem or a theoretical one. > > What about a compromise? Use double CRLFs. If there is any doubt > about the response (either no response within expected timeframe, > or unexpected response etc.), then generate an OPTIONS. > > This means that almost all keepalive traffic uses the lightweight > double CRLF approach, but that in the event of a network anomaly, > a normal SIP method (no new methods required) can be used to > confirm the path. If by some chance, a rogue double CRLF was > dropped or inserted into the stream, this normal method would also > flush it out, returning the stream to a known state. > > This seems to combine the best of both worlds - a lightweight > approach for normal use, and a more robust system when you need it. > > Regards, > > Michael Procter That's and interesting idea. I think the problem I was concerned with was not CRLF failing when the the connection was good but having CRLF succeed when the connection was bad. I can't decide if this really is a problem or not. It's hard to think of a practical example where the connection would be bad yet the UA would continue to get CRLF that were queued up in the connection. _______________________________________________ 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 sip-bounces@ietf.org Wed Feb 22 11:47:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBx7p-0006hH-0A; Wed, 22 Feb 2006 11:46:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBx7n-0006gx-AV for sip@ietf.org; Wed, 22 Feb 2006 11:45:59 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBx7m-0003VJ-1p for sip@ietf.org; Wed, 22 Feb 2006 11:45:59 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 22 Feb 2006 08:45:58 -0800 X-IronPort-AV: i="4.02,137,1139212800"; d="scan'208"; a="1778701753:sNHT63540348" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k1MGjsZC009288; Wed, 22 Feb 2006 08:45:55 -0800 (PST) Received: from 10.21.114.255 ([10.21.114.255]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Wed, 22 Feb 2006 16:45:54 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 22 Feb 2006 08:46:16 -0800 Subject: Re: [Sip] Outbound and STUN Keep Alive From: Cullen Jennings To: , Hisham Khartabil , Message-ID: Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcY2BST5ychGJsR7SJ+gQTmsc9kfBgBeOzKwABRbYoI= In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F01FE7E96@esebe103.NOE.Nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: "sip@ietf.org" , Francois Audet , fwmiller@cornfed.com, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 2/21/06 11:23 PM, "Erkki.Koivusalo@nokia.com" wrote: > Hi ! > >> Forget about the CRLF for UDP as well. It does not have >> the feature that solves the rebooting NAT problem. > > What about the following approach (at least as a short > term solution while the ultimate solution will not yet > be defined or supported by the deployed servers): > > - Send CRLF to SIP proxy for NAT binding keepalve > > - Simultaneously send STUN binding requests to a separate > STUN server discovered in the domain of registered SIP > AOR, in order to detect NAT reboots > > Yes it will add overhead (not good for an ultimate solution) > but can you point out any other profound flaw with this > approach ? E.g. SIP server and STUN server located in > different address spaces so that the NAT reboot detection > would possibly not work etc. ? > > Regards, > > Erkki Say you have two SIP clients A and B that use the same default port behind the same NAT and that NAT does port preservation (this is fairly common). Then the NAT reboots. Without loss of generality, assume A had got the preserved port and B had not. Each UA has sends a stun packet that create a new binding. If A sends first, it will get the same binding it had last time and it will not detect that the NAT had rebooted. However, it binding for SIP may or may not be the same as before the NAT rebooted and it may not work. In this case, it seems like about 50% of the time, one of two clients will think things are OK when in fact they are not. _______________________________________________ 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 sip-bounces@ietf.org Wed Feb 22 12:06:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBxPV-0001Vv-SH; Wed, 22 Feb 2006 12:04:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBxPU-0001Vh-EU for sip@ietf.org; Wed, 22 Feb 2006 12:04:16 -0500 Received: from firewall.objectworld.com ([72.1.207.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBxPU-0004Fj-4A for sip@ietf.org; Wed, 22 Feb 2006 12:04:16 -0500 Received: from photon.objectworld.com (photon.objectworld.com [192.168.1.2]) by firewall.objectworld.com (8.12.11/8.12.11) with ESMTP id k1MH4E8B007847 for ; Wed, 22 Feb 2006 12:04:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Wed, 22 Feb 2006 12:04:14 -0500 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C5062FE9@photon.objectworld.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcY2BST5ychGJsR7SJ+gQTmsc9kfBgBeOzKwABRbYoIAAIld0A== From: "Michael Slavitch" To: "Cullen Jennings" X-Spam-Score: 0.00 () [Tag at 15.00] X-CanItPRO-Stream: outgoing Content-Disposition: inline X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.1.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org We've seen this in our testing on commodity NAT equipment.=20=0A= =0A= It isn't theoretical. This is a regular occurrence and will happen with=0A= current devices in the field.=20=0A= =20=0A= =20=0A= It is amazing what you can accomplish if you do not care who gets the=0A= credit.=20=0A= =20=0A= - Harry S Truman=0A= =0A= -----Original Message-----=0A= From: Cullen Jennings [mailto:fluffy@cisco.com]=20=0A= Sent: February 22, 2006 11:46 AM=0A= To: Erkki.Koivusalo@nokia.com; Hisham Khartabil; ggan@cliquecom.com=0A= Cc: sip@ietf.org; Francois Audet; fwmiller@cornfed.com; Dean Willis=0A= Subject: Re: [Sip] Outbound and STUN Keep Alive=0A= =0A= On 2/21/06 11:23 PM, "Erkki.Koivusalo@nokia.com"=0A= =0A= wrote:=0A= =0A= > Hi !=20=0A= >=20=0A= >> Forget about the CRLF for UDP as well. It does not have the feature=20= =0A= >> that solves the rebooting NAT problem.=0A= >=20=0A= > What about the following approach (at least as a short term solution=20= =0A= > while the ultimate solution will not yet be defined or supported by=20=0A= > the deployed servers):=0A= >=20=0A= > - Send CRLF to SIP proxy for NAT binding keepalve=0A= >=20=0A= > - Simultaneously send STUN binding requests to a separate=0A= > STUN server discovered in the domain of registered SIP=0A= > AOR, in order to detect NAT reboots=0A= >=20=0A= > Yes it will add overhead (not good for an ultimate solution) but can=20= =0A= > you point out any other profound flaw with this approach ? E.g. SIP=20=0A= > server and STUN server located in different address spaces so that the=0A= =0A= > NAT reboot detection would possibly not work etc. ?=0A= >=20=0A= > Regards,=0A= >=20=0A= > Erkki=0A= =0A= Say you have two SIP clients A and B that use the same default port=0A= behind the same NAT and that NAT does port preservation (this is fairly=0A= common).=0A= Then the NAT reboots. Without loss of generality, assume A had got the=0A= preserved port and B had not. Each UA has sends a stun packet that=0A= create a new binding. If A sends first, it will get the same binding it=0A= had last time and it will not detect that the NAT had rebooted. However,=0A= it binding for SIP may or may not be the same as before the NAT rebooted=0A= and it may not work. In this case, it seems like about 50% of the time,=0A= one of two clients will think things are OK when in fact they are not.=0A= =0A= =0A= _______________________________________________=0A= Sip mailing list https://www1.ietf.org/mailman/listinfo/sip=0A= This list is for NEW development of the core SIP Protocol Use=0A= sip-implementors@cs.columbia.edu for questions on current sip Use=0A= sipping@ietf.org for new developments on the application of sip=0A= =0A= =0A= --=0A= =0A= =0A= -----------------------------------------------=0D=0A= =0D=0A= This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. =0D=0A= =0D=0A= Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp= .=20=0A= _______________________________________________ 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 sip-bounces@ietf.org Wed Feb 22 13:56:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBz8N-0007oE-PF; Wed, 22 Feb 2006 13:54:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBz8M-0007o6-9r for sip@ietf.org; Wed, 22 Feb 2006 13:54:42 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBz8K-0000iI-Va for sip@ietf.org; Wed, 22 Feb 2006 13:54:42 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1MIsRvW012980 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 22 Feb 2006 12:54:30 -0600 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <61CC99A0-15A8-4C93-8595-C69A88997776@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Wed, 22 Feb 2006 12:54:23 -0600 To: Cullen Jennings X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: "sip@ietf.org" , Francois Audet , Chris Boulton , Michael Procter , John Elwell , fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Feb 22, 2006, at 10:39 AM, Cullen Jennings wrote: > > That's and interesting idea. I think the problem I was concerned > with was > not CRLF failing when the the connection was good but having CRLF > succeed > when the connection was bad. I can't decide if this really is a > problem or > not. It's hard to think of a practical example where the connection > would be > bad yet the UA would continue to get CRLF that were queued up in the > connection. > Ambient echoes of CRLF are a different problem from NAT reset detection. Let's say that a NAT reboots, and you're suddenly sending CRLF through a new binding. Your old Contact won't work anymore. But the CRLF is getting passed to the server just fine via the new binding. Does the server that you're sending CRLF to just continue to echo CRLF back at you? Or does it have some way of recognizing that it's suddenly getting CRLF echo requests from a partner from which it has no current registration and stop echoing CRLF at you? -- 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 sip-bounces@ietf.org Wed Feb 22 14:04:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBzFX-0008Nq-9u; Wed, 22 Feb 2006 14:02:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBzFV-0008NJ-7i for sip@ietf.org; Wed, 22 Feb 2006 14:02:05 -0500 Received: from web34707.mail.mud.yahoo.com ([209.191.68.156]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FBzFU-0000yt-Ml for sip@ietf.org; Wed, 22 Feb 2006 14:02:05 -0500 Received: (qmail 90021 invoked by uid 60001); 22 Feb 2006 19:02:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=F1RS2/UbVgTomlsP52q3WJY1Peicxc1rUyHwnBmL4z9nhDl0LezZCr2Svu11X5PyzVJgtPi/audz7rjYzheKJ5b/n/spMVA5rNTNE9DQnpjEHe2eN/RHoGfPvkETWHhGZmJjRmMpbp38fF8m+ZdEYDzBh7FkO7T+DTAN8T4YtVM= ; Message-ID: <20060222190204.90019.qmail@web34707.mail.mud.yahoo.com> Received: from [134.56.105.33] by web34707.mail.mud.yahoo.com via HTTP; Wed, 22 Feb 2006 11:02:04 PST Date: Wed, 22 Feb 2006 11:02:04 -0800 (PST) From: Manish Joshi Subject: Re: [Sip] A problem of refresh SUBSCRIBE request between servers To: Xiao Wang , sip@ietf.org In-Reply-To: <000201c63785$61c953c0$b2b04c0a@china.huawei.com> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0295011965==" Errors-To: sip-bounces@ietf.org --===============0295011965== Content-Type: multipart/alternative; boundary="0-1466288343-1140634924=:87654" Content-Transfer-Encoding: 8bit --0-1466288343-1140634924=:87654 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Xiao, I havent tried it but a glance at RFC 3265 suggested that ID parameter in event header in Subscribe request can be used to have multiple subcription and refreshes in the same dialog. From RFC 3265 section "A SUBSCRIBE request MAY include an "id" parameter in its "Event" header to allow differentiation between multiple subscriptions in the same dialog." Thanks, Manish Xiao Wang wrote: Hi, all In some cases, there may exist a lot of subscriptions between servers. In other words, a server act as subscriber to subscribe resource from another server which act as notifier, and the subscriber can build a lot of subscriptions with the notifier. My question is a lot of subscriptions between servers can bring a lot of refresh SUBSCRIBE request for each subscription, I think the mechanism of refresh subscription of RFC3265 is low efficiency in this case. Is my view right? Xiao _______________________________________________ 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 --------------------------------- Yahoo! Autos. Looking for a sweet ride? Get pricing, reviews, & more on new and used cars. --0-1466288343-1140634924=:87654 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi Xiao,
 
I havent tried it but a glance at RFC 3265 suggested that ID parameter in event header in Subscribe request can be used to have multiple subcription and refreshes in the same dialog.
 
From RFC 3265 section
"A SUBSCRIBE request MAY include an "id" parameter in its "Event"
header to allow differentiation between multiple subscriptions in the
same dialog."
 
Thanks,
Manish


Xiao Wang <wangsmile@huawei.com> wrote:
Hi, all
In some cases, there may exist a lot of subscriptions between servers. In
other words, a server act as subscriber to subscribe resource from another
server which act as notifier, and the subscriber can build a lot of
subscriptions with the notifier.
My question is a lot of subscriptions between servers can bring a lot of
refresh SUBSCRIBE request for each subscription, I think the mechanism of
refresh subscription of RFC3265 is low efficiency in this case. Is my view
right?

Xiao



_______________________________________________
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

Yahoo! Autos. Looking for a sweet ride? Get pricing, reviews, & more on new and used cars. --0-1466288343-1140634924=:87654-- --===============0295011965== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0295011965==-- From sip-bounces@ietf.org Wed Feb 22 14:15:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBzQz-0000wX-3M; Wed, 22 Feb 2006 14:13:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBzQx-0000w8-NF; Wed, 22 Feb 2006 14:13:55 -0500 Received: from [156.154.16.129] (helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBzQx-0001Sg-DI; Wed, 22 Feb 2006 14:13:55 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k1MJDn0e013681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Feb 2006 19:13:50 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FBzQr-0003n1-QW; Wed, 22 Feb 2006 14:13:49 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Wed, 22 Feb 2006 14:13:49 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: sip mailing list , sip chair , Internet Architecture Board , sip chair , RFC Editor Subject: [Sip] Protocol Action: 'Suppression of Session Initiation Protocol REFER Method Implicit Subscription' to Proposed Standard X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The IESG has approved the following document: - 'Suppression of Session Initiation Protocol REFER Method Implicit Subscription ' as a Proposed Standard This document is the product of the Session Initiation Protocol Working Group. The IESG contact person is Allison Mankin. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-with-norefersub-04.txt Technical Summary The SIP REFER extension as defined in RFC 3515 automatically establishes a short-lived event subscription used to notify the party sending the REFER request about the execution of that request. This notification is not needed in all cases. This specification provides a way to prevent this subscription/notification sequence, using a new SIP extension header field which may be included in a REFER request. A new sip option tag is also defined to provide for declaration and discovery of support for this extension. Working Group Summary This specification was produced by the SIP working group in response to requirements forwarded by the SIPPING working group and based in part on requirements submitted by external organizations including the Open Mobile Alliance. The draft iterated several times as an individual draft before being adopted by the working group and added to the charter. Working group discussion centered on one key issue: What sort of SIP extension mechanism, including URI, header field, body part, or request type should be used to meet the requirements? A breakout session during IETF 63 resulted in the compromise documented in this specification, and subsequent working group review revealed a very high level of consensus for the direction selected. Several minor items, primarily typographical, were corrected during an extended working group last call. Protocol Quality There no implementations of this extension known to the WG Chairs at the time of publication request. However, we expect to see the extension broadly used in mobile phones implementing the Open Mobile Alliance's specification for Push to Talk Over Cellular. Dean Willis is the WG Chair shepherd. Allison Mankin is the Responsible Area Director. Notes to RFC Editor [replace the present abstract] Abstract OLD: This specification defines a way to suppress an implicit subscription with the Session Initiation Protocol (SIP) REFER method. A new SIP option tag "norefersub" is defined to indicate support for this extension. A new SIP header field "Refer-Sub" is defined to request the usage of this extension. NEW: The SIP REFER extension as defined in RFC 3515 automatically establishes a short-lived event subscription used to notify the party sending the REFER request about the execution of that request. This notification is not needed in all cases. This specification provides a way to prevent this subscription/notification sequence, using a new SIP extension header field which may be included in a REFER request. A new sip option tag is also defined to provide for declaration and discovery of support for this extension. ------ Please expand the first use of User Agent (UA) and URI (Uniform Resource Identifier) ------ Section 7 IANA Considerations OLD: The following information to be added to the header field sub-registry under http://www.iana.org/assignments/sip-parameters: NEW: The following information is added to the SIP Header field sub-registry in the SIP Parameters Registry. OLD: This document also registers a new SIP option tag, "norefersub". NEW: This document also registers a new SIP option tag, "norefersub" adding it to the SIP Option Tags sub-registry in the SIP Parameters Registry. ------ Note to IANA IANA - please note that the edits above are not new instruction, but clearer information on where the registry objects go. _______________________________________________ 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 sip-bounces@ietf.org Wed Feb 22 14:26:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBzbU-0003Nn-SU; Wed, 22 Feb 2006 14:24:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBzbT-0003Na-NG for sip@ietf.org; Wed, 22 Feb 2006 14:24:47 -0500 Received: from [66.155.254.250] (helo=isdmail1.inovsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBzbS-00020N-GD for sip@ietf.org; Wed, 22 Feb 2006 14:24:47 -0500 Received: from greatwall ([12.181.128.3]) by isdmail1.inovsys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 22 Feb 2006 14:24:45 -0500 From: "Gary Gan" To: "'Dean Willis'" , "'Cullen Jennings'" Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Wed, 22 Feb 2006 14:24:47 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <61CC99A0-15A8-4C93-8595-C69A88997776@softarmor.com> thread-index: AcY34W4KIl4BcxGqSvWlqo9beVEPmgAAt1Gg Message-ID: X-OriginalArrivalTime: 22 Feb 2006 19:24:46.0010 (UTC) FILETIME=[A3B319A0:01C637E5] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: sip@ietf.org, 'Francois Audet' , 'Chris Boulton' , 'Michael Procter' , fwmiller@cornfed.com, 'John Elwell' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >Does the server that you're sending CRLF to just continue to echo >CRLF back at you? Or does it have some way of recognizing that it's >suddenly getting CRLF echo requests from a partner from which it has >no current registration and stop echoing CRLF at you? >-- >Dean Depending on the server implementation, but either way has problems. If the echo comes back from the new binding, the UA would not know the NAT has rebooted. That's what the STUN multiplexing tries to resolve, which actually handles the binding comparison on the client side. If the server checks for the client bindings, then the server needs to maintain the binding states of all UA, either in memory or database. It uses server resource. I don't think it scales. Gary Gan Clique Communications _______________________________________________ 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 sip-bounces@ietf.org Wed Feb 22 14:39:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBzo3-0004ra-Jz; Wed, 22 Feb 2006 14:37:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBzo2-0004rM-OP for sip@ietf.org; Wed, 22 Feb 2006 14:37:46 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBzo2-0002hN-Dw for sip@ietf.org; Wed, 22 Feb 2006 14:37:46 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 22 Feb 2006 11:37:46 -0800 X-IronPort-AV: i="4.02,137,1139212800"; d="scan'208"; a="408735857:sNHT37889442" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1MJbLgN005655; Wed, 22 Feb 2006 11:37:43 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Feb 2006 11:37:33 -0800 Received: from [10.21.99.23] ([10.21.99.23]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Feb 2006 11:37:33 -0800 Message-ID: <43FCBD79.7080208@cisco.com> Date: Wed, 22 Feb 2006 14:37:29 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manish Joshi Subject: Re: [Sip] A problem of refresh SUBSCRIBE request between servers References: <20060222190204.90019.qmail@web34707.mail.mud.yahoo.com> In-Reply-To: <20060222190204.90019.qmail@web34707.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Feb 2006 19:37:33.0123 (UTC) FILETIME=[6CEF4130:01C637E7] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org While you can have a bunch of subscriptions share the same dialog, that doesn't eliminate the need to refresh each of them. It is the usage that expires, not the dialog. Paul Manish Joshi wrote: > Hi Xiao, > > I havent tried it but a glance at RFC 3265 suggested that ID parameter > in event header in Subscribe request can be used to have multiple > subcription and refreshes in the same dialog. > > From RFC 3265 section > "A SUBSCRIBE request MAY include an "id" parameter in its "Event" > header to allow differentiation between multiple subscriptions in the > same dialog." > > Thanks, > Manish > > > */Xiao Wang /* wrote: > > Hi, all > In some cases, there may exist a lot of subscriptions between > servers. In > other words, a server act as subscriber to subscribe resource from > another > server which act as notifier, and the subscriber can build a lot of > subscriptions with the notifier. > My question is a lot of subscriptions between servers can bring a lot of > refresh SUBSCRIBE request for each subscription, I think the > mechanism of > refresh subscription of RFC3265 is low efficiency in this case. Is > my view > right? > > Xiao > > > > _______________________________________________ > 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 > > > ------------------------------------------------------------------------ > Yahoo! Autos ylc=X3oDMTEzcGlrdGY5BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDMWF1dG9z/*http://autos.yahoo.com/index.html > >. Looking for a sweet ride? Get pricing, reviews, & more on new and > used cars. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 sip-bounces@ietf.org Wed Feb 22 15:07:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC0F4-0007CC-KS; Wed, 22 Feb 2006 15:05:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC0F3-0007Bs-1i for sip@ietf.org; Wed, 22 Feb 2006 15:05:41 -0500 Received: from [66.155.254.250] (helo=isdmail1.inovsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC0F2-0003oO-Px for sip@ietf.org; Wed, 22 Feb 2006 15:05:41 -0500 Received: from greatwall ([12.181.128.3]) by isdmail1.inovsys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 22 Feb 2006 15:05:40 -0500 From: "Gary Gan" To: "'Gary Gan'" , "'Dean Willis'" , "'Cullen Jennings'" Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Wed, 22 Feb 2006 15:05:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: thread-index: AcY34W4KIl4BcxGqSvWlqo9beVEPmgAAt1GgAAF1ymA= Message-ID: X-OriginalArrivalTime: 22 Feb 2006 20:05:40.0354 (UTC) FILETIME=[5A9A4620:01C637EB] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org [UA] ---> [Outbound Proxy] -->|N| -->[SIP Registrar server$B!!!!!!(B] | |A| | +$B!!!!!!!!!!!!!!!!!!!!!!!!(B| |------------STUN?--------->[T| -->[Multiplexed STUN server$B!!(B] I just wonder how the STUN solution works with the above scenario. With the outbound proxy in the different IP behind the NAT, the STUN keep-alive would not be valid since the NAT binding is between the outbound proxy and the SIP server. Gary Gan Clique Communications, LLC -----Original Message----- From: Gary Gan [mailto:ggan@cliquecom.com] Sent: Wednesday, February 22, 2006 2:25 PM To: 'Dean Willis'; 'Cullen Jennings' Cc: sip@ietf.org; 'Francois Audet'; 'Chris Boulton'; 'Michael Procter'; fwmiller@cornfed.com; 'John Elwell' Subject: RE: [Sip] Outbound and STUN Keep Alive >Does the server that you're sending CRLF to just continue to echo >CRLF back at you? Or does it have some way of recognizing that it's >suddenly getting CRLF echo requests from a partner from which it has >no current registration and stop echoing CRLF at you? >-- >Dean Depending on the server implementation, but either way has problems. If the echo comes back from the new binding, the UA would not know the NAT has rebooted. That's what the STUN multiplexing tries to resolve, which actually handles the binding comparison on the client side. If the server checks for the client bindings, then the server needs to maintain the binding states of all UA, either in memory or database. It uses server resource. I don't think it scales. Gary Gan Clique Communications _______________________________________________ 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 sip-bounces@ietf.org Wed Feb 22 15:09:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC0H5-0007Oo-8B; Wed, 22 Feb 2006 15:07:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC0H4-0007Of-2J for sip@ietf.org; Wed, 22 Feb 2006 15:07:46 -0500 Received: from web34702.mail.mud.yahoo.com ([209.191.68.151]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FC0H3-0003wl-Jh for sip@ietf.org; Wed, 22 Feb 2006 15:07:46 -0500 Received: (qmail 51631 invoked by uid 60001); 22 Feb 2006 20:07:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=p5oeEdEDBzbn6XofTf2AfRwUpmL81mk5uxBa8D5cXTGcu1FuA+WDcjZ2yqm7xuMshCaTU7USzsQ6V7rXxeajgXHgNK/GlHgxGm/hg02OMwWflePUR/hpnrqCTIXnx3M5oie56gSYHz9suRbmI4yyy33avAYxN0WgNWuvlf8N/FY= ; Message-ID: <20060222200745.51629.qmail@web34702.mail.mud.yahoo.com> Received: from [134.56.105.33] by web34702.mail.mud.yahoo.com via HTTP; Wed, 22 Feb 2006 12:07:45 PST Date: Wed, 22 Feb 2006 12:07:45 -0800 (PST) From: Manish Joshi Subject: Re: [Sip] A problem of refresh SUBSCRIBE request between servers To: Paul Kyzivat In-Reply-To: <43FCBD79.7080208@cisco.com> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0393469044==" Errors-To: sip-bounces@ietf.org --===============0393469044== Content-Type: multipart/alternative; boundary="0-865695646-1140638865=:50973" Content-Transfer-Encoding: 8bit --0-865695646-1140638865=:50973 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Oh yes, off-course. We still need to 'refresh' each of them but guess we can do all the refreshes again in a single dialog with all "id"s in EVent Header same as IDs in initial Subscription requests. -Manish Paul Kyzivat wrote: While you can have a bunch of subscriptions share the same dialog, that doesn't eliminate the need to refresh each of them. It is the usage that expires, not the dialog. Paul Manish Joshi wrote: > Hi Xiao, > > I havent tried it but a glance at RFC 3265 suggested that ID parameter > in event header in Subscribe request can be used to have multiple > subcription and refreshes in the same dialog. > > From RFC 3265 section > "A SUBSCRIBE request MAY include an "id" parameter in its "Event" > header to allow differentiation between multiple subscriptions in the > same dialog." > > Thanks, > Manish > > > */Xiao Wang /* wrote: > > Hi, all > In some cases, there may exist a lot of subscriptions between > servers. In > other words, a server act as subscriber to subscribe resource from > another > server which act as notifier, and the subscriber can build a lot of > subscriptions with the notifier. > My question is a lot of subscriptions between servers can bring a lot of > refresh SUBSCRIBE request for each subscription, I think the > mechanism of > refresh subscription of RFC3265 is low efficiency in this case. Is > my view > right? > > Xiao > > > > _______________________________________________ > 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 > > > ------------------------------------------------------------------------ > Yahoo! Autos > ylc=X3oDMTEzcGlrdGY5BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDMWF1dG9z/*http://autos.yahoo.com/index.html > >. Looking for a sweet ride? Get pricing, reviews, & more on new and > used cars. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 --------------------------------- Yahoo! Autos. Looking for a sweet ride? Get pricing, reviews, & more on new and used cars. --0-865695646-1140638865=:50973 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Oh yes, off-course. We still need to 'refresh' each of them but guess
we can do all the refreshes again in a single dialog with all "id"s in EVent Header same as IDs in initial Subscription requests.
 
-Manish

Paul Kyzivat <pkyzivat@cisco.com> wrote:
While you can have a bunch of subscriptions share the same dialog, that
doesn't eliminate the need to refresh each of them. It is the usage that
expires, not the dialog.

Paul

Manish Joshi wrote:
> Hi Xiao,
>
> I havent tried it but a glance at RFC 3265 suggested that ID parameter
> in event header in Subscribe request can be used to have multiple
> subcription and refreshes in the same dialog.
>
> From RFC 3265 section
> "A SUBSCRIBE request MAY include an "id" parameter in its "Event"
> header to allow differentiation between multiple subscriptions in the
> same dialog."
>
> Thanks,
> Manish
>
>
> */Xiao Wang /* wrote:
>
> Hi, all
> In some cases, there may exist a lot of subscriptions between
> servers. In
> other words, a server act as subscriber to subscribe resource from
> another
> server which act as notifier, and the subscriber can build a lot of
> subscriptions with the notifier.
> My question is a lot of subscriptions between servers can bring a lot of
> refresh SUBSCRIBE request for each subscription, I think the
> mechanism of
> refresh subscription of RFC3265 is low efficiency in this case. Is
> my view
> right?
>
> Xiao
>
>
>
> _______________________________________________
> 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
>
>
> ------------------------------------------------------------------------
> Yahoo! Autos > ylc=X3oDMTEzcGlrdGY5BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDMWF1dG9z/*http://autos.yahoo.com/index.html
> >. Looking for a sweet ride? Get pricing, reviews, & more on new and
> used cars.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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

Yahoo! Autos. Looking for a sweet ride? Get pricing, reviews, & more on new and used cars. --0-865695646-1140638865=:50973-- --===============0393469044== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0393469044==-- From sip-bounces@ietf.org Wed Feb 22 15:24:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC0Vb-0000rI-N6; Wed, 22 Feb 2006 15:22:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC0VZ-0000r7-QX for sip@ietf.org; Wed, 22 Feb 2006 15:22:45 -0500 Received: from web34715.mail.mud.yahoo.com ([209.191.68.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FC0VZ-0004kp-BB for sip@ietf.org; Wed, 22 Feb 2006 15:22:45 -0500 Received: (qmail 88049 invoked by uid 60001); 22 Feb 2006 20:22:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lseQtzftBMi5IDHQlkwlw78lSSVtI7yKc9YVuCDg6yNuxFbclLvDYCEYEI5BddYZPRlPo6fJOZpJMatbr4WHR67iP2jKw3fN3TGxosYmF/19dd72tij0WvL4LaokUvL5SlU/m5mKZKbYsApb714RGVZkvRzZpJ4UCwq2gsSwQsw= ; Message-ID: <20060222202244.88047.qmail@web34715.mail.mud.yahoo.com> Received: from [134.56.105.33] by web34715.mail.mud.yahoo.com via HTTP; Wed, 22 Feb 2006 12:22:44 PST Date: Wed, 22 Feb 2006 12:22:44 -0800 (PST) From: Manish Joshi Subject: Re: [Sip] A problem of refresh SUBSCRIBE request between servers To: Manish Joshi , Paul Kyzivat In-Reply-To: <20060222200745.51629.qmail@web34702.mail.mud.yahoo.com> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0720077077==" Errors-To: sip-bounces@ietf.org --===============0720077077== Content-Type: multipart/alternative; boundary="0-800527751-1140639764=:87706" Content-Transfer-Encoding: 8bit --0-800527751-1140639764=:87706 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Ok I think I got little confused with the RFC. Guess RFC doesnt really suggests having multiple IDs in the same SUBSCRIBE Requests. It just suggests that with "id" parameter in a event header it can be avoided to have a new dialog for each Subscription. The number of Subscribe / 200 OK request/response flowing over the network remains same. Am I right in my understanding? Thanks, Manish Manish Joshi wrote: Oh yes, off-course. We still need to 'refresh' each of them but guess we can do all the refreshes again in a single dialog with all "id"s in EVent Header same as IDs in initial Subscription requests. -Manish Paul Kyzivat wrote: While you can have a bunch of subscriptions share the same dialog, that doesn't eliminate the need to refresh each of them. It is the usage that expires, not the dialog. Paul Manish Joshi wrote: > Hi Xiao, > > I havent tried it but a glance at RFC 3265 suggested that ID parameter > in event header in Subscribe request can be used to have multiple > subcription and refreshes in the same dialog. > > From RFC 3265 section > "A SUBSCRIBE request MAY include an "id" parameter in its "Event" > header to allow differentiation between multiple subscriptions in the > same dialog." > > Thanks, > Manish > > > */Xiao Wang /* wrote: > > Hi, all > In some cases, there may exist a lot of subscriptions between > servers. In > other words, a server act as subscriber to subscribe resource from > another > server which act as notifier, and the subscriber can build a lot of > subscriptions with the notifier. > My question is a lot of subscriptions between servers can bring a lot of > refresh SUBSCRIBE request for each subscription, I think the > mechanism of > refresh subscription of RFC3265 is low efficiency in this case. Is > my view > right? > > Xiao > > > > _______________________________________________ > 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 > > > ------------------------------------------------------------------------ > Yahoo! Autos > ylc=X3oDMTEzcGlrdGY5BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDMWF1dG9z/*http://autos.yahoo.com/index.html > >. Looking for a sweet ride? Get pricing, reviews, & more on new and > used cars. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 --------------------------------- Yahoo! Autos. Looking for a sweet ride? Get pricing, reviews, & more on new and used cars._______________________________________________ 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 --------------------------------- What are the most popular cars? Find out at Yahoo! Autos --0-800527751-1140639764=:87706 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Ok I think I got little confused with the RFC.
Guess RFC doesnt really suggests having multiple IDs in the same SUBSCRIBE Requests.
It just suggests that with "id" parameter in a event header it can be avoided to have a new dialog for each Subscription. The number of Subscribe / 200 OK request/response flowing over the network remains same.
Am I right in my understanding?
 
Thanks,
Manish
 
Manish Joshi <mjoshi_blr@yahoo.com> wrote:
Oh yes, off-course. We still need to 'refresh' each of them but guess
we can do all the refreshes again in a single dialog with all "id"s in EVent Header same as IDs in initial Subscription requests.
 
-Manish

Paul Kyzivat <pkyzivat@cisco.com> wrote:
While you can have a bunch of subscriptions share the same dialog, that
doesn't eliminate the need to refresh each of them. It is the usage that
expires, not the dialog.

Paul

Manish Joshi wrote:
> Hi Xiao,
>
> I havent tried it but a glance at RFC 3265 suggested that ID parameter
> in event header in Subscribe request can be used to have multiple
> subcription and refreshes in the same dialog.
>
> From RFC 3265 section
> "A SUBSCRIBE request MAY include an "id" parameter in its "Event"
> header to allow differentiation between multiple subscriptions in the
> same dialog."
>
> Thanks,
> Manish
>
>
> */Xiao Wang /* wrote:
>
> Hi, all
> In some cases, there may exist a lot of subscriptions between
> servers. In
> other words, a server act as subscriber to subscribe resource from
> another
> server which act as notifier, and the subscriber can build a lot of
> subscriptions with the notifier.
> My question is a lot of subscriptions between servers can bring a lot of
> refresh SUBSCRIBE request for each subscription, I think the
> mechanism of
> refresh subscription of RFC3265 is low efficiency in this case. Is
> my view
> right?
>
> Xiao
>
>
>
> _______________________________________________
> 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
>
>
> ------------------------------------------------------------------------
> Yahoo! Autos > ylc=X3oDMTEzcGlrdGY5BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDMWF1dG9z/*http://autos.yahoo.com/index.html
> >. Looking for a sweet ride? Get pricing, reviews, & more on new and
> used cars.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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

Yahoo! Autos. Looking for a sweet ride? Get pricing, reviews, & more on new and used cars._______________________________________________
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


What are the most popular cars? Find out at Yahoo! Autos --0-800527751-1140639764=:87706-- --===============0720077077== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0720077077==-- From sip-bounces@ietf.org Wed Feb 22 15:28:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC0Yy-0001LC-4y; Wed, 22 Feb 2006 15:26:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC0Yx-0001L3-8x for sip@ietf.org; Wed, 22 Feb 2006 15:26:15 -0500 Received: from firewall.objectworld.com ([72.1.207.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC0Yw-0004wm-VU for sip@ietf.org; Wed, 22 Feb 2006 15:26:15 -0500 Received: from photon.objectworld.com (photon.objectworld.com [192.168.1.2]) by firewall.objectworld.com (8.12.11/8.12.11) with ESMTP id k1MKPGUr020416 for ; Wed, 22 Feb 2006 15:26:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Wed, 22 Feb 2006 15:25:15 -0500 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C5062FEE@photon.objectworld.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcY34W4KIl4BcxGqSvWlqo9beVEPmgAAt1GgAAJjDDA= From: "Michael Slavitch" To: "Gary Gan" , "Dean Willis" , "Cullen Jennings" X-Spam-Score: 0.00 () [Tag at 15.00] X-CanItPRO-Stream: outgoing Content-Disposition: inline X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.1.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: sip@ietf.org, Francois Audet , Chris Boulton , Michael Procter , John Elwell , fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org It can in some instances be exploited in a DOS attack if the front end=0A= NAT is dumb enough to not recognize spoofing and maintains sticky=0A= bindings.=20=0A= =20=0A= =20=0A= It is amazing what you can accomplish if you do not care who gets the=0A= credit.=20=0A= =20=0A= - Harry S Truman=0A= =0A= -----Original Message-----=0A= From: Gary Gan [mailto:ggan@cliquecom.com]=20=0A= Sent: February 22, 2006 2:25 PM=0A= To: 'Dean Willis'; 'Cullen Jennings'=0A= Cc: sip@ietf.org; 'Francois Audet'; 'Chris Boulton'; 'Michael Procter';=0A= fwmiller@cornfed.com; 'John Elwell'=0A= Subject: RE: [Sip] Outbound and STUN Keep Alive=0A= =0A= >Does the server that you're sending CRLF to just continue to echo CRLF=20= =0A= >back at you? Or does it have some way of recognizing that it's suddenly=0A= =0A= >getting CRLF echo requests from a partner from which it has no current=20= =0A= >registration and stop echoing CRLF at you?=0A= =0A= >--=0A= >Dean=0A= =0A= Depending on the server implementation, but either way has problems. If=0A= the echo comes back from the new binding, the UA would not know the NAT=0A= has rebooted. That's what the STUN multiplexing tries to resolve, which=0A= actually handles the binding comparison on the client side. If the=0A= server checks for the client bindings, then the server needs to maintain=0A= the binding states of all UA, either in memory or database. It uses=0A= server resource. I don't think it scales.=0A= =0A= Gary Gan=0A= Clique Communications=0A= =0A= =0A= _______________________________________________=0A= Sip mailing list https://www1.ietf.org/mailman/listinfo/sip=0A= This list is for NEW development of the core SIP Protocol Use=0A= sip-implementors@cs.columbia.edu for questions on current sip Use=0A= sipping@ietf.org for new developments on the application of sip=0A= =0A= =0A= --=0A= =0A= =0A= -----------------------------------------------=0D=0A= =0D=0A= This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. =0D=0A= =0D=0A= Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp= .=20=0A= _______________________________________________ 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 sip-bounces@ietf.org Wed Feb 22 15:38:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC0iY-0002g3-Fq; Wed, 22 Feb 2006 15:36:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC0iX-0002fv-EO for sip@ietf.org; Wed, 22 Feb 2006 15:36:09 -0500 Received: from firewall.objectworld.com ([72.1.207.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC0iX-0005wm-1l for sip@ietf.org; Wed, 22 Feb 2006 15:36:09 -0500 Received: from photon.objectworld.com (photon.objectworld.com [192.168.1.2]) by firewall.objectworld.com (8.12.11/8.12.11) with ESMTP id k1MKZqL2020658 for ; Wed, 22 Feb 2006 15:36:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Wed, 22 Feb 2006 15:35:52 -0500 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C5062FEF@photon.objectworld.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcY34W4KIl4BcxGqSvWlqo9beVEPmgAAt1GgAAJjDDAAAF4NwA== From: "Michael Slavitch" To: "Michael Slavitch" , "Gary Gan" , "Dean Willis" , "Cullen Jennings" X-Spam-Score: 0.00 () [Tag at 15.00] X-CanItPRO-Stream: outgoing Content-Disposition: inline X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.1.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: sip@ietf.org, Francois Audet , Chris Boulton , Michael Procter , fwmiller@cornfed.com, John Elwell X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Overloading CRLF, that is.=0A= =0A= I do not know if there are any similar security considerations regarding=0A= STUN.=20=20=0A= =0A= M=0A= =0A= -----Original Message-----=0A= From: Michael Slavitch [mailto:slavitch@objectworld.com]=20=0A= Sent: February 22, 2006 3:25 PM=0A= To: Gary Gan; Dean Willis; Cullen Jennings=0A= Cc: sip@ietf.org; Francois Audet; Chris Boulton; Michael Procter; John=0A= Elwell; fwmiller@cornfed.com=0A= Subject: RE: [Sip] Outbound and STUN Keep Alive=0A= =0A= It can in some instances be exploited in a DOS attack if the front end=0A= NAT is dumb enough to not recognize spoofing and maintains sticky=0A= bindings.=20=0A= =20=0A= =20=0A= It is amazing what you can accomplish if you do not care who gets the=0A= credit.=20=0A= =20=0A= - Harry S Truman=0A= =0A= -----Original Message-----=0A= From: Gary Gan [mailto:ggan@cliquecom.com]=0A= Sent: February 22, 2006 2:25 PM=0A= To: 'Dean Willis'; 'Cullen Jennings'=0A= Cc: sip@ietf.org; 'Francois Audet'; 'Chris Boulton'; 'Michael Procter';=0A= fwmiller@cornfed.com; 'John Elwell'=0A= Subject: RE: [Sip] Outbound and STUN Keep Alive=0A= =0A= >Does the server that you're sending CRLF to just continue to echo CRLF=20= =0A= >back at you? Or does it have some way of recognizing that it's suddenly=0A= =0A= >getting CRLF echo requests from a partner from which it has no current=20= =0A= >registration and stop echoing CRLF at you?=0A= =0A= >--=0A= >Dean=0A= =0A= Depending on the server implementation, but either way has problems. If=0A= the echo comes back from the new binding, the UA would not know the NAT=0A= has rebooted. That's what the STUN multiplexing tries to resolve, which=0A= actually handles the binding comparison on the client side. If the=0A= server checks for the client bindings, then the server needs to maintain=0A= the binding states of all UA, either in memory or database. It uses=0A= server resource. I don't think it scales.=0A= =0A= Gary Gan=0A= Clique Communications=0A= =0A= =0A= _______________________________________________=0A= Sip mailing list https://www1.ietf.org/mailman/listinfo/sip=0A= This list is for NEW development of the core SIP Protocol Use=0A= sip-implementors@cs.columbia.edu for questions on current sip Use=0A= sipping@ietf.org for new developments on the application of sip=0A= =0A= =0A= --=0A= =0A= =0A= -----------------------------------------------=0A= =0A= This transmission (including any attachments) may contain confidential=0A= information, privileged material (including material protected by the=0A= solicitor-client or other applicable privileges), or constitute=0A= non-public information. Any use of this information by anyone other than=0A= the intended recipient is prohibited. If you have received this=0A= transmission in error, please immediately reply to the sender and delete=0A= this information from your system. Use, dissemination, distribution, or=0A= reproduction of this transmission by unintended recipients is not=0A= authorized and may be unlawful.=20=0A= =0A= Any views, opinions and content presented in this e-mail are solely=0A= those of the author and may not represent those of Objectworld=0A= Communications Corp.=20=0A= =0A= _______________________________________________=0A= Sip mailing list https://www1.ietf.org/mailman/listinfo/sip=0A= This list is for NEW development of the core SIP Protocol Use=0A= sip-implementors@cs.columbia.edu for questions on current sip Use=0A= sipping@ietf.org for new developments on the application of sip=0A= =0A= =0A= --=0A= =0A= =0A= -----------------------------------------------=0D=0A= =0D=0A= This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. =0D=0A= =0D=0A= Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp= .=20=0A= _______________________________________________ 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 sip-bounces@ietf.org Wed Feb 22 15:41:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC0lv-0003En-Ls; Wed, 22 Feb 2006 15:39:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC0lt-0003Ea-Or for sip@ietf.org; Wed, 22 Feb 2006 15:39:37 -0500 Received: from bay110-f21.bay110.hotmail.com ([65.54.229.31] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC0ls-0006GY-HL for sip@ietf.org; Wed, 22 Feb 2006 15:39:37 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 22 Feb 2006 12:39:35 -0800 Message-ID: Received: from 65.54.229.220 by by110fd.bay110.hotmail.msn.com with HTTP; Wed, 22 Feb 2006 20:39:34 GMT X-Originating-IP: [213.213.211.56] X-Originating-Email: [ameno6@hotmail.com] X-Sender: ameno6@hotmail.com From: =?iso-8859-1?B?QmVub+50IFdlcmlvbg==?= To: sip@ietf.org Bcc: Date: Wed, 22 Feb 2006 21:39:34 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed X-OriginalArrivalTime: 22 Feb 2006 20:39:35.0333 (UTC) FILETIME=[178B6D50:01C637F0] X-Spam-Score: 1.0 (+) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Sip] FTP implementation X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I would like to implement the FTP protocol on a SIP and RTP based program. i'm right now searching for a source code in C or in JAVA to add this functionnality and i wanted to know if you can give me some advices or good tips :) Thanks in advance _______________________________________________ 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 sip-bounces@ietf.org Wed Feb 22 16:21:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC1OX-0000dE-3n; Wed, 22 Feb 2006 16:19:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC1OW-0000cv-1S for sip@ietf.org; Wed, 22 Feb 2006 16:19:32 -0500 Received: from [66.155.254.250] (helo=isdmail1.inovsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC1OU-000385-QU for sip@ietf.org; Wed, 22 Feb 2006 16:19:32 -0500 Received: from greatwall ([12.181.128.3]) by isdmail1.inovsys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 22 Feb 2006 16:19:30 -0500 From: "Gary Gan" To: "'Dean Willis'" Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Wed, 22 Feb 2006 16:19:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <95768D15-ACAA-49D3-BDD2-B089109DE7F4@softarmor.com> thread-index: AcY383vJo75JsyvTQp22ojhIZw8K/QAAXq7A Message-ID: X-OriginalArrivalTime: 22 Feb 2006 21:19:30.0497 (UTC) FILETIME=[AB2C7310:01C637F5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: 'Cullen Jennings' , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org So, it is not a simple STUN protocol anymore. The outbound proxy needs to know how to forward the STUN request/response. It is more like the PING keepalive mechanism. But I like the light weight of the STUN. How do we combine these two? Gary Gan Clique Communications, LLC -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Wednesday, February 22, 2006 4:04 PM To: Gary Gan Cc: 'Cullen Jennings'; sip@ietf.org Subject: Re: [Sip] Outbound and STUN Keep Alive On Feb 22, 2006, at 2:05 PM, Gary Gan wrote: > [UA] ---> [Outbound Proxy] -->|N| -->[SIP Registrar server$B!!!!!!(B] > | |A| | +$B!!!!!!!!!!!!!!!!(B > $B!!!!!!!!(B| > |------------STUN?--------->[T| -->[Multiplexed STUN server$B!!(B] > > I just wonder how the STUN solution works with the above scenario. > With the > outbound proxy in the different IP behind the NAT, the STUN keep- > alive would > not be valid since the NAT binding is between the outbound proxy > and the SIP > server. > It doesn't. Or, it does, only if the outbound proxy is engaging in STUN keepalive to the registrar, and does state matching to know to drop the STUN channel to the UA (forcing a re-register) if the STUN channel to the registrar breaks. To do this, the UA would be using multiplexed STUN to the outbound proxy, not through the NAT to the registrar. -- 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 sip-bounces@ietf.org Wed Feb 22 17:34:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC2Wx-0001G5-5F; Wed, 22 Feb 2006 17:32:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC2Wg-000193-3N for sip@ietf.org; Wed, 22 Feb 2006 17:32:02 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC1UB-0003L2-Ba for sip@ietf.org; Wed, 22 Feb 2006 16:25:23 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FC19N-0004MB-Ac for sip@ietf.org; Wed, 22 Feb 2006 16:04:01 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1ML3wsl013558 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 22 Feb 2006 15:03:59 -0600 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Message-Id: <95768D15-ACAA-49D3-BDD2-B089109DE7F4@softarmor.com> Content-Transfer-Encoding: quoted-printable From: Dean Willis Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Wed, 22 Feb 2006 15:03:54 -0600 To: "Gary Gan" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: -2.6 (--) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: 'Cullen Jennings' , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Feb 22, 2006, at 2:05 PM, Gary Gan wrote: > [UA] ---> [Outbound Proxy] -->|N| -->[SIP Registrar server=E3=80=80=E3=80= =80=E3=80=80] > | |A| | +=E3=80=80=E3=80=80=E3=80=80=E3= =80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=20 > =E3=80=80=E3=80=80=E3=80=80=E3=80=80| > |------------STUN?--------->[T| -->[Multiplexed STUN server=E3=80=80] > > I just wonder how the STUN solution works with the above scenario. =20 > With the > outbound proxy in the different IP behind the NAT, the STUN keep-=20 > alive would > not be valid since the NAT binding is between the outbound proxy =20 > and the SIP > server. > It doesn't. Or, it does, only if the outbound proxy is engaging in STUN keepalive =20= to the registrar, and does state matching to know to drop the STUN =20 channel to the UA (forcing a re-register) if the STUN channel to the =20 registrar breaks. To do this, the UA would be using multiplexed STUN =20 to the outbound proxy, not through the NAT to the registrar. -- 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 sip-bounces@ietf.org Wed Feb 22 17:49:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC2lr-0003rc-DN; Wed, 22 Feb 2006 17:47:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC2lq-0003rR-7P for sip@ietf.org; Wed, 22 Feb 2006 17:47:42 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC2lo-00080G-Qh for sip@ietf.org; Wed, 22 Feb 2006 17:47:42 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k1MMlYP14387; Wed, 22 Feb 2006 17:47:34 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Outbound and STUN Keep Alive Date: Wed, 22 Feb 2006 16:47:10 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60A86FA5A@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcYyUrWBOUuGZXKwRU+B8fBGyAo0ugFnVY9Q From: "Samir Srivastava" To: "Jonathan Rosenberg" , "Pekka Pessi" X-Spam-Score: 0.1 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: Cullen Jennings , sip@ietf.org, fwmiller@cornfed.com, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Compression can help here, if enough CPU juice is available. Can we avoid both ways messages (REQ/RSP) flowing for the KEEP ALIVE. Client indicates to the server (With Require tags), that it expects the CRLF or keep alive message from the server. Server will send the keep alive messages to clients without expecting a response. When client doesn't see the keep=20 alive messages for configured interval, it assumes box in between rebooted or mapping is lost. It finds new mappings=20 and re-registers. This does reduce traffic by half, though it is against the normal REQ/RSP model of protocols here,=20 and it does require periodic activity at server with some state for keep alive. As we are changing server and clients both for this, why not get the most optimal stuff. For SIP based keep alive, How 15 seconds interval fit with retransmission timers of NON-INVITE transactions which retransmit at the max at the interval of 4 seconds till 32 seconds . Are we saying that we are changing this ? If the binding is gone, Detection will take between 32 seconds to 47 seconds without changing the existing state machines. Whether 47 seconds unreachable time period is okay ? Thx Samir =20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Wednesday, February 15, 2006 9:05 AM To: Pekka Pessi Cc: Cullen Jennings; sip@ietf.org; fwmiller@cornfed.com; Dean Willis Subject: Re: [Sip] Outbound and STUN Keep Alive The bandwidth aspect of this is important too. The STUN request in question here is 20 bytes, and the response is 36. A SIP OPTIONS request and response is probably around 300-400 bytes. At a rate of a keepalive every 15 seconds, you end up with 320 bps per subscriber for OPTIONS, and 3.8 bps for STUN (not counting IP/UDP overheads). Its interesting to compare this to 'useful' traffic. Assuming .1 erlangs and a hold time of 3m during the busy hour, you get 5.5e-4 calls per second per subscriber. With a INV/200/ACK BYE/200 sequence, and assuming 1kB for INV/200 and 300B for the others, thats 2.9 kB total per call, and thus 12.76 bps per subscriber. As a consequence, with the OPTIONS approach, you have a bandwidth overhead of 320/12.76 which is 25, or 2500%!!!! WIth STUN, this is a still painful but palatable 3.8/12.76 =3D 30%. To put that in perspective, a server supporting 100k subscribers would require 1.2 Mbps access for useful signaling, and an additional 32 Mbps just for the useless OPTIONS message. To make sure you are nowhere near (i.e. not within 50%) of link saturation, this comes close enough to the limit of 100M ethernet that you'd probably need to jump to GiGE, whereas 10M ethernet would suffice with STUN keepalives. -Jonathan R. Pekka Pessi wrote: > Dean Willis writes: >=20 >>vikram.agarwal@flextronicssoftware.com wrote: >> >>>will OPTIONS method not work for the same? Instead of sending an CRLF >>>we can also send an OPTIONS method to refresh the NAT binding. If i=20 >>>am not wrong then OPTIONS method was discared because of the=20 >>>processing of the SIP message for keeeping the NAT binding alive.=20 >>>Hence, CRLF was considered. But CRLF is not backward compatible i.e.=20 >>>it does not provide MAPPED ADDRESS. Now bringing in the PING method=20 >>>would again be introducing a SIP message based processing which would lead to poor performance. >=20 >=20 >>We've demonstrated successfully slaying proxies by bombing them with=20 >>OPTIONS requests. >=20 >=20 >>Back in the "early days" of dynamicsoft, our first proxies were=20 >>processing 7 INVITE/200/ACK/BYE/200 non-authenticated transaction=20 >>sequences or about 20 OPTIONS transactions per second. They've of=20 >>course gotten much faster, but the proportions have stayed pretty much the same. >=20 >=20 >>So you can see that in models where a typical SIP transaction load=20 >>might be >>5 transactions per hour per node, adding another 60 OPTIONS=20 >>transactions per hour per node might reduce your edge-proxy=20 >>scalability by on the order of 13-1, or roughly a 93% performance hit. That's a big hit. >=20 >=20 > Of course, that is the relative performance hit that you will see on a > 100 Mb/s ethernet, which I think is the bottleneck on most SIP=20 > servers. You do lot of OPTIONS, you use all you bandwidth receiving=20 > OPTIONS, right? ;-) >=20 > On more serious discussion, you use roughly the same number of packets > and system calls to process a STUN request as when processing OPTIONS, > The bottleneck is not in the CPU doing SIP or STUN parsing but=20 > (hopefully) somewhere else, like your memory bus or network I/O. Both=20 > SIP and STUN parser and processing code fit nicely in your cache=20 > nowadays, mixed STUN/SIP server losing because it has to fit both SIP=20 > and STUN parser code in its cache. >=20 > Of course, a hypothetical SIP server implemented in Perl and heavily=20 > relying in shell scripting might be a different story. >=20 > --Pekka >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.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 _______________________________________________ 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 sip-bounces@ietf.org Wed Feb 22 19:31:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC4OS-0002PH-SX; Wed, 22 Feb 2006 19:31:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC4OR-0002P9-K7 for sip@ietf.org; Wed, 22 Feb 2006 19:31:39 -0500 Received: from celine.siteprotect.com ([64.41.122.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC4OQ-0003jl-BH for sip@ietf.org; Wed, 22 Feb 2006 19:31:39 -0500 Received: from [192.168.1.4] (pool-141-157-104-69.balt.east.verizon.net [141.157.104.69]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id k1N0VSC28348; Wed, 22 Feb 2006 18:31:28 -0600 Subject: RE: [Sip] Outbound and STUN Keep Alive From: "Frank W. Miller" To: Samir Srivastava In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60A86FA5A@zrc2hxm2.corp.nortel.com> References: <62B9B0847CC47543B6B3B5E26BD268E60A86FA5A@zrc2hxm2.corp.nortel.com> Content-Type: text/plain Organization: Cornfed Systems, LLC Date: Wed, 22 Feb 2006 19:31:24 -0500 Message-Id: <1140654684.2639.16.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Pekka Pessi , Cullen Jennings , sip@ietf.org, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fwmiller@cornfed.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Wed, 2006-02-22 at 16:47 -0600, Samir Srivastava wrote: > For SIP based keep alive, How 15 seconds interval fit with > retransmission timers of NON-INVITE transactions which retransmit at the > max at the interval of 4 seconds till 32 seconds . Are we saying that we > are changing this ? The current draft says that you cannot have more than one PING transaction outstanding with a given UAS at a time. If we assume that the UAC is retransmitting the PING but for some reason not receiving any response there are several possibilities. 1) The UAS has gone down 2) The NAT binding has gone away and for some reason sending the PING through it isnt refreshing it properly 3) The NAT is dead 4) Probably others... In any event, you're wanting to send a heartbeat every 15 seconds to keep the NAT up. If you're still retransmitting after 15 seconds, something is probably wrong. The main problem here is that you're now going to get into these 30 and 60 second waits as the backoff occurs on the retransmission timer and that blows your 15 second heartbeat function. I'm actually wondering if we want to change this so that it does not follow standard retransmission rules. For example, the PING might be sent unreliably, i.e. send it once and wait some period for a response. If it doesnt come back, you kill that particular PING transaction. If you want to retransmit the PING, its a new transaction. The choice of whether to retransmit is pushed up to the application. It knows best what the context is for sending the PING in the first place. So, some observations of something like this. First, its a new transaction type. Its really simple, but it is new, its definitely not a NIT. I think it would be OK to still adhere to the routing rules but not to the retransmission rules but I need to think on it some and I'd be interested in any comments on that. Second, its really dirt simple to implement at both the UAC and UAS. Third, its now definitely different from the OPTIONS request. Fourth, I'm starting to think that a PING request is a good idea in general. I've seen three good reasons why you would want something like this: 1) to refresh NAT bindings, 2) as a heartbeat during a session, and 3) as a check for the presence of a UA that is independent of registrations. This last bit could be very useful, particularly for B2BUAs. If I wanted to check whether another UA is available, a quick PING would do nicely. I know all three of these things can be done with OPTIONS but with these new semantics, a PING would make more sense for reasons that have been discussed, load, security, etc. Thoughts? 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 sip-bounces@ietf.org Wed Feb 22 19:50:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC4h6-0005UH-A4; Wed, 22 Feb 2006 19:50:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC1iH-0003D0-Cb for sip@ietf.org; Wed, 22 Feb 2006 16:39:57 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC1eX-0003yS-KN for sip@ietf.org; Wed, 22 Feb 2006 16:36:05 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 22 Feb 2006 13:36:05 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1MLa5Vb003124; Wed, 22 Feb 2006 13:36:05 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Feb 2006 13:36:05 -0800 Received: from [10.21.99.23] ([10.21.99.23]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Feb 2006 13:36:04 -0800 Message-ID: <43FCD944.2070800@cisco.com> Date: Wed, 22 Feb 2006 16:36:04 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manish Joshi Subject: Re: [Sip] A problem of refresh SUBSCRIBE request between servers References: <20060222200745.51629.qmail@web34702.mail.mud.yahoo.com> In-Reply-To: <20060222200745.51629.qmail@web34702.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Feb 2006 21:36:04.0591 (UTC) FILETIME=[FBB327F0:01C637F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Manish Joshi wrote: > Oh yes, off-course. We still need to 'refresh' each of them but guess > we can do all the refreshes again in a single dialog with all "id"s in > EVent Header same as IDs in initial Subscription requests. Yes. But it will still require a subscribe transaction for each one, and also a notify transaction for each one unless we define a way to avoid that. Paul > -Manish > > */Paul Kyzivat /* wrote: > > While you can have a bunch of subscriptions share the same dialog, that > doesn't eliminate the need to refresh each of them. It is the usage > that > expires, not the dialog. > > Paul > > Manish Joshi wrote: > > Hi Xiao, > > > > I havent tried it but a glance at RFC 3265 suggested that ID > parameter > > in event header in Subscribe request can be used to have multiple > > subcription and refreshes in the same dialog. > > > > From RFC 3265 section > > "A SUBSCRIBE request MAY include an "id" parameter in its "Event" > > header to allow differentiation between multiple subscriptions in the > > same dialog." > > > > Thanks, > > Manish > > > > > > */Xiao Wang /* wrote: > > > > Hi, all > > In some cases, there may exist a lot of subscriptions between > > servers. In > > other words, a server act as subscriber to subscribe resource from > > another > > server which act as notifier, and the subscriber can build a lot of > > subscriptions with the notifier. > > My question is a lot of subscriptions between servers can bring a > lot of > > refresh SUBSCRIBE request for each subscription, I think the > > mechanism of > > refresh subscription of RFC3265 is low efficiency in this case. Is > > my view > > right? > > > > Xiao > > > > > > > > _______________________________________________ > > 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 > > > > > > > ------------------------------------------------------------------------ > > Yahoo! Autos > > > ylc=X3oDMTEzcGlrdGY5BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDMWF1dG9z/*http://autos.yahoo.com/index.html > > > >. Looking for a sweet ride? Get pricing, reviews, & more on new and > > used cars. > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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 > > > ------------------------------------------------------------------------ > Yahoo! Autos ylc=X3oDMTEzcGlrdGY5BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDMWF1dG9z/*http://autos.yahoo.com/index.html > >. Looking for a sweet ride? Get pricing, reviews, & more on new and > used cars. _______________________________________________ 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 sip-bounces@ietf.org Wed Feb 22 20:28:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC5HL-0008IN-Si; Wed, 22 Feb 2006 20:28:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC5HJ-0008I7-OR for sip@ietf.org; Wed, 22 Feb 2006 20:28:21 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC5HJ-0006Ce-7N for sip@ietf.org; Wed, 22 Feb 2006 20:28:21 -0500 Received: from huawei.com ([172.24.2.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV4006U98O7PT@usaga01-in.huawei.com> for sip@ietf.org; Wed, 22 Feb 2006 17:12:08 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV4006V59EF64@szxga02-in.huawei.com> for sip@ietf.org; Thu, 23 Feb 2006 09:27:52 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV400EDY9BUN9@szxga02-in.huawei.com> for sip@ietf.org; Thu, 23 Feb 2006 09:27:51 +0800 (CST) Received: from w39649a ([10.76.176.178]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IV400LE99HLR9@szxml01-in.huawei.com>; Thu, 23 Feb 2006 09:29:49 +0800 (CST) Date: Thu, 23 Feb 2006 09:13:38 +0800 From: Xiao Wang Subject: RE: [Sip] A problem of refresh SUBSCRIBE request between servers In-reply-to: <20060222190204.90019.qmail@web34707.mail.mud.yahoo.com> To: 'Manish Joshi' , sip@ietf.org Message-id: <018d01c63816$63923500$b2b04c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcY34n3WEF+ZsQniQX6plu5kYLptxAAMmVbw X-Spam-Score: 0.0 (/) X-Scan-Signature: 90fbdaf3c139ce803b358d56775b59ed Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1629725762==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1629725762== Content-type: multipart/alternative; boundary="Boundary_(ID_AjiTxN3WQ3fhOxc5vzopmg)" This is a multi-part message in MIME format. --Boundary_(ID_AjiTxN3WQ3fhOxc5vzopmg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Manish, My understanding is RFC3265 allowed multiple subscriptions can be associated with a dialog, differentiating the refresh SUBSCRIBE request and NOTIFY request in each different subscriptions of a same dialog by the "id" parameter in its "Event" header field. Xiao _____ From: Manish Joshi [mailto:mjoshi_blr@yahoo.com] Sent: Thursday, February 23, 2006 3:02 AM To: Xiao Wang; sip@ietf.org Subject: Re: [Sip] A problem of refresh SUBSCRIBE request between servers Hi Xiao, I havent tried it but a glance at RFC 3265 suggested that ID parameter in event header in Subscribe request can be used to have multiple subcription and refreshes in the same dialog. >From RFC 3265 section "A SUBSCRIBE request MAY include an "id" parameter in its "Event" header to allow differentiation between multiple subscriptions in the same dialog." Thanks, Manish Xiao Wang wrote: Hi, all In some cases, there may exist a lot of subscriptions between servers. In other words, a server act as subscriber to subscribe resource from another server which act as notifier, and the subscriber can build a lot of subscriptions with the notifier. My question is a lot of subscriptions between servers can bring a lot of refresh SUBSCRIBE request for each subscription, I think the mechanism of refresh subscription of RFC3265 is low efficiency in this case. Is my view right? Xiao _______________________________________________ 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 _____ Yahoo! Autos. Looking for a sweet ride? Get pricing, reviews, & more on new and used cars. --Boundary_(ID_AjiTxN3WQ3fhOxc5vzopmg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Manish,

 

       My understanding is RFC3265 allowed multiple subscriptions can be associated with a dialog, differentiating

the refresh SUBSCRIBE request and NOTIFY request in each different subscriptions of a same dialog by the "id" parameter in its "Event" header field.

 

Xiao

From: Manish Joshi [mailto:mjoshi_blr@yahoo.com]
Sent: Thursday, February 23, 2006 3:02 AM
To: Xiao Wang; sip@ietf.org
Subject: Re: [Sip] A problem of refresh SUBSCRIBE request between servers

 

Hi Xiao,

 

I havent tried it but a glance at RFC 3265 suggested that ID parameter in event header in Subscribe request can be used to have multiple subcription and refreshes in the same dialog.

 

From RFC 3265 section

"A SUBSCRIBE request MAY include an "id" parameter in its "Event"
header to allow differentiation between multiple subscriptions in the
same dialog."

 

Thanks,

Manish


Xiao Wang <wangsmile@huawei.com> wrote:

Hi, all
In some cases, there may exist a lot of subscriptions between servers. In
other words, a server act as subscriber to subscribe resource from another
server which act as notifier, and the subscriber can build a lot of
subscriptions with the notifier.
My question is a lot of subscriptions between servers can bring a lot of
refresh SUBSCRIBE request for each subscription, I think the mechanism of
refresh subscription of RFC3265 is low efficiency in this case. Is my view
right?

Xiao



_______________________________________________
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

 

Yahoo! Autos. Looking for a sweet ride? Get pricing, reviews, & more on new and used cars.

--Boundary_(ID_AjiTxN3WQ3fhOxc5vzopmg)-- --===============1629725762== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1629725762==-- From sip-bounces@ietf.org Wed Feb 22 20:40:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC5TD-0000SG-DA; Wed, 22 Feb 2006 20:40:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC5TC-0000SB-0k for sip@ietf.org; Wed, 22 Feb 2006 20:40:38 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC5T8-0006iO-O0 for sip@ietf.org; Wed, 22 Feb 2006 20:40:37 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k1N1eSZ24471; Wed, 22 Feb 2006 20:40:28 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Outbound and STUN Keep Alive Date: Wed, 22 Feb 2006 19:40:25 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0700DAEB@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcY4FK3RY17SVK5zQbiymyUfbSKB/AABNKTg From: "Francois Audet" To: , "Samir Srivastava" X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Pekka Pessi , Cullen Jennings , sip@ietf.org, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > Fourth, I'm starting to think that a PING request is a good=20 > idea in general. I've seen three good reasons why you would=20 > want something like > this: 1) to refresh NAT bindings, 2) as a heartbeat during a=20 > session, and 3) as a check for the presence of a UA that is=20 > independent of registrations. This last bit could be very=20 > useful, particularly for B2BUAs. If I wanted to check=20 > whether another UA is available, a quick PING would do=20 > nicely. I know all three of these things can be done with=20 > OPTIONS but with these new semantics, a PING would make more=20 > sense for reasons that have been discussed, load, security, etc. Agree with 1.=20 2 already exists: empty UPDATE as per RFC 4028. Hadn't tought about 3 too much. I guess it would be a cheaper OPTIONS. _______________________________________________ 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 sip-bounces@ietf.org Wed Feb 22 21:08:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC5tx-0001k4-AX; Wed, 22 Feb 2006 21:08:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC5tu-0001jw-K7 for sip@ietf.org; Wed, 22 Feb 2006 21:08:15 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC5tu-0007eu-9L for sip@ietf.org; Wed, 22 Feb 2006 21:08:14 -0500 Received: from huawei.com ([172.24.2.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV40062NA7APT@usaga01-in.huawei.com> for sip@ietf.org; Wed, 22 Feb 2006 17:45:10 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV4006HEAXIDK@szxga02-in.huawei.com> for sip@ietf.org; Thu, 23 Feb 2006 10:00:54 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV400EJ4AWSN9@szxga02-in.huawei.com> for sip@ietf.org; Thu, 23 Feb 2006 10:00:54 +0800 (CST) Received: from w39649a ([10.76.176.178]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IV400068AP3SC@szxml01-in.huawei.com>; Thu, 23 Feb 2006 09:55:53 +0800 (CST) Date: Thu, 23 Feb 2006 09:39:49 +0800 From: Xiao Wang Subject: RE: [Sip] A problem of refresh SUBSCRIBE request between servers In-reply-to: <43FCBD79.7080208@cisco.com> To: 'Paul Kyzivat' , 'Manish Joshi' Message-id: <019201c6381a$08dcefc0$b2b04c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcY353qSDqwKPAa2R3KLb/4+CSnguAALxMNg X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul, Inline, Xiao > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, February 23, 2006 3:37 AM > To: Manish Joshi > Cc: Xiao Wang; sip@ietf.org > Subject: Re: [Sip] A problem of refresh SUBSCRIBE request between servers > > While you can have a bunch of subscriptions share the same dialog, that > doesn't eliminate the need to refresh each of them. It is the usage that > expires, not the dialog. > [Xiao]My view is the server act as subscriber which use a SIP message(called BSRM: Batch Subscriptions Refreshment Message) to include multiple refreshed subscriptions' id in the body , the subscriber send BSRM to notifier and notifier get all ids from BSRM body, so notifier can refresh the subscriptions which the ids indicate. The benefit is use BSRM to refresh multiple subscriptions and reduce refresh SUBCRIBE request in net, also reduce the transactions of refresh subscription. > Paul > > Manish Joshi wrote: > > Hi Xiao, > > > > I havent tried it but a glance at RFC 3265 suggested that ID parameter > > in event header in Subscribe request can be used to have multiple > > subcription and refreshes in the same dialog. > > > > From RFC 3265 section > > "A SUBSCRIBE request MAY include an "id" parameter in its "Event" > > header to allow differentiation between multiple subscriptions in the > > same dialog." > > > > Thanks, > > Manish > > > > > > */Xiao Wang /* wrote: > > > > Hi, all > > In some cases, there may exist a lot of subscriptions between > > servers. In > > other words, a server act as subscriber to subscribe resource from > > another > > server which act as notifier, and the subscriber can build a lot of > > subscriptions with the notifier. > > My question is a lot of subscriptions between servers can bring a lot > of > > refresh SUBSCRIBE request for each subscription, I think the > > mechanism of > > refresh subscription of RFC3265 is low efficiency in this case. Is > > my view > > right? > > > > Xiao > > > > > > > > _______________________________________________ > > 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 > > > > > > ------------------------------------------------------------------------ > > Yahoo! Autos > > ylc=X3oDMTEzcGlrdGY5BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDMWF1dG9z/*http > ://autos.yahoo.com/index.html > > >. Looking for a sweet ride? Get pricing, reviews, & more on new and > > used cars. > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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 sip-bounces@ietf.org Wed Feb 22 22:03:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC6kv-0005Yk-VE; Wed, 22 Feb 2006 22:03:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC6kv-0005Yf-1W for sip@ietf.org; Wed, 22 Feb 2006 22:03:01 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC6ku-0001Rp-Lp for sip@ietf.org; Wed, 22 Feb 2006 22:03:01 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 22 Feb 2006 19:03:01 -0800 X-IronPort-AV: i="4.02,138,1139212800"; d="scan'208"; a="1778889681:sNHT32624132" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k1N330uh021969; Wed, 22 Feb 2006 19:03:00 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Feb 2006 19:02:59 -0800 Received: from [10.21.121.114] ([10.21.121.114]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Feb 2006 19:02:59 -0800 Message-ID: <43FD25E2.5090209@cisco.com> Date: Wed, 22 Feb 2006 22:02:58 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Xiao Wang Subject: Re: [Sip] A problem of refresh SUBSCRIBE request between servers References: <019201c6381a$08dcefc0$b2b04c0a@china.huawei.com> In-Reply-To: <019201c6381a$08dcefc0$b2b04c0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Feb 2006 03:02:59.0473 (UTC) FILETIME=[A714A010:01C63825] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Xiao Wang wrote: > Paul, > Inline, > Xiao > >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Thursday, February 23, 2006 3:37 AM >>To: Manish Joshi >>Cc: Xiao Wang; sip@ietf.org >>Subject: Re: [Sip] A problem of refresh SUBSCRIBE request between servers >> >>While you can have a bunch of subscriptions share the same dialog, that >>doesn't eliminate the need to refresh each of them. It is the usage that >>expires, not the dialog. >> > > [Xiao]My view is the server act as subscriber which use a SIP message(called > BSRM: Batch Subscriptions Refreshment Message) to include multiple refreshed > subscriptions' id in the body , the subscriber send BSRM to notifier and > notifier get all ids from BSRM body, so notifier can refresh the > subscriptions which the ids indicate. > The benefit is use BSRM to refresh multiple subscriptions and reduce refresh > SUBCRIBE request in net, also reduce the transactions of refresh > subscription. I was talking about what is currently legal. You are free to propose your idea for BSRM. There are a lot of details you need to work out for that. If the subscriptions are not part of the same dialog, then you will need to figure out how to specify a request that applies to a number of different dialogs, and deals properly with the CSeqs of each of them. Paul > Paul >> >>Manish Joshi wrote: >> >>>Hi Xiao, >>> >>>I havent tried it but a glance at RFC 3265 suggested that ID parameter >>>in event header in Subscribe request can be used to have multiple >>>subcription and refreshes in the same dialog. >>> >>> From RFC 3265 section >>>"A SUBSCRIBE request MAY include an "id" parameter in its "Event" >>>header to allow differentiation between multiple subscriptions in the >>>same dialog." >>> >>>Thanks, >>>Manish >>> >>> >>>*/Xiao Wang /* wrote: >>> >>> Hi, all >>> In some cases, there may exist a lot of subscriptions between >>> servers. In >>> other words, a server act as subscriber to subscribe resource from >>> another >>> server which act as notifier, and the subscriber can build a lot of >>> subscriptions with the notifier. >>> My question is a lot of subscriptions between servers can bring a > > lot > >>of >> >>> refresh SUBSCRIBE request for each subscription, I think the >>> mechanism of >>> refresh subscription of RFC3265 is low efficiency in this case. Is >>> my view >>> right? >>> >>> Xiao >>> >>> >>> >>> _______________________________________________ >>> 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 >>> >>> >>>------------------------------------------------------------------------ >>>Yahoo! Autos >> >> >>ylc=X3oDMTEzcGlrdGY5BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDMWF1dG9z/*http >>://autos.yahoo.com/index.html >> >>> >. Looking for a sweet ride? Get pricing, reviews, & more on new and >>>used cars. >>> >>> >>>------------------------------------------------------------------------ >>> >>>_______________________________________________ >>>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 sip-bounces@ietf.org Wed Feb 22 22:32:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC7Da-0007bD-9L; Wed, 22 Feb 2006 22:32:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC7DY-0007b5-TX for sip@ietf.org; Wed, 22 Feb 2006 22:32:36 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC7DX-0003Qx-IT for sip@ietf.org; Wed, 22 Feb 2006 22:32:36 -0500 Received: from [131.161.248.90] (open-131-161-248-90.cliq.com [131.161.248.90]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k1N3WRF14634; Wed, 22 Feb 2006 19:32:27 -0800 Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <26fbf302818a0cbbe4558f83410f081c@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Wed, 22 Feb 2006 19:32:28 -0800 To: SIP WG X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Dean Willis Subject: [Sip] WGLC for draft-ietf-sip-answermode-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I'd like to start a 3-week working group last call for: draft-ietf-sip-answermode-00.txt This WGLC will complete on March 15th thanks, -rohan Rohan Mahy co-chair SIP WG _______________________________________________ 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 sip-bounces@ietf.org Wed Feb 22 22:44:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC7PN-0008Td-Qg; Wed, 22 Feb 2006 22:44:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC7PM-0008TY-8c for sip@ietf.org; Wed, 22 Feb 2006 22:44:48 -0500 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC7PL-0003rL-10 for sip@ietf.org; Wed, 22 Feb 2006 22:44:48 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id A55956C017 for ; Wed, 22 Feb 2006 22:44:46 -0500 (EST) Subject: Re: [Sip] What is going on with GRUU? From: "Dale R. Worley" To: Sip In-Reply-To: <43FBF9F9.3010806@cisco.com> References: <1140581121.25492.10.camel@cdhcp139.pingtel.com> <43FBF9F9.3010806@cisco.com> Content-Type: text/plain Date: Wed, 22 Feb 2006 22:44:46 -0500 Message-Id: <1140666286.29757.8.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Wed, 2006-02-22 at 00:43 -0500, Jonathan Rosenberg wrote: > > I personally prefer that the Supported and Require headers describe only > > properties of the UAs, and not properties of the messages per se. > > (Although that a UA conforms to an extension may imply something about > > all messages it handles.) draft-ietf-sip-gruu-06 uses these headers to > > mark properties of messages, in that a UA must apply "Supported: gruu" > > to some requests and not to others. But I heard a considerable amount > > of support on the mailing lists for my attitude. Does draft-ietf-sip- > > gruu-06 still express the consensus of the WG? > > With the above solution, there is no requirement for the home proxy to > know whether the contents of the contact are a gruu. As such, the spec > will relax this constraint around usage in the contact and Supported: gruu. -06 also prescribes particular usage of Supported and Require in regard to REGISTER requests, whereas I would take an approach more like this: + If a registrar is compliant with this feature, if a contact address has + a +sip.instance field-parameter, the registrar will return it in its response + with an appropriate gruu field-parameter. That is, the presence or absence of Supported/Require would not regulate GRUU issuing, only the presence of +sip.instance. This approach would be non-upward-compatible to some degree, in that if a non-GRUU-aware UA happens to apply +sip.instance to a contact, the response to the REGISTER will have a gruu applied to it, which presumably it does not understand. (I would argue that any UA should be prepared to ignore field-parameters that it does not understand.) On the other hand, this approach would retain the "pure" interpretation of Supported/Require. Dale _______________________________________________ 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 sip-bounces@ietf.org Thu Feb 23 04:38:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCCvV-0006Mc-S8; Thu, 23 Feb 2006 04:38:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCCvT-0006MU-OL for sip@ietf.org; Thu, 23 Feb 2006 04:38:19 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCCvT-0001Ga-4L for sip@ietf.org; Thu, 23 Feb 2006 04:38:19 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id DF03C194473 for ; Thu, 23 Feb 2006 10:38:17 +0100 (CET) Received: from [192.168.1.45] ([192.168.1.45]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Feb 2006 10:36:51 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Thu, 23 Feb 2006 10:38:37 +0100 To: "Gary Gan" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 23 Feb 2006 09:36:51.0162 (UTC) FILETIME=[ACAA33A0:01C6385C] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: 'Cullen Jennings' , sip@ietf.org, 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The first question is why would the UA be sending STUN requests. As far as that UA is concerned, there is no NAT (the UA can do a basic RFC1918). Note that for RTP, the situation a little different. But that's not what were are talking about here. Hisham On Feb 22, 2006, at 9:05 PM, Gary Gan wrote: > [UA] ---> [Outbound Proxy] -->|N| -->[SIP Registrar server$B!!!!!!(B] > | |A| | +$B!!!!!!!!!!!!!!!!!!!!!!!!(B| > |------------STUN?--------->[T| -->[Multiplexed STUN server$B!!(B] > > I just wonder how the STUN solution works with the above scenario. > With the > outbound proxy in the different IP behind the NAT, the STUN keep-alive > would > not be valid since the NAT binding is between the outbound proxy and > the SIP > server. > > Gary Gan > Clique Communications, LLC > > > -----Original Message----- > From: Gary Gan [mailto:ggan@cliquecom.com] > Sent: Wednesday, February 22, 2006 2:25 PM > To: 'Dean Willis'; 'Cullen Jennings' > Cc: sip@ietf.org; 'Francois Audet'; 'Chris Boulton'; 'Michael Procter'; > fwmiller@cornfed.com; 'John Elwell' > Subject: RE: [Sip] Outbound and STUN Keep Alive > >> Does the server that you're sending CRLF to just continue to echo >> CRLF back at you? Or does it have some way of recognizing that it's >> suddenly getting CRLF echo requests from a partner from which it has >> no current registration and stop echoing CRLF at you? > >> -- >> Dean > > Depending on the server implementation, but either way has problems. > If the > echo comes back from the new binding, the UA would not know the NAT has > rebooted. That's what the STUN multiplexing tries to resolve, which > actually > handles the binding comparison on the client side. If the server > checks for > the client bindings, then the server needs to maintain the binding > states of > all UA, either in memory or database. It uses server resource. I don't > think > it scales. > > Gary Gan > Clique Communications > > > _______________________________________________ > 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 sip-bounces@ietf.org Thu Feb 23 06:14:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCEQp-0002IC-MM; Thu, 23 Feb 2006 06:14:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCEQn-0002I1-Lo for sip@ietf.org; Thu, 23 Feb 2006 06:14:45 -0500 Received: from nproxy.gmail.com ([64.233.182.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCEQk-0004sS-A4 for sip@ietf.org; Thu, 23 Feb 2006 06:14:45 -0500 Received: by nproxy.gmail.com with SMTP id m19so15457nfc for ; Thu, 23 Feb 2006 03:14:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=YoJIMJ1Qw2m+rZBggDo1TdlzdpIcPWGe2mrCz5jofSRJBOABlnO2zJ+MKCwVxAQzA8QVvh67gjICavi/mvd7O9h+V1GuduN/+27fq+VnSBjlbczWpplBIhSP7IpoKEEb1hNhlqBHWXGvavKEG9Of36PftG7ff7r/eX2DM/mc8Mc= Received: by 10.48.238.20 with SMTP id l20mr2314010nfh; Thu, 23 Feb 2006 03:14:41 -0800 (PST) Received: by 10.49.35.18 with HTTP; Thu, 23 Feb 2006 03:14:41 -0800 (PST) Message-ID: <52db68bc0602230314j63088ae9ydb0ce7bca9529f9b@mail.gmail.com> Date: Thu, 23 Feb 2006 16:44:41 +0530 From: "Sudhir Kumar Reddy" To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Sip] Query regarding Cancel X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1099189921==" Errors-To: sip-bounces@ietf.org --===============1099189921== Content-Type: multipart/alternative; boundary="----=_Part_17077_3957309.1140693281051" ------=_Part_17077_3957309.1140693281051 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi All, Apologies if this has been discussed earlier Can we send Cancel request immediately after getting a 100 Trying response to the INVITE? The other question is when we receive a INVITE with Record-Route header, MUST we include this record-Route in the 487(to a CANCEL) response ? thanks in advance best regards, Sudhir ------=_Part_17077_3957309.1140693281051 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi All,
 
Apologies if this has been discussed earlier
 
 Can we send Cancel request immediately after getting a 100 = Trying response to the INVITE?
 
 The other question is when we receive a INVITE with Re= cord-Route header, MUST we include this record-Route in the 487(to a CANCEL= )
 response ?
 
thanks in advance
 
best regards,
Sudhir
------=_Part_17077_3957309.1140693281051-- --===============1099189921== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1099189921==-- From sip-bounces@ietf.org Thu Feb 23 07:39:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCFjK-0008AL-Qz; Thu, 23 Feb 2006 07:37:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCFjJ-00089d-NM for sip@ietf.org; Thu, 23 Feb 2006 07:37:57 -0500 Received: from usagi.ingate.se ([193.180.23.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCFjI-0007PF-6S for sip@ietf.org; Thu, 23 Feb 2006 07:37:57 -0500 Received: from eeek.ingate.se (eeek.ingate.se [193.180.23.45]) by usagi.ingate.se (8.12.11/8.12.11) with ESMTP id k1NCbhCS027668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Feb 2006 13:37:43 +0100 Received: from eeek.ingate.se (IDENT:7EcMy7Fq8zRWp9G+ReSTqBJSk5qZeE3S@localhost.localdomain [127.0.0.1]) by eeek.ingate.se (8.12.11/8.12.11) with ESMTP id k1NCbfeR007301; Thu, 23 Feb 2006 13:37:41 +0100 Received: (from hasse@localhost) by eeek.ingate.se (8.12.11/8.12.11/Submit) id k1NCba9G007297; Thu, 23 Feb 2006 13:37:37 +0100 X-Authentication-Warning: eeek.ingate.se: hasse set sender to hasse@ingate.com using -f Subject: Re: [Sip] WGLC for draft-ietf-sip-answermode-00 From: Hans Persson To: Rohan Mahy In-Reply-To: <26fbf302818a0cbbe4558f83410f081c@ekabal.com> References: <26fbf302818a0cbbe4558f83410f081c@ekabal.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Ingate Systems Message-Id: <1140698256.30530.154.camel@eeek.ingate.se> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 23 Feb 2006 13:37:36 +0100 X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on usagi.ingate.se X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (usagi.ingate.se [193.180.23.12]); Thu, 23 Feb 2006 13:37:43 +0100 (CET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: SIP WG , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org tor 2006-02-23 klockan 04.32 skrev Rohan Mahy: > I'd like to start a 3-week working group last call for: > > draft-ietf-sip-answermode-00.txt I have a couple of questions where I would like clarifications and a whole slew of nits. Questions: Page 8, Req-11: I'm not able to make sense of "[...] knowledge that may be important in informing UAC-user's usage of the session.". Page 12, Section 4.2.1: In this paragraph is the text: "must be done very carefully and only in the context of an external agreement between the proxy operator and the user of the UA.". The text "the UA" (singular) implies that we're talking about only one of the UAC and the UAS and not both, but I think it would be good to explicitly state which one is meant (I assume it would be the UAS, but more clarity won't hurt). Nits: Page 5, last paragraph: intercom(m) is spelled with first one, then two, then again one "m". Page 6, first (complete) paragraph: two instances of "caes" instead of "cases" and one of "Ther" instead of "There". Req-1: "for UAC" should be "for the UAC" and "UAS-user" should be "the UAS-user". Page 7, Req-2: "the UAC", "the UAS-user", "the UAS". Req-3: "the UAS". Req-4: "the UAC", "the UAS". Period missing at the end. Req-5: "the UAC" Req-6: "the UAS" (twice), "and or" should be "and/or". Req-7: "the UAS", duplicated "that", "the UAS". Page 8, Req-9: "the UAC", "the UAS". Req-10: "the UAC or the UAS" Req-11: "the UAS", "the UAC", "the UAC-user". Req-12: "a UAS" or "UASs". Actually this type of form may be the correct choise for some of the above cases as well, but *something* is definitely missing. Page 9, last paragraph of section 3: shouldn't this be "implementations MUST" for clarity? Last paragraph: Period missing before "For example". Page 10, first paragraph of section 4.1.3: insert "an" before "appropriate parameter". second paragraph, 4.1.3: "a Answer-Mode" should be "an Answer-Mode". Ditto in the following three paragraphs. Page 11, third (complete) paragraph: It looks messy to put text containing double quotes inside double quotes. The same goes for the following two paragraphs. In the last of these three, the problematic passage also contains an extra spurious double quote. Page 12, first (incomplete) paragraph: "prefxing" should be "prefixing". Section 4.2.1: "a Answer-Mode" should be "an...". Section 4.2.2, first paragraph: "UAS" -> "UASs" (twice, and once each in the next two paragraphs). Page 13, section 4.3.1, first paragraph: "for unattended UAS" -> "for unattended UASs". Third paragraph: "a Answer-Mode" -> "an ...". Fourth paragraph: This talks about 'an Answer-Mode *parameter* of "Auto"'. The previous paragraph has 'an Answer-Mode *value* of "Auto"'. Please use a consistent naming scheme. Page 15, section 5, first paragraph: Duplicated "the". Section 5.1: "a Answer-Mode" -> "an..." (twice). Page 16, first (incomplete) paragraph: "UAS" (last instance) -> "UASs". Section 6: Duplicated "an". "asnwering" -> "answering". Page 19, first (incomplete) paragraph: Duplicated "a". Page 20, first item 1: Missing period at end. Item 4: "nee o" -> "need to". First paragraph after items 1-5: Extra comma before "[2]". Second item 1: Missing period at end (and also for item 2, on the next page). Hans -- Hans Persson Ingate - Firewalls with SIP & NAT Ingate Systems AB +46 13 210877 http://www.ingate.com/ Private: http://www.lysator.liu.se/~unicorn/ _______________________________________________ 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 sip-bounces@ietf.org Thu Feb 23 09:10:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCH8w-0008KS-ET; Thu, 23 Feb 2006 09:08:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCH8u-0008HK-Nm for sip@ietf.org; Thu, 23 Feb 2006 09:08:28 -0500 Received: from [66.155.254.250] (helo=isdmail1.inovsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCH8s-0003EY-Df for sip@ietf.org; Thu, 23 Feb 2006 09:08:28 -0500 Received: from greatwall ([12.181.128.3]) by isdmail1.inovsys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 23 Feb 2006 09:08:26 -0500 From: "Gary Gan" To: "'Hisham Khartabil'" Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Thu, 23 Feb 2006 09:08:27 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: thread-index: AcY4XOgsOh+JA579QXS7x8mhyEC2ugAJXNvg Message-ID: X-OriginalArrivalTime: 23 Feb 2006 14:08:26.0137 (UTC) FILETIME=[9D3A1090:01C63882] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: 'Cullen Jennings' , sip@ietf.org, 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Take a look at: draft-ietf-sip-outbound-01 Gary Gan > The first question is why would the UA be sending STUN requests. As far > as that UA is concerned, there is no NAT (the UA can do a basic > RFC1918). Note that for RTP, the situation a little different. But > that's not what were are talking about here. Hisham On Feb 22, 2006, at 9:05 PM, Gary Gan wrote: > [UA] ---> [Outbound Proxy] -->|N| -->[SIP Registrar server$B!!!!!!(B] > | |A| | +$B!!!!!!!!!!!!!!!!!!!!!!!!(B| > |------------STUN?--------->[T| -->[Multiplexed STUN server$B!!(B] > > I just wonder how the STUN solution works with the above scenario. > With the > outbound proxy in the different IP behind the NAT, the STUN keep-alive > would > not be valid since the NAT binding is between the outbound proxy and > the SIP > server. > > Gary Gan > Clique Communications, LLC > > > -----Original Message----- > From: Gary Gan [mailto:ggan@cliquecom.com] > Sent: Wednesday, February 22, 2006 2:25 PM > To: 'Dean Willis'; 'Cullen Jennings' > Cc: sip@ietf.org; 'Francois Audet'; 'Chris Boulton'; 'Michael Procter'; > fwmiller@cornfed.com; 'John Elwell' > Subject: RE: [Sip] Outbound and STUN Keep Alive > >> Does the server that you're sending CRLF to just continue to echo >> CRLF back at you? Or does it have some way of recognizing that it's >> suddenly getting CRLF echo requests from a partner from which it has >> no current registration and stop echoing CRLF at you? > >> -- >> Dean > > Depending on the server implementation, but either way has problems. > If the > echo comes back from the new binding, the UA would not know the NAT has > rebooted. That's what the STUN multiplexing tries to resolve, which > actually > handles the binding comparison on the client side. If the server > checks for > the client bindings, then the server needs to maintain the binding > states of > all UA, either in memory or database. It uses server resource. I don't > think > it scales. > > Gary Gan > Clique Communications > > > _______________________________________________ > 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 sip-bounces@ietf.org Thu Feb 23 09:34:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCHVy-0006NF-21; Thu, 23 Feb 2006 09:32:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCHVw-0006Mx-89 for sip@ietf.org; Thu, 23 Feb 2006 09:32:16 -0500 Received: from defender.ccpu.com ([216.54.134.34] helo=smtp.ccpu.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCHVt-0004OF-NJ for sip@ietf.org; Thu, 23 Feb 2006 09:32:16 -0500 Received: from smtp.ccpu.com (localhost.localdomain [127.0.0.1]) by localhost.ccpu.com (Postfix) with ESMTP id 0A67F346980; Thu, 23 Feb 2006 06:32:13 -0800 (PST) Received: from sd-exchange.ccsd.ccpu.com (sd-exchange.ccpu.com [172.16.0.203]) by smtp.ccpu.com (Postfix) with ESMTP id EFDF5346966; Thu, 23 Feb 2006 06:32:12 -0800 (PST) Received: from IN-EXCHANGE.ccin.ccpu.com ([172.25.0.16]) by sd-exchange.ccsd.ccpu.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Feb 2006 06:32:11 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Query regarding Cancel X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Thu, 23 Feb 2006 20:02:05 +0530 Message-ID: <22F058C3ED9D784E90CE473F2A9847F042950B@in-exchange> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Query regarding Cancel Thread-Index: AcY4daZZXfFusJWnQcWh9io4a1DK7gACSuvA From: "Atul kumar Jha" To: "Sudhir Kumar Reddy" , X-OriginalArrivalTime: 23 Feb 2006 14:32:11.0979 (UTC) FILETIME=[EF1849B0:01C63885] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0780355906==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0780355906== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63885.EBDCDA55" This is a multi-part message in MIME format. ------_=_NextPart_001_01C63885.EBDCDA55 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sudhir, =20 CANCEL can be sent after receiving provisional response (not 100 Trying). As 100 trying can be sent by a Proxy. So, it should wait for provisional response to come. =20 =20 For 487, RFC does not mandate the Record-Route header to be copied. It is not needed because ACK in this case will follow the same Route as the INVITE. =20 Regards, Atul=20 =20 =20 ________________________________ From: Sudhir Kumar Reddy [mailto:t.sudhirkumar@gmail.com]=20 Sent: Thursday, February 23, 2006 4:45 PM To: sip@ietf.org Subject: [Sip] Query regarding Cancel =20 Hi All, =20 Apologies if this has been discussed earlier =20 Can we send Cancel request immediately after getting a 100 Trying response to the INVITE? =20 The other question is when we receive a INVITE with Record-Route header, MUST we include this record-Route in the 487(to a CANCEL)=20 response ? =20 thanks in advance =20 best regards, Sudhir ------_=_NextPart_001_01C63885.EBDCDA55 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Sudhir,

 

CANCEL can be sent after receiving provisional response (not 100 Trying).

As 100 trying can be sent by a = Proxy. So, it should wait for provisional response to come. =  

 

For 487, RFC does not mandate the Record-Route header to be copied.

It is not needed because ACK in = this case will follow the same Route as the INVITE.

 

Regards,

Atul

 

 

From: = Sudhir Kumar Reddy [mailto:t.sudhirkumar@gmail.com]
Sent: Thursday, February = 23, 2006 4:45 PM
To: sip@ietf.org
Subject: [Sip] Query = regarding Cancel

 

Hi All,

 

Apologies if this has been discussed = earlier

 

 Can we send Cancel request immediately after getting = a 100 Trying response to the INVITE?

 

 The other question is when we receive a = INVITE with Record-Route header, MUST we include this record-Route in the 487(to a = CANCEL)

 response ?

 

thanks in advance

 

best regards,

Sudhir

------_=_NextPart_001_01C63885.EBDCDA55-- --===============0780355906== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0780355906==-- From sip-bounces@ietf.org Thu Feb 23 09:35:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCHWo-0007My-Eu; Thu, 23 Feb 2006 09:33:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCHWm-0007MW-SH for sip@ietf.org; Thu, 23 Feb 2006 09:33:08 -0500 Received: from ip-10-194-65-202.rev.dyxnet.com ([202.65.194.10] helo=hitachi.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FCHWl-0004SK-Lc for sip@ietf.org; Thu, 23 Feb 2006 09:33:08 -0500 Received: (qmail 27665 invoked from network); 23 Feb 2006 14:33:05 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk1;119fc73abc85116ed9d8722abfb43511; Received: from unknown (HELO hitachihk5.hitachi.cn) (170.95.94.1)by ip-11-194-65-202.rev.dyxnet.com with SMTP; 23 Feb 2006 14:33:05 -0000 Received: (qmail 15325 invoked from network); 23 Feb 2006 14:33:06 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk5;7e025b7c8e1fd49d41dba5e9a2442541; Received: from hchidc204.hitachi-china.com (HELO hchidc204.hitachi.cn) (170.95.82.6)by 172.16.10.9 with SMTP; 23 Feb 2006 14:33:05 -0000 Received: from hcbjdc2.hitachi.cn ([170.95.81.2]) by hchidc204.hitachi.cn with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Feb 2006 22:33:05 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 23 Feb 2006 22:33:04 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA38BC6BD4@hcbjdc2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda of China workshop about Next Generatoin Internet Thread-Index: AcY4hg4MWqte+ZKmTJK489g3LjPXNA== From: "DENG, HUI -HCHBJ" To: ,, X-OriginalArrivalTime: 23 Feb 2006 14:33:05.0720 (UTC) FILETIME=[0F208380:01C63886] X-Scanned-By-hitachihk5: Virus scan performed by network-box X-Scanned-By-hitachihk5: Scanner file id is hitachihk5-1140705185.960-15322-000 X-Scanned-By-hitachihk5: No known viruses found in message (received+scanned in 0.02/0.05 secs) X-Scanned-By-hitachihk5: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Spam-Status: No X-Scanned-By-hitachihk1: Virus scan performed by network-box X-Scanned-By-hitachihk1: Scanner file id is hitachihk1-1140705185.350-27653-000 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 0.01/0.01 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk1: Whitelisted with valid signature (outbound via Network Box hitachihk5) X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: sip@ietf.org, mip6@ietf.org, softwires@ietf.org, mip4@ietf.org, netlmm@ngnet.it Subject: [Sip] Agenda of China workshop about Next Generatoin Internet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1544249978==" Errors-To: sip-bounces@ietf.org --===============1544249978== content-class: urn:content-classes:message Content-Type: text/plain;charset="utf-8" Content-Transfer-Encoding: base64 DQpXb3Jrc2hvcCBvbiBOZXcgVHJlbmQgb2YgTmV4dCBHZW5lcmF0aW9uIEludGVybmV0IGluIENo aW5hDQoNCigxKSBPcmdhbml6ZXJzOiAgQ2hpbmEgTmV4dC1HZW5lcmF0aW9uIEludGVybmV0IEV4 cGVydHMgQ29tbWlzc2lvbg0KICAgIEhvc3Q6ICAgICAgICBDRVJORVQgQ2VudGVyOiBDaGluYSBF ZHVjYXRpb24gYW5kIFJlc2VhcmNoIE5ldHdvcmsgQ2VudGVyDQogICAgU3BvbnNvcjogICAgIEhp dGFjaGkgKENoaW5hKSBSJkQgQ29ycG9yYXRpb24uDQooMikgRGF0ZS9UaW1lOiAgIEZlYi4gMjd0 aC0yOHRoLiBNb25kYXkvVHVlc2RheSwgMjAwNg0KKDMpIFZlbnVlOiAgICAgICBMZWN0dXJlIEhh bGwsIDJuZCBGbG9vciwgVHNpbmdodWEgVW5pdi4gRklUIEJ1aWxkaW5nDQooNCkgUHJvZ3JhbTog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgDQoNCkZlYi4gMjd0aA0K77ycTW9ybmluZyBTZXNzaW9u77ye44CA44CA44CA44CAQ2hh aXI6IFByb2YuIEhlcXVhbiBXdSAoQ2hpZWYgU2NpZW50aXN0IG9mIENOR0kgRXhwZXJ0cyBDb21t aXNzaW9uKQ0KIDk6MDAtIDk6MjAgIE9wZW5pbmcgQWRkcmVzcw0KICAgICAgICAgICAgIFByb2Yu IEhlcXVhbiBXdSAgKENoaWVmIFNjaWVudGlzdCBvZiBDTkdJIEV4cGVydHMgQ29tbWlzc2lvbikN Cg0KIDk6MjAtMTA6MDAgIElQIE1vYmlsaXR5IG1lY2hhbmlzbXMgLSB0b2RheSBhbmQgdG9tb3Jy b3cNCiAgICAgICAgICAgICBNci5IZW5yaWsgTGV2a293ZXR6IChFcmljc3NvbiwgQ2hhaXIgb2Yg TUlQNCBXRyBpbiBJRVRGKQ0KDQoxMDowMC0xMDo0MCAgU3RyYXRlZ3kgb2YgTmV4dCBHZW5lcmF0 aW9uIEludGVybmV0IG9mIENoaW5hIE5ldGNvbQ0KICAgICAgICAgICAgIE1zLiBZYW4gTWEgIChE aXJlY3RvciBvZiBEZXB0LiBUZWNobm9sb2d5LCBDaGluYSBOZXRjb20pDQoNCjEwOjQwLTEwOjUw ICAg77ycICBDb2ZmZWUgQnJlYWsg77yeDQoNCjEwOjUwLTExOjMwICBDRVJORVQyDQogICAgICAg ICAgICAgRHIuIEppYW5waW5nIFd1IChEaXJlY3RvciwgQ0VSTkVUMikNCg0KMTE6MzAtMTI6MTAg IE5UVCBEb0NvTW8ncyBWaWV3IGZvciBBbGwtSVAgTmV0d29yaw0KICAgICAgICAgICAgIE1yLiBI aXJvYWtpIEFtYWRhLCBEci4gTWFzYW1pIFlBQlVTQUtJLCAoSVAgQ29yZSBOZXR3b3JrIERldmVs b3BtZW50IERlcGFydG1lbnQsIERvQ29NbykNCg0KMTI6MjAtMTQ6MDAgIO+8nCBMdW5jaCDvvJ4N Cg0K77ycQWZ0ZXJub29uIFNlc3Npb27vvJ4gICAgICAgQ2hhaXI6IEhlbnJpayBMZXZrb3dldHog KENoYWlyIG9mIE1JUDQsIElFVEYpDQoxNDowMC0xNDo0MCAgTWVkaWEgSW5kZXBlbmRlbnQgSGFu ZG92ZXIgU2VydmljZXMgLSBJRUVFIDgwMi4yMQ0KICAgICAgICAgICAgIERyLiBBamF5IFJhamt1 bWFyIChMdWNlbnQsIENoYWlyIG9mIElFRUUgODAyLjIxKQ0KDQoxNDo0MC0xNToyMCAgTmV3IFRy ZW5kIG9mIE5leHQgR2VuZXJhdGlvbiBJbnRlcm5ldCBvZiBDaGluYSBVbmljb20uDQogICAgICAg ICAgICAgRHIuIFl1bmppZSBMaXUgKFByZS1DVE8gb2YgQ2hpbmEgVW5pY29tKQ0KDQoxNToyMC0x NjowMCAgTXVsdGljYXN0IGFuZCB0aGUgTmV4dCBHZW5lcmF0aW9uIEludGVybmV0OiBNQk1TLCBC Q01DUyANCiAgICAgICAgICAgICAgYW5kIE1vYmlsZSBNdWx0aWNhc3QgVmlkZW8gU2VydmljZXMN CiAgICAgICAgICAgICBNci4gTWFyc2hhbGwgRXViYW5rcyAoTXVsdGljYXN0IFRlY2gpDQoNCjE2 OjAwLTE2OjEwICAg77ycICBDb2ZmZWUgQnJlYWsg77yeDQoNCjE2OjEwLTE2OjUwICBPcGluaW9u IGFib3V0IE5leHQgR2VuZXJhdGlvbiBJbnRlcm5ldCBmcm9tIENoaW5hIE1vYmlsZQ0KICAgICAg ICAgICAgIE1zLiBNb2ZhbmcgTGkgKENUTywgQ2hpbmEgTW9iaWxlKQ0KDQoxNjo1MC0xNzozMCAg U3RhdHVzIGFuZCBkaXJlY3Rpb24gb2YgdGhlIFNJUCByZWxhdGVkIHdvcmtpbmcgZ3JvdXBzIGlu IHRoZSBJRVRGDQogICAgICAgICAgICAgTXIuIEF2c2hhbG9tIEhvdXJpIChTSVAgQXJ0ZWNoaXR1 cmUsIElCTSkNCg0KMTc6MzAtMTg6MTAgIE1NRCBhbmQgVm9JUCBPdmVydmlldw0KICAgICAgICAg ICAgIERyLiBZYW4gTGkgKFF1YWxjb21tKQ0KDQo8QmFucXVldD4gICAgMTg6MjAtMjA6MDANCg0K RmViLiAyOHRoDQoNCu+8nE1vcm5pbmcgU2Vzc2lvbu+8nuOAgOOAgOOAgOOAgENoYWlyOiBQcm9m LlppcWlhbmcgSG91IChDaGllZiBBZHZpc29yIG9mIENoaW5hIE5ldGNvbSkNCg0KIDk6MDAtIDk6 NDAgICBOZXcgVHJlbmQgb2YgTmV4dCBHZW5lcmF0aW9uIEludGVybmV0IG9mIENoaW5hIFRlbGVj b20uDQogICAgICAgICAgICAgIE1yLiBMZXBpbmcgV2VpICAoQ1RPLCBDaGluYSBUZWxlY29tKQ0K DQogOTo0MC0xMDoyMCAgIEZpeGVkIGFuZCBNb2JpbGUgQ29udmVyZ2VuY2UNCiAgICAgICAgICAg ICAgRHIuIEh1aSBEZW5nICAoSGl0YWNoaSkNCg0KMTA6MjAtMTA6MzAgICDvvJwgIENvZmZlZSBC cmVhayDvvJ4NCg0KMTA6MzAtMTE6MTAgICBNb2JpbGUgSVB2NiBpbiBJRVRGDQogICAgICAgICAg ICAgIERyLiBHb3BhbCBEb21tZXR5IChDby1DaGFpciBvZiBNSVA2IFdHIGluIElFVEYsIENpc2Nv KSANCg0KMTE6MTAtMTE6NTAgICBFdm9sdXRpb24gb2YgVHJhbnNwb3J0IGZvciBBY2Nlc3MgYW5k IENvcmUgTmV0d29ya3MgaW4gV2lNQVgNCiAgICAgICAgICAgICAgTXMuIFl1ZWh1YSBDaGVuLCBN ci5QaGlsbGlwIEJhcmJlciAoSHVhd2VpLCBDaGFpciBvZiBOZXRNQU4gb2YgSUVFRSA4MDIuMTYp DQoNCjExOjUwLTEyOjMwICAgSW52aXRlZCBzcGVha2VyIGZvcm0gTlNGIG9mIFVTQQ0KICAgICAg ICAgICAgICBNci4gV2VpIFpoYW8sIE5TRiBVU0EgKFd1KQ0KDQoxMjozMC0xNDowMCAg77ycIEx1 bmNoIO+8ng0KDQrvvJxBZnRlcm5vb24gU2Vzc2lvbu+8niAgRGlyZWN0b3Igb2YgQ0VSTkVULCBQ cm9mLiBKaWFucGluZyBXdQ0KDQogUGFuZWwgZGlzY3Vzc2lvbiBhbmQgVmlzaXQgQ0VSTkVUMg0K ICBJbnZpdGVkIFBlb3BsZTogTlNGLCBFcmljc3NvbiwgSHVhd2VpLCBJQk0sIERvY29tbywgQ2lz Y28sIEx1Y2VudCwgTXVsdGljYXN0LCBRdWFsY29tbSwgSGl0YWNoaSwgQ2hpbmEgU2lkZS4NCiAg VG9waWNzOiBOZXcgdHJlbmQgb2YgbmV4dCBnZW5lcmF0aW9uIEludGVybmV0DQoNCkNsb3Npbmcg QWRkcmVzcw0KDQogDQoNCg== Disclaimer: The contents of this e-mail, and its attachments, if any, are confidential and may be protected by law against any unauthorized use. If you have received this e-mail by mistake or have reason to believe that you are not the intended recipient, please notify the sender by reply e-mail as soon as possible and delete it from your computer system immediately thereafter. If you are not the intended recipient, you must not copy this e-mail or attachment or disclose the contents to any other person. While we have made every effort to keep our network virus free, we take no responsibility for any computer virus which might be transferred by way of this e-mail. --===============1544249978== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1544249978==-- From sip-bounces@ietf.org Thu Feb 23 09:52:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCHnh-0002UF-8e; Thu, 23 Feb 2006 09:50:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCHnf-0002Sz-VV for sip@ietf.org; Thu, 23 Feb 2006 09:50:35 -0500 Received: from lhrga01-in.huawei.com ([57.66.76.5] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCHnf-0005J8-GP for sip@ietf.org; Thu, 23 Feb 2006 09:50:35 -0500 Received: from huawei.com ([172.24.2.9]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV50002D9JZAS@lhrga01-in.huawei.com> for sip@ietf.org; Thu, 23 Feb 2006 14:28:47 +0000 (GMT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV5007HMAL6P1@szxga03-in.huawei.com> for sip@ietf.org; Thu, 23 Feb 2006 22:51:07 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV500G1JAL63F@szxga03-in.huawei.com> for sip@ietf.org; Thu, 23 Feb 2006 22:51:06 +0800 (CST) Received: from manjunath ([10.18.5.133]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IV500C89B04PS@szxml01-in.huawei.com>; Thu, 23 Feb 2006 23:00:05 +0800 (CST) Date: Thu, 23 Feb 2006 20:14:00 +0530 From: Manjunath Warad Subject: RE: [Sip] Query regarding Cancel In-reply-to: <22F058C3ED9D784E90CE473F2A9847F042950B@in-exchange> To: 'Atul kumar Jha' , 'Sudhir Kumar Reddy' , sip@ietf.org Message-id: <009801c63887$96129b20$8505120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: manjunathwarad@huawei.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1179700234==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1179700234== Content-type: multipart/alternative; boundary="Boundary_(ID_FnpAIk8iF6rmIjfHA8+lAQ)" This is a multi-part message in MIME format. --Boundary_(ID_FnpAIk8iF6rmIjfHA8+lAQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Since CANCEL is hop-by-hop request, it can be sent after receiving 100 Trying also. If a proxy responds with 100 Trying, UAC can send CANCEL, but proxy will wait till it gets some provisional response from the next hop, before it forwards the CANCEL. So CANCEL can be sent after receiving 100 Trying response also. Regards, Manju -----Original Message----- From: Atul kumar Jha [mailto:atulkumar.jha@ccpu.com] Sent: Thursday, February 23, 2006 8:02 PM To: Sudhir Kumar Reddy; sip@ietf.org Subject: RE: [Sip] Query regarding Cancel Hi Sudhir, CANCEL can be sent after receiving provisional response (not 100 Trying). As 100 trying can be sent by a Proxy. So, it should wait for provisional response to come. For 487, RFC does not mandate the Record-Route header to be copied. It is not needed because ACK in this case will follow the same Route as the INVITE. Regards, Atul _____ From: Sudhir Kumar Reddy [mailto:t.sudhirkumar@gmail.com] Sent: Thursday, February 23, 2006 4:45 PM To: sip@ietf.org Subject: [Sip] Query regarding Cancel Hi All, Apologies if this has been discussed earlier Can we send Cancel request immediately after getting a 100 Trying response to the INVITE? The other question is when we receive a INVITE with Record-Route header, MUST we include this record-Route in the 487(to a CANCEL) response ? thanks in advance best regards, Sudhir --Boundary_(ID_FnpAIk8iF6rmIjfHA8+lAQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Message
Hi,
    Since CANCEL is hop-by-hop request, it can be sent after receiving 100 Trying also. If a proxy responds with 100 Trying, UAC can send CANCEL, but proxy will wait till it gets some provisional response from the next hop, before it forwards the CANCEL.
    So CANCEL can be sent after receiving 100 Trying response also.
 
Regards,
Manju
-----Original Message-----
From: Atul kumar Jha [mailto:atulkumar.jha@ccpu.com]
Sent: Thursday, February 23, 2006 8:02 PM
To: Sudhir Kumar Reddy; sip@ietf.org
Subject: RE: [Sip] Query regarding Cancel

Hi Sudhir,

 

CANCEL can be sent after receiving provisional response (not 100 Trying).

As 100 trying can be sent by a Proxy. So, it should wait for provisional response to come.  

 

For 487, RFC does not mandate the Record-Route header to be copied.

It is not needed because ACK in this case will follow the same Route as the INVITE.

 

Regards,

Atul

 

 

From: Sudhir Kumar Reddy [mailto:t.sudhirkumar@gmail.com]
Sent: Thursday, February 23, 2006 4:45 PM
To: sip@ietf.org
Subject: [Sip] Query regarding Cancel

 

Hi All,

 

Apologies if this has been discussed earlier

 

 Can we send Cancel request immediately after getting a 100 Trying response to the INVITE?

 

 The other question is when we receive a INVITE with Record-Route header, MUST we include this record-Route in the 487(to a CANCEL)

 response ?

 

thanks in advance

 

best regards,

Sudhir

--Boundary_(ID_FnpAIk8iF6rmIjfHA8+lAQ)-- --===============1179700234== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1179700234==-- From sip-bounces@ietf.org Thu Feb 23 10:20:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCIEe-0003hj-UY; Thu, 23 Feb 2006 10:18:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCIEd-0003g2-0X for sip@ietf.org; Thu, 23 Feb 2006 10:18:27 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCIEc-0006k6-Id for sip@ietf.org; Thu, 23 Feb 2006 10:18:26 -0500 Received: from huawei.com ([172.24.2.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV500AKYBH7FZ@usaga01-in.huawei.com> for sip@ietf.org; Thu, 23 Feb 2006 07:10:20 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV50036PC7F9W@szxga02-in.huawei.com> for sip@ietf.org; Thu, 23 Feb 2006 23:26:03 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV500IVAC7FYP@szxga02-in.huawei.com> for sip@ietf.org; Thu, 23 Feb 2006 23:26:03 +0800 (CST) Received: from manjunath ([10.18.5.133]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IV500KBBC7622@szxml02-in.huawei.com>; Thu, 23 Feb 2006 23:25:56 +0800 (CST) Date: Thu, 23 Feb 2006 20:43:25 +0530 From: Manjunath Warad Subject: FW: [Sip] Query regarding Cancel To: atulkumar.jha@ccpu.com, t.sudhirkumar@gmail.com, sip@ietf.org Message-id: <009f01c6388b$b23a1b80$8505120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: manjunathwarad@huawei.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1356739945==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1356739945== Content-type: multipart/alternative; boundary="Boundary_(ID_yTHmsoqSZWxymWbXa9RLbQ)" This is a multi-part message in MIME format. --Boundary_(ID_yTHmsoqSZWxymWbXa9RLbQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Since CANCEL is hop-by-hop request, it can be sent after receiving 100 Trying also. If a proxy responds with 100 Trying, UAC can send CANCEL, but proxy will wait till it gets some provisional response from the next hop, before it forwards the CANCEL. So CANCEL can be sent after receiving 100 Trying response also. Regards, Manju -----Original Message----- From: Atul kumar Jha [mailto:atulkumar.jha@ccpu.com] Sent: Thursday, February 23, 2006 8:02 PM To: Sudhir Kumar Reddy; sip@ietf.org Subject: RE: [Sip] Query regarding Cancel Hi Sudhir, CANCEL can be sent after receiving provisional response (not 100 Trying). As 100 trying can be sent by a Proxy. So, it should wait for provisional response to come. For 487, RFC does not mandate the Record-Route header to be copied. It is not needed because ACK in this case will follow the same Route as the INVITE. Regards, Atul _____ From: Sudhir Kumar Reddy [mailto:t.sudhirkumar@gmail.com] Sent: Thursday, February 23, 2006 4:45 PM To: sip@ietf.org Subject: [Sip] Query regarding Cancel Hi All, Apologies if this has been discussed earlier Can we send Cancel request immediately after getting a 100 Trying response to the INVITE? The other question is when we receive a INVITE with Record-Route header, MUST we include this record-Route in the 487(to a CANCEL) response ? thanks in advance best regards, Sudhir --Boundary_(ID_yTHmsoqSZWxymWbXa9RLbQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Message
Hi,
    Since CANCEL is hop-by-hop request, it can be sent after receiving 100 Trying also. If a proxy responds with 100 Trying, UAC can send CANCEL, but proxy will wait till it gets some provisional response from the next hop, before it forwards the CANCEL.
    So CANCEL can be sent after receiving 100 Trying response also.
 
Regards,
Manju
-----Original Message-----
From: Atul kumar Jha [mailto:atulkumar.jha@ccpu.com]
Sent: Thursday, February 23, 2006 8:02 PM
To: Sudhir Kumar Reddy; sip@ietf.org
Subject: RE: [Sip] Query regarding Cancel

Hi Sudhir,

 

CANCEL can be sent after receiving provisional response (not 100 Trying).

As 100 trying can be sent by a Proxy. So, it should wait for provisional response to come.  

 

For 487, RFC does not mandate the Record-Route header to be copied.

It is not needed because ACK in this case will follow the same Route as the INVITE.

 

Regards,

Atul

 

 

From: Sudhir Kumar Reddy [mailto:t.sudhirkumar@gmail.com]
Sent: Thursday, February 23, 2006 4:45 PM
To: sip@ietf.org
Subject: [Sip] Query regarding Cancel

 

Hi All,

 

Apologies if this has been discussed earlier

 

 Can we send Cancel request immediately after getting a 100 Trying response to the INVITE?

 

 The other question is when we receive a INVITE with Record-Route header, MUST we include this record-Route in the 487(to a CANCEL)

 response ?

 

thanks in advance

 

best regards,

Sudhir

--Boundary_(ID_yTHmsoqSZWxymWbXa9RLbQ)-- --===============1356739945== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1356739945==-- From sip-bounces@ietf.org Thu Feb 23 11:34:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCJOV-0003Oy-Ch; Thu, 23 Feb 2006 11:32:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCJOT-0003O5-KI for sip@ietf.org; Thu, 23 Feb 2006 11:32:41 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCJOT-0004KV-23 for sip@ietf.org; Thu, 23 Feb 2006 11:32:41 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 1C19C194480 for ; Thu, 23 Feb 2006 17:32:40 +0100 (CET) Received: from [192.168.1.45] ([192.168.1.45]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Feb 2006 17:31:12 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Thu, 23 Feb 2006 17:32:56 +0100 To: "Gary Gan" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 23 Feb 2006 16:31:12.0453 (UTC) FILETIME=[8F262750:01C63896] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: 'Cullen Jennings' , sip@ietf.org, 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org what about it? The closest I see in the diagram in section 3.4. I still don't see why the UA needs to do anything about that. The NAT is between the outbound proxy and registrar. That the outbound proxy problem. Why would the UA be sending keepalive messages to keep the NAT binding open? Hisham On Feb 23, 2006, at 3:08 PM, Gary Gan wrote: > Take a look at: draft-ietf-sip-outbound-01 > > Gary Gan > >> The first question is why would the UA be sending STUN requests. As >> far >> as that UA is concerned, there is no NAT (the UA can do a basic >> RFC1918). Note that for RTP, the situation a little different. But >> that's not what were are talking about here. > > Hisham > > On Feb 22, 2006, at 9:05 PM, Gary Gan wrote: > >> [UA] ---> [Outbound Proxy] -->|N| -->[SIP Registrar server$B!!!!!!(B] >> | |A| | +$B!!!!!!!!!!!!!!!!!!!!!!!!(B| >> |------------STUN?--------->[T| -->[Multiplexed STUN server$B!!(B] >> >> I just wonder how the STUN solution works with the above scenario. >> With the >> outbound proxy in the different IP behind the NAT, the STUN keep-alive >> would >> not be valid since the NAT binding is between the outbound proxy and >> the SIP >> server. >> >> Gary Gan >> Clique Communications, LLC >> >> >> -----Original Message----- >> From: Gary Gan [mailto:ggan@cliquecom.com] >> Sent: Wednesday, February 22, 2006 2:25 PM >> To: 'Dean Willis'; 'Cullen Jennings' >> Cc: sip@ietf.org; 'Francois Audet'; 'Chris Boulton'; 'Michael >> Procter'; >> fwmiller@cornfed.com; 'John Elwell' >> Subject: RE: [Sip] Outbound and STUN Keep Alive >> >>> Does the server that you're sending CRLF to just continue to echo >>> CRLF back at you? Or does it have some way of recognizing that it's >>> suddenly getting CRLF echo requests from a partner from which it has >>> no current registration and stop echoing CRLF at you? >> >>> -- >>> Dean >> >> Depending on the server implementation, but either way has problems. >> If the >> echo comes back from the new binding, the UA would not know the NAT >> has >> rebooted. That's what the STUN multiplexing tries to resolve, which >> actually >> handles the binding comparison on the client side. If the server >> checks for >> the client bindings, then the server needs to maintain the binding >> states of >> all UA, either in memory or database. It uses server resource. I don't >> think >> it scales. >> >> Gary Gan >> Clique Communications >> >> >> _______________________________________________ >> 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 sip-bounces@ietf.org Thu Feb 23 11:35:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCJPK-0004C2-2G; Thu, 23 Feb 2006 11:33:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCJPH-000491-Sr for sip@ietf.org; Thu, 23 Feb 2006 11:33:31 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCJPH-0004Mx-QK for sip@ietf.org; Thu, 23 Feb 2006 11:33:31 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FCJPF-0001ft-SF for sip@ietf.org; Thu, 23 Feb 2006 11:33:31 -0500 Received: from [131.161.248.90] (open-131-161-248-90.cliq.com [131.161.248.90]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k1NGSLF19217; Thu, 23 Feb 2006 08:28:21 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Thu, 23 Feb 2006 08:28:20 -0800 To: Hisham Khartabil X-Mailer: Apple Mail (2.623) X-Spam-Score: -2.6 (--) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: sip@ietf.org, 'Cullen Jennings' , 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Gary, On Feb 23, 2006, at 1:38, Hisham Khartabil wrote: > The first question is why would the UA be sending STUN requests. As > far as that UA is concerned, there is no NAT (the UA can do a basic > RFC1918). Note that for RTP, the situation a little different. But > that's not what were are talking about here. > > Hisham > > On Feb 22, 2006, at 9:05 PM, Gary Gan wrote: > >> [UA] ---> [Outbound Proxy] -->|N| -->[SIP Registrar server$B!!!!!!(B] >> | |A| | +$B!!!!!!!!!!!!!!!!!!!!!!!!(B| >> |------------STUN?--------->[T| -->[Multiplexed STUN server$B!!(B] >> >> I just wonder how the STUN solution works with the above scenario. >> With the >> outbound proxy in the different IP behind the NAT, the STUN >> keep-alive would >> not be valid since the NAT binding is between the outbound proxy and >> the SIP >> server. The UA is supposed to send STUN requests or SIP requests over a flow to the outbound proxy. The outbound proxy responds directly to the STUN request and treats the SIP request normally according to the Route headers and Request-URI. So the outbound proxy will forward most SIP traffic on to the registrar/proxy. The UA processes the STUN responses by checking if the mapped address changes from the one used on the first STUN query over this flow. If so, the NAT binding has changed (probably due to the NAT rebooting). Hope this helps. If you can come up with a few sentences that explains this better, please propose it to the authors. thanks, -rohan >> Gary Gan >> Clique Communications, LLC >> >> >> -----Original Message----- >> From: Gary Gan [mailto:ggan@cliquecom.com] >> Sent: Wednesday, February 22, 2006 2:25 PM >> To: 'Dean Willis'; 'Cullen Jennings' >> Cc: sip@ietf.org; 'Francois Audet'; 'Chris Boulton'; 'Michael >> Procter'; >> fwmiller@cornfed.com; 'John Elwell' >> Subject: RE: [Sip] Outbound and STUN Keep Alive >> >>> Does the server that you're sending CRLF to just continue to echo >>> CRLF back at you? Or does it have some way of recognizing that it's >>> suddenly getting CRLF echo requests from a partner from which it has >>> no current registration and stop echoing CRLF at you? >> >>> -- >>> Dean >> >> Depending on the server implementation, but either way has problems. >> If the >> echo comes back from the new binding, the UA would not know the NAT >> has >> rebooted. That's what the STUN multiplexing tries to resolve, which >> actually >> handles the binding comparison on the client side. If the server >> checks for >> the client bindings, then the server needs to maintain the binding >> states of >> all UA, either in memory or database. It uses server resource. I >> don't think >> it scales. >> >> Gary Gan >> Clique Communications >> >> >> _______________________________________________ >> 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 sip-bounces@ietf.org Thu Feb 23 11:42:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCJWD-0000hm-Kt; Thu, 23 Feb 2006 11:40:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCJWB-0000hb-S3 for sip@ietf.org; Thu, 23 Feb 2006 11:40:39 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCJWB-0004Zv-Ee for sip@ietf.org; Thu, 23 Feb 2006 11:40:39 -0500 Received: from [131.161.248.90] (open-131-161-248-90.cliq.com [131.161.248.90]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k1NGeXF19305; Thu, 23 Feb 2006 08:40:33 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Thu, 23 Feb 2006 08:40:34 -0800 To: Hisham Khartabil X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: sip@ietf.org, 'Cullen Jennings' , 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Hisham, Perhaps I wasn't clear enough in my earlier message to Gary. STUN messages sent by the UA never get past the outbound proxy, so they will not help discover any change in connectivity between the outbound proxy and its next hop, nor will any other part of the outbound spec deal with connectivity between the outbound proxy and its next hop. Dealing with NATs between proxies was never a requirement of this particular draft. thanks, -rohan On Feb 23, 2006, at 8:32, Hisham Khartabil wrote: > what about it? The closest I see in the diagram in section 3.4. I > still don't see why the UA needs to do anything about that. The NAT is > between the outbound proxy and registrar. That the outbound proxy > problem. Why would the UA be sending keepalive messages to keep the > NAT binding open? > > Hisham > > On Feb 23, 2006, at 3:08 PM, Gary Gan wrote: > >> Take a look at: draft-ietf-sip-outbound-01 >> >> Gary Gan >> >>> The first question is why would the UA be sending STUN requests. As >>> far >>> as that UA is concerned, there is no NAT (the UA can do a basic >>> RFC1918). Note that for RTP, the situation a little different. But >>> that's not what were are talking about here. >> >> Hisham >> >> On Feb 22, 2006, at 9:05 PM, Gary Gan wrote: >> >>> [UA] ---> [Outbound Proxy] -->|N| -->[SIP Registrar server$B!!!!!!(B] >>> | |A| | +$B!!!!!!!!!!!!!!!!!!!!!!!!(B| >>> |------------STUN?--------->[T| -->[Multiplexed STUN server$B!!(B] >>> >>> I just wonder how the STUN solution works with the above scenario. >>> With the >>> outbound proxy in the different IP behind the NAT, the STUN >>> keep-alive >>> would >>> not be valid since the NAT binding is between the outbound proxy and >>> the SIP >>> server. >>> >>> Gary Gan >>> Clique Communications, LLC >>> >>> >>> -----Original Message----- >>> From: Gary Gan [mailto:ggan@cliquecom.com] >>> Sent: Wednesday, February 22, 2006 2:25 PM >>> To: 'Dean Willis'; 'Cullen Jennings' >>> Cc: sip@ietf.org; 'Francois Audet'; 'Chris Boulton'; 'Michael >>> Procter'; >>> fwmiller@cornfed.com; 'John Elwell' >>> Subject: RE: [Sip] Outbound and STUN Keep Alive >>> >>>> Does the server that you're sending CRLF to just continue to echo >>>> CRLF back at you? Or does it have some way of recognizing that it's >>>> suddenly getting CRLF echo requests from a partner from which it has >>>> no current registration and stop echoing CRLF at you? >>> >>>> -- >>>> Dean >>> >>> Depending on the server implementation, but either way has problems. >>> If the >>> echo comes back from the new binding, the UA would not know the NAT >>> has >>> rebooted. That's what the STUN multiplexing tries to resolve, which >>> actually >>> handles the binding comparison on the client side. If the server >>> checks for >>> the client bindings, then the server needs to maintain the binding >>> states of >>> all UA, either in memory or database. It uses server resource. I >>> don't >>> think >>> it scales. >>> >>> Gary Gan >>> Clique Communications >>> >>> >>> _______________________________________________ >>> 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 sip-bounces@ietf.org Thu Feb 23 12:25:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCKBb-00040d-Gd; Thu, 23 Feb 2006 12:23:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCKBa-000409-Hl for sip@ietf.org; Thu, 23 Feb 2006 12:23:26 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCKBZ-00067b-SS for sip@ietf.org; Thu, 23 Feb 2006 12:23:26 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id B9FED19447E for ; Thu, 23 Feb 2006 18:23:24 +0100 (CET) Received: from [192.168.1.45] ([192.168.1.45]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Feb 2006 18:21:57 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: <6bfd47eeddf80685f723b25993305e8b@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Thu, 23 Feb 2006 18:23:43 +0100 To: Rohan Mahy X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 23 Feb 2006 17:21:57.0055 (UTC) FILETIME=[A5DF8CF0:01C6389D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: 'Cullen Jennings' , sip@ietf.org, 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Rohan, That's what I'm trying to explain to Gary. BTW, I never got that reply. Did u send it to the list? Hisham On Feb 23, 2006, at 5:40 PM, Rohan Mahy wrote: > Hi Hisham, > > Perhaps I wasn't clear enough in my earlier message to Gary. STUN > messages sent by the UA never get past the outbound proxy, so they > will not help discover any change in connectivity between the outbound > proxy and its next hop, nor will any other part of the outbound spec > deal with connectivity between the outbound proxy and its next hop. > Dealing with NATs between proxies was never a requirement of this > particular draft. > > thanks, > -rohan > > > > On Feb 23, 2006, at 8:32, Hisham Khartabil wrote: >> what about it? The closest I see in the diagram in section 3.4. I >> still don't see why the UA needs to do anything about that. The NAT >> is between the outbound proxy and registrar. That the outbound proxy >> problem. Why would the UA be sending keepalive messages to keep the >> NAT binding open? >> >> Hisham >> >> On Feb 23, 2006, at 3:08 PM, Gary Gan wrote: >> >>> Take a look at: draft-ietf-sip-outbound-01 >>> >>> Gary Gan >>> >>>> The first question is why would the UA be sending STUN requests. As >>>> far >>>> as that UA is concerned, there is no NAT (the UA can do a basic >>>> RFC1918). Note that for RTP, the situation a little different. But >>>> that's not what were are talking about here. >>> >>> Hisham >>> >>> On Feb 22, 2006, at 9:05 PM, Gary Gan wrote: >>> >>>> [UA] ---> [Outbound Proxy] -->|N| -->[SIP Registrar server$B!!!!!!(B] >>>> | |A| | +$B!!!!!!!!!!!!!!!!!!!!!!!!(B| >>>> |------------STUN?--------->[T| -->[Multiplexed STUN server$B!!(B] >>>> >>>> I just wonder how the STUN solution works with the above scenario. >>>> With the >>>> outbound proxy in the different IP behind the NAT, the STUN >>>> keep-alive >>>> would >>>> not be valid since the NAT binding is between the outbound proxy and >>>> the SIP >>>> server. >>>> >>>> Gary Gan >>>> Clique Communications, LLC >>>> >>>> >>>> -----Original Message----- >>>> From: Gary Gan [mailto:ggan@cliquecom.com] >>>> Sent: Wednesday, February 22, 2006 2:25 PM >>>> To: 'Dean Willis'; 'Cullen Jennings' >>>> Cc: sip@ietf.org; 'Francois Audet'; 'Chris Boulton'; 'Michael >>>> Procter'; >>>> fwmiller@cornfed.com; 'John Elwell' >>>> Subject: RE: [Sip] Outbound and STUN Keep Alive >>>> >>>>> Does the server that you're sending CRLF to just continue to echo >>>>> CRLF back at you? Or does it have some way of recognizing that it's >>>>> suddenly getting CRLF echo requests from a partner from which it >>>>> has >>>>> no current registration and stop echoing CRLF at you? >>>> >>>>> -- >>>>> Dean >>>> >>>> Depending on the server implementation, but either way has problems. >>>> If the >>>> echo comes back from the new binding, the UA would not know the NAT >>>> has >>>> rebooted. That's what the STUN multiplexing tries to resolve, which >>>> actually >>>> handles the binding comparison on the client side. If the server >>>> checks for >>>> the client bindings, then the server needs to maintain the binding >>>> states of >>>> all UA, either in memory or database. It uses server resource. I >>>> don't >>>> think >>>> it scales. >>>> >>>> Gary Gan >>>> Clique Communications >>>> >>>> >>>> _______________________________________________ >>>> 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 sip-bounces@ietf.org Thu Feb 23 13:11:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCKtp-00007w-Ox; Thu, 23 Feb 2006 13:09:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCKtn-00007f-O9 for sip@ietf.org; Thu, 23 Feb 2006 13:09:07 -0500 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCKtn-0007JR-BO for sip@ietf.org; Thu, 23 Feb 2006 13:09:07 -0500 Received: (qmail 20362 invoked by uid 0); 23 Feb 2006 18:09:03 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 23 Feb 2006 18:09:03 -0000 Message-ID: <001601c638a4$3ab6fa60$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Rohan Mahy" , "SIP WG" References: <26fbf302818a0cbbe4558f83410f081c@ekabal.com> Subject: Re: [Sip] WGLC for draft-ietf-sip-answermode-00 Date: Thu, 23 Feb 2006 19:09:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Rohan, Two remarks: 1. I would propose to change the ABNF to allow for a list of generic-params, as is common for most SIP headers The current version limits the extensibility to 1 parameter (name=value) which would replace "Manual" or "Auto", and possibly a list of tokens (which would be interpreted as flag parameters) How about the following: Answer-Mode = "Answer-Mode" HCOLON answer-mode *(SEMI answer-mode-param) Priv-Answer-Mode = "Priv-Answer-Mode" HCOLON answer-mode *(SEMI answer-mode-param) answer-mode = "Manual" / "Auto" / token answer-mode-param = "require" / generic-param2. (NIT) Example section 6.2, "Requires" header should be "Require" Regards, jeroen ----- Original Message ----- From: "Rohan Mahy" To: "SIP WG" Cc: "Dean Willis" Sent: Thursday, February 23, 2006 4:32 AM Subject: [Sip] WGLC for draft-ietf-sip-answermode-00 > Hi, > > I'd like to start a 3-week working group last call for: > > draft-ietf-sip-answermode-00.txt > > This WGLC will complete on March 15th > > thanks, > -rohan > > Rohan Mahy > co-chair SIP WG > > > _______________________________________________ > 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 sip-bounces@ietf.org Thu Feb 23 13:25:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCL7Y-0001xL-NL; Thu, 23 Feb 2006 13:23:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCL7W-0001x7-Uk for sip@ietf.org; Thu, 23 Feb 2006 13:23:18 -0500 Received: from [66.155.254.250] (helo=isdmail1.inovsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCL7W-0007jr-Ka for sip@ietf.org; Thu, 23 Feb 2006 13:23:18 -0500 Received: from greatwall ([12.181.128.3]) by isdmail1.inovsys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 23 Feb 2006 13:23:18 -0500 From: "Gary Gan" To: "'Hisham Khartabil'" , "'Rohan Mahy'" Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Thu, 23 Feb 2006 13:23:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <6bfd47eeddf80685f723b25993305e8b@telio.no> thread-index: AcY4nd+oa0495B0PTrCk+aK2CQ245AACA0pQ Message-ID: X-OriginalArrivalTime: 23 Feb 2006 18:23:18.0358 (UTC) FILETIME=[3819CF60:01C638A6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: 'Cullen Jennings' , sip@ietf.org, 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org That is also my doubt. To simply use STUN multiplexing SIP port for keepalive may not work. Gary Gan > That's what I'm trying to explain to Gary. > > BTW, I never got that reply. Did u send it to the list? > > Hisham > On Feb 23, 2006, at 5:40 PM, Rohan Mahy wrote: > Hi Hisham, > > Perhaps I wasn't clear enough in my earlier message to Gary. STUN > messages sent by the UA never get past the outbound proxy, so they > will not help discover any change in connectivity between the outbound > proxy and its next hop, nor will any other part of the outbound spec > deal with connectivity between the outbound proxy and its next hop. > Dealing with NATs between proxies was never a requirement of this > particular draft. > > thanks, > -rohan > > > > On Feb 23, 2006, at 8:32, Hisham Khartabil wrote: >> what about it? The closest I see in the diagram in section 3.4. I >> still don't see why the UA needs to do anything about that. The NAT >> is between the outbound proxy and registrar. That the outbound proxy >> problem. Why would the UA be sending keepalive messages to keep the >> NAT binding open? >> >> Hisham >> >> On Feb 23, 2006, at 3:08 PM, Gary Gan wrote: >> >>> Take a look at: draft-ietf-sip-outbound-01 >>> >>> Gary Gan >>> >>>> The first question is why would the UA be sending STUN requests. As >>>> far >>>> as that UA is concerned, there is no NAT (the UA can do a basic >>>> RFC1918). Note that for RTP, the situation a little different. But >>>> that's not what were are talking about here. >>> >>> Hisham >>> >>> On Feb 22, 2006, at 9:05 PM, Gary Gan wrote: >>> >>>> [UA] ---> [Outbound Proxy] -->|N| -->[SIP Registrar server$B!!!!!!(B] >>>> | |A| | +$B!!!!!!!!!!!!!!!!!!!!!!!!(B| >>>> |------------STUN?--------->[T| -->[Multiplexed STUN server$B!!(B] >>>> >>>> I just wonder how the STUN solution works with the above scenario. >>>> With the >>>> outbound proxy in the different IP behind the NAT, the STUN >>>> keep-alive >>>> would >>>> not be valid since the NAT binding is between the outbound proxy and >>>> the SIP >>>> server. >>>> >>>> Gary Gan >>>> Clique Communications, LLC >>>> >>>> >>>> -----Original Message----- >>>> From: Gary Gan [mailto:ggan@cliquecom.com] >>>> Sent: Wednesday, February 22, 2006 2:25 PM >>>> To: 'Dean Willis'; 'Cullen Jennings' >>>> Cc: sip@ietf.org; 'Francois Audet'; 'Chris Boulton'; 'Michael >>>> Procter'; >>>> fwmiller@cornfed.com; 'John Elwell' >>>> Subject: RE: [Sip] Outbound and STUN Keep Alive >>>> >>>>> Does the server that you're sending CRLF to just continue to echo >>>>> CRLF back at you? Or does it have some way of recognizing that it's >>>>> suddenly getting CRLF echo requests from a partner from which it >>>>> has >>>>> no current registration and stop echoing CRLF at you? >>>> >>>>> -- >>>>> Dean >>>> >>>> Depending on the server implementation, but either way has problems. >>>> If the >>>> echo comes back from the new binding, the UA would not know the NAT >>>> has >>>> rebooted. That's what the STUN multiplexing tries to resolve, which >>>> actually >>>> handles the binding comparison on the client side. If the server >>>> checks for >>>> the client bindings, then the server needs to maintain the binding >>>> states of >>>> all UA, either in memory or database. It uses server resource. I >>>> don't >>>> think >>>> it scales. >>>> >>>> Gary Gan >>>> Clique Communications >>>> >>>> >>>> _______________________________________________ >>>> 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 sip-bounces@ietf.org Thu Feb 23 16:19:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCNqD-0004LT-D9; Thu, 23 Feb 2006 16:17:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCNqC-0004KD-JT for sip@ietf.org; Thu, 23 Feb 2006 16:17:36 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCNqC-0005if-AA for sip@ietf.org; Thu, 23 Feb 2006 16:17:36 -0500 Received: from deawilli-t42.cisco.com (shankarg-w2k.cisco.com [64.101.149.220] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1NLHbBs023444 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 23 Feb 2006 15:17:38 -0600 From: Dean Willis To: Rohan Mahy Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Thu, 23 Feb 2006 15:16:30 -0600 User-Agent: KMail/1.8.3 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602231516.30350.dean.willis@softarmor.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sip@ietf.org, 'Cullen Jennings' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Thursday 23 February 2006 10:40, Rohan Mahy wrote: > Hi Hisham, > > Perhaps I wasn't clear enough in my earlier message to Gary. STUN > messages sent by the UA never get past the outbound proxy, so they will > not help discover any change in connectivity between the outbound proxy > and its next hop, nor will any other part of the outbound spec deal > with connectivity between the outbound proxy and its next hop. Dealing > with NATs between proxies was never a requirement of this particular > draft. I think you guys are missing Gary's use case. He's postulating an entirely different NAT problem, where the NAT is between the outbound proxy and the real world, rather than between the UA and its outbound proxy. This just isn't a use case that's been in scope for general discussion so far. I'm not sure it needs to be -- it's a pretty freaky use case. Perhaps we might seee something like this in a small office, where there's an internal proxy-registrar that serves communications inside the firewall, but that then relies on an external proxy for routing calls outside the enterprise. This would require something like proxy-proxy connection reuse, or a port-forward rule on the firewall NAT, etc. to handle inbound calls. In this case, sending STUN requests (multiplexed or otherwise) from the UA to the outbound proxy accomplishes nothing useful, or at least nothing usefu lwith respect to NAT traversal. Instead, we would need the "outbound proxy" to itself implement a version of the "outbound draft" to the next-hop proxy, because there is a NAT binding between the user's outbound proxy and the user's outbound proxy's outbound proxy. Thus, we might see STUN used inter-proxy. The UA COULD also use STUN independently to a STUN server outside the NAT to discover the NAT's behavior, and possibly discover the UA's external address, which it would use in the construction of SDP. -- 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 sip-bounces@ietf.org Thu Feb 23 16:32:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCO30-0006aF-6Z; Thu, 23 Feb 2006 16:30:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCO2z-0006ZW-A0 for sip@ietf.org; Thu, 23 Feb 2006 16:30:49 -0500 Received: from firewall.objectworld.com ([72.1.207.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCO2w-00064o-Tx for sip@ietf.org; Thu, 23 Feb 2006 16:30:49 -0500 Received: from photon.objectworld.com (photon.objectworld.com [192.168.1.2]) by firewall.objectworld.com (8.12.11/8.12.11) with ESMTP id k1NLUii6005030 for ; Thu, 23 Feb 2006 16:30:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Thu, 23 Feb 2006 16:30:43 -0500 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C5062FFE@photon.objectworld.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcY4vqc/z4GWRtDlQ9maz1ZsCZw8BwAAMr3g From: "Michael Slavitch" To: "Dean Willis" , "Rohan Mahy" X-Spam-Score: 0.00 () [Tag at 15.00] X-CanItPRO-Stream: outgoing Content-Disposition: inline X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.1.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: sip@ietf.org, Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is very real world. Internal SIP server behind firewall, SIP/PSTN=0A= proxy in the public internet or Enterprise registrar in the public=0A= internet. Most common implementation for highly distributed companies=0A= that have no backbone, such as franchise operations. Common common real=0A= world stuff.=0A= =0A= Given that SIP proxies can be highly distributed and SIP is not=0A= monolithic I can't see why this is freaky at all. In fact this has=0A= massive benefits in areas such as security and redundancy.=0A= =0A= This is to be expected in implementation.=0A= =0A= Many businesses don't let you touch their NAT, and the proxy must be=0A= behind the NAT router.=20=0A= =0A= Something like this shall address it.=0A= =0A= M=0A= =0A= =0A= =20=0A= =20=0A= It is amazing what you can accomplish if you do not care who gets the=0A= credit.=20=0A= =20=0A= - Harry S Truman=0A= =0A= -----Original Message-----=0A= From: Dean Willis [mailto:dean.willis@softarmor.com]=20=0A= Sent: February 23, 2006 4:17 PM=0A= To: Rohan Mahy=0A= Cc: sip@ietf.org; 'Cullen Jennings'=0A= Subject: Re: [Sip] Outbound and STUN Keep Alive=0A= =0A= On Thursday 23 February 2006 10:40, Rohan Mahy wrote:=0A= > Hi Hisham,=0A= >=0A= > Perhaps I wasn't clear enough in my earlier message to Gary. STUN=20=0A= > messages sent by the UA never get past the outbound proxy, so they=20=0A= > will not help discover any change in connectivity between the outbound=0A= =0A= > proxy and its next hop, nor will any other part of the outbound spec=20= =0A= > deal with connectivity between the outbound proxy and its next hop.=20=20= =0A= > Dealing with NATs between proxies was never a requirement of this=20=0A= > particular draft.=0A= =0A= I think you guys are missing Gary's use case.=0A= =0A= He's postulating an entirely different NAT problem, where the NAT is=0A= between the outbound proxy and the real world, rather than between the=0A= UA and its outbound proxy.=0A= =0A= This just isn't a use case that's been in scope for general discussion=0A= so far.=20=0A= I'm not sure it needs to be -- it's a pretty freaky use case.=20=0A= =0A= Perhaps we might seee something like this in a small office, where=0A= there's an internal proxy-registrar that serves communications inside=0A= the firewall, but that then relies on an external proxy for routing=0A= calls outside the enterprise. This would require something like=0A= proxy-proxy connection reuse, or a port-forward rule on the firewall=0A= NAT, etc. to handle inbound calls.=0A= =0A= =0A= In this case, sending STUN requests (multiplexed or otherwise) from the=0A= UA to the outbound proxy accomplishes nothing useful, or at least=0A= nothing usefu lwith respect to NAT traversal.=20=0A= =0A= Instead, we would need the "outbound proxy" to itself implement a=0A= version of the "outbound draft" to the next-hop proxy, because there is=0A= a NAT binding between the user's outbound proxy and the user's outbound=0A= proxy's outbound proxy. Thus, we might see STUN used inter-proxy.=0A= =0A= The UA COULD also use STUN independently to a STUN server outside the=0A= NAT to discover the NAT's behavior, and possibly discover the UA's=0A= external address, which it would use in the construction of SDP.=0A= =0A= --=0A= Dean=0A= =0A= =20=0A= =0A= _______________________________________________=0A= Sip mailing list https://www1.ietf.org/mailman/listinfo/sip=0A= This list is for NEW development of the core SIP Protocol Use=0A= sip-implementors@cs.columbia.edu for questions on current sip Use=0A= sipping@ietf.org for new developments on the application of sip=0A= =0A= =0A= --=0A= =0A= =0A= -----------------------------------------------=0D=0A= =0D=0A= This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. =0D=0A= =0D=0A= Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp= .=20=0A= _______________________________________________ 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 sip-bounces@ietf.org Thu Feb 23 16:51:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCOKi-0003VT-T4; Thu, 23 Feb 2006 16:49:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCOKh-0003VL-4L for sip@ietf.org; Thu, 23 Feb 2006 16:49:07 -0500 Received: from firewall.objectworld.com ([72.1.207.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCOKg-0006hE-JK for sip@ietf.org; Thu, 23 Feb 2006 16:49:07 -0500 Received: from photon.objectworld.com (photon.objectworld.com [192.168.1.2]) by firewall.objectworld.com (8.12.11/8.12.11) with ESMTP id k1NLmvcj005391 for ; Thu, 23 Feb 2006 16:49:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Thu, 23 Feb 2006 16:48:57 -0500 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C5063000@photon.objectworld.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcY4vqc/z4GWRtDlQ9maz1ZsCZw8BwAAMr3gAABlTIA= From: "Michael Slavitch" To: "Michael Slavitch" , "Dean Willis" , "Rohan Mahy" X-Spam-Score: 0.00 () [Tag at 15.00] X-CanItPRO-Stream: outgoing Content-Disposition: inline X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.1.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: sip@ietf.org, Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org For example:=20=20=0A= =0A= Company A has ~1000 outlets. Loose franchise business. Cookie cutter IT.=0A= A real example, I'll leave the company unnamed.=0A= =0A= Each franchise has a network, behind a NAT. Each private network has an=0A= identical private network address, let's call it 172.17.x.x. This can=0A= not change. It will not change. Period.=0A= =0A= Each building is the same, each seat is the same, each server is the=0A= same, POS, payroll, out of the box. Literally.=0A= The infrastructure is quite literally packed in crates in a warehouse=0A= with the furniture.=0A= =0A= Common normal stuff in the "real world". The real world isn't the=0A= public internet. The real world is duplicate NAT.=0A= =0A= Now, this company has a web based server under SSL for operations on the=0A= public internet, this works fine for everything from procurement to=0A= payroll to sales figures to supply chain.=20=20=0A= =0A= It also has one or more registration proxy on the public internet, and=0A= has an agreement with one or more PSTN providers based on geographic=0A= location.=0A= =0A= But it also has to provide local wireline E911, local failover over=0A= wireline, all that so it needs a local presence, not just hosted. It has=0A= to survive different regulatory regimes in different countries: US,=0A= Canada, Mexico, It has no centralized IT, because it is a loose=0A= franchise model. Each franchise has to take local calls, and be in the=0A= local yellow pages, that is their business.=0A= =0A= No need for a VPN, no need for fiddling with firewalls or NAT, no need=0A= for anything but drop, go and turn it on, even the individual=0A= subscription identities are roles, not people. Build the building, move=0A= in, turn it on, and it just works. Each identity is a local, not global=0A= context.=0A= =20=0A= In such a model, SIP works great if the proxy and UA each do STUN=0A= Outbound and each do RTP NAT traversal.=0A= =0A= =0A= =0A= Michael=0A= =0A= =0A= =20=0A= It is amazing what you can accomplish if you do not care who gets the=0A= credit.=20=0A= =20=0A= - Harry S Truman=0A= =0A= -----Original Message-----=0A= From: Michael Slavitch [mailto:slavitch@objectworld.com]=20=0A= Sent: February 23, 2006 4:31 PM=0A= To: Dean Willis; Rohan Mahy=0A= Cc: sip@ietf.org; Cullen Jennings=0A= Subject: RE: [Sip] Outbound and STUN Keep Alive=0A= =0A= This is very real world. Internal SIP server behind firewall, SIP/PSTN=0A= proxy in the public internet or Enterprise registrar in the public=0A= internet. Most common implementation for highly distributed companies=0A= that have no backbone, such as franchise operations. Common common real=0A= world stuff.=0A= =0A= Given that SIP proxies can be highly distributed and SIP is not=0A= monolithic I can't see why this is freaky at all. In fact this has=0A= massive benefits in areas such as security and redundancy.=0A= =0A= This is to be expected in implementation.=0A= =0A= Many businesses don't let you touch their NAT, and the proxy must be=0A= behind the NAT router.=20=0A= =0A= Something like this shall address it.=0A= =0A= M=0A= =0A= =0A= =20=0A= =20=0A= It is amazing what you can accomplish if you do not care who gets the=0A= credit.=20=0A= =20=0A= - Harry S Truman=0A= =0A= -----Original Message-----=0A= From: Dean Willis [mailto:dean.willis@softarmor.com]=0A= Sent: February 23, 2006 4:17 PM=0A= To: Rohan Mahy=0A= Cc: sip@ietf.org; 'Cullen Jennings'=0A= Subject: Re: [Sip] Outbound and STUN Keep Alive=0A= =0A= On Thursday 23 February 2006 10:40, Rohan Mahy wrote:=0A= > Hi Hisham,=0A= >=0A= > Perhaps I wasn't clear enough in my earlier message to Gary. STUN=20=0A= > messages sent by the UA never get past the outbound proxy, so they=20=0A= > will not help discover any change in connectivity between the outbound=0A= =0A= > proxy and its next hop, nor will any other part of the outbound spec=20= =0A= > deal with connectivity between the outbound proxy and its next hop.=0A= > Dealing with NATs between proxies was never a requirement of this=20=0A= > particular draft.=0A= =0A= I think you guys are missing Gary's use case.=0A= =0A= He's postulating an entirely different NAT problem, where the NAT is=0A= between the outbound proxy and the real world, rather than between the=0A= UA and its outbound proxy.=0A= =0A= This just isn't a use case that's been in scope for general discussion=0A= so far.=20=0A= I'm not sure it needs to be -- it's a pretty freaky use case.=20=0A= =0A= Perhaps we might seee something like this in a small office, where=0A= there's an internal proxy-registrar that serves communications inside=0A= the firewall, but that then relies on an external proxy for routing=0A= calls outside the enterprise. This would require something like=0A= proxy-proxy connection reuse, or a port-forward rule on the firewall=0A= NAT, etc. to handle inbound calls.=0A= =0A= =0A= In this case, sending STUN requests (multiplexed or otherwise) from the=0A= UA to the outbound proxy accomplishes nothing useful, or at least=0A= nothing usefu lwith respect to NAT traversal.=20=0A= =0A= Instead, we would need the "outbound proxy" to itself implement a=0A= version of the "outbound draft" to the next-hop proxy, because there is=0A= a NAT binding between the user's outbound proxy and the user's outbound=0A= proxy's outbound proxy. Thus, we might see STUN used inter-proxy.=0A= =0A= The UA COULD also use STUN independently to a STUN server outside the=0A= NAT to discover the NAT's behavior, and possibly discover the UA's=0A= external address, which it would use in the construction of SDP.=0A= =0A= --=0A= Dean=0A= =0A= =20=0A= =0A= _______________________________________________=0A= Sip mailing list https://www1.ietf.org/mailman/listinfo/sip=0A= This list is for NEW development of the core SIP Protocol Use=0A= sip-implementors@cs.columbia.edu for questions on current sip Use=0A= sipping@ietf.org for new developments on the application of sip=0A= =0A= =0A= --=0A= =0A= =0A= -----------------------------------------------=0A= =0A= This transmission (including any attachments) may contain confidential=0A= information, privileged material (including material protected by the=0A= solicitor-client or other applicable privileges), or constitute=0A= non-public information. Any use of this information by anyone other than=0A= the intended recipient is prohibited. If you have received this=0A= transmission in error, please immediately reply to the sender and delete=0A= this information from your system. Use, dissemination, distribution, or=0A= reproduction of this transmission by unintended recipients is not=0A= authorized and may be unlawful.=20=0A= =0A= Any views, opinions and content presented in this e-mail are solely=0A= those of the author and may not represent those of Objectworld=0A= Communications Corp.=20=0A= =0A= _______________________________________________=0A= Sip mailing list https://www1.ietf.org/mailman/listinfo/sip=0A= This list is for NEW development of the core SIP Protocol Use=0A= sip-implementors@cs.columbia.edu for questions on current sip Use=0A= sipping@ietf.org for new developments on the application of sip=0A= =0A= =0A= --=0A= =0A= =0A= -----------------------------------------------=0D=0A= =0D=0A= This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. =0D=0A= =0D=0A= Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp= .=20=0A= _______________________________________________ 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 sip-bounces@ietf.org Thu Feb 23 19:32:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCQr8-00050T-FE; Thu, 23 Feb 2006 19:30:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCQr6-0004y3-AA; Thu, 23 Feb 2006 19:30:44 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCQr3-0004aL-Tw; Thu, 23 Feb 2006 19:30:44 -0500 Received: from [64.101.173.67] ([64.101.173.67]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1O0UnM2024315 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 23 Feb 2006 18:30:50 -0600 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <231F5685-CCC1-41B1-997E-74AF67D9EBCE@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Thu, 23 Feb 2006 18:30:44 -0600 To: "sip@ietf.org List" , Sipping List X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: Cullen Jennings , Jon Peterson , Allison Mankin Subject: [Sip] Thoughts on the Principle of Dividing and Conquering X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I've been working on SIP and SIPPING and P2P-SIP agendas this week, and that started me thinking. We spun up SIPPING to take some of the load off of SIP, and in doing so tried to more narrowly-define the charters of both SIP and SIPPING relative to the previous SIP charter. When we started talking about P2P-SIP, we thought about bringing in the topic as part of SIPPING, but fairly quickly rejected that idea because it was clearly partitionable. This started me thinking -- could we further apply this principle of partitioning? Both SIP and SIPPING have grown into multi-year monsters, each with large charters and the need for multiple long-sessions at each IETF. They're tricky to chair, require lots of secretarial work, and are chronically late on deliverables (in large part because the chairs are acting like ADs instead of chairs). SPPING, once viewed as the kidney of SIP, now needs its own dialysis. Perhaps if we were to split these two working groups into three or four working groups that have much more clearly defined missions and scopes, we could cut them down to one meeting slot each. And if we were to have separate management (chairs and secretaries) for each working group, we could better manage the groups to timely delivery. So I'd like to toss out some ideas on how we might subdivide, and see how you folks feel about this. I think the key to any success here would be in scope management. What if we had the following groups: 1) SIPEM -- SIP Extended Maintenance 2) SIPNEW -- New major functionality for SIP 3) SIPREQ -- Analysis of requirements raised by new applications or SDO liaison 4) SIPUSE -- Using SIP to meet specific application requirements Here's how we might divide the work: SIPEM ----- Scope: Maintenance of SIP 2.0 and development (as per RFC 3427) of backward-compatible extensions driven by applications with near-term deployment scenarios. Initial Milestone Tasks of SIPEM: 1) Developing a SIP Guidebook, roughly the equivalent of the TCP Roadmap, that defines what's "in" SIP and how the pieces fit together. 2) GRUU 3) Outbound 4) Target-Dialog 5) Certificate Usage 6) Location Transport 7) Loop Error Correction 8) Connected Party Identity 9) Hop Limit Diagnostics 10) TLS Usage 11) Answering Modes 12) Connection Reuse 13) Rejection of Anonymous Requests 14) Consent Mechanism SIPNEW ------ Scope: Enhancement and evolution of SIP including architectural-level requirements and (as per RFC 3427) extensions without requirements for backward compatibility. Initial milestone tasks of SIPNEW 1) Developing a "future roadmap" for the evolution of SIP 2) Solving the RFC 3261 Routing Problem 3) Use of SAML with SIP 4) Response Identity 5) Response Authentication 6) End to Middle Requests SIPREQ ------ Scope: Analysis of requirements raised by new applications of SIP in IETF or in external SDOs (as per RFC 3427). Development of requirements for changes to SIP or for usage guides in response to applications requirements. Another way of wording this would be "problem definition". Initial milestones and tasks of SIPREQ: 1) Session Policy Requirements SIPUSE ------ Scope: Guidance on how to use existing SIP specifications and mechanisms including examples, call flows, test cases, error avoidance, and so on. Review (as per RFC 3427) of SIP Event Packages. Initial milestones and tasks for SIPUSE: 1) Service Examples 2) Security Examples 3) Race Condition Examples 4) Session media policy mechanism 5) Session policy package mechanism 6) Service quality reporting mechanism 7) URI List mechanism 8) Subscriptions to Ad-Hoc Resource Lists mechanism 9) Multiple REFER mechanism 10) Ad-Hoc Conferencing using URI lists mechanism 11) Call Control Transfer mechanism 12) Configuration Delivery mechanism 13) Emergency Calling using SIP (SOS) mechanism Note that I'm not entirely happy with the division of SIPPING into SIPUSE and SIPREQ. While it seems like we spend a lot of time in SIPPING debating requirements, there are currently a lot of deliverables in this category. -- 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 sip-bounces@ietf.org Thu Feb 23 19:49:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCR7H-0000AO-Dx; Thu, 23 Feb 2006 19:47:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCR7F-00009f-Cw; Thu, 23 Feb 2006 19:47:25 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCR7E-0005FR-Ua; Thu, 23 Feb 2006 19:47:25 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 23 Feb 2006 16:47:25 -0800 X-IronPort-AV: i="4.02,142,1139212800"; d="scan'208"; a="1779219728:sNHT34686360" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k1O0lOXf005417; Thu, 23 Feb 2006 16:47:24 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Feb 2006 16:47:24 -0800 Received: from jmpolk-wxp.cisco.com ([10.89.16.85]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Feb 2006 16:47:23 -0800 Message-Id: <4.3.2.7.2.20060223184409.03593e18@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 Feb 2006 18:47:21 -0600 To: Dean Willis , "sip@ietf.org List" , Sipping List From: "James M. Polk" In-Reply-To: <231F5685-CCC1-41B1-997E-74AF67D9EBCE@softarmor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 24 Feb 2006 00:47:23.0543 (UTC) FILETIME=[E019FA70:01C638DB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: Cullen Jennings , Jon Peterson , Allison Mankin Subject: [Sip] Re: [Sipping] Thoughts on the Principle of Dividing and Conquering X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I don't mean to rain on this idea, but... What happens when these 4 grow too big for their britches, split them again? Shouldn't XCON and SIMPLE be considered when breaking SIP and SIPPING up, as these WGs were effectively split off of SIP earlier on? At 06:30 PM 2/23/2006 -0600, Dean Willis wrote: >I've been working on SIP and SIPPING and P2P-SIP agendas this week, >and that started me thinking. > >We spun up SIPPING to take some of the load off of SIP, and in doing >so tried to more narrowly-define the charters of both SIP and SIPPING >relative to the previous SIP charter. > >When we started talking about P2P-SIP, we thought about bringing in >the topic as part of SIPPING, but fairly quickly rejected that idea >because it was clearly partitionable. > >This started me thinking -- could we further apply this principle of >partitioning? > >Both SIP and SIPPING have grown into multi-year monsters, each with >large charters and the need for multiple long-sessions at each IETF. >They're tricky to chair, require lots of secretarial work, and are >chronically late on deliverables (in large part because the chairs >are acting like ADs instead of chairs). SPPING, once viewed as the >kidney of SIP, now needs its own dialysis. > >Perhaps if we were to split these two working groups into three or >four working groups that have much more clearly defined missions and >scopes, we could cut them down to one meeting slot each. And if we >were to have separate management (chairs and secretaries) for each >working group, we could better manage the groups to timely delivery. > >So I'd like to toss out some ideas on how we might subdivide, and see >how you folks feel about this. I think the key to any success here >would be in scope management. > >What if we had the following groups: > >1) SIPEM -- SIP Extended Maintenance > >2) SIPNEW -- New major functionality for SIP > >3) SIPREQ -- Analysis of requirements raised by new applications or >SDO liaison > >4) SIPUSE -- Using SIP to meet specific application requirements > > > >Here's how we might divide the work: > > >SIPEM >----- > >Scope: Maintenance of SIP 2.0 and development (as per RFC 3427) of >backward-compatible extensions driven by applications with near-term >deployment scenarios. > >Initial Milestone Tasks of SIPEM: > >1) Developing a SIP Guidebook, roughly the equivalent of the TCP >Roadmap, that defines what's "in" SIP and how the pieces fit together. > >2) GRUU > >3) Outbound > >4) Target-Dialog > >5) Certificate Usage > >6) Location Transport > >7) Loop Error Correction > >8) Connected Party Identity > >9) Hop Limit Diagnostics > >10) TLS Usage > >11) Answering Modes > >12) Connection Reuse > >13) Rejection of Anonymous Requests > >14) Consent Mechanism > > > >SIPNEW >------ > >Scope: Enhancement and evolution of SIP including architectural-level >requirements and (as per RFC 3427) extensions without requirements >for backward compatibility. > > >Initial milestone tasks of SIPNEW > >1) Developing a "future roadmap" for the evolution of SIP > >2) Solving the RFC 3261 Routing Problem > >3) Use of SAML with SIP > >4) Response Identity > >5) Response Authentication > >6) End to Middle Requests > > > >SIPREQ >------ > >Scope: Analysis of requirements raised by new applications of SIP in >IETF or in external SDOs (as per RFC 3427). Development of >requirements for changes to SIP or for usage guides in response to >applications requirements. Another way of wording this would be >"problem definition". > >Initial milestones and tasks of SIPREQ: > >1) Session Policy Requirements > > > >SIPUSE >------ > >Scope: Guidance on how to use existing SIP specifications and >mechanisms including examples, call flows, test cases, error >avoidance, and so on. Review (as per RFC 3427) of SIP Event Packages. > > >Initial milestones and tasks for SIPUSE: > >1) Service Examples > >2) Security Examples > >3) Race Condition Examples > >4) Session media policy mechanism > >5) Session policy package mechanism > >6) Service quality reporting mechanism > >7) URI List mechanism > >8) Subscriptions to Ad-Hoc Resource Lists mechanism > >9) Multiple REFER mechanism > >10) Ad-Hoc Conferencing using URI lists mechanism > >11) Call Control Transfer mechanism > >12) Configuration Delivery mechanism > >13) Emergency Calling using SIP (SOS) mechanism > > > > >Note that I'm not entirely happy with the division of SIPPING into >SIPUSE and SIPREQ. While it seems like we spend a lot of time in >SIPPING debating requirements, there are currently a lot of >deliverables in this category. > > >-- >Dean > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core 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 sip-bounces@ietf.org Thu Feb 23 21:39:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCSpk-0003yn-Jk; Thu, 23 Feb 2006 21:37:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCSpj-0003wW-2n; Thu, 23 Feb 2006 21:37:27 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FCSpi-0000IB-KP; Thu, 23 Feb 2006 21:37:27 -0500 X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-10.tower-121.messagelabs.com!1140748644!8024264!2 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 15907 invoked from network); 24 Feb 2006 02:37:25 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-10.tower-121.messagelabs.com with SMTP; 24 Feb 2006 02:37:25 -0000 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.12) by attrh3i.attrh.att.com (7.2.052) id 43D3BB52004AA4AF; Thu, 23 Feb 2006 21:37:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Feb 2006 20:37:23 -0600 Message-ID: <28F05913385EAC43AF019413F674A0170DE0C29A@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <4.3.2.7.2.20060223184409.03593e18@email.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Thoughts on the Principle of Dividing and Conquering Thread-Index: AcY42+mkgG1sYn21QmWaQKBk54mC0wADwsew From: "Dolly, Martin C, ALABS" To: "James M. Polk" , "Dean Willis" , , "Sipping List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Cc: Cullen Jennings , Jon Peterson , Allison Mankin Subject: [Sip] RE: [Sipping] Thoughts on the Principle of Dividing and Conquering X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org For as long as the "core" group of folks have to participate in all these topics, splitting solves nothing. If anything, it causes coordination issues. > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Thursday, February 23, 2006 7:47 PM > To: Dean Willis; sip@ietf.org List; Sipping List > Cc: Cullen Jennings; Jon Peterson; Allison Mankin > Subject: Re: [Sipping] Thoughts on the Principle of Dividing and > Conquering >=20 >=20 > I don't mean to rain on this idea, but... >=20 > What happens when these 4 grow too big for their britches,=20 > split them again? >=20 > Shouldn't XCON and SIMPLE be considered when breaking SIP and=20 > SIPPING up,=20 > as these WGs were effectively split off of SIP earlier on? >=20 > At 06:30 PM 2/23/2006 -0600, Dean Willis wrote: > >I've been working on SIP and SIPPING and P2P-SIP agendas this week, > >and that started me thinking. > > > >We spun up SIPPING to take some of the load off of SIP, and in doing > >so tried to more narrowly-define the charters of both SIP and SIPPING > >relative to the previous SIP charter. > > > >When we started talking about P2P-SIP, we thought about bringing in > >the topic as part of SIPPING, but fairly quickly rejected that idea > >because it was clearly partitionable. > > > >This started me thinking -- could we further apply this principle of > >partitioning? > > > >Both SIP and SIPPING have grown into multi-year monsters, each with > >large charters and the need for multiple long-sessions at each IETF. > >They're tricky to chair, require lots of secretarial work, and are > >chronically late on deliverables (in large part because the chairs > >are acting like ADs instead of chairs). SPPING, once viewed as the > >kidney of SIP, now needs its own dialysis. > > > >Perhaps if we were to split these two working groups into three or > >four working groups that have much more clearly defined missions and > >scopes, we could cut them down to one meeting slot each. And if we > >were to have separate management (chairs and secretaries) for each > >working group, we could better manage the groups to timely delivery. > > > >So I'd like to toss out some ideas on how we might subdivide, and see > >how you folks feel about this. I think the key to any success here > >would be in scope management. > > > >What if we had the following groups: > > > >1) SIPEM -- SIP Extended Maintenance > > > >2) SIPNEW -- New major functionality for SIP > > > >3) SIPREQ -- Analysis of requirements raised by new applications or > >SDO liaison > > > >4) SIPUSE -- Using SIP to meet specific application requirements > > > > > > > >Here's how we might divide the work: > > > > > >SIPEM > >----- > > > >Scope: Maintenance of SIP 2.0 and development (as per RFC 3427) of > >backward-compatible extensions driven by applications with near-term > >deployment scenarios. > > > >Initial Milestone Tasks of SIPEM: > > > >1) Developing a SIP Guidebook, roughly the equivalent of the TCP > >Roadmap, that defines what's "in" SIP and how the pieces fit=20 > together. > > > >2) GRUU > > > >3) Outbound > > > >4) Target-Dialog > > > >5) Certificate Usage > > > >6) Location Transport > > > >7) Loop Error Correction > > > >8) Connected Party Identity > > > >9) Hop Limit Diagnostics > > > >10) TLS Usage > > > >11) Answering Modes > > > >12) Connection Reuse > > > >13) Rejection of Anonymous Requests > > > >14) Consent Mechanism > > > > > > > >SIPNEW > >------ > > > >Scope: Enhancement and evolution of SIP including architectural-level > >requirements and (as per RFC 3427) extensions without requirements > >for backward compatibility. > > > > > >Initial milestone tasks of SIPNEW > > > >1) Developing a "future roadmap" for the evolution of SIP > > > >2) Solving the RFC 3261 Routing Problem > > > >3) Use of SAML with SIP > > > >4) Response Identity > > > >5) Response Authentication > > > >6) End to Middle Requests > > > > > > > >SIPREQ > >------ > > > >Scope: Analysis of requirements raised by new applications of SIP in > >IETF or in external SDOs (as per RFC 3427). Development of > >requirements for changes to SIP or for usage guides in response to > >applications requirements. Another way of wording this would be > >"problem definition". > > > >Initial milestones and tasks of SIPREQ: > > > >1) Session Policy Requirements > > > > > > > >SIPUSE > >------ > > > >Scope: Guidance on how to use existing SIP specifications and > >mechanisms including examples, call flows, test cases, error > >avoidance, and so on. Review (as per RFC 3427) of SIP Event Packages. > > > > > >Initial milestones and tasks for SIPUSE: > > > >1) Service Examples > > > >2) Security Examples > > > >3) Race Condition Examples > > > >4) Session media policy mechanism > > > >5) Session policy package mechanism > > > >6) Service quality reporting mechanism > > > >7) URI List mechanism > > > >8) Subscriptions to Ad-Hoc Resource Lists mechanism > > > >9) Multiple REFER mechanism > > > >10) Ad-Hoc Conferencing using URI lists mechanism > > > >11) Call Control Transfer mechanism > > > >12) Configuration Delivery mechanism > > > >13) Emergency Calling using SIP (SOS) mechanism > > > > > > > > > >Note that I'm not entirely happy with the division of SIPPING into > >SIPUSE and SIPREQ. While it seems like we spend a lot of time in > >SIPPING debating requirements, there are currently a lot of > >deliverables in this category. > > > > > >-- > >Dean > > > >_______________________________________________ > >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > >This list is for NEW development of the application of SIP > >Use sip-implementors@cs.columbia.edu for questions on current sip > >Use sip@ietf.org for new developments of core SIP >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core 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 sip-bounces@ietf.org Fri Feb 24 00:52:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCVq1-0001gA-Ri; Fri, 24 Feb 2006 00:49:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCVpz-0001fx-T8 for sip@ietf.org; Fri, 24 Feb 2006 00:49:55 -0500 Received: from nproxy.gmail.com ([64.233.182.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCVpw-00064u-KE for sip@ietf.org; Fri, 24 Feb 2006 00:49:55 -0500 Received: by nproxy.gmail.com with SMTP id a27so160232nfc for ; Thu, 23 Feb 2006 21:49:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=RCNj51CzO7tsFJP4a4zDuAu3QIeL4enoQYrk2cwlRJhinBT0seN0Xswd4CEAyKy4+rDT6VjzW+7B7PECa0sjz5BWe+mvI6jxRjHD6faBAbwqYeH+zDWJal4SaTaTTRtZvXlTOjJUlTOkI987IFlpKK0RoymKfS2vdgEM/IBPuyY= Received: by 10.48.240.15 with SMTP id n15mr1967086nfh; Thu, 23 Feb 2006 21:49:51 -0800 (PST) Received: by 10.49.35.18 with HTTP; Thu, 23 Feb 2006 21:49:51 -0800 (PST) Message-ID: <52db68bc0602232149s29e17b67w38226918a3f9ef03@mail.gmail.com> Date: Fri, 24 Feb 2006 11:19:51 +0530 From: "Sudhir Kumar Reddy" To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Sip] Query presence through polling X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0428260853==" Errors-To: sip-bounces@ietf.org --===============0428260853== Content-Type: multipart/alternative; boundary="----=_Part_12012_2604882.1140760191673" ------=_Part_12012_2604882.1140760191673 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi All, Is there any draft or RFC for reterieving the Presence through polling? any feedback is appericated. thanks in advance best regards Sudhir ------=_Part_12012_2604882.1140760191673 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi All,
 
Is there any draft or RFC for reterieving the Presence through polling= ?
 
 
any feedback is appericated.
 
thanks in advance
 
best regards
Sudhir
------=_Part_12012_2604882.1140760191673-- --===============0428260853== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0428260853==-- From sip-bounces@ietf.org Fri Feb 24 01:18:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCWG4-0003vF-Mn; Fri, 24 Feb 2006 01:16:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCWG3-0003uE-Mb for sip@ietf.org; Fri, 24 Feb 2006 01:16:51 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCWG2-0006Yc-DT for sip@ietf.org; Fri, 24 Feb 2006 01:16:51 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 23 Feb 2006 22:16:50 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1O6GnHf004090; Thu, 23 Feb 2006 22:16:49 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Feb 2006 22:16:49 -0800 Received: from [10.21.112.47] ([10.21.112.47]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Feb 2006 22:16:49 -0800 Message-ID: <43FEA4D0.3050806@cisco.com> Date: Fri, 24 Feb 2006 01:16:48 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Sip] WGLC for draft-ietf-sip-answermode-00 References: <26fbf302818a0cbbe4558f83410f081c@ekabal.com> In-Reply-To: <26fbf302818a0cbbe4558f83410f081c@ekabal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2006 06:16:49.0144 (UTC) FILETIME=[E5515780:01C63909] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: SIP WG , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org OK, I reviewed this one more time. Below are a bunch of things. They are all small except for the last one. Paul Rohan Mahy wrote: > Hi, > > I'd like to start a 3-week working group last call for: > > draft-ietf-sip-answermode-00.txt > > This WGLC will complete on March 15th There are several instances of a feature tag of "extension="answermode"". That ought to be "extensions". (I know dean consulted me on this long ago to get it right, so its most likely my own error.) Note that there are also some correct usages in the doc. In section 6.1, a Contact header is folded across multiple lines, but the subsequent lines are not indented. In section 7.3: s/nee o make/need to make/ In section 7.4: User agents implementing this specification MUST NOT establish a session providing outbound or bidirectional media without explicit user acceptance. Isn't this a little strong? It totally eliminates the baby monitor as a supported application. It also eliminates using this in support of a loopback test mode. _______________________________________________ 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 sip-bounces@ietf.org Fri Feb 24 02:45:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCXba-0005c1-RP; Fri, 24 Feb 2006 02:43:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCXbZ-0005bt-KY; Fri, 24 Feb 2006 02:43:09 -0500 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCXbZ-0000sT-1C; Fri, 24 Feb 2006 02:43:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Feb 2006 09:43:06 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C03428B1F@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Thoughts on the Principle of Dividing and Conquering Thread-Index: AcY42a+Gr49Qv1L5Sdm9tvkvUkVqvwAOnIbQ From: "Even, Roni" To: "Dean Willis" , , "Sipping List" X-Spam-Score: 0.1 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: Cullen Jennings , Jon Peterson , Allison Mankin Subject: [Sip] RE: [Sipping] Thoughts on the Principle of Dividing and Conquering X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean, I support this principal and think that in general the idea is good. I see the point of enabling WG chairs to focus on more specific topics and helping progress the work between the IETF meetings. Currently it looks to me that there is no lack of subjects to work (number of active drafts) but lack of time to cover and progress all of them.=20 I am not sure about the split you mentioned but at least a SIPUSE working group makes sense.=20 I think that we also need SIP applications WG (some of the topics are in the SIPUSE list you gave) like we have today in XCON and SIMPLE. Roni Even=20 =20 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Friday, February 24, 2006 2:31 AM To: sip@ietf.org List; Sipping List Cc: Cullen Jennings; Jon Peterson; Allison Mankin Subject: [Sipping] Thoughts on the Principle of Dividing and Conquering I've been working on SIP and SIPPING and P2P-SIP agendas this week, =20 and that started me thinking. We spun up SIPPING to take some of the load off of SIP, and in doing =20 so tried to more narrowly-define the charters of both SIP and SIPPING =20 relative to the previous SIP charter. When we started talking about P2P-SIP, we thought about bringing in =20 the topic as part of SIPPING, but fairly quickly rejected that idea =20 because it was clearly partitionable. This started me thinking -- could we further apply this principle of =20 partitioning? Both SIP and SIPPING have grown into multi-year monsters, each with =20 large charters and the need for multiple long-sessions at each IETF. =20 They're tricky to chair, require lots of secretarial work, and are =20 chronically late on deliverables (in large part because the chairs =20 are acting like ADs instead of chairs). SPPING, once viewed as the =20 kidney of SIP, now needs its own dialysis. Perhaps if we were to split these two working groups into three or =20 four working groups that have much more clearly defined missions and =20 scopes, we could cut them down to one meeting slot each. And if we =20 were to have separate management (chairs and secretaries) for each =20 working group, we could better manage the groups to timely delivery. So I'd like to toss out some ideas on how we might subdivide, and see =20 how you folks feel about this. I think the key to any success here =20 would be in scope management. What if we had the following groups: 1) SIPEM -- SIP Extended Maintenance 2) SIPNEW -- New major functionality for SIP 3) SIPREQ -- Analysis of requirements raised by new applications or =20 SDO liaison 4) SIPUSE -- Using SIP to meet specific application requirements Here's how we might divide the work: SIPEM ----- Scope: Maintenance of SIP 2.0 and development (as per RFC 3427) of =20 backward-compatible extensions driven by applications with near-term =20 deployment scenarios. Initial Milestone Tasks of SIPEM: 1) Developing a SIP Guidebook, roughly the equivalent of the TCP =20 Roadmap, that defines what's "in" SIP and how the pieces fit together. 2) GRUU 3) Outbound 4) Target-Dialog 5) Certificate Usage 6) Location Transport 7) Loop Error Correction 8) Connected Party Identity 9) Hop Limit Diagnostics 10) TLS Usage 11) Answering Modes 12) Connection Reuse 13) Rejection of Anonymous Requests 14) Consent Mechanism SIPNEW ------ Scope: Enhancement and evolution of SIP including architectural-level =20 requirements and (as per RFC 3427) extensions without requirements =20 for backward compatibility. Initial milestone tasks of SIPNEW 1) Developing a "future roadmap" for the evolution of SIP 2) Solving the RFC 3261 Routing Problem 3) Use of SAML with SIP 4) Response Identity 5) Response Authentication 6) End to Middle Requests SIPREQ ------ Scope: Analysis of requirements raised by new applications of SIP in =20 IETF or in external SDOs (as per RFC 3427). Development of =20 requirements for changes to SIP or for usage guides in response to =20 applications requirements. Another way of wording this would be =20 "problem definition". Initial milestones and tasks of SIPREQ: 1) Session Policy Requirements SIPUSE ------ Scope: Guidance on how to use existing SIP specifications and =20 mechanisms including examples, call flows, test cases, error =20 avoidance, and so on. Review (as per RFC 3427) of SIP Event Packages. Initial milestones and tasks for SIPUSE: 1) Service Examples 2) Security Examples 3) Race Condition Examples 4) Session media policy mechanism 5) Session policy package mechanism 6) Service quality reporting mechanism 7) URI List mechanism 8) Subscriptions to Ad-Hoc Resource Lists mechanism 9) Multiple REFER mechanism 10) Ad-Hoc Conferencing using URI lists mechanism 11) Call Control Transfer mechanism 12) Configuration Delivery mechanism 13) Emergency Calling using SIP (SOS) mechanism Note that I'm not entirely happy with the division of SIPPING into =20 SIPUSE and SIPREQ. While it seems like we spend a lot of time in =20 SIPPING debating requirements, there are currently a lot of =20 deliverables in this category. -- Dean _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core 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 sip-bounces@ietf.org Fri Feb 24 05:39:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCaJy-0003jW-75; Fri, 24 Feb 2006 05:37:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCaJv-0003jA-Oc; Fri, 24 Feb 2006 05:37:07 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCaJv-00063l-5Q; Fri, 24 Feb 2006 05:37:07 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k1OAaOYC030644; Fri, 24 Feb 2006 12:36:25 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Feb 2006 12:37:02 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Feb 2006 12:37:00 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Thoughts on the Principle of Dividing and Conquering Date: Fri, 24 Feb 2006 12:37:01 +0200 Message-ID: In-Reply-To: <231F5685-CCC1-41B1-997E-74AF67D9EBCE@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Thoughts on the Principle of Dividing and Conquering Thread-Index: AcY42afiPVEs19vcQ06b2UdoWVAPTgAShF1A From: To: , , X-OriginalArrivalTime: 24 Feb 2006 10:37:00.0759 (UTC) FILETIME=[3E90BE70:01C6392E] X-Spam-Score: 0.2 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: fluffy@cisco.com, jon.peterson@neustar.biz, mankin@psg.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean, (It seems we are creating the SIP Engineering Task Force (SPTF)... We = already know that the S in SIP certainly does not stand for "Simple", = but perhaps we should consider replacing "Session" with "Standards": = "SIP is a mechnism that allows people to initiate and manage Working = Groups and oher Standardization efforts mainly in the IETF, but also in = other organizations such as but not limited to OMA, 3GPP, 3GPP2, ETSI, = ATIS and MSF" :-)=20 Seriously speaking, I support your idea in general. Here are some more = specific points: - The most important improvent from my point of view would be the = separation of "major new work" from "small extensions and maintenance". = Currently, getting small, sometimes niche, extensions through the = process seems to be taking too long, and that is creating some = frustration. ("Implementing this takes two days, but getting this = standardized in the IETF will take 2 years".) Of course, it is still = important to review that the new things won't break the existing ones = etc. - Having more time in the meetings is always good, although it seems we = already have at the IETF something related to SIP at every slot...=20 - With a lot of people having worked with SIP in the IETF for many years = (forewver?), there should be many quite capable WG chairs available. - With the RAI area established, we have the higher level structure = already in place for this type of move. Markus > -----Original Message----- > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 24 February, 2006 02:31 > To: sip@ietf.org List; Sipping List > Cc: Cullen Jennings; Jon Peterson; Allison Mankin > Subject: [Sip] Thoughts on the Principle of Dividing and Conquering >=20 >=20 > I've been working on SIP and SIPPING and P2P-SIP agendas this week, =20 > and that started me thinking. >=20 > We spun up SIPPING to take some of the load off of SIP, and in doing =20 > so tried to more narrowly-define the charters of both SIP and=20 > SIPPING =20 > relative to the previous SIP charter. >=20 > When we started talking about P2P-SIP, we thought about bringing in =20 > the topic as part of SIPPING, but fairly quickly rejected that idea =20 > because it was clearly partitionable. >=20 > This started me thinking -- could we further apply this principle of =20 > partitioning? >=20 > Both SIP and SIPPING have grown into multi-year monsters, each with =20 > large charters and the need for multiple long-sessions at each IETF. =20 > They're tricky to chair, require lots of secretarial work, and are =20 > chronically late on deliverables (in large part because the chairs =20 > are acting like ADs instead of chairs). SPPING, once viewed as the =20 > kidney of SIP, now needs its own dialysis. >=20 > Perhaps if we were to split these two working groups into three or =20 > four working groups that have much more clearly defined missions and =20 > scopes, we could cut them down to one meeting slot each. And if we =20 > were to have separate management (chairs and secretaries) for each =20 > working group, we could better manage the groups to timely delivery. >=20 > So I'd like to toss out some ideas on how we might subdivide,=20 > and see =20 > how you folks feel about this. I think the key to any success here =20 > would be in scope management. >=20 > What if we had the following groups: >=20 > 1) SIPEM -- SIP Extended Maintenance >=20 > 2) SIPNEW -- New major functionality for SIP >=20 > 3) SIPREQ -- Analysis of requirements raised by new applications or =20 > SDO liaison >=20 > 4) SIPUSE -- Using SIP to meet specific application requirements >=20 >=20 >=20 > Here's how we might divide the work: >=20 >=20 > SIPEM > ----- >=20 > Scope: Maintenance of SIP 2.0 and development (as per RFC 3427) of =20 > backward-compatible extensions driven by applications with near-term =20 > deployment scenarios. >=20 > Initial Milestone Tasks of SIPEM: >=20 > 1) Developing a SIP Guidebook, roughly the equivalent of the TCP =20 > Roadmap, that defines what's "in" SIP and how the pieces fit together. >=20 > 2) GRUU >=20 > 3) Outbound >=20 > 4) Target-Dialog >=20 > 5) Certificate Usage >=20 > 6) Location Transport >=20 > 7) Loop Error Correction >=20 > 8) Connected Party Identity >=20 > 9) Hop Limit Diagnostics >=20 > 10) TLS Usage >=20 > 11) Answering Modes >=20 > 12) Connection Reuse >=20 > 13) Rejection of Anonymous Requests >=20 > 14) Consent Mechanism >=20 >=20 >=20 > SIPNEW > ------ >=20 > Scope: Enhancement and evolution of SIP including=20 > architectural-level =20 > requirements and (as per RFC 3427) extensions without requirements =20 > for backward compatibility. >=20 >=20 > Initial milestone tasks of SIPNEW >=20 > 1) Developing a "future roadmap" for the evolution of SIP >=20 > 2) Solving the RFC 3261 Routing Problem >=20 > 3) Use of SAML with SIP >=20 > 4) Response Identity >=20 > 5) Response Authentication >=20 > 6) End to Middle Requests >=20 >=20 >=20 > SIPREQ > ------ >=20 > Scope: Analysis of requirements raised by new applications of SIP in =20 > IETF or in external SDOs (as per RFC 3427). Development of =20 > requirements for changes to SIP or for usage guides in response to =20 > applications requirements. Another way of wording this would be =20 > "problem definition". >=20 > Initial milestones and tasks of SIPREQ: >=20 > 1) Session Policy Requirements >=20 >=20 >=20 > SIPUSE > ------ >=20 > Scope: Guidance on how to use existing SIP specifications and =20 > mechanisms including examples, call flows, test cases, error =20 > avoidance, and so on. Review (as per RFC 3427) of SIP Event Packages. >=20 >=20 > Initial milestones and tasks for SIPUSE: >=20 > 1) Service Examples >=20 > 2) Security Examples >=20 > 3) Race Condition Examples >=20 > 4) Session media policy mechanism >=20 > 5) Session policy package mechanism >=20 > 6) Service quality reporting mechanism >=20 > 7) URI List mechanism >=20 > 8) Subscriptions to Ad-Hoc Resource Lists mechanism >=20 > 9) Multiple REFER mechanism >=20 > 10) Ad-Hoc Conferencing using URI lists mechanism >=20 > 11) Call Control Transfer mechanism >=20 > 12) Configuration Delivery mechanism >=20 > 13) Emergency Calling using SIP (SOS) mechanism >=20 >=20 >=20 >=20 > Note that I'm not entirely happy with the division of SIPPING into =20 > SIPUSE and SIPREQ. While it seems like we spend a lot of time in =20 > SIPPING debating requirements, there are currently a lot of =20 > deliverables in this category. >=20 >=20 > -- > Dean >=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 sip-bounces@ietf.org Fri Feb 24 05:46:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCaR3-0000ag-8J; Fri, 24 Feb 2006 05:44:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCaR1-0000YZ-N5 for sip@ietf.org; Fri, 24 Feb 2006 05:44:27 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCaR0-0006HH-3d for sip@ietf.org; Fri, 24 Feb 2006 05:44:27 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 97C9B194487 for ; Fri, 24 Feb 2006 11:44:24 +0100 (CET) Received: from [192.168.1.72] ([192.168.1.72]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Feb 2006 11:42:56 +0100 In-Reply-To: <200602231516.30350.dean.willis@softarmor.com> References: <200602231516.30350.dean.willis@softarmor.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Fri, 24 Feb 2006 11:44:44 +0100 To: Dean Willis X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 24 Feb 2006 10:42:56.0684 (UTC) FILETIME=[12B696C0:01C6392F] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: 'Cullen Jennings' , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Feb 23, 2006, at 10:16 PM, Dean Willis wrote: > On Thursday 23 February 2006 10:40, Rohan Mahy wrote: >> Hi Hisham, >> >> Perhaps I wasn't clear enough in my earlier message to Gary. STUN >> messages sent by the UA never get past the outbound proxy, so they >> will >> not help discover any change in connectivity between the outbound >> proxy >> and its next hop, nor will any other part of the outbound spec deal >> with connectivity between the outbound proxy and its next hop. >> Dealing >> with NATs between proxies was never a requirement of this particular >> draft. > > I think you guys are missing Gary's use case. > > He's postulating an entirely different NAT problem, where the NAT is > between > the outbound proxy and the real world, rather than between the UA and > its > outbound proxy. > > This just isn't a use case that's been in scope for general discussion > so far. > I'm not sure it needs to be -- it's a pretty freaky use case. > > Perhaps we might seee something like this in a small office, where > there's an > internal proxy-registrar that serves communications inside the > firewall, but > that then relies on an external proxy for routing calls outside the > enterprise. This would require something like proxy-proxy connection > reuse, > or a port-forward rule on the firewall NAT, etc. to handle inbound > calls. > > > In this case, sending STUN requests (multiplexed or otherwise) from > the UA to > the outbound proxy accomplishes nothing useful, or at least nothing > usefu > lwith respect to NAT traversal. > > Instead, we would need the "outbound proxy" to itself implement a > version of > the "outbound draft" to the next-hop proxy, because there is a NAT > binding > between the user's outbound proxy and the user's outbound proxy's > outbound > proxy. Thus, we might see STUN used inter-proxy. This is addressed in section 3.4 of the draft (using path header). Isn't it? Hisham > > The UA COULD also use STUN independently to a STUN server outside the > NAT to > discover the NAT's behavior, and possibly discover the UA's external > address, > which it would use in the construction of SDP. > > -- > 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 sip-bounces@ietf.org Fri Feb 24 06:01:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCaff-00024l-Iq; Fri, 24 Feb 2006 05:59:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCafe-00024d-JB; Fri, 24 Feb 2006 05:59:34 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCafe-0006m6-0r; Fri, 24 Feb 2006 05:59:34 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 10B9A194486; Fri, 24 Feb 2006 11:59:33 +0100 (CET) Received: from [192.168.1.72] ([192.168.1.72]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Feb 2006 11:58:04 +0100 In-Reply-To: <231F5685-CCC1-41B1-997E-74AF67D9EBCE@softarmor.com> References: <231F5685-CCC1-41B1-997E-74AF67D9EBCE@softarmor.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6504c97d55581302c9e786a2ad8ce9b4@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Date: Fri, 24 Feb 2006 11:59:52 +0100 To: Dean Willis X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 24 Feb 2006 10:58:04.0988 (UTC) FILETIME=[301AC7C0:01C63931] X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: Cullen Jennings , "sip@ietf.org List" , Sipping List , Jon Peterson , Allison Mankin Subject: [Sip] Re: [Sipping] Thoughts on the Principle of Dividing and Conquering X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I support this idea. It will certainly reduce the load on chairs, but does it really reduce the load on the rest of us? I guess not :) So I only support this division because it allows focus and helps the community to better understand the progress of SIP. BTW, how about a 5th one: SIP-P, SIP for P-headers ;) Hisham On Feb 24, 2006, at 1:30 AM, Dean Willis wrote: > I've been working on SIP and SIPPING and P2P-SIP agendas this week, > and that started me thinking. > > We spun up SIPPING to take some of the load off of SIP, and in doing > so tried to more narrowly-define the charters of both SIP and SIPPING > relative to the previous SIP charter. > > When we started talking about P2P-SIP, we thought about bringing in > the topic as part of SIPPING, but fairly quickly rejected that idea > because it was clearly partitionable. > > This started me thinking -- could we further apply this principle of > partitioning? > > Both SIP and SIPPING have grown into multi-year monsters, each with > large charters and the need for multiple long-sessions at each IETF. > They're tricky to chair, require lots of secretarial work, and are > chronically late on deliverables (in large part because the chairs are > acting like ADs instead of chairs). SPPING, once viewed as the kidney > of SIP, now needs its own dialysis. > > Perhaps if we were to split these two working groups into three or > four working groups that have much more clearly defined missions and > scopes, we could cut them down to one meeting slot each. And if we > were to have separate management (chairs and secretaries) for each > working group, we could better manage the groups to timely delivery. > > So I'd like to toss out some ideas on how we might subdivide, and see > how you folks feel about this. I think the key to any success here > would be in scope management. > > What if we had the following groups: > > 1) SIPEM -- SIP Extended Maintenance > > 2) SIPNEW -- New major functionality for SIP > > 3) SIPREQ -- Analysis of requirements raised by new applications or > SDO liaison > > 4) SIPUSE -- Using SIP to meet specific application requirements > > > > Here's how we might divide the work: > > > SIPEM > ----- > > Scope: Maintenance of SIP 2.0 and development (as per RFC 3427) of > backward-compatible extensions driven by applications with near-term > deployment scenarios. > > Initial Milestone Tasks of SIPEM: > > 1) Developing a SIP Guidebook, roughly the equivalent of the TCP > Roadmap, that defines what's "in" SIP and how the pieces fit together. > > 2) GRUU > > 3) Outbound > > 4) Target-Dialog > > 5) Certificate Usage > > 6) Location Transport > > 7) Loop Error Correction > > 8) Connected Party Identity > > 9) Hop Limit Diagnostics > > 10) TLS Usage > > 11) Answering Modes > > 12) Connection Reuse > > 13) Rejection of Anonymous Requests > > 14) Consent Mechanism > > > > SIPNEW > ------ > > Scope: Enhancement and evolution of SIP including architectural-level > requirements and (as per RFC 3427) extensions without requirements for > backward compatibility. > > > Initial milestone tasks of SIPNEW > > 1) Developing a "future roadmap" for the evolution of SIP > > 2) Solving the RFC 3261 Routing Problem > > 3) Use of SAML with SIP > > 4) Response Identity > > 5) Response Authentication > > 6) End to Middle Requests > > > > SIPREQ > ------ > > Scope: Analysis of requirements raised by new applications of SIP in > IETF or in external SDOs (as per RFC 3427). Development of > requirements for changes to SIP or for usage guides in response to > applications requirements. Another way of wording this would be > "problem definition". > > Initial milestones and tasks of SIPREQ: > > 1) Session Policy Requirements > > > > SIPUSE > ------ > > Scope: Guidance on how to use existing SIP specifications and > mechanisms including examples, call flows, test cases, error > avoidance, and so on. Review (as per RFC 3427) of SIP Event Packages. > > > Initial milestones and tasks for SIPUSE: > > 1) Service Examples > > 2) Security Examples > > 3) Race Condition Examples > > 4) Session media policy mechanism > > 5) Session policy package mechanism > > 6) Service quality reporting mechanism > > 7) URI List mechanism > > 8) Subscriptions to Ad-Hoc Resource Lists mechanism > > 9) Multiple REFER mechanism > > 10) Ad-Hoc Conferencing using URI lists mechanism > > 11) Call Control Transfer mechanism > > 12) Configuration Delivery mechanism > > 13) Emergency Calling using SIP (SOS) mechanism > > > > > Note that I'm not entirely happy with the division of SIPPING into > SIPUSE and SIPREQ. While it seems like we spend a lot of time in > SIPPING debating requirements, there are currently a lot of > deliverables in this category. > > > -- > Dean > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core 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 sip-bounces@ietf.org Fri Feb 24 07:54:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCcRG-00041G-AL; Fri, 24 Feb 2006 07:52:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCcRE-0003zU-Fz; Fri, 24 Feb 2006 07:52:48 -0500 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCcRD-0001Ib-Jd; Fri, 24 Feb 2006 07:52:48 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id k1OCqkQk203338; Fri, 24 Feb 2006 12:52:46 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k1OCqveH195150; Fri, 24 Feb 2006 13:52:58 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k1OCqjv6015277; Fri, 24 Feb 2006 13:52:45 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k1OCqjVf015271; Fri, 24 Feb 2006 13:52:45 +0100 In-Reply-To: <231F5685-CCC1-41B1-997E-74AF67D9EBCE@softarmor.com> To: Dean Willis Subject: Re: [Sip] Thoughts on the Principle of Dividing and Conquering MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Avshalom Houri Message-ID: Date: Fri, 24 Feb 2006 14:52:55 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0HF90 | November 16, 2005) at 24/02/2006 14:52:56, Serialize complete at 24/02/2006 14:52:56 X-Spam-Score: 0.5 (/) X-Scan-Signature: c853ec6e79db43c8dbe6774215da1042 Cc: Cullen Jennings , "sip@ietf.org List" , Sipping List , Jon Peterson , Allison Mankin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1420013538==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1420013538== Content-Type: multipart/alternative; boundary="=_alternative 0046BB21C225711F_=" This is a multipart message in MIME format. --=_alternative 0046BB21C225711F_= Content-Type: text/plain; charset="US-ASCII" I do think that a step in this direction is very necessary. We will have to finalize the details as: * How this relates to SPEERMINT and to P2P-SIP? * A lot of very SIP related work is done MIDCOM, MMUSIC, IPTEL, ENUM, XCON, BEHAVE and probably more groups. How the SIP related work will fit into the new framework? * The SIP work in the IETF has become so big and very connected with other standard organizations that we really need to think about all the issues and there may be a need to a deeper change as creating a sub organization in the IETF for SIP that will meet in other dates (maybe collocated with other organization meetings from time to time as 3GPP and OMA. This way we may have much more time to deal with the necessary issues. Maybe we should have a BOF at the Dallas IETF for this? Although I am not sure we will have a big enough room or it will be easy to chair such a meeting. :) --Avshalom Dean Willis wrote on 24-02-2006 02:30:44 AM: > I've been working on SIP and SIPPING and P2P-SIP agendas this week, > and that started me thinking. > > We spun up SIPPING to take some of the load off of SIP, and in doing > so tried to more narrowly-define the charters of both SIP and SIPPING > relative to the previous SIP charter. > > When we started talking about P2P-SIP, we thought about bringing in > the topic as part of SIPPING, but fairly quickly rejected that idea > because it was clearly partitionable. > > This started me thinking -- could we further apply this principle of > partitioning? > > Both SIP and SIPPING have grown into multi-year monsters, each with > large charters and the need for multiple long-sessions at each IETF. > They're tricky to chair, require lots of secretarial work, and are > chronically late on deliverables (in large part because the chairs > are acting like ADs instead of chairs). SPPING, once viewed as the > kidney of SIP, now needs its own dialysis. > > Perhaps if we were to split these two working groups into three or > four working groups that have much more clearly defined missions and > scopes, we could cut them down to one meeting slot each. And if we > were to have separate management (chairs and secretaries) for each > working group, we could better manage the groups to timely delivery. > > So I'd like to toss out some ideas on how we might subdivide, and see > how you folks feel about this. I think the key to any success here > would be in scope management. > > What if we had the following groups: > > 1) SIPEM -- SIP Extended Maintenance > > 2) SIPNEW -- New major functionality for SIP > > 3) SIPREQ -- Analysis of requirements raised by new applications or > SDO liaison > > 4) SIPUSE -- Using SIP to meet specific application requirements > > > > Here's how we might divide the work: > > > SIPEM > ----- > > Scope: Maintenance of SIP 2.0 and development (as per RFC 3427) of > backward-compatible extensions driven by applications with near-term > deployment scenarios. > > Initial Milestone Tasks of SIPEM: > > 1) Developing a SIP Guidebook, roughly the equivalent of the TCP > Roadmap, that defines what's "in" SIP and how the pieces fit together. > > 2) GRUU > > 3) Outbound > > 4) Target-Dialog > > 5) Certificate Usage > > 6) Location Transport > > 7) Loop Error Correction > > 8) Connected Party Identity > > 9) Hop Limit Diagnostics > > 10) TLS Usage > > 11) Answering Modes > > 12) Connection Reuse > > 13) Rejection of Anonymous Requests > > 14) Consent Mechanism > > > > SIPNEW > ------ > > Scope: Enhancement and evolution of SIP including architectural-level > requirements and (as per RFC 3427) extensions without requirements > for backward compatibility. > > > Initial milestone tasks of SIPNEW > > 1) Developing a "future roadmap" for the evolution of SIP > > 2) Solving the RFC 3261 Routing Problem > > 3) Use of SAML with SIP > > 4) Response Identity > > 5) Response Authentication > > 6) End to Middle Requests > > > > SIPREQ > ------ > > Scope: Analysis of requirements raised by new applications of SIP in > IETF or in external SDOs (as per RFC 3427). Development of > requirements for changes to SIP or for usage guides in response to > applications requirements. Another way of wording this would be > "problem definition". > > Initial milestones and tasks of SIPREQ: > > 1) Session Policy Requirements > > > > SIPUSE > ------ > > Scope: Guidance on how to use existing SIP specifications and > mechanisms including examples, call flows, test cases, error > avoidance, and so on. Review (as per RFC 3427) of SIP Event Packages. > > > Initial milestones and tasks for SIPUSE: > > 1) Service Examples > > 2) Security Examples > > 3) Race Condition Examples > > 4) Session media policy mechanism > > 5) Session policy package mechanism > > 6) Service quality reporting mechanism > > 7) URI List mechanism > > 8) Subscriptions to Ad-Hoc Resource Lists mechanism > > 9) Multiple REFER mechanism > > 10) Ad-Hoc Conferencing using URI lists mechanism > > 11) Call Control Transfer mechanism > > 12) Configuration Delivery mechanism > > 13) Emergency Calling using SIP (SOS) mechanism > > > > > Note that I'm not entirely happy with the division of SIPPING into > SIPUSE and SIPREQ. While it seems like we spend a lot of time in > SIPPING debating requirements, there are currently a lot of > deliverables in this category. > > > -- > 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 --=_alternative 0046BB21C225711F_= Content-Type: text/html; charset="US-ASCII"
I do think that a step in this direction is very necessary.
We will have to finalize the details as:

* How this relates to SPEERMINT and to P2P-SIP?

* A lot of very SIP related work is done MIDCOM, MMUSIC, IPTEL, ENUM, XCON, BEHAVE and
probably more groups. How the SIP related work will fit into the new framework?

* The SIP work in the IETF has become so big and very connected with other standard organizations
that we really need to think about all the issues and there may be a need to a deeper change as
creating a sub organization in the IETF for SIP that will meet in other dates (maybe collocated with other
organization meetings from time to time as 3GPP and OMA. This way we may have much more time to deal
with the necessary issues.

Maybe we should have a BOF at the Dallas IETF for this? Although I am not sure we will have
a big enough room or it will be easy to chair such a meeting. :)

--Avshalom

Dean Willis <dean.willis@softarmor.com> wrote on 24-02-2006 02:30:44 AM:

> I've been working on SIP and SIPPING and P2P-SIP agendas this week,  
> and that started me thinking.
>
> We spun up SIPPING to take some of the load off of SIP, and in doing  
> so tried to more narrowly-define the charters of both SIP and SIPPING  
> relative to the previous SIP charter.
>
> When we started talking about P2P-SIP, we thought about bringing in  
> the topic as part of SIPPING, but fairly quickly rejected that idea  
> because it was clearly partitionable.
>
> This started me thinking -- could we further apply this principle of  
> partitioning?
>
> Both SIP and SIPPING have grown into multi-year monsters, each with  
> large charters and the need for multiple long-sessions at each IETF.  
> They're tricky to chair, require lots of secretarial work, and are  
> chronically late on deliverables (in large part because the chairs  
> are acting like ADs instead of chairs). SPPING, once viewed as the  
> kidney of SIP, now needs its own dialysis.
>
> Perhaps if we were to split these two working groups into three or  
> four working groups that have much more clearly defined missions and  
> scopes, we could cut them down to one meeting slot each. And if we  
> were to have separate management (chairs and secretaries) for each  
> working group, we could better manage the groups to timely delivery.
>
> So I'd like to toss out some ideas on how we might subdivide, and see  
> how you folks feel about this. I think the key to any success here  
> would be in scope management.
>
> What if we had the following groups:
>
> 1) SIPEM  -- SIP Extended Maintenance
>
> 2) SIPNEW -- New major functionality for SIP
>
> 3) SIPREQ -- Analysis of requirements raised by new applications or  
> SDO liaison
>
> 4) SIPUSE -- Using SIP to meet specific application requirements
>
>
>
> Here's how we might divide the work:
>
>
> SIPEM
> -----
>
> Scope: Maintenance of SIP 2.0 and development (as per RFC 3427) of  
> backward-compatible extensions driven by applications with near-term  
> deployment scenarios.
>
> Initial Milestone Tasks of SIPEM:
>
> 1)  Developing a SIP Guidebook, roughly the equivalent of the TCP  
> Roadmap, that defines what's "in" SIP and how the pieces fit together.
>
> 2)  GRUU
>
> 3)  Outbound
>
> 4)  Target-Dialog
>
> 5)  Certificate Usage
>
> 6)  Location Transport
>
> 7)  Loop Error Correction
>
> 8)  Connected Party Identity
>
> 9)  Hop Limit Diagnostics
>
> 10) TLS Usage
>
> 11) Answering Modes
>
> 12) Connection Reuse
>
> 13) Rejection of Anonymous Requests
>
> 14) Consent Mechanism
>
>
>
> SIPNEW
> ------
>
> Scope: Enhancement and evolution of SIP including architectural-level  
> requirements and (as per RFC 3427) extensions without requirements  
> for backward compatibility.
>
>
> Initial milestone tasks of SIPNEW
>
> 1)  Developing a "future roadmap" for the evolution of SIP
>
> 2)  Solving the RFC 3261 Routing Problem
>
> 3)  Use of SAML with SIP
>
> 4)  Response Identity
>
> 5)  Response Authentication
>
> 6)  End to Middle Requests
>
>
>
> SIPREQ
> ------
>
> Scope: Analysis of requirements raised by new applications of SIP in  
> IETF or in external SDOs (as per RFC 3427). Development of  
> requirements for changes to SIP or for usage guides in response to  
> applications requirements. Another way of wording this would be  
> "problem definition".
>
> Initial milestones and tasks of SIPREQ:
>
> 1)  Session Policy Requirements
>
>
>
> SIPUSE
> ------
>
> Scope: Guidance on how to use existing SIP specifications and  
> mechanisms including examples, call flows, test cases, error  
> avoidance, and so on. Review (as per RFC 3427) of SIP Event Packages.
>
>
> Initial milestones and tasks for SIPUSE:
>
> 1)  Service Examples
>
> 2)  Security Examples
>
> 3)  Race Condition Examples
>
> 4)  Session media policy mechanism
>
> 5)  Session policy package mechanism
>
> 6)  Service quality reporting mechanism
>
> 7)  URI List mechanism
>
> 8)  Subscriptions to Ad-Hoc Resource Lists mechanism
>
> 9)  Multiple REFER mechanism
>
> 10) Ad-Hoc Conferencing using URI lists mechanism
>
> 11) Call Control Transfer mechanism
>
> 12) Configuration Delivery mechanism
>
> 13) Emergency Calling using SIP (SOS) mechanism
>
>
>
>
> Note that I'm not entirely happy with the division of SIPPING into  
> SIPUSE and SIPREQ. While it seems like we spend a lot of time in  
> SIPPING debating requirements, there are currently a lot of  
> deliverables in this category.
>
>
> --
> 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
 --=_alternative 0046BB21C225711F_=-- --===============1420013538== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1420013538==-- From sip-bounces@ietf.org Fri Feb 24 09:21:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCdmj-0006bi-MB; Fri, 24 Feb 2006 09:19:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCdmh-0006bN-IO; Fri, 24 Feb 2006 09:19:03 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCdmg-0004H6-Vw; Fri, 24 Feb 2006 09:19:03 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 24 Feb 2006 06:19:03 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1OEJ2Hf023865; Fri, 24 Feb 2006 06:19:02 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Feb 2006 06:19:02 -0800 Received: from [10.21.112.47] ([10.21.112.47]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Feb 2006 06:19:01 -0800 Message-ID: <43FF15D4.4000209@cisco.com> Date: Fri, 24 Feb 2006 09:19:00 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hisham Khartabil Subject: Re: [Sip] Re: [Sipping] Thoughts on the Principle of Dividing and Conquering References: <231F5685-CCC1-41B1-997E-74AF67D9EBCE@softarmor.com> <6504c97d55581302c9e786a2ad8ce9b4@telio.no> In-Reply-To: <6504c97d55581302c9e786a2ad8ce9b4@telio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2006 14:19:01.0584 (UTC) FILETIME=[42655500:01C6394D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Cc: Cullen Jennings , Jon Peterson , Allison Mankin , "sip@ietf.org List" , Dean Willis , Sipping List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I don't see how any reorg like this will speed work, because I don't think the organization has much bearing on the speed of the work. That is mostly determined by when people write drafts, and whether they get sufficient attention units from others. Unfortunately, the creation of drafts seems to a large extent to be linked to the IETF meeting schedule. If we could find another way to motivate the submission of drafts that was as compelling as the meeting cutoff dates, but less bursty, then I think that could help a lot. Personally I find the division of work among WGs to be an irrelevant detail. It is simply a way to break up the work among meeting sessions. Whether there are four WGs with two sessions each, or one WG with eight sessions makes little difference to me. Breaking up into too many WGs could have a few negative consequences: - could result in inefficient use of meeting time. Meeting sessions are of a few fixed lengths. There is always going to be a bit of fragmentation waste when fitting agendas to meeting slots. The more WGs you split the work across the worse this becomes. - it will become harder to decide which WG to post questions to and submit new work to. We already have trouble with people cross posting or posting to the wrong list. I do understand that the load on the WG chairs is a problem. If more WGs helps that, then maybe it is worthwhile in spite of the above drawbacks. But perhaps there are other approaches to addressing that. E.g.: - more chairs per WG - division of responsibility for topics and drafts among chairs - division of responsibility for particular WG sessions at a meeting among the chairs I do think that new WGs would help if the charters can be structured such that they draw different communities of participants. I don't see the proposed division achieving that. I think I will still see the same people in the meetings regardless of what WG name is on the door of the session. Paul Hisham Khartabil wrote: > I support this idea. It will certainly reduce the load on chairs, but > does it really reduce the load on the rest of us? I guess not :) So I > only support this division because it allows focus and helps the > community to better understand the progress of SIP. > > BTW, how about a 5th one: SIP-P, SIP for P-headers ;) > > Hisham > > On Feb 24, 2006, at 1:30 AM, Dean Willis wrote: > >> I've been working on SIP and SIPPING and P2P-SIP agendas this week, >> and that started me thinking. >> >> We spun up SIPPING to take some of the load off of SIP, and in doing >> so tried to more narrowly-define the charters of both SIP and SIPPING >> relative to the previous SIP charter. >> >> When we started talking about P2P-SIP, we thought about bringing in >> the topic as part of SIPPING, but fairly quickly rejected that idea >> because it was clearly partitionable. >> >> This started me thinking -- could we further apply this principle of >> partitioning? >> >> Both SIP and SIPPING have grown into multi-year monsters, each with >> large charters and the need for multiple long-sessions at each IETF. >> They're tricky to chair, require lots of secretarial work, and are >> chronically late on deliverables (in large part because the chairs are >> acting like ADs instead of chairs). SPPING, once viewed as the kidney >> of SIP, now needs its own dialysis. >> >> Perhaps if we were to split these two working groups into three or >> four working groups that have much more clearly defined missions and >> scopes, we could cut them down to one meeting slot each. And if we >> were to have separate management (chairs and secretaries) for each >> working group, we could better manage the groups to timely delivery. >> >> So I'd like to toss out some ideas on how we might subdivide, and see >> how you folks feel about this. I think the key to any success here >> would be in scope management. >> >> What if we had the following groups: >> >> 1) SIPEM -- SIP Extended Maintenance >> >> 2) SIPNEW -- New major functionality for SIP >> >> 3) SIPREQ -- Analysis of requirements raised by new applications or >> SDO liaison >> >> 4) SIPUSE -- Using SIP to meet specific application requirements >> >> >> >> Here's how we might divide the work: >> >> >> SIPEM >> ----- >> >> Scope: Maintenance of SIP 2.0 and development (as per RFC 3427) of >> backward-compatible extensions driven by applications with near-term >> deployment scenarios. >> >> Initial Milestone Tasks of SIPEM: >> >> 1) Developing a SIP Guidebook, roughly the equivalent of the TCP >> Roadmap, that defines what's "in" SIP and how the pieces fit together. >> >> 2) GRUU >> >> 3) Outbound >> >> 4) Target-Dialog >> >> 5) Certificate Usage >> >> 6) Location Transport >> >> 7) Loop Error Correction >> >> 8) Connected Party Identity >> >> 9) Hop Limit Diagnostics >> >> 10) TLS Usage >> >> 11) Answering Modes >> >> 12) Connection Reuse >> >> 13) Rejection of Anonymous Requests >> >> 14) Consent Mechanism >> >> >> >> SIPNEW >> ------ >> >> Scope: Enhancement and evolution of SIP including architectural-level >> requirements and (as per RFC 3427) extensions without requirements for >> backward compatibility. >> >> >> Initial milestone tasks of SIPNEW >> >> 1) Developing a "future roadmap" for the evolution of SIP >> >> 2) Solving the RFC 3261 Routing Problem >> >> 3) Use of SAML with SIP >> >> 4) Response Identity >> >> 5) Response Authentication >> >> 6) End to Middle Requests >> >> >> >> SIPREQ >> ------ >> >> Scope: Analysis of requirements raised by new applications of SIP in >> IETF or in external SDOs (as per RFC 3427). Development of >> requirements for changes to SIP or for usage guides in response to >> applications requirements. Another way of wording this would be >> "problem definition". >> >> Initial milestones and tasks of SIPREQ: >> >> 1) Session Policy Requirements >> >> >> >> SIPUSE >> ------ >> >> Scope: Guidance on how to use existing SIP specifications and >> mechanisms including examples, call flows, test cases, error >> avoidance, and so on. Review (as per RFC 3427) of SIP Event Packages. >> >> >> Initial milestones and tasks for SIPUSE: >> >> 1) Service Examples >> >> 2) Security Examples >> >> 3) Race Condition Examples >> >> 4) Session media policy mechanism >> >> 5) Session policy package mechanism >> >> 6) Service quality reporting mechanism >> >> 7) URI List mechanism >> >> 8) Subscriptions to Ad-Hoc Resource Lists mechanism >> >> 9) Multiple REFER mechanism >> >> 10) Ad-Hoc Conferencing using URI lists mechanism >> >> 11) Call Control Transfer mechanism >> >> 12) Configuration Delivery mechanism >> >> 13) Emergency Calling using SIP (SOS) mechanism >> >> >> >> >> Note that I'm not entirely happy with the division of SIPPING into >> SIPUSE and SIPREQ. While it seems like we spend a lot of time in >> SIPPING debating requirements, there are currently a lot of >> deliverables in this category. >> >> >> -- >> Dean >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core 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 sip-bounces@ietf.org Fri Feb 24 09:35:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCe0j-0008HI-A7; Fri, 24 Feb 2006 09:33:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCe0h-0008H7-25 for sip@ietf.org; Fri, 24 Feb 2006 09:33:31 -0500 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCe0f-0004oj-Pc for sip@ietf.org; Fri, 24 Feb 2006 09:33:31 -0500 Received: from [127.0.0.1] (really [24.54.26.203]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060224143329.VHGR12914.mta9.adelphia.net@[127.0.0.1]>; Fri, 24 Feb 2006 09:33:29 -0500 Message-ID: <43FF42D7.8080809@ieee.org> Date: Fri, 24 Feb 2006 09:31:03 -0800 From: Mark Ellison Organization: Ellison Software Consulting, Inc. User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) 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-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: "Romascanu, Dan \(Dan\)" , dean.willis@softarmor.com Subject: [Sip] status on the SIP MIB modules? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, What is the current status for the SIP MIB modules? I notice that draft-ietf-sip-mib-09 is the latest revision of these module. It is my understanding -09 was submitted for IESG processing and that the current IESG status is "revised ID needed" , as of 2005-12-11 (see http://tools.ietf.org/wg/sip/). Also, I notice that this matter is not on the agenda for IETF #65. Also I have a question about the sipMethodSupportedIndex object with respect to IANA registrations. In checking the IANA registry for sip (http://www.iana.org/assignments/sip-parameters) I see a list of methods (e.g. ACK, BYE, CANCEL, INFO...). I am assuming the intent is that SIP method names are in the IANA registry, as are SIP option tags. Possibly this is an area of the SIP MIB modules in need of revision? Regards, Mark _______________________________________________ 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 sip-bounces@ietf.org Fri Feb 24 09:38:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCe3U-0001vs-KC; Fri, 24 Feb 2006 09:36:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCe3S-0001vC-Us; Fri, 24 Feb 2006 09:36:22 -0500 Received: from firewall.objectworld.com ([72.1.207.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCe3S-0004wV-FJ; Fri, 24 Feb 2006 09:36:22 -0500 Received: from photon.objectworld.com (photon.objectworld.com [192.168.1.2]) by firewall.objectworld.com (8.12.11/8.12.11) with ESMTP id k1OEa1Bd013637; Fri, 24 Feb 2006 09:36:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Thoughts on the Principle of Dividing and Conquering Date: Fri, 24 Feb 2006 09:36:01 -0500 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C506300C@photon.objectworld.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Thoughts on the Principle of Dividing and Conquering Thread-Index: AcY42afiPVEs19vcQ06b2UdoWVAPTgAShF1AAArhU+A= From: "Michael Slavitch" To: , , , X-Spam-Score: 1.20 (*) [Tag at 15.00] BIZ_TLD X-CanItPRO-Stream: outgoing Content-Disposition: inline X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.1.1 X-Spam-Score: 0.5 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Cc: fluffy@cisco.com, jon.peterson@neustar.biz, mankin@psg.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Given the growth of SIP, a look at how the W3 has grown and matured may=0A= well be a good idea.=0A= =0A= =0A= =20=0A= =20=0A= =20=0A= It is amazing what you can accomplish if you do not care who gets the=0A= credit.=20=0A= =20=0A= - Harry S Truman=0A= =0A= -----Original Message-----=0A= From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]=20=0A= Sent: February 24, 2006 5:37 AM=0A= To: dean.willis@softarmor.com; sip@ietf.org; sipping@ietf.org=0A= Cc: fluffy@cisco.com; jon.peterson@neustar.biz; mankin@psg.com=0A= Subject: RE: [Sip] Thoughts on the Principle of Dividing and Conquering=0A= =0A= Dean,=0A= =0A= (It seems we are creating the SIP Engineering Task Force (SPTF)... We=0A= already know that the S in SIP certainly does not stand for "Simple",=0A= but perhaps we should consider replacing "Session" with "Standards":=0A= "SIP is a mechnism that allows people to initiate and manage Working=0A= Groups and oher Standardization efforts mainly in the IETF, but also in=0A= other organizations such as but not limited to OMA, 3GPP, 3GPP2, ETSI,=0A= ATIS and MSF" :-)=20=0A= =0A= Seriously speaking, I support your idea in general. Here are some more=0A= specific points:=0A= - The most important improvent from my point of view would be the=0A= separation of "major new work" from "small extensions and maintenance".=0A= Currently, getting small, sometimes niche, extensions through the=0A= process seems to be taking too long, and that is creating some=0A= frustration. ("Implementing this takes two days, but getting this=0A= standardized in the IETF will take 2 years".) Of course, it is still=0A= important to review that the new things won't break the existing ones=0A= etc.=0A= - Having more time in the meetings is always good, although it seems we=0A= already have at the IETF something related to SIP at every slot...=20=0A= - With a lot of people having worked with SIP in the IETF for many years=0A= (forewver?), there should be many quite capable WG chairs available.=0A= - With the RAI area established, we have the higher level structure=0A= already in place for this type of move.=0A= =0A= Markus=0A= =0A= =0A= > -----Original Message-----=0A= > From: ext Dean Willis [mailto:dean.willis@softarmor.com]=0A= > Sent: 24 February, 2006 02:31=0A= > To: sip@ietf.org List; Sipping List=0A= > Cc: Cullen Jennings; Jon Peterson; Allison Mankin=0A= > Subject: [Sip] Thoughts on the Principle of Dividing and Conquering=0A= >=20=0A= >=20=0A= > I've been working on SIP and SIPPING and P2P-SIP agendas this week,=20=0A= > and that started me thinking.=0A= >=20=0A= > We spun up SIPPING to take some of the load off of SIP, and in doing=20= =0A= > so tried to more narrowly-define the charters of both SIP and SIPPING=20= =0A= > relative to the previous SIP charter.=0A= >=20=0A= > When we started talking about P2P-SIP, we thought about bringing in=20=0A= > the topic as part of SIPPING, but fairly quickly rejected that idea=20=0A= > because it was clearly partitionable.=0A= >=20=0A= > This started me thinking -- could we further apply this principle of=20= =0A= > partitioning?=0A= >=20=0A= > Both SIP and SIPPING have grown into multi-year monsters, each with=20=0A= > large charters and the need for multiple long-sessions at each IETF.=0A= > They're tricky to chair, require lots of secretarial work, and are=20=0A= > chronically late on deliverables (in large part because the chairs are=0A= =0A= > acting like ADs instead of chairs). SPPING, once viewed as the kidney=20= =0A= > of SIP, now needs its own dialysis.=0A= >=20=0A= > Perhaps if we were to split these two working groups into three or=20=0A= > four working groups that have much more clearly defined missions and=20= =0A= > scopes, we could cut them down to one meeting slot each. And if we=20=0A= > were to have separate management (chairs and secretaries) for each=20=0A= > working group, we could better manage the groups to timely delivery.=0A= >=20=0A= > So I'd like to toss out some ideas on how we might subdivide, and see=20= =0A= > how you folks feel about this. I think the key to any success here=20=0A= > would be in scope management.=0A= >=20=0A= > What if we had the following groups:=0A= >=20=0A= > 1) SIPEM -- SIP Extended Maintenance=0A= >=20=0A= > 2) SIPNEW -- New major functionality for SIP=0A= >=20=0A= > 3) SIPREQ -- Analysis of requirements raised by new applications or=20=0A= > SDO liaison=0A= >=20=0A= > 4) SIPUSE -- Using SIP to meet specific application requirements=0A= >=20=0A= >=20=0A= >=20=0A= > Here's how we might divide the work:=0A= >=20=0A= >=20=0A= > SIPEM=0A= > -----=0A= >=20=0A= > Scope: Maintenance of SIP 2.0 and development (as per RFC 3427) of=20=0A= > backward-compatible extensions driven by applications with near-term=20= =0A= > deployment scenarios.=0A= >=20=0A= > Initial Milestone Tasks of SIPEM:=0A= >=20=0A= > 1) Developing a SIP Guidebook, roughly the equivalent of the TCP=20=0A= > Roadmap, that defines what's "in" SIP and how the pieces fit together.=0A= >=20=0A= > 2) GRUU=0A= >=20=0A= > 3) Outbound=0A= >=20=0A= > 4) Target-Dialog=0A= >=20=0A= > 5) Certificate Usage=0A= >=20=0A= > 6) Location Transport=0A= >=20=0A= > 7) Loop Error Correction=0A= >=20=0A= > 8) Connected Party Identity=0A= >=20=0A= > 9) Hop Limit Diagnostics=0A= >=20=0A= > 10) TLS Usage=0A= >=20=0A= > 11) Answering Modes=0A= >=20=0A= > 12) Connection Reuse=0A= >=20=0A= > 13) Rejection of Anonymous Requests=0A= >=20=0A= > 14) Consent Mechanism=0A= >=20=0A= >=20=0A= >=20=0A= > SIPNEW=0A= > ------=0A= >=20=0A= > Scope: Enhancement and evolution of SIP including architectural-level=20= =0A= > requirements and (as per RFC 3427) extensions without requirements for=0A= =0A= > backward compatibility.=0A= >=20=0A= >=20=0A= > Initial milestone tasks of SIPNEW=0A= >=20=0A= > 1) Developing a "future roadmap" for the evolution of SIP=0A= >=20=0A= > 2) Solving the RFC 3261 Routing Problem=0A= >=20=0A= > 3) Use of SAML with SIP=0A= >=20=0A= > 4) Response Identity=0A= >=20=0A= > 5) Response Authentication=0A= >=20=0A= > 6) End to Middle Requests=0A= >=20=0A= >=20=0A= >=20=0A= > SIPREQ=0A= > ------=0A= >=20=0A= > Scope: Analysis of requirements raised by new applications of SIP in=20= =0A= > IETF or in external SDOs (as per RFC 3427). Development of=20=0A= > requirements for changes to SIP or for usage guides in response to=20=0A= > applications requirements. Another way of wording this would be=20=0A= > "problem definition".=0A= >=20=0A= > Initial milestones and tasks of SIPREQ:=0A= >=20=0A= > 1) Session Policy Requirements=0A= >=20=0A= >=20=0A= >=20=0A= > SIPUSE=0A= > ------=0A= >=20=0A= > Scope: Guidance on how to use existing SIP specifications and=20=0A= > mechanisms including examples, call flows, test cases, error=20=0A= > avoidance, and so on. Review (as per RFC 3427) of SIP Event Packages.=0A= >=20=0A= >=20=0A= > Initial milestones and tasks for SIPUSE:=0A= >=20=0A= > 1) Service Examples=0A= >=20=0A= > 2) Security Examples=0A= >=20=0A= > 3) Race Condition Examples=0A= >=20=0A= > 4) Session media policy mechanism=0A= >=20=0A= > 5) Session policy package mechanism=0A= >=20=0A= > 6) Service quality reporting mechanism=0A= >=20=0A= > 7) URI List mechanism=0A= >=20=0A= > 8) Subscriptions to Ad-Hoc Resource Lists mechanism=0A= >=20=0A= > 9) Multiple REFER mechanism=0A= >=20=0A= > 10) Ad-Hoc Conferencing using URI lists mechanism=0A= >=20=0A= > 11) Call Control Transfer mechanism=0A= >=20=0A= > 12) Configuration Delivery mechanism=0A= >=20=0A= > 13) Emergency Calling using SIP (SOS) mechanism=0A= >=20=0A= >=20=0A= >=20=0A= >=20=0A= > Note that I'm not entirely happy with the division of SIPPING into=20=0A= > SIPUSE and SIPREQ. While it seems like we spend a lot of time in=20=0A= > SIPPING debating requirements, there are currently a lot of=20=0A= > deliverables in this category.=0A= >=20=0A= >=20=0A= > --=0A= > Dean=0A= >=20=0A= > _______________________________________________=0A= > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip=0A= > This list is for NEW development of the core SIP Protocol=0A= > Use sip-implementors@cs.columbia.edu for questions on current sip=0A= > Use sipping@ietf.org for new developments on the application of sip=0A= >=20=0A= =0A= _______________________________________________=0A= Sip mailing list https://www1.ietf.org/mailman/listinfo/sip=0A= This list is for NEW development of the core SIP Protocol=0A= Use sip-implementors@cs.columbia.edu for questions on current sip=0A= Use sipping@ietf.org for new developments on the application of sip=0A= =0A= =0A= --=20=0A= =0A= =0A= -----------------------------------------------=0D=0A= =0D=0A= This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. =0D=0A= =0D=0A= Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp= .=20=0A= _______________________________________________ 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 sip-bounces@ietf.org Fri Feb 24 09:44:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCe9Q-0005bx-Os; Fri, 24 Feb 2006 09:42:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCe9N-0005ZP-QT; Fri, 24 Feb 2006 09:42:29 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCe9N-0005BO-2i; Fri, 24 Feb 2006 09:42:29 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k1OEfhmR025474; Fri, 24 Feb 2006 16:41:46 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Feb 2006 16:42:25 +0200 Received: from [10.162.253.169] ([10.162.253.169]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 24 Feb 2006 16:42:23 +0200 Message-ID: <43FF1B42.5050304@nokia.com> Date: Fri, 24 Feb 2006 16:42:10 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: ext Paul Kyzivat Subject: Re: [Sip] Re: [Sipping] Thoughts on the Principle of Dividing and Conquering References: <231F5685-CCC1-41B1-997E-74AF67D9EBCE@softarmor.com> <6504c97d55581302c9e786a2ad8ce9b4@telio.no> <43FF15D4.4000209@cisco.com> In-Reply-To: <43FF15D4.4000209@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2006 14:42:23.0786 (UTC) FILETIME=[862C60A0:01C63950] X-Spam-Score: 0.0 (/) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 Cc: Cullen Jennings , Jon Peterson , Allison Mankin , "sip@ietf.org List" , Dean Willis , Sipping List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Agree with Paul. A reorg will likely not increase the throughput, since the increased overhead will cause more context-switch for the same set of people, and like Paul mentions, just create general confusion of "I need X; wonder which of the ~7 sippishy WGs is now the correct place to go ask for that?" If chair bandwidth is the problem, may I suggest hiring more chairs to existing WGs, or replacing the existing ones, who've been doing an excellent job for so many years now, that they really start to deserve a break. Of course, both ways will suffer from the same problem of "promoting" more good engineers to managers. IMHO, we need more engineers, not more managers. Cheers, Aki ext Paul Kyzivat wrote: > I don't see how any reorg like this will speed work, because I don't > think the organization has much bearing on the speed of the work. That > is mostly determined by when people write drafts, and whether they get > sufficient attention units from others. Unfortunately, the creation of > drafts seems to a large extent to be linked to the IETF meeting > schedule. If we could find another way to motivate the submission of > drafts that was as compelling as the meeting cutoff dates, but less > bursty, then I think that could help a lot. > > Personally I find the division of work among WGs to be an irrelevant > detail. It is simply a way to break up the work among meeting sessions. > Whether there are four WGs with two sessions each, or one WG with eight > sessions makes little difference to me. > > Breaking up into too many WGs could have a few negative consequences: > - could result in inefficient use of meeting time. Meeting sessions > are of a few fixed lengths. There is always going to be a bit of > fragmentation waste when fitting agendas to meeting slots. The more > WGs you split the work across the worse this becomes. > - it will become harder to decide which WG to post questions to and > submit new work to. We already have trouble with people cross posting > or posting to the wrong list. > > I do understand that the load on the WG chairs is a problem. If more WGs > helps that, then maybe it is worthwhile in spite of the above drawbacks. > But perhaps there are other approaches to addressing that. E.g.: > - more chairs per WG > - division of responsibility for topics and drafts among chairs > - division of responsibility for particular WG sessions at a > meeting among the chairs > > I do think that new WGs would help if the charters can be structured > such that they draw different communities of participants. I don't see > the proposed division achieving that. I think I will still see the same > people in the meetings regardless of what WG name is on the door of the > session. > > Paul > > Hisham Khartabil wrote: >> I support this idea. It will certainly reduce the load on chairs, but >> does it really reduce the load on the rest of us? I guess not :) So I >> only support this division because it allows focus and helps the >> community to better understand the progress of SIP. >> >> BTW, how about a 5th one: SIP-P, SIP for P-headers ;) >> >> Hisham >> >> On Feb 24, 2006, at 1:30 AM, Dean Willis wrote: >> >>> I've been working on SIP and SIPPING and P2P-SIP agendas this week, >>> and that started me thinking. >>> >>> We spun up SIPPING to take some of the load off of SIP, and in doing >>> so tried to more narrowly-define the charters of both SIP and SIPPING >>> relative to the previous SIP charter. >>> >>> When we started talking about P2P-SIP, we thought about bringing in >>> the topic as part of SIPPING, but fairly quickly rejected that idea >>> because it was clearly partitionable. >>> >>> This started me thinking -- could we further apply this principle of >>> partitioning? >>> >>> Both SIP and SIPPING have grown into multi-year monsters, each with >>> large charters and the need for multiple long-sessions at each IETF. >>> They're tricky to chair, require lots of secretarial work, and are >>> chronically late on deliverables (in large part because the chairs >>> are acting like ADs instead of chairs). SPPING, once viewed as the >>> kidney of SIP, now needs its own dialysis. >>> >>> Perhaps if we were to split these two working groups into three or >>> four working groups that have much more clearly defined missions and >>> scopes, we could cut them down to one meeting slot each. And if we >>> were to have separate management (chairs and secretaries) for each >>> working group, we could better manage the groups to timely delivery. >>> >>> So I'd like to toss out some ideas on how we might subdivide, and see >>> how you folks feel about this. I think the key to any success here >>> would be in scope management. >>> >>> What if we had the following groups: >>> >>> 1) SIPEM -- SIP Extended Maintenance >>> >>> 2) SIPNEW -- New major functionality for SIP >>> >>> 3) SIPREQ -- Analysis of requirements raised by new applications or >>> SDO liaison >>> >>> 4) SIPUSE -- Using SIP to meet specific application requirements >>> >>> >>> >>> Here's how we might divide the work: >>> >>> >>> SIPEM >>> ----- >>> >>> Scope: Maintenance of SIP 2.0 and development (as per RFC 3427) of >>> backward-compatible extensions driven by applications with near-term >>> deployment scenarios. >>> >>> Initial Milestone Tasks of SIPEM: >>> >>> 1) Developing a SIP Guidebook, roughly the equivalent of the TCP >>> Roadmap, that defines what's "in" SIP and how the pieces fit together. >>> >>> 2) GRUU >>> >>> 3) Outbound >>> >>> 4) Target-Dialog >>> >>> 5) Certificate Usage >>> >>> 6) Location Transport >>> >>> 7) Loop Error Correction >>> >>> 8) Connected Party Identity >>> >>> 9) Hop Limit Diagnostics >>> >>> 10) TLS Usage >>> >>> 11) Answering Modes >>> >>> 12) Connection Reuse >>> >>> 13) Rejection of Anonymous Requests >>> >>> 14) Consent Mechanism >>> >>> >>> >>> SIPNEW >>> ------ >>> >>> Scope: Enhancement and evolution of SIP including architectural-level >>> requirements and (as per RFC 3427) extensions without requirements >>> for backward compatibility. >>> >>> >>> Initial milestone tasks of SIPNEW >>> >>> 1) Developing a "future roadmap" for the evolution of SIP >>> >>> 2) Solving the RFC 3261 Routing Problem >>> >>> 3) Use of SAML with SIP >>> >>> 4) Response Identity >>> >>> 5) Response Authentication >>> >>> 6) End to Middle Requests >>> >>> >>> >>> SIPREQ >>> ------ >>> >>> Scope: Analysis of requirements raised by new applications of SIP in >>> IETF or in external SDOs (as per RFC 3427). Development of >>> requirements for changes to SIP or for usage guides in response to >>> applications requirements. Another way of wording this would be >>> "problem definition". >>> >>> Initial milestones and tasks of SIPREQ: >>> >>> 1) Session Policy Requirements >>> >>> >>> >>> SIPUSE >>> ------ >>> >>> Scope: Guidance on how to use existing SIP specifications and >>> mechanisms including examples, call flows, test cases, error >>> avoidance, and so on. Review (as per RFC 3427) of SIP Event Packages. >>> >>> >>> Initial milestones and tasks for SIPUSE: >>> >>> 1) Service Examples >>> >>> 2) Security Examples >>> >>> 3) Race Condition Examples >>> >>> 4) Session media policy mechanism >>> >>> 5) Session policy package mechanism >>> >>> 6) Service quality reporting mechanism >>> >>> 7) URI List mechanism >>> >>> 8) Subscriptions to Ad-Hoc Resource Lists mechanism >>> >>> 9) Multiple REFER mechanism >>> >>> 10) Ad-Hoc Conferencing using URI lists mechanism >>> >>> 11) Call Control Transfer mechanism >>> >>> 12) Configuration Delivery mechanism >>> >>> 13) Emergency Calling using SIP (SOS) mechanism >>> >>> >>> >>> >>> Note that I'm not entirely happy with the division of SIPPING into >>> SIPUSE and SIPREQ. While it seems like we spend a lot of time in >>> SIPPING debating requirements, there are currently a lot of >>> deliverables in this category. >>> >>> >>> -- >>> Dean >>> >>> _______________________________________________ >>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>> This list is for NEW development of the application of SIP >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sip@ietf.org for new developments of core 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 sip-bounces@ietf.org Fri Feb 24 09:47:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCeCc-0000ln-Jp; Fri, 24 Feb 2006 09:45:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCeCa-0000jA-O4; Fri, 24 Feb 2006 09:45:48 -0500 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCeCZ-0005Ji-Eb; Fri, 24 Feb 2006 09:45:48 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k1OEjkY7014465; Fri, 24 Feb 2006 08:45:46 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k1OEjg205805; Fri, 24 Feb 2006 08:45:42 -0600 (CST) Message-ID: <43FF1C16.2050800@lucent.com> Date: Fri, 24 Feb 2006 08:45:42 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis References: <231F5685-CCC1-41B1-997E-74AF67D9EBCE@softarmor.com> In-Reply-To: <231F5685-CCC1-41B1-997E-74AF67D9EBCE@softarmor.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Cc: "sip@ietf.org List" , Sipping List Subject: [Sip] Re: [Sipping] Thoughts on the Principle of Dividing and Conquering X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0222732096==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0222732096== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090609080806050900080904" This is a cryptographically signed message in MIME format. --------------ms090609080806050900080904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dean Willis wrote: > I've been working on SIP and SIPPING and P2P-SIP agendas this week, and > that started me thinking. [...] Others have commented about the pros and cons of this approach, so I won't go into that. Instead, I have a different proposal. How about doing something like what the RTG area and the SEC area have done, namely, establishing a directorate and in this directorate, put in the core people who would be responsible for vetting I-Ds on various aspects of SIP. We are doing this to a great degree anyway, right now. Every I-D gets scrutiny by a core group of people who provide helpful comments. Why not make this arrangement more formal and have someone from the directorate work with a I-D authors to get it to completion in a short time? Informally, we can divide the directorate into folks responsible for SIPEM, SIPNEW, SIPREQ, and SIPUSE. Each sub-area in the directorate will ensure that the I-Ds assigned to the core group of people there get finished on time. And, just for fun, if we do end up breaking into baby SIPs, how about name changes: > What if we had the following groups: > > 1) SIPEM -- SIP Extended Maintenance SPEM? > 2) SIPNEW -- New major functionality for SIP SINEW? > 3) SIPREQ -- Analysis of requirements raised by new applications or SDO > liaison SHREK (yea, it's a stretch). > 4) SIPUSE -- Using SIP to meet specific application requirements SPOUSE? - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) --------------ms090609080806050900080904 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAyMjQxNDQ1NDJaMCMGCSqGSIb3DQEJ BDEWBBTwBF1JyrDHm9RhOUZUyXWUp8MvrjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGACCXPdjEMN2pLoKfDbUqmhixtB8+19f0S17JTGR+zBkQRXUZnkQeF P95i3m61bxmOpnix4FKb/NpbWkNXsgnYX1lUfKXb+BiGIP6quyR1QWGu57S1NA/z0sBuFpxf 3hahQcESzWzUwNe6+bBLAvG6K4bpSK43NU7k8GQ0mhgC6q8AAAAAAAA= --------------ms090609080806050900080904-- --===============0222732096== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0222732096==-- From sip-bounces@ietf.org Fri Feb 24 10:35:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCewE-0007Gp-4t; Fri, 24 Feb 2006 10:32:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCewC-0007FH-5U; Fri, 24 Feb 2006 10:32:56 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCewA-0006b2-Sp; Fri, 24 Feb 2006 10:32:56 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 24 Feb 2006 07:32:54 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1OFWrVb021718; Fri, 24 Feb 2006 07:32:53 -0800 (PST) Received: from [216.102.208.11] (sjc-vpn6-570.cisco.com [10.21.122.58]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k1OFZPrX012330; Fri, 24 Feb 2006 07:35:25 -0800 Message-ID: <43FF2722.3030205@cisco.com> Date: Fri, 24 Feb 2006 07:32:50 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] Re: [Sipping] Thoughts on the Principle of Dividing and Conquering References: <231F5685-CCC1-41B1-997E-74AF67D9EBCE@softarmor.com> <6504c97d55581302c9e786a2ad8ce9b4@telio.no> <43FF15D4.4000209@cisco.com> In-Reply-To: <43FF15D4.4000209@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1845; t=1140795327; x=1141227527; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=mat@cisco.com; z=From:Michael=20Thomas=20 |Subject:Re=3A=20[Sip]=20Re=3A=20[Sipping]=20Thoughts=20on=20the=20Principle=20of =20Dividing=20and=0A=20Conquering |To:Paul=20Kyzivat=20; X=v=3Dmtcc.com=3B=20h=3DJYsYB81FK97Tj9aPEA62jL9+bm8=3D; b=cNYj70SrsosheV15j+6C5vSETQRmVqRP0vI3lusZlRCvViCgtSfsjHrYxgkhT0Gf1D9z0XCE 5EUwC+b4wCE57DzZ8P4cZ7AhZFse+t0jyEucpFQ+eVL9UF6zGAkW/0YpxA0rp3nh/PrPPgANtyx t60sdmCJGxC2+7VSMq9ibYrE=; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Cullen Jennings , Jon Peterson , Allison Mankin , "sip@ietf.org List" , Dean Willis , Sipping List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: > I don't see how any reorg like this will speed work, because I don't > think the organization has much bearing on the speed of the work [] My suspicion is that Paul is right. My visualization of SIP these days seems much more akin to a voracious black hole sucking in all available matter rather than a smart cocktail tippled through a dainty straw. Maybe the base problem is that the energy barrier to new work is generally too low? And that fairly open-ended charters inevitably lead to far too many good ideas? Perhaps instead of dividing along the lines that Dean was suggesting, we should require them to actually *charter* a fixed-function working group that actually has a set of goals and ::drum roll:: a criteria to shut itself down. Including new WG chairs. Dean also pointed at "evolution". What does that mean? Is speciation a good or bad thing? What Dean proposes seems more top-down: kind of like -- dare I say -- eugenics. The one thing I would observe is that speciation is a fact whether the IETF likes it or not -- if people find utility in a base good mutation, they will live with the accreted bad mutations that happened gratuitiously. So the real question in my mind is not whether we can stop speciation, so much as whether we can manage the gene pool and try to keep out the deleterious mutations. And for that, it seems that placing each new problem more in a box might help since it becomes easier to say no when somebody proposes to sprout a limb from a forehead, and suchlike. On the other hand, a "problem" wg structure would seemingly just donate its dna at the beginning (ie its Y chromosome). Where would the check in development happen? In "new"? Which essentially becomes one giant species non-specific womb? Hmm. Anyway, enough of this :) Mike _______________________________________________ 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 sip-bounces@ietf.org Fri Feb 24 10:38:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCezP-0000ds-Bx; Fri, 24 Feb 2006 10:36:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCezN-0000bQ-0W; Fri, 24 Feb 2006 10:36:13 -0500 Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCezI-0006fh-MC; Fri, 24 Feb 2006 10:36:12 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k1OFVxW29586; Fri, 24 Feb 2006 10:31:59 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Re: [Sipping] Thoughts on the Principle of Dividing andConquering Date: Fri, 24 Feb 2006 09:36:05 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: [Sipping] Thoughts on the Principle of Dividing andConquering Thread-Index: AcY5URKrW1W5HDYuSyu2tvE4syGa0AABm/Cw From: "Mary Barnes" To: "Vijay K. Gurbani" , "Dean Willis" X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: sip@ietf.org, Sipping List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think Vijay's suggestion of a directorate approach is a good idea (the names, I think are a bad idea). As others have suggested making separate WGs doesn't really solve the problem that there's just lots of work in this area. The directorate approach should help offload the WG chairs.=20 Mary -----Original Message----- From: Vijay K. Gurbani [mailto:vkg@lucent.com]=20 Sent: Friday, February 24, 2006 8:46 AM To: Dean Willis Cc: sip@ietf.org List; Sipping List Subject: [Sip] Re: [Sipping] Thoughts on the Principle of Dividing andConquering Dean Willis wrote: > I've been working on SIP and SIPPING and P2P-SIP agendas this week, and=20 > that started me thinking. [...] Others have commented about the pros and cons of this approach, so I won't go into that. Instead, I have a different proposal. How about doing something like what the RTG area and the SEC area have done, namely, establishing a directorate and in this directorate, put in the core people who would be responsible for vetting I-Ds on various aspects of SIP. We are doing this to a great degree anyway, right now. Every I-D gets scrutiny by a core group of people who provide helpful comments. Why not make this arrangement more formal and have someone from the directorate work with a I-D authors to get it to completion in a short time? Informally, we can divide the directorate into folks responsible for SIPEM, SIPNEW, SIPREQ, and SIPUSE. Each sub-area in the directorate will ensure that the I-Ds assigned to the core group of people there get finished on time. And, just for fun, if we do end up breaking into baby SIPs, how about name changes: > What if we had the following groups: >=20 > 1) SIPEM -- SIP Extended Maintenance SPEM? > 2) SIPNEW -- New major functionality for SIP SINEW? > 3) SIPREQ -- Analysis of requirements raised by new applications or SDO=20 > liaison SHREK (yea, it's a stretch). > 4) SIPUSE -- Using SIP to meet specific application requirements SPOUSE? - vijay --=20 Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ 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 sip-bounces@ietf.org Fri Feb 24 10:48:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCf9c-0008U4-MZ; Fri, 24 Feb 2006 10:46:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCf9a-0008Tm-Qk; Fri, 24 Feb 2006 10:46:46 -0500 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCf9Z-0006yA-5v; Fri, 24 Feb 2006 10:46:46 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id DC97F6C01C; Fri, 24 Feb 2006 10:46:41 -0500 (EST) From: "Dale R. Worley" To: Sip , Sipping In-Reply-To: <6504c97d55581302c9e786a2ad8ce9b4@telio.no> References: <231F5685-CCC1-41B1-997E-74AF67D9EBCE@softarmor.com> <6504c97d55581302c9e786a2ad8ce9b4@telio.no> Content-Type: text/plain Date: Fri, 24 Feb 2006 10:46:41 -0500 Message-Id: <1140796001.5055.6.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [Sip] Re: [Sipping] Thoughts on the Principle of Dividing and Conquering X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Fri, 2006-02-24 at 11:59 +0100, Hisham Khartabil wrote: > I support this idea. It will certainly reduce the load on chairs, but > does it really reduce the load on the rest of us? I guess not :) This approach (whether we call it more WGs or a directorate or whatever) brings in more people to do WG Chair work. If WG Chairs are the current bottleneck, it will help. Will it reduce the load on the rest of us? If we all attend all the various SIP WGs, it will not. But I think that SIP is approaching the point where individuals do not attempt to track everything that is going on in SIP. I know that I don't; there are even areas that are crucial to my employer that I don't track because my employer has someone else who tracks that. If we can sensibly partition SIP into areas of interest, I think that you will find that many people will be interested in only a few areas. Right now, all those people have to attend all the sessions; if the sessions are partitioned by area of interest, they no longer have to. Dale _______________________________________________ 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 sip-bounces@ietf.org Fri Feb 24 11:21:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCffo-0005B6-0R; Fri, 24 Feb 2006 11:20:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCffl-0005AI-BU; Fri, 24 Feb 2006 11:20:01 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCffk-0000E1-LJ; Fri, 24 Feb 2006 11:20:01 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 24 Feb 2006 08:20:00 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,144,1139212800"; d="scan'208,217"; a="22543364:sNHT47056600" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1OGJxqM025068; Fri, 24 Feb 2006 11:19:59 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Feb 2006 11:19:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sipping] Re: [Sip] Thoughts on the Principle of Dividing andConquering Date: Fri, 24 Feb 2006 11:19:58 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30124552C@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Re: [Sip] Thoughts on the Principle of Dividing andConquering Thread-Index: AcY5QUhG5qVnqeYTQjG4tMq6H2fJoAAHDXnQ From: "Michael Hammer \(mhammer\)" To: "Avshalom Houri" , "Dean Willis" X-OriginalArrivalTime: 24 Feb 2006 16:19:59.0180 (UTC) FILETIME=[284298C0:01C6395E] X-Spam-Score: 0.1 (/) X-Scan-Signature: 09f2eafe5f7c426554d5f494540a89cd Cc: "Cullen Jennings \(fluffy\)" , sip@ietf.org, Sipping List , Jon Peterson , Allison Mankin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1939309310==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1939309310== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6395E.27FF3C27" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6395E.27FF3C27 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Oh, this is starting to sound scary. =20 N SIP WGs x M IETF SIP-related groups x P non-IETF SIP-related groups = =3D Who's on First? =20 (Abbott and Costello reference) =20 We will need a SIP WG just to manage the liaisons for each pair of groups. =20 BTW, how do we clone Dean? :) =20 If this is really just an administrative issue. Could not the WG just have extra multiple secretaries to help manage each sub-category of drafts? =20 Mike =20 ________________________________ From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com]=20 Sent: Friday, February 24, 2006 7:53 AM To: Dean Willis Cc: Cullen Jennings (fluffy); sip@ietf.org List; Sipping List; Jon Peterson; Allison Mankin Subject: [Sipping] Re: [Sip] Thoughts on the Principle of Dividing andConquering =09 =09 I do think that a step in this direction is very necessary.=20 We will have to finalize the details as:=20 =09 * How this relates to SPEERMINT and to P2P-SIP?=20 =09 * A lot of very SIP related work is done MIDCOM, MMUSIC, IPTEL, ENUM, XCON, BEHAVE and=20 probably more groups. How the SIP related work will fit into the new framework?=20 =09 * The SIP work in the IETF has become so big and very connected with other standard organizations=20 that we really need to think about all the issues and there may be a need to a deeper change as=20 creating a sub organization in the IETF for SIP that will meet in other dates (maybe collocated with other=20 organization meetings from time to time as 3GPP and OMA. This way we may have much more time to deal=20 with the necessary issues.=20 =09 Maybe we should have a BOF at the Dallas IETF for this? Although I am not sure we will have=20 a big enough room or it will be easy to chair such a meeting. :) =09 --Avshalom=20 =09 Dean Willis wrote on 24-02-2006 02:30:44 AM: =09 > I've been working on SIP and SIPPING and P2P-SIP agendas this week, =20 > and that started me thinking. >=20 > We spun up SIPPING to take some of the load off of SIP, and in doing =20 > so tried to more narrowly-define the charters of both SIP and SIPPING =20 > relative to the previous SIP charter. >=20 > When we started talking about P2P-SIP, we thought about bringing in =20 > the topic as part of SIPPING, but fairly quickly rejected that idea =20 > because it was clearly partitionable. >=20 > This started me thinking -- could we further apply this principle of =20 > partitioning? >=20 > Both SIP and SIPPING have grown into multi-year monsters, each with =20 > large charters and the need for multiple long-sessions at each IETF. =20 > They're tricky to chair, require lots of secretarial work, and are =20 > chronically late on deliverables (in large part because the chairs =20 > are acting like ADs instead of chairs). SPPING, once viewed as the =20 > kidney of SIP, now needs its own dialysis. >=20 > Perhaps if we were to split these two working groups into three or =20 > four working groups that have much more clearly defined missions and =20 > scopes, we could cut them down to one meeting slot each. And if we =20 > were to have separate management (chairs and secretaries) for each =20 > working group, we could better manage the groups to timely delivery. >=20 > So I'd like to toss out some ideas on how we might subdivide, and see =20 > how you folks feel about this. I think the key to any success here =20 > would be in scope management. >=20 > What if we had the following groups: >=20 > 1) SIPEM -- SIP Extended Maintenance >=20 > 2) SIPNEW -- New major functionality for SIP >=20 > 3) SIPREQ -- Analysis of requirements raised by new applications or =20 > SDO liaison >=20 > 4) SIPUSE -- Using SIP to meet specific application requirements >=20 >=20 >=20 > Here's how we might divide the work: >=20 >=20 > SIPEM > ----- >=20 > Scope: Maintenance of SIP 2.0 and development (as per RFC 3427) of =20 > backward-compatible extensions driven by applications with near-term =20 > deployment scenarios. >=20 > Initial Milestone Tasks of SIPEM: >=20 > 1) Developing a SIP Guidebook, roughly the equivalent of the TCP =20 > Roadmap, that defines what's "in" SIP and how the pieces fit together. >=20 > 2) GRUU >=20 > 3) Outbound >=20 > 4) Target-Dialog >=20 > 5) Certificate Usage >=20 > 6) Location Transport >=20 > 7) Loop Error Correction >=20 > 8) Connected Party Identity >=20 > 9) Hop Limit Diagnostics >=20 > 10) TLS Usage >=20 > 11) Answering Modes >=20 > 12) Connection Reuse >=20 > 13) Rejection of Anonymous Requests >=20 > 14) Consent Mechanism >=20 >=20 >=20 > SIPNEW > ------ >=20 > Scope: Enhancement and evolution of SIP including architectural-level =20 > requirements and (as per RFC 3427) extensions without requirements =20 > for backward compatibility. >=20 >=20 > Initial milestone tasks of SIPNEW >=20 > 1) Developing a "future roadmap" for the evolution of SIP >=20 > 2) Solving the RFC 3261 Routing Problem >=20 > 3) Use of SAML with SIP >=20 > 4) Response Identity >=20 > 5) Response Authentication >=20 > 6) End to Middle Requests >=20 >=20 >=20 > SIPREQ > ------ >=20 > Scope: Analysis of requirements raised by new applications of SIP in =20 > IETF or in external SDOs (as per RFC 3427). Development of =20 > requirements for changes to SIP or for usage guides in response to =20 > applications requirements. Another way of wording this would be =20 > "problem definition". >=20 > Initial milestones and tasks of SIPREQ: >=20 > 1) Session Policy Requirements >=20 >=20 >=20 > SIPUSE > ------ >=20 > Scope: Guidance on how to use existing SIP specifications and > mechanisms including examples, call flows, test cases, error =20 > avoidance, and so on. Review (as per RFC 3427) of SIP Event Packages. >=20 >=20 > Initial milestones and tasks for SIPUSE: >=20 > 1) Service Examples >=20 > 2) Security Examples >=20 > 3) Race Condition Examples >=20 > 4) Session media policy mechanism >=20 > 5) Session policy package mechanism >=20 > 6) Service quality reporting mechanism >=20 > 7) URI List mechanism >=20 > 8) Subscriptions to Ad-Hoc Resource Lists mechanism >=20 > 9) Multiple REFER mechanism >=20 > 10) Ad-Hoc Conferencing using URI lists mechanism >=20 > 11) Call Control Transfer mechanism >=20 > 12) Configuration Delivery mechanism >=20 > 13) Emergency Calling using SIP (SOS) mechanism >=20 >=20 >=20 >=20 > Note that I'm not entirely happy with the division of SIPPING into =20 > SIPUSE and SIPREQ. While it seems like we spend a lot of time in =20 > SIPPING debating requirements, there are currently a lot of =20 > deliverables in this category. >=20 >=20 > -- > Dean >=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 =09 ------_=_NextPart_001_01C6395E.27FF3C27 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Oh, this is starting to sound scary.
 
N SIP WGs x M IETF SIP-related groups x P non-IETF = SIP-related=20 groups =3D Who's on First? 
(Abbott and Costello reference)
 
We will need a SIP WG just to manage the liaisons for = each pair of=20 groups.
 
BTW, how do we clone Dean? :)
 
If this is really just an administrative issue.  = Could not=20 the WG just have extra multiple secretaries to help manage each=20 sub-category of drafts?
 
Mike
 

From: Avshalom Houri=20 [mailto:AVSHALOM@il.ibm.com]
Sent: Friday, February 24, = 2006 7:53=20 AM
To: Dean Willis
Cc: Cullen Jennings (fluffy);=20 sip@ietf.org List; Sipping List; Jon Peterson; Allison=20 Mankin
Subject: [Sipping] Re: [Sip] Thoughts on the = Principle of=20 Dividing andConquering


I do think that a = step in this=20 direction is very necessary.
We=20 will have to finalize the details as:

* How this relates to SPEERMINT and to P2P-SIP? =

* A lot of very SIP related work is done = MIDCOM,=20 MMUSIC, IPTEL, ENUM, XCON, BEHAVE and
probably more groups. How the SIP related work will fit into = the new=20 framework?

* The = SIP work in=20 the IETF has become so big and very connected with other standard=20 organizations
that we = really need=20 to think about all the issues and there may be a need to a deeper = change=20 as
creating a sub = organization in=20 the IETF for SIP that will meet in other dates (maybe collocated with=20 other
organization = meetings from=20 time to time as 3GPP and OMA. This way we may have much more time to=20 deal
with the necessary = issues.

Maybe we = should have a=20 BOF at the Dallas IETF for this? Although I am not sure we will = have=20
a big enough room or it will = be easy to=20 chair such a meeting. :)

--Avshalom

Dean Willis=20 <dean.willis@softarmor.com> wrote on 24-02-2006 02:30:44 = AM:

>=20 I've been working on SIP and SIPPING and P2P-SIP agendas this week,=20  
> and that started me thinking.
>
> We spun = up=20 SIPPING to take some of the load off of SIP, and in doing =  
> so=20 tried to more narrowly-define the charters of both SIP and SIPPING=20  
> relative to the previous SIP charter.
>
> = When we=20 started talking about P2P-SIP, we thought about bringing in =  
> the=20 topic as part of SIPPING, but fairly quickly rejected that idea =  
>=20 because it was clearly partitionable.
>
> This started me = thinking -- could we further apply this principle of  
>=20 partitioning?
>
> Both SIP and SIPPING have grown into = multi-year=20 monsters, each with  
> large charters and the need for = multiple=20 long-sessions at each IETF.  
> They're tricky to chair, = require=20 lots of secretarial work, and are  
> chronically late on=20 deliverables (in large part because the chairs  
> are = acting like=20 ADs instead of chairs). SPPING, once viewed as the  
> = kidney of=20 SIP, now needs its own dialysis.
>
> Perhaps if we were = to split=20 these two working groups into three or  
> four working = groups that=20 have much more clearly defined missions and  
> scopes, we = could=20 cut them down to one meeting slot each. And if we  
> were = to have=20 separate management (chairs and secretaries) for each  
> = working=20 group, we could better manage the groups to timely delivery.
> =
>=20 So I'd like to toss out some ideas on how we might subdivide, and see=20  
> how you folks feel about this. I think the key to any = success=20 here  
> would be in scope management.
>
> = What if we=20 had the following groups:
>
> 1) SIPEM  -- SIP = Extended=20 Maintenance
>
> 2) SIPNEW -- New major functionality for=20 SIP
>
> 3) SIPREQ -- Analysis of requirements raised by = new=20 applications or  
> SDO liaison
>
> 4) SIPUSE = -- Using=20 SIP to meet specific application requirements
>
> =
>=20
> Here's how we might divide the work:
>
> =
>=20 SIPEM
> -----
>
> Scope: Maintenance of SIP 2.0 and = development (as per RFC 3427) of  
> backward-compatible = extensions=20 driven by applications with near-term  
> deployment=20 scenarios.
>
> Initial Milestone Tasks of SIPEM:
> =
>=20 1)  Developing a SIP Guidebook, roughly the equivalent of the TCP =  
> Roadmap, that defines what's "in" SIP and how the = pieces fit=20 together.
>
> 2)  GRUU
>
> 3)=20  Outbound
>
> 4)  Target-Dialog
> =
> 5)=20  Certificate Usage
>
> 6)  Location = Transport
>=20
> 7)  Loop Error Correction
>
> 8) =  Connected=20 Party Identity
>
> 9)  Hop Limit Diagnostics
> =
> 10) TLS Usage
>
> 11) Answering Modes
> =
>=20 12) Connection Reuse
>
> 13) Rejection of Anonymous=20 Requests
>
> 14) Consent Mechanism
>
> =
>=20
> SIPNEW
> ------
>
> Scope: Enhancement and = evolution of SIP including architectural-level  
> = requirements and=20 (as per RFC 3427) extensions without requirements  
> for = backward=20 compatibility.
>
>
> Initial milestone tasks of=20 SIPNEW
>
> 1)  Developing a "future roadmap" for the = evolution of SIP
>
> 2)  Solving the RFC 3261 = Routing=20 Problem
>
> 3)  Use of SAML with SIP
> =
> 4)=20  Response Identity
>
> 5)  Response=20 Authentication
>
> 6)  End to Middle = Requests
>=20
>
>
> SIPREQ
> ------
>
> = Scope:=20 Analysis of requirements raised by new applications of SIP in =  
>=20 IETF or in external SDOs (as per RFC 3427). Development of =  
>=20 requirements for changes to SIP or for usage guides in response to=20  
> applications requirements. Another way of wording this = would be=20  
> "problem definition".
>
> Initial = milestones and=20 tasks of SIPREQ:
>
> 1)  Session Policy = Requirements
>=20
>
>
> SIPUSE
> ------
>
> = Scope:=20 Guidance on how to use existing SIP specifications and  
>=20 mechanisms including examples, call flows, test cases, error =  
>=20 avoidance, and so on. Review (as per RFC 3427) of SIP Event = Packages.
>=20
>
> Initial milestones and tasks for SIPUSE:
> =
> 1)=20  Service Examples
>
> 2)  Security = Examples
>=20
> 3)  Race Condition Examples
>
> 4) =  Session=20 media policy mechanism
>
> 5)  Session policy = package=20 mechanism
>
> 6)  Service quality reporting=20 mechanism
>
> 7)  URI List mechanism
> =
> 8)=20  Subscriptions to Ad-Hoc Resource Lists mechanism
> =
> 9)=20  Multiple REFER mechanism
>
> 10) Ad-Hoc = Conferencing using=20 URI lists mechanism
>
> 11) Call Control Transfer=20 mechanism
>
> 12) Configuration Delivery = mechanism
>=20
> 13) Emergency Calling using SIP (SOS) mechanism
> =
>=20
>
>
> Note that I'm not entirely happy with the = division=20 of SIPPING into  
> SIPUSE and SIPREQ. While it seems like = we spend=20 a lot of time in  
> SIPPING debating requirements, there = are=20 currently a lot of  
> deliverables in this = category.
>=20
>
> --
> Dean
>
>=20 _______________________________________________
> Sip mailing = list=20  https://www1.ietf.org/mailman/listinfo/sip
> This list is = for NEW=20 development of the core SIP Protocol
> Use=20 sip-implementors@cs.columbia.edu for questions on current sip
> = Use=20 sipping@ietf.org for new developments on the application of=20 sip
 ------_=_NextPart_001_01C6395E.27FF3C27-- --===============1939309310== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1939309310==-- From sip-bounces@ietf.org Fri Feb 24 12:31:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCgkd-0003Hd-58; Fri, 24 Feb 2006 12:29:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCgka-0003Fe-FU; Fri, 24 Feb 2006 12:29:04 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCgkY-0002YY-Ha; Fri, 24 Feb 2006 12:29:04 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k1OHSv003403; Fri, 24 Feb 2006 12:28:57 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sipping] Re: [Sip] Thoughts on the Principle ofDividingandConquering Date: Fri, 24 Feb 2006 11:28:40 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Re: [Sip] Thoughts on the Principle ofDividingandConquering Thread-Index: AcY5QUhG5qVnqeYTQjG4tMq6H2fJoAAHDXnQAAEsoKAAARadkA== From: "Mary Barnes" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ad34ef4f81ffc6635f3eb8320caa45a Cc: "Cullen Jennings \(fluffy\)" , sip@ietf.org, Sipping List , Jon Peterson , Allison Mankin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2017831798==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2017831798== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63967.C09E8322" This is a multi-part message in MIME format. ------_=_NextPart_001_01C63967.C09E8322 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Although, I'd love that break, it frightens me to think what would happen with all the other SDOs that are using SIP and continually proposing enhancements (that they need right now, by the way). I would be very concerned that the industry would be even more fragmented in those 2 years than it is today.=20 =20 The reality is that there's a boatload of work to do and there's going to continue to be a boatload of new requirements coming in regularly for quite some time. So, we need an effective way to manage that. I think the categorization of the work, regardless of which WG handles it, is useful, as it does provide a reasonable way for logically dividing up the work. Another option would be prioritize the existing work based on WG input (without other SDOs demands that they need it to complete their written specs having higher priority than folks that need to solve current real problems). And, I'll say it again, that some sort of directorate or adjunct group of folks to help lessen the burden of the existing WG chairs would be a good thing. As to another suggestion that dividing the work into separate WGs lessens the burden for some folks in terms of not having to attend all the sessions, there are some of us for whom the expectation is that we follow all the work (despite the fact that it's a virtually impossible task).=20 =20 Mary=20 Note: I did snip the receiver list a bit as it was getting long.=20 -----Original Message----- From: henry@sinnreich.net [mailto:henry@sinnreich.net]=20 Sent: Friday, February 24, 2006 10:57 AM To: 'Michael Hammer (mhammer)'; 'Avshalom Houri'; 'Dean Willis' Cc: 'Cullen Jennings (fluffy)'; sip@ietf.org; 'Sipping List'; 'Jon Peterson'; 'Allison Mankin' Subject: RE: [Sipping] Re: [Sip] Thoughts on the Principle ofDividingandConquering =09 =09 * Could not the WG just have extra multiple secretaries to help manage each sub-category of drafts?=20 =20 If we take a look at the huge volume of output recorded at http://rfc3261.net/, we could also come to the contrarian alternative:=20 =20 Take a break for a couple of years, so the industry can catch up with all the SIP standards work and that the reality in deployment should separate the generally useful standards from those that are more limited in scope. =20 Hint: Finalize only ICE and P2P SIP before taking the break. =20 Thanks, Henry=20 =20 =09 ________________________________ From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: Friday, February 24, 2006 5:20 PM To: Avshalom Houri; Dean Willis Cc: Cullen Jennings (fluffy); sip@ietf.org; Sipping List; Jon Peterson; Allison Mankin Subject: RE: [Sipping] Re: [Sip] Thoughts on the Principle of DividingandConquering =20 Oh, this is starting to sound scary. =20 N SIP WGs x M IETF SIP-related groups x P non-IETF SIP-related groups =3D Who's on First? =20 (Abbott and Costello reference) =20 We will need a SIP WG just to manage the liaisons for each pair of groups. =20 BTW, how do we clone Dean? :) =20 If this is really just an administrative issue. Could not the WG just have extra multiple secretaries to help manage each sub-category of drafts? =20 Mike =20 =20 =09 ________________________________ From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com]=20 Sent: Friday, February 24, 2006 7:53 AM To: Dean Willis Cc: Cullen Jennings (fluffy); sip@ietf.org List; Sipping List; Jon Peterson; Allison Mankin Subject: [Sipping] Re: [Sip] Thoughts on the Principle of Dividing andConquering =09 I do think that a step in this direction is very necessary.=20 We will have to finalize the details as:=20 =09 * How this relates to SPEERMINT and to P2P-SIP?=20 =09 * A lot of very SIP related work is done MIDCOM, MMUSIC, IPTEL, ENUM, XCON, BEHAVE and=20 probably more groups. How the SIP related work will fit into the new framework?=20 =09 * The SIP work in the IETF has become so big and very connected with other standard organizations=20 that we really need to think about all the issues and there may be a need to a deeper change as=20 creating a sub organization in the IETF for SIP that will meet in other dates (maybe collocated with other=20 organization meetings from time to time as 3GPP and OMA. This way we may have much more time to deal=20 with the necessary issues.=20 =09 Maybe we should have a BOF at the Dallas IETF for this? Although I am not sure we will have=20 a big enough room or it will be easy to chair such a meeting. :)=20 =09 --Avshalom=20 =09 Dean Willis wrote on 24-02-2006 02:30:44 AM: =09 > I've been working on SIP and SIPPING and P2P-SIP agendas this week, =20 > and that started me thinking. >=20 > We spun up SIPPING to take some of the load off of SIP, and in doing =20 > so tried to more narrowly-define the charters of both SIP and SIPPING =20 > relative to the previous SIP charter. >=20 > When we started talking about P2P-SIP, we thought about bringing in =20 > the topic as part of SIPPING, but fairly quickly rejected that idea =20 > because it was clearly partitionable. >=20 > This started me thinking -- could we further apply this principle of =20 > partitioning? >=20 > Both SIP and SIPPING have grown into multi-year monsters, each with =20 > large charters and the need for multiple long-sessions at each IETF. =20 > They're tricky to chair, require lots of secretarial work, and are =20 > chronically late on deliverables (in large part because the chairs =20 > are acting like ADs instead of chairs). SPPING, once viewed as the =20 > kidney of SIP, now needs its own dialysis. >=20 > Perhaps if we were to split these two working groups into three or =20 > four working groups that have much more clearly defined missions and =20 > scopes, we could cut them down to one meeting slot each. And if we =20 > were to have separate management (chairs and secretaries) for each =20 > working group, we could better manage the groups to timely delivery. >=20 > So I'd like to toss out some ideas on how we might subdivide, and see =20 > how you folks feel about this. I think the key to any success here =20 > would be in scope management. >=20 > What if we had the following groups: >=20 > 1) SIPEM -- SIP Extended Maintenance >=20 > 2) SIPNEW -- New major functionality for SIP >=20 > 3) SIPREQ -- Analysis of requirements raised by new applications or =20 > SDO liaison >=20 > 4) SIPUSE -- Using SIP to meet specific application requirements >=20 >=20 >=20 > Here's how we might divide the work: >=20 >=20 > SIPEM > ----- >=20 > Scope: Maintenance of SIP 2.0 and development (as per RFC 3427) of =20 > backward-compatible extensions driven by applications with near-term =20 > deployment scenarios. >=20 > Initial Milestone Tasks of SIPEM: >=20 > 1) Developing a SIP Guidebook, roughly the equivalent of the TCP =20 > Roadmap, that defines what's "in" SIP and how the pieces fit together. >=20 > 2) GRUU >=20 > 3) Outbound >=20 > 4) Target-Dialog >=20 > 5) Certificate Usage >=20 > 6) Location Transport >=20 > 7) Loop Error Correction >=20 > 8) Connected Party Identity >=20 > 9) Hop Limit Diagnostics >=20 > 10) TLS Usage >=20 > 11) Answering Modes >=20 > 12) Connection Reuse >=20 > 13) Rejection of Anonymous Requests >=20 > 14) Consent Mechanism >=20 >=20 >=20 > SIPNEW > ------ >=20 > Scope: Enhancement and evolution of SIP including architectural-level =20 > requirements and (as per RFC 3427) extensions without requirements =20 > for backward compatibility. >=20 >=20 > Initial milestone tasks of SIPNEW >=20 > 1) Developing a "future roadmap" for the evolution of SIP >=20 > 2) Solving the RFC 3261 Routing Problem >=20 > 3) Use of SAML with SIP >=20 > 4) Response Identity >=20 > 5) Response Authentication >=20 > 6) End to Middle Requests >=20 >=20 >=20 > SIPREQ > ------ >=20 > Scope: Analysis of requirements raised by new applications of SIP in =20 > IETF or in external SDOs (as per RFC 3427). Development of =20 > requirements for changes to SIP or for usage guides in response to =20 > applications requirements. Another way of wording this would be =20 > "problem definition". >=20 > Initial milestones and tasks of SIPREQ: >=20 > 1) Session Policy Requirements >=20 >=20 >=20 > SIPUSE > ------ >=20 > Scope: Guidance on how to use existing SIP specifications and =20 > mechanisms including examples, call flows, test cases, error =20 > avoidance, and so on. Review (as per RFC 3427) of SIP Event Packages. >=20 >=20 > Initial milestones and tasks for SIPUSE: >=20 > 1) Service Examples >=20 > 2) Security Examples >=20 > 3) Race Condition Examples >=20 > 4) Session media policy mechanism >=20 > 5) Session policy package mechanism >=20 > 6) Service quality reporting mechanism >=20 > 7) URI List mechanism >=20 > 8) Subscriptions to Ad-Hoc Resource Lists mechanism >=20 > 9) Multiple REFER mechanism >=20 > 10) Ad-Hoc Conferencing using URI lists mechanism >=20 > 11) Call Control Transfer mechanism >=20 > 12) Configuration Delivery mechanism >=20 > 13) Emergency Calling using SIP (SOS) mechanism >=20 >=20 >=20 >=20 > Note that I'm not entirely happy with the division of SIPPING into =20 > SIPUSE and SIPREQ. While it seems like we spend a lot of time in =20 > SIPPING debating requirements, there are currently a lot of =20 > deliverables in this category. >=20 >=20 > -- > Dean >=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 ------_=_NextPart_001_01C63967.C09E8322 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Although, I'd love that break, it frightens = me to think=20 what would happen with all the other SDOs that are using SIP and = continually=20 proposing enhancements (that they need right now, by the = way).   I=20 would be very concerned that the industry would be even more fragmented = in those=20 2 years than it is today.
 
The=20 reality is that there's a boatload of work to do and there's going to = continue=20 to be a boatload of new requirements coming in regularly for quite some=20 time.   So, we need an effective way to manage = that.   I=20 think the categorization of the work, regardless of which WG handles it, = is=20 useful, as it does provide a reasonable way for logically dividing up = the work.=20 Another option would be prioritize the existing work based on WG input = (without=20 other SDOs demands that they need it to complete their written specs = having=20 higher priority than folks that need to solve current real=20 problems).   And, I'll say it again, that some sort of = directorate or=20 adjunct group of folks to help lessen the burden of the existing WG = chairs would=20 be a good thing.  As to another suggestion that dividing the work = into=20 separate WGs lessens the burden for some folks in terms of not having to = attend=20 all the sessions, there are some of us for whom the expectation is that = we=20 follow all the work (despite the fact that it's a virtually impossible = task).=20
 
Mary
Note:=20 I did snip the receiver list a bit as it was getting long. =
-----Original Message-----
From:=20 henry@sinnreich.net [mailto:henry@sinnreich.net]
Sent: = Friday,=20 February 24, 2006 10:57 AM
To: 'Michael Hammer (mhammer)'; = 'Avshalom=20 Houri'; 'Dean Willis'
Cc: 'Cullen Jennings (fluffy)'; = sip@ietf.org;=20 'Sipping List'; 'Jon Peterson'; 'Allison Mankin'
Subject: = RE:=20 [Sipping] Re: [Sip] Thoughts on the Principle=20 ofDividingandConquering

Ø      =20 Could = not the WG=20 just have extra multiple secretaries to help manage each = sub-category of=20 drafts?

 

If we = take a look=20 at the huge volume of output recorded at http://rfc3261.net/, we could also = come to the=20 contrarian alternative:

 

Take a = break for a=20 couple of years, so the industry can catch up with all the SIP = standards work=20 and that the reality in deployment should separate the generally = useful=20 standards from those that are more limited in=20 scope.

 

Hint: = Finalize only=20 ICE and P2P SIP before taking the break.

 

Thanks, = Henry=20

 

From: Michael=20 Hammer (mhammer) [mailto:mhammer@cisco.com]
Sent: Friday, February 24, 2006 = 5:20=20 PM
To: Avshalom = Houri; Dean=20 Willis
Cc: Cullen = Jennings=20 (fluffy); sip@ietf.org; Sipping List; Jon Peterson; Allison = Mankin
Subject: RE: [Sipping] Re: = [Sip] Thoughts=20 on the Principle of = DividingandConquering

 

Oh, this = is=20 starting to sound scary.

 

N SIP WGs = x M IETF=20 SIP-related groups x P non-IETF SIP-related groups =3D Who's on = First? =20

(Abbott = and=20 Costello reference)

 

We will = need a SIP=20 WG just to manage the liaisons for each pair of=20 groups.

 

BTW, how = do we=20 clone Dean? :)

 

If this = is really=20 just an administrative issue.  Could not the WG just have extra = multiple=20 secretaries to help manage each sub-category of=20 drafts?

 

Mike

 

 

From:=20 Avshalom Houri [mailto:AVSHALOM@il.ibm.com]
Sent: Friday, February 24, = 2006 7:53=20 AM
To: Dean=20 Willis
Cc: Cullen = Jennings=20 (fluffy); sip@ietf.org List; Sipping List; Jon Peterson; Allison=20 Mankin
Subject: = [Sipping]=20 Re: [Sip] Thoughts on the Principle of Dividing=20 andConquering


I do think=20 that a step in this direction is very necessary. =
We will have = to finalize=20 the details as:

* How this = relates to=20 SPEERMINT and to P2P-SIP?

* A lot of=20 very SIP related work is done MIDCOM, MMUSIC, IPTEL, ENUM, XCON, = BEHAVE=20 and
probably more = groups.=20 How the SIP related work will fit into the new = framework?=20

* The SIP work = in the=20 IETF has become so big and very connected with other standard=20 organizations
that we really = need to=20 think about all the issues and there may be a need to a deeper = change=20 as
creating a sub = organization in the IETF for SIP that will meet in other dates = (maybe=20 collocated with other
organization = meetings=20 from time to time as 3GPP and OMA. This way we may have much more = time to=20 deal
with the = necessary=20 issues.

Maybe we = should have a=20 BOF at the Dallas IETF for this? Although I am not sure we will=20 have
a big enough = room or it=20 will be easy to chair such a meeting. :)

--Avshalom=20

Dean Willis=20 <dean.willis@softarmor.com> wrote on 24-02-2006 02:30:44=20 AM:

> I've been working on SIP and SIPPING and P2P-SIP = agendas=20 this week,  
> and that started me thinking.
> =
> We=20 spun up SIPPING to take some of the load off of SIP, and in doing=20  
> so tried to more narrowly-define the charters of both = SIP and=20 SIPPING  
> relative to the previous SIP charter.
> =
> When we started talking about P2P-SIP, we thought about = bringing in=20  
> the topic as part of SIPPING, but fairly quickly = rejected=20 that idea  
> because it was clearly = partitionable.
>=20
> This started me thinking -- could we further apply this = principle=20 of  
> partitioning?
>
> Both SIP and = SIPPING have=20 grown into multi-year monsters, each with  
> large = charters and=20 the need for multiple long-sessions at each IETF.  
> = They're=20 tricky to chair, require lots of secretarial work, and are =  
>=20 chronically late on deliverables (in large part because the chairs=20  
> are acting like ADs instead of chairs). SPPING, once = viewed=20 as the  
> kidney of SIP, now needs its own = dialysis.
>=20
> Perhaps if we were to split these two working groups into = three or=20  
> four working groups that have much more clearly = defined=20 missions and  
> scopes, we could cut them down to one = meeting=20 slot each. And if we  
> were to have separate management = (chairs=20 and secretaries) for each  
> working group, we could = better=20 manage the groups to timely delivery.
>
> So I'd like = to toss=20 out some ideas on how we might subdivide, and see  
> how = you=20 folks feel about this. I think the key to any success here =  
>=20 would be in scope management.
>
> What if we had the = following=20 groups:
>
> 1) SIPEM  -- SIP Extended = Maintenance
>=20
> 2) SIPNEW -- New major functionality for SIP
> =
> 3)=20 SIPREQ -- Analysis of requirements raised by new applications or=20  
> SDO liaison
>
> 4) SIPUSE -- Using SIP = to meet=20 specific application requirements
>
>
>
> = Here's=20 how we might divide the work:
>
>
> = SIPEM
>=20 -----
>
> Scope: Maintenance of SIP 2.0 and development = (as per=20 RFC 3427) of  
> backward-compatible extensions driven by = applications with near-term  
> deployment = scenarios.
>=20
> Initial Milestone Tasks of SIPEM:
>
> 1)=20  Developing a SIP Guidebook, roughly the equivalent of the TCP=20  
> Roadmap, that defines what's "in" SIP and how the = pieces fit=20 together.
>
> 2)  GRUU
>
> 3)=20  Outbound
>
> 4)  Target-Dialog
> =
> 5)=20  Certificate Usage
>
> 6)  Location = Transport
>=20
> 7)  Loop Error Correction
>
> 8) =  Connected=20 Party Identity
>
> 9)  Hop Limit = Diagnostics
>=20
> 10) TLS Usage
>
> 11) Answering Modes
> =
>=20 12) Connection Reuse
>
> 13) Rejection of Anonymous=20 Requests
>
> 14) Consent Mechanism
>
> =
>=20
> SIPNEW
> ------
>
> Scope: Enhancement = and=20 evolution of SIP including architectural-level  
> = requirements=20 and (as per RFC 3427) extensions without requirements  
> = for=20 backward compatibility.
>
>
> Initial milestone = tasks of=20 SIPNEW
>
> 1)  Developing a "future roadmap" for = the=20 evolution of SIP
>
> 2)  Solving the RFC 3261 = Routing=20 Problem
>
> 3)  Use of SAML with SIP
> =
> 4)=20  Response Identity
>
> 5)  Response=20 Authentication
>
> 6)  End to Middle = Requests
>=20
>
>
> SIPREQ
> ------
>
> = Scope:=20 Analysis of requirements raised by new applications of SIP in =  
>=20 IETF or in external SDOs (as per RFC 3427). Development of =  
>=20 requirements for changes to SIP or for usage guides in response to=20  
> applications requirements. Another way of wording = this would=20 be  
> "problem definition".
>
> Initial = milestones=20 and tasks of SIPREQ:
>
> 1)  Session Policy=20 Requirements
>
>
>
> SIPUSE
>=20 ------
>
> Scope: Guidance on how to use existing SIP=20 specifications and  
> mechanisms including examples, = call flows,=20 test cases, error  
> avoidance, and so on. Review (as = per RFC=20 3427) of SIP Event Packages.
>
>
> Initial = milestones=20 and tasks for SIPUSE:
>
> 1)  Service = Examples
>=20
> 2)  Security Examples
>
> 3)  Race = Condition=20 Examples
>
> 4)  Session media policy = mechanism
>=20
> 5)  Session policy package mechanism
>
> = 6)=20  Service quality reporting mechanism
>
> 7) =  URI List=20 mechanism
>
> 8)  Subscriptions to Ad-Hoc Resource = Lists=20 mechanism
>
> 9)  Multiple REFER mechanism
> =
> 10) Ad-Hoc Conferencing using URI lists mechanism
> =
>=20 11) Call Control Transfer mechanism
>
> 12) = Configuration=20 Delivery mechanism
>
> 13) Emergency Calling using SIP = (SOS)=20 mechanism
>
>
>
>
> Note that I'm = not=20 entirely happy with the division of SIPPING into  
> = SIPUSE and=20 SIPREQ. While it seems like we spend a lot of time in  
> = SIPPING=20 debating requirements, there are currently a lot of  
>=20 deliverables in this category.
>
>
> --
>=20 Dean
>
>=20 _______________________________________________
> Sip mailing = list=20  https://www1.ietf.org/mailman/listinfo/sip
> This list = is for=20 NEW development of the core SIP Protocol
> Use=20 sip-implementors@cs.columbia.edu for questions on current = sip
> Use=20 sipping@ietf.org for new developments on the application of=20 = sip

------_=_NextPart_001_01C63967.C09E8322-- --===============2017831798== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============2017831798==-- From sip-bounces@ietf.org Fri Feb 24 12:58:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FChB6-0003Pi-GF; Fri, 24 Feb 2006 12:56:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FChB4-0003Jg-5J; Fri, 24 Feb 2006 12:56:26 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FChB0-0003b8-Qo; Fri, 24 Feb 2006 12:56:26 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1OHuU9T028673 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 24 Feb 2006 11:56:31 -0600 In-Reply-To: <200602241325.k1ODPCiv027435@nylon.softarmor.com> References: <200602241325.k1ODPCiv027435@nylon.softarmor.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <32A596D9-0883-4DF5-B496-56278EE979A8@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Fri, 24 Feb 2006 11:56:16 -0600 To: X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: sip@ietf.org, 'Cullen Jennings' , 'Sipping List' , 'Jon Peterson' , 'Allison Mankin' Subject: [Sip] Re: [Sipping] Thoughts on the Principle of Dividing and Conquering X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Feb 24, 2006, at 7:25 AM, Henry Sinnreich wrote: > Dean, > > This is good initiative, but where would you put P2P SIP? > In its own working group, as it is a reasonably encapsulated aspect of SIP, just as SIMPLE and XCON and ECRIT are. I would suggest doing the same for other large but reasonably encapsulated aspects as they become foci of attention. -- 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 sip-bounces@ietf.org Fri Feb 24 13:01:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FChDo-0006iP-H2; Fri, 24 Feb 2006 12:59:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FChDm-0006bJ-07; Fri, 24 Feb 2006 12:59:14 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FChDk-0003h7-Lr; Fri, 24 Feb 2006 12:59:13 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1OHxLcB028709 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 24 Feb 2006 11:59:22 -0600 In-Reply-To: <4.3.2.7.2.20060223184409.03593e18@email.cisco.com> References: <4.3.2.7.2.20060223184409.03593e18@email.cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Re: [Sipping] Thoughts on the Principle of Dividing and Conquering Date: Fri, 24 Feb 2006 11:59:07 -0600 To: "James M. Polk" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: "sip@ietf.org List" , Cullen Jennings , Sipping List , Jon Peterson , Allison Mankin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Feb 23, 2006, at 6:47 PM, James M. Polk wrote: > I don't mean to rain on this idea, but... > > What happens when these 4 grow too big for their britches, split > them again? Quite possibly. Although the intent here is to narrow the scope of each so that it is easier for the participants and chairs to understand how to make scope decisions. > Shouldn't XCON and SIMPLE be considered when breaking SIP and > SIPPING up, as these WGs were effectively split off of SIP earlier on? They are. They're discrete chunks we've forked of in the past. We will fork off more in the future, as we are proposing to do with P2P- SIP (which will have a BOF at Dallas). Forking appears to be a fundamental design aspect of SIP. Seriously, we don't have all protocols that use TCP developed in the TCP Maintenance working group. Why should we do that to SIP? -- 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 sip-bounces@ietf.org Fri Feb 24 13:03:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FChG0-0007qt-BZ; Fri, 24 Feb 2006 13:01:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FChFx-0007oc-5W; Fri, 24 Feb 2006 13:01:29 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FChFv-0003kT-Rj; Fri, 24 Feb 2006 13:01:29 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1OI1YOw028755 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 24 Feb 2006 12:01:36 -0600 In-Reply-To: <28F05913385EAC43AF019413F674A0170DE0C29A@OCCLUST04EVS1.ugd.att.com> References: <28F05913385EAC43AF019413F674A0170DE0C29A@OCCLUST04EVS1.ugd.att.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <24551DCC-FE0C-4DEE-BEF5-09F4A1C97FBC@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Fri, 24 Feb 2006 12:01:21 -0600 To: "Dolly, Martin C, ALABS" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Cullen Jennings , Jon Peterson , Allison Mankin , sip@ietf.org, "James M. Polk" , Sipping List Subject: [Sip] Re: [Sipping] Thoughts on the Principle of Dividing and Conquering X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Feb 23, 2006, at 8:37 PM, Dolly, Martin C, ALABS wrote: > For as long as the "core" group of folks have to participate in all > these topics, splitting solves nothing. If anything, it causes > coordination issues. Actually, nobody said this would make it easier for the attendees, although I am hoping that it will help with scope management. The real intent is to make it easier for chairs and ADs. Chairing 12 hours of SIP meetings chopped up into 10-20 minute slots is a real PITA, and I'm not talking flatbread here. -- 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 sip-bounces@ietf.org Fri Feb 24 13:10:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FChMw-0003VK-0O; Fri, 24 Feb 2006 13:08:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FChMt-0003Oq-87; Fri, 24 Feb 2006 13:08:39 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FChMs-00044f-TN; Fri, 24 Feb 2006 13:08:39 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1OI8kbX028788 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 24 Feb 2006 12:08:47 -0600 In-Reply-To: <43FF2722.3030205@cisco.com> References: <231F5685-CCC1-41B1-997E-74AF67D9EBCE@softarmor.com> <6504c97d55581302c9e786a2ad8ce9b4@telio.no> <43FF15D4.4000209@cisco.com> <43FF2722.3030205@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <33AC4B26-88C6-46A6-9DF7-61F649414426@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Re: [Sipping] Thoughts on the Principle of Dividing and Conquering Date: Fri, 24 Feb 2006 12:08:33 -0600 To: Michael Thomas X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Cullen Jennings , Jon Peterson , Allison Mankin , "sip@ietf.org List" , Paul Kyzivat , Sipping List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Feb 24, 2006, at 9:32 AM, Michael Thomas wrote: > > Maybe the base problem is that the energy barrier to new work is > generally too low? And that fairly open-ended charters inevitably > lead to far too many good ideas? Perhaps instead of dividing > along the lines that Dean was suggesting, we should > require them to actually *charter* a fixed-function working > group that actually has a set of goals and ::drum roll:: a > criteria to shut itself down. Including new WG chairs. > That was one of the ideas going into this. The idea was for SIPM to extend to our current definition of "what is SIP" and take over maintenance of that concept. I personally favor a version number increment for any core changes past that threshold. Significant new usages of SIP should fork out new working groups, which we have done with SIMPLE and XCON and ECRIT and now P2P-SIP. These should have very limited charters and come equipped with "lights at the end of the tunnel" -- that is -- the end should be in sight, and we should know when we get there. Feel free to suggest alternative divisions of the work that moves us more directly to this goal. -- 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 sip-bounces@ietf.org Fri Feb 24 13:14:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FChQh-0007l7-T4; Fri, 24 Feb 2006 13:12:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FChQg-0007jJ-5D; Fri, 24 Feb 2006 13:12:34 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FChQe-0004Hd-R6; Fri, 24 Feb 2006 13:12:34 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1OICepW028810 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 24 Feb 2006 12:12:42 -0600 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E30124552C@xmb-rtp-20b.amer.cisco.com> References: <072C5B76F7CEAB488172C6F64B30B5E30124552C@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of Dividing andConquering Date: Fri, 24 Feb 2006 12:12:27 -0600 To: Michael Hammer ((mhammer)) X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: "Cullen Jennings \(fluffy\)" , Avshalom Houri , Jon Peterson , Allison Mankin , sip@ietf.org, Sipping List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Feb 24, 2006, at 10:19 AM, Michael Hammer ((mhammer)) wrote: > > If this is really just an administrative issue. Could not the WG > just have extra multiple secretaries to help manage each sub- > category of drafts? > Of course, a couple of uber-chairs with a bunch of under-chairs is in IETF speak called an "area", which has "area directors" for oversight and "working groups chairs" and "working groups" for each sub- category of draft. The main challenge is cleanly defined sub-categories, which is a large part of what I'm trying to figure out here. -- 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 sip-bounces@ietf.org Fri Feb 24 13:56:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCi5j-0001PW-Tf; Fri, 24 Feb 2006 13:54:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCi5h-0001NW-11 for sip@ietf.org; Fri, 24 Feb 2006 13:54:57 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCi5f-0005TA-MT for sip@ietf.org; Fri, 24 Feb 2006 13:54:56 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 24 Feb 2006 10:54:56 -0800 X-IronPort-AV: i="4.02,144,1139212800"; d="scan'208"; a="1779511748:sNHT32206700" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k1OIssuh028976; Fri, 24 Feb 2006 10:54:54 -0800 (PST) Received: from 171.68.225.134 ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Fri, 24 Feb 2006 18:54:54 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Fri, 24 Feb 2006 10:54:52 -0800 Subject: Re: [Sip] Outbound and STUN Keep Alive From: Cullen Jennings To: Dean Willis , Rohan Mahy Message-ID: Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcY5c8s2CeRQTKVnEdqitwARJEEJ/A== In-Reply-To: <200602231516.30350.dean.willis@softarmor.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 2/23/06 1:16 PM, "Dean Willis" wrote: > I think you guys are missing Gary's use case. > > He's postulating an entirely different NAT problem, where the NAT is between > the outbound proxy and the real world, rather than between the UA and its > outbound proxy. > > This just isn't a use case that's been in scope for general discussion so far. If I understand correctly ... I thin I added this use case to the document awhile back because some people request it. For some vague reason, I thought Dean was one of the people that had requested it. People had brought up system like the ingate stuff. If the use case complicated stuff, I would remove it but so far the baseline the simple case has pretty much solved this one too. _______________________________________________ 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 sip-bounces@ietf.org Fri Feb 24 14:41:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCimz-0005W4-Bj; Fri, 24 Feb 2006 14:39:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCimw-0005Vp-TF; Fri, 24 Feb 2006 14:39:38 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCimv-0006gP-JU; Fri, 24 Feb 2006 14:39:38 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 24 Feb 2006 11:39:37 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1OJdZHh014291; Fri, 24 Feb 2006 11:39:36 -0800 (PST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Feb 2006 14:39:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] Re: [Sip] Thoughts on the Principle of Dividing andConquering Date: Fri, 24 Feb 2006 14:39:34 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301245612@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Re: [Sip] Thoughts on the Principle of Dividing andConquering Thread-Index: AcY5beZcyD7SfiOyTuqreWaYbMGTQwAC0PYQ From: "Michael Hammer \(mhammer\)" To: "Dean Willis" X-OriginalArrivalTime: 24 Feb 2006 19:39:35.0542 (UTC) FILETIME=[0ABA6960:01C6397A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: "Cullen Jennings \(fluffy\)" , Avshalom Houri , Jon Peterson , Allison Mankin , sip@ietf.org, Sipping List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean, I sympathize with the plight of the WG chairs and support the search for a solution. What I was trying to suggest is that we not get tunnel vision and think that these changes will only affect those inside the WGs. Because many other standards groups are interacting with the IETF wrt SIP, the external communications is also a consideration that should be taken into account. I didn't want to lose sight of that. So, I guess this means that the external communications will be a key responsibility of the new RAI AD's then. Could someone describe how this will work inter-WG, inter-Area, inter-standards groups? Mike > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Friday, February 24, 2006 1:12 PM > To: Michael Hammer (mhammer) > Cc: Avshalom Houri; Cullen Jennings (fluffy); sip@ietf.org;=20 > Sipping List; Jon Peterson; Allison Mankin > Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of=20 > Dividing andConquering >=20 >=20 > On Feb 24, 2006, at 10:19 AM, Michael Hammer ((mhammer)) wrote: >=20 > > > > If this is really just an administrative issue. Could not=20 > the WG just=20 > > have extra multiple secretaries to help manage each sub-=20 > category of=20 > > drafts? > > >=20 > Of course, a couple of uber-chairs with a bunch of=20 > under-chairs is in =20 > IETF speak called an "area", which has "area directors" for=20 > oversight =20 > and "working groups chairs" and "working groups" for each sub-=20 > category of draft. >=20 >=20 > The main challenge is cleanly defined sub-categories, which is a =20 > large part of what I'm trying to figure out here. >=20 > -- > Dean >=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 sip-bounces@ietf.org Fri Feb 24 14:57:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCj2a-0007cC-0r; Fri, 24 Feb 2006 14:55:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCj2Y-0007aa-5H; Fri, 24 Feb 2006 14:55:46 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCj2W-0007BP-S2; Fri, 24 Feb 2006 14:55:46 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1OJtr5r029209 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 24 Feb 2006 13:55:54 -0600 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301245612@xmb-rtp-20b.amer.cisco.com> References: <072C5B76F7CEAB488172C6F64B30B5E301245612@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1CA19B55-963C-4669-82F4-E5ACB55CCA3C@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of Dividing andConquering Date: Fri, 24 Feb 2006 13:55:39 -0600 To: "Michael Hammer \(mhammer\)" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: "Cullen Jennings \(fluffy\)" , Avshalom Houri , Jon Peterson , Allison Mankin , sip@ietf.org, Sipping List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Feb 24, 2006, at 1:39 PM, Michael Hammer ((mhammer)) wrote: > Dean, > > I sympathize with the plight of the WG chairs and support the > search for > a solution. What I was trying to suggest is that we not get tunnel > vision and think that these changes will only affect those inside the > WGs. Because many other standards groups are interacting with the > IETF > wrt SIP, the external communications is also a consideration that > should > be taken into account. I didn't want to lose sight of that. > That's a good point, Mike. Thanks for clarifying. Lateral communication is always critical. I was thinking that the primary conduit "in" from external SDO's would be the SIPREQ function, which would analyze the requirements and either kick them to the SIPUSE, SIPEM, or SIPNEW functions as appropriate. Things that are effectively just bug reports could probably go directly into SIPEM, which would of course be free to kick stuff back to SIPREQ, over to SIPUSE, or out to SIPNEW if they found it wasn't really a maintenance-level request. Other SIP-usage working groups inside IETF could probably operate in a similar fashion. Output communication would perhaps be a larger challenge, with the key part being effectively communicating exactly where a change- request is "living" at any given time. This sounds like it be could be handled by our usual liaison mechanisms, but there might be an opportunity to augment this with a "tracker" tool. -- 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 sip-bounces@ietf.org Fri Feb 24 15:01:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCj6T-0001r6-7s; Fri, 24 Feb 2006 14:59:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCj6R-0001qy-NE; Fri, 24 Feb 2006 14:59:47 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCj6R-0007HS-C9; Fri, 24 Feb 2006 14:59:47 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k1OJxdY8015206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Feb 2006 14:59:40 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id k1OJxaFi008758; Fri, 24 Feb 2006 14:59:37 -0500 Message-ID: <43FF323F.4060409@cs.columbia.edu> Date: Fri, 24 Feb 2006 11:20:15 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Thoughts on the Principle of Dividing and Conquering References: <231F5685-CCC1-41B1-997E-74AF67D9EBCE@softarmor.com> In-Reply-To: <231F5685-CCC1-41B1-997E-74AF67D9EBCE@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=XI, Probability=11%, Report='DATE_IN_PAST_03_06 1.0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: "sip@ietf.org List" , Cullen Jennings , Sipping List , Jon Peterson , Allison Mankin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Without speaking to the specific division of labor (I think just about any division would do), something clearly has to be done to increase overall throughput. According to my rough count, in 2005 we managed to publish 5 SIPPING and 5 SIP RFC (and 1 SIMPLE RFC). 2004 saw a few more, but the total was also not more than 20. However, we added 26 SIP, 52 SIPPING and 15 SIMPLE -00 drafts, both draft-personal and draft-ietf. Some of these, I'm sure, were added initially as draft-personal and become draft-ietf, but I don't think that changes the picture all that much. Not counting the backlog, we thus accumulated between 4.5 (at 20 RFCs/year) and 9 years of work (at 10 RFCs) last year. Currently, we seem to operate like the American Airlines check-in at JFK: regular customers wait 3 hours if they stand in line, but passengers with a flight about to depart (or an SDO about to get really mad) get into another queue and just barely make the flight, if they skip the line on the security checkpoint (IESG review). Unless we plan to prioritize work by the patience of the authors, this is not a good way to run an airline or the IETF. Henning Dean Willis wrote: > I've been working on SIP and SIPPING and P2P-SIP agendas this week, and > that started me thinking. > > We spun up SIPPING to take some of the load off of SIP, and in doing so > tried to more narrowly-define the charters of both SIP and SIPPING > relative to the previous SIP charter. > > When we started talking about P2P-SIP, we thought about bringing in the > topic as part of SIPPING, but fairly quickly rejected that idea because > it was clearly partitionable. > > This started me thinking -- could we further apply this principle of > partitioning? > > Both SIP and SIPPING have grown into multi-year monsters, each with > large charters and the need for multiple long-sessions at each IETF. > They're tricky to chair, require lots of secretarial work, and are > chronically late on deliverables (in large part because the chairs are > acting like ADs instead of chairs). SPPING, once viewed as the kidney of > SIP, now needs its own dialysis. > > Perhaps if we were to split these two working groups into three or four > working groups that have much more clearly defined missions and scopes, > we could cut them down to one meeting slot each. And if we were to have > separate management (chairs and secretaries) for each working group, we > could better manage the groups to timely delivery. > > So I'd like to toss out some ideas on how we might subdivide, and see > how you folks feel about this. I think the key to any success here would > be in scope management. > > What if we had the following groups: > > 1) SIPEM -- SIP Extended Maintenance > > 2) SIPNEW -- New major functionality for SIP > > 3) SIPREQ -- Analysis of requirements raised by new applications or SDO > liaison > > 4) SIPUSE -- Using SIP to meet specific application requirements > > > > Here's how we might divide the work: > > > SIPEM > ----- > > Scope: Maintenance of SIP 2.0 and development (as per RFC 3427) of > backward-compatible extensions driven by applications with near-term > deployment scenarios. > > Initial Milestone Tasks of SIPEM: > > 1) Developing a SIP Guidebook, roughly the equivalent of the TCP > Roadmap, that defines what's "in" SIP and how the pieces fit together. > > 2) GRUU > > 3) Outbound > > 4) Target-Dialog > > 5) Certificate Usage > > 6) Location Transport > > 7) Loop Error Correction > > 8) Connected Party Identity > > 9) Hop Limit Diagnostics > > 10) TLS Usage > > 11) Answering Modes > > 12) Connection Reuse > > 13) Rejection of Anonymous Requests > > 14) Consent Mechanism > > > > SIPNEW > ------ > > Scope: Enhancement and evolution of SIP including architectural-level > requirements and (as per RFC 3427) extensions without requirements for > backward compatibility. > > > Initial milestone tasks of SIPNEW > > 1) Developing a "future roadmap" for the evolution of SIP > > 2) Solving the RFC 3261 Routing Problem > > 3) Use of SAML with SIP > > 4) Response Identity > > 5) Response Authentication > > 6) End to Middle Requests > > > > SIPREQ > ------ > > Scope: Analysis of requirements raised by new applications of SIP in > IETF or in external SDOs (as per RFC 3427). Development of requirements > for changes to SIP or for usage guides in response to applications > requirements. Another way of wording this would be "problem definition". > > Initial milestones and tasks of SIPREQ: > > 1) Session Policy Requirements > > > > SIPUSE > ------ > > Scope: Guidance on how to use existing SIP specifications and mechanisms > including examples, call flows, test cases, error avoidance, and so on. > Review (as per RFC 3427) of SIP Event Packages. > > > Initial milestones and tasks for SIPUSE: > > 1) Service Examples > > 2) Security Examples > > 3) Race Condition Examples > > 4) Session media policy mechanism > > 5) Session policy package mechanism > > 6) Service quality reporting mechanism > > 7) URI List mechanism > > 8) Subscriptions to Ad-Hoc Resource Lists mechanism > > 9) Multiple REFER mechanism > > 10) Ad-Hoc Conferencing using URI lists mechanism > > 11) Call Control Transfer mechanism > > 12) Configuration Delivery mechanism > > 13) Emergency Calling using SIP (SOS) mechanism > > > > > Note that I'm not entirely happy with the division of SIPPING into > SIPUSE and SIPREQ. While it seems like we spend a lot of time in SIPPING > debating requirements, there are currently a lot of deliverables in this > category. > > > -- > 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 sip-bounces@ietf.org Fri Feb 24 15:20:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCjP3-0006s1-Ce; Fri, 24 Feb 2006 15:19:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCjP1-0006ne-Ha; Fri, 24 Feb 2006 15:18:59 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCjP0-0007or-5L; Fri, 24 Feb 2006 15:18:59 -0500 Received: from [10.31.13.102] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1OKJNtx025342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Feb 2006 12:19:24 -0800 Message-ID: <43FF6A29.4010402@shockey.us> Date: Fri, 24 Feb 2006 15:18:49 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "James M. Polk" References: <4.3.2.7.2.20060223184409.03593e18@email.cisco.com> In-Reply-To: <4.3.2.7.2.20060223184409.03593e18@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Cullen Jennings , Jon Peterson , Allison Mankin , "sip@ietf.org List" , Dean Willis , Sipping List Subject: [Sip] Re: [Sipping] Thoughts on the Principle of Dividing and Conquering X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org James M. Polk wrote: > I don't mean to rain on this idea, but... > > What happens when these 4 grow too big for their britches, split them > again? Sure then form our own standards body .. SETF SIP Engineering Task Force :-) Have a real SIP Architecture Board...wouldn't that be novel!! Mandatory meetings 3 times a year in the Bahamas. > > Shouldn't XCON and SIMPLE be considered when breaking SIP and SIPPING > up, as these WGs were effectively split off of SIP earlier on? > > At 06:30 PM 2/23/2006 -0600, Dean Willis wrote: >> I've been working on SIP and SIPPING and P2P-SIP agendas this week, >> and that started me thinking. >> >> We spun up SIPPING to take some of the load off of SIP, and in doing >> so tried to more narrowly-define the charters of both SIP and SIPPING >> relative to the previous SIP charter. >> >> When we started talking about P2P-SIP, we thought about bringing in >> the topic as part of SIPPING, but fairly quickly rejected that idea >> because it was clearly partitionable. >> >> -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ 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 sip-bounces@ietf.org Fri Feb 24 16:49:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCkmk-0008QF-8h; Fri, 24 Feb 2006 16:47:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCkmj-0008QA-Ri for sip@ietf.org; Fri, 24 Feb 2006 16:47:33 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCkmj-0003DJ-Hc for sip@ietf.org; Fri, 24 Feb 2006 16:47:33 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1OLlcpS029648 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 24 Feb 2006 15:47:39 -0600 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5D0FEDCB-A6BD-45B5-9076-71DBFB479480@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Fri, 24 Feb 2006 15:47:24 -0600 To: Cullen Jennings X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Feb 24, 2006, at 12:54 PM, Cullen Jennings wrote: > On 2/23/06 1:16 PM, "Dean Willis" wrote: > >> I think you guys are missing Gary's use case. >> >> He's postulating an entirely different NAT problem, where the NAT >> is between >> the outbound proxy and the real world, rather than between the UA >> and its >> outbound proxy. >> >> This just isn't a use case that's been in scope for general >> discussion so far. > > If I understand correctly ... I thin I added this use case to the > document > awhile back because some people request it. For some vague reason, > I thought > Dean was one of the people that had requested it. People had > brought up > system like the ingate stuff. If the use case complicated stuff, I > would > remove it but so far the baseline the simple case has pretty much > solved > this one too. Yep, I motivated the use case at one point. However, what you have in 3.4 isn't quite what what Gary seemed to be looking at, in that: 1) 3.4 shows another NAT between the UA and the EP. This doesn't make the use case of 3.4 weaker, but might lead people to think that it is a different problem, when this aspect is really a more-general variant of Gary's case. 2) 3.4 does not seem show the use of "classic STUN" to discover the effective IP address for RTP, along a path disparate from the coaxial STUN used as a NAT keepalive. This is implied in the text, and is obvious from STUN itself, but might not be obvious to somebody who hasn't been thinking about this for a long time. 3) The use of coaxial STUN between the EP and the registrar, though implied in 3.4, also doesn't seem obvious in the text. Nor is the requirement for "back pressure" from the EP to the UA, should the EP- Registrar coaxial STUN indicate a reset of the NAT between those nodes. If this happens, I think that EP needs to induce a "keepalive failure" on its own channel back to UA. You talk about UAs detecting flow failure, but not about proxies detecting flow failure. Maybe it is in there and I just missed it . . . -- 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 sip-bounces@ietf.org Fri Feb 24 17:11:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCl8C-0007PS-SD; Fri, 24 Feb 2006 17:09:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCl8B-0007OV-NN for sip@ietf.org; Fri, 24 Feb 2006 17:09:43 -0500 Received: from ussjmh01.bea.com ([63.96.162.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCl8A-0003c7-0u for sip@ietf.org; Fri, 24 Feb 2006 17:09:43 -0500 Received: from ussjfe01.amer.bea.com (ussjfe01.bea.com [172.16.120.53]) by ussjmh01.bea.com (Switch-3.0.5/Switch-3.0.0) with ESMTP id k1OM9bLE015530 for ; Fri, 24 Feb 2006 14:09:40 -0800 Received: from repbex01.amer.bea.com ([10.160.26.98]) by ussjfe01.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 24 Feb 2006 14:09:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 24 Feb 2006 14:09:09 -0800 Message-ID: <6E9C82D532D127439D866C0425182770779BAB@repbex01.amer.bea.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: content indirection design question Thread-Index: AcY5ju+KZ8mFUq64RAqknG3Fr8AYMA== From: "Nasir Khan" To: X-OriginalArrivalTime: 24 Feb 2006 22:09:09.0753 (UTC) FILETIME=[EFC65690:01C6398E] X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2006.02.24.124604 X-Spam-Score: 0.4 (/) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c Subject: [Sip] content indirection design question X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0643055511==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0643055511== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6398E.EFA2D591" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6398E.EFA2D591 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have this question for the designers of http://www.ietf.org/internet-drafts/draft-ietf-sip-content-indirect-mech -05.txt The way the meta data about the indirect content is split between message and body is counter-intuitive.=20 =20 Eg.=20 -----------------------------Actual------------------------- Content-Type: message/external-body; access-type=3D"URL"; expiration=3D"Mon, 24 June 2002 09:00:00 GMT"; URL=3Dhttp://www.example.com/the-indirect-content Content-Length : 234 Content-Type: image/jpeg Content-Disposition: render --------------------------------- =20 The Content-Type header indicates that this is an indirect content and also contains the pointer to the actual content, it contains a lot of other information about the content and then there is a Content-Length that is not the length of the actual content but the length of the content attributes that appear as Content headers in the body of this message, which contains some further information about the content.=20 This type of semantic overloading and distribution has not been seen in most of the SIP design that I am aware of so far, what were the reasons for this design decision?=20 =20 You could have defined a simple protocol (which you have done indirectly) which is transported in the message body much like SDP and defines the content as indirect content, as an example .. =20 Eg.=20 ------------------------Suggested--------------------------------------- ---- Content-Type: application/indirect-content Content-Length: 563 Indirect-Content-Param: URL;expiration=3D"Mon, 24 June 2002 09:00:00 GMT" Indirect-Content: http://www.example.com/the-indirect-content Indirect-Content-Type: image/jpeg Indirect-Content-Length : 234532 Indirect-Content-Description : Happy fish image ......etc etc.=20=20 ------------------------------------------------------------------------ ---------- =20 OR alternatively You could have extended SIP by adding these headers (Indirect-XXX) headers in this draft to describe the indirect content and left the body empty.=20 =20 Any of these approaches simplify the UA implementation, particularly in approach-1 that I describe above, I could have used a factory generated pluggable content protocol handler which is delegated to deal with the content it specializes in, selectable by Content-Type header alone which just reads the body of the message after , where it finds everything it needs.=20 =20 =20 Thanks ~Nasir=20=20=20=20 =20 =20 _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. ------_=_NextPart_001_01C6398E.EFA2D591 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
I have this question for the designers of http://www.ietf.org/internet-drafts/draft-ietf-sip-content-in=
direct-mech-05.txt
Th=
e way the meta data about the indirect content is split between message and=
 body is counter-intuitive. 
 
Eg=
. 
--=
---------------------------Actual-------------------------
&n=
bsp;            =
;           Content-Type: message/external-body; access-type=3D"URL";
  =
            &nb=
sp; expiration=3D"Mon, 24 June 2002 09:00:00 GMT";
&n=
bsp;            =
;   URL=3Dhttp://www.example.com=
/the-indirect-content
&n=
bsp;           Content-Le=
ngth : 234
&n=
bsp;           <CRLF&g=
t;
&n=
bsp;           Content-Ty=
pe: image/jpeg
&n=
bsp;           Content-Di=
sposition: render
------------=
---------------------
 
Th=
e Content-Type header indicates that this is an indirect content and also c=
ontains the pointer to the actual content, it contains a lot of other infor=
mation about the content and then there is a Content-Length that is not the=
 length of the actual content but the length of the content attributes that=
 appear as Content headers in the body of this message, which contains some=
 further information about the content.
Th= is type of semantic overloading and distribution has not been seen in most = of the SIP design that I am aware of so far, what were the reasons for this= design decision? 
 
Yo=
u could have defined a simple protocol (which you have done indirectly) whi=
ch is transported in the message body much like SDP and defines the content=
 as indirect content, as an example ..
<=
font
size=3D2 face=3DArial> 
Eg=
. 
--=
----------------------Suggested-------------------------------------------<=
o:p>
Content-Type: application/indirect-content<=
/o:p>
Content-Length: 563
<CRLF>
Indirect-Content-Param: URL;expiration=3D"M=
on, 24 June 2002 09:00:00 GMT"
Indirect-Content:  http://www.example.com=
/the-indirect-content
Indirect-Content-Type: image/jpeg
Indirect-Content-Length : 234532=

Indirect-Content-Description : Happy fish i=
mage
……etc etc.  


--------------------------------------------------------=
--------------------------



 



OR alternatively



You could have extended SIP by adding these headers
(Indirect-XXX) headers in this draft to describe the indirect content and l=
eft
the body empty. 



 



Any of these approaches simplify the UA implementation,
particularly in approach-1 that I describe above, I could have used a facto=
ry
generated pluggable content protocol handler which is delegated to deal with
the content it specializes in, selectable by Content-Type header alone which
just reads the body of the message after <CRLF>, where it finds
everything it needs. 



 



 



Thanks



~Nasir    



 



 



_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
------_=_NextPart_001_01C6398E.EFA2D591-- --===============0643055511== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0643055511==-- From sip-bounces@ietf.org Fri Feb 24 17:14:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FClBD-0001ds-TM; Fri, 24 Feb 2006 17:12:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FClBD-0001dl-0c for sip@ietf.org; Fri, 24 Feb 2006 17:12:51 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FClBB-0003jU-Kf for sip@ietf.org; Fri, 24 Feb 2006 17:12:50 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1OMCm8q029746 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 24 Feb 2006 16:12:49 -0600 In-Reply-To: <43FF42D7.8080809@ieee.org> References: <43FF42D7.8080809@ieee.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <84020EBD-77D7-46D5-A887-AD12EEB2F8BE@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] status on the SIP MIB modules? Date: Fri, 24 Feb 2006 16:12:33 -0600 To: Mark Ellison , klingle@cisco.com, jf.mule@cablelabs.com X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: "sip@ietf.org List" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Feb 24, 2006, at 11:31 AM, Mark Ellison wrote: > Hi, > > What is the current status for the SIP MIB modules? > > I notice that draft-ietf-sip-mib-09 is the latest revision of these > module. It is my understanding -09 was submitted for IESG > processing and that the current IESG status is "revised ID > needed" , as of 2005-12-11 (see http://tools.ietf.org/wg/sip/). > Also, I notice that this matter is not on the agenda for IETF #65. > > Also I have a question about the sipMethodSupportedIndex object > with respect to IANA registrations. In checking the IANA registry > for sip (http://www.iana.org/assignments/sip-parameters) I see a > list of methods (e.g. ACK, BYE, CANCEL, INFO...). I am assuming > the intent is that SIP method names are in the IANA registry, as > are SIP option tags. Possibly this is an area of the SIP MIB > modules in need of revision? > > Regards, It appears to be suffering from a severe case of apathy. The last email I saw on the list was last summer, which may answer your question about the sipMethodSupportedIndex object. > -----Original Message----- > From: Kevin Lingle (klingle) [mailto:klingle@cisco.com] > Sent: Friday, August 05, 2005 1:07 AM > To: Romascanu, Dan (Dan) > Cc: j.schoenwaelder@iu-bremen.de; sip@ietf.org; Wijnen, Bert > (Bert); jf.mule@cablelabs.com > Subject: RE: [Sip] draft-ietf-sip-mib-09.txt - 'MIB Doctor' review > > dan, > > jean-francois and i have discussed the issue of using method > name as an index and, at this point, neither of us > are against making that change. it has the benefit of > removing the method to identifier table and the IANA overhead > of administering the method identifiers. i'm going to take > a look at the actual changes required to the mib, but don't > believe they will be significant. > > if you, as our mib doctor, think this is a useful change we > will persue it. please let us know your opinion. > > thanks, > kevin to which Dan, as our MIB doctor, heartily agreed. Since then, we have awaited the revised MIB document. Interestingly enough, though the chairs and Allison discussed it in December, with Allison suggesting it was time to declare the document dead and either 1) get new editors, or 2) abandon the effort. Note that since then nobody has asked it about until today. This argues for option 2. Seriously, is anybody actually implementing the SIP mib? If it turns out that people really need this thing, perhaps we can ask Kevin either cough out the document or surrender the pen (and the document source) to a pinch-hitter for carrying across the finish line. -- Dean cochair _______________________________________________ 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 sip-bounces@ietf.org Fri Feb 24 17:28:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FClO9-0003Lc-8a; Fri, 24 Feb 2006 17:26:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FClO7-0003LN-D7 for sip@ietf.org; Fri, 24 Feb 2006 17:26:11 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FClO6-0004E5-1b for sip@ietf.org; Fri, 24 Feb 2006 17:26:11 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1OMQHtf029958 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 24 Feb 2006 16:26:18 -0600 In-Reply-To: <6E9C82D532D127439D866C0425182770779BAB@repbex01.amer.bea.com> References: <6E9C82D532D127439D866C0425182770779BAB@repbex01.amer.bea.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <987F2DB9-DDFC-429D-A5BE-56513CC24F50@softarmor.com> Content-Transfer-Encoding: quoted-printable From: Dean Willis Subject: Re: [Sip] content indirection design question Date: Fri, 24 Feb 2006 16:26:03 -0600 To: Nasir Khan X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Feb 24, 2006, at 4:09 PM, Nasir Khan wrote: > I have this question for the designers of http://www.ietf.org/=20 > internet-drafts/draft-ietf-sip-content-indirect-mech-05.txtThe way =20 > the meta data about the indirect content is split between message =20 > and body is counter-intuitive. Eg. -----------------------------=20 > Actual------------------------- Content-=20 > Type: message/external-body; access-type=3D"URL"; =20 > expiration=3D"Mon, 24 June 2002 09:00:00 GMT"; =20 > URL=3Dhttp://www.example.com/the-indirect-content Content-=20= > Length : 234 Content-Type: image/=20 > jpeg Content-Disposition: =20 > render--------------------------------- The Content-Type header =20 > indicates that this is an indirect content and also contains the =20 > pointer to the actual content, it contains a lot of other =20 > information about the content and then there is a Content-Length =20 > that is not the length of the actual content but the length of the =20 > content attributes that appear as Content headers in the body of =20 > this message, which contains some further information about the =20 > content. This type of semantic overloading and distribution has not =20= > been seen in most of the SIP design that I am aware of so far, what =20= > were the reasons for this design decision? You could have defined =20 > a simple protocol (which you have done indirectly) which is =20 > transported in the message body much like SDP and defines the =20 > content as indirect content, as an example .. Eg. =20 > ------------------------=20 > Suggested-------------------------------------------Content-Type: =20 > application/indirect-contentContent-Length: 563Indirect-=20 > Content-Param: URL;expiration=3D"Mon, 24 June 2002 09:00:00 =20 > GMT"Indirect-Content: http://www.example.com/the-indirect-=20 > contentIndirect-Content-Type: image/jpegIndirect-Content-Length : =20 > 234532Indirect-Content-Description : Happy fish image=85=85etc etc. > ----------------------------------------------------------------------=20= > ------------ > > > > OR alternatively > > You could have extended SIP by adding these headers (Indirect-XXX) =20 > headers in this draft to describe the indirect content and left the =20= > body empty. > > > > Any of these approaches simplify the UA implementation, =20 > particularly in approach-1 that I describe above, I could have used =20= > a factory generated pluggable content protocol handler which is =20 > delegated to deal with the content it specializes in, selectable by =20= > Content-Type header alone which just reads the body of the message =20 > after , where it finds Interesting email format, seems to be devoid of newlines. The history is like this: MIME had already defined message/external-=20 body (RFC 2017) and its semantics. This approach was used in ietf-=20 announce email for years, and I believe was still being used at the =20 time SIP content indirection was introduced. In the usual IETF =20 tradition, we re-used it rather than inventing yet another MIME type. =20= Generality over simplicity, and all that. Besides, this was what the MIME people told us to do. -- 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 sip-bounces@ietf.org Fri Feb 24 21:04:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCokz-0004Ad-SO; Fri, 24 Feb 2006 21:02:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCoky-00049E-Ma for sip@ietf.org; Fri, 24 Feb 2006 21:02:00 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCokx-0005ea-C2 for sip@ietf.org; Fri, 24 Feb 2006 21:02:00 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k1P21te28894; Fri, 24 Feb 2006 21:01:55 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Outbound and STUN Keep Alive Date: Fri, 24 Feb 2006 20:01:49 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF07164A09@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcY5c8s2CeRQTKVnEdqitwARJEEJ/AAOwqJw From: "Francois Audet" To: "Cullen Jennings" , "Dean Willis" , "Rohan Mahy" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Why do you need STUN for that? Couldn't you just assign a static NAT binding for the Outbound proxy?=20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: Friday, February 24, 2006 10:55 > To: Dean Willis; Rohan Mahy > Cc: sip@ietf.org > Subject: Re: [Sip] Outbound and STUN Keep Alive >=20 >=20 > On 2/23/06 1:16 PM, "Dean Willis" wrote: >=20 > > I think you guys are missing Gary's use case. > >=20 > > He's postulating an entirely different NAT problem, where=20 > the NAT is=20 > > between the outbound proxy and the real world, rather than=20 > between the=20 > > UA and its outbound proxy. > >=20 > > This just isn't a use case that's been in scope for general=20 > discussion=20 > > so far. >=20 > If I understand correctly ... I thin I added this use case to=20 > the document awhile back because some people request it. For=20 > some vague reason, I thought Dean was one of the people that=20 > had requested it. People had brought up system like the=20 > ingate stuff. If the use case complicated stuff, I would=20 > remove it but so far the baseline the simple case has pretty=20 > much solved this one too. =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 >=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 sip-bounces@ietf.org Fri Feb 24 23:09:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCqhy-0001jU-73; Fri, 24 Feb 2006 23:07:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCqhw-0001jL-KS for sip@ietf.org; Fri, 24 Feb 2006 23:07:00 -0500 Received: from xproxy.gmail.com ([66.249.82.204]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCqht-0000fJ-EK for sip@ietf.org; Fri, 24 Feb 2006 23:07:00 -0500 Received: by xproxy.gmail.com with SMTP id s19so326751wxc for ; Fri, 24 Feb 2006 20:06:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=pwuj9Cqq2OE1hFXFX9LXYGshTLk7Jl9ItRKXV6ZrEBXlEBD/uPUfKTRrxSxrJHy1KWteX3F/QrQoedtaLLHj4uzXjm12C/E49eRuYv8b/QhWa+slu+SjrfHQI6AFDLo2O4PEeJSiIdCdFvOpC+aKz3a9W96ftvcEOcpIwlXwHiw= Received: by 10.70.105.2 with SMTP id d2mr978904wxc; Fri, 24 Feb 2006 19:59:47 -0800 (PST) Received: by 10.70.122.15 with HTTP; Fri, 24 Feb 2006 19:59:47 -0800 (PST) Message-ID: Date: Sat, 25 Feb 2006 09:29:47 +0530 From: "Adishesh M" To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.8 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Sip] subscription X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0451698328==" Errors-To: sip-bounces@ietf.org --===============0451698328== Content-Type: multipart/alternative; boundary="----=_Part_2724_16141297.1140839987197" ------=_Part_2724_16141297.1140839987197 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Thanks in Advance ------=_Part_2724_16141297.1140839987197 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Thanks in Advance
 
------=_Part_2724_16141297.1140839987197-- --===============0451698328== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0451698328==-- From sip-bounces@ietf.org Fri Feb 24 23:33:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCr5u-0003ug-7R; Fri, 24 Feb 2006 23:31:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCr5r-0003u6-Un for sip@ietf.org; Fri, 24 Feb 2006 23:31:43 -0500 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCr5p-0001bQ-N4 for sip@ietf.org; Fri, 24 Feb 2006 23:31:43 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 0DFFC6C01C; Fri, 24 Feb 2006 23:31:41 -0500 (EST) From: "Dale R. Worley" To: Sip , Sip-Implementors Content-Type: text/plain Date: Fri, 24 Feb 2006 23:31:40 -0500 Message-Id: <1140841900.22188.9.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [Sip] ID: Guidelines for Implementing the GRUU Support in User Agents X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I have just submitted an Internet-Draft that gives a concise summary of how to implement GRUU support in user agents: Guidelines for Implementing the GRUU Support in User Agents draft-worley-sip-gruu-implement-01 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). An Internet-Draft is progressing toward standardization that gives a method by which proxies can construct and delver GRUUs to UAs that request them. This document distills that Internet-Draft into a guide for UA implementors. This I-D is based on the -06 version of the GRUU I-D and on comments from the I-D's authors about the forthcoming -07 version. I would like feedback on this draft, especially from UA implementors. Until it shows up in the usual I-D directories, you can fetch it from: http://scm.sipfoundry.org/rep/ietf-drafts/worley/draft-worley-sip-gruu-implement-01.txt http://scm.sipfoundry.org/rep/ietf-drafts/worley/draft-worley-sip-gruu-implement-01.html http://scm.sipfoundry.org/rep/ietf-drafts/worley/draft-worley-sip-gruu-implement-01.xml Dale --- interop.pingtel.com -- the public SIP phone interoperability test server _______________________________________________ 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 sip-bounces@ietf.org Sat Feb 25 00:49:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCsGt-0006RJ-GQ; Sat, 25 Feb 2006 00:47:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCsGr-0006RB-Jh for sip@ietf.org; Sat, 25 Feb 2006 00:47:09 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCsGr-00038S-AQ for sip@ietf.org; Sat, 25 Feb 2006 00:47:09 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 24 Feb 2006 21:47:09 -0800 X-IronPort-AV: i="4.02,145,1139212800"; d="scan'208"; a="1779639357:sNHT34877572" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k1P5l8uh021363; Fri, 24 Feb 2006 21:47:08 -0800 (PST) Received: from 10.21.80.142 ([10.21.80.142]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sat, 25 Feb 2006 05:47:08 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Fri, 24 Feb 2006 21:47:06 -0800 Subject: Re: [Sip] Outbound and STUN Keep Alive From: Cullen Jennings To: Dean Willis Message-ID: Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcY5zujkJ5v6CKXCEdq+6AARJEEJ/A== In-Reply-To: <5D0FEDCB-A6BD-45B5-9076-71DBFB479480@softarmor.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 2/24/06 1:47 PM, "Dean Willis" wrote: > > On Feb 24, 2006, at 12:54 PM, Cullen Jennings wrote: > >> On 2/23/06 1:16 PM, "Dean Willis" wrote: >> >>> I think you guys are missing Gary's use case. >>> >>> He's postulating an entirely different NAT problem, where the NAT >>> is between >>> the outbound proxy and the real world, rather than between the UA >>> and its >>> outbound proxy. >>> >>> This just isn't a use case that's been in scope for general >>> discussion so far. >> >> If I understand correctly ... I thin I added this use case to the >> document >> awhile back because some people request it. For some vague reason, >> I thought >> Dean was one of the people that had requested it. People had >> brought up >> system like the ingate stuff. If the use case complicated stuff, I >> would >> remove it but so far the baseline the simple case has pretty much >> solved >> this one too. > > Yep, I motivated the use case at one point. > > However, what you have in 3.4 isn't quite what what Gary seemed to be > looking at, in that: > > 1) 3.4 shows another NAT between the UA and the EP. This doesn't make > the use case of 3.4 weaker, but might lead people to think that it is > a different problem, when this aspect is really a more-general > variant of Gary's case. > > 2) 3.4 does not seem show the use of "classic STUN" to discover the > effective IP address for RTP, along a path disparate from the coaxial > STUN used as a NAT keepalive. This is implied in the text, and is > obvious from STUN itself, but might not be obvious to somebody who > hasn't been thinking about this for a long time. > > 3) The use of coaxial STUN between the EP and the registrar, though > implied in 3.4, also doesn't seem obvious in the text. Nor is the > requirement for "back pressure" from the EP to the UA, should the EP- > Registrar coaxial STUN indicate a reset of the NAT between those > nodes. If this happens, I think that EP needs to induce a "keepalive > failure" on its own channel back to UA. You talk about UAs detecting > flow failure, but not about proxies detecting flow failure. Maybe it > is in there and I just missed it . . . > > -- > Dean > Yep - I see what you are saying. I will try and clarify the draft a bit. _______________________________________________ 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 sip-bounces@ietf.org Sat Feb 25 00:52:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCsKH-0000Em-Dk; Sat, 25 Feb 2006 00:50:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCsKF-0000Eg-PG for sip@ietf.org; Sat, 25 Feb 2006 00:50:39 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCsKE-0003GO-Ev for sip@ietf.org; Sat, 25 Feb 2006 00:50:39 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 24 Feb 2006 21:50:39 -0800 X-IronPort-AV: i="4.02,145,1139212800"; d="scan'208"; a="1779639951:sNHT31911644" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k1P5obXf025426; Fri, 24 Feb 2006 21:50:37 -0800 (PST) Received: from 10.21.80.142 ([10.21.80.142]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sat, 25 Feb 2006 05:50:37 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Fri, 24 Feb 2006 21:50:35 -0800 Subject: Re: [Sip] Outbound and STUN Keep Alive From: Cullen Jennings To: Francois Audet , Dean Willis , Rohan Mahy Message-ID: Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcY5c8s2CeRQTKVnEdqitwARJEEJ/AAOwqJwAAgj7kk= In-Reply-To: <1ECE0EB50388174790F9694F77522CCF07164A09@zrc2hxm0.corp.nortel.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Static binding would work but requires NAT configuration. I think some people were imaging a small office type situation where it would be preferable not to require manual configuration of the NAT. If this complicates the draft, based on the input to get the main use case done, I am likely to just point it out as something not solved and keep the draft such that future work could solve this. On 2/24/06 6:01 PM, "Francois Audet" wrote: > Why do you need STUN for that? > > Couldn't you just assign a static NAT binding for the Outbound proxy? > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Friday, February 24, 2006 10:55 >> To: Dean Willis; Rohan Mahy >> Cc: sip@ietf.org >> Subject: Re: [Sip] Outbound and STUN Keep Alive >> >> >> On 2/23/06 1:16 PM, "Dean Willis" wrote: >> >>> I think you guys are missing Gary's use case. >>> >>> He's postulating an entirely different NAT problem, where >> the NAT is >>> between the outbound proxy and the real world, rather than >> between the >>> UA and its outbound proxy. >>> >>> This just isn't a use case that's been in scope for general >> discussion >>> so far. >> >> If I understand correctly ... I thin I added this use case to >> the document awhile back because some people request it. For >> some vague reason, I thought Dean was one of the people that >> had requested it. People had brought up system like the >> ingate stuff. If the use case complicated stuff, I would >> remove it but so far the baseline the simple case has pretty >> much solved this one too. >> >> _______________________________________________ >> 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 sip-bounces@ietf.org Sat Feb 25 02:37:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCtxG-0005TA-1B; Sat, 25 Feb 2006 02:35:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCtxE-0005RO-5a for sip@ietf.org; Sat, 25 Feb 2006 02:35:00 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCtxA-0006Do-QJ for sip@ietf.org; Sat, 25 Feb 2006 02:35:00 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1P7Z2aT031715 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 25 Feb 2006 01:35:03 -0600 In-Reply-To: <43FEA4D0.3050806@cisco.com> References: <26fbf302818a0cbbe4558f83410f081c@ekabal.com> <43FEA4D0.3050806@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <626CD79E-7A79-4F4A-A69B-BDB74A1672F6@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] WGLC for draft-ietf-sip-answermode-00 Date: Sat, 25 Feb 2006 01:34:48 -0600 To: Paul Kyzivat X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: SIP WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Feb 24, 2006, at 12:16 AM, Paul Kyzivat wrote: >> Hi, >> I'd like to start a 3-week working group last call for: >> draft-ietf-sip-answermode-00.txt >> This WGLC will complete on March 15th > > There are several instances of a feature tag of > "extension="answermode"". That ought to be "extensions". > > (I know dean consulted me on this long ago to get it right, so its > most likely my own error.) Hey, I just cut-and-paste. I don't know nothing. > > Note that there are also some correct usages in the doc. > I got lucky? > In section 6.1, a Contact header is folded across multiple lines, > but the subsequent lines are not indented. > xml2rfc . . . > In section 7.3: s/nee o make/need to make/ > thanks. > In section 7.4: > > User agents implementing this specification MUST NOT establish a > session providing outbound or bidirectional media without explicit > user acceptance. > > Isn't this a little strong? It totally eliminates the baby monitor > as a supported application. It also eliminates using this in > support of a loopback test mode. Eliminating any possibility of baby monitor was a "very hard" requirement from Cullen. I don't think, however, that looped-back media counts as bidirectional. I can probably tack a caveat on here for media reflection or loopback. -- 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 sip-bounces@ietf.org Sat Feb 25 02:38:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCtyP-0006yp-12; Sat, 25 Feb 2006 02:36:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCtyO-0006yW-2O for sip@ietf.org; Sat, 25 Feb 2006 02:36:12 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCtyN-0006Em-PK for sip@ietf.org; Sat, 25 Feb 2006 02:36:12 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1P7aIcI031719 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 25 Feb 2006 01:36:19 -0600 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF07164A09@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF07164A09@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9273F8D2-4FDE-4744-B8AF-7E36512788AA@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Sat, 25 Feb 2006 01:36:04 -0600 To: Francois Audet X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Cullen Jennings , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Feb 24, 2006, at 8:01 PM, Francois Audet wrote: > Why do you need STUN for that? > > Couldn't you just assign a static NAT binding for the Outbound proxy? How do you do that? It's a DHCP client behind the NAT-firewall . . . possibly somebody else's NAT-firewall. -- 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 sip-bounces@ietf.org Sat Feb 25 02:39:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCtzu-0008Ds-8O; Sat, 25 Feb 2006 02:37:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCtzs-0008Di-P4 for sip@ietf.org; Sat, 25 Feb 2006 02:37:44 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCtzs-0006II-FT for sip@ietf.org; Sat, 25 Feb 2006 02:37:44 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1P7bpG7031745 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 25 Feb 2006 01:37:52 -0600 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Sat, 25 Feb 2006 01:37:36 -0600 To: Cullen Jennings X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: "sip@ietf.org" , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Feb 24, 2006, at 11:50 PM, Cullen Jennings wrote: > > Static binding would work but requires NAT configuration. I think some > people were imaging a small office type situation where it would be > preferable not to require manual configuration of the NAT. > > If this complicates the draft, based on the input to get the main > use case > done, I am likely to just point it out as something not solved and > keep the > draft such that future work could solve this. > personally, I could be happy with that. We can do interproxy coaxial stunalive separately. Wow, I just made up a new phrase! -- 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 sip-bounces@ietf.org Sat Feb 25 02:44:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCu4v-0003dG-PD; Sat, 25 Feb 2006 02:42:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCu4u-0003dB-3T for sip@ietf.org; Sat, 25 Feb 2006 02:42:56 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCu4s-0006Xh-PV for sip@ietf.org; Sat, 25 Feb 2006 02:42:56 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1P7h0uq031793 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 25 Feb 2006 01:43:02 -0600 In-Reply-To: <001601c638a4$3ab6fa60$31713b51@BEMBUSTER> References: <26fbf302818a0cbbe4558f83410f081c@ekabal.com> <001601c638a4$3ab6fa60$31713b51@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5F2FBAD3-197B-4EC1-BF56-CDE9D633E3F1@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] WGLC for draft-ietf-sip-answermode-00 Date: Sat, 25 Feb 2006 01:42:46 -0600 To: Jeroen van Bemmel , Paul Kyzivat X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: SIP WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org n Feb 23, 2006, at 12:09 PM, Jeroen van Bemmel wrote: > Rohan, > > Two remarks: > 1. I would propose to change the ABNF to allow for a list of > generic-params, as is common for most SIP headers > The current version limits the extensibility to 1 parameter > (name=value) which would replace "Manual" or "Auto", and possibly a > list of tokens (which would be interpreted as flag parameters) > > How about the following: > Answer-Mode = "Answer-Mode" HCOLON answer-mode *(SEMI answer-mode- > param) > Priv-Answer-Mode = "Priv-Answer-Mode" HCOLON answer-mode *(SEMI > answer-mode-param) > > answer-mode = "Manual" / "Auto" / token > answer-mode-param = "require" / generic-param2. (NIT) Example > section 6.2, "Requires" header should be "Require" > Yeah, that works for me. OK with you, Paul? You sent the other syntax. -- 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 sip-bounces@ietf.org Sat Feb 25 10:16:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD17j-0003WK-Sv; Sat, 25 Feb 2006 10:14:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD17i-0003WF-Km for sip@ietf.org; Sat, 25 Feb 2006 10:14:18 -0500 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FD17h-0002TS-5m for sip@ietf.org; Sat, 25 Feb 2006 10:14:18 -0500 Received: (qmail 30616 invoked by uid 0); 25 Feb 2006 15:14:12 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 25 Feb 2006 15:14:12 -0000 Message-ID: <030801c63a1e$20df1ac0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Dale R. Worley" , "Sip" , "Sip-Implementors" References: <1140841900.22188.9.camel@cdhcp139.pingtel.com> Date: Sat, 25 Feb 2006 16:14:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Subject: [Sip] Re: [Sip-implementors] ID: Guidelines for Implementing the GRUU Supportin User Agents X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dale, Three questions: 1) Guideline 16: "The UA should add "Supported: gruu" to its requests and responses [...]", isn't this too broad? We had some quite extensive discussions about the meaning of Supported, and ended up with some text suggested by you on 9th of November 2005: "The presence of Supported: gruu suggests a high likelihood that the Contact is a GRUU, and so a UA using that Contact SHOULD proceed on the assumption that it is a GRUU, until it has positive information that it is not. In particular, the UA should not utilize any mechanisms to work around that the Contact is not a GRUU until it has determined that utilizing it as a GRUU does not work." I'm assuming this is going to be in the next update of the draft. "Supported: gruu" would thus only be needed whenever a Contact is provided (i.e. in dialog-creating requests and responses, REGISTER, target refreshes), and then only iff the Contact is indeed a GRUU. A UAC that registered with a registrar which does not support GRUUs should not add it 2) Guideline 12 - shouldn't this be about the From header? 3) On 6th of november 2005 Jonathan made a remark on caching of capabilities, and that it would probably be convenient if endpoints were to change their instance ID when their firmware / software changed. Would this be something to put in a guideline? Regards, jeroen ----- Original Message ----- From: "Dale R. Worley" To: "Sip" ; "Sip-Implementors" Sent: Saturday, February 25, 2006 5:31 AM Subject: [Sip-implementors] ID: Guidelines for Implementing the GRUU Supportin User Agents >I have just submitted an Internet-Draft that gives a concise summary of > how to implement GRUU support in user agents: > > Guidelines for Implementing the GRUU Support in User Agents > draft-worley-sip-gruu-implement-01 > > 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). An Internet-Draft is progressing > toward standardization that gives a method by which proxies can > construct and delver GRUUs to UAs that request them. This document > distills that Internet-Draft into a guide for UA implementors. > > This I-D is based on the -06 version of the GRUU I-D and on comments > from the I-D's authors about the forthcoming -07 version. > > I would like feedback on this draft, especially from UA implementors. > > Until it shows up in the usual I-D directories, you can fetch it from: > http://scm.sipfoundry.org/rep/ietf-drafts/worley/draft-worley-sip-gruu-implement-01.txt > http://scm.sipfoundry.org/rep/ietf-drafts/worley/draft-worley-sip-gruu-implement-01.html > http://scm.sipfoundry.org/rep/ietf-drafts/worley/draft-worley-sip-gruu-implement-01.xml > > Dale > > --- > interop.pingtel.com -- the public SIP phone interoperability test server > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ 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 sip-bounces@ietf.org Sat Feb 25 11:08:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD1wM-0005fH-EF; Sat, 25 Feb 2006 11:06:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD1wL-0005fC-7q for sip@ietf.org; Sat, 25 Feb 2006 11:06:37 -0500 Received: from celine.siteprotect.com ([64.41.122.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FD1wJ-0003z7-Vd for sip@ietf.org; Sat, 25 Feb 2006 11:06:37 -0500 Received: from [192.168.1.5] (pool-141-157-104-69.balt.east.verizon.net [141.157.104.69]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id k1PG6Za00892 for ; Sat, 25 Feb 2006 10:06:35 -0600 Subject: RE: [Sip] Outbound and STUN Keep Alive From: "Frank W. Miller" To: sip@ietf.org In-Reply-To: <1ECE0EB50388174790F9694F77522CCF07164A09@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF07164A09@zrc2hxm0.corp.nortel.com> Content-Type: text/plain Organization: Cornfed Systems, LLC Date: Sat, 25 Feb 2006 11:06:30 -0500 Message-Id: <1140883590.2638.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fwmiller@cornfed.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org PING draft updated to reflect unreliable transmission (i.e. no retransmission required at the transaction level). http://www.cornfed.com/ping.html http://www.cornfed.com/ping.txt 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 sip-bounces@ietf.org Sat Feb 25 12:18:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD32E-0002yw-BY; Sat, 25 Feb 2006 12:16:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD32D-0002yr-FR for sip@ietf.org; Sat, 25 Feb 2006 12:16:45 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FD32C-0006C4-6e for sip@ietf.org; Sat, 25 Feb 2006 12:16:45 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 25 Feb 2006 09:16:44 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1PHGgtH022127; Sat, 25 Feb 2006 09:16:42 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 25 Feb 2006 09:15:35 -0800 Received: from [10.21.120.130] ([10.21.120.130]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 25 Feb 2006 09:15:35 -0800 Message-ID: <440090B6.1050509@cisco.com> Date: Sat, 25 Feb 2006 12:15:34 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] WGLC for draft-ietf-sip-answermode-00 References: <26fbf302818a0cbbe4558f83410f081c@ekabal.com> <001601c638a4$3ab6fa60$31713b51@BEMBUSTER> <5F2FBAD3-197B-4EC1-BF56-CDE9D633E3F1@softarmor.com> In-Reply-To: <5F2FBAD3-197B-4EC1-BF56-CDE9D633E3F1@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Feb 2006 17:15:35.0516 (UTC) FILETIME=[1748D1C0:01C63A2F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: SIP WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yes, that works for me, almost. What is "generic-param2"? I presume "generic-param" is what is intended. Paul Dean Willis wrote: > > n Feb 23, 2006, at 12:09 PM, Jeroen van Bemmel wrote: > >> Rohan, >> >> Two remarks: >> 1. I would propose to change the ABNF to allow for a list of >> generic-params, as is common for most SIP headers >> The current version limits the extensibility to 1 parameter >> (name=value) which would replace "Manual" or "Auto", and possibly a >> list of tokens (which would be interpreted as flag parameters) >> >> How about the following: >> Answer-Mode = "Answer-Mode" HCOLON answer-mode *(SEMI answer-mode- param) >> Priv-Answer-Mode = "Priv-Answer-Mode" HCOLON answer-mode *(SEMI >> answer-mode-param) >> >> answer-mode = "Manual" / "Auto" / token >> answer-mode-param = "require" / generic-param2. (NIT) Example section >> 6.2, "Requires" header should be "Require" >> > > > > Yeah, that works for me. > > OK with you, Paul? You sent the other syntax. > > -- > 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 sip-bounces@ietf.org Sat Feb 25 13:13:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD3tQ-0005RL-DD; Sat, 25 Feb 2006 13:11:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD3tP-0005Qx-3x for sip@ietf.org; Sat, 25 Feb 2006 13:11:43 -0500 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FD3tN-0007wJ-Nb for sip@ietf.org; Sat, 25 Feb 2006 13:11:43 -0500 Received: (qmail 8878 invoked by uid 0); 25 Feb 2006 18:11:38 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 25 Feb 2006 18:11:38 -0000 Message-ID: <033b01c63a36$ea216560$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Paul Kyzivat" , "Dean Willis" References: <26fbf302818a0cbbe4558f83410f081c@ekabal.com> <001601c638a4$3ab6fa60$31713b51@BEMBUSTER> <5F2FBAD3-197B-4EC1-BF56-CDE9D633E3F1@softarmor.com> <440090B6.1050509@cisco.com> Subject: Re: [Sip] WGLC for draft-ietf-sip-answermode-00 Date: Sat, 25 Feb 2006 19:11:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: SIP WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul, Sorry, the newline fell away (2 was a second, minor point). It should say: Answer-Mode = "Answer-Mode" HCOLON answer-mode *(SEMI answer-mode- param) Priv-Answer-Mode = "Priv-Answer-Mode" HCOLON answer-mode *(SEMI answer-mode-param) answer-mode = "Manual" / "Auto" / token answer-mode-param = "require" / generic-param 2. Example section 6.2, "Requires" header should be "Require" jeroen ----- Original Message ----- From: "Paul Kyzivat" To: "Dean Willis" Cc: "Jeroen van Bemmel" ; "Rohan Mahy" ; "SIP WG" Sent: Saturday, February 25, 2006 6:15 PM Subject: Re: [Sip] WGLC for draft-ietf-sip-answermode-00 > Yes, that works for me, almost. What is "generic-param2"? I presume > "generic-param" is what is intended. > > Paul > > Dean Willis wrote: >> >> n Feb 23, 2006, at 12:09 PM, Jeroen van Bemmel wrote: >> >>> Rohan, >>> >>> Two remarks: >>> 1. I would propose to change the ABNF to allow for a list of >>> generic-params, as is common for most SIP headers >>> The current version limits the extensibility to 1 parameter >>> (name=value) which would replace "Manual" or "Auto", and possibly a >>> list of tokens (which would be interpreted as flag parameters) >>> >>> How about the following: >>> Answer-Mode = "Answer-Mode" HCOLON answer-mode *(SEMI answer-mode- >>> param) >>> Priv-Answer-Mode = "Priv-Answer-Mode" HCOLON answer-mode *(SEMI >>> answer-mode-param) >>> >>> answer-mode = "Manual" / "Auto" / token >>> answer-mode-param = "require" / generic-param2. (NIT) Example section >>> 6.2, "Requires" header should be "Require" >>> >> >> >> >> Yeah, that works for me. >> >> OK with you, Paul? You sent the other syntax. >> >> -- >> 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 sip-bounces@ietf.org Sat Feb 25 16:27:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD6vA-0002Io-Vv; Sat, 25 Feb 2006 16:25:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD6v9-0002Ij-8r for sip@ietf.org; Sat, 25 Feb 2006 16:25:43 -0500 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55] helo=zrtps0kn.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FD6v5-0005VS-TB for sip@ietf.org; Sat, 25 Feb 2006 16:25:43 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k1PLPZY17858; Sat, 25 Feb 2006 16:25:35 -0500 (EST) Received: from [192.168.15.100] ([47.102.184.97] RDNS failed) by zrc2hxm0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 25 Feb 2006 15:25:34 -0600 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6FCEDB39-F249-4E29-804A-F6ED487B7C1C@nortel.com> Content-Transfer-Encoding: 7bit From: "Francois Audet" Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Sat, 25 Feb 2006 13:25:34 -0800 To: Dean Willis X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 25 Feb 2006 21:25:34.0884 (UTC) FILETIME=[039ABE40:01C63A52] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: JENNINGS Cullen , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I guess one could have the proxy itself send STUN packets (or other methods). It could try to multiplex many connections into a smaller number of TCP connections (like 1). But, yeah, I'm happy with Cullen's proposal. On Feb 24, 2006, at 23:37 , Dean Willis wrote: > > On Feb 24, 2006, at 11:50 PM, Cullen Jennings wrote: > >> >> Static binding would work but requires NAT configuration. I think >> some >> people were imaging a small office type situation where it would be >> preferable not to require manual configuration of the NAT. >> >> If this complicates the draft, based on the input to get the main >> use case >> done, I am likely to just point it out as something not solved and >> keep the >> draft such that future work could solve this. >> > > personally, I could be happy with that. We can do interproxy > coaxial stunalive separately. Wow, I just made up a new phrase! > > -- > 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 sip-bounces@ietf.org Sun Feb 26 14:42:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDRkH-0004hC-L8; Sun, 26 Feb 2006 14:39:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDRkF-0004h7-VP for sip@ietf.org; Sun, 26 Feb 2006 14:39:51 -0500 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDRkE-0004pm-KT for sip@ietf.org; Sun, 26 Feb 2006 14:39:51 -0500 Received: from [127.0.0.1] (really [24.54.26.203]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060226193949.OCLZ8442.mta10.adelphia.net@[127.0.0.1]> for ; Sun, 26 Feb 2006 14:39:49 -0500 Message-ID: <44022DA1.5050403@ieee.org> Date: Sun, 26 Feb 2006 14:37:21 -0800 From: Mark Ellison Organization: Ellison Software Consulting, Inc. User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Subject: Re: [Sip] status on the SIP MIB modules? References: <43FF42D7.8080809@ieee.org> <84020EBD-77D7-46D5-A887-AD12EEB2F8BE@softarmor.com> In-Reply-To: <84020EBD-77D7-46D5-A887-AD12EEB2F8BE@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Dean, Thanks for your reply. My understanding is another mechanism for exposing SIP statistics is moving forward, based upon the SIPPING draft-ietf-sipping-rtcp-summary-00 and AVT draft-ietf-avt-rtcp-xr-mib-03 drafts. Maybe others on the list have considerations or concerns regarding any added usefulness for keeping the SIP MIB modules around? Regards, Mark Dean Willis wrote: > On Feb 24, 2006, at 11:31 AM, Mark Ellison wrote: > >> Hi, >> >> What is the current status for the SIP MIB modules? >> >> I notice that draft-ietf-sip-mib-09 is the latest revision of these >> module. It is my understanding -09 was submitted for IESG >> processing and that the current IESG status is "revised ID needed" , >> as of 2005-12-11 (see http://tools.ietf.org/wg/sip/). Also, I >> notice that this matter is not on the agenda for IETF #65. >> >> Also I have a question about the sipMethodSupportedIndex object with >> respect to IANA registrations. In checking the IANA registry for >> sip (http://www.iana.org/assignments/sip-parameters) I see a list >> of methods (e.g. ACK, BYE, CANCEL, INFO...). I am assuming the >> intent is that SIP method names are in the IANA registry, as are SIP >> option tags. Possibly this is an area of the SIP MIB modules in >> need of revision? >> >> Regards, > > > It appears to be suffering from a severe case of apathy. > > The last email I saw on the list was last summer, which may answer > your question about the sipMethodSupportedIndex object. > >> -----Original Message----- >> From: Kevin Lingle (klingle) [mailto:klingle@cisco.com] >> Sent: Friday, August 05, 2005 1:07 AM >> To: Romascanu, Dan (Dan) >> Cc: j.schoenwaelder@iu-bremen.de; sip@ietf.org; Wijnen, Bert >> (Bert); jf.mule@cablelabs.com >> Subject: RE: [Sip] draft-ietf-sip-mib-09.txt - 'MIB Doctor' review >> >> dan, >> >> jean-francois and i have discussed the issue of using method >> name as an index and, at this point, neither of us >> are against making that change. it has the benefit of >> removing the method to identifier table and the IANA overhead >> of administering the method identifiers. i'm going to take >> a look at the actual changes required to the mib, but don't >> believe they will be significant. >> >> if you, as our mib doctor, think this is a useful change we >> will persue it. please let us know your opinion. >> >> thanks, >> kevin > > > to which Dan, as our MIB doctor, heartily agreed. > > Since then, we have awaited the revised MIB document. > > Interestingly enough, though the chairs and Allison discussed it in > December, with Allison suggesting it was time to declare the document > dead and either 1) get new editors, or 2) abandon the effort. Note > that since then nobody has asked it about until today. This argues > for option 2. > > Seriously, is anybody actually implementing the SIP mib? > > If it turns out that people really need this thing, perhaps we can > ask Kevin either cough out the document or surrender the pen (and the > document source) to a pinch-hitter for carrying across the finish line. > > -- > Dean > cochair > > _______________________________________________ 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 sip-bounces@ietf.org Sun Feb 26 18:15:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDV4l-0007PA-9h; Sun, 26 Feb 2006 18:13:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDV4j-0007P5-MH for sip@ietf.org; Sun, 26 Feb 2006 18:13:13 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDV4j-0001p0-Ad for sip@ietf.org; Sun, 26 Feb 2006 18:13:13 -0500 Received: from [131.161.248.91] (open-131-161-248-91.cliq.com [131.161.248.91]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k1QND5F07868; Sun, 26 Feb 2006 15:13:05 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4d8ab737eca9374ed60fb959e29ec1ed@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Sun, 26 Feb 2006 15:13:09 -0800 To: Cullen Jennings X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: "sip@ietf.org" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, If my recollection is correct, I think we decided that use cases of NATs between proxies is out of scope of *this* document and that we can work on the (probably harder) proxy to proxy problem in *another* document so we can solve the more pressing problem sooner. In any case, the proxy to proxy case is not explicitly listed in the requirements anywhere. thanks, -rohan On Feb 24, 2006, at 21:47, Cullen Jennings wrote: > On 2/24/06 1:47 PM, "Dean Willis" wrote: > >> >> On Feb 24, 2006, at 12:54 PM, Cullen Jennings wrote: >> >>> On 2/23/06 1:16 PM, "Dean Willis" wrote: >>> >>>> I think you guys are missing Gary's use case. >>>> >>>> He's postulating an entirely different NAT problem, where the NAT >>>> is between >>>> the outbound proxy and the real world, rather than between the UA >>>> and its >>>> outbound proxy. >>>> >>>> This just isn't a use case that's been in scope for general >>>> discussion so far. >>> >>> If I understand correctly ... I thin I added this use case to the >>> document >>> awhile back because some people request it. For some vague reason, >>> I thought >>> Dean was one of the people that had requested it. People had >>> brought up >>> system like the ingate stuff. If the use case complicated stuff, I >>> would >>> remove it but so far the baseline the simple case has pretty much >>> solved >>> this one too. >> >> Yep, I motivated the use case at one point. >> >> However, what you have in 3.4 isn't quite what what Gary seemed to be >> looking at, in that: >> >> 1) 3.4 shows another NAT between the UA and the EP. This doesn't make >> the use case of 3.4 weaker, but might lead people to think that it is >> a different problem, when this aspect is really a more-general >> variant of Gary's case. >> >> 2) 3.4 does not seem show the use of "classic STUN" to discover the >> effective IP address for RTP, along a path disparate from the coaxial >> STUN used as a NAT keepalive. This is implied in the text, and is >> obvious from STUN itself, but might not be obvious to somebody who >> hasn't been thinking about this for a long time. >> >> 3) The use of coaxial STUN between the EP and the registrar, though >> implied in 3.4, also doesn't seem obvious in the text. Nor is the >> requirement for "back pressure" from the EP to the UA, should the EP- >> Registrar coaxial STUN indicate a reset of the NAT between those >> nodes. If this happens, I think that EP needs to induce a "keepalive >> failure" on its own channel back to UA. You talk about UAs detecting >> flow failure, but not about proxies detecting flow failure. Maybe it >> is in there and I just missed it . . . >> >> -- >> Dean >> > > Yep - I see what you are saying. I will try and clarify the draft a > bit. _______________________________________________ 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 sip-bounces@ietf.org Sun Feb 26 19:08:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDVtw-0001WS-FF; Sun, 26 Feb 2006 19:06:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDVtu-0001Vs-IZ; Sun, 26 Feb 2006 19:06:06 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDVtu-0003Ex-19; Sun, 26 Feb 2006 19:06:06 -0500 Received: from [131.161.248.91] (open-131-161-248-91.cliq.com [131.161.248.91]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k1R05wF08403; Sun, 26 Feb 2006 16:05:58 -0800 In-Reply-To: <231F5685-CCC1-41B1-997E-74AF67D9EBCE@softarmor.com> References: <231F5685-CCC1-41B1-997E-74AF67D9EBCE@softarmor.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Thoughts on the Principle of Dividing and Conquering Date: Sun, 26 Feb 2006 16:06:01 -0800 To: Dean Willis X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: Cullen Jennings , Jon Peterson , Allison Mankin , "sip@ietf.org List" , Sipping List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I don't think further splitting is going to solve our problems due to the complexity of lateral communication required among groups with this much in common. I do think that a working group that describes use cases for the RAI area in general could produce some very useful output that has been out of scope of individual working groups. The SIP NAT scenarios document would be a good candidate to move into such a WG. I think mostly we have a problem saying no. We have too much work to do and the only effective way for this community to get better throughput is to focus religiously on a much smaller handful of work items (ex: 4 or 5) at a time. I am as guilty as the next person for adding new milestones (actually, more guilty as a chair), but it is hard to say no to new work when old work that is "almost done" takes so long to finish. Perhaps we can have a discussion of this in the RAI area open meeting at Dallas. It would be nice to hear the new ADs jump in here with their thoughts. Also, Allison has been wrangling this monster longer than anyone except Dean, so I am curious what she has to say. thanks, -rohan On Feb 23, 2006, at 16:30, Dean Willis wrote: > I've been working on SIP and SIPPING and P2P-SIP agendas this week, > and that started me thinking. > > We spun up SIPPING to take some of the load off of SIP, and in doing > so tried to more narrowly-define the charters of both SIP and SIPPING > relative to the previous SIP charter. > > When we started talking about P2P-SIP, we thought about bringing in > the topic as part of SIPPING, but fairly quickly rejected that idea > because it was clearly partitionable. > > This started me thinking -- could we further apply this principle of > partitioning? > > Both SIP and SIPPING have grown into multi-year monsters, each with > large charters and the need for multiple long-sessions at each IETF. > They're tricky to chair, require lots of secretarial work, and are > chronically late on deliverables (in large part because the chairs are > acting like ADs instead of chairs). SPPING, once viewed as the kidney > of SIP, now needs its own dialysis. > > Perhaps if we were to split these two working groups into three or > four working groups that have much more clearly defined missions and > scopes, we could cut them down to one meeting slot each. And if we > were to have separate management (chairs and secretaries) for each > working group, we could better manage the groups to timely delivery. > > So I'd like to toss out some ideas on how we might subdivide, and see > how you folks feel about this. I think the key to any success here > would be in scope management. > > What if we had the following groups: > > 1) SIPEM -- SIP Extended Maintenance > > 2) SIPNEW -- New major functionality for SIP > > 3) SIPREQ -- Analysis of requirements raised by new applications or > SDO liaison > > 4) SIPUSE -- Using SIP to meet specific application requirements > > > > Here's how we might divide the work: > > > SIPEM > ----- > > Scope: Maintenance of SIP 2.0 and development (as per RFC 3427) of > backward-compatible extensions driven by applications with near-term > deployment scenarios. > > Initial Milestone Tasks of SIPEM: > > 1) Developing a SIP Guidebook, roughly the equivalent of the TCP > Roadmap, that defines what's "in" SIP and how the pieces fit together. > > 2) GRUU > > 3) Outbound > > 4) Target-Dialog > > 5) Certificate Usage > > 6) Location Transport > > 7) Loop Error Correction > > 8) Connected Party Identity > > 9) Hop Limit Diagnostics > > 10) TLS Usage > > 11) Answering Modes > > 12) Connection Reuse > > 13) Rejection of Anonymous Requests > > 14) Consent Mechanism > > > > SIPNEW > ------ > > Scope: Enhancement and evolution of SIP including architectural-level > requirements and (as per RFC 3427) extensions without requirements for > backward compatibility. > > > Initial milestone tasks of SIPNEW > > 1) Developing a "future roadmap" for the evolution of SIP > > 2) Solving the RFC 3261 Routing Problem > > 3) Use of SAML with SIP > > 4) Response Identity > > 5) Response Authentication > > 6) End to Middle Requests > > > > SIPREQ > ------ > > Scope: Analysis of requirements raised by new applications of SIP in > IETF or in external SDOs (as per RFC 3427). Development of > requirements for changes to SIP or for usage guides in response to > applications requirements. Another way of wording this would be > "problem definition". > > Initial milestones and tasks of SIPREQ: > > 1) Session Policy Requirements > > > > SIPUSE > ------ > > Scope: Guidance on how to use existing SIP specifications and > mechanisms including examples, call flows, test cases, error > avoidance, and so on. Review (as per RFC 3427) of SIP Event Packages. > > > Initial milestones and tasks for SIPUSE: > > 1) Service Examples > > 2) Security Examples > > 3) Race Condition Examples > > 4) Session media policy mechanism > > 5) Session policy package mechanism > > 6) Service quality reporting mechanism > > 7) URI List mechanism > > 8) Subscriptions to Ad-Hoc Resource Lists mechanism > > 9) Multiple REFER mechanism > > 10) Ad-Hoc Conferencing using URI lists mechanism > > 11) Call Control Transfer mechanism > > 12) Configuration Delivery mechanism > > 13) Emergency Calling using SIP (SOS) mechanism > > > > > Note that I'm not entirely happy with the division of SIPPING into > SIPUSE and SIPREQ. While it seems like we spend a lot of time in > SIPPING debating requirements, there are currently a lot of > deliverables in this category. > > > -- > 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 sip-bounces@ietf.org Sun Feb 26 20:23:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDX4W-0002vS-NZ; Sun, 26 Feb 2006 20:21:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDX4V-0002vN-7V for sip@ietf.org; Sun, 26 Feb 2006 20:21:07 -0500 Received: from firewall.objectworld.com ([72.1.207.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDX4U-0005Lg-B9 for sip@ietf.org; Sun, 26 Feb 2006 20:21:07 -0500 Received: from photon.objectworld.com (photon.objectworld.com [192.168.1.2]) by firewall.objectworld.com (8.12.11/8.12.11) with ESMTP id k1R1Ktje007846 for ; Sun, 26 Feb 2006 20:21:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Outbound and STUN Keep Alive Date: Sun, 26 Feb 2006 20:20:55 -0500 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C51609E1@photon.objectworld.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcY7KpguGLAmPCvoR3KU0rDNoVIhugAD/F0K References: <4d8ab737eca9374ed60fb959e29ec1ed@ekabal.com> From: "Michael Slavitch" To: "Rohan Mahy" , "Cullen Jennings" X-Spam-Score: 0.00 () [Tag at 15.00] HTML_MESSAGE X-CanItPRO-Stream: outgoing X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.1.1 X-Spam-Score: 0.5 (/) X-Scan-Signature: 5ba9b8496764663b12c333825fbf6b3d Cc: sip@ietf.org, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0904254957==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0904254957== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63B3C.0E90CB72" This is a multi-part message in MIME format. ------_=_NextPart_001_01C63B3C.0E90CB72 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =0A= I am not sure why it is a harder problem. It is a question of actions that = happen between peer agents, in this case one agent just happens to be a pro= xy, and in the other case both agents are proxies. I can see why it was not= in the original scope of requirements, but now that it's been alerted it g= ives me pause that there is resistence in putting it in. Proxies should be = able to go anywhere in the same way that agents should be able to go anywhe= re.=0A= =0A= Do people really consider proxies something so special that they deserve sp= ecial treatment, and are things SIP-wise separate from user agents? If so t= hen SIP has changed from what it used to be and is losing its simple distri= buted nature and becoming something that seems increasingly monolithic.=0A= =0A= Regards=0A= =0A= M=0A= =0A= =0A= -----Original Message-----=0A= From: Rohan Mahy [mailto:rohan@ekabal.com]=0A= Sent: Sun 26/02/2006 6:13 PM=0A= To: Cullen Jennings=0A= Cc: sip@ietf.org; Dean Willis=0A= Subject: Re: [Sip] Outbound and STUN Keep Alive=0A= =20=0A= Hi,=0A= =0A= If my recollection is correct, I think we decided that use cases of=20=0A= NATs between proxies is out of scope of *this* document and that we can=20= =0A= work on the (probably harder) proxy to proxy problem in *another*=20=0A= document so we can solve the more pressing problem sooner.=0A= =0A= In any case, the proxy to proxy case is not explicitly listed in the=20=0A= requirements anywhere.=0A= =0A= thanks,=0A= -rohan=0A= =0A= =0A= =0A= On Feb 24, 2006, at 21:47, Cullen Jennings wrote:=0A= > On 2/24/06 1:47 PM, "Dean Willis" wrote:=0A= >=0A= >>=0A= >> On Feb 24, 2006, at 12:54 PM, Cullen Jennings wrote:=0A= >>=0A= >>> On 2/23/06 1:16 PM, "Dean Willis" wrote:=0A= >>>=0A= >>>> I think you guys are missing Gary's use case.=0A= >>>>=0A= >>>> He's postulating an entirely different NAT problem, where the NAT=0A= >>>> is between=0A= >>>> the outbound proxy and the real world, rather than between the UA=0A= >>>> and its=0A= >>>> outbound proxy.=0A= >>>>=0A= >>>> This just isn't a use case that's been in scope for general=0A= >>>> discussion so far.=0A= >>>=0A= >>> If I understand correctly ... I thin I added this use case to the=0A= >>> document=0A= >>> awhile back because some people request it. For some vague reason,=0A= >>> I thought=0A= >>> Dean was one of the people that had requested it. People had=0A= >>> brought up=0A= >>> system like the ingate stuff. If the use case complicated stuff, I=0A= >>> would=0A= >>> remove it but so far the baseline the simple case has pretty much=0A= >>> solved=0A= >>> this one too.=0A= >>=0A= >> Yep, I motivated the use case at one point.=0A= >>=0A= >> However, what you have in 3.4 isn't quite what what Gary seemed to be=0A= >> looking at, in that:=0A= >>=0A= >> 1) 3.4 shows another NAT between the UA and the EP. This doesn't make=0A= >> the use case of 3.4 weaker, but might lead people to think that it is=0A= >> a different problem, when this aspect is really a more-general=0A= >> variant of Gary's case.=0A= >>=0A= >> 2) 3.4 does not seem show the use of "classic STUN" to discover the=0A= >> effective IP address for RTP, along a path disparate from the coaxial=0A= >> STUN used as a NAT keepalive. This is implied in the text, and is=0A= >> obvious from STUN itself, but might not be obvious to somebody who=0A= >> hasn't been thinking about this for a long time.=0A= >>=0A= >> 3) The use of coaxial STUN between the EP and the registrar, though=0A= >> implied in 3.4, also doesn't seem obvious in the text. Nor is the=0A= >> requirement for "back pressure" from the EP to the UA, should the EP-=0A= >> Registrar coaxial STUN indicate a reset of the NAT between those=0A= >> nodes. If this happens, I think that EP needs to induce a "keepalive=0A= >> failure" on its own channel back to UA. You talk about UAs detecting=0A= >> flow failure, but not about proxies detecting flow failure. Maybe it=0A= >> is in there and I just missed it . . .=0A= >>=0A= >> --=0A= >> Dean=0A= >>=0A= >=0A= > Yep - I see what you are saying. I will try and clarify the draft a=20=0A= > bit.=0A= =0A= =0A= _______________________________________________=0A= Sip mailing list https://www1.ietf.org/mailman/listinfo/sip=0A= This list is for NEW development of the core SIP Protocol=0A= Use sip-implementors@cs.columbia.edu for questions on current sip=0A= Use sipping@ietf.org for new developments on the application of sip=0A= =0A= =0A= --=20=0A= =0A= =0A= =0A= -----------------------------------------------=0D=0A= =0D=0A= This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. =0D=0A= =0D=0A= Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp= .=20=0A= ------_=_NextPart_001_01C63B3C.0E90CB72 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =0A= =0A= =0A= =0A= = =0A= RE: [Sip] Outbound and STUN Keep Alive=0A= =0A= =0A= =0A=
=0A= =0A=

I am not sure why it is a harder problem. It is a questio= n of actions that happen between peer agents, in this case one agent just h= appens to be a proxy, and in the other case both agents are proxies. I can = see why it was not in the original scope of requirements, but now that it's= been alerted it gives me pause that there is resistence in putting it in. = Proxies should be able to go anywhere in the same way that agents should be= able to go anywhere.
=0A=
=0A= Do people really consider proxies something so special that they deserve sp= ecial treatment, and are things SIP-wise separate from user agents? If so t= hen SIP has changed from what it used to be and is losing its simple distri= buted nature and becoming something that seems increasingly monolithic.
= =0A=
=0A= Regards
=0A=
=0A= M
=0A=
=0A=
=0A= -----Original Message-----
=0A= From: Rohan Mahy [mailto:rohan@ekabal.c= om]
=0A= Sent: Sun 26/02/2006 6:13 PM
=0A= To: Cullen Jennings
=0A= Cc: sip@ietf.org; Dean Willis
=0A= Subject: Re: [Sip] Outbound and STUN Keep Alive
=0A=
=0A= Hi,
=0A=
=0A= If my recollection is correct, I think we decided that use cases of
=0A= NATs between proxies is out of scope of *this* document and that we can
= =0A= work on the (probably harder) proxy to proxy problem in *another*
=0A= document so we can solve the more pressing problem sooner.
=0A=
=0A= In any case, the proxy to proxy case is not explicitly listed in the
=0A= requirements anywhere.
=0A=
=0A= thanks,
=0A= -rohan
=0A=
=0A=
=0A=
=0A= On Feb 24, 2006, at 21:47, Cullen Jennings wrote:
=0A= > On 2/24/06 1:47 PM, "Dean Willis" <dean.willis@softarmor.= com> wrote:
=0A= >
=0A= >>
=0A= >> On Feb 24, 2006, at 12:54 PM, Cullen Jennings wrote:
=0A= >>
=0A= >>> On 2/23/06 1:16 PM, "Dean Willis" <dean.willis@so= ftarmor.com> wrote:
=0A= >>>
=0A= >>>> I think you guys are missing Gary's use case.
=0A= >>>>
=0A= >>>> He's postulating an entirely different NAT problem, where = the NAT
=0A= >>>> is between
=0A= >>>> the outbound proxy and the real world, rather than between= the UA
=0A= >>>> and its
=0A= >>>> outbound proxy.
=0A= >>>>
=0A= >>>> This just isn't a use case that's been in scope for genera= l
=0A= >>>> discussion so far.
=0A= >>>
=0A= >>> If I understand correctly ... I thin I added this use case to = the
=0A= >>> document
=0A= >>> awhile back because some people request it. For some vague rea= son,
=0A= >>> I thought
=0A= >>> Dean was one of the people that had requested it. People had=0A= >>> brought up
=0A= >>> system like the ingate stuff. If the use case complicated stuf= f, I
=0A= >>> would
=0A= >>> remove it but so far the baseline the simple case has pretty m= uch
=0A= >>> solved
=0A= >>> this one too.
=0A= >>
=0A= >> Yep, I motivated the use case at one point.
=0A= >>
=0A= >> However, what you have in 3.4 isn't quite what what Gary seemed to= be
=0A= >> looking at, in that:
=0A= >>
=0A= >> 1) 3.4 shows another NAT between the UA and the EP. This doesn't m= ake
=0A= >> the use case of 3.4 weaker, but might lead people to think that it= is
=0A= >> a different problem, when this aspect is really a more-general
= =0A= >> variant of Gary's case.
=0A= >>
=0A= >> 2) 3.4 does not seem show the use of "classic STUN" to d= iscover the
=0A= >> effective IP address for RTP, along a path disparate from the coax= ial
=0A= >> STUN used as a NAT keepalive. This is implied in the text, and is<= BR>=0A= >> obvious from STUN itself, but might not be obvious to somebody who=
=0A= >> hasn't been thinking about this for a long time.
=0A= >>
=0A= >> 3) The use of coaxial STUN between the EP and the registrar, thoug= h
=0A= >> implied in 3.4, also doesn't seem obvious in the text. Nor is the<= BR>=0A= >> requirement for "back pressure" from the EP to the UA, s= hould the EP-
=0A= >> Registrar coaxial STUN indicate a reset of the NAT between those=0A= >> nodes. If this happens, I think that EP needs to induce a "ke= epalive
=0A= >> failure" on its own channel back to UA. You talk about UAs de= tecting
=0A= >> flow failure, but not about proxies detecting flow failure. Maybe = it
=0A= >> is in there and I just missed it . . .
=0A= >>
=0A= >> --
=0A= >> Dean
=0A= >>
=0A= >
=0A= > Yep - I see what you are saying. I will try and clarify the draft a
= =0A= > bit.
=0A=
=0A=
=0A= _______________________________________________
=0A= Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
=0A= This list is for NEW development of the core SIP Protocol
=0A= Use sip-implementors@cs.columbia.edu for questions on current sip
=0A= Use sipping@ietf.org for new developments on the application of sip
=0A=
=0A=
=0A= --
=0A=
=0A=
=0A= =0A=

=0A= =0A=
=0D=0A=

=0D=0A= This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful.

=0D=0A= =0D=0A=

Any views, opinions and content presented in this e-mail are solely thos= e of the author and may not represent those of Objectworld Communications C= orp.

=0D=0A= =0A= =0A= = ------_=_NextPart_001_01C63B3C.0E90CB72-- --===============0904254957== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0904254957==-- From sip-bounces@ietf.org Sun Feb 26 20:50:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDXV5-0005Wv-Pu; Sun, 26 Feb 2006 20:48:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDXV4-0005Wq-0X for sip@ietf.org; Sun, 26 Feb 2006 20:48:34 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDXV3-00067Z-F7 for sip@ietf.org; Sun, 26 Feb 2006 20:48:33 -0500 Received: from [131.161.248.91] (open-131-161-248-91.cliq.com [131.161.248.91]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k1R1mPF10086; Sun, 26 Feb 2006 17:48:25 -0800 In-Reply-To: <4E2DC1ACE541B94A946B8D8657E372C51609E1@photon.objectworld.com> References: <4d8ab737eca9374ed60fb959e29ec1ed@ekabal.com> <4E2DC1ACE541B94A946B8D8657E372C51609E1@photon.objectworld.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Rohan Mahy Subject: Re: [Sip] Outbound and STUN Keep Alive Date: Sun, 26 Feb 2006 17:48:03 -0800 To: "Michael Slavitch" X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: Cullen Jennings , sip@ietf.org, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Michael, First of all, proxies don't register. The way outbound works now, new=20 requests toward the UA go over an existing connection because of=20 information provided during registration. A mechanism for proxy-proxy=20= outbound only connections is likely to require an unrelated mechanism. Second, there are already rules in RFC 3261 and RFC 3263 for how to=20 route from one proxy to the next. These rules assume that a proxy=20 server is accessible. This is not an especially radical concept. HTTP=20= assumes that HTTP servers are accessible and this did not turn out to=20 be a huge barrier for most web sites. Third, if a UA is sending traffic through a proxy, then a NAT, then a=20 proxy, I ask why the UA bothered to send its SIP traffic through the=20 first proxy instead of directly to the publicly accessible proxy? What=20= service is being provided? Recall that it is perfectly appropriate for=20= a UA to be registered with multiple AORs in different domains. In the=20= case of a collocated proxy/NAT/FW, the purpose of sending through the=20 first proxy is supposed to be NAT and firewall traversal. The very=20 purpose of outbound is to provide a mechanism for UAs so they do not=20 require the help of such a NAT/FW. Finally, the *title* of the draft says "User Agent initiated=20 connections". While I can still see valid use cases for proxy to proxy outbound=20 connections, it seems clear to me that such a mechanism will a) be a=20 different mechanism, b) require non-trivial changes to languages in the=20= core spec, and c) need better use cases and requirements. Hope this helps. thanks, -rohan On Feb 26, 2006, at 17:20, Michael Slavitch wrote: > > I am not sure why it is a harder problem. It is a question of actions=20= > that happen between peer agents, in this case one agent just happens=20= > to be a proxy, and in the other case both agents are proxies. I can=20 > see why it was not in the original scope of requirements, but now that=20= > it's been alerted it gives me pause that there is resistence in=20 > putting it in. Proxies should be able to go anywhere in the same way=20= > that agents should be able to go anywhere. > > Do people really consider proxies something so special that they=20 > deserve special treatment, and are things SIP-wise separate from user=20= > agents? If so then SIP has changed from what it used to be and is=20 > losing its simple distributed nature and becoming something that seems=20= > increasingly monolithic. > > Regards > > M > > > -----Original Message----- > From: Rohan Mahy [mailto:rohan@ekabal.com] > Sent: Sun 26/02/2006 6:13 PM > To: Cullen Jennings > Cc: sip@ietf.org; Dean Willis > Subject: Re: [Sip] Outbound and STUN Keep Alive > > Hi, > > If my recollection is correct, I think we decided that use cases of > NATs between proxies is out of scope of *this* document and that we=20= > can > work on the (probably harder) proxy to proxy problem in *another* > document so we can solve the more pressing problem sooner. > > In any case, the proxy to proxy case is not explicitly listed in the > requirements anywhere. > > thanks, > -rohan > > > > On Feb 24, 2006, at 21:47, Cullen Jennings wrote: > > On 2/24/06 1:47 PM, "Dean Willis" = wrote: > > > >> > >> On Feb 24, 2006, at 12:54 PM, Cullen Jennings wrote: > >> > >>> On 2/23/06 1:16 PM, "Dean Willis" =20 > wrote: > >>> > >>>> I think you guys are missing Gary's use case. > >>>> > >>>> He's postulating an entirely different NAT problem, where the = NAT > >>>> is between > >>>> the outbound proxy and the real world, rather than between the = UA > >>>> and its > >>>> outbound proxy. > >>>> > >>>> This just isn't a use case that's been in scope for general > >>>> discussion so far. > >>> > >>> If I understand correctly ... I thin I added this use case to the > >>> document > >>> awhile back because some people request it. For some vague = reason, > >>> I thought > >>> Dean was one of the people that had requested it. People had > >>> brought up > >>> system like the ingate stuff. If the use case complicated stuff, = I > >>> would > >>> remove it but so far the baseline the simple case has pretty much > >>> solved > >>> this one too. > >> > >> Yep, I motivated the use case at one point. > >> > >> However, what you have in 3.4 isn't quite what what Gary seemed to=20= > be > >> looking at, in that: > >> > >> 1) 3.4 shows another NAT between the UA and the EP. This doesn't=20= > make > >> the use case of 3.4 weaker, but might lead people to think that it=20= > is > >> a different problem, when this aspect is really a more-general > >> variant of Gary's case. > >> > >> 2) 3.4 does not seem show the use of "classic STUN" to discover = the > >> effective IP address for RTP, along a path disparate from the=20 > coaxial > >> STUN used as a NAT keepalive. This is implied in the text, and is > >> obvious from STUN itself, but might not be obvious to somebody who > >> hasn't been thinking about this for a long time. > >> > >> 3) The use of coaxial STUN between the EP and the registrar, = though > >> implied in 3.4, also doesn't seem obvious in the text. Nor is the > >> requirement for "back pressure" from the EP to the UA, should the=20= > EP- > >> Registrar coaxial STUN indicate a reset of the NAT between those > >> nodes. If this happens, I think that EP needs to induce a=20 > "keepalive > >> failure" on its own channel back to UA. You talk about UAs=20 > detecting > >> flow failure, but not about proxies detecting flow failure. Maybe=20= > it > >> is in there and I just missed it . . . > >> > >> -- > >> Dean > >> > > > > Yep - I see what you are saying. I will try and clarify the draft a > > bit. > > > _______________________________________________ > Sip mailing list=A0 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 transmission (including any attachments) may contain confidential=20= > information, privileged material (including material protected by the=20= > solicitor-client or other applicable privileges), or constitute=20 > non-public information. Any use of this information by anyone other=20 > than the intended recipient is prohibited. If you have received this=20= > transmission in error, please immediately reply to the sender and=20 > delete this information from your system. Use, dissemination,=20 > distribution, or reproduction of this transmission by unintended=20 > recipients is not authorized and may be unlawful. > > Any views, opinions and content presented in this e-mail are solely=20 > those of the author and may not represent those of Objectworld=20 > Communications Corp. > =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 sip-bounces@ietf.org Sun Feb 26 21:16:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDXuY-0007Ax-I4; Sun, 26 Feb 2006 21:14:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDXuW-0007Ai-5k; Sun, 26 Feb 2006 21:14:52 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDXuV-0006nD-GY; Sun, 26 Feb 2006 21:14:52 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 26 Feb 2006 18:14:51 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1R2EoVb009381; Sun, 26 Feb 2006 18:14:50 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 26 Feb 2006 18:14:50 -0800 Received: from jmpolk-wxp.cisco.com ([10.89.16.142]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 26 Feb 2006 18:14:49 -0800 Message-Id: <4.3.2.7.2.20060226195704.03416ad8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 26 Feb 2006 20:14:48 -0600 To: Rohan Mahy , Dean Willis From: "James M. Polk" Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of Dividing and Conquering In-Reply-To: References: <231F5685-CCC1-41B1-997E-74AF67D9EBCE@softarmor.com> <231F5685-CCC1-41B1-997E-74AF67D9EBCE@softarmor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Feb 2006 02:14:49.0911 (UTC) FILETIME=[966B7470:01C63B43] X-Spam-Score: 0.0 (/) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 Cc: Cullen Jennings , "sip@ietf.org List" , Sipping List , Jon Peterson , Allison Mankin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hey While I was the first to comment on Dean's proposal not involving enough groups, and the potential for deviding again, I can see the flip side of this problem being if SIP does exactly what you suggest here: limited work to 4 or 5 items. The consequences of that action (or inaction) would be to have *more* SDOs defining extensions to SIP than is already going on. Many people have valid new ideas that are shut/stalled out because it takes so long to get any document done under the best of circumstances. Venture into this scenario: Rohan writes a new ID that has zero resistance Does it become a WG item in the first meeting? yeah - in SIPPING that's 6 months of time with zero resistance In the next meeting it may be moved to SIP for "protocol" work to be done 3 more months, with zero resistance How long does it take the WG to review the ID? No one can tell me reaslistically this happens overnight because everyone has queued the right amount of time to this effort. so it sits 3 more months Is this sip-00 version ready for WGLC? maybe, maybe not Maybe there is one thing that needs to be adjusted 3 more months until the next meeting At the next meeting, *maybe* this ID is ready for WGLC 2 more weeks if this is PS track 2 more weeks for IETF LC it gets to IESG, does it pass the first time? If not, that's 2 more weeks If so, it's 5 months with the RFC-Editor This adds up to roughly 20 months to get one idea through with unrealistically minimal resistance to the idea. I think this WG has more time on its hands to do more work than 4-5 items. If it takes 4 WGs to have faster milestones on the smaller IDs, I think that alone is a great idea. I look forward to a live discussion on this, if it is brought up. What I'm thinking is happening is more and more SDOs are getting tired of the IETF taking so long to get docs out. At some point they will consider the SIP WG irrelevant and do their own thing. Do we want that? If giving some of the tasks to other WG chairs to relieve you two (Dean and Rohan) to get more work done, even if the same number of core folks sit in each meeting, then I think it is better to get more work done with a series of WGs having more milestones to meet because there are more chairs cracking the whip on authors to get IDs revved and/or reviewed. At 04:06 PM 2/26/2006 -0800, Rohan Mahy wrote: >Hi, > >I don't think further splitting is going to solve our problems due to the >complexity of lateral communication required among groups with this much >in common. > >I do think that a working group that describes use cases for the RAI area >in general could produce some very useful output that has been out of >scope of individual working groups. The SIP NAT scenarios document would >be a good candidate to move into such a WG. > >I think mostly we have a problem saying no. We have too much work to do >and the only effective way for this community to get better throughput is >to focus religiously on a much smaller handful of work items (ex: 4 or 5) >at a time. I am as guilty as the next person for adding new milestones >(actually, more guilty as a chair), but it is hard to say no to new work >when old work that is "almost done" takes so long to finish. > >Perhaps we can have a discussion of this in the RAI area open meeting at >Dallas. It would be nice to hear the new ADs jump in here with their >thoughts. Also, Allison has been wrangling this monster longer than >anyone except Dean, so I am curious what she has to say. > >thanks, >-rohan > > >On Feb 23, 2006, at 16:30, Dean Willis wrote: >>I've been working on SIP and SIPPING and P2P-SIP agendas this week, and >>that started me thinking. >> >>We spun up SIPPING to take some of the load off of SIP, and in doing so >>tried to more narrowly-define the charters of both SIP and SIPPING >>relative to the previous SIP charter. >> >>When we started talking about P2P-SIP, we thought about bringing in the >>topic as part of SIPPING, but fairly quickly rejected that idea because >>it was clearly partitionable. >> >>This started me thinking -- could we further apply this principle of >>partitioning? >> >>Both SIP and SIPPING have grown into multi-year monsters, each with large >>charters and the need for multiple long-sessions at each IETF. They're >>tricky to chair, require lots of secretarial work, and are chronically >>late on deliverables (in large part because the chairs are acting like >>ADs instead of chairs). SPPING, once viewed as the kidney of SIP, now >>needs its own dialysis. >> >>Perhaps if we were to split these two working groups into three or four >>working groups that have much more clearly defined missions and scopes, >>we could cut them down to one meeting slot each. And if we were to have >>separate management (chairs and secretaries) for each working group, we >>could better manage the groups to timely delivery. >> >>So I'd like to toss out some ideas on how we might subdivide, and see how >>you folks feel about this. I think the key to any success here would be >>in scope management. >> >>What if we had the following groups: >> >>1) SIPEM -- SIP Extended Maintenance >> >>2) SIPNEW -- New major functionality for SIP >> >>3) SIPREQ -- Analysis of requirements raised by new applications or SDO >>liaison >> >>4) SIPUSE -- Using SIP to meet specific application requirements >> >> >> >>Here's how we might divide the work: >> >> >>SIPEM >>----- >> >>Scope: Maintenance of SIP 2.0 and development (as per RFC 3427) of >>backward-compatible extensions driven by applications with near-term >>deployment scenarios. >> >>Initial Milestone Tasks of SIPEM: >> >>1) Developing a SIP Guidebook, roughly the equivalent of the TCP >>Roadmap, that defines what's "in" SIP and how the pieces fit together. >> >>2) GRUU >> >>3) Outbound >> >>4) Target-Dialog >> >>5) Certificate Usage >> >>6) Location Transport >> >>7) Loop Error Correction >> >>8) Connected Party Identity >> >>9) Hop Limit Diagnostics >> >>10) TLS Usage >> >>11) Answering Modes >> >>12) Connection Reuse >> >>13) Rejection of Anonymous Requests >> >>14) Consent Mechanism >> >> >> >>SIPNEW >>------ >> >>Scope: Enhancement and evolution of SIP including architectural-level >>requirements and (as per RFC 3427) extensions without requirements for >>backward compatibility. >> >> >>Initial milestone tasks of SIPNEW >> >>1) Developing a "future roadmap" for the evolution of SIP >> >>2) Solving the RFC 3261 Routing Problem >> >>3) Use of SAML with SIP >> >>4) Response Identity >> >>5) Response Authentication >> >>6) End to Middle Requests >> >> >> >>SIPREQ >>------ >> >>Scope: Analysis of requirements raised by new applications of SIP in IETF >>or in external SDOs (as per RFC 3427). Development of requirements for >>changes to SIP or for usage guides in response to applications >>requirements. Another way of wording this would be "problem definition". >> >>Initial milestones and tasks of SIPREQ: >> >>1) Session Policy Requirements >> >> >> >>SIPUSE >>------ >> >>Scope: Guidance on how to use existing SIP specifications and mechanisms >>including examples, call flows, test cases, error avoidance, and so on. >>Review (as per RFC 3427) of SIP Event Packages. >> >> >>Initial milestones and tasks for SIPUSE: >> >>1) Service Examples >> >>2) Security Examples >> >>3) Race Condition Examples >> >>4) Session media policy mechanism >> >>5) Session policy package mechanism >> >>6) Service quality reporting mechanism >> >>7) URI List mechanism >> >>8) Subscriptions to Ad-Hoc Resource Lists mechanism >> >>9) Multiple REFER mechanism >> >>10) Ad-Hoc Conferencing using URI lists mechanism >> >>11) Call Control Transfer mechanism >> >>12) Configuration Delivery mechanism >> >>13) Emergency Calling using SIP (SOS) mechanism >> >> >> >> >>Note that I'm not entirely happy with the division of SIPPING into SIPUSE >>and SIPREQ. While it seems like we spend a lot of time in SIPPING >>debating requirements, there are currently a lot of deliverables in this >>category. >> >> >>-- >>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 > > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core 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 sip-bounces@ietf.org Sun Feb 26 22:04:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDYfA-0004vy-Ab; Sun, 26 Feb 2006 22:03:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDYf9-0004vq-0W; Sun, 26 Feb 2006 22:03:03 -0500 Received: from mail126.messagelabs.com ([216.82.250.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FDYf8-00084f-Bw; Sun, 26 Feb 2006 22:03:02 -0500 X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-15.tower-126.messagelabs.com!1141009365!9654123!5 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 11302 invoked from network); 27 Feb 2006 03:02:59 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-15.tower-126.messagelabs.com with SMTP; 27 Feb 2006 03:02:59 -0000 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.13) by attrh3i.attrh.att.com (7.2.052) id 4401E00700003712; Sun, 26 Feb 2006 22:02:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] Re: [Sip] Thoughts on the Principle of Dividingand Conquering Date: Sun, 26 Feb 2006 21:02:55 -0600 Message-ID: <28F05913385EAC43AF019413F674A0170DE0C2DF@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <4.3.2.7.2.20060226195704.03416ad8@email.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Re: [Sip] Thoughts on the Principle of Dividingand Conquering Thread-Index: AcY7Q6mOhR2LvnfAR2GcDpXGmRTTDQABZDVQ From: "Dolly, Martin C, ALABS" To: "James M. Polk" , "Rohan Mahy" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: e3901bdd61b234d82da85cc76f05a7e8 Cc: Cullen Jennings , sip@ietf.org, Sipping List , Jon Peterson , Allison Mankin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hello, I do not see where further splitting work into new WGs..etc. solves any problem. I believe that "strong" chairing, and a true "democratic" process, where not only the voices of the few are heard, will result in faster results. Cheers, Martin > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Sunday, February 26, 2006 9:15 PM > To: Rohan Mahy; Dean Willis > Cc: Cullen Jennings; sip@ietf.org List; Sipping List; Jon Peterson; > Allison Mankin > Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of > Dividingand Conquering >=20 >=20 > Hey >=20 > While I was the first to comment on Dean's proposal not=20 > involving enough=20 > groups, and the potential for deviding again, I can see the=20 > flip side of=20 > this problem being if SIP does exactly what you suggest here:=20 > limited work=20 > to 4 or 5 items. >=20 > The consequences of that action (or inaction) would be to=20 > have *more* SDOs=20 > defining extensions to SIP than is already going on. Many=20 > people have=20 > valid new ideas that are shut/stalled out because it takes so=20 > long to get=20 > any document done under the best of circumstances. >=20 > Venture into this scenario: >=20 > Rohan writes a new ID that has zero resistance >=20 > Does it become a WG item in the first meeting? >=20 > yeah - in SIPPING >=20 > that's 6 months of time with zero resistance >=20 > In the next meeting it may be moved to SIP for "protocol"=20 > work to be done >=20 > 3 more months, with zero resistance >=20 > How long does it take the WG to review the ID? >=20 > No one can tell me reaslistically this happens overnight=20 > because everyone=20 > has queued the right amount of time to this effort. >=20 > so it sits 3 more months >=20 > Is this sip-00 version ready for WGLC? >=20 > maybe, maybe not >=20 > Maybe there is one thing that needs to be adjusted >=20 > 3 more months until the next meeting >=20 > At the next meeting, *maybe* this ID is ready for WGLC >=20 > 2 more weeks >=20 > if this is PS track >=20 > 2 more weeks for IETF LC >=20 > it gets to IESG, does it pass the first time? >=20 > If not, that's 2 more weeks >=20 > If so, it's 5 months with the RFC-Editor >=20 > This adds up to roughly 20 months to get one idea through with=20 > unrealistically minimal resistance to the idea. >=20 > I think this WG has more time on its hands to do more work=20 > than 4-5 items. >=20 > If it takes 4 WGs to have faster milestones on the smaller=20 > IDs, I think=20 > that alone is a great idea. >=20 > I look forward to a live discussion on this, if it is brought up. >=20 > What I'm thinking is happening is more and more SDOs are=20 > getting tired of=20 > the IETF taking so long to get docs out. At some point they=20 > will consider=20 > the SIP WG irrelevant and do their own thing. >=20 > Do we want that? >=20 > If giving some of the tasks to other WG chairs to relieve you=20 > two (Dean and=20 > Rohan) to get more work done, even if the same number of core=20 > folks sit in=20 > each meeting, then I think it is better to get more work done=20 > with a series=20 > of WGs having more milestones to meet because there are more chairs=20 > cracking the whip on authors to get IDs revved and/or reviewed. >=20 > >=20 > At 04:06 PM 2/26/2006 -0800, Rohan Mahy wrote: > >Hi, > > > >I don't think further splitting is going to solve our=20 > problems due to the=20 > >complexity of lateral communication required among groups=20 > with this much=20 > >in common. > > > >I do think that a working group that describes use cases for=20 > the RAI area=20 > >in general could produce some very useful output that has=20 > been out of=20 > >scope of individual working groups. The SIP NAT scenarios=20 > document would=20 > >be a good candidate to move into such a WG. > > > >I think mostly we have a problem saying no. We have too=20 > much work to do=20 > >and the only effective way for this community to get better=20 > throughput is=20 > >to focus religiously on a much smaller handful of work items=20 > (ex: 4 or 5)=20 > >at a time. I am as guilty as the next person for adding new=20 > milestones=20 > >(actually, more guilty as a chair), but it is hard to say no=20 > to new work=20 > >when old work that is "almost done" takes so long to finish. > > > >Perhaps we can have a discussion of this in the RAI area=20 > open meeting at=20 > >Dallas. It would be nice to hear the new ADs jump in here=20 > with their=20 > >thoughts. Also, Allison has been wrangling this monster longer than=20 > >anyone except Dean, so I am curious what she has to say. > > > >thanks, > >-rohan > > > > > >On Feb 23, 2006, at 16:30, Dean Willis wrote: > >>I've been working on SIP and SIPPING and P2P-SIP agendas=20 > this week, and=20 > >>that started me thinking. > >> > >>We spun up SIPPING to take some of the load off of SIP, and=20 > in doing so=20 > >>tried to more narrowly-define the charters of both SIP and SIPPING=20 > >>relative to the previous SIP charter. > >> > >>When we started talking about P2P-SIP, we thought about=20 > bringing in the=20 > >>topic as part of SIPPING, but fairly quickly rejected that=20 > idea because=20 > >>it was clearly partitionable. > >> > >>This started me thinking -- could we further apply this=20 > principle of=20 > >>partitioning? > >> > >>Both SIP and SIPPING have grown into multi-year monsters,=20 > each with large=20 > >>charters and the need for multiple long-sessions at each=20 > IETF. They're=20 > >>tricky to chair, require lots of secretarial work, and are=20 > chronically=20 > >>late on deliverables (in large part because the chairs are=20 > acting like=20 > >>ADs instead of chairs). SPPING, once viewed as the kidney=20 > of SIP, now=20 > >>needs its own dialysis. > >> > >>Perhaps if we were to split these two working groups into=20 > three or four=20 > >>working groups that have much more clearly defined missions=20 > and scopes,=20 > >>we could cut them down to one meeting slot each. And if we=20 > were to have=20 > >>separate management (chairs and secretaries) for each=20 > working group, we=20 > >>could better manage the groups to timely delivery. > >> > >>So I'd like to toss out some ideas on how we might=20 > subdivide, and see how=20 > >>you folks feel about this. I think the key to any success=20 > here would be=20 > >>in scope management. > >> > >>What if we had the following groups: > >> > >>1) SIPEM -- SIP Extended Maintenance > >> > >>2) SIPNEW -- New major functionality for SIP > >> > >>3) SIPREQ -- Analysis of requirements raised by new=20 > applications or SDO=20 > >>liaison > >> > >>4) SIPUSE -- Using SIP to meet specific application requirements > >> > >> > >> > >>Here's how we might divide the work: > >> > >> > >>SIPEM > >>----- > >> > >>Scope: Maintenance of SIP 2.0 and development (as per RFC 3427) of=20 > >>backward-compatible extensions driven by applications with=20 > near-term=20 > >>deployment scenarios. > >> > >>Initial Milestone Tasks of SIPEM: > >> > >>1) Developing a SIP Guidebook, roughly the equivalent of the TCP=20 > >>Roadmap, that defines what's "in" SIP and how the pieces=20 > fit together. > >> > >>2) GRUU > >> > >>3) Outbound > >> > >>4) Target-Dialog > >> > >>5) Certificate Usage > >> > >>6) Location Transport > >> > >>7) Loop Error Correction > >> > >>8) Connected Party Identity > >> > >>9) Hop Limit Diagnostics > >> > >>10) TLS Usage > >> > >>11) Answering Modes > >> > >>12) Connection Reuse > >> > >>13) Rejection of Anonymous Requests > >> > >>14) Consent Mechanism > >> > >> > >> > >>SIPNEW > >>------ > >> > >>Scope: Enhancement and evolution of SIP including=20 > architectural-level=20 > >>requirements and (as per RFC 3427) extensions without=20 > requirements for=20 > >>backward compatibility. > >> > >> > >>Initial milestone tasks of SIPNEW > >> > >>1) Developing a "future roadmap" for the evolution of SIP > >> > >>2) Solving the RFC 3261 Routing Problem > >> > >>3) Use of SAML with SIP > >> > >>4) Response Identity > >> > >>5) Response Authentication > >> > >>6) End to Middle Requests > >> > >> > >> > >>SIPREQ > >>------ > >> > >>Scope: Analysis of requirements raised by new applications=20 > of SIP in IETF=20 > >>or in external SDOs (as per RFC 3427). Development of=20 > requirements for=20 > >>changes to SIP or for usage guides in response to applications=20 > >>requirements. Another way of wording this would be "problem=20 > definition". > >> > >>Initial milestones and tasks of SIPREQ: > >> > >>1) Session Policy Requirements > >> > >> > >> > >>SIPUSE > >>------ > >> > >>Scope: Guidance on how to use existing SIP specifications=20 > and mechanisms=20 > >>including examples, call flows, test cases, error=20 > avoidance, and so on.=20 > >>Review (as per RFC 3427) of SIP Event Packages. > >> > >> > >>Initial milestones and tasks for SIPUSE: > >> > >>1) Service Examples > >> > >>2) Security Examples > >> > >>3) Race Condition Examples > >> > >>4) Session media policy mechanism > >> > >>5) Session policy package mechanism > >> > >>6) Service quality reporting mechanism > >> > >>7) URI List mechanism > >> > >>8) Subscriptions to Ad-Hoc Resource Lists mechanism > >> > >>9) Multiple REFER mechanism > >> > >>10) Ad-Hoc Conferencing using URI lists mechanism > >> > >>11) Call Control Transfer mechanism > >> > >>12) Configuration Delivery mechanism > >> > >>13) Emergency Calling using SIP (SOS) mechanism > >> > >> > >> > >> > >>Note that I'm not entirely happy with the division of=20 > SIPPING into SIPUSE=20 > >>and SIPREQ. While it seems like we spend a lot of time in SIPPING=20 > >>debating requirements, there are currently a lot of=20 > deliverables in this=20 > >>category. > >> > >> > >>-- > >>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 > > > > > >_______________________________________________ > >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > >This list is for NEW development of the application of SIP > >Use sip-implementors@cs.columbia.edu for questions on current sip > >Use sip@ietf.org for new developments of core SIP >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core 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 sip-bounces@ietf.org Sun Feb 26 22:22:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDYwM-00052e-QY; Sun, 26 Feb 2006 22:20:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDYwL-00052Q-KS for sip@ietf.org; Sun, 26 Feb 2006 22:20:49 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDYwI-00008b-Ru for sip@ietf.org; Sun, 26 Feb 2006 22:20:49 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 26 Feb 2006 19:20:48 -0800 X-IronPort-AV: i="4.02,149,1139212800"; d="scan'208,217"; a="1779863011:sNHT54621768" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k1R3KkXf021855; Sun, 26 Feb 2006 19:20:46 -0800 (PST) Received: from 171.68.225.134 ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Mon, 27 Feb 2006 03:20:45 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sun, 26 Feb 2006 19:20:44 -0800 Subject: Re: [Sip] Outbound and STUN Keep Alive From: Cullen Jennings To: Michael Slavitch , Rohan Mahy Message-ID: Thread-Topic: [Sip] Outbound and STUN Keep Alive Thread-Index: AcY7KpguGLAmPCvoR3KU0rDNoVIhugAD/F0KAASQZu8= In-Reply-To: <4E2DC1ACE541B94A946B8D8657E372C51609E1@photon.objectworld.com> Mime-version: 1.0 X-Spam-Score: 2.1 (++) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 Cc: "sip@ietf.org" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0780502308==" Errors-To: sip-bounces@ietf.org > 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. --===============0780502308== Content-type: multipart/alternative; boundary="B_3223826444_7636451" > 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_3223826444_7636451 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I think the hard part is that when the inner proxy detects the NAT between the inter and out proxy has rebooted, it needs a way to tell all the UA to re-register. It's not that I don't want to solve this, is just that I think the solution to this can be solved separately from the minimal stuff that needs to be outbound. On 2/26/06 5:20 PM, "Michael Slavitch" wrote: > > > I am not sure why it is a harder problem. It is a question of actions that > happen between peer agents, in this case one agent just happens to be a proxy, > and in the other case both agents are proxies. I can see why it was not in the > original scope of requirements, but now that it's been alerted it gives me > pause that there is resistence in putting it in. Proxies should be able to go > anywhere in the same way that agents should be able to go anywhere. > > Do people really consider proxies something so special that they deserve > special treatment, and are things SIP-wise separate from user agents? If so > then SIP has changed from what it used to be and is losing its simple > distributed nature and becoming something that seems increasingly monolithic. > > Regards > > M > > > -----Original Message----- > From: Rohan Mahy [mailto:rohan@ekabal.com] > Sent: Sun 26/02/2006 6:13 PM > To: Cullen Jennings > Cc: sip@ietf.org; Dean Willis > Subject: Re: [Sip] Outbound and STUN Keep Alive > > Hi, > > If my recollection is correct, I think we decided that use cases of > NATs between proxies is out of scope of *this* document and that we can > work on the (probably harder) proxy to proxy problem in *another* > document so we can solve the more pressing problem sooner. > > In any case, the proxy to proxy case is not explicitly listed in the > requirements anywhere. > > thanks, > -rohan > > > > On Feb 24, 2006, at 21:47, Cullen Jennings wrote: >> > On 2/24/06 1:47 PM, "Dean Willis" wrote: >> > >>> >> >>> >> On Feb 24, 2006, at 12:54 PM, Cullen Jennings wrote: >>> >> >>>> >>> On 2/23/06 1:16 PM, "Dean Willis" wrote: >>>> >>> >>>>> >>>> I think you guys are missing Gary's use case. >>>>> >>>> >>>>> >>>> He's postulating an entirely different NAT problem, where the NAT >>>>> >>>> is between >>>>> >>>> the outbound proxy and the real world, rather than between the UA >>>>> >>>> and its >>>>> >>>> outbound proxy. >>>>> >>>> >>>>> >>>> This just isn't a use case that's been in scope for general >>>>> >>>> discussion so far. >>>> >>> >>>> >>> If I understand correctly ... I thin I added this use case to the >>>> >>> document >>>> >>> awhile back because some people request it. For some vague reason, >>>> >>> I thought >>>> >>> Dean was one of the people that had requested it. People had >>>> >>> brought up >>>> >>> system like the ingate stuff. If the use case complicated stuff, I >>>> >>> would >>>> >>> remove it but so far the baseline the simple case has pretty much >>>> >>> solved >>>> >>> this one too. >>> >> >>> >> Yep, I motivated the use case at one point. >>> >> >>> >> However, what you have in 3.4 isn't quite what what Gary seemed to be >>> >> looking at, in that: >>> >> >>> >> 1) 3.4 shows another NAT between the UA and the EP. This doesn't make >>> >> the use case of 3.4 weaker, but might lead people to think that it is >>> >> a different problem, when this aspect is really a more-general >>> >> variant of Gary's case. >>> >> >>> >> 2) 3.4 does not seem show the use of "classic STUN" to discover the >>> >> effective IP address for RTP, along a path disparate from the coaxial >>> >> STUN used as a NAT keepalive. This is implied in the text, and is >>> >> obvious from STUN itself, but might not be obvious to somebody who >>> >> hasn't been thinking about this for a long time. >>> >> >>> >> 3) The use of coaxial STUN between the EP and the registrar, though >>> >> implied in 3.4, also doesn't seem obvious in the text. Nor is the >>> >> requirement for "back pressure" from the EP to the UA, should the EP- >>> >> Registrar coaxial STUN indicate a reset of the NAT between those >>> >> nodes. If this happens, I think that EP needs to induce a "keepalive >>> >> failure" on its own channel back to UA. You talk about UAs detecting >>> >> flow failure, but not about proxies detecting flow failure. Maybe it >>> >> is in there and I just missed it . . . >>> >> >>> >> -- >>> >> Dean >>> >> >> > >> > Yep - I see what you are saying. I will try and clarify the draft a >> > bit. > > > _______________________________________________ > 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 transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from your > system. Use, dissemination, distribution, or reproduction of this transmission > by unintended recipients is not authorized and may be unlawful. > > Any views, opinions and content presented in this e-mail are solely those of > the author and may not represent those of Objectworld Communications Corp. > --B_3223826444_7636451 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [Sip] Outbound and STUN Keep Alive
I think the hard part is that when the inner proxy detects the NAT between = the inter and out proxy has rebooted, it needs a way to tell all the UA to r= e-register. It's not that I don't want to solve this, is just that I think t= he solution to this can be solved separately from the minimal stuff that nee= ds to be outbound.


On 2/26/06 5:20 PM, "Michael Slavitch" <slavitch@objectworld.c= om> wrote:



I am not sure why it is a harder problem. It is a question of actions that = happen between peer agents, in this case one agent just happens to be a prox= y, and in the other case both agents are proxies. I can see why it was not i= n the original scope of requirements, but now that it's been alerted it give= s me pause that there is resistence in putting it in. Proxies should be able= to go anywhere in the same way that agents should be able to go anywhere.
Do people really consider proxies something so special that they deserve sp= ecial treatment, and are things SIP-wise separate from user agents? If so th= en SIP has changed from what it used to be and is losing its simple distribu= ted nature and becoming something that seems increasingly monolithic.

Regards

M


-----Original Message-----
From: Rohan Mahy [mailto:rohan@ekabal.co= m]
Sent: Sun 26/02/2006 6:13 PM
To: Cullen Jennings
Cc: sip@ietf.org; Dean Willis
Subject: Re: [Sip] Outbound and STUN Keep Alive

Hi,

If my recollection is correct, I think we decided that use cases of
NATs between proxies is out of scope of *this* document and that we can
work on the (probably harder) proxy to proxy problem in *another*
document so we can solve the more pressing problem sooner.

In any case, the proxy to proxy case is not explicitly listed in the
requirements anywhere.

thanks,
-rohan



On Feb 24, 2006, at 21:47, Cullen Jennings wrote:
> On 2/24/06 1:47 PM, "Dean Willis" <dean.willis@softarmor.= com> wrote:
>
>>
>> On Feb 24, 2006, at 12:54 PM, Cullen Jennings wrote:
>>
>>> On 2/23/06 1:16 PM, "Dean Willis" <dean.willis@so= ftarmor.com> wrote:
>>>
>>>> I think you guys are missing Gary's use case.
>>>>
>>>> He's postulating an entirely different NAT problem, where = the NAT
>>>> is between
>>>> the outbound proxy and the real world, rather than between= the UA
>>>> and its
>>>> outbound proxy.
>>>>
>>>> This just isn't a use case that's been in scope for genera= l
>>>> discussion so far.
>>>
>>> If I understand correctly ... I thin I added this use case to = the
>>> document
>>> awhile back because some people request it. For some vague rea= son,
>>> I thought
>>> Dean was one of the people that had requested it. People had >>> brought up
>>> system like the ingate stuff. If the use case complicated stuf= f, I
>>> would
>>> remove it but so far the baseline the simple case has pretty m= uch
>>> solved
>>> this one too.
>>
>> Yep, I motivated the use case at one point.
>>
>> However, what you have in 3.4 isn't quite what what Gary seemed to= be
>> looking at, in that:
>>
>> 1) 3.4 shows another NAT between the UA and the EP. This doesn't m= ake
>> the use case of 3.4 weaker, but might lead people to think that it= is
>> a different problem, when this aspect is really a more-general
>> variant of Gary's case.
>>
>> 2) 3.4 does not seem show the use of "classic STUN" to d= iscover the
>> effective IP address for RTP, along a path disparate from the coax= ial
>> STUN used as a NAT keepalive. This is implied in the text, and is<= BR> >> obvious from STUN itself, but might not be obvious to somebody who=
>> hasn't been thinking about this for a long time.
>>
>> 3) The use of coaxial STUN between the EP and the registrar, thoug= h
>> implied in 3.4, also doesn't seem obvious in the text. Nor is the<= BR> >> requirement for "back pressure" from the EP to the UA, s= hould the EP-
>> Registrar coaxial STUN indicate a reset of the NAT between those >> nodes. If this happens, I think that EP needs to induce a "ke= epalive
>> failure" on its own channel back to UA. You talk about UAs de= tecting
>> flow failure, but not about proxies detecting flow failure. Maybe = it
>> is in there and I just missed it . . .
>>
>> --
>> Dean
>>
>
> Yep - I see what you are saying. I will try and clarify the draft a > bit.


_______________________________________________
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 transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor-= client or other applicable privileges), or constitute non-public information= . Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use, = dissemination, distribution, or reproduction of this transmission by uninten= ded recipients is not authorized and may be unlawful.

Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp.=


--B_3223826444_7636451-- --===============0780502308== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0780502308==-- From sip-bounces@ietf.org Mon Feb 27 01:11:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDbZY-00066f-IE; Mon, 27 Feb 2006 01:09:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDbZV-00064p-BH; Mon, 27 Feb 2006 01:09:25 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDbZT-0004bM-Vt; Mon, 27 Feb 2006 01:09:25 -0500 Received: from [192.168.1.106] (c-24-1-44-191.hsd1.tx.comcast.net [24.1.44.191]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1R69T3q032586 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 27 Feb 2006 00:09:30 -0600 In-Reply-To: <28F05913385EAC43AF019413F674A0170DE0C2DF@OCCLUST04EVS1.ugd.att.com> References: <28F05913385EAC43AF019413F674A0170DE0C2DF@OCCLUST04EVS1.ugd.att.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3B5E51BE-ACE2-40BA-9DE3-6427D91B9116@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of Dividingand Conquering Date: Mon, 27 Feb 2006 00:09:16 -0600 To: "Dolly, Martin C, ALABS" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 1.0 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Cullen Jennings , Rohan Mahy , Jon Peterson , Allison Mankin , sip@ietf.org, "James M. Polk" , Sipping List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Feb 26, 2006, at 9:02 PM, Dolly, Martin C, ALABS wrote: > I do not see where further splitting work into new WGs..etc. solves > any > problem. More chairs, who are better empowered to keep their scopes narrow. More forceful chairing and supervision. Less groupthink. -- 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 sip-bounces@ietf.org Mon Feb 27 01:12:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDbaL-0006Z7-Fw; Mon, 27 Feb 2006 01:10:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDbaK-0006WD-4O for sip@ietf.org; Mon, 27 Feb 2006 01:10:16 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDbaI-0004cW-PC for sip@ietf.org; Mon, 27 Feb 2006 01:10:16 -0500 Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by nj300815-ier2.net.avaya.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k1R653X3023879 for ; Mon, 27 Feb 2006 01:05:03 -0500 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 k1R676hj000248 for ; Mon, 27 Feb 2006 01:07:07 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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] status on the SIP MIB modules? Date: Mon, 27 Feb 2006 08:10:12 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] status on the SIP MIB modules? Thread-Index: AcY7DKHb/ZaGeJlFSKqEJcMP/EDV3AAVqfow From: "Romascanu, Dan \(Dan\)" To: "Mark Ellison" , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Mark, Those are complementary. The SIP MIB draft exposes a different layer of management than the SIPPING and AVT drafts. Among other the SIP MIB provides configuration information on UAs and servers, and SIP session statistics. The SIPPING and AVT drafts focus on QoS reporting for media traffic using SIP mechanisms (draft-ietf-sipping-rtcp-summary-00) or SNMP (draft-ietf-avt-rtcp-xr-mib-03).=20 Regards, Dan =20 =20 > -----Original Message----- > From: Mark Ellison [mailto:ellison@ieee.org]=20 > Sent: Monday, February 27, 2006 12:37 AM > To: sip@ietf.org > Subject: Re: [Sip] status on the SIP MIB modules? >=20 > Hi Dean, >=20 > Thanks for your reply. >=20 > My understanding is another mechanism for exposing SIP=20 > statistics is moving forward, based upon the SIPPING=20 > draft-ietf-sipping-rtcp-summary-00 and AVT=20 > draft-ietf-avt-rtcp-xr-mib-03 drafts. >=20 > Maybe others on the list have considerations or concerns=20 > regarding any added usefulness for keeping the SIP MIB modules around? >=20 > Regards, >=20 > Mark >=20 > Dean Willis wrote: >=20 > > On Feb 24, 2006, at 11:31 AM, Mark Ellison wrote: > > > >> Hi, > >> > >> What is the current status for the SIP MIB modules? > >> > >> I notice that draft-ietf-sip-mib-09 is the latest revision=20 > of these=20 > >> module. It is my understanding -09 was submitted for IESG=20 > processing=20 > >> and that the current IESG status is "revised ID needed" , > >> as of 2005-12-11 (see http://tools.ietf.org/wg/sip/). Also, I=20 > >> notice that this matter is not on the agenda for IETF #65. > >> > >> Also I have a question about the sipMethodSupportedIndex=20 > object with=20 > >> respect to IANA registrations. In checking the IANA registry for=20 > >> sip (http://www.iana.org/assignments/sip-parameters) I=20 > see a list=20 > >> of methods (e.g. ACK, BYE, CANCEL, INFO...). I am assuming the=20 > >> intent is that SIP method names are in the IANA registry,=20 > as are SIP=20 > >> option tags. Possibly this is an area of the SIP MIB modules in=20 > >> need of revision? > >> > >> Regards, > > > > > > It appears to be suffering from a severe case of apathy. > > > > The last email I saw on the list was last summer, which may answer=20 > > your question about the sipMethodSupportedIndex object. > > > >> -----Original Message----- > >> From: Kevin Lingle (klingle) [mailto:klingle@cisco.com] > >> Sent: Friday, August 05, 2005 1:07 AM > >> To: Romascanu, Dan (Dan) > >> Cc: j.schoenwaelder@iu-bremen.de; sip@ietf.org; Wijnen,=20 > Bert (Bert);=20 > >> jf.mule@cablelabs.com > >> Subject: RE: [Sip] draft-ietf-sip-mib-09.txt - 'MIB Doctor' review > >> > >> dan, > >> > >> jean-francois and i have discussed the issue of using=20 > method name as=20 > >> an index and, at this point, neither of us > >> are against making that change. it has the benefit of > >> removing the method to identifier table and the IANA overhead > >> of administering the method identifiers. i'm going to take > >> a look at the actual changes required to the mib, but=20 > don't believe=20 > >> they will be significant. > >> > >> if you, as our mib doctor, think this is a useful change we will=20 > >> persue it. please let us know your opinion. > >> > >> thanks, > >> kevin > > > > > > to which Dan, as our MIB doctor, heartily agreed. > > > > Since then, we have awaited the revised MIB document. > > > > Interestingly enough, though the chairs and Allison discussed it in=20 > > December, with Allison suggesting it was time to declare=20 > the document=20 > > dead and either 1) get new editors, or 2) abandon the effort. Note=20 > > that since then nobody has asked it about until today. This=20 > argues for=20 > > option 2. > > > > Seriously, is anybody actually implementing the SIP mib? > > > > If it turns out that people really need this thing, perhaps=20 > we can ask=20 > > Kevin either cough out the document or surrender the pen (and the=20 > > document source) to a pinch-hitter for carrying across the=20 > finish line. > > > > -- > > Dean > > cochair > > > > >=20 >=20 >=20 >=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=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > 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 sip-bounces@ietf.org Mon Feb 27 01:20:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDbhx-0002gu-5Q; Mon, 27 Feb 2006 01:18:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDbhu-0002cE-2g; Mon, 27 Feb 2006 01:18:06 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDbht-0004w7-76; Mon, 27 Feb 2006 01:18:06 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 26 Feb 2006 22:18:05 -0800 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k1R6I4Xf005810; Sun, 26 Feb 2006 22:18:04 -0800 (PST) Received: from 171.68.225.134 ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Mon, 27 Feb 2006 06:18:03 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sun, 26 Feb 2006 22:18:01 -0800 Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of Dividingand Conquering From: Cullen Jennings To: "sip@ietf.org" , sipping Message-ID: Thread-Topic: [Sipping] Re: [Sip] Thoughts on the Principle of Dividingand Conquering Thread-Index: AcY7Q6mOhR2LvnfAR2GcDpXGmRTTDQABZDVQAAcVQBQ= In-Reply-To: <28F05913385EAC43AF019413F674A0170DE0C2DF@OCCLUST04EVS1.ugd.att.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 43ca87c8fcef5d9f6e966e1c3917103e Cc: Jon Peterson , Allison Mankin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I have written replies to this thread several times - then deleted them :-) It's a hard topic and certainly one that Jon, Allison and I were discussing before this thread. We have talked about it in relation to this thread. We will no doubt be talking about it for some time to come. Below are some questions I have been asking myself. They are really a random stream of conscious. I don't really want answers to them all but if they trigger some thoughts on concrete ideas we can that will help. That is great. I am clearly still in the stage of listening to ideas. Are the chairs the bottleneck that limits the rate? Are the ADs? How can we transfer responsibility from the ADs to chairs? Is the bottleneck to do with the rate that authors update drafts? Is if the bottleneck to do with the rate that comments are provided on the mailing lists? Can having a directorate get this done faster? Can we expand the amount of total work being done or can we only move it around? Do we need more people writing the same number of documents? Can we get new people? How much can we move work around from one topic to another? Will people work on a document they don't care about? why? I hear lots about what documents should be going faster but what documents should be slowed down? Are there whole WGs or topics that we should slow down to zero? There is a large amount of consensus on what document are critical to get done soon. That's surprising. Why? Can we take advantage of that somehow? What's stopping you from getting your drafts done? Is it just time to work on them? Do you need people to review them? Are they held up on other work? What's stopping you from reviewing the drafts you think are important and sending comments? What's stopping you from forcing the the drafts you want finished to get done? If you logically split some WG in two (trying to logical group related thing in each halt), then scheduled them concurrently, would you get twice as much work done or nothing done because everyone who was not there objected to any decision made? The ADs for the RAI WGs right now are Jon and Allison but I've certainly been doing a lot of thinking about this. Let me make a few observations: I would want any change to have some reasonably good chance to make more than a trivial impact. Mostly people work on what they want work on - they vote with their feet. This is a feature not a bug and much better than the alternative. People will work on stuff they don't care about but only to a limited degree. Once things get past WGLC, perhaps Chairs and ADs could be faster but this would not really accelerate things in a huge way. Still worth working on but less clear it can make a huge impact. Having Chairs carefully hound people to work on all the documents that few people care about might only speed up that work at the expense of stuff that is critical. I suspect that for the critical stuff, more hounding is good but there may be a limit. If we think that the sipping chairs are the bottleneck, well hypothetically, we could add another 5 people to the chair list. It's an interesting thought experiment to compare this to adding more groups. I can see several problems with this. Many of the same problems happen by having more working groups. Working groups could have an impact far greater than just more chairs. They allow us to partition time to certain classes of problems - effectively one class per working group - this might help or might not. It might result in a tool to speed up some classes of problems while slowing down others. I think it is reasonably clear that XCON and SIMPLE forking from SIPPING was a good thing. Selecting the right level of decomposition is always a balancing act. If you look at the other IETF directorates, they focus on a particular problem (such as XML, or MIB doctor) and thus can have a handful or two of people. What would we want a directorate here to do? Are we thinking of it as people that could take on an particular draft and help it accelerate it getting done? Would a directorate help this? I believe it might. Jon and I have been talking about this. Could we achieve the same thing some other ways? Would a directorate turn into a group that occasionally went for a nice dinner but did not do much else? I sort of like the directorate idea but I have just not figured out how to get one or more directorates focused enough to help. I have toyed with the idea of asking everyone to periodically focus some fraction of their energy on one key draft for a short period of time and try and get it done. By scheduling these out in time a bit, we might be able to deal with the complain of people not being able to schedule time for when drafts they care about need work. Would this work or be useless? Would it turn out being more or less the same thing as WGLC? Should we try and track the expected schedule for WGLCs across RAI? We have some problems where the solution must intrinsically be entangled across several RAI WGs. Would spending meeting time in a cross RAI meeting help with these? The energy barrier of new work is low. The energy barrier of finishing even simple work is very high. Some of the biggest things I can think of are already underway. The protos makes it so that chairs can do much of what only ADs could do previously. This is good. The formation of RAI allows the ADs to focus more. Anyways, don't read too much into anything I said here other than I'm glad to hear about ideas. In the end, the bulk of the work is done by volunteers that read drafts, provide ideas and comments, and write the drafts - it the people that count. Cullen On 2/26/06 7:02 PM, "Dolly, Martin C, ALABS" wrote: > Hello, > > I do not see where further splitting work into new WGs..etc. solves any > problem. > > I believe that "strong" chairing, and a true "democratic" process, where > not only the voices of the few are heard, will result in faster results. > > Cheers, > > Martin > >> -----Original Message----- >> From: James M. Polk [mailto:jmpolk@cisco.com] >> Sent: Sunday, February 26, 2006 9:15 PM >> To: Rohan Mahy; Dean Willis >> Cc: Cullen Jennings; sip@ietf.org List; Sipping List; Jon Peterson; >> Allison Mankin >> Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of >> Dividingand Conquering >> >> >> Hey >> >> While I was the first to comment on Dean's proposal not >> involving enough >> groups, and the potential for deviding again, I can see the >> flip side of >> this problem being if SIP does exactly what you suggest here: >> limited work >> to 4 or 5 items. >> >> The consequences of that action (or inaction) would be to >> have *more* SDOs >> defining extensions to SIP than is already going on. Many >> people have >> valid new ideas that are shut/stalled out because it takes so >> long to get >> any document done under the best of circumstances. >> >> Venture into this scenario: >> >> Rohan writes a new ID that has zero resistance >> >> Does it become a WG item in the first meeting? >> >> yeah - in SIPPING >> >> that's 6 months of time with zero resistance >> >> In the next meeting it may be moved to SIP for "protocol" >> work to be done >> >> 3 more months, with zero resistance >> >> How long does it take the WG to review the ID? >> >> No one can tell me reaslistically this happens overnight >> because everyone >> has queued the right amount of time to this effort. >> >> so it sits 3 more months >> >> Is this sip-00 version ready for WGLC? >> >> maybe, maybe not >> >> Maybe there is one thing that needs to be adjusted >> >> 3 more months until the next meeting >> >> At the next meeting, *maybe* this ID is ready for WGLC >> >> 2 more weeks >> >> if this is PS track >> >> 2 more weeks for IETF LC >> >> it gets to IESG, does it pass the first time? >> >> If not, that's 2 more weeks >> >> If so, it's 5 months with the RFC-Editor >> >> This adds up to roughly 20 months to get one idea through with >> unrealistically minimal resistance to the idea. >> >> I think this WG has more time on its hands to do more work >> than 4-5 items. >> >> If it takes 4 WGs to have faster milestones on the smaller >> IDs, I think >> that alone is a great idea. >> >> I look forward to a live discussion on this, if it is brought up. >> >> What I'm thinking is happening is more and more SDOs are >> getting tired of >> the IETF taking so long to get docs out. At some point they >> will consider >> the SIP WG irrelevant and do their own thing. >> >> Do we want that? >> >> If giving some of the tasks to other WG chairs to relieve you >> two (Dean and >> Rohan) to get more work done, even if the same number of core >> folks sit in >> each meeting, then I think it is better to get more work done >> with a series >> of WGs having more milestones to meet because there are more chairs >> cracking the whip on authors to get IDs revved and/or reviewed. >> >> >> >> At 04:06 PM 2/26/2006 -0800, Rohan Mahy wrote: >>> Hi, >>> >>> I don't think further splitting is going to solve our >> problems due to the >>> complexity of lateral communication required among groups >> with this much >>> in common. >>> >>> I do think that a working group that describes use cases for >> the RAI area >>> in general could produce some very useful output that has >> been out of >>> scope of individual working groups. The SIP NAT scenarios >> document would >>> be a good candidate to move into such a WG. >>> >>> I think mostly we have a problem saying no. We have too >> much work to do >>> and the only effective way for this community to get better >> throughput is >>> to focus religiously on a much smaller handful of work items >> (ex: 4 or 5) >>> at a time. I am as guilty as the next person for adding new >> milestones >>> (actually, more guilty as a chair), but it is hard to say no >> to new work >>> when old work that is "almost done" takes so long to finish. >>> >>> Perhaps we can have a discussion of this in the RAI area >> open meeting at >>> Dallas. It would be nice to hear the new ADs jump in here >> with their >>> thoughts. Also, Allison has been wrangling this monster longer than >>> anyone except Dean, so I am curious what she has to say. >>> >>> thanks, >>> -rohan >>> >>> >>> On Feb 23, 2006, at 16:30, Dean Willis wrote: >>>> I've been working on SIP and SIPPING and P2P-SIP agendas >> this week, and >>>> that started me thinking. >>>> >>>> We spun up SIPPING to take some of the load off of SIP, and >> in doing so >>>> tried to more narrowly-define the charters of both SIP and SIPPING >>>> relative to the previous SIP charter. >>>> >>>> When we started talking about P2P-SIP, we thought about >> bringing in the >>>> topic as part of SIPPING, but fairly quickly rejected that >> idea because >>>> it was clearly partitionable. >>>> >>>> This started me thinking -- could we further apply this >> principle of >>>> partitioning? >>>> >>>> Both SIP and SIPPING have grown into multi-year monsters, >> each with large >>>> charters and the need for multiple long-sessions at each >> IETF. They're >>>> tricky to chair, require lots of secretarial work, and are >> chronically >>>> late on deliverables (in large part because the chairs are >> acting like >>>> ADs instead of chairs). SPPING, once viewed as the kidney >> of SIP, now >>>> needs its own dialysis. >>>> >>>> Perhaps if we were to split these two working groups into >> three or four >>>> working groups that have much more clearly defined missions >> and scopes, >>>> we could cut them down to one meeting slot each. And if we >> were to have >>>> separate management (chairs and secretaries) for each >> working group, we >>>> could better manage the groups to timely delivery. >>>> >>>> So I'd like to toss out some ideas on how we might >> subdivide, and see how >>>> you folks feel about this. I think the key to any success >> here would be >>>> in scope management. >>>> >>>> What if we had the following groups: >>>> >>>> 1) SIPEM -- SIP Extended Maintenance >>>> >>>> 2) SIPNEW -- New major functionality for SIP >>>> >>>> 3) SIPREQ -- Analysis of requirements raised by new >> applications or SDO >>>> liaison >>>> >>>> 4) SIPUSE -- Using SIP to meet specific application requirements >>>> >>>> >>>> >>>> Here's how we might divide the work: >>>> >>>> >>>> SIPEM >>>> ----- >>>> >>>> Scope: Maintenance of SIP 2.0 and development (as per RFC 3427) of >>>> backward-compatible extensions driven by applications with >> near-term >>>> deployment scenarios. >>>> >>>> Initial Milestone Tasks of SIPEM: >>>> >>>> 1) Developing a SIP Guidebook, roughly the equivalent of the TCP >>>> Roadmap, that defines what's "in" SIP and how the pieces >> fit together. >>>> >>>> 2) GRUU >>>> >>>> 3) Outbound >>>> >>>> 4) Target-Dialog >>>> >>>> 5) Certificate Usage >>>> >>>> 6) Location Transport >>>> >>>> 7) Loop Error Correction >>>> >>>> 8) Connected Party Identity >>>> >>>> 9) Hop Limit Diagnostics >>>> >>>> 10) TLS Usage >>>> >>>> 11) Answering Modes >>>> >>>> 12) Connection Reuse >>>> >>>> 13) Rejection of Anonymous Requests >>>> >>>> 14) Consent Mechanism >>>> >>>> >>>> >>>> SIPNEW >>>> ------ >>>> >>>> Scope: Enhancement and evolution of SIP including >> architectural-level >>>> requirements and (as per RFC 3427) extensions without >> requirements for >>>> backward compatibility. >>>> >>>> >>>> Initial milestone tasks of SIPNEW >>>> >>>> 1) Developing a "future roadmap" for the evolution of SIP >>>> >>>> 2) Solving the RFC 3261 Routing Problem >>>> >>>> 3) Use of SAML with SIP >>>> >>>> 4) Response Identity >>>> >>>> 5) Response Authentication >>>> >>>> 6) End to Middle Requests >>>> >>>> >>>> >>>> SIPREQ >>>> ------ >>>> >>>> Scope: Analysis of requirements raised by new applications >> of SIP in IETF >>>> or in external SDOs (as per RFC 3427). Development of >> requirements for >>>> changes to SIP or for usage guides in response to applications >>>> requirements. Another way of wording this would be "problem >> definition". >>>> >>>> Initial milestones and tasks of SIPREQ: >>>> >>>> 1) Session Policy Requirements >>>> >>>> >>>> >>>> SIPUSE >>>> ------ >>>> >>>> Scope: Guidance on how to use existing SIP specifications >> and mechanisms >>>> including examples, call flows, test cases, error >> avoidance, and so on. >>>> Review (as per RFC 3427) of SIP Event Packages. >>>> >>>> >>>> Initial milestones and tasks for SIPUSE: >>>> >>>> 1) Service Examples >>>> >>>> 2) Security Examples >>>> >>>> 3) Race Condition Examples >>>> >>>> 4) Session media policy mechanism >>>> >>>> 5) Session policy package mechanism >>>> >>>> 6) Service quality reporting mechanism >>>> >>>> 7) URI List mechanism >>>> >>>> 8) Subscriptions to Ad-Hoc Resource Lists mechanism >>>> >>>> 9) Multiple REFER mechanism >>>> >>>> 10) Ad-Hoc Conferencing using URI lists mechanism >>>> >>>> 11) Call Control Transfer mechanism >>>> >>>> 12) Configuration Delivery mechanism >>>> >>>> 13) Emergency Calling using SIP (SOS) mechanism >>>> >>>> >>>> >>>> >>>> Note that I'm not entirely happy with the division of >> SIPPING into SIPUSE >>>> and SIPREQ. While it seems like we spend a lot of time in SIPPING >>>> debating requirements, there are currently a lot of >> deliverables in this >>>> category. >>>> >>>> >>>> -- >>>> 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 >>> >>> >>> _______________________________________________ >>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>> This list is for NEW development of the application of SIP >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sip@ietf.org for new developments of core SIP >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core 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 sip-bounces@ietf.org Mon Feb 27 02:35:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDcsq-00020X-1U; Mon, 27 Feb 2006 02:33:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDcsn-0001zw-KW; Mon, 27 Feb 2006 02:33:25 -0500 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDcsm-000711-Gu; Mon, 27 Feb 2006 02:33:25 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id k1R7XNHm128254; Mon, 27 Feb 2006 07:33:23 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k1R7Xb85232726; Mon, 27 Feb 2006 08:33:37 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k1R7XNcO018111; Mon, 27 Feb 2006 08:33:23 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k1R7XNRU018108; Mon, 27 Feb 2006 08:33:23 +0100 To: Cullen Jennings Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of Dividingand Conquering MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Avshalom Houri Message-ID: Date: Mon, 27 Feb 2006 09:33:31 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0HF90 | November 16, 2005) at 27/02/2006 09:33:36, Serialize complete at 27/02/2006 09:33:36 X-Spam-Score: 1.0 (+) X-Scan-Signature: 4c463dcf97e2b913ab242796279c24d2 Cc: "sip@ietf.org" , sipping , Jon Peterson , Allison Mankin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0767381306==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0767381306== Content-Type: multipart/alternative; boundary="=_alternative 00296A68C2257122_=" This is a multipart message in MIME format. --=_alternative 00296A68C2257122_= Content-Type: text/plain; charset="US-ASCII" If we look at SIP and compare it to TCP or other basic protocol, the main difference that I see that the base protocol of SIP never got really stable. Some new features that we are working on are features that have an effect into the protocol itself. Examples are GRUU and security. Although the amount of attention and the amount of work that people will be doing will influence a lot and hence the suggestions to restructure the group, I think that the main issue we have is if we can define what will consist as the base protocol and we will not be extending the base protocol in the years to come the same way we have a stability in TCP. Maybe the key issue here is to define layers and SIP and make sure that base layers will be stable enough so new extensions will not change them. I really wish to see SIP as a base protocol like TCP or HTTP and have the ability to define extensions and usages in many unrelated groups. Imagine what would have happened if we would have still defined TCP in the way we are doing now for SIP where new features influence the base protocol and have dependency on each other. Is there something inherent in SIP that will prevent us from freezing a base protocol while enabling the creation of many extensions in an independent way? If this is the case then we will shortly reach a point where any new extension to SIP will take years or have we reached that point? Thanks --Avshalom Cullen Jennings 27-02-06 08:18 AM To "sip@ietf.org" , sipping cc Jon Peterson , Allison Mankin Subject Re: [Sipping] Re: [Sip] Thoughts on the Principle of Dividingand Conquering I have written replies to this thread several times - then deleted them :-) It's a hard topic and certainly one that Jon, Allison and I were discussing before this thread. We have talked about it in relation to this thread. We will no doubt be talking about it for some time to come. Below are some questions I have been asking myself. They are really a random stream of conscious. I don't really want answers to them all but if they trigger some thoughts on concrete ideas we can that will help. That is great. I am clearly still in the stage of listening to ideas. Are the chairs the bottleneck that limits the rate? Are the ADs? How can we transfer responsibility from the ADs to chairs? Is the bottleneck to do with the rate that authors update drafts? Is if the bottleneck to do with the rate that comments are provided on the mailing lists? Can having a directorate get this done faster? Can we expand the amount of total work being done or can we only move it around? Do we need more people writing the same number of documents? Can we get new people? How much can we move work around from one topic to another? Will people work on a document they don't care about? why? I hear lots about what documents should be going faster but what documents should be slowed down? Are there whole WGs or topics that we should slow down to zero? There is a large amount of consensus on what document are critical to get done soon. That's surprising. Why? Can we take advantage of that somehow? What's stopping you from getting your drafts done? Is it just time to work on them? Do you need people to review them? Are they held up on other work? What's stopping you from reviewing the drafts you think are important and sending comments? What's stopping you from forcing the the drafts you want finished to get done? If you logically split some WG in two (trying to logical group related thing in each halt), then scheduled them concurrently, would you get twice as much work done or nothing done because everyone who was not there objected to any decision made? The ADs for the RAI WGs right now are Jon and Allison but I've certainly been doing a lot of thinking about this. Let me make a few observations: I would want any change to have some reasonably good chance to make more than a trivial impact. Mostly people work on what they want work on - they vote with their feet. This is a feature not a bug and much better than the alternative. People will work on stuff they don't care about but only to a limited degree. Once things get past WGLC, perhaps Chairs and ADs could be faster but this would not really accelerate things in a huge way. Still worth working on but less clear it can make a huge impact. Having Chairs carefully hound people to work on all the documents that few people care about might only speed up that work at the expense of stuff that is critical. I suspect that for the critical stuff, more hounding is good but there may be a limit. If we think that the sipping chairs are the bottleneck, well hypothetically, we could add another 5 people to the chair list. It's an interesting thought experiment to compare this to adding more groups. I can see several problems with this. Many of the same problems happen by having more working groups. Working groups could have an impact far greater than just more chairs. They allow us to partition time to certain classes of problems - effectively one class per working group - this might help or might not. It might result in a tool to speed up some classes of problems while slowing down others. I think it is reasonably clear that XCON and SIMPLE forking from SIPPING was a good thing. Selecting the right level of decomposition is always a balancing act. If you look at the other IETF directorates, they focus on a particular problem (such as XML, or MIB doctor) and thus can have a handful or two of people. What would we want a directorate here to do? Are we thinking of it as people that could take on an particular draft and help it accelerate it getting done? Would a directorate help this? I believe it might. Jon and I have been talking about this. Could we achieve the same thing some other ways? Would a directorate turn into a group that occasionally went for a nice dinner but did not do much else? I sort of like the directorate idea but I have just not figured out how to get one or more directorates focused enough to help. I have toyed with the idea of asking everyone to periodically focus some fraction of their energy on one key draft for a short period of time and try and get it done. By scheduling these out in time a bit, we might be able to deal with the complain of people not being able to schedule time for when drafts they care about need work. Would this work or be useless? Would it turn out being more or less the same thing as WGLC? Should we try and track the expected schedule for WGLCs across RAI? We have some problems where the solution must intrinsically be entangled across several RAI WGs. Would spending meeting time in a cross RAI meeting help with these? The energy barrier of new work is low. The energy barrier of finishing even simple work is very high. Some of the biggest things I can think of are already underway. The protos makes it so that chairs can do much of what only ADs could do previously. This is good. The formation of RAI allows the ADs to focus more. Anyways, don't read too much into anything I said here other than I'm glad to hear about ideas. In the end, the bulk of the work is done by volunteers that read drafts, provide ideas and comments, and write the drafts - it the people that count. Cullen --=_alternative 00296A68C2257122_= Content-Type: text/html; charset="US-ASCII"
If we look at SIP and compare it to TCP or other basic protocol, the main difference that I see that
the base protocol of SIP never got really stable. Some new features that we are working on
are features that have an effect into the protocol itself. Examples are GRUU and security.

Although the amount of attention and the amount of work that people will be doing will influence a lot
and hence the suggestions to restructure the group, I think that the main issue we have is if we can define
what will consist as the base protocol and we will not be extending the base protocol in the years to come
the same way we have a stability in TCP.

Maybe the key issue here is to define layers and SIP and make sure that base layers will be stable enough
so new extensions will not change them. I really wish to see SIP as a base protocol like TCP or HTTP and
have the ability to define extensions and usages in many unrelated groups. Imagine what would have happened
if we would have still defined TCP in the way we are doing now for SIP where new features influence the base
protocol and have dependency on each other.

Is there something inherent in SIP that will prevent us from freezing a base protocol while enabling the creation
of many extensions in an independent way? If this is the case then we will shortly reach a point where any new
extension to SIP will take years or have we reached that point?

Thanks
--Avshalom


Cullen Jennings <fluffy@cisco.com>

27-02-06 08:18 AM

To
"sip@ietf.org" <sip@ietf.org>, sipping <sipping@ietf.org>
cc
Jon Peterson <jon.peterson@neustar.biz>, Allison Mankin <mankin@psg.com>
Subject
Re: [Sipping] Re: [Sip] Thoughts on the Principle of Dividingand        Conquering






I have written replies to this thread several times - then deleted them :-)
It's a hard topic and certainly one that Jon, Allison and I were discussing
before this thread. We have talked about it in relation to this thread. We
will no doubt be talking about it for some time to come. Below are some
questions I have been asking myself. They are really a random stream of
conscious. I don't really want answers to them all but if they trigger some
thoughts on concrete ideas we can that will help. That is great. I am
clearly still in the stage of listening to ideas.

Are the chairs the bottleneck that limits the rate? Are the ADs? How can we
transfer responsibility from the ADs to chairs?

Is the bottleneck to do with the rate that authors update drafts? Is if the
bottleneck to do with the rate that comments are provided on the mailing
lists? Can having a directorate get this done faster?

Can we expand the amount of total work being done or can we only move it
around? Do we need more people writing the same number of documents? Can we
get new people? How much can we move work around from one topic to another?
Will people work on a document they don't care about? why?

I hear lots about what documents should be going faster but what documents
should be slowed down? Are there whole WGs or topics that we should slow
down to zero? There is a large amount of consensus on what document are
critical to get done soon. That's surprising. Why? Can we take advantage of
that somehow?

What's stopping you from getting your drafts done? Is it just time to work
on them? Do you need people to review them? Are they held up on other work?
What's stopping you from reviewing the drafts you think are important and
sending comments? What's stopping you from forcing the the drafts you want
finished to get done?

If you logically split some WG in two (trying to logical group related thing
in each halt), then scheduled them concurrently, would you get twice as much
work done or nothing done because everyone who was not there objected to any
decision made?

The ADs for the RAI WGs right now are Jon and Allison but I've certainly
been doing a lot of thinking about this. Let me make a few observations:

I would want any change to have some reasonably good chance to make more
than a trivial impact.

Mostly people work on what they want work on -  they vote with their feet.
This is a feature not a bug and much better than the alternative. People
will work on stuff they don't care about but only to a limited degree.

Once things get past WGLC, perhaps Chairs and ADs could be faster but this
would not really accelerate things in a huge way. Still worth working on but
less clear it can make a huge impact.

Having Chairs carefully hound people to work on all the documents that few
people care about might only speed up that work at the expense of stuff that
is critical. I suspect that for the critical stuff, more hounding is good
but there may be a limit.

If we think that the sipping chairs are the bottleneck, well hypothetically,
we could add another 5 people to the chair list. It's an interesting thought
experiment to compare this to adding more groups. I can see several problems
with this. Many of the same problems happen by having more working groups.

Working groups could have an impact far greater than just more chairs. They
allow us to partition time to certain classes of problems - effectively one
class per working group - this might help or might not.  It might result in
a tool to speed up some classes of problems while slowing down others. I
think it is reasonably clear that XCON and SIMPLE forking from SIPPING was a
good thing. Selecting the right level of decomposition is always a balancing
act.

If you look at the other IETF directorates, they focus on a particular
problem (such as XML, or MIB doctor) and thus can have a handful or two of
people. What would we want a directorate here to do? Are we thinking of it
as people that could take on an particular draft and help it accelerate it
getting done? Would a directorate help this? I believe it might. Jon and I
have been talking about this. Could we achieve the same thing some other
ways? Would a directorate turn into a group that occasionally went for a
nice dinner but did not do much else? I sort of like the directorate idea
but I have just not figured out how to get one or more directorates focused
enough to help.

I have toyed with the idea of asking everyone to periodically focus some
fraction of their energy on one key draft for a short period of time and try
and get it done. By scheduling these out in time a bit, we might be able to
deal with the complain of people not being able to schedule time for when
drafts they care about need work. Would this work or be useless? Would it
turn out being more or less the same thing as WGLC? Should we try and track
the expected schedule for WGLCs across RAI?

We have some problems where the solution must intrinsically be entangled
across several RAI WGs. Would spending meeting time in a cross RAI meeting
help with these?

The energy barrier of new work is low. The energy barrier of finishing even
simple work is very high.

Some of the biggest things I can think of are already underway. The protos
makes it so that chairs can do much of what only ADs could do previously.
This is good. The formation of RAI allows the ADs to focus more.

Anyways, don't read too much into anything I said here other than I'm glad
to hear about ideas. In the end, the bulk of the work is done by volunteers
that read drafts, provide ideas and comments, and write the drafts - it the
people that count.

Cullen
--=_alternative 00296A68C2257122_=-- --===============0767381306== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0767381306==-- From sip-bounces@ietf.org Mon Feb 27 03:47:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDe0d-00058g-I0; Mon, 27 Feb 2006 03:45:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDe0c-00058b-CB for sip@ietf.org; Mon, 27 Feb 2006 03:45:34 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDe0a-0001A1-PT for sip@ietf.org; Mon, 27 Feb 2006 03:45:34 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 106834F0043 for ; Mon, 27 Feb 2006 09:45:32 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Feb 2006 09:45:31 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Feb 2006 09:45:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Feb 2006 09:45:30 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1AAC@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Questions on subscription dialogs Thread-Index: AcX5rzj/n3mO2zF7Tx2QopvIMU8+exByiqWQ From: "Christer Holmberg \(JO/LMF\)" To: "IETF SIP List" X-OriginalArrivalTime: 27 Feb 2006 08:45:31.0562 (UTC) FILETIME=[2ABB88A0:01C63B7A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Sip] Questions on subscription dialogs X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, A few questions on subscription dialogs. Q1: Is it allowed to send non-NOTIFY request within a subscription dialog (initiated by SUBSCRIBE), assuming the users support it? Q2: If Q1=3D=3DTRUE, is it allowed to add media during a subscription dialog, by sending an SDP offer in an UPDATE/re-INVITE? Q3: If Q2=3D=3DTRUE, is it allowed to use re-INVITE, eventhough the = dialog was not initiated using INVITE? Q4: If Q1=3D=3DTRUE, if I send an empty re-INVITE within a subscription dialog, e.g. to update the remote target, I assume the receiver MUST create and include an SDP offer in the 200 OK response, eventhough no media has previously been used within the dialog? Regards, Christer _______________________________________________ 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 sip-bounces@ietf.org Mon Feb 27 05:00:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDf8q-0002kM-Qh; Mon, 27 Feb 2006 04:58:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDf8p-0002jb-Ik for sip@ietf.org; Mon, 27 Feb 2006 04:58:07 -0500 Received: from [80.74.106.10] (helo=rvil-mail1.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDf8n-0003AY-IK for sip@ietf.org; Mon, 27 Feb 2006 04:58:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 27 Feb 2006 11:59:08 +0200 Message-ID: <7579E2B4F92E89429C01EA57E4E6DBBB1D5E2C@rvil-mail1.RADVISION.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Problem in digest authentication usage in RFC3329 Thread-Index: AcY7g+kNxfVhVSc6TAOBCAZG7h9mfwAAFBJQ From: "Tamar Barzuza" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Subject: [Sip] Problem in digest authentication usage in RFC3329 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2146858581==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2146858581== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63B84.734ECEAB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C63B84.734ECEAB Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, =20 The usage of digest authentication by RFC3329 is unclear to me. =20 1. Who inserts the digest-verify parameter to the security header? Is it the client to Security-Verify or the server to Security-Server, or both? 2. Does the client use the Security-Server header as a string in computing the digest-verify parameter? It seems unreasonable to rely on string representation of headers, due to the parsing and encoding mechanisms that occur at each hop and might change the order of parameters and their spacing. =20 Thank you, Tamar. ------_=_NextPart_001_01C63B84.734ECEAB Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi,

 

The usage of digest authentication by RFC3329 is unclear to = me.

 

1.     = Who inserts the digest-verify parameter to the security header? Is it the = client to Security-Verify or the server to Security-Server, or = both?

2.     = Does the client use the Security-Server header as a string in computing the digest-verify parameter? It seems unreasonable to rely on string = representation of headers, due to the parsing and encoding mechanisms that occur at = each hop and might change the order of parameters and their = spacing.

 

Thank you,

Tamar.

------_=_NextPart_001_01C63B84.734ECEAB-- --===============2146858581== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============2146858581==-- From sip-bounces@ietf.org Mon Feb 27 05:34:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDffu-0003L4-Ua; Mon, 27 Feb 2006 05:32:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDfft-0003Iv-8p for sip@ietf.org; Mon, 27 Feb 2006 05:32:17 -0500 Received: from zproxy.gmail.com ([64.233.162.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDffs-0004Pl-2J for sip@ietf.org; Mon, 27 Feb 2006 05:32:17 -0500 Received: by zproxy.gmail.com with SMTP id i1so931143nzh for ; Mon, 27 Feb 2006 02:32:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=bb8d0HB/EgNaL4q0w4JDd20eTcNraZ9H08TdxdLdbLA+ool/ENUAHKaYrxu31pG20PKu5Af1J8RS34uA3Q8fsVZ+ZEr4q7b99g8bRlpkei8aBnU7oMfnMc29yZGk2IuQtcI63LzSgIzv7Yz3XT+Po9xLlc2ymeTeuCVQUYZrVH8= Received: by 10.65.74.12 with SMTP id b12mr501368qbl; Mon, 27 Feb 2006 02:32:15 -0800 (PST) Received: by 10.64.156.20 with HTTP; Mon, 27 Feb 2006 02:32:15 -0800 (PST) Message-ID: <7f5ac7240602270232r10516ad6xd0a4a8843b9d23c2@mail.gmail.com> Date: Mon, 27 Feb 2006 19:32:15 +0900 From: "Mahesh Govind" To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Rajkumar Nair , "Ivan Varghis \(ivarghis\)" Subject: [Sip] draft-asyn-service-state-notification-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1606247907==" Errors-To: sip-bounces@ietf.org --===============1606247907== Content-Type: multipart/alternative; boundary="----=_Part_1215_5846405.1141036335614" ------=_Part_1215_5846405.1141036335614 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline HI All, We would like to submit a draft on asynchronous service state notification= s of sip entities .The draft explains about an event based mechanism for notification of state of SIP entities. The mechanism can be used for advanc= e notification of going out of state of SIP entitles, service redirection for proper load balancing etc. http://www.geocities.com/maheshwarrier/draft-asyn-service-state-notificatio= n-00.txt Please send us the feed back on the same . With thanks and regards Ivan,Mahesh,Rajkumar ------=_Part_1215_5846405.1141036335614 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
 
HI All,
We  would like to submit a draft on asynchronous service state no= tifications of
sip entities .The draft explains about an event based mechanism for notification of state of SIP entities. The mechanism can be used for adva= nce notification of
going out of state of SIP entitles, service redirec= tion for proper load balancing etc.=20
 
 
Please send us the feed back on the same .
With thanks and regards
Ivan,Mahesh,Rajkumar
------=_Part_1215_5846405.1141036335614-- --===============1606247907== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1606247907==-- From sip-bounces@ietf.org Mon Feb 27 08:09:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDi5f-0005aE-SH; Mon, 27 Feb 2006 08:07:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDi5e-0005ZX-OJ for sip@ietf.org; Mon, 27 Feb 2006 08:07:02 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDi5d-0000yl-BN for sip@ietf.org; Mon, 27 Feb 2006 08:07:02 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id k1RD6snN021396; Mon, 27 Feb 2006 06:06:54 -0700 (MST) 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] status on the SIP MIB modules? Date: Mon, 27 Feb 2006 06:06:54 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] status on the SIP MIB modules? Thread-Index: AcY5j29dKQxxIed4SCWenzWDWU3cwgCDbzWg From: "Jean-Francois Mule" To: "Dean Willis" , "Mark Ellison" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean wrote: > It appears to be suffering from a severe case of apathy. This is an aggravated case since MIB doctors reviewed the health of the last draft. Kevin and I are working on a revision to address the main mib doctor comments on sipMethodSupportedIndex. The goal is also to go thru the mib design guidelines and do all the final checks on the SMI. We intend to publish draft-10 by next Monday March 6 to meet the cut-off deadline for the next meeting. There are better topics for f2f time so I don't think the co-authors would like to put this topic on the SIP agenda item. Mark Ellison wrote > > Also I have a question about the sipMethodSupportedIndex object > > with respect to IANA registrations. In checking the IANA registry > > for sip (http://www.iana.org/assignments/sip-parameters) I see a > > list of methods (e.g. ACK, BYE, CANCEL, INFO...). I am assuming > > the intent is that SIP method names are in the IANA registry, as > > are SIP option tags. Possibly this is an area of the SIP MIB > > modules in need of revision? http://www.iana.org/assignments/sip-parameters We don't intend to change anything to add new supported methods in the draft. Jean-Francois > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, February 24, 2006 3:13 PM > To: Mark Ellison; klingle@cisco.com; Jean-Francois Mule > Cc: sip@ietf.org List > Subject: Re: [Sip] status on the SIP MIB modules? >=20 > On Feb 24, 2006, at 11:31 AM, Mark Ellison wrote: >=20 > > Hi, > > > > What is the current status for the SIP MIB modules? > > > > I notice that draft-ietf-sip-mib-09 is the latest revision of these > > module. It is my understanding -09 was submitted for IESG > > processing and that the current IESG status is "revised ID > > needed" , as of 2005-12-11 (see http://tools.ietf.org/wg/sip/). > > Also, I notice that this matter is not on the agenda for IETF #65. > > > > Also I have a question about the sipMethodSupportedIndex object > > with respect to IANA registrations. In checking the IANA registry > > for sip (http://www.iana.org/assignments/sip-parameters) I see a > > list of methods (e.g. ACK, BYE, CANCEL, INFO...). I am assuming > > the intent is that SIP method names are in the IANA registry, as > > are SIP option tags. Possibly this is an area of the SIP MIB > > modules in need of revision? > > > > Regards, >=20 > It appears to be suffering from a severe case of apathy. >=20 > The last email I saw on the list was last summer, which may answer > your question about the sipMethodSupportedIndex object. >=20 > > -----Original Message----- > > From: Kevin Lingle (klingle) [mailto:klingle@cisco.com] > > Sent: Friday, August 05, 2005 1:07 AM > > To: Romascanu, Dan (Dan) > > Cc: j.schoenwaelder@iu-bremen.de; sip@ietf.org; Wijnen, Bert > > (Bert); jf.mule@cablelabs.com > > Subject: RE: [Sip] draft-ietf-sip-mib-09.txt - 'MIB Doctor' review > > > > dan, > > > > jean-francois and i have discussed the issue of using method > > name as an index and, at this point, neither of us > > are against making that change. it has the benefit of > > removing the method to identifier table and the IANA overhead > > of administering the method identifiers. i'm going to take > > a look at the actual changes required to the mib, but don't > > believe they will be significant. > > > > if you, as our mib doctor, think this is a useful change we > > will persue it. please let us know your opinion. > > > > thanks, > > kevin >=20 > to which Dan, as our MIB doctor, heartily agreed. >=20 > Since then, we have awaited the revised MIB document. >=20 > Interestingly enough, though the chairs and Allison discussed it in > December, with Allison suggesting it was time to declare the document > dead and either 1) get new editors, or 2) abandon the effort. Note > that since then nobody has asked it about until today. This argues > for option 2. >=20 > Seriously, is anybody actually implementing the SIP mib? >=20 > If it turns out that people really need this thing, perhaps we can > ask Kevin either cough out the document or surrender the pen (and the > document source) to a pinch-hitter for carrying across the finish > line. >=20 > -- > Dean > cochair _______________________________________________ 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 sip-bounces@ietf.org Mon Feb 27 08:46:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDig3-0006Lj-U1; Mon, 27 Feb 2006 08:44:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDig2-0006Kp-3h; Mon, 27 Feb 2006 08:44:38 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDig0-0002Ug-Dl; Mon, 27 Feb 2006 08:44:38 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 27 Feb 2006 05:44:36 -0800 X-IronPort-AV: i="4.02,150,1139212800"; d="scan'208"; a="1779984386:sNHT190882538" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k1RDiYuj003654; Mon, 27 Feb 2006 05:44:35 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Feb 2006 08:44:35 -0500 Received: from [192.168.1.104] ([10.86.240.111]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Feb 2006 08:44:34 -0500 Message-ID: <44030241.90007@cisco.com> Date: Mon, 27 Feb 2006 08:44:33 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avshalom Houri Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of Dividingand Conquering References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Feb 2006 13:44:34.0696 (UTC) FILETIME=[F1AC8080:01C63BA3] X-Spam-Score: 0.5 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: Cullen Jennings , "sip@ietf.org" , sipping , Jon Peterson , Allison Mankin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Avshalom, I disagree that any of the work we're doing is changing the base protocol. Everything is an extension to SIP, not a change to it. Some of them are important (like sip-outbound) and some of them seem like commonly needed functions, but all add new functionality. The way to figure out whether something is really changing the base spec is if you have something that needs Require or Proxy-Require in every message sent by a client. draft-ietf-sip-guidelines recognizes that such extensions are effectively changes to sip. Thanks, Jonathan R. Avshalom Houri wrote: > > If we look at SIP and compare it to TCP or other basic protocol, the > main difference that I see that > the base protocol of SIP never got really stable. Some new features that > we are working on > are features that have an effect into the protocol itself. Examples are > GRUU and security. > > Although the amount of attention and the amount of work that people will > be doing will influence a lot > and hence the suggestions to restructure the group, I think that the > main issue we have is if we can define > what will consist as the base protocol and we will not be extending the > base protocol in the years to come > the same way we have a stability in TCP. > > Maybe the key issue here is to define layers and SIP and make sure that > base layers will be stable enough > so new extensions will not change them. I really wish to see SIP as a > base protocol like TCP or HTTP and > have the ability to define extensions and usages in many unrelated > groups. Imagine what would have happened > if we would have still defined TCP in the way we are doing now for SIP > where new features influence the base > protocol and have dependency on each other. > > Is there something inherent in SIP that will prevent us from freezing a > base protocol while enabling the creation > of many extensions in an independent way? If this is the case then we > will shortly reach a point where any new > extension to SIP will take years or have we reached that point? > > Thanks > --Avshalom > > > > *Cullen Jennings * > > 27-02-06 08:18 AM > > > To > "sip@ietf.org" , sipping > cc > Jon Peterson , Allison Mankin > Subject > Re: [Sipping] Re: [Sip] Thoughts on the Principle of Dividingand > Conquering > > > > > > > > > > I have written replies to this thread several times - then deleted them :-) > It's a hard topic and certainly one that Jon, Allison and I were discussing > before this thread. We have talked about it in relation to this thread. We > will no doubt be talking about it for some time to come. Below are some > questions I have been asking myself. They are really a random stream of > conscious. I don't really want answers to them all but if they trigger some > thoughts on concrete ideas we can that will help. That is great. I am > clearly still in the stage of listening to ideas. > > Are the chairs the bottleneck that limits the rate? Are the ADs? How can we > transfer responsibility from the ADs to chairs? > > Is the bottleneck to do with the rate that authors update drafts? Is if the > bottleneck to do with the rate that comments are provided on the mailing > lists? Can having a directorate get this done faster? > > Can we expand the amount of total work being done or can we only move it > around? Do we need more people writing the same number of documents? Can we > get new people? How much can we move work around from one topic to another? > Will people work on a document they don't care about? why? > > I hear lots about what documents should be going faster but what documents > should be slowed down? Are there whole WGs or topics that we should slow > down to zero? There is a large amount of consensus on what document are > critical to get done soon. That's surprising. Why? Can we take advantage of > that somehow? > > What's stopping you from getting your drafts done? Is it just time to work > on them? Do you need people to review them? Are they held up on other work? > What's stopping you from reviewing the drafts you think are important and > sending comments? What's stopping you from forcing the the drafts you want > finished to get done? > > If you logically split some WG in two (trying to logical group related thing > in each halt), then scheduled them concurrently, would you get twice as much > work done or nothing done because everyone who was not there objected to any > decision made? > > The ADs for the RAI WGs right now are Jon and Allison but I've certainly > been doing a lot of thinking about this. Let me make a few observations: > > I would want any change to have some reasonably good chance to make more > than a trivial impact. > > Mostly people work on what they want work on - they vote with their feet. > This is a feature not a bug and much better than the alternative. People > will work on stuff they don't care about but only to a limited degree. > > Once things get past WGLC, perhaps Chairs and ADs could be faster but this > would not really accelerate things in a huge way. Still worth working on but > less clear it can make a huge impact. > > Having Chairs carefully hound people to work on all the documents that few > people care about might only speed up that work at the expense of stuff that > is critical. I suspect that for the critical stuff, more hounding is good > but there may be a limit. > > If we think that the sipping chairs are the bottleneck, well hypothetically, > we could add another 5 people to the chair list. It's an interesting thought > experiment to compare this to adding more groups. I can see several problems > with this. Many of the same problems happen by having more working groups. > > Working groups could have an impact far greater than just more chairs. They > allow us to partition time to certain classes of problems - effectively one > class per working group - this might help or might not. It might result in > a tool to speed up some classes of problems while slowing down others. I > think it is reasonably clear that XCON and SIMPLE forking from SIPPING was a > good thing. Selecting the right level of decomposition is always a balancing > act. > > If you look at the other IETF directorates, they focus on a particular > problem (such as XML, or MIB doctor) and thus can have a handful or two of > people. What would we want a directorate here to do? Are we thinking of it > as people that could take on an particular draft and help it accelerate it > getting done? Would a directorate help this? I believe it might. Jon and I > have been talking about this. Could we achieve the same thing some other > ways? Would a directorate turn into a group that occasionally went for a > nice dinner but did not do much else? I sort of like the directorate idea > but I have just not figured out how to get one or more directorates focused > enough to help. > > I have toyed with the idea of asking everyone to periodically focus some > fraction of their energy on one key draft for a short period of time and try > and get it done. By scheduling these out in time a bit, we might be able to > deal with the complain of people not being able to schedule time for when > drafts they care about need work. Would this work or be useless? Would it > turn out being more or less the same thing as WGLC? Should we try and track > the expected schedule for WGLCs across RAI? > > We have some problems where the solution must intrinsically be entangled > across several RAI WGs. Would spending meeting time in a cross RAI meeting > help with these? > > The energy barrier of new work is low. The energy barrier of finishing even > simple work is very high. > > Some of the biggest things I can think of are already underway. The protos > makes it so that chairs can do much of what only ADs could do previously. > This is good. The formation of RAI allows the ADs to focus more. > > Anyways, don't read too much into anything I said here other than I'm glad > to hear about ideas. In the end, the bulk of the work is done by volunteers > that read drafts, provide ideas and comments, and write the drafts - it the > people that count. > > Cullen > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.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 sip-bounces@ietf.org Mon Feb 27 09:01:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDiuj-00070k-TP; Mon, 27 Feb 2006 08:59:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDiui-00070Q-Kc for sip@ietf.org; Mon, 27 Feb 2006 08:59:48 -0500 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDiui-00030R-E2 for sip@ietf.org; Mon, 27 Feb 2006 08:59:48 -0500 Received: from 71-81-78-136.dhcp.stls.mo.charter.com ([71.81.78.136] helo=[192.168.30.38]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1FDiui-000KJ4-1V; Mon, 27 Feb 2006 08:59:48 -0500 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 71.81.78.136 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: digitalari Message-ID: <440305D2.80300@sipstation.com> Date: Mon, 27 Feb 2006 07:59:46 -0600 From: Alan Johnston User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) 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-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Philip Zimmermann Subject: [Sip] draft-zimmermann-avt-zrtp-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org All, We have just submitted a new Internet-Draft draft-zimmermann-avt-zrtp-00.txt. Until it becomes available in the archives, you can get a copy at: http://www.philzimmermann.com/zfone/draft-zimmermann-avt-zrtp-00.txt http://www.philzimmermann.com/zfone/draft-zimmermann-avt-zrtp-00.html We will request a slot in AVT in Dallas to discuss. Discussion about the RTP extensions and mechanism are best held on the AVT list while discussions about key management for SRTP are best held on the MMUSIC list, with some cross posting as needed. Apologies for the multiple postings. Thanks, Alan - - - ZRTP: Extensions to RTP for Diffie-Hellman Key Agreement for SRTP draft-zimmermann-avt-zrtp-00 Abstract This document defines ZRTP, RTP (Real-time Transport Protocol) header extensions for a Diffie-Hellman exchange to agree on a session key and parameters for establishing Secure RTP (SRTP) sessions. The ZRTP protocol is completely self-contained in RTP and does not require support in the signaling protocol or assume a Public Key Infrastructure (PKI) infrastructure. For the media session, ZRTP provides confidentiality and, in cases where a secret is available from the signaling protocol, authentication. _______________________________________________ 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 sip-bounces@ietf.org Mon Feb 27 10:06:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDjvM-0008Sx-5F; Mon, 27 Feb 2006 10:04:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDjvK-0008PQ-9N for sip@ietf.org; Mon, 27 Feb 2006 10:04:30 -0500 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDjvI-0005au-QE for sip@ietf.org; Mon, 27 Feb 2006 10:04:30 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 4FBC16C01C for ; Mon, 27 Feb 2006 10:04:27 -0500 (EST) From: "Dale R. Worley" To: Sip Content-Type: text/plain Date: Mon, 27 Feb 2006 10:04:27 -0500 Message-Id: <1141052667.2206.20.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Sip] draft-worley-sip-dialog-00: Guidelines for Implementing the Dialog Event Package in User Agents X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I've revised my Internet-Draft on what is needed in dialog event packages to implement EPCC features. (It's now marked "sip" rather than "sipping", because the dialog event package is now an RFC, so this is tidying up an existing SIP feature, not part of a new one. Hence the number starts over again at 00.) Guidelines for Implementing the Dialog Event Package in User Agents draft-worley-sip-dialog-00 This document sets out guidelines for how user agents should implement the dialog event package in order to be usable in systems that implement end-point controlled call-control (EPCC) features. It is in addition to the basic requirements for dialog event package implementation in RFC 3265 and RFC 4235. Further discussion and input is greatly desired. Until it is available from the I-D directories, you can get it from: http://scm.sipfoundry.org/rep/ietf-drafts/worley/draft-worley-sip-dialog-00.txt http://scm.sipfoundry.org/rep/ietf-drafts/worley/draft-worley-sip-dialog-00.html http://scm.sipfoundry.org/rep/ietf-drafts/worley/draft-worley-sip-dialog-00.xml Dale _______________________________________________ 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 sip-bounces@ietf.org Mon Feb 27 14:07:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDngh-0000lE-Jd; Mon, 27 Feb 2006 14:05:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDngf-0000kw-Tt; Mon, 27 Feb 2006 14:05:37 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDngf-0006GZ-4S; Mon, 27 Feb 2006 14:05:37 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 27 Feb 2006 14:05:37 -0500 X-IronPort-AV: i="4.02,150,1139202000"; d="scan'208"; a="83198063:sNHT41032640" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1RJ5PjP013794; Mon, 27 Feb 2006 14:05:36 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Feb 2006 14:05:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] Re: [Sip] Thoughts on the Principle of DividingandConquering Date: Mon, 27 Feb 2006 14:05:28 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301245A9E@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Re: [Sip] Thoughts on the Principle of DividingandConquering Thread-Index: AcY7Q6mOhR2LvnfAR2GcDpXGmRTTDQABZDVQAAcVQBQAGp20wA== From: "Michael Hammer \(mhammer\)" To: "Cullen Jennings \(fluffy\)" , , "sipping" X-OriginalArrivalTime: 27 Feb 2006 19:05:31.0501 (UTC) FILETIME=[C79FC1D0:01C63BD0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9724479da43a8325ad975c1a9b841870 Cc: Jon Peterson , Allison Mankin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen, Your questions echo some that have been bouncing around in my head as well. With so many drafts, I tend to think it is a dilution of focus, where the speed of any one document is progressed at the speed of its share of the groups collective focus. In other words, the collective brain is thrashing from one draft to another. =20 If the chairs could get the group to agree on the prioritized list of drafts (or just make that decision), then have a draft of the month system where the WG focuses on one draft until it is finished. The author should be prepared to update it every workday if needed to keep pace. At the end of the month, it goes to last call. If the author is not prepared, go to end of the queue, or have another author take over. Mike > -----Original Message----- > From: Cullen Jennings (fluffy)=20 > Sent: Monday, February 27, 2006 1:18 AM > To: sip@ietf.org; sipping > Cc: Jon Peterson; Allison Mankin > Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of=20 > DividingandConquering >=20 >=20 > I have written replies to this thread several times - then=20 > deleted them :-) It's a hard topic and certainly one that=20 > Jon, Allison and I were discussing before this thread. We=20 > have talked about it in relation to this thread. We will no=20 > doubt be talking about it for some time to come. Below are=20 > some questions I have been asking myself. They are really a=20 > random stream of conscious. I don't really want answers to=20 > them all but if they trigger some thoughts on concrete ideas=20 > we can that will help. That is great. I am clearly still in=20 > the stage of listening to ideas. >=20 > Are the chairs the bottleneck that limits the rate? Are the=20 > ADs? How can we transfer responsibility from the ADs to chairs? >=20 > Is the bottleneck to do with the rate that authors update=20 > drafts? Is if the bottleneck to do with the rate that=20 > comments are provided on the mailing lists? Can having a=20 > directorate get this done faster? >=20 > Can we expand the amount of total work being done or can we=20 > only move it around? Do we need more people writing the same=20 > number of documents? Can we get new people? How much can we=20 > move work around from one topic to another? > Will people work on a document they don't care about? why? >=20 > I hear lots about what documents should be going faster but=20 > what documents should be slowed down? Are there whole WGs or=20 > topics that we should slow down to zero? There is a large=20 > amount of consensus on what document are critical to get done=20 > soon. That's surprising. Why? Can we take advantage of that somehow? >=20 > What's stopping you from getting your drafts done? Is it just=20 > time to work on them? Do you need people to review them? Are=20 > they held up on other work? > What's stopping you from reviewing the drafts you think are=20 > important and sending comments? What's stopping you from=20 > forcing the the drafts you want finished to get done? >=20 > If you logically split some WG in two (trying to logical=20 > group related thing in each halt), then scheduled them=20 > concurrently, would you get twice as much work done or=20 > nothing done because everyone who was not there objected to=20 > any decision made?=20 >=20 > The ADs for the RAI WGs right now are Jon and Allison but=20 > I've certainly been doing a lot of thinking about this. Let=20 > me make a few observations: >=20 > I would want any change to have some reasonably good chance=20 > to make more than a trivial impact. >=20 > Mostly people work on what they want work on - they vote=20 > with their feet. > This is a feature not a bug and much better than the=20 > alternative. People will work on stuff they don't care about=20 > but only to a limited degree. >=20 > Once things get past WGLC, perhaps Chairs and ADs could be=20 > faster but this would not really accelerate things in a huge=20 > way. Still worth working on but less clear it can make a huge impact. >=20 > Having Chairs carefully hound people to work on all the=20 > documents that few people care about might only speed up that=20 > work at the expense of stuff that is critical. I suspect that=20 > for the critical stuff, more hounding is good but there may=20 > be a limit. >=20 > If we think that the sipping chairs are the bottleneck, well=20 > hypothetically, we could add another 5 people to the chair=20 > list. It's an interesting thought experiment to compare this=20 > to adding more groups. I can see several problems with this.=20 > Many of the same problems happen by having more working groups. >=20 > Working groups could have an impact far greater than just=20 > more chairs. They allow us to partition time to certain=20 > classes of problems - effectively one class per working group=20 > - this might help or might not. It might result in a tool to=20 > speed up some classes of problems while slowing down others.=20 > I think it is reasonably clear that XCON and SIMPLE forking=20 > from SIPPING was a good thing. Selecting the right level of=20 > decomposition is always a balancing act.=20 >=20 > If you look at the other IETF directorates, they focus on a=20 > particular problem (such as XML, or MIB doctor) and thus can=20 > have a handful or two of people. What would we want a=20 > directorate here to do? Are we thinking of it as people that=20 > could take on an particular draft and help it accelerate it=20 > getting done? Would a directorate help this? I believe it=20 > might. Jon and I have been talking about this. Could we=20 > achieve the same thing some other ways? Would a directorate=20 > turn into a group that occasionally went for a nice dinner=20 > but did not do much else? I sort of like the directorate idea=20 > but I have just not figured out how to get one or more=20 > directorates focused enough to help.=20 >=20 > I have toyed with the idea of asking everyone to periodically=20 > focus some fraction of their energy on one key draft for a=20 > short period of time and try and get it done. By scheduling=20 > these out in time a bit, we might be able to deal with the=20 > complain of people not being able to schedule time for when=20 > drafts they care about need work. Would this work or be=20 > useless? Would it turn out being more or less the same thing=20 > as WGLC? Should we try and track the expected schedule for=20 > WGLCs across RAI? >=20 > We have some problems where the solution must intrinsically=20 > be entangled across several RAI WGs. Would spending meeting=20 > time in a cross RAI meeting help with these?=20 >=20 > The energy barrier of new work is low. The energy barrier of=20 > finishing even simple work is very high. >=20 > Some of the biggest things I can think of are already=20 > underway. The protos makes it so that chairs can do much of=20 > what only ADs could do previously. > This is good. The formation of RAI allows the ADs to focus more. >=20 > Anyways, don't read too much into anything I said here other=20 > than I'm glad to hear about ideas. In the end, the bulk of=20 > the work is done by volunteers that read drafts, provide=20 > ideas and comments, and write the drafts - it the people that count.=20 >=20 > Cullen >=20 >=20 > On 2/26/06 7:02 PM, "Dolly, Martin C, ALABS" wrote: >=20 > > Hello, > >=20 > > I do not see where further splitting work into new WGs..etc. solves=20 > > any problem. > >=20 > > I believe that "strong" chairing, and a true "democratic" process,=20 > > where not only the voices of the few are heard, will result=20 > in faster results. > >=20 > > Cheers, > >=20 > > Martin > >=20 > >> -----Original Message----- > >> From: James M. Polk [mailto:jmpolk@cisco.com] > >> Sent: Sunday, February 26, 2006 9:15 PM > >> To: Rohan Mahy; Dean Willis > >> Cc: Cullen Jennings; sip@ietf.org List; Sipping List; Jon=20 > Peterson;=20 > >> Allison Mankin > >> Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of=20 > >> Dividingand Conquering > >>=20 > >>=20 > >> Hey > >>=20 > >> While I was the first to comment on Dean's proposal not involving=20 > >> enough groups, and the potential for deviding again, I can see the=20 > >> flip side of this problem being if SIP does exactly what=20 > you suggest=20 > >> here: > >> limited work > >> to 4 or 5 items. > >>=20 > >> The consequences of that action (or inaction) would be to=20 > have *more*=20 > >> SDOs defining extensions to SIP than is already going on. Many=20 > >> people have valid new ideas that are shut/stalled out because it=20 > >> takes so long to get any document done under the best of=20 > >> circumstances. > >>=20 > >> Venture into this scenario: > >>=20 > >> Rohan writes a new ID that has zero resistance > >>=20 > >> Does it become a WG item in the first meeting? > >>=20 > >> yeah - in SIPPING > >>=20 > >> that's 6 months of time with zero resistance > >>=20 > >> In the next meeting it may be moved to SIP for "protocol" > >> work to be done > >>=20 > >> 3 more months, with zero resistance > >>=20 > >> How long does it take the WG to review the ID? > >>=20 > >> No one can tell me reaslistically this happens overnight because=20 > >> everyone has queued the right amount of time to this effort. > >>=20 > >> so it sits 3 more months > >>=20 > >> Is this sip-00 version ready for WGLC? > >>=20 > >> maybe, maybe not > >>=20 > >> Maybe there is one thing that needs to be adjusted > >>=20 > >> 3 more months until the next meeting > >>=20 > >> At the next meeting, *maybe* this ID is ready for WGLC > >>=20 > >> 2 more weeks > >>=20 > >> if this is PS track > >>=20 > >> 2 more weeks for IETF LC > >>=20 > >> it gets to IESG, does it pass the first time? > >>=20 > >> If not, that's 2 more weeks > >>=20 > >> If so, it's 5 months with the RFC-Editor > >>=20 > >> This adds up to roughly 20 months to get one idea through with=20 > >> unrealistically minimal resistance to the idea. > >>=20 > >> I think this WG has more time on its hands to do more work=20 > than 4-5=20 > >> items. > >>=20 > >> If it takes 4 WGs to have faster milestones on the smaller IDs, I=20 > >> think that alone is a great idea. > >>=20 > >> I look forward to a live discussion on this, if it is brought up. > >>=20 > >> What I'm thinking is happening is more and more SDOs are getting=20 > >> tired of the IETF taking so long to get docs out. At some=20 > point they=20 > >> will consider the SIP WG irrelevant and do their own thing. > >>=20 > >> Do we want that? > >>=20 > >> If giving some of the tasks to other WG chairs to relieve you two=20 > >> (Dean and > >> Rohan) to get more work done, even if the same number of=20 > core folks=20 > >> sit in each meeting, then I think it is better to get more=20 > work done=20 > >> with a series of WGs having more milestones to meet=20 > because there are=20 > >> more chairs cracking the whip on authors to get IDs revved and/or=20 > >> reviewed. > >>=20 > >> > >>=20 > >> At 04:06 PM 2/26/2006 -0800, Rohan Mahy wrote: > >>> Hi, > >>>=20 > >>> I don't think further splitting is going to solve our > >> problems due to the > >>> complexity of lateral communication required among groups > >> with this much > >>> in common. > >>>=20 > >>> I do think that a working group that describes use cases for > >> the RAI area > >>> in general could produce some very useful output that has > >> been out of > >>> scope of individual working groups. The SIP NAT scenarios > >> document would > >>> be a good candidate to move into such a WG. > >>>=20 > >>> I think mostly we have a problem saying no. We have too > >> much work to do > >>> and the only effective way for this community to get better > >> throughput is > >>> to focus religiously on a much smaller handful of work items > >> (ex: 4 or 5) > >>> at a time. I am as guilty as the next person for adding new > >> milestones > >>> (actually, more guilty as a chair), but it is hard to say no > >> to new work > >>> when old work that is "almost done" takes so long to finish. > >>>=20 > >>> Perhaps we can have a discussion of this in the RAI area > >> open meeting at > >>> Dallas. It would be nice to hear the new ADs jump in here > >> with their > >>> thoughts. Also, Allison has been wrangling this monster=20 > longer than=20 > >>> anyone except Dean, so I am curious what she has to say. > >>>=20 > >>> thanks, > >>> -rohan > >>>=20 > >>>=20 > >>> On Feb 23, 2006, at 16:30, Dean Willis wrote: > >>>> I've been working on SIP and SIPPING and P2P-SIP agendas > >> this week, and > >>>> that started me thinking. > >>>>=20 > >>>> We spun up SIPPING to take some of the load off of SIP, and > >> in doing so > >>>> tried to more narrowly-define the charters of both SIP=20 > and SIPPING=20 > >>>> relative to the previous SIP charter. > >>>>=20 > >>>> When we started talking about P2P-SIP, we thought about > >> bringing in the > >>>> topic as part of SIPPING, but fairly quickly rejected that > >> idea because > >>>> it was clearly partitionable. > >>>>=20 > >>>> This started me thinking -- could we further apply this > >> principle of > >>>> partitioning? > >>>>=20 > >>>> Both SIP and SIPPING have grown into multi-year monsters, > >> each with large > >>>> charters and the need for multiple long-sessions at each > >> IETF. They're > >>>> tricky to chair, require lots of secretarial work, and are > >> chronically > >>>> late on deliverables (in large part because the chairs are > >> acting like > >>>> ADs instead of chairs). SPPING, once viewed as the kidney > >> of SIP, now > >>>> needs its own dialysis. > >>>>=20 > >>>> Perhaps if we were to split these two working groups into > >> three or four > >>>> working groups that have much more clearly defined missions > >> and scopes, > >>>> we could cut them down to one meeting slot each. And if we > >> were to have > >>>> separate management (chairs and secretaries) for each > >> working group, we > >>>> could better manage the groups to timely delivery. > >>>>=20 > >>>> So I'd like to toss out some ideas on how we might > >> subdivide, and see how > >>>> you folks feel about this. I think the key to any success > >> here would be > >>>> in scope management. > >>>>=20 > >>>> What if we had the following groups: > >>>>=20 > >>>> 1) SIPEM -- SIP Extended Maintenance > >>>>=20 > >>>> 2) SIPNEW -- New major functionality for SIP > >>>>=20 > >>>> 3) SIPREQ -- Analysis of requirements raised by new > >> applications or SDO > >>>> liaison > >>>>=20 > >>>> 4) SIPUSE -- Using SIP to meet specific application requirements > >>>>=20 > >>>>=20 > >>>>=20 > >>>> Here's how we might divide the work: > >>>>=20 > >>>>=20 > >>>> SIPEM > >>>> ----- > >>>>=20 > >>>> Scope: Maintenance of SIP 2.0 and development (as per=20 > RFC 3427) of=20 > >>>> backward-compatible extensions driven by applications with > >> near-term > >>>> deployment scenarios. > >>>>=20 > >>>> Initial Milestone Tasks of SIPEM: > >>>>=20 > >>>> 1) Developing a SIP Guidebook, roughly the equivalent=20 > of the TCP=20 > >>>> Roadmap, that defines what's "in" SIP and how the pieces > >> fit together. > >>>>=20 > >>>> 2) GRUU > >>>>=20 > >>>> 3) Outbound > >>>>=20 > >>>> 4) Target-Dialog > >>>>=20 > >>>> 5) Certificate Usage > >>>>=20 > >>>> 6) Location Transport > >>>>=20 > >>>> 7) Loop Error Correction > >>>>=20 > >>>> 8) Connected Party Identity > >>>>=20 > >>>> 9) Hop Limit Diagnostics > >>>>=20 > >>>> 10) TLS Usage > >>>>=20 > >>>> 11) Answering Modes > >>>>=20 > >>>> 12) Connection Reuse > >>>>=20 > >>>> 13) Rejection of Anonymous Requests > >>>>=20 > >>>> 14) Consent Mechanism > >>>>=20 > >>>>=20 > >>>>=20 > >>>> SIPNEW > >>>> ------ > >>>>=20 > >>>> Scope: Enhancement and evolution of SIP including > >> architectural-level > >>>> requirements and (as per RFC 3427) extensions without > >> requirements for > >>>> backward compatibility. > >>>>=20 > >>>>=20 > >>>> Initial milestone tasks of SIPNEW > >>>>=20 > >>>> 1) Developing a "future roadmap" for the evolution of SIP > >>>>=20 > >>>> 2) Solving the RFC 3261 Routing Problem > >>>>=20 > >>>> 3) Use of SAML with SIP > >>>>=20 > >>>> 4) Response Identity > >>>>=20 > >>>> 5) Response Authentication > >>>>=20 > >>>> 6) End to Middle Requests > >>>>=20 > >>>>=20 > >>>>=20 > >>>> SIPREQ > >>>> ------ > >>>>=20 > >>>> Scope: Analysis of requirements raised by new applications > >> of SIP in IETF > >>>> or in external SDOs (as per RFC 3427). Development of > >> requirements for > >>>> changes to SIP or for usage guides in response to applications=20 > >>>> requirements. Another way of wording this would be "problem > >> definition". > >>>>=20 > >>>> Initial milestones and tasks of SIPREQ: > >>>>=20 > >>>> 1) Session Policy Requirements > >>>>=20 > >>>>=20 > >>>>=20 > >>>> SIPUSE > >>>> ------ > >>>>=20 > >>>> Scope: Guidance on how to use existing SIP specifications > >> and mechanisms > >>>> including examples, call flows, test cases, error > >> avoidance, and so on. > >>>> Review (as per RFC 3427) of SIP Event Packages. > >>>>=20 > >>>>=20 > >>>> Initial milestones and tasks for SIPUSE: > >>>>=20 > >>>> 1) Service Examples > >>>>=20 > >>>> 2) Security Examples > >>>>=20 > >>>> 3) Race Condition Examples > >>>>=20 > >>>> 4) Session media policy mechanism > >>>>=20 > >>>> 5) Session policy package mechanism > >>>>=20 > >>>> 6) Service quality reporting mechanism > >>>>=20 > >>>> 7) URI List mechanism > >>>>=20 > >>>> 8) Subscriptions to Ad-Hoc Resource Lists mechanism > >>>>=20 > >>>> 9) Multiple REFER mechanism > >>>>=20 > >>>> 10) Ad-Hoc Conferencing using URI lists mechanism > >>>>=20 > >>>> 11) Call Control Transfer mechanism > >>>>=20 > >>>> 12) Configuration Delivery mechanism > >>>>=20 > >>>> 13) Emergency Calling using SIP (SOS) mechanism > >>>>=20 > >>>>=20 > >>>>=20 > >>>>=20 > >>>> Note that I'm not entirely happy with the division of > >> SIPPING into SIPUSE > >>>> and SIPREQ. While it seems like we spend a lot of time=20 > in SIPPING=20 > >>>> debating requirements, there are currently a lot of > >> deliverables in this > >>>> category. > >>>>=20 > >>>>=20 > >>>> -- > >>>> Dean > >>>>=20 > >>>> _______________________________________________ > >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>> This list is for NEW development of the core SIP Protocol Use=20 > >>>> 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 > >>> _______________________________________________ > >>> Sipping mailing list =20 > https://www1.ietf.org/mailman/listinfo/sipping > >>> This list is for NEW development of the application of SIP Use=20 > >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>> sip@ietf.org for new developments of core SIP > >>=20 > >> _______________________________________________ > >> Sipping mailing list =20 > https://www1.ietf.org/mailman/listinfo/sipping > >> This list is for NEW development of the application of SIP Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sip@ietf.org for new developments of core SIP > >>=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > 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 sip-bounces@ietf.org Mon Feb 27 14:44:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDoFx-0008TR-E2; Mon, 27 Feb 2006 14:42:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDoFv-0008Sz-16; Mon, 27 Feb 2006 14:42:03 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDoFt-0007eF-Oc; Mon, 27 Feb 2006 14:42:02 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 27 Feb 2006 11:42:03 -0800 X-IronPort-AV: i="4.02,150,1139212800"; d="scan'208"; a="258151063:sNHT37964002" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k1RJfwuh003521; Mon, 27 Feb 2006 11:42:00 -0800 (PST) Received: from 171.68.225.134 ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Mon, 27 Feb 2006 19:41:58 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Mon, 27 Feb 2006 11:41:57 -0800 Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of Dividingand Conquering From: Cullen Jennings To: Dean Willis , Dolly Martin Message-ID: Thread-Topic: [Sipping] Re: [Sip] Thoughts on the Principle of Dividingand Conquering Thread-Index: AcY71d5IHOHjRKfJEdqxOwARJEEJ/A== In-Reply-To: <3B5E51BE-ACE2-40BA-9DE3-6427D91B9116@softarmor.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Rohan Mahy , Jon Peterson , Allison Mankin , "sip@ietf.org" , "James M. Polk" , sipping X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 2/26/06 10:09 PM, "Dean Willis" wrote: > > On Feb 26, 2006, at 9:02 PM, Dolly, Martin C, ALABS wrote: > >> I do not see where further splitting work into new WGs..etc. solves >> any >> problem. > > More chairs, who are better empowered to keep their scopes narrow. > More forceful chairing and supervision. Less groupthink. > Yep - I agree - I tried to hit some of theses points but I guess they did not com across. _______________________________________________ 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 sip-bounces@ietf.org Mon Feb 27 15:13:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDoi8-0003Ss-T4; Mon, 27 Feb 2006 15:11:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDof9-0002jE-7N; Mon, 27 Feb 2006 15:08:07 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDoa6-00082o-Kr; Mon, 27 Feb 2006 15:02:55 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k1RK2lL10874; Mon, 27 Feb 2006 15:02:47 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: [Sipping] Re: [Sip] Thoughts on the Principle ofDividingandConquering Date: Mon, 27 Feb 2006 14:02:45 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Re: [Sip] Thoughts on the Principle ofDividingandConquering Thread-Index: AcY7Q6mOhR2LvnfAR2GcDpXGmRTTDQABZDVQAAcVQBQAGp20wAAB2sUQ From: "Mary Barnes" To: "Michael Hammer \(mhammer\)" , "Cullen Jennings \(fluffy\)" , , "sipping" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ce0328cdf9c90e4680655d09dccace5 Cc: Jon Peterson , Allison Mankin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think this is a reasonable approach. Although, given the amount of work, you might have to do a different draft every two weeks to get things progressed or interleave 2 drafts. And, perhaps, to further expand on this suggestion, each draft should have several people (i.e., dedicated reviewers selected from a pool of volunteers) who have committed (upfront) to providing the necessary feedback. If you can't get that commitment, then you skip the draft straightaway and move on to the next. This certainly would require some housekeeping work by the chairs to keep things going, but with the volume of work, there needs to be a way of forcing attention to work to get it progressed. =20 I still think the directorate concept is also not unreasonable and that after x amount of time spinning in the WG, a draft should go to the directorate (with any known open issues identified). The directorate could decide whether they think the draft in it's current form has any hope - I think one of the problems is that it's hard for the original authors/editor to see cases where significant rethinking might be necessary and again, it's hit or miss whether someone else in the WG takes the time to do this sort of review with the current volume of work. I think catching problems and doing this sort of revie earlier in the cycle might help improve overall quality and speed things up. =20 Mary.=20 -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: Monday, February 27, 2006 1:05 PM To: Cullen Jennings (fluffy); sip@ietf.org; sipping Cc: Jon Peterson; Allison Mankin Subject: RE: [Sipping] Re: [Sip] Thoughts on the Principle ofDividingandConquering Cullen, Your questions echo some that have been bouncing around in my head as well. With so many drafts, I tend to think it is a dilution of focus, where the speed of any one document is progressed at the speed of its share of the groups collective focus. In other words, the collective brain is thrashing from one draft to another. =20 If the chairs could get the group to agree on the prioritized list of drafts (or just make that decision), then have a draft of the month system where the WG focuses on one draft until it is finished. The author should be prepared to update it every workday if needed to keep pace. At the end of the month, it goes to last call. If the author is not prepared, go to end of the queue, or have another author take over. Mike > -----Original Message----- > From: Cullen Jennings (fluffy) > Sent: Monday, February 27, 2006 1:18 AM > To: sip@ietf.org; sipping > Cc: Jon Peterson; Allison Mankin > Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of=20 > DividingandConquering >=20 >=20 > I have written replies to this thread several times - then > deleted them :-) It's a hard topic and certainly one that=20 > Jon, Allison and I were discussing before this thread. We=20 > have talked about it in relation to this thread. We will no=20 > doubt be talking about it for some time to come. Below are=20 > some questions I have been asking myself. They are really a=20 > random stream of conscious. I don't really want answers to=20 > them all but if they trigger some thoughts on concrete ideas=20 > we can that will help. That is great. I am clearly still in=20 > the stage of listening to ideas. >=20 > Are the chairs the bottleneck that limits the rate? Are the > ADs? How can we transfer responsibility from the ADs to chairs? >=20 > Is the bottleneck to do with the rate that authors update > drafts? Is if the bottleneck to do with the rate that=20 > comments are provided on the mailing lists? Can having a=20 > directorate get this done faster? >=20 > Can we expand the amount of total work being done or can we > only move it around? Do we need more people writing the same=20 > number of documents? Can we get new people? How much can we=20 > move work around from one topic to another? > Will people work on a document they don't care about? why? >=20 > I hear lots about what documents should be going faster but > what documents should be slowed down? Are there whole WGs or=20 > topics that we should slow down to zero? There is a large=20 > amount of consensus on what document are critical to get done=20 > soon. That's surprising. Why? Can we take advantage of that somehow? >=20 > What's stopping you from getting your drafts done? Is it just > time to work on them? Do you need people to review them? Are=20 > they held up on other work? > What's stopping you from reviewing the drafts you think are=20 > important and sending comments? What's stopping you from=20 > forcing the the drafts you want finished to get done? >=20 > If you logically split some WG in two (trying to logical > group related thing in each halt), then scheduled them=20 > concurrently, would you get twice as much work done or=20 > nothing done because everyone who was not there objected to=20 > any decision made?=20 >=20 > The ADs for the RAI WGs right now are Jon and Allison but > I've certainly been doing a lot of thinking about this. Let=20 > me make a few observations: >=20 > I would want any change to have some reasonably good chance > to make more than a trivial impact. >=20 > Mostly people work on what they want work on - they vote > with their feet. > This is a feature not a bug and much better than the=20 > alternative. People will work on stuff they don't care about=20 > but only to a limited degree. >=20 > Once things get past WGLC, perhaps Chairs and ADs could be > faster but this would not really accelerate things in a huge=20 > way. Still worth working on but less clear it can make a huge impact. >=20 > Having Chairs carefully hound people to work on all the > documents that few people care about might only speed up that=20 > work at the expense of stuff that is critical. I suspect that=20 > for the critical stuff, more hounding is good but there may=20 > be a limit. >=20 > If we think that the sipping chairs are the bottleneck, well > hypothetically, we could add another 5 people to the chair=20 > list. It's an interesting thought experiment to compare this=20 > to adding more groups. I can see several problems with this.=20 > Many of the same problems happen by having more working groups. >=20 > Working groups could have an impact far greater than just > more chairs. They allow us to partition time to certain=20 > classes of problems - effectively one class per working group=20 > - this might help or might not. It might result in a tool to=20 > speed up some classes of problems while slowing down others.=20 > I think it is reasonably clear that XCON and SIMPLE forking=20 > from SIPPING was a good thing. Selecting the right level of=20 > decomposition is always a balancing act.=20 >=20 > If you look at the other IETF directorates, they focus on a > particular problem (such as XML, or MIB doctor) and thus can=20 > have a handful or two of people. What would we want a=20 > directorate here to do? Are we thinking of it as people that=20 > could take on an particular draft and help it accelerate it=20 > getting done? Would a directorate help this? I believe it=20 > might. Jon and I have been talking about this. Could we=20 > achieve the same thing some other ways? Would a directorate=20 > turn into a group that occasionally went for a nice dinner=20 > but did not do much else? I sort of like the directorate idea=20 > but I have just not figured out how to get one or more=20 > directorates focused enough to help.=20 >=20 > I have toyed with the idea of asking everyone to periodically > focus some fraction of their energy on one key draft for a=20 > short period of time and try and get it done. By scheduling=20 > these out in time a bit, we might be able to deal with the=20 > complain of people not being able to schedule time for when=20 > drafts they care about need work. Would this work or be=20 > useless? Would it turn out being more or less the same thing=20 > as WGLC? Should we try and track the expected schedule for=20 > WGLCs across RAI? >=20 > We have some problems where the solution must intrinsically > be entangled across several RAI WGs. Would spending meeting=20 > time in a cross RAI meeting help with these?=20 >=20 > The energy barrier of new work is low. The energy barrier of > finishing even simple work is very high. >=20 > Some of the biggest things I can think of are already > underway. The protos makes it so that chairs can do much of=20 > what only ADs could do previously. > This is good. The formation of RAI allows the ADs to focus more. >=20 > Anyways, don't read too much into anything I said here other > than I'm glad to hear about ideas. In the end, the bulk of=20 > the work is done by volunteers that read drafts, provide=20 > ideas and comments, and write the drafts - it the people that count.=20 >=20 > Cullen >=20 >=20 > On 2/26/06 7:02 PM, "Dolly, Martin C, ALABS" wrote: >=20 > > Hello, > >=20 > > I do not see where further splitting work into new WGs..etc. solves > > any problem. > >=20 > > I believe that "strong" chairing, and a true "democratic" process, > > where not only the voices of the few are heard, will result=20 > in faster results. > >=20 > > Cheers, > >=20 > > Martin > >=20 > >> -----Original Message----- > >> From: James M. Polk [mailto:jmpolk@cisco.com] > >> Sent: Sunday, February 26, 2006 9:15 PM > >> To: Rohan Mahy; Dean Willis > >> Cc: Cullen Jennings; sip@ietf.org List; Sipping List; Jon > Peterson; > >> Allison Mankin > >> Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of > >> Dividingand Conquering > >>=20 > >>=20 > >> Hey > >>=20 > >> While I was the first to comment on Dean's proposal not involving > >> enough groups, and the potential for deviding again, I can see the=20 > >> flip side of this problem being if SIP does exactly what=20 > you suggest > >> here: > >> limited work > >> to 4 or 5 items. > >>=20 > >> The consequences of that action (or inaction) would be to > have *more* > >> SDOs defining extensions to SIP than is already going on. Many > >> people have valid new ideas that are shut/stalled out because it=20 > >> takes so long to get any document done under the best of=20 > >> circumstances. > >>=20 > >> Venture into this scenario: > >>=20 > >> Rohan writes a new ID that has zero resistance > >>=20 > >> Does it become a WG item in the first meeting? > >>=20 > >> yeah - in SIPPING > >>=20 > >> that's 6 months of time with zero resistance > >>=20 > >> In the next meeting it may be moved to SIP for "protocol" work to=20 > >> be done > >>=20 > >> 3 more months, with zero resistance > >>=20 > >> How long does it take the WG to review the ID? > >>=20 > >> No one can tell me reaslistically this happens overnight because > >> everyone has queued the right amount of time to this effort. > >>=20 > >> so it sits 3 more months > >>=20 > >> Is this sip-00 version ready for WGLC? > >>=20 > >> maybe, maybe not > >>=20 > >> Maybe there is one thing that needs to be adjusted > >>=20 > >> 3 more months until the next meeting > >>=20 > >> At the next meeting, *maybe* this ID is ready for WGLC > >>=20 > >> 2 more weeks > >>=20 > >> if this is PS track > >>=20 > >> 2 more weeks for IETF LC > >>=20 > >> it gets to IESG, does it pass the first time? > >>=20 > >> If not, that's 2 more weeks > >>=20 > >> If so, it's 5 months with the RFC-Editor > >>=20 > >> This adds up to roughly 20 months to get one idea through with > >> unrealistically minimal resistance to the idea. > >>=20 > >> I think this WG has more time on its hands to do more work > than 4-5 > >> items. > >>=20 > >> If it takes 4 WGs to have faster milestones on the smaller IDs, I > >> think that alone is a great idea. > >>=20 > >> I look forward to a live discussion on this, if it is brought up. > >>=20 > >> What I'm thinking is happening is more and more SDOs are getting > >> tired of the IETF taking so long to get docs out. At some=20 > point they > >> will consider the SIP WG irrelevant and do their own thing. > >>=20 > >> Do we want that? > >>=20 > >> If giving some of the tasks to other WG chairs to relieve you two > >> (Dean and > >> Rohan) to get more work done, even if the same number of=20 > core folks > >> sit in each meeting, then I think it is better to get more > work done > >> with a series of WGs having more milestones to meet > because there are > >> more chairs cracking the whip on authors to get IDs revved and/or > >> reviewed. > >>=20 > >> > >>=20 > >> At 04:06 PM 2/26/2006 -0800, Rohan Mahy wrote: > >>> Hi, > >>>=20 > >>> I don't think further splitting is going to solve our > >> problems due to the > >>> complexity of lateral communication required among groups > >> with this much > >>> in common. > >>>=20 > >>> I do think that a working group that describes use cases for > >> the RAI area > >>> in general could produce some very useful output that has > >> been out of > >>> scope of individual working groups. The SIP NAT scenarios > >> document would > >>> be a good candidate to move into such a WG. > >>>=20 > >>> I think mostly we have a problem saying no. We have too > >> much work to do > >>> and the only effective way for this community to get better > >> throughput is > >>> to focus religiously on a much smaller handful of work items > >> (ex: 4 or 5) > >>> at a time. I am as guilty as the next person for adding new > >> milestones > >>> (actually, more guilty as a chair), but it is hard to say no > >> to new work > >>> when old work that is "almost done" takes so long to finish. > >>>=20 > >>> Perhaps we can have a discussion of this in the RAI area > >> open meeting at > >>> Dallas. It would be nice to hear the new ADs jump in here > >> with their > >>> thoughts. Also, Allison has been wrangling this monster > longer than > >>> anyone except Dean, so I am curious what she has to say. > >>>=20 > >>> thanks, > >>> -rohan > >>>=20 > >>>=20 > >>> On Feb 23, 2006, at 16:30, Dean Willis wrote: > >>>> I've been working on SIP and SIPPING and P2P-SIP agendas > >> this week, and > >>>> that started me thinking. > >>>>=20 > >>>> We spun up SIPPING to take some of the load off of SIP, and > >> in doing so > >>>> tried to more narrowly-define the charters of both SIP > and SIPPING > >>>> relative to the previous SIP charter. > >>>>=20 > >>>> When we started talking about P2P-SIP, we thought about > >> bringing in the > >>>> topic as part of SIPPING, but fairly quickly rejected that > >> idea because > >>>> it was clearly partitionable. > >>>>=20 > >>>> This started me thinking -- could we further apply this > >> principle of > >>>> partitioning? > >>>>=20 > >>>> Both SIP and SIPPING have grown into multi-year monsters, > >> each with large > >>>> charters and the need for multiple long-sessions at each > >> IETF. They're > >>>> tricky to chair, require lots of secretarial work, and are > >> chronically > >>>> late on deliverables (in large part because the chairs are > >> acting like > >>>> ADs instead of chairs). SPPING, once viewed as the kidney > >> of SIP, now > >>>> needs its own dialysis. > >>>>=20 > >>>> Perhaps if we were to split these two working groups into > >> three or four > >>>> working groups that have much more clearly defined missions > >> and scopes, > >>>> we could cut them down to one meeting slot each. And if we > >> were to have > >>>> separate management (chairs and secretaries) for each > >> working group, we > >>>> could better manage the groups to timely delivery. > >>>>=20 > >>>> So I'd like to toss out some ideas on how we might > >> subdivide, and see how > >>>> you folks feel about this. I think the key to any success > >> here would be > >>>> in scope management. > >>>>=20 > >>>> What if we had the following groups: > >>>>=20 > >>>> 1) SIPEM -- SIP Extended Maintenance > >>>>=20 > >>>> 2) SIPNEW -- New major functionality for SIP > >>>>=20 > >>>> 3) SIPREQ -- Analysis of requirements raised by new > >> applications or SDO > >>>> liaison > >>>>=20 > >>>> 4) SIPUSE -- Using SIP to meet specific application requirements > >>>>=20 > >>>>=20 > >>>>=20 > >>>> Here's how we might divide the work: > >>>>=20 > >>>>=20 > >>>> SIPEM > >>>> ----- > >>>>=20 > >>>> Scope: Maintenance of SIP 2.0 and development (as per > RFC 3427) of > >>>> backward-compatible extensions driven by applications with > >> near-term > >>>> deployment scenarios. > >>>>=20 > >>>> Initial Milestone Tasks of SIPEM: > >>>>=20 > >>>> 1) Developing a SIP Guidebook, roughly the equivalent > of the TCP > >>>> Roadmap, that defines what's "in" SIP and how the pieces > >> fit together. > >>>>=20 > >>>> 2) GRUU > >>>>=20 > >>>> 3) Outbound > >>>>=20 > >>>> 4) Target-Dialog > >>>>=20 > >>>> 5) Certificate Usage > >>>>=20 > >>>> 6) Location Transport > >>>>=20 > >>>> 7) Loop Error Correction > >>>>=20 > >>>> 8) Connected Party Identity > >>>>=20 > >>>> 9) Hop Limit Diagnostics > >>>>=20 > >>>> 10) TLS Usage > >>>>=20 > >>>> 11) Answering Modes > >>>>=20 > >>>> 12) Connection Reuse > >>>>=20 > >>>> 13) Rejection of Anonymous Requests > >>>>=20 > >>>> 14) Consent Mechanism > >>>>=20 > >>>>=20 > >>>>=20 > >>>> SIPNEW > >>>> ------ > >>>>=20 > >>>> Scope: Enhancement and evolution of SIP including > >> architectural-level > >>>> requirements and (as per RFC 3427) extensions without > >> requirements for > >>>> backward compatibility. > >>>>=20 > >>>>=20 > >>>> Initial milestone tasks of SIPNEW > >>>>=20 > >>>> 1) Developing a "future roadmap" for the evolution of SIP > >>>>=20 > >>>> 2) Solving the RFC 3261 Routing Problem > >>>>=20 > >>>> 3) Use of SAML with SIP > >>>>=20 > >>>> 4) Response Identity > >>>>=20 > >>>> 5) Response Authentication > >>>>=20 > >>>> 6) End to Middle Requests > >>>>=20 > >>>>=20 > >>>>=20 > >>>> SIPREQ > >>>> ------ > >>>>=20 > >>>> Scope: Analysis of requirements raised by new applications > >> of SIP in IETF > >>>> or in external SDOs (as per RFC 3427). Development of > >> requirements for > >>>> changes to SIP or for usage guides in response to applications > >>>> requirements. Another way of wording this would be "problem > >> definition". > >>>>=20 > >>>> Initial milestones and tasks of SIPREQ: > >>>>=20 > >>>> 1) Session Policy Requirements > >>>>=20 > >>>>=20 > >>>>=20 > >>>> SIPUSE > >>>> ------ > >>>>=20 > >>>> Scope: Guidance on how to use existing SIP specifications > >> and mechanisms > >>>> including examples, call flows, test cases, error > >> avoidance, and so on. > >>>> Review (as per RFC 3427) of SIP Event Packages. > >>>>=20 > >>>>=20 > >>>> Initial milestones and tasks for SIPUSE: > >>>>=20 > >>>> 1) Service Examples > >>>>=20 > >>>> 2) Security Examples > >>>>=20 > >>>> 3) Race Condition Examples > >>>>=20 > >>>> 4) Session media policy mechanism > >>>>=20 > >>>> 5) Session policy package mechanism > >>>>=20 > >>>> 6) Service quality reporting mechanism > >>>>=20 > >>>> 7) URI List mechanism > >>>>=20 > >>>> 8) Subscriptions to Ad-Hoc Resource Lists mechanism > >>>>=20 > >>>> 9) Multiple REFER mechanism > >>>>=20 > >>>> 10) Ad-Hoc Conferencing using URI lists mechanism > >>>>=20 > >>>> 11) Call Control Transfer mechanism > >>>>=20 > >>>> 12) Configuration Delivery mechanism > >>>>=20 > >>>> 13) Emergency Calling using SIP (SOS) mechanism > >>>>=20 > >>>>=20 > >>>>=20 > >>>>=20 > >>>> Note that I'm not entirely happy with the division of > >> SIPPING into SIPUSE > >>>> and SIPREQ. While it seems like we spend a lot of time > in SIPPING > >>>> debating requirements, there are currently a lot of > >> deliverables in this > >>>> category. > >>>>=20 > >>>>=20 > >>>> -- > >>>> Dean > >>>>=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 > >>>> sipping@ietf.org for new developments on the application of sip > >>>=20 > >>>=20 > >>> _______________________________________________ > >>> Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > >>> This list is for NEW development of the application of SIP Use > >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>> sip@ietf.org for new developments of core SIP > >>=20 > >> _______________________________________________ > >> Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > >> This list is for NEW development of the application of SIP Use > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sip@ietf.org for new developments of core SIP > >>=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=20 > 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 _______________________________________________ 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 sip-bounces@ietf.org Mon Feb 27 16:32:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDpwj-00086M-Fb; Mon, 27 Feb 2006 16:30:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDpwh-00084Y-Cc for sip@ietf.org; Mon, 27 Feb 2006 16:30:19 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDpwf-00070m-1V for sip@ietf.org; Mon, 27 Feb 2006 16:30:19 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 27 Feb 2006 13:30:17 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,150,1139212800"; d="scan'208"; a="22687982:sNHT23827796" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1RLUGjJ007452; Mon, 27 Feb 2006 16:30:16 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Feb 2006 16:30:16 -0500 Received: from [161.44.79.183] ([161.44.79.183]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Feb 2006 16:30:15 -0500 Message-ID: <44036F67.8090106@cisco.com> Date: Mon, 27 Feb 2006 16:30:15 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] Questions on subscription dialogs References: <5EB80D22825EEE42872083AD5BFFB5945D1AAC@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1AAC@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Feb 2006 21:30:15.0939 (UTC) FILETIME=[FFF3D530:01C63BE4] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer - see comments inline. Christer Holmberg (JO/LMF) wrote: > Hi, > > A few questions on subscription dialogs. > > Q1: Is it allowed to send non-NOTIFY request within a subscription > dialog (initiated by SUBSCRIBE), assuming the users support it? Yes, with limits. In general, a request that is legal outside a dialog is also legal within a dialog. (E.g. OPTIONS.) In some cases (e.g. MESSAGE) other limitations have been applied. (You aren't supposed to use MESSAGE within a dialog as a way to avoid session mode messaging.) It is legal, though generally discouraged, to send requests within an existing dialog that establish a new dialog usage. Sending an INVITE within a dialog established by a SUBSCRIBE falls into this category. > Q2: If Q1==TRUE, is it allowed to add media during a subscription > dialog, by sending an SDP offer in an UPDATE/re-INVITE? An INVITE in this case (at least the first one) would not be a reINVITE. It would establish a new invite dialog usage within an already established dialog. IMO an UPDATE is only permitted within an existing invite dialog usage. So you would have to send an INVITE to establish the usage before you could use UPDATE to do a subsequent offer/answer. > Q3: If Q2==TRUE, is it allowed to use re-INVITE, eventhough the dialog > was not initiated using INVITE? See above. Beware that I have heard of no implementation that actually support this. > Q4: If Q1==TRUE, if I send an empty re-INVITE within a subscription > dialog, e.g. to update the remote target, I assume the receiver MUST > create and include an SDP offer in the 200 OK response, eventhough no > media has previously been used within the dialog? Again see above. The invite must follow all the normal rules. Note that as defined, all the usages of the dialog share the same targets. If you have a dialog shared by an invite usage and a subscribe usage, then either a reinvite or a resubscribe will update the target they share in common. If you have just a subscription, and what to change the target, you can use a resubscribe. No need to use UPDATE or INVITE to accomplish that. Paul > Regards, > > Christer > > _______________________________________________ > 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 sip-bounces@ietf.org Mon Feb 27 16:43:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDq7n-0006tn-QH; Mon, 27 Feb 2006 16:41:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDq7k-0006sH-N5; Mon, 27 Feb 2006 16:41:44 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDq7j-0007Rm-PL; Mon, 27 Feb 2006 16:41:44 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 27 Feb 2006 13:41:43 -0800 X-IronPort-AV: i="4.02,150,1139212800"; d="scan'208"; a="1780170455:sNHT51616962" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1RLfgHf008603; Mon, 27 Feb 2006 13:41:42 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Feb 2006 16:41:42 -0500 Received: from [161.44.79.183] ([161.44.79.183]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Feb 2006 16:41:41 -0500 Message-ID: <44037215.1030601@cisco.com> Date: Mon, 27 Feb 2006 16:41:41 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of DividingandConquering References: <072C5B76F7CEAB488172C6F64B30B5E301245A9E@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301245A9E@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Feb 2006 21:41:41.0720 (UTC) FILETIME=[98B5B580:01C63BE6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 04ebe73024b6be81174765e91aced811 Cc: "Cullen Jennings \(fluffy\)" , sip@ietf.org, sipping , Jon Peterson , Allison Mankin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I like this idea. I think it probably need fine tuning regarding the number of drafts that can be worked in parallel this way, exactly what the timers are (frequency of updates, how long allowed to converge, etc.) but the general concept of scheduling things like this sounds good to me. Given people's availability, it might need more than a queue - rather a schedule with a queue governing who is allowed to bid for a slot in the schedule. Paul Michael Hammer (mhammer) wrote: > Cullen, > > Your questions echo some that have been bouncing around in my head as > well. With so many drafts, I tend to think it is a dilution of focus, > where the speed of any one document is progressed at the speed of its > share of the groups collective focus. In other words, the collective > brain is thrashing from one draft to another. > > If the chairs could get the group to agree on the prioritized list of > drafts (or just make that decision), then have a draft of the month > system where the WG focuses on one draft until it is finished. The > author should be prepared to update it every workday if needed to keep > pace. At the end of the month, it goes to last call. If the author is > not prepared, go to end of the queue, or have another author take over. > > Mike > > > >>-----Original Message----- >>From: Cullen Jennings (fluffy) >>Sent: Monday, February 27, 2006 1:18 AM >>To: sip@ietf.org; sipping >>Cc: Jon Peterson; Allison Mankin >>Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of >>DividingandConquering >> >> >>I have written replies to this thread several times - then >>deleted them :-) It's a hard topic and certainly one that >>Jon, Allison and I were discussing before this thread. We >>have talked about it in relation to this thread. We will no >>doubt be talking about it for some time to come. Below are >>some questions I have been asking myself. They are really a >>random stream of conscious. I don't really want answers to >>them all but if they trigger some thoughts on concrete ideas >>we can that will help. That is great. I am clearly still in >>the stage of listening to ideas. >> >>Are the chairs the bottleneck that limits the rate? Are the >>ADs? How can we transfer responsibility from the ADs to chairs? >> >>Is the bottleneck to do with the rate that authors update >>drafts? Is if the bottleneck to do with the rate that >>comments are provided on the mailing lists? Can having a >>directorate get this done faster? >> >>Can we expand the amount of total work being done or can we >>only move it around? Do we need more people writing the same >>number of documents? Can we get new people? How much can we >>move work around from one topic to another? >>Will people work on a document they don't care about? why? >> >>I hear lots about what documents should be going faster but >>what documents should be slowed down? Are there whole WGs or >>topics that we should slow down to zero? There is a large >>amount of consensus on what document are critical to get done >>soon. That's surprising. Why? Can we take advantage of that somehow? >> >>What's stopping you from getting your drafts done? Is it just >>time to work on them? Do you need people to review them? Are >>they held up on other work? >>What's stopping you from reviewing the drafts you think are >>important and sending comments? What's stopping you from >>forcing the the drafts you want finished to get done? >> >>If you logically split some WG in two (trying to logical >>group related thing in each halt), then scheduled them >>concurrently, would you get twice as much work done or >>nothing done because everyone who was not there objected to >>any decision made? >> >>The ADs for the RAI WGs right now are Jon and Allison but >>I've certainly been doing a lot of thinking about this. Let >>me make a few observations: >> >>I would want any change to have some reasonably good chance >>to make more than a trivial impact. >> >>Mostly people work on what they want work on - they vote >>with their feet. >>This is a feature not a bug and much better than the >>alternative. People will work on stuff they don't care about >>but only to a limited degree. >> >>Once things get past WGLC, perhaps Chairs and ADs could be >>faster but this would not really accelerate things in a huge >>way. Still worth working on but less clear it can make a huge impact. >> >>Having Chairs carefully hound people to work on all the >>documents that few people care about might only speed up that >>work at the expense of stuff that is critical. I suspect that >>for the critical stuff, more hounding is good but there may >>be a limit. >> >>If we think that the sipping chairs are the bottleneck, well >>hypothetically, we could add another 5 people to the chair >>list. It's an interesting thought experiment to compare this >>to adding more groups. I can see several problems with this. >>Many of the same problems happen by having more working groups. >> >>Working groups could have an impact far greater than just >>more chairs. They allow us to partition time to certain >>classes of problems - effectively one class per working group >>- this might help or might not. It might result in a tool to >>speed up some classes of problems while slowing down others. >>I think it is reasonably clear that XCON and SIMPLE forking >>from SIPPING was a good thing. Selecting the right level of >>decomposition is always a balancing act. >> >>If you look at the other IETF directorates, they focus on a >>particular problem (such as XML, or MIB doctor) and thus can >>have a handful or two of people. What would we want a >>directorate here to do? Are we thinking of it as people that >>could take on an particular draft and help it accelerate it >>getting done? Would a directorate help this? I believe it >>might. Jon and I have been talking about this. Could we >>achieve the same thing some other ways? Would a directorate >>turn into a group that occasionally went for a nice dinner >>but did not do much else? I sort of like the directorate idea >>but I have just not figured out how to get one or more >>directorates focused enough to help. >> >>I have toyed with the idea of asking everyone to periodically >>focus some fraction of their energy on one key draft for a >>short period of time and try and get it done. By scheduling >>these out in time a bit, we might be able to deal with the >>complain of people not being able to schedule time for when >>drafts they care about need work. Would this work or be >>useless? Would it turn out being more or less the same thing >>as WGLC? Should we try and track the expected schedule for >>WGLCs across RAI? >> >>We have some problems where the solution must intrinsically >>be entangled across several RAI WGs. Would spending meeting >>time in a cross RAI meeting help with these? >> >>The energy barrier of new work is low. The energy barrier of >>finishing even simple work is very high. >> >>Some of the biggest things I can think of are already >>underway. The protos makes it so that chairs can do much of >>what only ADs could do previously. >>This is good. The formation of RAI allows the ADs to focus more. >> >>Anyways, don't read too much into anything I said here other >>than I'm glad to hear about ideas. In the end, the bulk of >>the work is done by volunteers that read drafts, provide >>ideas and comments, and write the drafts - it the people that count. >> >>Cullen >> >> >>On 2/26/06 7:02 PM, "Dolly, Martin C, ALABS" wrote: >> >> >>>Hello, >>> >>>I do not see where further splitting work into new WGs..etc. solves >>>any problem. >>> >>>I believe that "strong" chairing, and a true "democratic" process, >>>where not only the voices of the few are heard, will result >> >>in faster results. >> >>>Cheers, >>> >>>Martin >>> >>> >>>>-----Original Message----- >>>>From: James M. Polk [mailto:jmpolk@cisco.com] >>>>Sent: Sunday, February 26, 2006 9:15 PM >>>>To: Rohan Mahy; Dean Willis >>>>Cc: Cullen Jennings; sip@ietf.org List; Sipping List; Jon >> >>Peterson; >> >>>>Allison Mankin >>>>Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of >>>>Dividingand Conquering >>>> >>>> >>>>Hey >>>> >>>>While I was the first to comment on Dean's proposal not involving >>>>enough groups, and the potential for deviding again, I can see the >>>>flip side of this problem being if SIP does exactly what >> >>you suggest >> >>>>here: >>>>limited work >>>>to 4 or 5 items. >>>> >>>>The consequences of that action (or inaction) would be to >> >>have *more* >> >>>>SDOs defining extensions to SIP than is already going on. Many >>>>people have valid new ideas that are shut/stalled out because it >>>>takes so long to get any document done under the best of >>>>circumstances. >>>> >>>>Venture into this scenario: >>>> >>>>Rohan writes a new ID that has zero resistance >>>> >>>>Does it become a WG item in the first meeting? >>>> >>>>yeah - in SIPPING >>>> >>>> that's 6 months of time with zero resistance >>>> >>>>In the next meeting it may be moved to SIP for "protocol" >>>>work to be done >>>> >>>> 3 more months, with zero resistance >>>> >>>>How long does it take the WG to review the ID? >>>> >>>>No one can tell me reaslistically this happens overnight because >>>>everyone has queued the right amount of time to this effort. >>>> >>>> so it sits 3 more months >>>> >>>>Is this sip-00 version ready for WGLC? >>>> >>>>maybe, maybe not >>>> >>>>Maybe there is one thing that needs to be adjusted >>>> >>>> 3 more months until the next meeting >>>> >>>>At the next meeting, *maybe* this ID is ready for WGLC >>>> >>>> 2 more weeks >>>> >>>>if this is PS track >>>> >>>> 2 more weeks for IETF LC >>>> >>>>it gets to IESG, does it pass the first time? >>>> >>>> If not, that's 2 more weeks >>>> >>>>If so, it's 5 months with the RFC-Editor >>>> >>>>This adds up to roughly 20 months to get one idea through with >>>>unrealistically minimal resistance to the idea. >>>> >>>>I think this WG has more time on its hands to do more work >> >>than 4-5 >> >>>>items. >>>> >>>>If it takes 4 WGs to have faster milestones on the smaller IDs, I >>>>think that alone is a great idea. >>>> >>>>I look forward to a live discussion on this, if it is brought up. >>>> >>>>What I'm thinking is happening is more and more SDOs are getting >>>>tired of the IETF taking so long to get docs out. At some >> >>point they >> >>>>will consider the SIP WG irrelevant and do their own thing. >>>> >>>>Do we want that? >>>> >>>>If giving some of the tasks to other WG chairs to relieve you two >>>>(Dean and >>>>Rohan) to get more work done, even if the same number of >> >>core folks >> >>>>sit in each meeting, then I think it is better to get more >> >>work done >> >>>>with a series of WGs having more milestones to meet >> >>because there are >> >>>>more chairs cracking the whip on authors to get IDs revved and/or >>>>reviewed. >>>> >>>> >>>> >>>>At 04:06 PM 2/26/2006 -0800, Rohan Mahy wrote: >>>> >>>>>Hi, >>>>> >>>>>I don't think further splitting is going to solve our >>>> >>>>problems due to the >>>> >>>>>complexity of lateral communication required among groups >>>> >>>>with this much >>>> >>>>>in common. >>>>> >>>>>I do think that a working group that describes use cases for >>>> >>>>the RAI area >>>> >>>>>in general could produce some very useful output that has >>>> >>>>been out of >>>> >>>>>scope of individual working groups. The SIP NAT scenarios >>>> >>>>document would >>>> >>>>>be a good candidate to move into such a WG. >>>>> >>>>>I think mostly we have a problem saying no. We have too >>>> >>>>much work to do >>>> >>>>>and the only effective way for this community to get better >>>> >>>>throughput is >>>> >>>>>to focus religiously on a much smaller handful of work items >>>> >>>>(ex: 4 or 5) >>>> >>>>>at a time. I am as guilty as the next person for adding new >>>> >>>>milestones >>>> >>>>>(actually, more guilty as a chair), but it is hard to say no >>>> >>>>to new work >>>> >>>>>when old work that is "almost done" takes so long to finish. >>>>> >>>>>Perhaps we can have a discussion of this in the RAI area >>>> >>>>open meeting at >>>> >>>>>Dallas. It would be nice to hear the new ADs jump in here >>>> >>>>with their >>>> >>>>>thoughts. Also, Allison has been wrangling this monster >> >>longer than >> >>>>>anyone except Dean, so I am curious what she has to say. >>>>> >>>>>thanks, >>>>>-rohan >>>>> >>>>> >>>>>On Feb 23, 2006, at 16:30, Dean Willis wrote: >>>>> >>>>>>I've been working on SIP and SIPPING and P2P-SIP agendas >>>> >>>>this week, and >>>> >>>>>>that started me thinking. >>>>>> >>>>>>We spun up SIPPING to take some of the load off of SIP, and >>>> >>>>in doing so >>>> >>>>>>tried to more narrowly-define the charters of both SIP >> >>and SIPPING >> >>>>>>relative to the previous SIP charter. >>>>>> >>>>>>When we started talking about P2P-SIP, we thought about >>>> >>>>bringing in the >>>> >>>>>>topic as part of SIPPING, but fairly quickly rejected that >>>> >>>>idea because >>>> >>>>>>it was clearly partitionable. >>>>>> >>>>>>This started me thinking -- could we further apply this >>>> >>>>principle of >>>> >>>>>>partitioning? >>>>>> >>>>>>Both SIP and SIPPING have grown into multi-year monsters, >>>> >>>>each with large >>>> >>>>>>charters and the need for multiple long-sessions at each >>>> >>>>IETF. They're >>>> >>>>>>tricky to chair, require lots of secretarial work, and are >>>> >>>>chronically >>>> >>>>>>late on deliverables (in large part because the chairs are >>>> >>>>acting like >>>> >>>>>>ADs instead of chairs). SPPING, once viewed as the kidney >>>> >>>>of SIP, now >>>> >>>>>>needs its own dialysis. >>>>>> >>>>>>Perhaps if we were to split these two working groups into >>>> >>>>three or four >>>> >>>>>>working groups that have much more clearly defined missions >>>> >>>>and scopes, >>>> >>>>>>we could cut them down to one meeting slot each. And if we >>>> >>>>were to have >>>> >>>>>>separate management (chairs and secretaries) for each >>>> >>>>working group, we >>>> >>>>>>could better manage the groups to timely delivery. >>>>>> >>>>>>So I'd like to toss out some ideas on how we might >>>> >>>>subdivide, and see how >>>> >>>>>>you folks feel about this. I think the key to any success >>>> >>>>here would be >>>> >>>>>>in scope management. >>>>>> >>>>>>What if we had the following groups: >>>>>> >>>>>>1) SIPEM -- SIP Extended Maintenance >>>>>> >>>>>>2) SIPNEW -- New major functionality for SIP >>>>>> >>>>>>3) SIPREQ -- Analysis of requirements raised by new >>>> >>>>applications or SDO >>>> >>>>>>liaison >>>>>> >>>>>>4) SIPUSE -- Using SIP to meet specific application requirements >>>>>> >>>>>> >>>>>> >>>>>>Here's how we might divide the work: >>>>>> >>>>>> >>>>>>SIPEM >>>>>>----- >>>>>> >>>>>>Scope: Maintenance of SIP 2.0 and development (as per >> >>RFC 3427) of >> >>>>>>backward-compatible extensions driven by applications with >>>> >>>>near-term >>>> >>>>>>deployment scenarios. >>>>>> >>>>>>Initial Milestone Tasks of SIPEM: >>>>>> >>>>>>1) Developing a SIP Guidebook, roughly the equivalent >> >>of the TCP >> >>>>>>Roadmap, that defines what's "in" SIP and how the pieces >>>> >>>>fit together. >>>> >>>>>>2) GRUU >>>>>> >>>>>>3) Outbound >>>>>> >>>>>>4) Target-Dialog >>>>>> >>>>>>5) Certificate Usage >>>>>> >>>>>>6) Location Transport >>>>>> >>>>>>7) Loop Error Correction >>>>>> >>>>>>8) Connected Party Identity >>>>>> >>>>>>9) Hop Limit Diagnostics >>>>>> >>>>>>10) TLS Usage >>>>>> >>>>>>11) Answering Modes >>>>>> >>>>>>12) Connection Reuse >>>>>> >>>>>>13) Rejection of Anonymous Requests >>>>>> >>>>>>14) Consent Mechanism >>>>>> >>>>>> >>>>>> >>>>>>SIPNEW >>>>>>------ >>>>>> >>>>>>Scope: Enhancement and evolution of SIP including >>>> >>>>architectural-level >>>> >>>>>>requirements and (as per RFC 3427) extensions without >>>> >>>>requirements for >>>> >>>>>>backward compatibility. >>>>>> >>>>>> >>>>>>Initial milestone tasks of SIPNEW >>>>>> >>>>>>1) Developing a "future roadmap" for the evolution of SIP >>>>>> >>>>>>2) Solving the RFC 3261 Routing Problem >>>>>> >>>>>>3) Use of SAML with SIP >>>>>> >>>>>>4) Response Identity >>>>>> >>>>>>5) Response Authentication >>>>>> >>>>>>6) End to Middle Requests >>>>>> >>>>>> >>>>>> >>>>>>SIPREQ >>>>>>------ >>>>>> >>>>>>Scope: Analysis of requirements raised by new applications >>>> >>>>of SIP in IETF >>>> >>>>>>or in external SDOs (as per RFC 3427). Development of >>>> >>>>requirements for >>>> >>>>>>changes to SIP or for usage guides in response to applications >>>>>>requirements. Another way of wording this would be "problem >>>> >>>>definition". >>>> >>>>>>Initial milestones and tasks of SIPREQ: >>>>>> >>>>>>1) Session Policy Requirements >>>>>> >>>>>> >>>>>> >>>>>>SIPUSE >>>>>>------ >>>>>> >>>>>>Scope: Guidance on how to use existing SIP specifications >>>> >>>>and mechanisms >>>> >>>>>>including examples, call flows, test cases, error >>>> >>>>avoidance, and so on. >>>> >>>>>>Review (as per RFC 3427) of SIP Event Packages. >>>>>> >>>>>> >>>>>>Initial milestones and tasks for SIPUSE: >>>>>> >>>>>>1) Service Examples >>>>>> >>>>>>2) Security Examples >>>>>> >>>>>>3) Race Condition Examples >>>>>> >>>>>>4) Session media policy mechanism >>>>>> >>>>>>5) Session policy package mechanism >>>>>> >>>>>>6) Service quality reporting mechanism >>>>>> >>>>>>7) URI List mechanism >>>>>> >>>>>>8) Subscriptions to Ad-Hoc Resource Lists mechanism >>>>>> >>>>>>9) Multiple REFER mechanism >>>>>> >>>>>>10) Ad-Hoc Conferencing using URI lists mechanism >>>>>> >>>>>>11) Call Control Transfer mechanism >>>>>> >>>>>>12) Configuration Delivery mechanism >>>>>> >>>>>>13) Emergency Calling using SIP (SOS) mechanism >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>Note that I'm not entirely happy with the division of >>>> >>>>SIPPING into SIPUSE >>>> >>>>>>and SIPREQ. While it seems like we spend a lot of time >> >>in SIPPING >> >>>>>>debating requirements, there are currently a lot of >>>> >>>>deliverables in this >>>> >>>>>>category. >>>>>> >>>>>> >>>>>>-- >>>>>>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 >>>>> >>>>> >>>>>_______________________________________________ >>>>>Sipping mailing list >> >>https://www1.ietf.org/mailman/listinfo/sipping >> >>>>>This list is for NEW development of the application of SIP Use >>>>>sip-implementors@cs.columbia.edu for questions on current sip Use >>>>>sip@ietf.org for new developments of core SIP >>>> >>>>_______________________________________________ >>>>Sipping mailing list >> >>https://www1.ietf.org/mailman/listinfo/sipping >> >>>>This list is for NEW development of the application of SIP Use >>>>sip-implementors@cs.columbia.edu for questions on current sip Use >>>>sip@ietf.org for new developments of core 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 >> > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core 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 sip-bounces@ietf.org Mon Feb 27 17:51:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDrAu-0000sj-1U; Mon, 27 Feb 2006 17:49:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDrAs-0000qp-9p; Mon, 27 Feb 2006 17:49:02 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDpYD-0003tf-Sx; Mon, 27 Feb 2006 16:05:01 -0500 Received: from [156.154.24.129] (helo=oak.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FDpJi-0002PV-7v; Mon, 27 Feb 2006 15:50:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k1RKo1BX001481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Feb 2006 20:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FDpJh-00070l-Ru; Mon, 27 Feb 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 27 Feb 2006 15:50:01 -0500 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --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 : Diagnostic Responses for SIP Hop Limit Errors Author(s) : S. Lawrence, et al. Filename : draft-ietf-sip-hop-limit-diagnostics-00.txt Pages : 12 Date : 2006-2-27 The SIP protocol imposes a limit on the number of hops a request may make from a sender to the recipient. When this limit is reached, a 483 error response is returned. The present form of the 483 response does not provide enough information for the sender or proxies on the path to diagnose failures whose symptom is that the hop limit is reached. This document proposes additional diagnostic information to be returned in a 483 response. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-hop-limit-diagnostics-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-hop-limit-diagnostics-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-hop-limit-diagnostics-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: <2006-2-27112016.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-hop-limit-diagnostics-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-hop-limit-diagnostics-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-27112016.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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-- From sip-bounces@ietf.org Mon Feb 27 19:26:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDsfC-0005My-J8; Mon, 27 Feb 2006 19:24:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDsCV-0006nF-7C; Mon, 27 Feb 2006 18:54:47 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDsCU-00005A-Eh; Mon, 27 Feb 2006 18:54:46 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 27 Feb 2006 15:54:45 -0800 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k1RNsjXh021891; Mon, 27 Feb 2006 15:54:45 -0800 (PST) Received: from 171.68.225.134 ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Mon, 27 Feb 2006 23:54:44 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Mon, 27 Feb 2006 15:54:42 -0800 Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle ofDividingandConquering From: Cullen Jennings To: Mary Barnes , Michael P Hammer , "sip@ietf.org" , sipping Message-ID: Thread-Topic: [Sipping] Re: [Sip] Thoughts on the Principle ofDividingandConquering Thread-Index: AcY7Q6mOhR2LvnfAR2GcDpXGmRTTDQABZDVQAAcVQBQAGp20wAAB2sUQAAhvA5k= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Henning Schulzrinne , Jon Peterson , Allison Mankin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org These seem like some concrete ideas that sound like they could speed stuff up. One of the problems we have is that all our work is done in three impulses each year. Most drafts only cycle before each meeting. If we could come up with a scheme, such as this, that helped some of the draft get reasonable review more often, it could speed things up. The risk is that a few people that do care about a draft ignore it until the next meeting then explode the work that was reached between the meetings. We have many examples of this. Do you think we could get a bunch of people in RAI to all agree to review 2 drafts a month? Say we told authors, you have a slot here, if you have a draft ready, at least 5 people will review it. If it is not ready, you miss your slot. Would this speed stuff up? Could we get agreement on a stawman list of drafts they we believe are in the category of trivial to finish and are needed now or yesterday? Running this would be non trivial but hopefully we could find a victim^H^H^H^H^H^H volunteer. If we can get a few concrete ideas like this together for the next meeting, it might make sense to spend a *short* amount of time getting input on them. I certainly don't want to delay work by using valuable meeting time to discuss process. I would be somewhat hesitant to ask this group "Do you want to do X?" because historically we say yes to everything. On 2/27/06 12:02 PM, "Mary Barnes" wrote: > I think this is a reasonable approach. Although, given the amount of > work, you might have to do a different draft every two weeks to get > things progressed or interleave 2 drafts. And, perhaps, to further > expand on this suggestion, each draft should have several people (i.e., > dedicated reviewers selected from a pool of volunteers) who have > committed (upfront) to providing the necessary feedback. If you can't > get that commitment, then you skip the draft straightaway and move on to > the next. This certainly would require some housekeeping work by the > chairs to keep things going, but with the volume of work, there needs to > be a way of forcing attention to work to get it progressed. > > I still think the directorate concept is also not unreasonable and that > after x amount of time spinning in the WG, a draft should go to the > directorate (with any known open issues identified). The directorate > could decide whether they think the draft in it's current form has any > hope - I think one of the problems is that it's hard for the original > authors/editor to see cases where significant rethinking might be > necessary and again, it's hit or miss whether someone else in the WG > takes the time to do this sort of review with the current volume of > work. I think catching problems and doing this sort of revie earlier in > the cycle might help improve overall quality and speed things up. > > Mary. > > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Monday, February 27, 2006 1:05 PM > To: Cullen Jennings (fluffy); sip@ietf.org; sipping > Cc: Jon Peterson; Allison Mankin > Subject: RE: [Sipping] Re: [Sip] Thoughts on the Principle > ofDividingandConquering > > > Cullen, > > Your questions echo some that have been bouncing around in my head as > well. With so many drafts, I tend to think it is a dilution of focus, > where the speed of any one document is progressed at the speed of its > share of the groups collective focus. In other words, the collective > brain is thrashing from one draft to another. > > If the chairs could get the group to agree on the prioritized list of > drafts (or just make that decision), then have a draft of the month > system where the WG focuses on one draft until it is finished. The > author should be prepared to update it every workday if needed to keep > pace. At the end of the month, it goes to last call. If the author is > not prepared, go to end of the queue, or have another author take over. > > Mike _______________________________________________ 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 sip-bounces@ietf.org Mon Feb 27 20:30:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDtf8-0001Ns-3f; Mon, 27 Feb 2006 20:28:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDtf5-0001Hl-HZ; Mon, 27 Feb 2006 20:28:23 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDtf2-0006xC-Ug; Mon, 27 Feb 2006 20:28:23 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 27 Feb 2006 17:28:20 -0800 X-IronPort-AV: i="4.02,151,1139212800"; d="scan'208"; a="1780234591:sNHT35753120" Received: from dwingwxp ([10.32.240.197]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k1S1SIuh026389; Mon, 27 Feb 2006 17:28:19 -0800 (PST) From: "Dan Wing" To: "'Cullen Jennings'" , "'Mary Barnes'" , "'Michael P Hammer'" , , "'sipping'" Subject: RE: [Sipping] Re: [Sip] Thoughts on the PrincipleofDividingandConquering Date: Mon, 27 Feb 2006 17:28:17 -0800 Message-ID: <086101c63c06$412434c0$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Thread-Index: AcY7Q6mOhR2LvnfAR2GcDpXGmRTTDQABZDVQAAcVQBQAGp20wAAB2sUQAAhvA5kAAyZZEA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: 'Allison Mankin' , 'Jon Peterson' , 'Henning Schulzrinne' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The motivation for finishing I-Ds before the WG meeting is the I-D cutoff date and the pressure to have made progress since the last meeting. What you're describing is another way to create pressure. I agree that will help accelerate things. We might be best served by accelerating the important things -- a 'fast track', if you will. This would require editors to submit documents 'between' the normal cutoff dates (IETF meetings) and require substantive review and comments from the community. This would double the speed of changes of those documents which everyone would support. A 100% improvement would be valuable to the community. I could think of some SIP and SIP-related documents that I would put on such a fast track, if one existed. -d > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Monday, February 27, 2006 3:55 PM > To: Mary Barnes; Michael P Hammer; sip@ietf.org; sipping > Cc: Henning Schulzrinne; Jon Peterson; Allison Mankin > Subject: Re: [Sipping] Re: [Sip] Thoughts on the > PrincipleofDividingandConquering > > > These seem like some concrete ideas that sound like they > could speed stuff > up. One of the problems we have is that all our work is done in three > impulses each year. Most drafts only cycle before each > meeting. If we could > come up with a scheme, such as this, that helped some of the draft get > reasonable review more often, it could speed things up. The > risk is that a > few people that do care about a draft ignore it until the > next meeting then > explode the work that was reached between the meetings. We have many > examples of this. > > Do you think we could get a bunch of people in RAI to all > agree to review 2 > drafts a month? Say we told authors, you have a slot here, if > you have a > draft ready, at least 5 people will review it. If it is not > ready, you miss > your slot. Would this speed stuff up? Could we get agreement > on a stawman > list of drafts they we believe are in the category of trivial > to finish and > are needed now or yesterday? Running this would be non > trivial but hopefully > we could find a victim^H^H^H^H^H^H volunteer. > > If we can get a few concrete ideas like this together for the > next meeting, > it might make sense to spend a *short* amount of time getting > input on them. > I certainly don't want to delay work by using valuable meeting time to > discuss process. I would be somewhat hesitant to ask this > group "Do you want > to do X?" because historically we say yes to everything. > > > > > On 2/27/06 12:02 PM, "Mary Barnes" wrote: > > > I think this is a reasonable approach. Although, given the amount of > > work, you might have to do a different draft every two weeks to get > > things progressed or interleave 2 drafts. And, perhaps, to further > > expand on this suggestion, each draft should have several > people (i.e., > > dedicated reviewers selected from a pool of volunteers) who have > > committed (upfront) to providing the necessary feedback. If > you can't > > get that commitment, then you skip the draft straightaway > and move on to > > the next. This certainly would require some housekeeping > work by the > > chairs to keep things going, but with the volume of work, > there needs to > > be a way of forcing attention to work to get it progressed. > > > > I still think the directorate concept is also not > unreasonable and that > > after x amount of time spinning in the WG, a draft should go to the > > directorate (with any known open issues identified). The > directorate > > could decide whether they think the draft in it's current > form has any > > hope - I think one of the problems is that it's hard for > the original > > authors/editor to see cases where significant rethinking might be > > necessary and again, it's hit or miss whether someone else in the WG > > takes the time to do this sort of review with the current volume of > > work. I think catching problems and doing this sort of > revie earlier in > > the cycle might help improve overall quality and speed things up. > > > > Mary. > > > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Monday, February 27, 2006 1:05 PM > > To: Cullen Jennings (fluffy); sip@ietf.org; sipping > > Cc: Jon Peterson; Allison Mankin > > Subject: RE: [Sipping] Re: [Sip] Thoughts on the Principle > > ofDividingandConquering > > > > > > Cullen, > > > > Your questions echo some that have been bouncing around in > my head as > > well. With so many drafts, I tend to think it is a > dilution of focus, > > where the speed of any one document is progressed at the > speed of its > > share of the groups collective focus. In other words, the > collective > > brain is thrashing from one draft to another. > > > > If the chairs could get the group to agree on the > prioritized list of > > drafts (or just make that decision), then have a draft of the month > > system where the WG focuses on one draft until it is finished. The > > author should be prepared to update it every workday if > needed to keep > > pace. At the end of the month, it goes to last call. If > the author is > > not prepared, go to end of the queue, or have another > author take over. > > > > Mike > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core 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 sip-bounces@ietf.org Mon Feb 27 20:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDtj0-0005Au-M6; Mon, 27 Feb 2006 20:32:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDtix-00056x-Nr; Mon, 27 Feb 2006 20:32:23 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDtiw-000776-DK; Mon, 27 Feb 2006 20:32:23 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k1S1WX8N011967 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 27 Feb 2006 19:32:34 -0600 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301245A9E@xmb-rtp-20b.amer.cisco.com> References: <072C5B76F7CEAB488172C6F64B30B5E301245A9E@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <05B6D9FD-C811-4474-9701-4A1A7C79A40C@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of DividingandConquering Date: Mon, 27 Feb 2006 19:32:17 -0600 To: "Michael Hammer \(mhammer\)" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: "Cullen Jennings \(fluffy\)" , sip@ietf.org, sipping , Jon Peterson , Allison Mankin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Feb 27, 2006, at 1:05 PM, Michael Hammer ((mhammer)) wrote: > Cullen, > > Your questions echo some that have been bouncing around in my head as > well. With so many drafts, I tend to think it is a dilution of focus, > where the speed of any one document is progressed at the speed of its > share of the groups collective focus. In other words, the collective > brain is thrashing from one draft to another. > > If the chairs could get the group to agree on the prioritized list of > drafts (or just make that decision), then have a draft of the month > system where the WG focuses on one draft until it is finished. The > author should be prepared to update it every workday if needed to keep > pace. At the end of the month, it goes to last call. If the > author is > not prepared, go to end of the queue, or have another author take > over. We tried this once upon a time, and it just doesn't work with the ITEF editing model. Other groups, like OMA, make it work by having a professional editing staff (or in some cases a volunteer editor who is dedicated) that maintains the master copy of each draft, and other people submit change requests against it. When a change request is "agreed", the editor incorporates it into the draft. During a week long meeting, an OMA working group like POC (yes, they meet for 40 hours or so in one week) may review 300 change requests and agree 50 or so. IETF editors tend to be not dedicated full-time to their role. They're bursty. Stuff happens in unpredictable episodes, and it becomes very hard to predict what is happening when and where. For example: Despite my attempts to figure out what new -00 drafts needed to be approved, I still ended up having to send in late approvals for three new SIP drafts. Sure, I could have said no, but that would have pushed us even further off the chartered work plan. Unless we really want to change the way we work and go to "drafting sessions" and "weekly conference calls", we just have to accept that things are bursty and try to engage simultaneously on several fronts. Historically, IETF has tried to have working groups that last a year or two and produce three or four documents. SIP, by itself, has lasted almost 7 years so far (not counting when we were part of MMUSIC) and has generated thousands of documents and 40 RFCs. And we have another 20 or so RFCs in the pipeline. Now, while I won't say that returning to the traditional IETF "smaller, bounded WG" model is the only alternative we have, it really is the only model that the IETF currently knows how to work with. -- 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 sip-bounces@ietf.org Mon Feb 27 21:11:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDuJM-0007ig-1g; Mon, 27 Feb 2006 21:10:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDuJK-0007hr-5W; Mon, 27 Feb 2006 21:09:58 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDuJI-0007tu-QQ; Mon, 27 Feb 2006 21:09:58 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 27 Feb 2006 18:09:56 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1S29tVb021924; Mon, 27 Feb 2006 18:09:55 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Feb 2006 21:09:55 -0500 Received: from [192.168.1.104] ([10.86.240.111]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Feb 2006 21:09:54 -0500 Message-ID: <4403B0F1.4090305@cisco.com> Date: Mon, 27 Feb 2006 21:09:53 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Wing Subject: Re: [Sipping] Re: [Sip] Thoughts on the PrincipleofDividingandConquering References: <086101c63c06$412434c0$c5f0200a@amer.cisco.com> In-Reply-To: <086101c63c06$412434c0$c5f0200a@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Feb 2006 02:09:54.0614 (UTC) FILETIME=[10D27560:01C63C0C] X-Spam-Score: 1.8 (+) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: 'Cullen Jennings' , 'Jon Peterson' , 'Allison Mankin' , sip@ietf.org, 'Mary Barnes' , 'sipping' , 'Henning Schulzrinne' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dan Wing wrote: > The motivation for finishing I-Ds before the WG meeting is the > I-D cutoff date and the pressure to have made progress since the > last meeting. Actually, I think the motivation really comes down to one thing: shame. The IETF meeting is where everyone meets and drafts that made progress get discussed and talked about. If you didnt revise your draft because you didn't get around to it, its embarassing. I know :) Another aspect of this is the meeting blackout period. Because of it, if you don't update your draft NOW, you'll have to wait another three weeks to do so. > What you're describing is another way to create > pressure. I agree that will help accelerate things. We might > be best served by accelerating the important things -- a 'fast > track', if you will. This would require editors to submit > documents 'between' the normal cutoff dates (IETF meetings) > and require substantive review and comments from the community. There are two ways to create pressure- carrots and sticks. The IETF draft deadlines are sticks, I think. To find more sticks and carrots you need to look at what incents people. I think all of the following are real incentives: 1. people are incented to get RFCs published with their names as authors; it brings recognition to their peers and the industry. 2. people are incented to get RFCs published that benefit their day-job, because their day job requires problem X to be solved soon. The carrot here is the the day job = $$. 3. people are incented to submit new drafts and work on new drafts because everyone likes working on the new cool stuff, rather than the tired-of-it stuff that is 90% complete, where the work is just getting that MUST/SHOULD correct. I'm sure there are others. Given those incentives, you need to tie them into making forward progress on our work in genreal. One idea, for example, is to tie draft acceptance to reviews. Lets say I write draft X and I want it adopted by the WG. I can't get my draft accepted by the WG as a new item, until I commit to reviews and assistance in solving open issues for another draft that is already a WG item. Only once it is approved by IESG to I get to have my draft added. This is a carrot incentive. A related one, is that if a draft author does not complete a set of assigned reviews in time, or does not produce a revision of the spec on an agreed-upon timetable, they are removed as author. This is a stick version of the same incentive. No doubt there are others. I personally think most of our problems are NOT with iesg or with WG chairs, but with the authors/editors and community. I know that I myself am not quick enough in turning around drafts, and that every time, I fall into the same trap of getting the updates done just before the deadline. And then, after IETF, I promise myself it won't happen again, and then day-job work that I put off comes up, and the previous IETF fades away, and each and every day there is always something more pressing to do than to update or work on an I-D that isn't really "due" until the next deadline.... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.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 sip-bounces@ietf.org Mon Feb 27 23:00:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDw0h-0002kF-DP; Mon, 27 Feb 2006 22:58:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDw0f-0002jY-Ct; Mon, 27 Feb 2006 22:58:49 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDw0d-0002zr-Uv; Mon, 27 Feb 2006 22:58:49 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 27 Feb 2006 19:58:47 -0800 X-IronPort-AV: i="4.02,151,1139212800"; d="scan'208"; a="410594218:sNHT35554200" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1S3vaVj004347; Mon, 27 Feb 2006 19:58:46 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Feb 2006 22:58:34 -0500 Received: from [10.86.242.50] ([10.86.242.50]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Feb 2006 22:58:33 -0500 Message-ID: <4403CA68.5030400@cisco.com> Date: Mon, 27 Feb 2006 22:58:32 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle ofDividingandConquering References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Feb 2006 03:58:33.0572 (UTC) FILETIME=[3E6C8240:01C63C1B] X-Spam-Score: 1.8 (+) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: Jon Peterson , Allison Mankin , "sip@ietf.org" , Mary Barnes , sipping , Henning Schulzrinne X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen Jennings wrote: > These seem like some concrete ideas that sound like they could speed stuff > up. One of the problems we have is that all our work is done in three > impulses each year. Most drafts only cycle before each meeting. If we could > come up with a scheme, such as this, that helped some of the draft get > reasonable review more often, it could speed things up. The risk is that a > few people that do care about a draft ignore it until the next meeting then > explode the work that was reached between the meetings. We have many > examples of this. > > Do you think we could get a bunch of people in RAI to all agree to review 2 > drafts a month? I would think so. I know I have been buried in other work and have been ignoring most drafts this cycle - much more than before. But I am sure I could promise to look at a few a month. > Say we told authors, you have a slot here, if you have a > draft ready, at least 5 people will review it. If it is not ready, you miss > your slot. Would this speed stuff up? I don't know for sure, but I would hope so. Paul > Could we get agreement on a stawman > list of drafts they we believe are in the category of trivial to finish and > are needed now or yesterday? Running this would be non trivial but hopefully > we could find a victim^H^H^H^H^H^H volunteer. > > If we can get a few concrete ideas like this together for the next meeting, > it might make sense to spend a *short* amount of time getting input on them. > I certainly don't want to delay work by using valuable meeting time to > discuss process. I would be somewhat hesitant to ask this group "Do you want > to do X?" because historically we say yes to everything. > > > > > On 2/27/06 12:02 PM, "Mary Barnes" wrote: > > >>I think this is a reasonable approach. Although, given the amount of >>work, you might have to do a different draft every two weeks to get >>things progressed or interleave 2 drafts. And, perhaps, to further >>expand on this suggestion, each draft should have several people (i.e., >>dedicated reviewers selected from a pool of volunteers) who have >>committed (upfront) to providing the necessary feedback. If you can't >>get that commitment, then you skip the draft straightaway and move on to >>the next. This certainly would require some housekeeping work by the >>chairs to keep things going, but with the volume of work, there needs to >>be a way of forcing attention to work to get it progressed. >> >>I still think the directorate concept is also not unreasonable and that >>after x amount of time spinning in the WG, a draft should go to the >>directorate (with any known open issues identified). The directorate >>could decide whether they think the draft in it's current form has any >>hope - I think one of the problems is that it's hard for the original >>authors/editor to see cases where significant rethinking might be >>necessary and again, it's hit or miss whether someone else in the WG >>takes the time to do this sort of review with the current volume of >>work. I think catching problems and doing this sort of revie earlier in >>the cycle might help improve overall quality and speed things up. >> >>Mary. >> >>-----Original Message----- >>From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] >>Sent: Monday, February 27, 2006 1:05 PM >>To: Cullen Jennings (fluffy); sip@ietf.org; sipping >>Cc: Jon Peterson; Allison Mankin >>Subject: RE: [Sipping] Re: [Sip] Thoughts on the Principle >>ofDividingandConquering >> >> >>Cullen, >> >>Your questions echo some that have been bouncing around in my head as >>well. With so many drafts, I tend to think it is a dilution of focus, >>where the speed of any one document is progressed at the speed of its >>share of the groups collective focus. In other words, the collective >>brain is thrashing from one draft to another. >> >>If the chairs could get the group to agree on the prioritized list of >>drafts (or just make that decision), then have a draft of the month >>system where the WG focuses on one draft until it is finished. The >>author should be prepared to update it every workday if needed to keep >>pace. At the end of the month, it goes to last call. If the author is >>not prepared, go to end of the queue, or have another author take over. >> >>Mike > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core 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 sip-bounces@ietf.org Tue Feb 28 02:53:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDzde-0005eP-NV; Tue, 28 Feb 2006 02:51:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDzdb-0005dT-Fc; Tue, 28 Feb 2006 02:51:15 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDzdX-00013j-WD; Tue, 28 Feb 2006 02:51:15 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k1S7p1gw020713; Tue, 28 Feb 2006 09:51:02 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Feb 2006 09:51:02 +0200 Received: from [172.21.37.166] ([172.21.37.166]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 28 Feb 2006 09:51:01 +0200 Message-ID: <440400E5.1060205@nokia.com> Date: Tue, 28 Feb 2006 09:51:01 +0200 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: ext Rohan Mahy Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of Dividing and Conquering References: <231F5685-CCC1-41B1-997E-74AF67D9EBCE@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Feb 2006 07:51:01.0577 (UTC) FILETIME=[B8152B90:01C63C3B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Cullen Jennings , Jon Peterson , Allison Mankin , "sip@ietf.org List" , Dean Willis , Sipping List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Inline. ext Rohan Mahy wrote: > I think mostly we have a problem saying no. We have too much work to do > and the only effective way for this community to get better throughput > is to focus religiously on a much smaller handful of work items (ex: 4 > or 5) at a time. I am as guilty as the next person for adding new > milestones (actually, more guilty as a chair), but it is hard to say no > to new work when old work that is "almost done" takes so long to finish. I don't think this will help much. These core efforts are concentrated to a very small number of authors, perhaps as few as 2-3. How would saying that the rest will need to stop working on their drafts help speed up the work done by these 2-3 authors? Granted, the few core authors are doing an excellent job, but I wonder if there's anything we could do to balance the load. I just can't see that the work amount can be carried by such few authors in the long run. Especially since these same people are holding various other positions in the IETF at the same time. Cheers, Aki _______________________________________________ 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 sip-bounces@ietf.org Tue Feb 28 04:57:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE1aI-00016y-Lp; Tue, 28 Feb 2006 04:55:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE1aG-00016n-Kx for sip@ietf.org; Tue, 28 Feb 2006 04:55:56 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE1aF-0004wV-2O for sip@ietf.org; Tue, 28 Feb 2006 04:55:56 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 33D284F0009; Tue, 28 Feb 2006 10:55:54 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Feb 2006 10:55:53 +0100 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Feb 2006 10:55:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Questions on subscription dialogs Date: Tue, 28 Feb 2006 10:55:52 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1ABC@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Questions on subscription dialogs Thread-Index: AcY75QUVRMIHxKy7SQmZmocrDWtCKwAZeyyw From: "Christer Holmberg \(JO/LMF\)" To: "Paul Kyzivat" X-OriginalArrivalTime: 28 Feb 2006 09:55:53.0391 (UTC) FILETIME=[298D43F0:01C63C4D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Paul, Thanks for your reply! Comments inline ([CHH]).=20 >>Q1: Is it allowed to send non-NOTIFY request within a subscription=20 >>dialog (initiated by SUBSCRIBE), assuming the users support it? >> >Yes, with limits. In general, a request that is legal outside a dialog is also legal within a dialog. (E.g. OPTIONS.) In some cases (e.g.=20 >MESSAGE) other limitations have been applied. (You aren't supposed to use MESSAGE within a dialog as a way to avoid session mode messaging.) > >It is legal, though generally discouraged, to send requests within an existing dialog that establish a new dialog usage. Sending an INVITE within a=20 >dialog established by a SUBSCRIBE falls into this category. [CHH] Is the discouragement documented somewhere? Or, is it just one of the "unwritten rules"? :) >>Q2: If Q1=3D=3DTRUE, is it allowed to add media during a subscription=20 >>dialog, by sending an SDP offer in an UPDATE/re-INVITE? >An INVITE in this case (at least the first one) would not be a reINVITE.=20 >It would establish a new invite dialog usage within an already established dialog. [CHH] Well, it would contain a To tag, and I believe it is said somewhere that it then should be treated as a re-INVITE. But, at the end I guess it doesn't matter what we call it, as long as it is allowed to send it. >IMO an UPDATE is only permitted within an existing invite dialog usage. >So you would have to send an INVITE to establish the usage before you could use UPDATE to do a subsequent offer/answer. [CHH] Where is that said? I was looking in RFC 3311, and eventhough the text examples talk about INVITE initiated dialogs I didn't find any text forbidding it to be used elswhere. But, of course I may have missed it... >>>Q3: If Q2=3D=3DTRUE, is it allowed to use re-INVITE, eventhough the dialog was not initiated using INVITE? >>See above. Beware that I have heard of no implementation that actually support this. [CHH] Neither have I - so far :) >>Q4: If Q1=3D=3DTRUE, if I send an empty re-INVITE within a = subscription=20 >>dialog, e.g. to update the remote target, I assume the receiver MUST=20 >>create and include an SDP offer in the 200 OK response, eventhough no=20 >>media has previously been used within the dialog? >Again see above. The invite must follow all the normal rules. > >Note that as defined, all the usages of the dialog share the same targets. If you have a dialog shared by an invite usage and a subscribe usage, then=20 >either a reinvite or a resubscribe will update the target they share in common. [CHH] I agree. It's still the same dialog, I think, eventhough there seem to be different "usage" of it. But, if you use (re-)INVITE, an SDP offer MUST be included (either in the request or response), according to the normal rules. >If you have just a subscription, and what to change the target, you can use a resubscribe. No need to use UPDATE or INVITE to accomplish that. [CHH] I agree. However, my main issue was not so much related to updating of the target, but more to the possibility to add media to an ongoing subscription dialog. Regards, Christer _______________________________________________ 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 sip-bounces@ietf.org Tue Feb 28 05:07:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE1jv-0008Re-Ie; Tue, 28 Feb 2006 05:05:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE1jt-0008Qi-Nd for sip@ietf.org; Tue, 28 Feb 2006 05:05:53 -0500 Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE1js-0005AQ-E0 for sip@ietf.org; Tue, 28 Feb 2006 05:05:53 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id 8758A74489 for ; Tue, 28 Feb 2006 11:05:51 +0100 (CET) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 22922-01-14 for ; Tue, 28 Feb 2006 11:05:51 +0100 (CET) Received: from dhcp-wavelan-v-249.publik.su.se (dhcp-wavelan-v-249.publik.su.se [130.237.168.249]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id 1FE1574038 for ; Tue, 28 Feb 2006 11:05:51 +0100 (CET) From: Fredrik Thulin To: sip@ietf.org Date: Tue, 28 Feb 2006 11:05:47 +0100 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200602281105.47759.ft@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.521 tagged_above=-99 required=7 tests=[AWL=0.144, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Sip] Comments on draft-ietf-sip-hop-limit-diagnostics-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi I've read draft-ietf-sip-hop-limit-diagnostics-00 and have some comments. Generally I think the idea is very good. First, a nit perhaps. The From: in the examples have a Display name of "Sip Send" without quotes. Aren't quotes required in this case according to RFC3261? Of course that part isn't very important to this particular draft, but examples might as well be wellformed in my opinion. Secondly, and more important. If I'm not missing anything it might still be hard/impossible to unambigously identify the element that actually generated a 483. If I get a 483 containing Via headers (in the message/sipfrag body) like the one on page 6 (section 2.3. Example) then I can guess/assume that the host that actually generated the 483 is the one running on 192.0.2.162 port 5080, but I cannot know this for sure, can I? To clarify, perhaps "interop.pingtel.com" (as used in the example from the draft) has SRV records that make nine out of ten requests go to the first proxy in a cluster (P2A), but one in ten will go to the second proxy in the cluster (P2B). The Via headers might then show what looks like a loop solely between P1 and P2A, with no evidence to the sender that it was actually P2B that got the request when Max-Forwards reached zero and the 483 was generated (by P2B). Perhaps this draft could suggest that the element generating 483's SHOULD include information about itself (hostname/IP and, if necessary, listening port) in some way? /Fredrik _______________________________________________ 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 sip-bounces@ietf.org Tue Feb 28 08:20:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE4kY-0007AB-Ca; Tue, 28 Feb 2006 08:18:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE4kW-00079S-TR; Tue, 28 Feb 2006 08:18:44 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE4kV-00031H-Ip; Tue, 28 Feb 2006 08:18:44 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 28 Feb 2006 05:18:44 -0800 X-IronPort-AV: i="4.02,152,1139212800"; d="scan'208"; a="1780408627:sNHT1401085194" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1SDIfVb023248; Tue, 28 Feb 2006 05:18:41 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Feb 2006 08:18:41 -0500 Received: from [10.86.242.50] ([10.86.242.50]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Feb 2006 08:18:41 -0500 Message-ID: <44044DB0.7010002@cisco.com> Date: Tue, 28 Feb 2006 08:18:40 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of Dividing and Conquering References: <231F5685-CCC1-41B1-997E-74AF67D9EBCE@softarmor.com> <440400E5.1060205@nokia.com> In-Reply-To: <440400E5.1060205@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Feb 2006 13:18:41.0106 (UTC) FILETIME=[7E133B20:01C63C69] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Cullen Jennings , ext Rohan Mahy , Jon Peterson , Allison Mankin , "sip@ietf.org List" , Dean Willis , Sipping List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I agree. While I think there definitely are things that we should say NO to, I don't think restricting our efforts to 4-5 things is a recipe for success. People are out there trying to apply SIP, and they are finding things that need standardization. If we say NO, then either we will delay the application of SIP, or else we will force those extras to be done elsewhere, leading to more severe fragmentation of sip. Paul Aki Niemi wrote: > Inline. > > ext Rohan Mahy wrote: > >>I think mostly we have a problem saying no. We have too much work to do >>and the only effective way for this community to get better throughput >>is to focus religiously on a much smaller handful of work items (ex: 4 >>or 5) at a time. I am as guilty as the next person for adding new >>milestones (actually, more guilty as a chair), but it is hard to say no >>to new work when old work that is "almost done" takes so long to finish. > > > I don't think this will help much. These core efforts are concentrated > to a very small number of authors, perhaps as few as 2-3. How would > saying that the rest will need to stop working on their drafts help > speed up the work done by these 2-3 authors? > > Granted, the few core authors are doing an excellent job, but I wonder > if there's anything we could do to balance the load. I just can't see > that the work amount can be carried by such few authors in the long run. > Especially since these same people are holding various other positions > in the IETF at the same time. > > Cheers, > Aki > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core 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 sip-bounces@ietf.org Tue Feb 28 08:46:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE599-00009F-Nj; Tue, 28 Feb 2006 08:44:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE598-000094-FK for sip@ietf.org; Tue, 28 Feb 2006 08:44:10 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE598-0003qL-5J for sip@ietf.org; Tue, 28 Feb 2006 08:44:10 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 28 Feb 2006 08:44:10 -0500 X-IronPort-AV: i="4.02,152,1139202000"; d="scan'208"; a="83236125:sNHT33943372" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1SDi9qM022187; Tue, 28 Feb 2006 08:44:09 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Feb 2006 08:44:09 -0500 Received: from [10.86.242.50] ([10.86.242.50]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Feb 2006 08:44:09 -0500 Message-ID: <440453A8.9020201@cisco.com> Date: Tue, 28 Feb 2006 08:44:08 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] Questions on subscription dialogs References: <5EB80D22825EEE42872083AD5BFFB5945D1ABC@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1ABC@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Feb 2006 13:44:09.0331 (UTC) FILETIME=[0CF7DC30:01C63C6D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer, More in line. Once again we are spelling out the unwritten rules of dialogs. Paul Christer Holmberg (JO/LMF) wrote: > Hi Paul, > > Thanks for your reply! Comments inline ([CHH]). > > >>>Q1: Is it allowed to send non-NOTIFY request within a subscription >>>dialog (initiated by SUBSCRIBE), assuming the users support it? >>> >> >>Yes, with limits. In general, a request that is legal outside a dialog > > is also legal within a dialog. (E.g. OPTIONS.) In some cases (e.g. > >>MESSAGE) other limitations have been applied. (You aren't supposed to > > use MESSAGE within a dialog as a way to avoid session mode messaging.) > >>It is legal, though generally discouraged, to send requests within an > > existing dialog that establish a new dialog usage. Sending an INVITE > within a > >>dialog established by a SUBSCRIBE falls into this category. > > > [CHH] Is the discouragement documented somewhere? Or, is it just one of > the "unwritten rules"? :) I believe it has mostly been written in email threads here. I'm not sure if it is enshrined in any RFC or draft. (I think it might be mentioned in the target-dialog draft, and I think it might be mentioned in a draft by ben or robert.) I know there was a discussion thread a few months ago about this. I was nearly alone in advocating that shared dialogs are not always evil. >>>Q2: If Q1==TRUE, is it allowed to add media during a subscription >>>dialog, by sending an SDP offer in an UPDATE/re-INVITE? >> >>An INVITE in this case (at least the first one) would not be a > > reINVITE. > >>It would establish a new invite dialog usage within an already > > established dialog. > > [CHH] Well, it would contain a To tag, and I believe it is said > somewhere that it then should be treated as a re-INVITE. But, at the end > I guess it doesn't matter what we call it, as long as it is allowed to > send it. You may be right. The language in 3261 is very sloppy in this regard. It implies, but doesn't formalize, the notion of dialog usages, and mixes up dialogs and their usages a lot. IMO a reinvite refreshes an invite dialog usage. >>IMO an UPDATE is only permitted within an existing invite dialog usage. > > >>So you would have to send an INVITE to establish the usage before you > > could use UPDATE to do a subsequent offer/answer. > > [CHH] Where is that said? I was looking in RFC 3311, and eventhough the > text examples talk about INVITE initiated dialogs I didn't find any text > forbidding it to be used elswhere. But, of course I may have missed > it... I doubt it is said anywhere. Its another thing that has evolved via discussion, and enshrined in draft-sawada-sipping-sip-offeranswer-00. >>>>Q3: If Q2==TRUE, is it allowed to use re-INVITE, eventhough the > > dialog was not initiated using INVITE? > >>>See above. Beware that I have heard of no implementation that actually > > support this. > > [CHH] Neither have I - so far :) > > >>>Q4: If Q1==TRUE, if I send an empty re-INVITE within a subscription >>>dialog, e.g. to update the remote target, I assume the receiver MUST >>>create and include an SDP offer in the 200 OK response, eventhough no >>>media has previously been used within the dialog? >> >>Again see above. The invite must follow all the normal rules. >> >>Note that as defined, all the usages of the dialog share the same > > targets. If you have a dialog shared by an invite usage and a subscribe > usage, then > >>either a reinvite or a resubscribe will update the target they share in > > common. > > [CHH] I agree. It's still the same dialog, I think, eventhough there > seem to be different "usage" of it. But, if you use (re-)INVITE, an SDP > offer MUST be included (either in the request or response), according to > the normal rules. We are in violent agreement here. >>If you have just a subscription, and what to change the target, you can > > use a resubscribe. No need to use UPDATE or INVITE to accomplish that. > > [CHH] I agree. However, my main issue was not so much related to > updating of the target, but more to the possibility to add media to an > ongoing subscription dialog. IMO the media is a property of an invite dialog usage. You can't add media directly to a dialog, you must first add an invite dialog usage to the dialog and then it can have media. I don't want to attempt drawing a UML diagram here with text art, so I will try to do it with text: class: dialog attribute: cseq attribute: callid attribute: to-tag attribute: from-tag attribute: route set attribute: local contact attribute: remote contact attribute: ... subclass: zero or one invite-dialog-usage subclass: zero or more subscribe-dialog-usage class: invite-dialog-usage attribute: expiration-time attribute: active offer attribute: active answer attribute: offer/answer state attribute: pending offer attribute: pending answer attribute: zero or more media-session attribute: ... class: subscribe-dialog-usage attribute: expiration-time attribute: event-type attribute: event-parameters attribute: event-id attribute: direction (watcher/notifier) attribute: ... _______________________________________________ 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 sip-bounces@ietf.org Tue Feb 28 08:53:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE5G9-0008RS-Ua; Tue, 28 Feb 2006 08:51:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE5G8-0008RD-Lg; Tue, 28 Feb 2006 08:51:24 -0500 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE5G7-0003x1-7v; Tue, 28 Feb 2006 08:51:24 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id k1SDpMQk115754; Tue, 28 Feb 2006 13:51:22 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k1SDpawQ205556; Tue, 28 Feb 2006 14:51:36 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k1SDpLXT025500; Tue, 28 Feb 2006 14:51:21 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k1SDpLM5025489; Tue, 28 Feb 2006 14:51:21 +0100 In-Reply-To: <440400E5.1060205@nokia.com> To: sip@ietf.org, sipping@ietf.org Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of Dividing and Conquering MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Avshalom Houri Message-ID: Date: Tue, 28 Feb 2006 15:51:34 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0HF90 | November 16, 2005) at 28/02/2006 15:51:36, Serialize complete at 28/02/2006 15:51:36 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1113536036==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1113536036== Content-Type: multipart/alternative; boundary="=_alternative 004B6107C2257123_=" This is a multipart message in MIME format. --=_alternative 004B6107C2257123_= Content-Type: text/plain; charset="US-ASCII" Just a small optimization suggestion, can we decide to continue this discussion either in sip or sipping (sipping probably is more appropriate for this). We do not need to get a multiple copy of the message so near to the next IETF when the IETF mailing lists are full anyway (people that are in the to or cc list get 3 copies...) Thanks --Avshalom --=_alternative 004B6107C2257123_= Content-Type: text/html; charset="US-ASCII"
Just a small optimization suggestion, can we decide to continue this discussion either in sip or sipping (sipping probably is more appropriate for this).
We do not need to get a multiple copy of the message so near to the next IETF when the IETF mailing lists are full anyway (people that are in the to or
cc list get 3 copies...)

Thanks
--Avshalom
--=_alternative 004B6107C2257123_=-- --===============1113536036== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1113536036==-- From sip-bounces@ietf.org Tue Feb 28 09:22:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE5iI-0002MB-MJ; Tue, 28 Feb 2006 09:20:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE5iH-0002Lq-D0 for sip@ietf.org; Tue, 28 Feb 2006 09:20:29 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE5iG-0004lN-Rc for sip@ietf.org; Tue, 28 Feb 2006 09:20:29 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 28 Feb 2006 06:20:28 -0800 X-IronPort-AV: i="4.02,152,1139212800"; d="scan'208"; a="410760154:sNHT34497832" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1SEKNVj029590; Tue, 28 Feb 2006 06:20:28 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Feb 2006 09:20:23 -0500 Received: from [161.44.79.183] ([161.44.79.183]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Feb 2006 09:20:23 -0500 Message-ID: <44045C27.6000805@cisco.com> Date: Tue, 28 Feb 2006 09:20:23 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] Questions on subscription dialogs (correction) References: <5EB80D22825EEE42872083AD5BFFB5945D1ABC@esealmw113.eemea.ericsson.se> <440453A8.9020201@cisco.com> In-Reply-To: <440453A8.9020201@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Feb 2006 14:20:23.0532 (UTC) FILETIME=[1CE49AC0:01C63C72] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I botched up the data model I posted in the last message. (Too early in the morning.) I will try again: class: dialog attribute: cseq attribute: callid attribute: to-tag attribute: from-tag attribute: route set attribute: local contact attribute: remote contact association: one or more dialog-usage constraint: at most one invite-dialog-usage attribute: ... class: dialog-usage association: exactly one dialog class: invite-dialog-usage superclass: dialog-usage attribute: expiration-time attribute: active offer attribute: active answer attribute: offer/answer state attribute: pending offer attribute: pending answer attribute: zero or more media-session attribute: ... class: subscribe-dialog-usage superclass: dialog-usage attribute: expiration-time attribute: event-type attribute: event-parameters attribute: event-id attribute: direction (watcher/notifier) attribute: ... Paul Kyzivat wrote: > Christer, > > More in line. Once again we are spelling out the unwritten rules of > dialogs. > > Paul > > Christer Holmberg (JO/LMF) wrote: > >> Hi Paul, >> >> Thanks for your reply! Comments inline ([CHH]). >> >>>> Q1: Is it allowed to send non-NOTIFY request within a subscription >>>> dialog (initiated by SUBSCRIBE), assuming the users support it? >>>> >>> >>> Yes, with limits. In general, a request that is legal outside a dialog >> >> >> is also legal within a dialog. (E.g. OPTIONS.) In some cases (e.g. >> >>> MESSAGE) other limitations have been applied. (You aren't supposed to >> >> >> use MESSAGE within a dialog as a way to avoid session mode messaging.) >> >>> It is legal, though generally discouraged, to send requests within an >> >> >> existing dialog that establish a new dialog usage. Sending an INVITE >> within a >> >>> dialog established by a SUBSCRIBE falls into this category. >> >> >> >> [CHH] Is the discouragement documented somewhere? Or, is it just one of >> the "unwritten rules"? :) > > > I believe it has mostly been written in email threads here. I'm not sure > if it is enshrined in any RFC or draft. (I think it might be mentioned > in the target-dialog draft, and I think it might be mentioned in a draft > by ben or robert.) > > I know there was a discussion thread a few months ago about this. I was > nearly alone in advocating that shared dialogs are not always evil. > >>>> Q2: If Q1==TRUE, is it allowed to add media during a subscription >>>> dialog, by sending an SDP offer in an UPDATE/re-INVITE? >>> >>> >>> An INVITE in this case (at least the first one) would not be a >> >> >> reINVITE. >> >>> It would establish a new invite dialog usage within an already >> >> >> established dialog. >> >> [CHH] Well, it would contain a To tag, and I believe it is said >> somewhere that it then should be treated as a re-INVITE. But, at the end >> I guess it doesn't matter what we call it, as long as it is allowed to >> send it. > > > You may be right. The language in 3261 is very sloppy in this regard. It > implies, but doesn't formalize, the notion of dialog usages, and mixes > up dialogs and their usages a lot. IMO a reinvite refreshes an invite > dialog usage. > >>> IMO an UPDATE is only permitted within an existing invite dialog usage. >> >> >> >>> So you would have to send an INVITE to establish the usage before you >> >> >> could use UPDATE to do a subsequent offer/answer. >> >> [CHH] Where is that said? I was looking in RFC 3311, and eventhough the >> text examples talk about INVITE initiated dialogs I didn't find any text >> forbidding it to be used elswhere. But, of course I may have missed >> it... > > > I doubt it is said anywhere. Its another thing that has evolved via > discussion, and enshrined in draft-sawada-sipping-sip-offeranswer-00. > >>>>> Q3: If Q2==TRUE, is it allowed to use re-INVITE, eventhough the >> >> >> dialog was not initiated using INVITE? >> >>>> See above. Beware that I have heard of no implementation that actually >> >> >> support this. >> >> [CHH] Neither have I - so far :) >> >> >>>> Q4: If Q1==TRUE, if I send an empty re-INVITE within a subscription >>>> dialog, e.g. to update the remote target, I assume the receiver MUST >>>> create and include an SDP offer in the 200 OK response, eventhough >>>> no media has previously been used within the dialog? >>> >>> >>> Again see above. The invite must follow all the normal rules. >>> >>> Note that as defined, all the usages of the dialog share the same >> >> >> targets. If you have a dialog shared by an invite usage and a subscribe >> usage, then >> >>> either a reinvite or a resubscribe will update the target they share in >> >> >> common. >> >> [CHH] I agree. It's still the same dialog, I think, eventhough there >> seem to be different "usage" of it. But, if you use (re-)INVITE, an SDP >> offer MUST be included (either in the request or response), according to >> the normal rules. > > > We are in violent agreement here. > >>> If you have just a subscription, and what to change the target, you can >> >> >> use a resubscribe. No need to use UPDATE or INVITE to accomplish that. >> >> [CHH] I agree. However, my main issue was not so much related to >> updating of the target, but more to the possibility to add media to an >> ongoing subscription dialog. > > > IMO the media is a property of an invite dialog usage. You can't add > media directly to a dialog, you must first add an invite dialog usage to > the dialog and then it can have media. I don't want to attempt drawing a > UML diagram here with text art, so I will try to do it with text: > > class: dialog > attribute: cseq > attribute: callid > attribute: to-tag > attribute: from-tag > attribute: route set > attribute: local contact > attribute: remote contact > attribute: ... > subclass: zero or one invite-dialog-usage > subclass: zero or more subscribe-dialog-usage > > class: invite-dialog-usage > attribute: expiration-time > attribute: active offer > attribute: active answer > attribute: offer/answer state > attribute: pending offer > attribute: pending answer > attribute: zero or more media-session > attribute: ... > > class: subscribe-dialog-usage > attribute: expiration-time > attribute: event-type > attribute: event-parameters > attribute: event-id > attribute: direction (watcher/notifier) > attribute: ... > _______________________________________________ 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 sip-bounces@ietf.org Tue Feb 28 09:39:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE5yM-00081G-Rx; Tue, 28 Feb 2006 09:37:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE5yM-000818-82 for sip@ietf.org; Tue, 28 Feb 2006 09:37:06 -0500 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE5yL-0005QK-26 for sip@ietf.org; Tue, 28 Feb 2006 09:37:06 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 9C2E46C01D for ; Tue, 28 Feb 2006 09:37:04 -0500 (EST) Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of DividingandConquering From: "Dale R. Worley" Cc: Sip In-Reply-To: <05B6D9FD-C811-4474-9701-4A1A7C79A40C@softarmor.com> References: <072C5B76F7CEAB488172C6F64B30B5E301245A9E@xmb-rtp-20b.amer.cisco.com> <05B6D9FD-C811-4474-9701-4A1A7C79A40C@softarmor.com> Content-Type: text/plain Date: Tue, 28 Feb 2006 09:37:04 -0500 Message-Id: <1141137424.20405.3.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mon, 2006-02-27 at 19:32 -0600, Dean Willis wrote: > Historically, IETF has tried to have working groups that last a year > or two and produce three or four documents. SIP, by itself, has > lasted almost 7 years so far (not counting when we were part of > MMUSIC) and has generated thousands of documents and 40 RFCs. And we > have another 20 or so RFCs in the pipeline. How have sessions and attendance at IETFs been doing? Are the number of people participating going up, too? Dale _______________________________________________ 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 sip-bounces@ietf.org Tue Feb 28 10:15:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE6Xq-0007Qh-5j; Tue, 28 Feb 2006 10:13:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE6Xo-0007QQ-Su for sip@ietf.org; Tue, 28 Feb 2006 10:13:44 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE6Xn-0006od-9P for sip@ietf.org; Tue, 28 Feb 2006 10:13:44 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 28 Feb 2006 07:13:44 -0800 X-IronPort-AV: i="4.02,153,1139212800"; d="scan'208"; a="1780474307:sNHT34535836" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k1SFDbuv006334; Tue, 28 Feb 2006 07:13:42 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Feb 2006 10:13:41 -0500 Received: from [192.168.1.104] ([10.86.240.111]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Feb 2006 10:13:40 -0500 Message-ID: <440468A4.80308@cisco.com> Date: Tue, 28 Feb 2006 10:13:40 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] Questions on subscription dialogs References: <5EB80D22825EEE42872083AD5BFFB5945D1ABC@esealmw113.eemea.ericsson.se> <440453A8.9020201@cisco.com> In-Reply-To: <440453A8.9020201@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Feb 2006 15:13:40.0797 (UTC) FILETIME=[8E9C86D0:01C63C79] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: IETF SIP List , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think most of the wisdom on dialog usages is captured in: http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialogusage-00.txt -Jonathan R. Paul Kyzivat wrote: > Christer, > > More in line. Once again we are spelling out the unwritten rules of > dialogs. > > Paul > > Christer Holmberg (JO/LMF) wrote: > >> Hi Paul, >> >> Thanks for your reply! Comments inline ([CHH]). >> >>>> Q1: Is it allowed to send non-NOTIFY request within a subscription >>>> dialog (initiated by SUBSCRIBE), assuming the users support it? >>>> >>> >>> Yes, with limits. In general, a request that is legal outside a dialog >> >> >> is also legal within a dialog. (E.g. OPTIONS.) In some cases (e.g. >> >>> MESSAGE) other limitations have been applied. (You aren't supposed to >> >> >> use MESSAGE within a dialog as a way to avoid session mode messaging.) >> >>> It is legal, though generally discouraged, to send requests within an >> >> >> existing dialog that establish a new dialog usage. Sending an INVITE >> within a >> >>> dialog established by a SUBSCRIBE falls into this category. >> >> >> >> [CHH] Is the discouragement documented somewhere? Or, is it just one of >> the "unwritten rules"? :) > > > I believe it has mostly been written in email threads here. I'm not sure > if it is enshrined in any RFC or draft. (I think it might be mentioned > in the target-dialog draft, and I think it might be mentioned in a draft > by ben or robert.) > > I know there was a discussion thread a few months ago about this. I was > nearly alone in advocating that shared dialogs are not always evil. > >>>> Q2: If Q1==TRUE, is it allowed to add media during a subscription >>>> dialog, by sending an SDP offer in an UPDATE/re-INVITE? >>> >>> >>> An INVITE in this case (at least the first one) would not be a >> >> >> reINVITE. >> >>> It would establish a new invite dialog usage within an already >> >> >> established dialog. >> >> [CHH] Well, it would contain a To tag, and I believe it is said >> somewhere that it then should be treated as a re-INVITE. But, at the end >> I guess it doesn't matter what we call it, as long as it is allowed to >> send it. > > > You may be right. The language in 3261 is very sloppy in this regard. It > implies, but doesn't formalize, the notion of dialog usages, and mixes > up dialogs and their usages a lot. IMO a reinvite refreshes an invite > dialog usage. > >>> IMO an UPDATE is only permitted within an existing invite dialog usage. >> >> >> >>> So you would have to send an INVITE to establish the usage before you >> >> >> could use UPDATE to do a subsequent offer/answer. >> >> [CHH] Where is that said? I was looking in RFC 3311, and eventhough the >> text examples talk about INVITE initiated dialogs I didn't find any text >> forbidding it to be used elswhere. But, of course I may have missed >> it... > > > I doubt it is said anywhere. Its another thing that has evolved via > discussion, and enshrined in draft-sawada-sipping-sip-offeranswer-00. > >>>>> Q3: If Q2==TRUE, is it allowed to use re-INVITE, eventhough the >> >> >> dialog was not initiated using INVITE? >> >>>> See above. Beware that I have heard of no implementation that actually >> >> >> support this. >> >> [CHH] Neither have I - so far :) >> >> >>>> Q4: If Q1==TRUE, if I send an empty re-INVITE within a subscription >>>> dialog, e.g. to update the remote target, I assume the receiver MUST >>>> create and include an SDP offer in the 200 OK response, eventhough >>>> no media has previously been used within the dialog? >>> >>> >>> Again see above. The invite must follow all the normal rules. >>> >>> Note that as defined, all the usages of the dialog share the same >> >> >> targets. If you have a dialog shared by an invite usage and a subscribe >> usage, then >> >>> either a reinvite or a resubscribe will update the target they share in >> >> >> common. >> >> [CHH] I agree. It's still the same dialog, I think, eventhough there >> seem to be different "usage" of it. But, if you use (re-)INVITE, an SDP >> offer MUST be included (either in the request or response), according to >> the normal rules. > > > We are in violent agreement here. > >>> If you have just a subscription, and what to change the target, you can >> >> >> use a resubscribe. No need to use UPDATE or INVITE to accomplish that. >> >> [CHH] I agree. However, my main issue was not so much related to >> updating of the target, but more to the possibility to add media to an >> ongoing subscription dialog. > > > IMO the media is a property of an invite dialog usage. You can't add > media directly to a dialog, you must first add an invite dialog usage to > the dialog and then it can have media. I don't want to attempt drawing a > UML diagram here with text art, so I will try to do it with text: > > class: dialog > attribute: cseq > attribute: callid > attribute: to-tag > attribute: from-tag > attribute: route set > attribute: local contact > attribute: remote contact > attribute: ... > subclass: zero or one invite-dialog-usage > subclass: zero or more subscribe-dialog-usage > > class: invite-dialog-usage > attribute: expiration-time > attribute: active offer > attribute: active answer > attribute: offer/answer state > attribute: pending offer > attribute: pending answer > attribute: zero or more media-session > attribute: ... > > class: subscribe-dialog-usage > attribute: expiration-time > attribute: event-type > attribute: event-parameters > attribute: event-id > attribute: direction (watcher/notifier) > attribute: ... > > _______________________________________________ > 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 Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.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 sip-bounces@ietf.org Tue Feb 28 11:26:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE7e4-0003a3-O4; Tue, 28 Feb 2006 11:24:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE7e2-0003ZY-QF for sip@ietf.org; Tue, 28 Feb 2006 11:24:14 -0500 Received: from firewall.objectworld.com ([72.1.207.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE7e1-0000qs-GK for sip@ietf.org; Tue, 28 Feb 2006 11:24:14 -0500 Received: from photon.objectworld.com (photon.objectworld.com [192.168.1.2]) by firewall.objectworld.com (8.12.11/8.12.11) with ESMTP id k1SGOB9m027746 for ; Tue, 28 Feb 2006 11:24:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] Re: [Sip] Thoughts on the Principle ofDividingandConquering Date: Tue, 28 Feb 2006 11:24:11 -0500 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C52EF769@photon.objectworld.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Re: [Sip] Thoughts on the Principle ofDividingandConquering Thread-Index: AcY8dICG4ndXvZPoR6yhboaDPANQhgADrs0w From: "Michael Slavitch" To: "Dale R. Worley" X-Spam-Score: 0.00 () [Tag at 15.00] X-CanItPRO-Stream: outgoing Content-Disposition: inline X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.1.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm surprised that in this day and age when I can have a multiuser=0A= conference with my mother and her cousins in three different countries=0A= that such meetings still have to be directly attended at all.=20=0A= =0A= M=0A= =0A= =20=0A= =20=0A= =20=0A= It is amazing what you can accomplish if you do not care who gets the=0A= credit.=20=0A= =20=0A= - Harry S Truman=0A= =0A= -----Original Message-----=0A= From: Dale R. Worley [mailto:dworley@pingtel.com]=20=0A= Sent: February 28, 2006 9:37 AM=0A= Cc: Sip=0A= Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle=0A= ofDividingandConquering=0A= =0A= On Mon, 2006-02-27 at 19:32 -0600, Dean Willis wrote:=0A= > Historically, IETF has tried to have working groups that last a year=20= =0A= > or two and produce three or four documents. SIP, by itself, has lasted=0A= =0A= > almost 7 years so far (not counting when we were part of=0A= > MMUSIC) and has generated thousands of documents and 40 RFCs. And we=20= =0A= > have another 20 or so RFCs in the pipeline.=0A= =0A= How have sessions and attendance at IETFs been doing? Are the number of=0A= people participating going up, too?=0A= =0A= Dale=0A= =0A= =0A= =0A= _______________________________________________=0A= Sip mailing list https://www1.ietf.org/mailman/listinfo/sip=0A= This list is for NEW development of the core SIP Protocol Use=0A= sip-implementors@cs.columbia.edu for questions on current sip Use=0A= sipping@ietf.org for new developments on the application of sip=0A= =0A= =0A= --=0A= =0A= =0A= -----------------------------------------------=0D=0A= =0D=0A= This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. =0D=0A= =0D=0A= Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp= .=20=0A= _______________________________________________ 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 sip-bounces@ietf.org Tue Feb 28 11:33:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE7l6-0007R4-Re; Tue, 28 Feb 2006 11:31:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE7l5-0007Nq-Do for sip@ietf.org; Tue, 28 Feb 2006 11:31:31 -0500 Received: from smtp3.wanadoo.co.uk ([193.252.22.156] helo=smtp3.freeserve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE7l3-00011q-WC for sip@ietf.org; Tue, 28 Feb 2006 11:31:31 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3202.me.freeserve.com (SMTP Server) with ESMTP id F1C501C0008C for ; Tue, 28 Feb 2006 17:31:28 +0100 (CET) Received: from RW (user-6256.lns2-c7.dsl.pol.co.uk [84.65.184.112]) by mwinf3202.me.freeserve.com (SMTP Server) with SMTP id B3D3B1C00082 for ; Tue, 28 Feb 2006 17:31:28 +0100 (CET) X-ME-UUID: 20060228163128736.B3D3B1C00082@mwinf3202.me.freeserve.com Message-ID: <00b901c63c84$6b77a2b0$b100a8c0@RW> From: "Pete Cordell" To: "IETF SIP List" References: <4400BE40.9080207@cisco.com><44032336.4030606@lucent.com> <17411.23980.393969.239892@rautu.tutpro.com> <440392C4.7090404@acm.org><17412.691.95314.608716@rautu.tutpro.com> <44046EB5.3050701@cisco.com> Date: Tue, 28 Feb 2006 16:31:07 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [Sip] Using ABNF incremental rules to extend SIP grammer X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Apologies if this has been discussed before, but I quickly scanned Jonathan's recently mentioned draft, and it occurred to me that the grammar for the SIP extensions could be made more formal using ABNF's incremental rules. As you no doubt recall from rfc4234: ruleset = alt1 / alt2 ruleset =/ alt3 ruleset =/ alt4 / alt5 is the same as specifying ruleset = alt1 / alt2 / alt3 / alt4 / alt5 Thus the grammar specified in Jonathan's document could have been made more formal by doing: message-header =/ Anonymous-To ; Extended from RFC3261 Anonymous-To = "Anonymous-To" HCOLON ( name-addr / addr-spec ) *( SEMI generic-param ) option-tag =/ anonymous-tag ; Extended from RFC3261 anonymous-tag = "anonymous" other-user =/ "anonymous" Similarly, the grammar from draft-ietf-sip-answermode-00.txt, could be augmented to become: message-header =/ Answer-Mode / Priv-Answer-Mode ; Extended from RFC3261 Answer-Mode = "Answer-Mode" HCOLON answer-mode-param *(SEMI answer-mode-option) Priv-Answer-Mode = "Priv-Answer-Mode" HCOLON answer-mode-param *(SEMI answer-mode-option) answer-mode-param = "Manual" / "Auto" / generic-param answer-mode-option = "require" / token As code will often be generated from the ABNF definition, or manually created parsers will often include the ABNF as comments, it seems to me that this would reduce the scope for errors in implementation, with only minor effort from the document editors. Pete. -- ============================================= Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx (or http://www.xml2cpp.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 sip-bounces@ietf.org Tue Feb 28 13:26:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE9W8-0004HG-0b; Tue, 28 Feb 2006 13:24:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE9W5-0004Cd-TM; Tue, 28 Feb 2006 13:24:09 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE9W4-0004wt-IE; Tue, 28 Feb 2006 13:24:09 -0500 Received: from localhost (rohan@localhost) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k1SINvp06092; Tue, 28 Feb 2006 10:23:58 -0800 X-Authentication-Warning: figas.ekabal.com: rohan owned process doing -bs Date: Tue, 28 Feb 2006 10:23:57 -0800 (PST) From: Rohan Mahy To: Aki Niemi Subject: Re: [Sipping] Re: [Sip] Thoughts on the Principle of Dividing and Conquering In-Reply-To: <440400E5.1060205@nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 1.2 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Cullen Jennings , Jon Peterson , Allison Mankin , "sip@ietf.org List" , Dean Willis , Sipping List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Aki, I certainly agree that a small number of busy authors creates a huge bottleneck for us. That said, the review time of the entire working group (including many of the contributors who also author documents) is also spread too thin. If a WG is clearly focused on a small set of documents, and the WG is prompt and thorough about reviewing those documents and can even get early implementation experience with a small number of documents, this causes a huge incentive to the author to prioritize this work. If the WG takes a long time to review or come to consensus, the author/editor won't feel the same sense of urgency. thanks, -rohan On Tue, 28 Feb 2006, Aki Niemi wrote: > Inline. > > ext Rohan Mahy wrote: > > I think mostly we have a problem saying no. We have too much work to do > > and the only effective way for this community to get better throughput > > is to focus religiously on a much smaller handful of work items (ex: 4 > > or 5) at a time. I am as guilty as the next person for adding new > > milestones (actually, more guilty as a chair), but it is hard to say no > > to new work when old work that is "almost done" takes so long to finish. > > I don't think this will help much. These core efforts are concentrated > to a very small number of authors, perhaps as few as 2-3. How would > saying that the rest will need to stop working on their drafts help > speed up the work done by these 2-3 authors? > > Granted, the few core authors are doing an excellent job, but I wonder > if there's anything we could do to balance the load. I just can't see > that the work amount can be carried by such few authors in the long run. > Especially since these same people are holding various other positions > in the IETF at the same time. > > Cheers, > Aki > _______________________________________________ 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