From mailnull@www1.ietf.org Wed Jan 1 07:27:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03323 for ; Wed, 1 Jan 2003 07:27:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h01CZPq28710 for sip-archive@odin.ietf.org; Wed, 1 Jan 2003 07:35:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h01CVdJ28611; Wed, 1 Jan 2003 07:31:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h01CPwJ28485 for ; Wed, 1 Jan 2003 07:25:59 -0500 Received: from protactinium.btinternet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03250 for ; Wed, 1 Jan 2003 07:17:39 -0500 (EST) Received: from host62-6-93-123.in-addr.btopenworld.com ([62.6.93.123] helo=tkw) by protactinium.btinternet.com with smtp (Exim 3.22 #16) id 18ThrZ-0006Vk-00; Wed, 01 Jan 2003 12:20:45 +0000 Message-ID: <000201c2b190$3c17e0c0$0200000a@tkw> From: "Pete Cordell" To: "Jonathan Rosenberg" , References: <3E0B6293.4030600@dynamicsoft.com> Subject: Re: [Sip] INFO considered harmful Date: Wed, 1 Jan 2003 11:43:45 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit How about we use new methods to define end-to-end application data, but name the messages INFO-*. e.g. INFO-MY-FEATURE, so that they can be readily identified as application data rather than SIP state affecting methods. Allow: can then be used to negotiate 'INFO' extensions. - It's easy to parse. - It's very easy for a stack to treat it generically. - It can reuse existing SIP features to do negotiation etc. (e.g. Allow) - It could be easily documented in the SIP usage document. My other thoughts on the subject (and what has led me to the above position are): - I think its important to have some mechanism that allows end-to-end application data exchange that is independent of SIP state. - Doing this in-band (rather than starting up potentially numerous side connections) will be desirable for some applications (such as those that use a small amounts of data). - It seems appealing to be readily able to tell which methods affect SIP state, and which is application level data. - Require:, Supported: and Allow: already negotiation of features and where possible it would be beneficial to re-use these mechanisms rather than invent new ones.. - An INFO mechanism does not need to offer any semantics beyond simple data delivery (although it might be nice to have an in-order delivery service?) (and the afore mentioned negotiation). - The main problem with INFO is that it doesn't give a single specific way of identifying which application a particular INFO method is related to. Hence it necessitates some sort of heuristic procedure to be used. Some other ways to move ahead might be to: - Specify that the application that the INFO corresponds to is defined by the MIME type of the body. - Define a new header that defines the application that the INFO corresponds to. Pete. ----- Original Message ----- From: "Jonathan Rosenberg" To: Sent: 26 December 2002 20:12 Subject: [Sip] INFO considered harmful > Folks, > > For some time, I've been complaining about the continued abuse of the > INFO method for things that should be done other ways (frequently, not > using sip at all). I've written up a summary of the problems and a > proposed path forward. Specifically, I'd like to obsolete INFO and > replace it with a spec that is approved ONLY for SIP-T. > > Until the I-D appears, you can pick up a version at: > > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.html > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Jan 1 14:48:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13054 for ; Wed, 1 Jan 2003 14:48:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h01Juk721332 for sip-archive@odin.ietf.org; Wed, 1 Jan 2003 14:56:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h01JqtJ21229; Wed, 1 Jan 2003 14:52:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h01JmGJ21157 for ; Wed, 1 Jan 2003 14:48:16 -0500 Received: from gorilla.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12997 for ; Wed, 1 Jan 2003 14:39:49 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id UAA25414 for ; Wed, 1 Jan 2003 20:42:57 +0100 (MET) Received: from siemens.com ([139.25.62.39]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id UAA25437 for ; Wed, 1 Jan 2003 20:42:59 +0100 (MET) Message-ID: <3E1344F4.5040008@siemens.com> Date: Wed, 01 Jan 2003 20:43:48 +0100 From: Peter =?UTF-8?B?UMOkcHBpbmdoYXVz?= Organization: Siemens AG User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en,de MIME-Version: 1.0 To: sip@ietf.org Subject: Repost: [Sip] Buggy example in RFC 3261 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I have posted this earlier, but it seems to have gone unnoticed. Hi, I believe to have stumbled on a buggy example in RFC 3261. The 200 OK in the REGISTER example of RFC 3261, sec. 24.1 contains an Expires header, but no expires parameter in the Contact header. This violates RFC 3261, sec. 10.3, bullet 8: "Each Contact value MUST feature an "expires" parameter indicating its expiration interval chosen by the registrar." Regards, Peter Paeppinghaus -- Dr. Peter Päppinghaus Siemens AG | Phone: +49 89 - 722 40065 ICM N PG U ID A1 | Fax: +49 89 - 722 58726 Hofmannstr. 51 | Visitors: Building 1713 / Room 714 D - 81359 München | Email: peter.paeppinghaus@siemens.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 2 00:04:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18876 for ; Thu, 2 Jan 2003 00:04:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h025CsV14659 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 00:12:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02591J14508; Thu, 2 Jan 2003 00:09:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0256SJ13825 for ; Thu, 2 Jan 2003 00:06:28 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18738 for ; Wed, 1 Jan 2003 23:57:50 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.143]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h02512YH024391; Thu, 2 Jan 2003 00:01:02 -0500 (EST) Message-ID: <3E13C78B.5080906@dynamicsoft.com> Date: Thu, 02 Jan 2003 00:00:59 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?UTF-8?B?UGV0ZXIgUMOkcHBpbmdoYXVz?= CC: sip@ietf.org Subject: Re: Repost: [Sip] Buggy example in RFC 3261 References: <3E1344F4.5040008@siemens.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Sorry for not responding. I did notice this. There is an error here, as you point out. What is NOT clear is whether the error is in the example, or in the normative text. For REGISTER requests, you can use either the Expires header field or the expires contact header field parameter. It seems odd that this same rule would not apply to REGISTER responses. My personal recollection was that either the Expires header field or the expires contact param was OK for either request or response. This doesn't match the normative text though. Does anyone use the Expires header field and NOT the expires contact param in REGISTER responses? -Jonathan R. Peter Päppinghaus wrote: > I have posted this earlier, but it seems to have gone > unnoticed. > > Hi, > > I believe to have stumbled on a buggy example in RFC 3261. > > The 200 OK in the REGISTER example of RFC 3261, sec. 24.1 contains > an Expires header, but no expires parameter in the Contact header. > > This violates RFC 3261, sec. 10.3, bullet 8: > "Each Contact value MUST feature an "expires" parameter > indicating its expiration interval chosen by the registrar." > > Regards, > > Peter Paeppinghaus > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 2 00:05:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18892 for ; Thu, 2 Jan 2003 00:05:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h025DY414690 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 00:13:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h025A8J14573; Thu, 2 Jan 2003 00:10:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0257fJ14462 for ; Thu, 2 Jan 2003 00:07:41 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18759 for ; Wed, 1 Jan 2003 23:59:03 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.143]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0252GYH024394; Thu, 2 Jan 2003 00:02:16 -0500 (EST) Message-ID: <3E13C7D5.7030605@dynamicsoft.com> Date: Thu, 02 Jan 2003 00:02:13 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?UTF-8?B?UGV0ZXIgUMOkcHBpbmdoYXVz?= CC: sip@ietf.org Subject: Re: Repost: [Sip] Buggy example in RFC 3261 References: <3E1344F4.5040008@siemens.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit PS, a bugzilla bug was logged against this some time back: http://www.sipwg.org/sipwg/show_bug.cgi?id=682 -Jonathan R. Peter Päppinghaus wrote: > I have posted this earlier, but it seems to have gone > unnoticed. > > Hi, > > I believe to have stumbled on a buggy example in RFC 3261. > > The 200 OK in the REGISTER example of RFC 3261, sec. 24.1 contains > an Expires header, but no expires parameter in the Contact header. > > This violates RFC 3261, sec. 10.3, bullet 8: > "Each Contact value MUST feature an "expires" parameter > indicating its expiration interval chosen by the registrar." > > Regards, > > Peter Paeppinghaus > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 2 00:07:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18963 for ; Thu, 2 Jan 2003 00:07:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h025FY114763 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 00:15:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h025C7J14642; Thu, 2 Jan 2003 00:12:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h025BcJ14615 for ; Thu, 2 Jan 2003 00:11:38 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18857 for ; Thu, 2 Jan 2003 00:03:00 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.143]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0256DYH024398; Thu, 2 Jan 2003 00:06:13 -0500 (EST) Message-ID: <3E13C8C2.3060206@dynamicsoft.com> Date: Thu, 02 Jan 2003 00:06:10 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Amit Bhadoria CC: sip@ietf.org Subject: Re: [Sip] TLS: how to validate multiple domains with single certificate (fwd) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit response inline. Amit Bhadoria wrote: > repost from yesterday... > > ---------- Forwarded message ---------- > Date: Mon, 30 Dec 2002 17:20:50 -0800 (PST) > From: Amit Bhadoria > To: sip@ietf.org > Subject: [TLS] how to validate multiple domains with single certificate > > hi, > > i have some questions based on rfc 3263 "locating sip services". in > rfc 3263 it is mentioned that: > "For NAPTR records with SIPS protocol fields, (if the server is using > a site certificate), the domain name in the query and the domain name > in the replacement field MUST both be valid based on the site > certificate handed out by the server in the TLS exchange. Similarly, > the domain name in the SRV query and the domain name in the target in > the SRV record MUST both be valid based on the same site certificate. > Otherwise, an attacker could modify the DNS records to contain > replacement values in a different domain, and the client could not > validate that this was the desired behavior or the result of an > attack." > > now, there are three potentially different domains in concern while > processing a SIPS request: > 1. domain used in NAPTR querry: this is the target domain for this > request > 2. domain mentioned in replacement field of NAPTR records: this > is the domain used in the SRV querry, obtained from replacement > field of NAPTR records > 3. domain mentioned in target in the SRV record: the domain > mentioned in the SRV record selected for final A lookup > > is it possible to have all the three domains different, or is it just a > bad example (due to my limited knowledge of DNS setups), and in practical > cases the three domains will either be same as TARGET or a subdomain of > it? They can be different as far as DNS is concerned, but the point of the text is to say that for SIPS URIs, they generally shouldn't be. Otherwise, there is this potential DNS attack. I say "generally" because it is possible for a single site certificate to be valid for multiple domains. In that case, so long as the domains in the DNS were all valid for that single certificate, its OK to use different domains. But, this is rare I think. > > incase my imagination is correct, and it is possible to have a setup where > all three domains (from three steps of DNS procedures) are different, then > how can a client validate these three domains using the same certificate? It can't. Thats why the domains really can't be different. The only exception is if single site certificate can validate multiple domains. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 2 00:48:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19455 for ; Thu, 2 Jan 2003 00:48:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h025uGw16486 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 00:56:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h025qLJ16365; Thu, 2 Jan 2003 00:52:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h025pEJ16317 for ; Thu, 2 Jan 2003 00:51:14 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19381 for ; Thu, 2 Jan 2003 00:42:31 -0500 (EST) Received: from Natarajucl1127 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H8200968NX7XF@mta0.huawei.com> for sip@ietf.org; Thu, 02 Jan 2003 13:44:00 +0800 (CST) Date: Thu, 02 Jan 2003 11:16:41 +0530 From: "Nataraju A.B." Subject: Re: [Sip] A simple query... To: Jonathan Rosenberg Cc: sip@ietf.org Message-id: <003101c2b222$550924d0$5d02120a@in.huawei.com> Organization: Huawei Technologies India Pvt. Ltd., MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_OpowXGA61r7iJ+ETTzIEeA)" X-Priority: 3 X-MSMail-priority: Normal References: <004401c2a85e$99855700$618d6b80@amer.cisco.com> <3E0375E7.1080608@dynamicsoft.com> <1040415671.949.161.camel@RjS.localdomain> <15888.48291.700746.59246@thomasm-u1.cisco.com> <15889.35402.270711.303036@lohi.eng.song.fi> <004401c2b0ce$627520b0$5d02120a@in.huawei.com> <3E11AB76.5080903@dynamicsoft.com> Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_OpowXGA61r7iJ+ETTzIEeA) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi, Server = "Server" HCOLON server-val *(LWS server-val) server-val = product / comment product = token [SLASH product-version] product-version = token both product and product version are of type tokens. if two tokes are in the input what should be considered. I mean product an dprod version OR two product values. for ex : Server: HomeServer HS v2 in this case HS is prod version or product2. Regards, ------------------------------------------- Nataraju A.B. Huawei Technologies India Pvt. Ltd., Tel : +91-80-5216824/6/7 Xtn 142 ------------------------------------------- ----- Original Message ----- From: Jonathan Rosenberg To: Nataraju A.B. Cc: sip@ietf.org Sent: Tuesday, 31 December 2002 20-06 Subject: Re: [Sip] A simple query... inline. Nataraju A.B. wrote: > Hi, > I have a query regarding the server/user-agent coding format: > The ABNF encoding specifies it as : > > Server = "Server" HCOLON server-val *(LWS server-val) > server-val = product / comment > product = token [SLASH product-version] > product-version = token > > whereas teh SIP-rfc says it should be > Server: HomeServer v2 > CanI know the correct format to be used. The above is just an example of the server header. It is a valid value according to the BNF, since the BNF allows a series of lws-separated tokens, without any slashes. Thus, either of these is valid: Server: HomeServer v2 Server: HomeServer/v2 > > If the SIP format is to be used then is it product version is a > mandatory argument. Version is not mandatory according to the BNF. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --Boundary_(ID_OpowXGA61r7iJ+ETTzIEeA) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi,
 
Server           =  "Server" HCOLON server-val *(LWS server-val)
 server-val       =  product / comment

product          =  token [SLASH product-version]

product-version  =  token

both product and product version are of type tokens.
if two tokes are in the input what should be considered. I mean product an dprod version OR two product values.
 
 for ex : Server: HomeServer HS v2
in this case HS is prod version or product2.
 
Regards,
-------------------------------------------
Nataraju A.B.
Huawei Technologies India Pvt. Ltd.,
Tel : +91-80-5216824/6/7 Xtn 142
-------------------------------------------
----- Original Message -----
Sent: Tuesday, 31 December 2002 20-06
Subject: Re: [Sip] A simple query...

inline.

Nataraju A.B. wrote:
> Hi,
> I have a query regarding the server/user-agent coding format:
> The ABNF encoding specifies it as :
> 
> Server           =  "Server" HCOLON server-val *(LWS server-val)
> server-val       =  product / comment
> product          =  token [SLASH product-version]
> product-version  =  token
> 
> whereas teh SIP-rfc says it should be
>  Server: HomeServer v2
> CanI know the correct format to be used.

The above is just an example of the server header. It is a valid value
according to the BNF, since the BNF allows a series of lws-separated
tokens, without any slashes. Thus, either of these is valid:

Server: HomeServer v2
Server: HomeServer/v2


> 
> If the SIP format is to be used then is it product version is a
> mandatory argument.

Version is not mandatory according to the BNF.

-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--Boundary_(ID_OpowXGA61r7iJ+ETTzIEeA)-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 2 06:26:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02820 for ; Thu, 2 Jan 2003 06:26:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02BZCX14583 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 06:35:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02BVLJ14427; Thu, 2 Jan 2003 06:31:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02BTsJ14330 for ; Thu, 2 Jan 2003 06:29:54 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02795 for ; Thu, 2 Jan 2003 06:21:07 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h02BNiL12265; Thu, 2 Jan 2003 11:23:49 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Jan 2003 11:23:45 -0000 Message-ID: From: "Mark Watson" To: "'Peterson, Jon'" , "'Jonathan Rosenberg'" , sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Thu, 2 Jan 2003 11:23:42 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B251.6756F584" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2B251.6756F584 Content-Type: text/plain; charset="iso-8859-1" Jon, There may be alternatives to INFO for everything in ANSI ISUP, but in ITU-T there is the Application Transport Message (APM). The purpose of this is, ...err..., to transparently transport Application layer information. I think any new method defined for carrying this would end up with identical semantics to 'INFO restricted to SIP-T' as proposed in Jonathan's draft - namely 'transport of application layer information, with the restriction that the application layer is SIP-T'. If you wanted to restrict its use to APM, this is something you would restrict at the SIP-T application layer, not in SIP. ...Mark > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: 30 December 2002 19:46 > To: 'Jonathan Rosenberg'; sip@ietf.org > Subject: RE: [Sip] INFO considered harmful > > > > First, I think it is a really good idea to restrict the > applicability of SIP > INFO method - I very much agree with the problem defined in > Section 2 of > this draft. > > That much said, when it comes to solutions I am torn between > option number 3 > and a more radical alternative - deprecating INFO altogether. > While it is > true that INFO was inspired by some of the requirements of > SIP-T, over time, > we've found less and less use for INFO. The original vision > for SIP+ (an > ancestor of SIP-T) relied on INFO for sending virtually every > ISUP message, > but today, there just isn't that much that we do with INFO. > Practically > speaking, we could probably find alternatives to INFO for > carrying ISUP data > in these cases (which include SUS/RES, INF/INR, some > provisional response > cases). Using INFO to send other ISUP messages is frequently > misguided, and > can potentially lead to the same sorts of interoperability > problems we have > with INFO in other arenas. > > Today, however, RFC3398 does allow the use of INFO in these > three cases, so > it's simplest to let the INFO method to exist (option 3) for > the time being > - but we should be sure to document, even for ISUP > transmissions, the cases > in which it is and is not appropriate. In the long term, > though, I think we > should just get rid of it entirely. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Thursday, December 26, 2002 12:12 PM > > To: sip@ietf.org > > Subject: [Sip] INFO considered harmful > > > > > > Folks, > > > > For some time, I've been complaining about the continued > abuse of the > > INFO method for things that should be done other ways > > (frequently, not > > using sip at all). I've written up a summary of the problems and a > > proposed path forward. Specifically, I'd like to obsolete INFO and > > replace it with a spec that is approved ONLY for SIP-T. > > > > Until the I-D appears, you can pick up a version at: > > > > > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt > > > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.html > > > > Thanks, > > Jonathan R. > > -- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------_=_NextPart_001_01C2B251.6756F584 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] INFO considered harmful

Jon,

There may be alternatives to INFO for everything in = ANSI ISUP, but in ITU-T there is the Application Transport Message = (APM). The purpose of this is, ...err..., to transparently transport = Application layer information.

I think any new method defined for carrying this = would end up with identical semantics to 'INFO restricted to SIP-T' as = proposed in Jonathan's draft - namely 'transport of application layer = information, with the restriction that the application layer is = SIP-T'.

If you wanted to restrict its use to APM, this is = something you would restrict at the SIP-T application layer, not in = SIP.

...Mark

> -----Original Message-----
> From: Peterson, Jon [mailto:jon.peterson@neustar.biz= ]
> Sent: 30 December 2002 19:46
> To: 'Jonathan Rosenberg'; sip@ietf.org
> Subject: RE: [Sip] INFO considered = harmful
>
>
>
> First, I think it is a really good idea to = restrict the
> applicability of SIP
> INFO method - I very much agree with the = problem defined in
> Section 2 of
> this draft.
>
> That much said, when it comes to solutions I am = torn between
> option number 3
> and a more radical alternative - deprecating = INFO altogether.
> While it is
> true that INFO was inspired by some of the = requirements of
> SIP-T, over time,
> we've found less and less use for INFO. The = original vision
> for SIP+ (an
> ancestor of SIP-T) relied on INFO for sending = virtually every
> ISUP message,
> but today, there just isn't that much that we = do with INFO.
> Practically
> speaking, we could probably find alternatives = to INFO for
> carrying ISUP data
> in these cases (which include SUS/RES, INF/INR, = some
> provisional response
> cases). Using INFO to send other ISUP messages = is frequently
> misguided, and
> can potentially lead to the same sorts of = interoperability
> problems we have
> with INFO in other arenas.
>
> Today, however, RFC3398 does allow the use of = INFO in these
> three cases, so
> it's simplest to let the INFO method to exist = (option 3) for
> the time being
> - but we should be sure to document, even for = ISUP
> transmissions, the cases
> in which it is and is not appropriate. In the = long term,
> though, I think we
> should just get rid of it entirely.
>
> Jon Peterson
> NeuStar, Inc.
>
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> > Sent: Thursday, December 26, 2002 12:12 = PM
> > To: sip@ietf.org
> > Subject: [Sip] INFO considered = harmful
> >
> >
> > Folks,
> >
> > For some time, I've been complaining about = the continued
> abuse of the
> > INFO method for things that should be done = other ways
> > (frequently, not
> > using sip at all). I've written up a = summary of the problems and a
> > proposed path forward. Specifically, I'd = like to obsolete INFO and
> > replace it with a spec that is approved = ONLY for SIP-T.
> >
> > Until the I-D appears, you can pick up a = version at:
> >
> >
> http://www.jdrosen.net/papers/draft-rosenberg-sip-info= -harmful-00.txt
> >
> http://www.jdrosen.net/papers/draft-rosenberg-sip-info= -harmful-00.html
> >
> > Thanks,
> > Jonathan R.
> > --
> > Jonathan D. Rosenberg, = Ph.D.           &= nbsp;    72 Eagle Rock Ave.
> > Chief = Scientist          &nb= sp;           &nb= sp;      First Floor
> > = dynamicsoft          &= nbsp;           &= nbsp;          East = Hanover, NJ 07936
> > = jdrosen@dynamicsoft.com        &= nbsp;            = FAX:   (973) 952-5050
> > http://www.jdrosen.net    &nbs= p;           &nbs= p;     PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> >
> > = _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the = core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for = questions on current sip
> > Use sipping@ietf.org for new developments = on the application of sip
> >
> = _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP Protocol
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sipping@ietf.org for new developments on = the application of sip
>

------_=_NextPart_001_01C2B251.6756F584-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 2 09:29:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05264 for ; Thu, 2 Jan 2003 09:29:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02EcBH27321 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 09:38:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02EYZJ26470; Thu, 2 Jan 2003 09:34:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02EWaJ26356 for ; Thu, 2 Jan 2003 09:32:36 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05101 for ; Thu, 2 Jan 2003 09:23:45 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h02ESmt27823 for ; Thu, 2 Jan 2003 16:28:48 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 2 Jan 2003 16:22:16 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 2 Jan 2003 16:22:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: RE: Repost: [Sip] Buggy example in RFC 3261 Date: Thu, 2 Jan 2003 16:22:15 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE70A3@esebe019.ntc.nokia.com> Thread-Topic: Repost: [Sip] Buggy example in RFC 3261 Thread-Index: AcKyHbA1yhcH/+e7R56DEwT6A5IYvgAS0aiA To: , Cc: X-OriginalArrivalTime: 02 Jan 2003 14:22:16.0603 (UTC) FILETIME=[5A001EB0:01C2B26A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h02EWaJ26357 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit This is an extract from a discussion I had with Robert Sparks: > >Yes, that was exactly what I asked. If its not so, what does an Expires > >header in a 200 OK for a REGISTER mean? > > >As I note above, with the current text an Expire header field has no meaning >if it appears in a 200 response to a REGISTER request. http://www.ietf.org/mail-archive/working-groups/sip/current/msg03602.html Regards, Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, January 02, 2003 7:01 AM > To: Peter Päppinghaus > Cc: sip@ietf.org > Subject: Re: Repost: [Sip] Buggy example in RFC 3261 > > > Sorry for not responding. I did notice this. There is an > error here, as > you point out. What is NOT clear is whether the error is in > the example, > or in the normative text. For REGISTER requests, you can use > either the > Expires header field or the expires contact header field > parameter. It > seems odd that this same rule would not apply to REGISTER > responses. My > personal recollection was that either the Expires header field or the > expires contact param was OK for either request or response. This > doesn't match the normative text though. > > Does anyone use the Expires header field and NOT the expires contact > param in REGISTER responses? > > -Jonathan R. > > Peter Päppinghaus wrote: > > I have posted this earlier, but it seems to have gone > > unnoticed. > > > > Hi, > > > > I believe to have stumbled on a buggy example in RFC 3261. > > > > The 200 OK in the REGISTER example of RFC 3261, sec. 24.1 contains > > an Expires header, but no expires parameter in the Contact header. > > > > This violates RFC 3261, sec. 10.3, bullet 8: > > "Each Contact value MUST feature an "expires" parameter > > indicating its expiration interval chosen by the registrar." > > > > Regards, > > > > Peter Paeppinghaus > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 2 11:30:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07799 for ; Thu, 2 Jan 2003 11:30:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02GcQA03380 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 11:38:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02GYZJ02627; Thu, 2 Jan 2003 11:34:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02GWUJ02559 for ; Thu, 2 Jan 2003 11:32:30 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07694 for ; Thu, 2 Jan 2003 11:23:39 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.143]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h02GQnYH024558; Thu, 2 Jan 2003 11:26:51 -0500 (EST) Message-ID: <3E146845.5020707@dynamicsoft.com> Date: Thu, 02 Jan 2003 11:26:45 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Nataraju A.B." CC: sip@ietf.org Subject: Re: [Sip] A simple query... References: <004401c2a85e$99855700$618d6b80@amer.cisco.com> <3E0375E7.1080608@dynamicsoft.com> <1040415671.949.161.camel@RjS.localdomain> <15888.48291.700746.59246@thomasm-u1.cisco.com> <15889.35402.270711.303036@lohi.eng.song.fi> <004401c2b0ce$627520b0$5d02120a@in.huawei.com> <3E11AB76.5080903@dynamicsoft.com> <003101c2b222$550924d0$5d02120a@in.huawei.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Nataraju A.B. wrote: > Hi, > > Server = "Server" HCOLON server-val *(LWS server-val) > server-val = product / comment > > product = token [SLASH product-version] > > product-version = token > > both product and product version are of type tokens. > if two tokes are in the input what should be considered. I mean product > an dprod version OR two product values. > > for ex : Server: *HomeServer HS v2* > in this case HS is prod version or product2. Its a second product. Version requires a slash. As a result, the example in the SIP spec which you quoted would have v2 parse as a product, not a version. Thats fine. This field is only useful for display to humans or for string comparison, in which case it doesnt matter whether the "v2" is interpreted as a product version or a product. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 2 12:34:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09174 for ; Thu, 2 Jan 2003 12:34:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02HgN907992 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 12:42:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02HcWJ07713; Thu, 2 Jan 2003 12:38:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02HagJ07008 for ; Thu, 2 Jan 2003 12:36:42 -0500 Received: from hclnpd.hclt.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08998 for ; Thu, 2 Jan 2003 12:27:48 -0500 (EST) Received: from blaze.hcltech.com (blaze.hclt-ntl.co.in [192.168.19.30]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y1WDHL1X; Thu, 2 Jan 2003 23:01:48 +0530 Received: from sachin-pc.netlab.hcltech.com ([192.168.201.60]) by blaze.hcltech.com (8.9.3/8.9.3) with ESMTP id XAA25753; Thu, 2 Jan 2003 23:28:34 +0530 Message-Id: <4.3.2.7.0.20030102223536.036c2980@blaze> X-Sender: sachins@blaze X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 02 Jan 2003 22:52:26 +0530 To: Jonathan Rosenberg From: Sachin Shenoy Subject: Re: [Sip] Loop detection; Not a bad thing to have Cc: sip@ietf.org In-Reply-To: <3E11AC8D.5090700@dynamicsoft.com> References: <006001c2af6e$9ed02660$a5f1fea9@sachinhome> <4.3.2.7.0.20021231124454.00e19220@blaze> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Please find my comments inline. >>I have to take your word on this (that loops are rare). But sure it >>creates havoc once >>it happens. (Simple tests where request from UA looped between 2 proxies >>ran for more >>than 10 minutes. > >That should not happen. Max-Forwards should be preventing that. > >>Where re transmissions of original INVITE from UA, the "Too Many hops" >>response and ACK for this just kept on circulating). > >The INVITE should not be retransmitted once the final response has arrived. > >It seems your problems are the result of faulty software, not an incorrect >approach to handling loops. Yes indeed, as you said, the problem was due to faulty software (or wrong configuration in this case). Mistake was on my part for having enabled full fledged debug logging for this test. This slowed down the stack considerably. When the tests were rerun, with logging turned off, it went through without even the slightest hiccup. The whole transaction got completed in less than a second. (UAC only re-transmitted the INVITE once which did not create any problem). Thanks Sachin _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 2 12:37:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09232 for ; Thu, 2 Jan 2003 12:37:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02HjQn08105 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 12:45:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02Hf9J07912; Thu, 2 Jan 2003 12:41:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02HeLJ07850 for ; Thu, 2 Jan 2003 12:40:21 -0500 Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09119 for ; Thu, 2 Jan 2003 12:31:28 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message Subject: RE: [Sip] INFO considered harmful MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 2 Jan 2003 12:34:37 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D248639@zoe.office.snowshore.com> Thread-Topic: [Sip] INFO considered harmful Thread-Index: AcKwmsBwcvA7w11qT6eyw/BTjA7N6QB08o2w From: "Eric Burger" To: "Dean Willis" , "Jonathan Rosenberg" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h02HeLJ07851 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I fully agree with Dean on this one. One point to consider (I'm on the fence on this one) is whether we would say that INFO is 100% application-specific. That is, the WG will not publish standard body types. A reason for doing that is to let people know that INFO really is just, as Dean points out, application-to-application communication. If you want applications to interoperate, take it either to an Application Area WG or take it outside the IETF. One reason to not do this is SIP-T should use a method other than INFO. That said, I don't think there are that many SIP-T implementations extant. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, December 31, 2002 1:48 AM > To: Jonathan Rosenberg; Orit Levin > Cc: sip@ietf.org > Subject: Re: [Sip] INFO considered harmful > > > At 12:48 AM 12/31/2002 -0500, Jonathan Rosenberg wrote: > >Orit Levin wrote: > >>>The big huge difference I have been trying to point out is > that EVENTS > >>>DEFINES SEMANTICS, whereas INFO doesnt. > >>>MIME provides semantics and syntax that are independent of > the type. > >>>SIP events provides semantics and syntax that are > independent of the > >>>package. > >>>INFO provides nothing. > >> > >>INFO provides "minimal" but very important semantics: > asynchronous data > >>reliably follows the established SIP path. > > > >Huh? > > > >Every new SIP method is reliable, it inherits the SIP > transaction state > >machine for non-invite. Follows the established path? Every > in-dialog > >method would have this property, it is method independent. > >Asynchronous? You can send any method at any time. > > > >Thus, nothing you have pointed out above is different > between INFO and any > >other new method we might introduce. > > I think the key point is that there is a difference between transport > protocol semantic and application semantic. The transport > protocol semantic > expressed in INFO is "Here is some data that will be used by the > application. It is not important to the transport protocol, > except that the > transport protocol is expected to deliver it reliably". INFO > says NOTHING > about the APPLICATION level semantic -- that's up to what > goes IN the INFO > payloads. The question is -- do we try to rigidly define > application-level > semantics here? Do we define that there ARE no such > applications possible? > Or do we design a framework by which application-level > semantics can be > expressed outside of the protocol definition? > > And as for "Just add another method to your SIP stack". Let's > say I have a > mobile phone and the SIP stack is burned into ROM and exposes only a > simplistic transactional API. This is only likely to happen, oh, 100 > million times or so over the next two years . . . Now, just > exactly how is > my BREW or JTME application going to go about extending the > SIP stack to > support another method? Will the evil wireless operator > networks even pass > another method? Neither is happening anytime soon, I think . . . > > -- > 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 mailnull@www1.ietf.org Thu Jan 2 12:37:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09250 for ; Thu, 2 Jan 2003 12:37:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02Hjfl08124 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 12:45:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02HfFJ07931; Thu, 2 Jan 2003 12:41:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02HeKJ07848 for ; Thu, 2 Jan 2003 12:40:20 -0500 Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09117 for ; Thu, 2 Jan 2003 12:31:27 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message Subject: RE: [Sip] INFO considered harmful MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 2 Jan 2003 12:34:37 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D248638@zoe.office.snowshore.com> Thread-Topic: [Sip] INFO considered harmful Thread-Index: AcKxknyCLwoa7/XoT6OBMpUscvSNzQA27omQ From: "Eric Burger" To: "Pete Cordell" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h02HeQJ07854 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit What is the difference between: INFO-MUMBLE INFO-FOO and MUMBLE FOO ??? I don't think we should go down the path of "if you method looks like INFO-%, it is special". If you are going to parse the first few characters of the method name, you might as well parse the method name. > -----Original Message----- > From: Pete Cordell [mailto:pete@tech-know-ware.com] > Sent: Wednesday, January 01, 2003 6:44 AM > To: Jonathan Rosenberg; sip@ietf.org > Subject: Re: [Sip] INFO considered harmful > > > How about we use new methods to define end-to-end application > data, but name > the messages INFO-*. e.g. INFO-MY-FEATURE, so that they can > be readily > identified as application data rather than SIP state > affecting methods. > Allow: can then be used to negotiate 'INFO' extensions. > > > - It's easy to parse. > > - It's very easy for a stack to treat it generically. > > - It can reuse existing SIP features to do negotiation etc. > (e.g. Allow) > > - It could be easily documented in the SIP usage document. > > > > My other thoughts on the subject (and what has led me to the > above position > are): > > - I think its important to have some mechanism that allows end-to-end > application data exchange that is independent of SIP state. > > - Doing this in-band (rather than starting up potentially > numerous side > connections) will be desirable for some applications (such as > those that use > a small amounts of data). > > - It seems appealing to be readily able to tell which methods > affect SIP > state, and which is application level data. > > - Require:, Supported: and Allow: already negotiation of > features and where > possible it would be beneficial to re-use these mechanisms rather than > invent new ones.. > > - An INFO mechanism does not need to offer any semantics > beyond simple data > delivery (although it might be nice to have an in-order > delivery service?) > (and the afore mentioned negotiation). > > - The main problem with INFO is that it doesn't give a single > specific way > of identifying which application a particular INFO method is > related to. > Hence it necessitates some sort of heuristic procedure to be used. > > > Some other ways to move ahead might be to: > > - Specify that the application that the INFO corresponds to > is defined by > the MIME type of the body. > > - Define a new header that defines the application that the > INFO corresponds > to. > > Pete. > > ----- Original Message ----- > From: "Jonathan Rosenberg" > To: > Sent: 26 December 2002 20:12 > Subject: [Sip] INFO considered harmful > > > > Folks, > > > > For some time, I've been complaining about the continued > abuse of the > > INFO method for things that should be done other ways > (frequently, not > > using sip at all). I've written up a summary of the problems and a > > proposed path forward. Specifically, I'd like to obsolete INFO and > > replace it with a spec that is approved ONLY for SIP-T. > > > > Until the I-D appears, you can pick up a version at: > > > > > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt > > > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.html > > > > Thanks, > > Jonathan R. > > -- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 2 12:55:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09616 for ; Thu, 2 Jan 2003 12:55:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02I3MH08864 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 13:03:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02HxVJ08641; Thu, 2 Jan 2003 12:59:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02HwUJ08577 for ; Thu, 2 Jan 2003 12:58:30 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09501 for ; Thu, 2 Jan 2003 12:49:36 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.143]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h02HqoYH024605; Thu, 2 Jan 2003 12:52:50 -0500 (EST) Message-ID: <3E147C6F.1060104@dynamicsoft.com> Date: Thu, 02 Jan 2003 12:52:47 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Nataraju A.B." , sip@ietf.org Subject: Re: [Sip] A simple query... References: <004401c2a85e$99855700$618d6b80@amer.cisco.com> <3E0375E7.1080608@dynamicsoft.com> <1040415671.949.161.camel@RjS.localdomain> <15888.48291.700746.59246@thomasm-u1.cisco.com> <15889.35402.270711.303036@lohi.eng.song.fi> <004401c2b0ce$627520b0$5d02120a@in.huawei.com> <3E11AB76.5080903@dynamicsoft.com> <003101c2b222$550924d0$5d02120a@in.huawei.com> <3E146845.5020707@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit One additional comment here. I do appreciate that the example is probably confusing, since you would think that "v2" is a version, but its not. I've logged that into bugzilla. -Jonathan R. Jonathan Rosenberg wrote: > inline. > > Nataraju A.B. wrote: > >> Hi, >> >> Server = "Server" HCOLON server-val *(LWS server-val) >> server-val = product / comment >> >> product = token [SLASH product-version] >> >> product-version = token >> >> both product and product version are of type tokens. >> if two tokes are in the input what should be considered. I mean >> product an dprod version OR two product values. >> >> for ex : Server: *HomeServer HS v2* >> in this case HS is prod version or product2. > > > Its a second product. Version requires a slash. As a result, the example > in the SIP spec which you quoted would have v2 parse as a product, not a > version. Thats fine. This field is only useful for display to humans or > for string comparison, in which case it doesnt matter whether the "v2" > is interpreted as a product version or a product. > > -Jonathan R. > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 2 12:55:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09630 for ; Thu, 2 Jan 2003 12:55:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02I3ce08882 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 13:03:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02I09J08697; Thu, 2 Jan 2003 13:00:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02HxGJ08630 for ; Thu, 2 Jan 2003 12:59:16 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09511 for ; Thu, 2 Jan 2003 12:50:21 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id h02HrVfm006976; Thu, 2 Jan 2003 09:53:31 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id ABA23746; Thu, 2 Jan 2003 09:46:28 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA26831; Thu, 2 Jan 2003 09:53:24 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15892.31891.956251.196024@thomasm-u1.cisco.com> Date: Thu, 2 Jan 2003 09:53:23 -0800 (PST) To: "Eric Burger" Cc: "Dean Willis" , "Jonathan Rosenberg" , Subject: RE: [Sip] INFO considered harmful In-Reply-To: <4A3384433CE2AB46A63468CB207E209D248639@zoe.office.snowshore.com> References: <4A3384433CE2AB46A63468CB207E209D248639@zoe.office.snowshore.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I don't get it. If you want "100% application specific", why not pick an unused port and roll your own protocol? Then all of the crufty SIPism don't get in the way, and the hue and cry from this working group ceases immediately. Do the bits on the wire keep warmer if they're dressed in SIP? Mike Eric Burger writes: > I fully agree with Dean on this one. > > One point to consider (I'm on the fence on this one) is whether we would say that INFO is 100% application-specific. That is, the WG will not publish standard body types. > > A reason for doing that is to let people know that INFO really is just, as Dean points out, application-to-application communication. If you want applications to interoperate, take it either to an Application Area WG or take it outside the IETF. > > One reason to not do this is SIP-T should use a method other than INFO. That said, I don't think there are that many SIP-T implementations extant. > > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Tuesday, December 31, 2002 1:48 AM > > To: Jonathan Rosenberg; Orit Levin > > Cc: sip@ietf.org > > Subject: Re: [Sip] INFO considered harmful > > > > > > At 12:48 AM 12/31/2002 -0500, Jonathan Rosenberg wrote: > > >Orit Levin wrote: > > >>>The big huge difference I have been trying to point out is > > that EVENTS > > >>>DEFINES SEMANTICS, whereas INFO doesnt. > > >>>MIME provides semantics and syntax that are independent of > > the type. > > >>>SIP events provides semantics and syntax that are > > independent of the > > >>>package. > > >>>INFO provides nothing. > > >> > > >>INFO provides "minimal" but very important semantics: > > asynchronous data > > >>reliably follows the established SIP path. > > > > > >Huh? > > > > > >Every new SIP method is reliable, it inherits the SIP > > transaction state > > >machine for non-invite. Follows the established path? Every > > in-dialog > > >method would have this property, it is method independent. > > >Asynchronous? You can send any method at any time. > > > > > >Thus, nothing you have pointed out above is different > > between INFO and any > > >other new method we might introduce. > > > > I think the key point is that there is a difference between transport > > protocol semantic and application semantic. The transport > > protocol semantic > > expressed in INFO is "Here is some data that will be used by the > > application. It is not important to the transport protocol, > > except that the > > transport protocol is expected to deliver it reliably". INFO > > says NOTHING > > about the APPLICATION level semantic -- that's up to what > > goes IN the INFO > > payloads. The question is -- do we try to rigidly define > > application-level > > semantics here? Do we define that there ARE no such > > applications possible? > > Or do we design a framework by which application-level > > semantics can be > > expressed outside of the protocol definition? > > > > And as for "Just add another method to your SIP stack". Let's > > say I have a > > mobile phone and the SIP stack is burned into ROM and exposes only a > > simplistic transactional API. This is only likely to happen, oh, 100 > > million times or so over the next two years . . . Now, just > > exactly how is > > my BREW or JTME application going to go about extending the > > SIP stack to > > support another method? Will the evil wireless operator > > networks even pass > > another method? Neither is happening anytime soon, I think . . . > > > > -- > > 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 mailnull@www1.ietf.org Thu Jan 2 13:56:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11468 for ; Thu, 2 Jan 2003 13:56:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02J4nG13238 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 14:04:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02J19J13043; Thu, 2 Jan 2003 14:01:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02IxUJ12888 for ; Thu, 2 Jan 2003 13:59:30 -0500 Received: from commserver.iperia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11403 for ; Thu, 2 Jan 2003 13:50:34 -0500 (EST) Received: by commserver.erictest.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Jan 2003 13:53:46 -0500 Message-ID: <1A69639B9B6AD511812B00B0D0DE19F60A39A4@commserver.erictest.com> From: Gordon Ledgard To: "'Michael Thomas'" , Eric Burger Cc: Dean Willis , Jonathan Rosenberg , sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Thu, 2 Jan 2003 13:53:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I think people are suffering from the delusion that because SIP has already established a channel of communication between the transport layer of the SIP entities on the involved machines, that it then becomes "easier" to get information to the application layer by tunneling it through INFO on this established channel, and that you gain something by the "handshakes" provided "free" by SIP. In fact, nothing at all has been gained. All of your application connection problems remain. Michael is right in saying it provides no such benefit, and it makes NO difference from an app perspective, if you tunnel junk through INFO or roll you own protocol over another port. Which is not to say INFO isn't useful. Gordon > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Thursday, January 02, 2003 12:53 PM > To: Eric Burger > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > Subject: RE: [Sip] INFO considered harmful > > > > I don't get it. If you want "100% application > specific", why not pick an unused port and roll > your own protocol? Then all of the crufty SIPism > don't get in the way, and the hue and cry from > this working group ceases immediately. Do the bits > on the wire keep warmer if they're dressed in SIP? > > Mike > > Eric Burger writes: > > I fully agree with Dean on this one. > > > > One point to consider (I'm on the fence on this one) is > whether we would say that INFO is 100% application-specific. > That is, the WG will not publish standard body types. > > > > A reason for doing that is to let people know that INFO > really is just, as Dean points out, > application-to-application communication. If you want > applications to interoperate, take it either to an > Application Area WG or take it outside the IETF. > > > > One reason to not do this is SIP-T should use a method > other than INFO. That said, I don't think there are that > many SIP-T implementations extant. > > > > > > > -----Original Message----- > > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > Sent: Tuesday, December 31, 2002 1:48 AM > > > To: Jonathan Rosenberg; Orit Levin > > > Cc: sip@ietf.org > > > Subject: Re: [Sip] INFO considered harmful > > > > > > > > > At 12:48 AM 12/31/2002 -0500, Jonathan Rosenberg wrote: > > > >Orit Levin wrote: > > > >>>The big huge difference I have been trying to point out is > > > that EVENTS > > > >>>DEFINES SEMANTICS, whereas INFO doesnt. > > > >>>MIME provides semantics and syntax that are independent of > > > the type. > > > >>>SIP events provides semantics and syntax that are > > > independent of the > > > >>>package. > > > >>>INFO provides nothing. > > > >> > > > >>INFO provides "minimal" but very important semantics: > > > asynchronous data > > > >>reliably follows the established SIP path. > > > > > > > >Huh? > > > > > > > >Every new SIP method is reliable, it inherits the SIP > > > transaction state > > > >machine for non-invite. Follows the established path? Every > > > in-dialog > > > >method would have this property, it is method independent. > > > >Asynchronous? You can send any method at any time. > > > > > > > >Thus, nothing you have pointed out above is different > > > between INFO and any > > > >other new method we might introduce. > > > > > > I think the key point is that there is a difference > between transport > > > protocol semantic and application semantic. The transport > > > protocol semantic > > > expressed in INFO is "Here is some data that will be used by the > > > application. It is not important to the transport protocol, > > > except that the > > > transport protocol is expected to deliver it reliably". INFO > > > says NOTHING > > > about the APPLICATION level semantic -- that's up to what > > > goes IN the INFO > > > payloads. The question is -- do we try to rigidly define > > > application-level > > > semantics here? Do we define that there ARE no such > > > applications possible? > > > Or do we design a framework by which application-level > > > semantics can be > > > expressed outside of the protocol definition? > > > > > > And as for "Just add another method to your SIP stack". Let's > > > say I have a > > > mobile phone and the SIP stack is burned into ROM and > exposes only a > > > simplistic transactional API. This is only likely to > happen, oh, 100 > > > million times or so over the next two years . . . Now, just > > > exactly how is > > > my BREW or JTME application going to go about extending the > > > SIP stack to > > > support another method? Will the evil wireless operator > > > networks even pass > > > another method? Neither is happening anytime soon, I think . . . > > > > > > -- > > > 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 2 13:57:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11489 for ; Thu, 2 Jan 2003 13:57:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02J5gw13293 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 14:05:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02J2EJ13136; Thu, 2 Jan 2003 14:02:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02J1aJ13073 for ; Thu, 2 Jan 2003 14:01:36 -0500 Received: from imr2.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11422 for ; Thu, 2 Jan 2003 13:52:40 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id h02ItGW16228; Thu, 2 Jan 2003 12:55:16 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h02ItFx01028; Thu, 2 Jan 2003 12:55:15 -0600 (CST) Received: from eammlex033.lmc.ericsson.se (eammlex033.lmc.ericsson.se [142.133.1.133]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id h02ItEh09961; Thu, 2 Jan 2003 13:55:14 -0500 (EST) Received: by eammlex033.lmc.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 2 Jan 2003 13:56:13 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C037BFB@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'Michael Thomas'" , Eric Burger Cc: Dean Willis , Jonathan Rosenberg , sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Thu, 2 Jan 2003 13:55:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , The application is SIP based, we dont need yet another protocol to convey what needs to be conveyed e2e. No need to go around the bush. Lets find *real* arguments against using INFO for that purpopse rather than philosphical ones. /gf -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Thursday, January 02, 2003 12:53 PM To: Eric Burger Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org Subject: RE: [Sip] INFO considered harmful I don't get it. If you want "100% application specific", why not pick an unused port and roll your own protocol? Then all of the crufty SIPism don't get in the way, and the hue and cry from this working group ceases immediately. Do the bits on the wire keep warmer if they're dressed in SIP? Mike Eric Burger writes: > I fully agree with Dean on this one. > > One point to consider (I'm on the fence on this one) is whether we would say that INFO is 100% application-specific. That is, the WG will not publish standard body types. > > A reason for doing that is to let people know that INFO really is just, as Dean points out, application-to-application communication. If you want applications to interoperate, take it either to an Application Area WG or take it outside the IETF. > > One reason to not do this is SIP-T should use a method other than INFO. That said, I don't think there are that many SIP-T implementations extant. > > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Tuesday, December 31, 2002 1:48 AM > > To: Jonathan Rosenberg; Orit Levin > > Cc: sip@ietf.org > > Subject: Re: [Sip] INFO considered harmful > > > > > > At 12:48 AM 12/31/2002 -0500, Jonathan Rosenberg wrote: > > >Orit Levin wrote: > > >>>The big huge difference I have been trying to point out is > > that EVENTS > > >>>DEFINES SEMANTICS, whereas INFO doesnt. > > >>>MIME provides semantics and syntax that are independent of > > the type. > > >>>SIP events provides semantics and syntax that are > > independent of the > > >>>package. > > >>>INFO provides nothing. > > >> > > >>INFO provides "minimal" but very important semantics: > > asynchronous data > > >>reliably follows the established SIP path. > > > > > >Huh? > > > > > >Every new SIP method is reliable, it inherits the SIP > > transaction state > > >machine for non-invite. Follows the established path? Every > > in-dialog > > >method would have this property, it is method independent. > > >Asynchronous? You can send any method at any time. > > > > > >Thus, nothing you have pointed out above is different > > between INFO and any > > >other new method we might introduce. > > > > I think the key point is that there is a difference between transport > > protocol semantic and application semantic. The transport > > protocol semantic > > expressed in INFO is "Here is some data that will be used by the > > application. It is not important to the transport protocol, > > except that the > > transport protocol is expected to deliver it reliably". INFO > > says NOTHING > > about the APPLICATION level semantic -- that's up to what > > goes IN the INFO > > payloads. The question is -- do we try to rigidly define > > application-level > > semantics here? Do we define that there ARE no such > > applications possible? > > Or do we design a framework by which application-level > > semantics can be > > expressed outside of the protocol definition? > > > > And as for "Just add another method to your SIP stack". Let's > > say I have a > > mobile phone and the SIP stack is burned into ROM and exposes only a > > simplistic transactional API. This is only likely to happen, oh, 100 > > million times or so over the next two years . . . Now, just > > exactly how is > > my BREW or JTME application going to go about extending the > > SIP stack to > > support another method? Will the evil wireless operator > > networks even pass > > another method? Neither is happening anytime soon, I think . . . > > > > -- > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 2 14:38:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12438 for ; Thu, 2 Jan 2003 14:38:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02JkaY16281 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 14:46:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02JgeJ16079; Thu, 2 Jan 2003 14:42:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02JfZJ16019 for ; Thu, 2 Jan 2003 14:41:36 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12271 for ; Thu, 2 Jan 2003 14:32:39 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h02JYQSK009127; Thu, 2 Jan 2003 14:34:26 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Jan 2003 13:35:47 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A643B2@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'George Foti (LMC)'" , "'Michael Thomas'" , Eric Burger Cc: Dean Willis , Jonathan Rosenberg , sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Thu, 2 Jan 2003 13:35:38 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , The argument of "but I'm already holding a hammer and *want* to treat everything like a nail!" comes up on about an annual basis, and is rejected outright each time. Just because you have a SIP stack in your application does *not* mean that it is appropriate to use that stack for all general network access. You're allowing laziness to overwhelm good application design. /a > -----Original Message----- > From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] > Sent: Thursday, January 02, 2003 12:55 > To: 'Michael Thomas'; Eric Burger > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > Subject: RE: [Sip] INFO considered harmful > > > The application is SIP based, we dont need yet another > protocol to convey what needs to be conveyed e2e. > No need to go around the bush. > Lets find *real* arguments against using INFO for that > purpopse rather than philosphical ones. > > /gf > > > > > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Thursday, January 02, 2003 12:53 PM > To: Eric Burger > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > Subject: RE: [Sip] INFO considered harmful > > > > I don't get it. If you want "100% application > specific", why not pick an unused port and roll > your own protocol? Then all of the crufty SIPism > don't get in the way, and the hue and cry from > this working group ceases immediately. Do the bits > on the wire keep warmer if they're dressed in SIP? > > Mike > > Eric Burger writes: > > I fully agree with Dean on this one. > > > > One point to consider (I'm on the fence on this one) is > whether we would say that INFO is 100% application-specific. > That is, the WG will not publish standard body types. > > > > A reason for doing that is to let people know that INFO > really is just, as Dean points out, > application-to-application communication. If you want > applications to interoperate, take it either to an > Application Area WG or take it outside the IETF. > > > > One reason to not do this is SIP-T should use a method > other than INFO. That said, I don't think there are that > many SIP-T implementations extant. > > > > > > > -----Original Message----- > > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > Sent: Tuesday, December 31, 2002 1:48 AM > > > To: Jonathan Rosenberg; Orit Levin > > > Cc: sip@ietf.org > > > Subject: Re: [Sip] INFO considered harmful > > > > > > > > > At 12:48 AM 12/31/2002 -0500, Jonathan Rosenberg wrote: > > > >Orit Levin wrote: > > > >>>The big huge difference I have been trying to point out is > > > that EVENTS > > > >>>DEFINES SEMANTICS, whereas INFO doesnt. > > > >>>MIME provides semantics and syntax that are independent of > > > the type. > > > >>>SIP events provides semantics and syntax that are > > > independent of the > > > >>>package. > > > >>>INFO provides nothing. > > > >> > > > >>INFO provides "minimal" but very important semantics: > > > asynchronous data > > > >>reliably follows the established SIP path. > > > > > > > >Huh? > > > > > > > >Every new SIP method is reliable, it inherits the SIP > > > transaction state > > > >machine for non-invite. Follows the established path? Every > > > in-dialog > > > >method would have this property, it is method independent. > > > >Asynchronous? You can send any method at any time. > > > > > > > >Thus, nothing you have pointed out above is different > > > between INFO and any > > > >other new method we might introduce. > > > > > > I think the key point is that there is a difference > between transport > > > protocol semantic and application semantic. The transport > > > protocol semantic > > > expressed in INFO is "Here is some data that will be used by the > > > application. It is not important to the transport protocol, > > > except that the > > > transport protocol is expected to deliver it reliably". INFO > > > says NOTHING > > > about the APPLICATION level semantic -- that's up to what > > > goes IN the INFO > > > payloads. The question is -- do we try to rigidly define > > > application-level > > > semantics here? Do we define that there ARE no such > > > applications possible? > > > Or do we design a framework by which application-level > > > semantics can be > > > expressed outside of the protocol definition? > > > > > > And as for "Just add another method to your SIP stack". Let's > > > say I have a > > > mobile phone and the SIP stack is burned into ROM and > exposes only a > > > simplistic transactional API. This is only likely to > happen, oh, 100 > > > million times or so over the next two years . . . Now, just > > > exactly how is > > > my BREW or JTME application going to go about extending the > > > SIP stack to > > > support another method? Will the evil wireless operator > > > networks even pass > > > another method? Neither is happening anytime soon, I think . . . > > > > > > -- > > > 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 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Jan 2 14:53:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12695 for ; Thu, 2 Jan 2003 14:53:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02K1bn17052 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 15:01:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02JvcJ16774; Thu, 2 Jan 2003 14:57:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02JtIJ16675 for ; Thu, 2 Jan 2003 14:55:18 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12534 for ; Thu, 2 Jan 2003 14:46:21 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h02JeaSK009148; Thu, 2 Jan 2003 14:40:36 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Jan 2003 13:41:57 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A643B3@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Sachin Shenoy'" , Jonathan Rosenberg Cc: sip@ietf.org Subject: RE: [Sip] Loop detection; Not a bad thing to have Date: Thu, 2 Jan 2003 13:41:49 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > From: Sachin Shenoy [mailto:sachins@netlab.hcltech.com] > > > I have to take your word on this (that loops are rare). > But sure it > > > creates havoc once > > > it happens. (Simple tests where request from UA looped > between 2 proxies > > > ran for more > > > than 10 minutes. > > > > That should not happen. Max-Forwards should be preventing that. > > Max-Forwards did work in this case. But didn't prevent the > above mentioned > problem. It took you *10* *MINUTES* to perform *70* *HOPS*?!?!? I think you need to seriously work on getting your proxies above 0.1 tps before pursuing this particular problem much further. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 2 15:17:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13205 for ; Thu, 2 Jan 2003 15:17:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02KPXf18646 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 15:25:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02KLiJ18534; Thu, 2 Jan 2003 15:21:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02KKLJ18486 for ; Thu, 2 Jan 2003 15:20:21 -0500 Received: from mpls-qmqp-02.inet.qwest.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13121 for ; Thu, 2 Jan 2003 15:11:22 -0500 (EST) Received: (qmail 92574 invoked by uid 0); 2 Jan 2003 20:00:57 -0000 Received: from mpls-pop-14.inet.qwest.net (63.231.195.14) by mpls-qmqp-02.inet.qwest.net with QMQP; 2 Jan 2003 20:00:57 -0000 Received: from unknown (HELO DONGWLAPTOP) (63.229.230.222) by mpls-pop-14.inet.qwest.net with SMTP; 2 Jan 2003 20:14:33 -0000 Date: Thu, 2 Jan 2003 13:12:54 -0700 Message-ID: <003001c2b29b$560fb460$0300000a@DONGWLAPTOP> From: "Don Stanwyck" To: "'George Foti (LMC)'" , "'Michael Thomas'" , "'Eric Burger'" Cc: "'Dean Willis'" , "'Jonathan Rosenberg'" , sip@ietf.org Subject: RE: [Sip] INFO considered harmful MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <32CD630F6CBED411AE180008C7894CBC0C037BFB@lmc37.lmc.ericsson.se> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h02KKLJ18487 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I guess I have two problems with the statement below. 1) Applications should not be protocol based - they may be protocol aware. Unless the SIP stack is rolled into the application, it merely uses SIP as a lower layer tool to establish communications. It is a violation of good design to roll the protocol into the application itself. BTW, if the SIP stack is rolled into the application, then when the next edition of SIP comes along you will have to rewrite the app. You really should have an API that keeps the app from needing to know the details of the communication establishment protocol. 2) If the apps need to talk directly to each other there are a host of protocols that are extremely trivial that can do the job. The apps can even just open a port over any transport protocol and exchange information as they please. There is no reason to bother all the routing proxies in the network with your e2e private chatter. Just a thought. don > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of George Foti (LMC) > Sent: Thursday, January 02, 2003 11:55 AM > To: 'Michael Thomas'; Eric Burger > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > Subject: RE: [Sip] INFO considered harmful > > > The application is SIP based, we dont need yet another > protocol to convey what needs to be conveyed e2e. No need to > go around the bush. Lets find *real* arguments against using > INFO for that purpopse rather than philosphical ones. > > /gf > > > > > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Thursday, January 02, 2003 12:53 PM > To: Eric Burger > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > Subject: RE: [Sip] INFO considered harmful > > > > I don't get it. If you want "100% application > specific", why not pick an unused port and roll > your own protocol? Then all of the crufty SIPism > don't get in the way, and the hue and cry from > this working group ceases immediately. Do the bits > on the wire keep warmer if they're dressed in SIP? > > Mike > > Eric Burger writes: > > I fully agree with Dean on this one. > > > > One point to consider (I'm on the fence on this one) is > whether we would say that INFO is 100% application-specific. > That is, the WG will not publish standard body types. > > > A reason for doing that is to let people know that INFO > really is just, as Dean points out, > application-to-application communication. If you want > applications to interoperate, take it either to an > Application Area WG or take it outside the IETF. > > > One reason to not do this is SIP-T should use a method > other than INFO. That said, I don't think there are that > many SIP-T implementations extant. > > > > > > -----Original Message----- > > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > Sent: Tuesday, December 31, 2002 1:48 AM > > > To: Jonathan Rosenberg; Orit Levin > > > Cc: sip@ietf.org > > > Subject: Re: [Sip] INFO considered harmful > > > > > > > > > At 12:48 AM 12/31/2002 -0500, Jonathan Rosenberg wrote: > > > >Orit Levin wrote: > > > >>>The big huge difference I have been trying to point out is > > > that EVENTS > > > >>>DEFINES SEMANTICS, whereas INFO doesnt. > > > >>>MIME provides semantics and syntax that are independent of > > > the type. > > > >>>SIP events provides semantics and syntax that are > > > independent of the > > > >>>package. > > > >>>INFO provides nothing. > > > >> > > > >>INFO provides "minimal" but very important semantics: > > > asynchronous data > > > >>reliably follows the established SIP path. > > > > > > > >Huh? > > > > > > > >Every new SIP method is reliable, it inherits the SIP > > > transaction state > > > >machine for non-invite. Follows the established path? Every > > > in-dialog > > > >method would have this property, it is method independent. > > > >Asynchronous? You can send any method at any time. > > > > > > > >Thus, nothing you have pointed out above is different > > > between INFO and any > > > >other new method we might introduce. > > > > > > I think the key point is that there is a difference > between transport > > > protocol semantic and application semantic. The transport > > > protocol semantic > > > expressed in INFO is "Here is some data that will be used by the > > > application. It is not important to the transport protocol, > > > except that the > > > transport protocol is expected to deliver it reliably". INFO > > > says NOTHING > > > about the APPLICATION level semantic -- that's up to what > > > goes IN the INFO > > > payloads. The question is -- do we try to rigidly define > > > application-level > > > semantics here? Do we define that there ARE no such > > > applications possible? > > > Or do we design a framework by which application-level > > > semantics can be > > > expressed outside of the protocol definition? > > > > > > And as for "Just add another method to your SIP stack". Let's > > > say I have a > > > mobile phone and the SIP stack is burned into ROM and > exposes only a > > > simplistic transactional API. This is only likely to > happen, oh, 100 > > > million times or so over the next two years . . . Now, just > > > exactly how is > > > my BREW or JTME application going to go about extending the > > > SIP stack to > > > support another method? Will the evil wireless operator > > > networks even pass > > > another method? Neither is happening anytime soon, I > think . . . > > > > > -- > > > 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 _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Jan 2 15:36:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13556 for ; Thu, 2 Jan 2003 15:36:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02Kicv19978 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 15:44:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02KepJ19876; Thu, 2 Jan 2003 15:40:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02KdVJ19800 for ; Thu, 2 Jan 2003 15:39:31 -0500 Received: from EXECDSL.COM (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13472 for ; Thu, 2 Jan 2003 15:30:33 -0500 (EST) Received: from [63.113.114.131] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 4101619 for sip@ietf.org; Thu, 02 Jan 2003 15:33:45 -0500 Message-Id: <5.1.0.14.0.20030102152640.017ee838@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 02 Jan 2003 15:33:04 -0500 To: sip@ietf.org From: "Joel M. Halpern" Subject: RE: [Sip] INFO considered harmful In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A643B2@DYN-TX-EXCH-001.dyn amicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I think that there is another way to phrase the issue which at least raises a fair question. I have an application. It uses SIP, and then (sometimes) establishes a media session. However, none of those exchanges provide the IP address of the controlling remote application. Hence, if one application control entity wants to send (or receive) information to (from) the other application control entity, the only clearly available path is through SIP messages. Preferably SIP messages tied to the existing session. Presumably, one could mandate a single header for carrying a "control entity IP address / port / protocol" but that seems pretty silly. Yours, Joel M. Halpern At 01:35 PM 1/2/2003 -0600, Adam Roach wrote: >The argument of "but I'm already holding a hammer and *want* >to treat everything like a nail!" comes up on about an annual >basis, and is rejected outright each time. > >Just because you have a SIP stack in your application does >*not* mean that it is appropriate to use that stack for >all general network access. You're allowing laziness to >overwhelm good application design. > >/a > > > -----Original Message----- > > From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] > > Sent: Thursday, January 02, 2003 12:55 > > To: 'Michael Thomas'; Eric Burger > > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > > Subject: RE: [Sip] INFO considered harmful > > > > > > The application is SIP based, we dont need yet another > > protocol to convey what needs to be conveyed e2e. > > No need to go around the bush. > > Lets find *real* arguments against using INFO for that > > purpopse rather than philosphical ones. > > > > /gf > > > > > > > > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Thursday, January 02, 2003 12:53 PM > > To: Eric Burger > > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > > Subject: RE: [Sip] INFO considered harmful > > > > > > > > I don't get it. If you want "100% application > > specific", why not pick an unused port and roll > > your own protocol? Then all of the crufty SIPism > > don't get in the way, and the hue and cry from > > this working group ceases immediately. Do the bits > > on the wire keep warmer if they're dressed in SIP? > > > > Mike > > > > Eric Burger writes: > > > I fully agree with Dean on this one. > > > > > > One point to consider (I'm on the fence on this one) is > > whether we would say that INFO is 100% application-specific. > > That is, the WG will not publish standard body types. > > > > > > A reason for doing that is to let people know that INFO > > really is just, as Dean points out, > > application-to-application communication. If you want > > applications to interoperate, take it either to an > > Application Area WG or take it outside the IETF. > > > > > > One reason to not do this is SIP-T should use a method > > other than INFO. That said, I don't think there are that > > many SIP-T implementations extant. > > > > > > > > > > -----Original Message----- > > > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > > Sent: Tuesday, December 31, 2002 1:48 AM > > > > To: Jonathan Rosenberg; Orit Levin > > > > Cc: sip@ietf.org > > > > Subject: Re: [Sip] INFO considered harmful > > > > > > > > > > > > At 12:48 AM 12/31/2002 -0500, Jonathan Rosenberg wrote: > > > > >Orit Levin wrote: > > > > >>>The big huge difference I have been trying to point out is > > > > that EVENTS > > > > >>>DEFINES SEMANTICS, whereas INFO doesnt. > > > > >>>MIME provides semantics and syntax that are independent of > > > > the type. > > > > >>>SIP events provides semantics and syntax that are > > > > independent of the > > > > >>>package. > > > > >>>INFO provides nothing. > > > > >> > > > > >>INFO provides "minimal" but very important semantics: > > > > asynchronous data > > > > >>reliably follows the established SIP path. > > > > > > > > > >Huh? > > > > > > > > > >Every new SIP method is reliable, it inherits the SIP > > > > transaction state > > > > >machine for non-invite. Follows the established path? Every > > > > in-dialog > > > > >method would have this property, it is method independent. > > > > >Asynchronous? You can send any method at any time. > > > > > > > > > >Thus, nothing you have pointed out above is different > > > > between INFO and any > > > > >other new method we might introduce. > > > > > > > > I think the key point is that there is a difference > > between transport > > > > protocol semantic and application semantic. The transport > > > > protocol semantic > > > > expressed in INFO is "Here is some data that will be used by the > > > > application. It is not important to the transport protocol, > > > > except that the > > > > transport protocol is expected to deliver it reliably". INFO > > > > says NOTHING > > > > about the APPLICATION level semantic -- that's up to what > > > > goes IN the INFO > > > > payloads. The question is -- do we try to rigidly define > > > > application-level > > > > semantics here? Do we define that there ARE no such > > > > applications possible? > > > > Or do we design a framework by which application-level > > > > semantics can be > > > > expressed outside of the protocol definition? > > > > > > > > And as for "Just add another method to your SIP stack". Let's > > > > say I have a > > > > mobile phone and the SIP stack is burned into ROM and > > exposes only a > > > > simplistic transactional API. This is only likely to > > happen, oh, 100 > > > > million times or so over the next two years . . . Now, just > > > > exactly how is > > > > my BREW or JTME application going to go about extending the > > > > SIP stack to > > > > support another method? Will the evil wireless operator > > > > networks even pass > > > > another method? Neither is happening anytime soon, I think . . . > > > > > > > > -- > > > > 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 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Jan 2 15:48:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13785 for ; Thu, 2 Jan 2003 15:48:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02Kv7C20743 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 15:57:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02KrSJ20494; Thu, 2 Jan 2003 15:53:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02KpNJ20367 for ; Thu, 2 Jan 2003 15:51:23 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13677 for ; Thu, 2 Jan 2003 15:42:24 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.143]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h02KjYYH024634; Thu, 2 Jan 2003 15:45:39 -0500 (EST) Message-ID: <3E14A4EA.8060409@dynamicsoft.com> Date: Thu, 02 Jan 2003 15:45:30 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Joel M. Halpern" CC: sip@ietf.org Subject: Re: [Sip] INFO considered harmful References: <5.1.0.14.0.20030102152640.017ee838@mail.stevecrocker.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Joel, I am not entirely sure I follow you here. As I started reading, I thought you were proposing what I do believe is the right answer here. If people want to exchange proprietary data between applications that are set up using sip, we have a way to do that. This application data can just be considered another session type (along with audio and video) which SIP can set up and manage for you. So, roll your own protocol (say, foo) that does just what you want, and then use SDP to exchange the IP/ports and protocol identification infomration needed to make it work. This way, proxies don't see any of it, and SIP is not being abused in any way. -Jonathan R. Joel M. Halpern wrote: > I think that there is another way to phrase the issue which at least > raises a fair question. > I have an application. It uses SIP, and then (sometimes) establishes a > media session. > However, none of those exchanges provide the IP address of the > controlling remote application. > > Hence, if one application control entity wants to send (or receive) > information to (from) the other application control entity, the only > clearly available path is through SIP messages. Preferably SIP messages > tied to the existing session. > Presumably, one could mandate a single header for carrying a "control > entity IP address / port / protocol" but that seems pretty silly. > > Yours, > Joel M. Halpern > > At 01:35 PM 1/2/2003 -0600, Adam Roach wrote: > >> The argument of "but I'm already holding a hammer and *want* >> to treat everything like a nail!" comes up on about an annual >> basis, and is rejected outright each time. >> >> Just because you have a SIP stack in your application does >> *not* mean that it is appropriate to use that stack for >> all general network access. You're allowing laziness to >> overwhelm good application design. >> >> /a >> >> > -----Original Message----- >> > From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] >> > Sent: Thursday, January 02, 2003 12:55 >> > To: 'Michael Thomas'; Eric Burger >> > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org >> > Subject: RE: [Sip] INFO considered harmful >> > >> > >> > The application is SIP based, we dont need yet another >> > protocol to convey what needs to be conveyed e2e. >> > No need to go around the bush. >> > Lets find *real* arguments against using INFO for that >> > purpopse rather than philosphical ones. >> > >> > /gf >> > >> > >> > >> > >> > -----Original Message----- >> > From: Michael Thomas [mailto:mat@cisco.com] >> > Sent: Thursday, January 02, 2003 12:53 PM >> > To: Eric Burger >> > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org >> > Subject: RE: [Sip] INFO considered harmful >> > >> > >> > >> > I don't get it. If you want "100% application >> > specific", why not pick an unused port and roll >> > your own protocol? Then all of the crufty SIPism >> > don't get in the way, and the hue and cry from >> > this working group ceases immediately. Do the bits >> > on the wire keep warmer if they're dressed in SIP? >> > >> > Mike >> > >> > Eric Burger writes: >> > > I fully agree with Dean on this one. >> > > >> > > One point to consider (I'm on the fence on this one) is >> > whether we would say that INFO is 100% application-specific. >> > That is, the WG will not publish standard body types. >> > > >> > > A reason for doing that is to let people know that INFO >> > really is just, as Dean points out, >> > application-to-application communication. If you want >> > applications to interoperate, take it either to an >> > Application Area WG or take it outside the IETF. >> > > >> > > One reason to not do this is SIP-T should use a method >> > other than INFO. That said, I don't think there are that >> > many SIP-T implementations extant. >> > > >> > > >> > > > -----Original Message----- >> > > > From: Dean Willis [mailto:dean.willis@softarmor.com] >> > > > Sent: Tuesday, December 31, 2002 1:48 AM >> > > > To: Jonathan Rosenberg; Orit Levin >> > > > Cc: sip@ietf.org >> > > > Subject: Re: [Sip] INFO considered harmful >> > > > >> > > > >> > > > At 12:48 AM 12/31/2002 -0500, Jonathan Rosenberg wrote: >> > > > >Orit Levin wrote: >> > > > >>>The big huge difference I have been trying to point out is >> > > > that EVENTS >> > > > >>>DEFINES SEMANTICS, whereas INFO doesnt. >> > > > >>>MIME provides semantics and syntax that are independent of >> > > > the type. >> > > > >>>SIP events provides semantics and syntax that are >> > > > independent of the >> > > > >>>package. >> > > > >>>INFO provides nothing. >> > > > >> >> > > > >>INFO provides "minimal" but very important semantics: >> > > > asynchronous data >> > > > >>reliably follows the established SIP path. >> > > > > >> > > > >Huh? >> > > > > >> > > > >Every new SIP method is reliable, it inherits the SIP >> > > > transaction state >> > > > >machine for non-invite. Follows the established path? Every >> > > > in-dialog >> > > > >method would have this property, it is method independent. >> > > > >Asynchronous? You can send any method at any time. >> > > > > >> > > > >Thus, nothing you have pointed out above is different >> > > > between INFO and any >> > > > >other new method we might introduce. >> > > > >> > > > I think the key point is that there is a difference >> > between transport >> > > > protocol semantic and application semantic. The transport >> > > > protocol semantic >> > > > expressed in INFO is "Here is some data that will be used by the >> > > > application. It is not important to the transport protocol, >> > > > except that the >> > > > transport protocol is expected to deliver it reliably". INFO >> > > > says NOTHING >> > > > about the APPLICATION level semantic -- that's up to what >> > > > goes IN the INFO >> > > > payloads. The question is -- do we try to rigidly define >> > > > application-level >> > > > semantics here? Do we define that there ARE no such >> > > > applications possible? >> > > > Or do we design a framework by which application-level >> > > > semantics can be >> > > > expressed outside of the protocol definition? >> > > > >> > > > And as for "Just add another method to your SIP stack". Let's >> > > > say I have a >> > > > mobile phone and the SIP stack is burned into ROM and >> > exposes only a >> > > > simplistic transactional API. This is only likely to >> > happen, oh, 100 >> > > > million times or so over the next two years . . . Now, just >> > > > exactly how is >> > > > my BREW or JTME application going to go about extending the >> > > > SIP stack to >> > > > support another method? Will the evil wireless operator >> > > > networks even pass >> > > > another method? Neither is happening anytime soon, I think . . . >> > > > >> > > > -- >> > > > 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 >> > _______________________________________________ >> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> > This list is for NEW development of the core SIP 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. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 2 16:00:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14158 for ; Thu, 2 Jan 2003 16:00:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02L8gA22206 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 16:08:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02L4YJ21251; Thu, 2 Jan 2003 16:04:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02L3KJ21195 for ; Thu, 2 Jan 2003 16:03:20 -0500 Received: from EXECDSL.COM (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13987 for ; Thu, 2 Jan 2003 15:54:21 -0500 (EST) Received: from [63.113.114.131] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 4101667; Thu, 02 Jan 2003 15:57:33 -0500 Message-Id: <5.1.0.14.0.20030102155304.028405c0@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 02 Jan 2003 15:56:53 -0500 To: Jonathan Rosenberg From: "Joel M. Halpern" Subject: Re: [Sip] INFO considered harmful Cc: sip@ietf.org In-Reply-To: <3E14A4EA.8060409@dynamicsoft.com> References: <5.1.0.14.0.20030102152640.017ee838@mail.stevecrocker.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Using an SDP extension to set up the control entity communication path would be reasonable. My point is that simply saying "the applications can already communicate" (as some respondents on the list have said) is not true, as the normal usage does not permit the entities to communicate. If the communication is going to be extended, it would seem that the SDP based approach is correct. However, it would seem sensible to have a method to carry smaller pieces of information. This could possible be done with alternative content, or with extended headers. In either case, it would be for the low rate communication that would not warrant and SDP exchange to establish the session. Obviously, this is a slippery slope. We do not want to turn the control plane into a generic communication channel. (I've been there, and been unhappy doing that.) Yours, Joel At 03:45 PM 1/2/2003 -0500, Jonathan Rosenberg wrote: >Joel, > >I am not entirely sure I follow you here. As I started reading, I thought >you were proposing what I do believe is the right answer here. > >If people want to exchange proprietary data between applications that are >set up using sip, we have a way to do that. This application data can just >be considered another session type (along with audio and video) which SIP >can set up and manage for you. So, roll your own protocol (say, foo) that >does just what you want, and then use SDP to exchange the IP/ports and >protocol identification infomration needed to make it work. > >This way, proxies don't see any of it, and SIP is not being abused in any way. > >-Jonathan R. > >Joel M. Halpern wrote: >>I think that there is another way to phrase the issue which at least >>raises a fair question. >>I have an application. It uses SIP, and then (sometimes) establishes a >>media session. >>However, none of those exchanges provide the IP address of the >>controlling remote application. >>Hence, if one application control entity wants to send (or receive) >>information to (from) the other application control entity, the only >>clearly available path is through SIP messages. Preferably SIP messages >>tied to the existing session. >>Presumably, one could mandate a single header for carrying a "control >>entity IP address / port / protocol" but that seems pretty silly. >>Yours, >>Joel M. Halpern >>At 01:35 PM 1/2/2003 -0600, Adam Roach wrote: >> >>>The argument of "but I'm already holding a hammer and *want* >>>to treat everything like a nail!" comes up on about an annual >>>basis, and is rejected outright each time. >>> >>>Just because you have a SIP stack in your application does >>>*not* mean that it is appropriate to use that stack for >>>all general network access. You're allowing laziness to >>>overwhelm good application design. >>> >>>/a >>> >>> > -----Original Message----- >>> > From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] >>> > Sent: Thursday, January 02, 2003 12:55 >>> > To: 'Michael Thomas'; Eric Burger >>> > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org >>> > Subject: RE: [Sip] INFO considered harmful >>> > >>> > >>> > The application is SIP based, we dont need yet another >>> > protocol to convey what needs to be conveyed e2e. >>> > No need to go around the bush. >>> > Lets find *real* arguments against using INFO for that >>> > purpopse rather than philosphical ones. >>> > >>> > /gf >>> > >>> > >>> > >>> > >>> > -----Original Message----- >>> > From: Michael Thomas [mailto:mat@cisco.com] >>> > Sent: Thursday, January 02, 2003 12:53 PM >>> > To: Eric Burger >>> > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org >>> > Subject: RE: [Sip] INFO considered harmful >>> > >>> > >>> > >>> > I don't get it. If you want "100% application >>> > specific", why not pick an unused port and roll >>> > your own protocol? Then all of the crufty SIPism >>> > don't get in the way, and the hue and cry from >>> > this working group ceases immediately. Do the bits >>> > on the wire keep warmer if they're dressed in SIP? >>> > >>> > Mike >>> > >>> > Eric Burger writes: >>> > > I fully agree with Dean on this one. >>> > > >>> > > One point to consider (I'm on the fence on this one) is >>> > whether we would say that INFO is 100% application-specific. >>> > That is, the WG will not publish standard body types. >>> > > >>> > > A reason for doing that is to let people know that INFO >>> > really is just, as Dean points out, >>> > application-to-application communication. If you want >>> > applications to interoperate, take it either to an >>> > Application Area WG or take it outside the IETF. >>> > > >>> > > One reason to not do this is SIP-T should use a method >>> > other than INFO. That said, I don't think there are that >>> > many SIP-T implementations extant. >>> > > >>> > > >>> > > > -----Original Message----- >>> > > > From: Dean Willis [mailto:dean.willis@softarmor.com] >>> > > > Sent: Tuesday, December 31, 2002 1:48 AM >>> > > > To: Jonathan Rosenberg; Orit Levin >>> > > > Cc: sip@ietf.org >>> > > > Subject: Re: [Sip] INFO considered harmful >>> > > > >>> > > > >>> > > > At 12:48 AM 12/31/2002 -0500, Jonathan Rosenberg wrote: >>> > > > >Orit Levin wrote: >>> > > > >>>The big huge difference I have been trying to point out is >>> > > > that EVENTS >>> > > > >>>DEFINES SEMANTICS, whereas INFO doesnt. >>> > > > >>>MIME provides semantics and syntax that are independent of >>> > > > the type. >>> > > > >>>SIP events provides semantics and syntax that are >>> > > > independent of the >>> > > > >>>package. >>> > > > >>>INFO provides nothing. >>> > > > >> >>> > > > >>INFO provides "minimal" but very important semantics: >>> > > > asynchronous data >>> > > > >>reliably follows the established SIP path. >>> > > > > >>> > > > >Huh? >>> > > > > >>> > > > >Every new SIP method is reliable, it inherits the SIP >>> > > > transaction state >>> > > > >machine for non-invite. Follows the established path? Every >>> > > > in-dialog >>> > > > >method would have this property, it is method independent. >>> > > > >Asynchronous? You can send any method at any time. >>> > > > > >>> > > > >Thus, nothing you have pointed out above is different >>> > > > between INFO and any >>> > > > >other new method we might introduce. >>> > > > >>> > > > I think the key point is that there is a difference >>> > between transport >>> > > > protocol semantic and application semantic. The transport >>> > > > protocol semantic >>> > > > expressed in INFO is "Here is some data that will be used by the >>> > > > application. It is not important to the transport protocol, >>> > > > except that the >>> > > > transport protocol is expected to deliver it reliably". INFO >>> > > > says NOTHING >>> > > > about the APPLICATION level semantic -- that's up to what >>> > > > goes IN the INFO >>> > > > payloads. The question is -- do we try to rigidly define >>> > > > application-level >>> > > > semantics here? Do we define that there ARE no such >>> > > > applications possible? >>> > > > Or do we design a framework by which application-level >>> > > > semantics can be >>> > > > expressed outside of the protocol definition? >>> > > > >>> > > > And as for "Just add another method to your SIP stack". Let's >>> > > > say I have a >>> > > > mobile phone and the SIP stack is burned into ROM and >>> > exposes only a >>> > > > simplistic transactional API. This is only likely to >>> > happen, oh, 100 >>> > > > million times or so over the next two years . . . Now, just >>> > > > exactly how is >>> > > > my BREW or JTME application going to go about extending the >>> > > > SIP stack to >>> > > > support another method? Will the evil wireless operator >>> > > > networks even pass >>> > > > another method? Neither is happening anytime soon, I think . . . >>> > > > >>> > > > -- >>> > > > 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 >>> > _______________________________________________ >>> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> > This list is for NEW development of the core SIP 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. 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 2 16:02:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14247 for ; Thu, 2 Jan 2003 16:02:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02LAoj22353 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 16:10:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02L7HJ21696; Thu, 2 Jan 2003 16:07:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02L6wJ21398 for ; Thu, 2 Jan 2003 16:06:58 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14044 for ; Thu, 2 Jan 2003 15:57:59 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.143]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h02L1DYH024638; Thu, 2 Jan 2003 16:01:13 -0500 (EST) Message-ID: <3E14A895.7010804@dynamicsoft.com> Date: Thu, 02 Jan 2003 16:01:09 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Frank W. Miller" CC: sip@ietf.org Subject: Re: [Sip] INFO considered harmful References: <3E0F3B60.A1D37549@lmf.ericsson.se><00c501c2b037$db7e90f0$56fa403f@txdwillis> <15888.45814.401844.797450@thomasm-u1.cisco.com> <006c01c2b055$aab320d0$9f00000a@overhill> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Frank W. Miller wrote: > Greetings, > > I would take issue with the basic premise of the draft, which is that the > SIP and SIPPING groups need to have control over every bit that passes > through a SIP message. It is not possible for the standard to anticpate > every situation that people might want to use the protocol. It's > interesting how many times I've heard WG members say, "thats not what I > intended it for". The beauty of SIP is that its basic framework and > semantic level endear it to so many different signaling situations. The use > of INFO to supplement the corners of specific applications is a very > important part of that versatility. It is the job of the IETF to define protocols that interoperate, that scale well, that have good security, that don't congest the internet, and so on. Sometimes, there is a need for vendor proprietary extensions to such protocols. However, all vendor extensions need to live within a "sandbox" that limits the scope of what can be done. Specifically, that sandbox has to draw the line around issues of scale, security, and congestion control, which affect *other* networks and other vendors. IETF protocols are used on networks where other things live too. The problem with INFO is that it defines no such sandbox. It allows anything, and can be used in ways which will cause problems when those messages flow through other vendors equipment or run on other networks. The clearest example of that is the rate. A record-routing proxy in some other domain might get a flood of INFO messages because some app in someone elses server thought INFO was a good way to tunnel voice. Let me take this to the extreme. By your argument, TCP should allow for vendor-specified plug ins for congestion control. After all, why should IETF prevent me from using something that works well for MY application? Indeed, there is lots of research on different congestion control algorithms. TCP should allow those to be used! But, would you really want someone to be able to plug in a congestion control algorithm that basically doesn't do congestion control algorithm? I should hope not. > > JR cites three specific problems with INFO: > > Lack of interoperability: This is not a problem. Since the INFO contents > are explicitly outside the standard, this must be assumed by the > implementor. If they persist with INFO to implement some signaling > situtations, there are likely other good reasons for doing so. You have not properly interpreted my draft. THe interoperability failure is that there is know what to know the intent of the INFO method. There is no way to signal that this is the "frank's extension usage" as opposed to anyone elses. > > Inappropriateness: As I've already stated, I do not feel that the SIP and > SIPPING working groups should (let alone can) realistically expect that they > can determine how and when the protocol will be applied in applications at > this late date. Please see my above comments on this. I believe that this is a fundamental issue about the role of IETF in protocols. > > Incorrectness: Jonathan is eluding to the possiblity of errors being present > in the protocol extensions. Well, this is not the SIP and SIPPING groups > problem. These extensions are outside the scope of the standard. If the > purveyors of the extension design the error, they're responsible for it, not > the SIP and SIPPING groups. Except where those extensions impact other servers, vendors or service providers. And they can. > > As has already been noted in this thread, there are a number of fine > implementations (including Dynamicsoft) in the field, many, if not all, > including a punt to the application of the INFO body. Frank, pointing a finger at me and saying "but your company does it!" is neither a compelling argument or, IMHO, a civilized way to conduct a discussion on the list. It is frequently the case that ones company does something that one does not like, because a customer asked, or a partner is doing it, or because of one reason or another. Does that mean that we should be promoting such things as IETF standards? > This is very useful > functionality to implementors and as such it makes very little sense to > deprecate this method. Another will take its place as the abused. For > example, I've had discussions with people about doing extensions using > SUBSCRIBE/NOTIFY that had nothing whatever to do with events just because of > the "political incorrectness" of INFO. Unlike INFO, SUB/NOT defines a very well-scoped and limited repetoire of behavior for packages. So, while someone may violate the spec and do something inappropriate, it would not be IETF compliant. WIth INFO, one can do bad things and still claim to be compliant to the specifications. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 2 16:07:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14455 for ; Thu, 2 Jan 2003 16:07:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02LFf722668 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 16:15:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02LCBJ22441; Thu, 2 Jan 2003 16:12:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02LB9J22391 for ; Thu, 2 Jan 2003 16:11:09 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14245 for ; Thu, 2 Jan 2003 16:02:10 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.143]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h02L5NYH024642; Thu, 2 Jan 2003 16:05:23 -0500 (EST) Message-ID: <3E14A98F.3070803@dynamicsoft.com> Date: Thu, 02 Jan 2003 16:05:19 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: Orit Levin , sip@ietf.org Subject: Re: [Sip] INFO considered harmful References: <5.2.0.9.0.20021231004126.025ac570@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Dean Willis wrote: > At 12:48 AM 12/31/2002 -0500, Jonathan Rosenberg wrote: > >> Orit Levin wrote: >> >>>> The big huge difference I have been trying to point out is that EVENTS >>>> DEFINES SEMANTICS, whereas INFO doesnt. >>>> MIME provides semantics and syntax that are independent of the type. >>>> SIP events provides semantics and syntax that are independent of the >>>> package. >>>> INFO provides nothing. >>> >>> >>> INFO provides "minimal" but very important semantics: asynchronous data >>> reliably follows the established SIP path. >> >> >> Huh? >> >> Every new SIP method is reliable, it inherits the SIP transaction >> state machine for non-invite. Follows the established path? Every >> in-dialog method would have this property, it is method independent. >> Asynchronous? You can send any method at any time. >> >> Thus, nothing you have pointed out above is different between INFO and >> any other new method we might introduce. > > > I think the key point is that there is a difference between transport > protocol semantic and application semantic. The transport protocol > semantic expressed in INFO is "Here is some data that will be used by > the application. It is not important to the transport protocol, except > that the transport protocol is expected to deliver it reliably". Just one moment. SIP is not a transport protocol as its defined in my book. Although SIP is generic in that it can support lots of applications (conferencing, IVR, gaming, etc.), it is not unbounded. SIP's messages provide semantics common to all applications which require person-to-person communications. That does NOT make it a transport prorotocol for arbitrary data communication. > And as for "Just add another method to your SIP stack". Let's say I have > a mobile phone and the SIP stack is burned into ROM and exposes only a > simplistic transactional API. This is only likely to happen, oh, 100 > million times or so over the next two years . . . Now, just exactly how > is my BREW or JTME application going to go about extending the SIP stack > to support another method? Will the evil wireless operator networks even > pass another method? Neither is happening anytime soon, I think . . . The stack has to allow extensibility to pass unknown INFO bodies up to the application for handling. Why this is any different than having extensibility to handle unknown methods up to the application, is a mystery to me. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 2 17:06:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15800 for ; Thu, 2 Jan 2003 17:06:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02MFIG27065 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 17:15:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02MAvJ26900; Thu, 2 Jan 2003 17:10:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02M9WJ26845 for ; Thu, 2 Jan 2003 17:09:32 -0500 Received: from imr2.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15643 for ; Thu, 2 Jan 2003 17:00:33 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id h02M2uW09016; Thu, 2 Jan 2003 16:02:56 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h02M2tj04044; Thu, 2 Jan 2003 16:02:55 -0600 (CST) Received: from eammlex033.lmc.ericsson.se (eammlex033.lmc.ericsson.se [142.133.1.133]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id h02M2sh15860; Thu, 2 Jan 2003 17:02:54 -0500 (EST) Received: by eammlex033.lmc.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 2 Jan 2003 17:03:53 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C037BFC@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'Don Stanwyck'" , "George Foti (LMC)" , "'Michael Thomas'" , "'Eric Burger'" Cc: "'Dean Willis'" , "'Jonathan Rosenberg'" , sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Thu, 2 Jan 2003 17:02:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , >There is no reason to bother all the >routing proxies in the network with your e2e private chatter. How are they bothered ? What extra logic do they need? /gf -----Original Message----- From: Don Stanwyck [mailto:don@stanwyck.com] Sent: Thursday, January 02, 2003 3:13 PM To: 'George Foti (LMC)'; 'Michael Thomas'; 'Eric Burger' Cc: 'Dean Willis'; 'Jonathan Rosenberg'; sip@ietf.org Subject: RE: [Sip] INFO considered harmful I guess I have two problems with the statement below. 1) Applications should not be protocol based - they may be protocol aware. Unless the SIP stack is rolled into the application, it merely uses SIP as a lower layer tool to establish communications. It is a violation of good design to roll the protocol into the application itself. BTW, if the SIP stack is rolled into the application, then when the next edition of SIP comes along you will have to rewrite the app. You really should have an API that keeps the app from needing to know the details of the communication establishment protocol. 2) If the apps need to talk directly to each other there are a host of protocols that are extremely trivial that can do the job. The apps can even just open a port over any transport protocol and exchange information as they please. There is no reason to bother all the routing proxies in the network with your e2e private chatter. Just a thought. don > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of George Foti (LMC) > Sent: Thursday, January 02, 2003 11:55 AM > To: 'Michael Thomas'; Eric Burger > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > Subject: RE: [Sip] INFO considered harmful > > > The application is SIP based, we dont need yet another > protocol to convey what needs to be conveyed e2e. No need to > go around the bush. Lets find *real* arguments against using > INFO for that purpopse rather than philosphical ones. > > /gf > > > > > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Thursday, January 02, 2003 12:53 PM > To: Eric Burger > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > Subject: RE: [Sip] INFO considered harmful > > > > I don't get it. If you want "100% application > specific", why not pick an unused port and roll > your own protocol? Then all of the crufty SIPism > don't get in the way, and the hue and cry from > this working group ceases immediately. Do the bits > on the wire keep warmer if they're dressed in SIP? > > Mike > > Eric Burger writes: > > I fully agree with Dean on this one. > > > > One point to consider (I'm on the fence on this one) is > whether we would say that INFO is 100% application-specific. > That is, the WG will not publish standard body types. > > > A reason for doing that is to let people know that INFO > really is just, as Dean points out, > application-to-application communication. If you want > applications to interoperate, take it either to an > Application Area WG or take it outside the IETF. > > > One reason to not do this is SIP-T should use a method > other than INFO. That said, I don't think there are that > many SIP-T implementations extant. > > > > > > -----Original Message----- > > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > Sent: Tuesday, December 31, 2002 1:48 AM > > > To: Jonathan Rosenberg; Orit Levin > > > Cc: sip@ietf.org > > > Subject: Re: [Sip] INFO considered harmful > > > > > > > > > At 12:48 AM 12/31/2002 -0500, Jonathan Rosenberg wrote: > > > >Orit Levin wrote: > > > >>>The big huge difference I have been trying to point out is > > > that EVENTS > > > >>>DEFINES SEMANTICS, whereas INFO doesnt. > > > >>>MIME provides semantics and syntax that are independent of > > > the type. > > > >>>SIP events provides semantics and syntax that are > > > independent of the > > > >>>package. > > > >>>INFO provides nothing. > > > >> > > > >>INFO provides "minimal" but very important semantics: > > > asynchronous data > > > >>reliably follows the established SIP path. > > > > > > > >Huh? > > > > > > > >Every new SIP method is reliable, it inherits the SIP > > > transaction state > > > >machine for non-invite. Follows the established path? Every > > > in-dialog > > > >method would have this property, it is method independent. > > > >Asynchronous? You can send any method at any time. > > > > > > > >Thus, nothing you have pointed out above is different > > > between INFO and any > > > >other new method we might introduce. > > > > > > I think the key point is that there is a difference > between transport > > > protocol semantic and application semantic. The transport > > > protocol semantic > > > expressed in INFO is "Here is some data that will be used by the > > > application. It is not important to the transport protocol, > > > except that the > > > transport protocol is expected to deliver it reliably". INFO > > > says NOTHING > > > about the APPLICATION level semantic -- that's up to what > > > goes IN the INFO > > > payloads. The question is -- do we try to rigidly define > > > application-level > > > semantics here? Do we define that there ARE no such > > > applications possible? > > > Or do we design a framework by which application-level > > > semantics can be > > > expressed outside of the protocol definition? > > > > > > And as for "Just add another method to your SIP stack". Let's > > > say I have a > > > mobile phone and the SIP stack is burned into ROM and > exposes only a > > > simplistic transactional API. This is only likely to > happen, oh, 100 > > > million times or so over the next two years . . . Now, just > > > exactly how is > > > my BREW or JTME application going to go about extending the > > > SIP stack to > > > support another method? Will the evil wireless operator > > > networks even pass > > > another method? Neither is happening anytime soon, I > think . . . > > > > > -- > > > 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 _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Jan 2 17:07:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15820 for ; Thu, 2 Jan 2003 17:07:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02MG0f27104 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 17:16:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02MCHJ26950; Thu, 2 Jan 2003 17:12:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02MB0J26904 for ; Thu, 2 Jan 2003 17:11:00 -0500 Received: from imr2.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15677 for ; Thu, 2 Jan 2003 17:02:01 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id h02M4iW09497; Thu, 2 Jan 2003 16:04:44 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h02M4hj04500; Thu, 2 Jan 2003 16:04:44 -0600 (CST) Received: from eammlex033.lmc.ericsson.se (eammlex033.lmc.ericsson.se [142.133.1.133]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id h02M4hh15877; Thu, 2 Jan 2003 17:04:43 -0500 (EST) Received: by eammlex033.lmc.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 2 Jan 2003 17:05:42 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C037BFD@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'Adam Roach'" , "George Foti (LMC)" , "'Michael Thomas'" , Eric Burger Cc: Dean Willis , Jonathan Rosenberg , sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Thu, 2 Jan 2003 17:04:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This should not be a philosophical discusion. If a new SIP method is okay, why is INFO not okay. What is the difference? Please explain in technical terms? /gf -----Original Message----- From: Adam Roach [mailto:adam@dynamicsoft.com] Sent: Thursday, January 02, 2003 2:36 PM To: 'George Foti (LMC)'; 'Michael Thomas'; Eric Burger Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org Subject: RE: [Sip] INFO considered harmful The argument of "but I'm already holding a hammer and *want* to treat everything like a nail!" comes up on about an annual basis, and is rejected outright each time. Just because you have a SIP stack in your application does *not* mean that it is appropriate to use that stack for all general network access. You're allowing laziness to overwhelm good application design. /a > -----Original Message----- > From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] > Sent: Thursday, January 02, 2003 12:55 > To: 'Michael Thomas'; Eric Burger > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > Subject: RE: [Sip] INFO considered harmful > > > The application is SIP based, we dont need yet another > protocol to convey what needs to be conveyed e2e. > No need to go around the bush. > Lets find *real* arguments against using INFO for that > purpopse rather than philosphical ones. > > /gf > > > > > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Thursday, January 02, 2003 12:53 PM > To: Eric Burger > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > Subject: RE: [Sip] INFO considered harmful > > > > I don't get it. If you want "100% application > specific", why not pick an unused port and roll > your own protocol? Then all of the crufty SIPism > don't get in the way, and the hue and cry from > this working group ceases immediately. Do the bits > on the wire keep warmer if they're dressed in SIP? > > Mike > > Eric Burger writes: > > I fully agree with Dean on this one. > > > > One point to consider (I'm on the fence on this one) is > whether we would say that INFO is 100% application-specific. > That is, the WG will not publish standard body types. > > > > A reason for doing that is to let people know that INFO > really is just, as Dean points out, > application-to-application communication. If you want > applications to interoperate, take it either to an > Application Area WG or take it outside the IETF. > > > > One reason to not do this is SIP-T should use a method > other than INFO. That said, I don't think there are that > many SIP-T implementations extant. > > > > > > > -----Original Message----- > > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > Sent: Tuesday, December 31, 2002 1:48 AM > > > To: Jonathan Rosenberg; Orit Levin > > > Cc: sip@ietf.org > > > Subject: Re: [Sip] INFO considered harmful > > > > > > > > > At 12:48 AM 12/31/2002 -0500, Jonathan Rosenberg wrote: > > > >Orit Levin wrote: > > > >>>The big huge difference I have been trying to point out is > > > that EVENTS > > > >>>DEFINES SEMANTICS, whereas INFO doesnt. > > > >>>MIME provides semantics and syntax that are independent of > > > the type. > > > >>>SIP events provides semantics and syntax that are > > > independent of the > > > >>>package. > > > >>>INFO provides nothing. > > > >> > > > >>INFO provides "minimal" but very important semantics: > > > asynchronous data > > > >>reliably follows the established SIP path. > > > > > > > >Huh? > > > > > > > >Every new SIP method is reliable, it inherits the SIP > > > transaction state > > > >machine for non-invite. Follows the established path? Every > > > in-dialog > > > >method would have this property, it is method independent. > > > >Asynchronous? You can send any method at any time. > > > > > > > >Thus, nothing you have pointed out above is different > > > between INFO and any > > > >other new method we might introduce. > > > > > > I think the key point is that there is a difference > between transport > > > protocol semantic and application semantic. The transport > > > protocol semantic > > > expressed in INFO is "Here is some data that will be used by the > > > application. It is not important to the transport protocol, > > > except that the > > > transport protocol is expected to deliver it reliably". INFO > > > says NOTHING > > > about the APPLICATION level semantic -- that's up to what > > > goes IN the INFO > > > payloads. The question is -- do we try to rigidly define > > > application-level > > > semantics here? Do we define that there ARE no such > > > applications possible? > > > Or do we design a framework by which application-level > > > semantics can be > > > expressed outside of the protocol definition? > > > > > > And as for "Just add another method to your SIP stack". Let's > > > say I have a > > > mobile phone and the SIP stack is burned into ROM and > exposes only a > > > simplistic transactional API. This is only likely to > happen, oh, 100 > > > million times or so over the next two years . . . Now, just > > > exactly how is > > > my BREW or JTME application going to go about extending the > > > SIP stack to > > > support another method? Will the evil wireless operator > > > networks even pass > > > another method? Neither is happening anytime soon, I think . . . > > > > > > -- > > > 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 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Jan 2 17:59:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16453 for ; Thu, 2 Jan 2003 17:59:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02N7eE30314 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 18:07:40 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02N3rJ29555; Thu, 2 Jan 2003 18:03:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02N2PJ29507 for ; Thu, 2 Jan 2003 18:02:25 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16419 for ; Thu, 2 Jan 2003 17:53:25 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h02MtBSK009939; Thu, 2 Jan 2003 17:55:11 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Jan 2003 16:56:33 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A643BD@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'George Foti (LMC)'" , Adam Roach , "'Michael Thomas'" , Eric Burger Cc: Dean Willis , Jonathan Rosenberg , sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Thu, 2 Jan 2003 16:56:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , A new method would be okay for new SIP-related functionality. But that's not what you proposed. You said, "The application is SIP based, we dont need yet another protocol to convey what needs to be conveyed e2e," which is an argument that we should use SIP as a general purpose RPC mechanism for any application that already has a SIP stack. Doing what you propose with INFO is inappropriate. Doing what you propose with a new method is inappropriate. Doing what you propose with SIP is inappropriate. Since you keep harping on technical, as opposed to philosophical, arguments, here's a couple: - The SIP protocol was designed for session initiation, negotiation, and teardown. The timing characteristics are not generally appropriate for application control. For example, with typical SIP networks, latency and jitter of messages are too high to provide any sort of reasonable user experience for floor control or DTMF transport. - Many proxies stay in the signalling path for the purposes of providing services. By sending unnecessary application- level information throught these proxies, you reduce the capacity and increase possible congestion of the network. I could go on, but this topic has had extensive airing on the list in years past. There's really no reason to beat this particular dead horse any longer. /a > -----Original Message----- > From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] > Sent: Thursday, January 02, 2003 16:05 > To: 'Adam Roach'; George Foti (LMC); 'Michael Thomas'; Eric Burger > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > Subject: RE: [Sip] INFO considered harmful > > > This should not be a philosophical discusion. > If a new SIP method is okay, why is INFO not okay. > > What is the difference? > Please explain in technical terms? > > /gf > > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Thursday, January 02, 2003 2:36 PM > To: 'George Foti (LMC)'; 'Michael Thomas'; Eric Burger > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > Subject: RE: [Sip] INFO considered harmful > > > The argument of "but I'm already holding a hammer and *want* > to treat everything like a nail!" comes up on about an annual > basis, and is rejected outright each time. > > Just because you have a SIP stack in your application does > *not* mean that it is appropriate to use that stack for > all general network access. You're allowing laziness to > overwhelm good application design. > > /a > > > -----Original Message----- > > From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] > > Sent: Thursday, January 02, 2003 12:55 > > To: 'Michael Thomas'; Eric Burger > > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > > Subject: RE: [Sip] INFO considered harmful > > > > > > The application is SIP based, we dont need yet another > > protocol to convey what needs to be conveyed e2e. > > No need to go around the bush. > > Lets find *real* arguments against using INFO for that > > purpopse rather than philosphical ones. > > > > /gf > > > > > > > > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Thursday, January 02, 2003 12:53 PM > > To: Eric Burger > > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > > Subject: RE: [Sip] INFO considered harmful > > > > > > > > I don't get it. If you want "100% application > > specific", why not pick an unused port and roll > > your own protocol? Then all of the crufty SIPism > > don't get in the way, and the hue and cry from > > this working group ceases immediately. Do the bits > > on the wire keep warmer if they're dressed in SIP? > > > > Mike > > > > Eric Burger writes: > > > I fully agree with Dean on this one. > > > > > > One point to consider (I'm on the fence on this one) is > > whether we would say that INFO is 100% application-specific. > > That is, the WG will not publish standard body types. > > > > > > A reason for doing that is to let people know that INFO > > really is just, as Dean points out, > > application-to-application communication. If you want > > applications to interoperate, take it either to an > > Application Area WG or take it outside the IETF. > > > > > > One reason to not do this is SIP-T should use a method > > other than INFO. That said, I don't think there are that > > many SIP-T implementations extant. > > > > > > > > > > -----Original Message----- > > > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > > Sent: Tuesday, December 31, 2002 1:48 AM > > > > To: Jonathan Rosenberg; Orit Levin > > > > Cc: sip@ietf.org > > > > Subject: Re: [Sip] INFO considered harmful > > > > > > > > > > > > At 12:48 AM 12/31/2002 -0500, Jonathan Rosenberg wrote: > > > > >Orit Levin wrote: > > > > >>>The big huge difference I have been trying to point out is > > > > that EVENTS > > > > >>>DEFINES SEMANTICS, whereas INFO doesnt. > > > > >>>MIME provides semantics and syntax that are independent of > > > > the type. > > > > >>>SIP events provides semantics and syntax that are > > > > independent of the > > > > >>>package. > > > > >>>INFO provides nothing. > > > > >> > > > > >>INFO provides "minimal" but very important semantics: > > > > asynchronous data > > > > >>reliably follows the established SIP path. > > > > > > > > > >Huh? > > > > > > > > > >Every new SIP method is reliable, it inherits the SIP > > > > transaction state > > > > >machine for non-invite. Follows the established path? Every > > > > in-dialog > > > > >method would have this property, it is method independent. > > > > >Asynchronous? You can send any method at any time. > > > > > > > > > >Thus, nothing you have pointed out above is different > > > > between INFO and any > > > > >other new method we might introduce. > > > > > > > > I think the key point is that there is a difference > > between transport > > > > protocol semantic and application semantic. The transport > > > > protocol semantic > > > > expressed in INFO is "Here is some data that will be > used by the > > > > application. It is not important to the transport protocol, > > > > except that the > > > > transport protocol is expected to deliver it reliably". INFO > > > > says NOTHING > > > > about the APPLICATION level semantic -- that's up to what > > > > goes IN the INFO > > > > payloads. The question is -- do we try to rigidly define > > > > application-level > > > > semantics here? Do we define that there ARE no such > > > > applications possible? > > > > Or do we design a framework by which application-level > > > > semantics can be > > > > expressed outside of the protocol definition? > > > > > > > > And as for "Just add another method to your SIP stack". Let's > > > > say I have a > > > > mobile phone and the SIP stack is burned into ROM and > > exposes only a > > > > simplistic transactional API. This is only likely to > > happen, oh, 100 > > > > million times or so over the next two years . . . Now, just > > > > exactly how is > > > > my BREW or JTME application going to go about extending the > > > > SIP stack to > > > > support another method? Will the evil wireless operator > > > > networks even pass > > > > another method? Neither is happening anytime soon, I > think . . . > > > > > > > > -- > > > > 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 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Jan 2 18:05:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16562 for ; Thu, 2 Jan 2003 18:05:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02NDif30648 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 18:13:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02NAFJ30450; Thu, 2 Jan 2003 18:10:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02N9ZJ30405 for ; Thu, 2 Jan 2003 18:09:35 -0500 Received: from mpls-qmqp-02.inet.qwest.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16506 for ; Thu, 2 Jan 2003 18:00:34 -0500 (EST) Received: (qmail 73081 invoked by uid 0); 2 Jan 2003 22:50:07 -0000 Received: from mpls-pop-02.inet.qwest.net (63.231.195.2) by mpls-qmqp-02.inet.qwest.net with QMQP; 2 Jan 2003 22:50:07 -0000 Received: from unknown (HELO DONGWLAPTOP) (63.229.230.222) by mpls-pop-02.inet.qwest.net with SMTP; 2 Jan 2003 23:03:44 -0000 Date: Thu, 2 Jan 2003 16:02:05 -0700 Message-ID: <006d01c2b2b2$f849bca0$0300000a@DONGWLAPTOP> From: "Don Stanwyck" To: "'George Foti (LMC)'" , "'George Foti (LMC)'" , "'Michael Thomas'" , "'Eric Burger'" Cc: "'Dean Willis'" , "'Jonathan Rosenberg'" , sip@ietf.org Subject: RE: [Sip] INFO considered harmful MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <32CD630F6CBED411AE180008C7894CBC0C037BFC@lmc37.lmc.ericsson.se> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h02N9ZJ30406 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit It increases the number of transactions they have to process. Nothing in life is free. SIP Proxies, like other call routing devices, assume a certain number of transactions per call as part of their design numbers. This is important for traffic engineering. If we allow SIP to become the new FTP protocol (and there is nothing right now that would stop a UA from using SIP-INFO for FTP or FTP like functions), then the calls/second counts and all other traffic engineering rules that are needed for proper network operation become meaningless. Don > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of George Foti (LMC) > Sent: Thursday, January 02, 2003 3:03 PM > To: 'Don Stanwyck'; George Foti (LMC); 'Michael Thomas'; 'Eric Burger' > Cc: 'Dean Willis'; 'Jonathan Rosenberg'; sip@ietf.org > Subject: RE: [Sip] INFO considered harmful > > > >There is no reason to bother all the > >routing proxies in the network with your e2e private chatter. > > How are they bothered ? > What extra logic do they need? > > /gf > > > -----Original Message----- > From: Don Stanwyck [mailto:don@stanwyck.com] > Sent: Thursday, January 02, 2003 3:13 PM > To: 'George Foti (LMC)'; 'Michael Thomas'; 'Eric Burger' > Cc: 'Dean Willis'; 'Jonathan Rosenberg'; sip@ietf.org > Subject: RE: [Sip] INFO considered harmful > > > I guess I have two problems with the statement below. > > 1) Applications should not be protocol based - they may be > protocol aware. Unless the SIP stack is rolled into the > application, it merely uses SIP as a lower layer tool to > establish communications. It is a violation of good design > to roll the protocol into the application itself. > BTW, if the SIP stack is rolled into the application, then > when the next edition of SIP comes along you will have to > rewrite the app. You really should have an API that keeps > the app from needing to know the details of the communication > establishment protocol. > > 2) If the apps need to talk directly to each other there are > a host of protocols that are extremely trivial that can do > the job. The apps can even just open a port over any > transport protocol and exchange information as they please. > There is no reason to bother all the routing proxies in the > network with your e2e private chatter. > > Just a thought. > don > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > > Behalf Of George Foti (LMC) > > Sent: Thursday, January 02, 2003 11:55 AM > > To: 'Michael Thomas'; Eric Burger > > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > > Subject: RE: [Sip] INFO considered harmful > > > > > > The application is SIP based, we dont need yet another > > protocol to convey what needs to be conveyed e2e. No need to > > go around the bush. Lets find *real* arguments against using > > INFO for that purpopse rather than philosphical ones. > > > > /gf > > > > > > > > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Thursday, January 02, 2003 12:53 PM > > To: Eric Burger > > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > > Subject: RE: [Sip] INFO considered harmful > > > > > > > > I don't get it. If you want "100% application > > specific", why not pick an unused port and roll > > your own protocol? Then all of the crufty SIPism > > don't get in the way, and the hue and cry from > > this working group ceases immediately. Do the bits > > on the wire keep warmer if they're dressed in SIP? > > > > Mike > > > > Eric Burger writes: > > > I fully agree with Dean on this one. > > > > > > One point to consider (I'm on the fence on this one) is > > whether we would say that INFO is 100% application-specific. > > That is, the WG will not publish standard body types. > > > > A reason for doing that is to let people know that INFO > > really is just, as Dean points out, > > application-to-application communication. If you want > > applications to interoperate, take it either to an > > Application Area WG or take it outside the IETF. > > > > One reason to not do this is SIP-T should use a method > > other than INFO. That said, I don't think there are that > > many SIP-T implementations extant. > > > > > > > > -----Original Message----- > > > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > > Sent: Tuesday, December 31, 2002 1:48 AM > > > > To: Jonathan Rosenberg; Orit Levin > > > > Cc: sip@ietf.org > > > > Subject: Re: [Sip] INFO considered harmful > > > > > > > > > > > > At 12:48 AM 12/31/2002 -0500, Jonathan Rosenberg wrote: > > > > >Orit Levin wrote: > > > > >>>The big huge difference I have been trying to point out is > > > > that EVENTS > > > > >>>DEFINES SEMANTICS, whereas INFO doesnt. > > > > >>>MIME provides semantics and syntax that are independent of > > > > the type. > > > > >>>SIP events provides semantics and syntax that are > > > > independent of the > > > > >>>package. > > > > >>>INFO provides nothing. > > > > >> > > > > >>INFO provides "minimal" but very important semantics: > > > > asynchronous data > > > > >>reliably follows the established SIP path. > > > > > > > > > >Huh? > > > > > > > > > >Every new SIP method is reliable, it inherits the SIP > > > > transaction state > > > > >machine for non-invite. Follows the established path? Every > > > > in-dialog > > > > >method would have this property, it is method independent. > > > > >Asynchronous? You can send any method at any time. > > > > > > > > > >Thus, nothing you have pointed out above is different > > > > between INFO and any > > > > >other new method we might introduce. > > > > > > > > I think the key point is that there is a difference > > between transport > > > > protocol semantic and application semantic. The transport > > > > protocol semantic > > > > expressed in INFO is "Here is some data that will be > used by the > > > > application. It is not important to the transport protocol, > > > > except that the > > > > transport protocol is expected to deliver it reliably". INFO > > > > says NOTHING > > > > about the APPLICATION level semantic -- that's up to what > > > > goes IN the INFO > > > > payloads. The question is -- do we try to rigidly define > > > > application-level > > > > semantics here? Do we define that there ARE no such > > > > applications possible? > > > > Or do we design a framework by which application-level > > > > semantics can be > > > > expressed outside of the protocol definition? > > > > > > > > And as for "Just add another method to your SIP stack". Let's > > > > say I have a > > > > mobile phone and the SIP stack is burned into ROM and > > exposes only a > > > > simplistic transactional API. This is only likely to > > happen, oh, 100 > > > > million times or so over the next two years . . . Now, just > > > > exactly how is > > > > my BREW or JTME application going to go about extending the > > > > SIP stack to > > > > support another method? Will the evil wireless operator > > > > networks even pass > > > > another method? Neither is happening anytime soon, I > > think . . . > > > > > > -- > > > > 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 _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Jan 2 18:08:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16609 for ; Thu, 2 Jan 2003 18:08:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02NGmZ30788 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 18:16:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02NDGJ30633; Thu, 2 Jan 2003 18:13:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02NCRJ30579 for ; Thu, 2 Jan 2003 18:12:27 -0500 Received: from mpls-qmqp-02.inet.qwest.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16531 for ; Thu, 2 Jan 2003 18:03:26 -0500 (EST) Received: (qmail 76014 invoked by uid 0); 2 Jan 2003 22:53:00 -0000 Received: from mpls-pop-10.inet.qwest.net (63.231.195.10) by mpls-qmqp-02.inet.qwest.net with QMQP; 2 Jan 2003 22:53:00 -0000 Received: from unknown (HELO DONGWLAPTOP) (63.229.230.222) by mpls-pop-10.inet.qwest.net with SMTP; 2 Jan 2003 23:06:36 -0000 Date: Thu, 2 Jan 2003 16:04:57 -0700 Message-ID: <006e01c2b2b3$5efc2c30$0300000a@DONGWLAPTOP> From: "Don Stanwyck" To: "'Don Stanwyck'" , "'George Foti (LMC)'" , "'George Foti (LMC)'" , "'Michael Thomas'" , "'Eric Burger'" Cc: "'Dean Willis'" , "'Jonathan Rosenberg'" , sip@ietf.org Subject: RE: [Sip] INFO considered harmful MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h02NCRJ30580 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit To follow up my own posting (bad form, I know), I thought I should mention a real life example that worries me. Many new cell phones have picture taking and picture sending capabilities. Some even allow for "movie" modes that send a picture per second of so. If the call is set up using SIP and the phone then wants to send all these photos also over SIP, then the SIP proxies in the network can become overloaded with what should be a low priority traffic instead of being used for their design purpose - to process communication session establishment information. Don > -----Original Message----- > From: Don Stanwyck [mailto:don@stanwyck.com] > Sent: Thursday, January 02, 2003 4:02 PM > To: 'George Foti (LMC)'; 'George Foti (LMC)'; 'Michael > Thomas'; 'Eric Burger' > Cc: 'Dean Willis'; 'Jonathan Rosenberg'; 'sip@ietf.org' > Subject: RE: [Sip] INFO considered harmful > > > It increases the number of transactions they have to process. > Nothing in life is free. SIP Proxies, like other call > routing devices, assume a certain number of transactions per > call as part of their design numbers. This is important for > traffic engineering. > > If we allow SIP to become the new FTP protocol (and there is > nothing right now that would stop a UA from using SIP-INFO > for FTP or FTP like functions), then the calls/second counts > and all other traffic engineering rules that are needed for > proper network operation become meaningless. > > Don > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > > Behalf Of George Foti (LMC) > > Sent: Thursday, January 02, 2003 3:03 PM > > To: 'Don Stanwyck'; George Foti (LMC); 'Michael Thomas'; > 'Eric Burger' > > Cc: 'Dean Willis'; 'Jonathan Rosenberg'; sip@ietf.org > > Subject: RE: [Sip] INFO considered harmful > > > > > > >There is no reason to bother all the > > >routing proxies in the network with your e2e private chatter. > > > > How are they bothered ? > > What extra logic do they need? > > > > /gf > > > > > > -----Original Message----- > > From: Don Stanwyck [mailto:don@stanwyck.com] > > Sent: Thursday, January 02, 2003 3:13 PM > > To: 'George Foti (LMC)'; 'Michael Thomas'; 'Eric Burger' > > Cc: 'Dean Willis'; 'Jonathan Rosenberg'; sip@ietf.org > > Subject: RE: [Sip] INFO considered harmful > > > > > > I guess I have two problems with the statement below. > > > > 1) Applications should not be protocol based - they may be > > protocol aware. Unless the SIP stack is rolled into the > > application, it merely uses SIP as a lower layer tool to > > establish communications. It is a violation of good design > > to roll the protocol into the application itself. > > BTW, if the SIP stack is rolled into the application, then > > when the next edition of SIP comes along you will have to > > rewrite the app. You really should have an API that keeps > > the app from needing to know the details of the communication > > establishment protocol. > > > > 2) If the apps need to talk directly to each other there are > > a host of protocols that are extremely trivial that can do > > the job. The apps can even just open a port over any > > transport protocol and exchange information as they please. > > There is no reason to bother all the routing proxies in the > > network with your e2e private chatter. > > > > Just a thought. > > don > > > > > -----Original Message----- > > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of > > > George Foti (LMC) > > > Sent: Thursday, January 02, 2003 11:55 AM > > > To: 'Michael Thomas'; Eric Burger > > > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > > > Subject: RE: [Sip] INFO considered harmful > > > > > > > > > The application is SIP based, we dont need yet another > protocol to > > > convey what needs to be conveyed e2e. No need to go > around the bush. > > > Lets find *real* arguments against using INFO for that purpopse > > > rather than philosphical ones. > > > > > > /gf > > > > > > > > > > > > > > > -----Original Message----- > > > From: Michael Thomas [mailto:mat@cisco.com] > > > Sent: Thursday, January 02, 2003 12:53 PM > > > To: Eric Burger > > > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > > > Subject: RE: [Sip] INFO considered harmful > > > > > > > > > > > > I don't get it. If you want "100% application > > > specific", why not pick an unused port and roll > > > your own protocol? Then all of the crufty SIPism > > > don't get in the way, and the hue and cry from > > > this working group ceases immediately. Do the bits > > > on the wire keep warmer if they're dressed in SIP? > > > > > > Mike > > > > > > Eric Burger writes: > > > > I fully agree with Dean on this one. > > > > > > > > One point to consider (I'm on the fence on this one) is > > > whether we would say that INFO is 100% application-specific. > > > That is, the WG will not publish standard body types. > > > > > A reason for doing that is to let people know that INFO > > > really is just, as Dean points out, > > > application-to-application communication. If you want > > > applications to interoperate, take it either to an > > > Application Area WG or take it outside the IETF. > > > > > One reason to not do this is SIP-T should use a method > > > other than INFO. That said, I don't think there are that > > > many SIP-T implementations extant. > > > > > > > > > > -----Original Message----- > > > > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > > > Sent: Tuesday, December 31, 2002 1:48 AM > > > > > To: Jonathan Rosenberg; Orit Levin > > > > > Cc: sip@ietf.org > > > > > Subject: Re: [Sip] INFO considered harmful > > > > > > > > > > > > > > > At 12:48 AM 12/31/2002 -0500, Jonathan Rosenberg wrote: > > > > > >Orit Levin wrote: > > > > > >>>The big huge difference I have been trying to > point out is > > > > > that EVENTS > > > > > >>>DEFINES SEMANTICS, whereas INFO doesnt. > > > > > >>>MIME provides semantics and syntax that are > independent of > > > > > the type. > > > > > >>>SIP events provides semantics and syntax that are > > > > > independent of the > > > > > >>>package. > > > > > >>>INFO provides nothing. > > > > > >> > > > > > >>INFO provides "minimal" but very important semantics: > > > > > asynchronous data > > > > > >>reliably follows the established SIP path. > > > > > > > > > > > >Huh? > > > > > > > > > > > >Every new SIP method is reliable, it inherits the SIP > > > > > transaction state > > > > > >machine for non-invite. Follows the established path? Every > > > > > in-dialog > > > > > >method would have this property, it is method independent. > > > > > >Asynchronous? You can send any method at any time. > > > > > > > > > > > >Thus, nothing you have pointed out above is different > > > > > between INFO and any > > > > > >other new method we might introduce. > > > > > > > > > > I think the key point is that there is a difference > > > between transport > > > > > protocol semantic and application semantic. The transport > > > > > protocol semantic > > > > > expressed in INFO is "Here is some data that will be > > used by the > > > > > application. It is not important to the transport protocol, > > > > > except that the > > > > > transport protocol is expected to deliver it reliably". INFO > > > > > says NOTHING > > > > > about the APPLICATION level semantic -- that's up to what > > > > > goes IN the INFO > > > > > payloads. The question is -- do we try to rigidly define > > > > > application-level > > > > > semantics here? Do we define that there ARE no such > > > > > applications possible? > > > > > Or do we design a framework by which application-level > > > > > semantics can be > > > > > expressed outside of the protocol definition? > > > > > > > > > > And as for "Just add another method to your SIP > stack". Let's > > > > > say I have a > > > > > mobile phone and the SIP stack is burned into ROM and > > > exposes only a > > > > > simplistic transactional API. This is only likely to > > > happen, oh, 100 > > > > > million times or so over the next two years . . . Now, just > > > > > exactly how is > > > > > my BREW or JTME application going to go about extending the > > > > > SIP stack to > > > > > support another method? Will the evil wireless operator > > > > > networks even pass > > > > > another method? Neither is happening anytime soon, I > > > think . . . > > > > > > > -- > > > > > 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 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Jan 2 18:35:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16988 for ; Thu, 2 Jan 2003 18:35:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02Nhxk32505 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 18:43:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02NeUJ32324; Thu, 2 Jan 2003 18:40:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02NdKJ32255 for ; Thu, 2 Jan 2003 18:39:20 -0500 Received: from face.sentitonetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16876 for ; Thu, 2 Jan 2003 18:30:20 -0500 (EST) Received: (qmail 63757 invoked from network); 2 Jan 2003 23:33:31 -0000 Received: from unknown (HELO overhill) (10.0.0.159) by face.sentito.com with SMTP; 2 Jan 2003 23:33:31 -0000 Message-ID: <00aa01c2b2b7$5c943010$9f00000a@overhill> From: "Frank W. Miller" To: "Jonathan Rosenberg" Cc: References: <3E0F3B60.A1D37549@lmf.ericsson.se><00c501c2b037$db7e90f0$56fa403f@txdwillis> <15888.45814.401844.797450@thomasm-u1.cisco.com> <006c01c2b055$aab320d0$9f00000a@overhill> <3E14A895.7010804@dynamicsoft.com> Subject: Re: [Sip] INFO considered harmful Date: Thu, 2 Jan 2003 18:33:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thanks for the thoughtful reply. Comments inline... ----- Original Message ----- From: "Jonathan Rosenberg" To: "Frank W. Miller" Cc: Sent: Thursday, January 02, 2003 4:01 PM Subject: Re: [Sip] INFO considered harmful > > Sometimes, there is a need for vendor proprietary extensions > to such protocols. However, all vendor extensions need to live within a > "sandbox" that limits the scope of what can be done. I think this is really the crux of the issue for me. Because this is a signaling protocol and not a routing or transport protocol, the need to provide for corner cases and extensions over time is greater. > The problem with INFO is that it defines no such sandbox. Absolutely correct and absolutely a potential problem for a variety of reasons, including clobbering the intermediary servers. But, the reality is, application implementors need some kind of app-to-app tunneling for stuff that isn't explictily handled. Also a reality is that INFO has been around for awhile and people are using it. In lieu of something better, the mechanism has to be there. In a way, using INFO can actually be a good thing because it paints a great big red "A" on the packet as soon as it show up somewhere. If it were in some other legal method that was being abused, the potential for abuse might not be as easy to spot. > Let me take this to the extreme. By your argument, TCP should allow for > vendor-specified plug ins for congestion control. After all, why should > IETF prevent me from using something that works well for MY application? > Indeed, there is lots of research on different congestion control > algorithms. TCP should allow those to be used! But, would you really > want someone to be able to plug in a congestion control algorithm that > basically doesn't do congestion control algorithm? I should hope not. > Your point is well taken, but I would refer back to my earlier statement. This is a signaling protocol, and has different, higher-level semantic requirements placed on it. The need for various congestion control algorithms (to continue your example) is mitigated by the fact that the existing protocol covers a huge portion of the requirement space. This is not as clear with a signaling protocol. > > > > As has already been noted in this thread, there are a number of fine > > implementations (including Dynamicsoft) in the field, many, if not all, > > including a punt to the application of the INFO body. > > Frank, pointing a finger at me and saying "but your company does it!" is > neither a compelling argument or, IMHO, a civilized way to conduct a > discussion on the list. It is frequently the case that ones company does > something that one does not like, because a customer asked, or a partner > is doing it, or because of one reason or another. Does that mean that we > should be promoting such things as IETF standards? > My apologies. I should have realized that just because it might be in your product, that would not necessarily affect your opinion in the IETF forum. But that was not really the intent of my comment. I was simply trying to point out that the need for tunneling is apparent since all the major vendors are supporting what their customers have required, nothing more. > > > This is very useful > > functionality to implementors and as such it makes very little sense to > > deprecate this method. Another will take its place as the abused. For > > example, I've had discussions with people about doing extensions using > > SUBSCRIBE/NOTIFY that had nothing whatever to do with events just because of > > the "political incorrectness" of INFO. > > Unlike INFO, SUB/NOT defines a very well-scoped and limited repetoire of > behavior for packages. So, while someone may violate the spec and do > something inappropriate, it would not be IETF compliant. WIth INFO, one > can do bad things and still claim to be compliant to the specifications. > So, there it is. What we really need is a substitute for INFO that works the way implementors need but also has the appropriate scaling and safety properties. I think the substitute consists of two parts. 1) A method/methods that allow for some degree of application-to-application tunneling 2) An IETF process associated with this method that allows for incorporation of this tunneling into the mainline protocol over time Ideally, if 1) is done right, very little syntactic change to extensions would be necessary for 2) to happen. The split of SIP into SIP/SIPPING was a step down the road to 2) What was missing from that was 1). If there was a a 1), the flow of new elements coming into these WGs and subsequently into the standard might have more rigor and hopefully progress more quickly. Thanks again, FM Frank W. Miller, Ph.D. Chief Technical Officer sentitO Networks, Inc. fmiller@sentito.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 mailnull@www1.ietf.org Thu Jan 2 18:58:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17306 for ; Thu, 2 Jan 2003 18:58:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0307Rw01477 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 19:07:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0303MJ00882; Thu, 2 Jan 2003 19:03:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03028J00837 for ; Thu, 2 Jan 2003 19:02:08 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17202 for ; Thu, 2 Jan 2003 18:53:06 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id h02NuFfm005057; Thu, 2 Jan 2003 15:56:15 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id ABA34274; Thu, 2 Jan 2003 15:49:13 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA26858; Thu, 2 Jan 2003 15:56:09 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15892.53657.358186.315527@thomasm-u1.cisco.com> Date: Thu, 2 Jan 2003 15:56:09 -0800 (PST) To: Adam Roach Cc: "'George Foti (LMC)'" , "'Michael Thomas'" , Eric Burger , Dean Willis , Jonathan Rosenberg , sip@ietf.org Subject: RE: [Sip] INFO considered harmful In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A643BD@DYN-TX-EXCH-001.dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F3A643BD@DYN-TX-EXCH-001.dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Right, but my personal bugaboo is modularity. Like Don's FTPoSIP example, the more junk you throw into one protocol, the more entangled it becomes to the point that you have a deep dark morass. In any case, we already have a real live kitchen sink protocol: HTTP; you even run IP over HTTP these days. I'd be surprised to hear that just about anything that runs SIP doesn't also have web kruft in it as well. Mike Adam Roach writes: > A new method would be okay for new SIP-related functionality. > > But that's not what you proposed. > > You said, "The application is SIP based, we dont need yet > another protocol to convey what needs to be conveyed e2e," > which is an argument that we should use SIP as a general > purpose RPC mechanism for any application that already has > a SIP stack. > > Doing what you propose with INFO is inappropriate. > > Doing what you propose with a new method is inappropriate. > > Doing what you propose with SIP is inappropriate. > > Since you keep harping on technical, as opposed to > philosophical, arguments, here's a couple: > > - The SIP protocol was designed for session initiation, > negotiation, and teardown. The timing characteristics > are not generally appropriate for application control. > For example, with typical SIP networks, latency and > jitter of messages are too high to provide any sort > of reasonable user experience for floor control > or DTMF transport. > > - Many proxies stay in the signalling path for the purposes > of providing services. By sending unnecessary application- > level information throught these proxies, you reduce the > capacity and increase possible congestion of the network. > > I could go on, but this topic has had extensive airing on > the list in years past. There's really no reason to beat > this particular dead horse any longer. > > /a > > > -----Original Message----- > > From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] > > Sent: Thursday, January 02, 2003 16:05 > > To: 'Adam Roach'; George Foti (LMC); 'Michael Thomas'; Eric Burger > > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > > Subject: RE: [Sip] INFO considered harmful > > > > > > This should not be a philosophical discusion. > > If a new SIP method is okay, why is INFO not okay. > > > > What is the difference? > > Please explain in technical terms? > > > > /gf > > > > -----Original Message----- > > From: Adam Roach [mailto:adam@dynamicsoft.com] > > Sent: Thursday, January 02, 2003 2:36 PM > > To: 'George Foti (LMC)'; 'Michael Thomas'; Eric Burger > > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > > Subject: RE: [Sip] INFO considered harmful > > > > > > The argument of "but I'm already holding a hammer and *want* > > to treat everything like a nail!" comes up on about an annual > > basis, and is rejected outright each time. > > > > Just because you have a SIP stack in your application does > > *not* mean that it is appropriate to use that stack for > > all general network access. You're allowing laziness to > > overwhelm good application design. > > > > /a > > > > > -----Original Message----- > > > From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] > > > Sent: Thursday, January 02, 2003 12:55 > > > To: 'Michael Thomas'; Eric Burger > > > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > > > Subject: RE: [Sip] INFO considered harmful > > > > > > > > > The application is SIP based, we dont need yet another > > > protocol to convey what needs to be conveyed e2e. > > > No need to go around the bush. > > > Lets find *real* arguments against using INFO for that > > > purpopse rather than philosphical ones. > > > > > > /gf > > > > > > > > > > > > > > > -----Original Message----- > > > From: Michael Thomas [mailto:mat@cisco.com] > > > Sent: Thursday, January 02, 2003 12:53 PM > > > To: Eric Burger > > > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > > > Subject: RE: [Sip] INFO considered harmful > > > > > > > > > > > > I don't get it. If you want "100% application > > > specific", why not pick an unused port and roll > > > your own protocol? Then all of the crufty SIPism > > > don't get in the way, and the hue and cry from > > > this working group ceases immediately. Do the bits > > > on the wire keep warmer if they're dressed in SIP? > > > > > > Mike > > > > > > Eric Burger writes: > > > > I fully agree with Dean on this one. > > > > > > > > One point to consider (I'm on the fence on this one) is > > > whether we would say that INFO is 100% application-specific. > > > That is, the WG will not publish standard body types. > > > > > > > > A reason for doing that is to let people know that INFO > > > really is just, as Dean points out, > > > application-to-application communication. If you want > > > applications to interoperate, take it either to an > > > Application Area WG or take it outside the IETF. > > > > > > > > One reason to not do this is SIP-T should use a method > > > other than INFO. That said, I don't think there are that > > > many SIP-T implementations extant. > > > > > > > > > > > > > -----Original Message----- > > > > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > > > Sent: Tuesday, December 31, 2002 1:48 AM > > > > > To: Jonathan Rosenberg; Orit Levin > > > > > Cc: sip@ietf.org > > > > > Subject: Re: [Sip] INFO considered harmful > > > > > > > > > > > > > > > At 12:48 AM 12/31/2002 -0500, Jonathan Rosenberg wrote: > > > > > >Orit Levin wrote: > > > > > >>>The big huge difference I have been trying to point out is > > > > > that EVENTS > > > > > >>>DEFINES SEMANTICS, whereas INFO doesnt. > > > > > >>>MIME provides semantics and syntax that are independent of > > > > > the type. > > > > > >>>SIP events provides semantics and syntax that are > > > > > independent of the > > > > > >>>package. > > > > > >>>INFO provides nothing. > > > > > >> > > > > > >>INFO provides "minimal" but very important semantics: > > > > > asynchronous data > > > > > >>reliably follows the established SIP path. > > > > > > > > > > > >Huh? > > > > > > > > > > > >Every new SIP method is reliable, it inherits the SIP > > > > > transaction state > > > > > >machine for non-invite. Follows the established path? Every > > > > > in-dialog > > > > > >method would have this property, it is method independent. > > > > > >Asynchronous? You can send any method at any time. > > > > > > > > > > > >Thus, nothing you have pointed out above is different > > > > > between INFO and any > > > > > >other new method we might introduce. > > > > > > > > > > I think the key point is that there is a difference > > > between transport > > > > > protocol semantic and application semantic. The transport > > > > > protocol semantic > > > > > expressed in INFO is "Here is some data that will be > > used by the > > > > > application. It is not important to the transport protocol, > > > > > except that the > > > > > transport protocol is expected to deliver it reliably". INFO > > > > > says NOTHING > > > > > about the APPLICATION level semantic -- that's up to what > > > > > goes IN the INFO > > > > > payloads. The question is -- do we try to rigidly define > > > > > application-level > > > > > semantics here? Do we define that there ARE no such > > > > > applications possible? > > > > > Or do we design a framework by which application-level > > > > > semantics can be > > > > > expressed outside of the protocol definition? > > > > > > > > > > And as for "Just add another method to your SIP stack". Let's > > > > > say I have a > > > > > mobile phone and the SIP stack is burned into ROM and > > > exposes only a > > > > > simplistic transactional API. This is only likely to > > > happen, oh, 100 > > > > > million times or so over the next two years . . . Now, just > > > > > exactly how is > > > > > my BREW or JTME application going to go about extending the > > > > > SIP stack to > > > > > support another method? Will the evil wireless operator > > > > > networks even pass > > > > > another method? Neither is happening anytime soon, I > > think . . . > > > > > > > > > > -- > > > > > 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 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Jan 2 19:02:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17416 for ; Thu, 2 Jan 2003 19:02:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h030Aph01901 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 19:10:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0307NJ01453; Thu, 2 Jan 2003 19:07:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0306PJ01047 for ; Thu, 2 Jan 2003 19:06:25 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17279 for ; Thu, 2 Jan 2003 18:57:24 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h02NxCSK010127; Thu, 2 Jan 2003 18:59:12 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Jan 2003 18:00:34 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A643C0@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Frank W. Miller'" , Jonathan Rosenberg Cc: sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Thu, 2 Jan 2003 18:00:27 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > From: Frank W. Miller [mailto:fmiller@sentito.com] > > [T]he reality is, application implementors need some kind of > app-to-app tunneling for stuff that isn't explictily handled. I'm trying to understand this argument more clearly. It sounds to me like you need some sort of session of application- specific information that you can use to communicate between two nodes. Perhaps using some sort of protocol to initate this session would be appropriate. You'll also needs a protocol of some sort to describe it, probably carried as a payload in this session initation protocol. Ideally, this session description protocol could leverage IANA-registered media types to describe the content of such sessions, so that an infinite number of types of sessions can be described. Hmmm... /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 2 19:13:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17535 for ; Thu, 2 Jan 2003 19:13:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h030LY202317 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 19:21:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h030HVJ02113; Thu, 2 Jan 2003 19:17:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h030GbJ02056 for ; Thu, 2 Jan 2003 19:16:37 -0500 Received: from imr2.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17462 for ; Thu, 2 Jan 2003 19:07:35 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id h030AMW10044; Thu, 2 Jan 2003 18:10:22 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h030AMm15394; Thu, 2 Jan 2003 18:10:22 -0600 (CST) Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id h030AMh18151; Thu, 2 Jan 2003 19:10:22 -0500 (EST) Received: by eammlex034.lmc.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 2 Jan 2003 19:10:21 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C037BFE@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'Adam Roach'" , "George Foti (LMC)" , "'Michael Thomas'" , Eric Burger Cc: Dean Willis , Jonathan Rosenberg , sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Thu, 2 Jan 2003 19:10:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , >I could go on, but this topic has had extensive airing on >the list in years past. There's really no reason to beat >this particular dead horse any longer. Agreed, but the extremety, the exaggarations and the imaginary, creative non-real abuses and comparisons with other protocols, that have been raised on e-mails about misuse of INFO represents a *sad* distortion of how most common sense people have used it, and contradicts the reality on the ground. Only constructive counter proposals may move this forward. Rgds/gf -----Original Message----- From: Adam Roach [mailto:adam@dynamicsoft.com] Sent: Thursday, January 02, 2003 5:57 PM To: 'George Foti (LMC)'; Adam Roach; 'Michael Thomas'; Eric Burger Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org Subject: RE: [Sip] INFO considered harmful A new method would be okay for new SIP-related functionality. But that's not what you proposed. You said, "The application is SIP based, we dont need yet another protocol to convey what needs to be conveyed e2e," which is an argument that we should use SIP as a general purpose RPC mechanism for any application that already has a SIP stack. Doing what you propose with INFO is inappropriate. Doing what you propose with a new method is inappropriate. Doing what you propose with SIP is inappropriate. Since you keep harping on technical, as opposed to philosophical, arguments, here's a couple: - The SIP protocol was designed for session initiation, negotiation, and teardown. The timing characteristics are not generally appropriate for application control. For example, with typical SIP networks, latency and jitter of messages are too high to provide any sort of reasonable user experience for floor control or DTMF transport. - Many proxies stay in the signalling path for the purposes of providing services. By sending unnecessary application- level information throught these proxies, you reduce the capacity and increase possible congestion of the network. I could go on, but this topic has had extensive airing on the list in years past. There's really no reason to beat this particular dead horse any longer. /a > -----Original Message----- > From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] > Sent: Thursday, January 02, 2003 16:05 > To: 'Adam Roach'; George Foti (LMC); 'Michael Thomas'; Eric Burger > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > Subject: RE: [Sip] INFO considered harmful > > > This should not be a philosophical discusion. > If a new SIP method is okay, why is INFO not okay. > > What is the difference? > Please explain in technical terms? > > /gf > > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Thursday, January 02, 2003 2:36 PM > To: 'George Foti (LMC)'; 'Michael Thomas'; Eric Burger > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > Subject: RE: [Sip] INFO considered harmful > > > The argument of "but I'm already holding a hammer and *want* > to treat everything like a nail!" comes up on about an annual > basis, and is rejected outright each time. > > Just because you have a SIP stack in your application does > *not* mean that it is appropriate to use that stack for > all general network access. You're allowing laziness to > overwhelm good application design. > > /a > > > -----Original Message----- > > From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] > > Sent: Thursday, January 02, 2003 12:55 > > To: 'Michael Thomas'; Eric Burger > > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > > Subject: RE: [Sip] INFO considered harmful > > > > > > The application is SIP based, we dont need yet another > > protocol to convey what needs to be conveyed e2e. > > No need to go around the bush. > > Lets find *real* arguments against using INFO for that > > purpopse rather than philosphical ones. > > > > /gf > > > > > > > > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Thursday, January 02, 2003 12:53 PM > > To: Eric Burger > > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > > Subject: RE: [Sip] INFO considered harmful > > > > > > > > I don't get it. If you want "100% application > > specific", why not pick an unused port and roll > > your own protocol? Then all of the crufty SIPism > > don't get in the way, and the hue and cry from > > this working group ceases immediately. Do the bits > > on the wire keep warmer if they're dressed in SIP? > > > > Mike > > > > Eric Burger writes: > > > I fully agree with Dean on this one. > > > > > > One point to consider (I'm on the fence on this one) is > > whether we would say that INFO is 100% application-specific. > > That is, the WG will not publish standard body types. > > > > > > A reason for doing that is to let people know that INFO > > really is just, as Dean points out, > > application-to-application communication. If you want > > applications to interoperate, take it either to an > > Application Area WG or take it outside the IETF. > > > > > > One reason to not do this is SIP-T should use a method > > other than INFO. That said, I don't think there are that > > many SIP-T implementations extant. > > > > > > > > > > -----Original Message----- > > > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > > Sent: Tuesday, December 31, 2002 1:48 AM > > > > To: Jonathan Rosenberg; Orit Levin > > > > Cc: sip@ietf.org > > > > Subject: Re: [Sip] INFO considered harmful > > > > > > > > > > > > At 12:48 AM 12/31/2002 -0500, Jonathan Rosenberg wrote: > > > > >Orit Levin wrote: > > > > >>>The big huge difference I have been trying to point out is > > > > that EVENTS > > > > >>>DEFINES SEMANTICS, whereas INFO doesnt. > > > > >>>MIME provides semantics and syntax that are independent of > > > > the type. > > > > >>>SIP events provides semantics and syntax that are > > > > independent of the > > > > >>>package. > > > > >>>INFO provides nothing. > > > > >> > > > > >>INFO provides "minimal" but very important semantics: > > > > asynchronous data > > > > >>reliably follows the established SIP path. > > > > > > > > > >Huh? > > > > > > > > > >Every new SIP method is reliable, it inherits the SIP > > > > transaction state > > > > >machine for non-invite. Follows the established path? Every > > > > in-dialog > > > > >method would have this property, it is method independent. > > > > >Asynchronous? You can send any method at any time. > > > > > > > > > >Thus, nothing you have pointed out above is different > > > > between INFO and any > > > > >other new method we might introduce. > > > > > > > > I think the key point is that there is a difference > > between transport > > > > protocol semantic and application semantic. The transport > > > > protocol semantic > > > > expressed in INFO is "Here is some data that will be > used by the > > > > application. It is not important to the transport protocol, > > > > except that the > > > > transport protocol is expected to deliver it reliably". INFO > > > > says NOTHING > > > > about the APPLICATION level semantic -- that's up to what > > > > goes IN the INFO > > > > payloads. The question is -- do we try to rigidly define > > > > application-level > > > > semantics here? Do we define that there ARE no such > > > > applications possible? > > > > Or do we design a framework by which application-level > > > > semantics can be > > > > expressed outside of the protocol definition? > > > > > > > > And as for "Just add another method to your SIP stack". Let's > > > > say I have a > > > > mobile phone and the SIP stack is burned into ROM and > > exposes only a > > > > simplistic transactional API. This is only likely to > > happen, oh, 100 > > > > million times or so over the next two years . . . Now, just > > > > exactly how is > > > > my BREW or JTME application going to go about extending the > > > > SIP stack to > > > > support another method? Will the evil wireless operator > > > > networks even pass > > > > another method? Neither is happening anytime soon, I > think . . . > > > > > > > > -- > > > > 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 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Jan 2 19:16:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17570 for ; Thu, 2 Jan 2003 19:16:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h030OdT02369 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 19:24:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h030LDJ02294; Thu, 2 Jan 2003 19:21:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h030KwJ02276 for ; Thu, 2 Jan 2003 19:20:58 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17516 for ; Thu, 2 Jan 2003 19:11:57 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h030DfSK010165; Thu, 2 Jan 2003 19:13:42 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Jan 2003 18:15:04 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A643C1@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'George Foti (LMC)'" , Adam Roach , "George Foti (LMC)" , "'Michael Thomas'" , Eric Burger Cc: Dean Willis , Jonathan Rosenberg , sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Thu, 2 Jan 2003 18:15:00 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > -----Original Message----- > From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] > > >I could go on, but this topic has had extensive airing on > >the list in years past. There's really no reason to beat > >this particular dead horse any longer. > > Agreed, but the extremety, the exaggarations and the > imaginary, creative non-real abuses and comparisons with > other protocols, that have been raised on e-mails about > misuse of INFO represents a *sad* distortion of how most > common sense people have used it, and contradicts the reality > on the ground. Imaginary? Non-real? Ummm... "DTMF Transport" and "Floor Control" are the two examples I offered as being inappropriate (along with a good, technical explanation of why). Both of these have been seriously suggested as standard extensions to SIP. I've even seen attempts to deploy them. In a real carrier environment. End result: scrapping that part of the system and going back to the drawing board. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 2 19:22:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17736 for ; Thu, 2 Jan 2003 19:22:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h030UnC02613 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 19:30:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h030REJ02469; Thu, 2 Jan 2003 19:27:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h030QTJ02440 for ; Thu, 2 Jan 2003 19:26:29 -0500 Received: from gbnewp0915s1.eu.ubiquity.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17591 for ; Thu, 2 Jan 2003 19:17:25 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for [132.151.6.1]) with SMTP; 3 Jan 2003 00:19:44 UT Received: from gbnewp1014m ([172.25.1.88]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.4905); Fri, 3 Jan 2003 00:20:36 +0000 From: "Neil Deason" To: "Don Stanwyck" , "'George Foti \(LMC\)'" , "'George Foti \(LMC\)'" , "'Michael Thomas'" , "'Eric Burger'" Cc: "'Dean Willis'" , "'Jonathan Rosenberg'" , Subject: RE: [Sip] INFO considered harmful Date: Thu, 2 Jan 2003 16:20:33 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <006e01c2b2b3$5efc2c30$0300000a@DONGWLAPTOP> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 03 Jan 2003 00:20:37.0121 (UTC) FILETIME=[F0606F10:01C2B2BD] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello. An observation + suggested way forward inline ... > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Don > Stanwyck > > To follow up my own posting (bad form, I know), I thought I should > mention a real life example that worries me. > > Many new cell phones have picture taking and picture sending > capabilities. Some even allow for "movie" modes that send a > picture per > second of so. > > If the call is set up using SIP and the phone then wants to send all > these photos also over SIP, then the SIP proxies in the network can > become overloaded with what should be a low priority traffic > instead of > being used for their design purpose - to process communication session > establishment information. No need to worry about INFO abuse here. Obviously this would be done using MESSAGE ;) Actually if we want to police protocol usage closely we had better look at deprecating MESSAGE too. This method allows SIP to be used as a data transport protocol, either inside or outside the context of dialog. It seems naive to think saying usage is expected to be "small in number, short content, SMS like" etc. is going to make much difference. While MESSAGE may have slightly more defined method semantics than INFO, I am not convinced they are really that much more defined. To me it looks like MESSAGE sematics are more being inferred by the paging-like application typically associated with it. Anyway my $0.02 on INFO itself. Personally I am not a huge fan and obviously many people _really_ don't like it, but one man's meat is another man's poison. So returning to the original proposal - option 2/"INFO-packages" looks like a way to progress. Providing of course there is sufficient commitment to keeping INFO around to spur authorship. Cheers, Neil. > > -----Original Message----- > > From: Don Stanwyck [mailto:don@stanwyck.com] > > Sent: Thursday, January 02, 2003 4:02 PM > > To: 'George Foti (LMC)'; 'George Foti (LMC)'; 'Michael > > Thomas'; 'Eric Burger' > > Cc: 'Dean Willis'; 'Jonathan Rosenberg'; 'sip@ietf.org' > > Subject: RE: [Sip] INFO considered harmful > > > > > > It increases the number of transactions they have to process. > > Nothing in life is free. SIP Proxies, like other call > > routing devices, assume a certain number of transactions per > > call as part of their design numbers. This is important for > > traffic engineering. > > > > If we allow SIP to become the new FTP protocol (and there is > > nothing right now that would stop a UA from using SIP-INFO > > for FTP or FTP like functions), then the calls/second counts > > and all other traffic engineering rules that are needed for > > proper network operation become meaningless. > > > > Don > > > > > -----Original Message----- > > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > > > Behalf Of George Foti (LMC) > > > Sent: Thursday, January 02, 2003 3:03 PM > > > To: 'Don Stanwyck'; George Foti (LMC); 'Michael Thomas'; > > 'Eric Burger' > > > Cc: 'Dean Willis'; 'Jonathan Rosenberg'; sip@ietf.org > > > Subject: RE: [Sip] INFO considered harmful > > > > > > > > > >There is no reason to bother all the > > > >routing proxies in the network with your e2e private chatter. > > > > > > How are they bothered ? > > > What extra logic do they need? > > > > > > /gf > > > > > > > > > -----Original Message----- > > > From: Don Stanwyck [mailto:don@stanwyck.com] > > > Sent: Thursday, January 02, 2003 3:13 PM > > > To: 'George Foti (LMC)'; 'Michael Thomas'; 'Eric Burger' > > > Cc: 'Dean Willis'; 'Jonathan Rosenberg'; sip@ietf.org > > > Subject: RE: [Sip] INFO considered harmful > > > > > > > > > I guess I have two problems with the statement below. > > > > > > 1) Applications should not be protocol based - they may be > > > protocol aware. Unless the SIP stack is rolled into the > > > application, it merely uses SIP as a lower layer tool to > > > establish communications. It is a violation of good design > > > to roll the protocol into the application itself. > > > BTW, if the SIP stack is rolled into the application, then > > > when the next edition of SIP comes along you will have to > > > rewrite the app. You really should have an API that keeps > > > the app from needing to know the details of the communication > > > establishment protocol. > > > > > > 2) If the apps need to talk directly to each other there are > > > a host of protocols that are extremely trivial that can do > > > the job. The apps can even just open a port over any > > > transport protocol and exchange information as they please. > > > There is no reason to bother all the routing proxies in the > > > network with your e2e private chatter. > > > > > > Just a thought. > > > don > > > > > > > -----Original Message----- > > > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of > > > > George Foti (LMC) > > > > Sent: Thursday, January 02, 2003 11:55 AM > > > > To: 'Michael Thomas'; Eric Burger > > > > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > > > > Subject: RE: [Sip] INFO considered harmful > > > > > > > > > > > > The application is SIP based, we dont need yet another > > protocol to > > > > convey what needs to be conveyed e2e. No need to go > > around the bush. > > > > Lets find *real* arguments against using INFO for that purpopse > > > > rather than philosphical ones. > > > > > > > > /gf > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Michael Thomas [mailto:mat@cisco.com] > > > > Sent: Thursday, January 02, 2003 12:53 PM > > > > To: Eric Burger > > > > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > > > > Subject: RE: [Sip] INFO considered harmful > > > > > > > > > > > > > > > > I don't get it. If you want "100% application > > > > specific", why not pick an unused port and roll > > > > your own protocol? Then all of the crufty SIPism > > > > don't get in the way, and the hue and cry from > > > > this working group ceases immediately. Do the bits > > > > on the wire keep warmer if they're dressed in SIP? > > > > > > > > Mike > > > > > > > > Eric Burger writes: > > > > > I fully agree with Dean on this one. > > > > > > > > > > One point to consider (I'm on the fence on this one) is > > > > whether we would say that INFO is 100% application-specific. > > > > That is, the WG will not publish standard body types. > > > > > > A reason for doing that is to let people know that INFO > > > > really is just, as Dean points out, > > > > application-to-application communication. If you want > > > > applications to interoperate, take it either to an > > > > Application Area WG or take it outside the IETF. > > > > > > One reason to not do this is SIP-T should use a method > > > > other than INFO. That said, I don't think there are that > > > > many SIP-T implementations extant. > > > > > > > > > > > > -----Original Message----- > > > > > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > > > > Sent: Tuesday, December 31, 2002 1:48 AM > > > > > > To: Jonathan Rosenberg; Orit Levin > > > > > > Cc: sip@ietf.org > > > > > > Subject: Re: [Sip] INFO considered harmful > > > > > > > > > > > > > > > > > > At 12:48 AM 12/31/2002 -0500, Jonathan Rosenberg wrote: > > > > > > >Orit Levin wrote: > > > > > > >>>The big huge difference I have been trying to > > point out is > > > > > > that EVENTS > > > > > > >>>DEFINES SEMANTICS, whereas INFO doesnt. > > > > > > >>>MIME provides semantics and syntax that are > > independent of > > > > > > the type. > > > > > > >>>SIP events provides semantics and syntax that are > > > > > > independent of the > > > > > > >>>package. > > > > > > >>>INFO provides nothing. > > > > > > >> > > > > > > >>INFO provides "minimal" but very important semantics: > > > > > > asynchronous data > > > > > > >>reliably follows the established SIP path. > > > > > > > > > > > > > >Huh? > > > > > > > > > > > > > >Every new SIP method is reliable, it inherits the SIP > > > > > > transaction state > > > > > > >machine for non-invite. Follows the established > path? Every > > > > > > in-dialog > > > > > > >method would have this property, it is method > independent. > > > > > > >Asynchronous? You can send any method at any time. > > > > > > > > > > > > > >Thus, nothing you have pointed out above is different > > > > > > between INFO and any > > > > > > >other new method we might introduce. > > > > > > > > > > > > I think the key point is that there is a difference > > > > between transport > > > > > > protocol semantic and application semantic. The transport > > > > > > protocol semantic > > > > > > expressed in INFO is "Here is some data that will be > > > used by the > > > > > > application. It is not important to the transport protocol, > > > > > > except that the > > > > > > transport protocol is expected to deliver it > reliably". INFO > > > > > > says NOTHING > > > > > > about the APPLICATION level semantic -- that's up to what > > > > > > goes IN the INFO > > > > > > payloads. The question is -- do we try to rigidly define > > > > > > application-level > > > > > > semantics here? Do we define that there ARE no such > > > > > > applications possible? > > > > > > Or do we design a framework by which application-level > > > > > > semantics can be > > > > > > expressed outside of the protocol definition? > > > > > > > > > > > > And as for "Just add another method to your SIP > > stack". Let's > > > > > > say I have a > > > > > > mobile phone and the SIP stack is burned into ROM and > > > > exposes only a > > > > > > simplistic transactional API. This is only likely to > > > > happen, oh, 100 > > > > > > million times or so over the next two years . . . > Now, just > > > > > > exactly how is > > > > > > my BREW or JTME application going to go about > extending the > > > > > > SIP stack to > > > > > > support another method? Will the evil wireless operator > > > > > > networks even pass > > > > > > another method? Neither is happening anytime soon, I > > > > think . . . > > > > > > > > -- > > > > > > 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 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Jan 2 19:39:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18171 for ; Thu, 2 Jan 2003 19:39:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h030m9m04052 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 19:48:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h030ieJ03906; Thu, 2 Jan 2003 19:44:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h030hPJ03812 for ; Thu, 2 Jan 2003 19:43:25 -0500 Received: from face.sentitonetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18089 for ; Thu, 2 Jan 2003 19:34:23 -0500 (EST) Received: (qmail 69281 invoked from network); 3 Jan 2003 00:37:35 -0000 Received: from unknown (HELO overhill) (10.0.0.159) by face.sentito.com with SMTP; 3 Jan 2003 00:37:35 -0000 Message-ID: <013401c2b2c0$4f7fb670$9f00000a@overhill> From: "Frank W. Miller" To: "Adam Roach" Cc: References: <9BF66EBF6BEFD942915B4D4D45C051F3A643C0@DYN-TX-EXCH-001.dynamicsoft.com> Subject: Re: [Sip] INFO considered harmful Date: Thu, 2 Jan 2003 19:37:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Heh. What I'm referring to is the need for implementors to build upon the basic signaling mechanism that SIP provides. If an application has signaling needs that are not met with the basic protocol constructs, application implementors need a way to make it happen. As others have argued, there are instances where augmenting the (perhaps third party) SIP stack source code with new methods does not make sense. This can be expensive and time-consuming compared to say, punting an INFO body written in XML to an open source parser. The ability to get something like this done quickly and/or without perturbing the SIP stack code is very important, despite your sarcasm. FM Frank W. Miller, Ph.D. Chief Technical Officer sentitO Networks, Inc. fmiller@sentito.com ----- Original Message ----- From: "Adam Roach" To: "'Frank W. Miller'" ; "Jonathan Rosenberg" Cc: Sent: Thursday, January 02, 2003 7:00 PM Subject: RE: [Sip] INFO considered harmful > > From: Frank W. Miller [mailto:fmiller@sentito.com] > > > > [T]he reality is, application implementors need some kind of > > app-to-app tunneling for stuff that isn't explictily handled. > > I'm trying to understand this argument more clearly. > > It sounds to me like you need some sort of session of application- > specific information that you can use to communicate between two > nodes. > > Perhaps using some sort of protocol to initate this session > would be appropriate. You'll also needs a protocol of some sort > to describe it, probably carried as a payload in this session > initation protocol. Ideally, this session description protocol > could leverage IANA-registered media types to describe the content > of such sessions, so that an infinite number of types of sessions > can be described. > > Hmmm... > > /a > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 2 20:10:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18778 for ; Thu, 2 Jan 2003 20:10:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h031IaR06032 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 20:18:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h031EZJ05883; Thu, 2 Jan 2003 20:14:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h031DvJ05825 for ; Thu, 2 Jan 2003 20:13:57 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18700 for ; Thu, 2 Jan 2003 20:04:54 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h0316jSK010270; Thu, 2 Jan 2003 20:06:45 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Jan 2003 19:08:05 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A643C2@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Frank W. Miller'" , Adam Roach Cc: sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Thu, 2 Jan 2003 19:07:54 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > From: Frank W. Miller [mailto:fmiller@sentito.com] > > What I'm referring to is the need for implementors to build > upon the basic signaling mechanism that SIP provides. If an > application has signaling needs that are not met with the basic > protocol constructs, application implementors need a way to make > it happen. As others have argued, there are instances where > augmenting the (perhaps third party) SIP stack source code with > new methods does not make sense. Sorry for being a bit obtuse (and sarcastic). I was trying to grab your attention, since the earlier statement (made by Jonathan) that one should use SIP to initiate such sessions apparently failed to do so. I wasn't proposing adding new methods. I was proposing using INVITE to establish a session, and exchanging your application-level information using such a session. > This can be expensive and > time-consuming compared to say, punting an INFO body written in > XML to an open source parser. The ability to get something > like this done quickly and/or without perturbing the SIP stack > code is very important, despite your sarcasm. Shoving XML over TCP (perhaps using SOAP, if that suits your fancy) is trivial to code, and the comedia extensions make it possible. It is all eminently expresible using SDP as it exists today, and, for any decent programmer with the most basic understanding of sockets programming (or even a good abstraction library), is every bit as easy as what you propose. Except, of course, that it lacks the "SIP as general-purpose RPC" abuse factor. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 2 20:12:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18830 for ; Thu, 2 Jan 2003 20:12:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h031KbA06136 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 20:20:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h031H8J05985; Thu, 2 Jan 2003 20:17:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h031GbJ05962 for ; Thu, 2 Jan 2003 20:16:37 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18749 for ; Thu, 2 Jan 2003 20:07:34 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h0319PSK010273; Thu, 2 Jan 2003 20:09:25 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Jan 2003 19:10:45 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A643C3@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Neil Deason'" Cc: sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Thu, 2 Jan 2003 19:10:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > From: Neil Deason [mailto:ndeason@ubiquity.net] > > Actually if we want to police protocol usage closely we had > better look at deprecating MESSAGE too. Come back when SIMPLE has finished defining the message sessions, and I'll throw my voice behind yours in advocating this. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 2 20:28:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19031 for ; Thu, 2 Jan 2003 20:28:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h031bNp07325 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 20:37:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h031XNJ06669; Thu, 2 Jan 2003 20:33:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h031WrJ06611 for ; Thu, 2 Jan 2003 20:32:53 -0500 Received: from mtiwmhc12.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18962 for ; Thu, 2 Jan 2003 20:23:50 -0500 (EST) Received: from cs.columbia.edu ([12.84.238.57]) by mtiwmhc12.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030103012701.RFKC12483.mtiwmhc12.worldnet.att.net@cs.columbia.edu>; Fri, 3 Jan 2003 01:27:01 +0000 Message-ID: <3E14E655.9030805@cs.columbia.edu> Date: Thu, 02 Jan 2003 20:24:37 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'Neil Deason'" , sip@ietf.org Subject: Re: [Sip] INFO considered harmful References: <9BF66EBF6BEFD942915B4D4D45C051F3A643C3@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Actually, there's an important difference: MESSAGE can use the SIP features outside an established session, while INFO is within a session (and thus there are other SDP-negotiated, options available). Within a session, the only real reason for a follow-the-INVITE SIP message is that a direct IP-level connection can't be made to work. From an efficiency standpoint, if you only have very occasional messages, you gain by a "connectionless" approach. After all, an INVITE transaction for a single MESSAGE doesn't buy you much and doesn't conserve the oh-so-precious proxy cycles. While such short sessions are probably not common for human-to-human communication (except spam...), they may well be common for the type of things that SMS and pagers are popular for: machine-to-human or machine-to-machine communications announcing infrequent and unpredictable events ("your flight is now leaving on gate 37", "your FedEx just arrived", "Server 42 is on fire"). Adam Roach wrote: >>From: Neil Deason [mailto:ndeason@ubiquity.net] >> >>Actually if we want to police protocol usage closely we had >>better look at deprecating MESSAGE too. > > > Come back when SIMPLE has finished defining the message sessions, > and I'll throw my voice behind yours in advocating this. > > /a > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 2 22:01:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20929 for ; Thu, 2 Jan 2003 22:01:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0339ht12439 for sip-archive@odin.ietf.org; Thu, 2 Jan 2003 22:09:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03364J11693; Thu, 2 Jan 2003 22:06:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0332KJ11603 for ; Thu, 2 Jan 2003 22:02:20 -0500 Received: from gbnewp0915s1.eu.ubiquity.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20752 for ; Thu, 2 Jan 2003 21:53:14 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for [132.151.6.1]) with SMTP; 3 Jan 2003 02:55:34 UT Received: from gbnewp1014m ([192.168.1.100]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.4905); Fri, 3 Jan 2003 02:56:28 +0000 From: "Neil Deason" To: "Adam Roach" Cc: Subject: RE: [Sip] INFO considered harmful Date: Thu, 2 Jan 2003 18:56:23 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A643C3@DYN-TX-EXCH-001.dynamicsoft.com> X-OriginalArrivalTime: 03 Jan 2003 02:56:29.0204 (UTC) FILETIME=[B6A70D40:01C2B2D3] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > > > From: Neil Deason [mailto:ndeason@ubiquity.net] > > > > Actually if we want to police protocol usage closely we had > > better look at deprecating MESSAGE too. > > Come back when SIMPLE has finished defining the message sessions, > and I'll throw my voice behind yours in advocating this. What I was actually advocating here was ppl wanting to keep INFO around write up something to illuminate INFO packages and provide example usage. The MESSAGE cf INFO was just an attempt to highlight an apparent limitation with the ban INFO approach. Every MIME type in an INFO can be moved into MESSAGE rather than go away. Maybe through exploring INFO packages we evolve the collective understanding that this is/isn't a necessary thing. Cheers, Neil. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 3 01:20:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23700 for ; Fri, 3 Jan 2003 01:20:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h036TRW22466 for sip-archive@odin.ietf.org; Fri, 3 Jan 2003 01:29:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h036PgJ22340; Fri, 3 Jan 2003 01:25:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h036NdJ22269 for ; Fri, 3 Jan 2003 01:23:39 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23668 for ; Fri, 3 Jan 2003 01:14:30 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.143]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h036HhYH024720; Fri, 3 Jan 2003 01:17:44 -0500 (EST) Message-ID: <3E152B05.2080800@dynamicsoft.com> Date: Fri, 03 Jan 2003 01:17:41 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Neil Deason CC: Adam Roach , sip@ietf.org Subject: Re: [Sip] INFO considered harmful References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Neil Deason wrote: >>-----Original Message----- >>From: Adam Roach [mailto:adam@dynamicsoft.com] >> >> >>>From: Neil Deason [mailto:ndeason@ubiquity.net] >>> >>>Actually if we want to police protocol usage closely we had >>>better look at deprecating MESSAGE too. >> >>Come back when SIMPLE has finished defining the message sessions, >>and I'll throw my voice behind yours in advocating this. > > > What I was actually advocating here was ppl wanting to keep INFO around > write up something to illuminate INFO packages and provide example > usage. Well, let me suggest an amendment to that. It seems that people have a bunch of problems they want to solve, for which they are finding INFO a good solution. They have some requirements like, "support application to application messaging", and other folks, like myself, have requirements for things like congestion control and the ability to indicate what kind of usages are supported. It seems like RFC 3427 is screaming at us here. Someone needs to write down what problems they are trying to solve, and then sipping can debate them. If we choose to address them, the sip working group might conclude that it should revise INFO to meet those requirements, or it might decide to obsolete it in favor of a totally separate solution (like my proposed SDP-based approach). Given the volume on this thread during the holiday season even, there should be no shortage of volunteers to write such a requirements doc. For once though, I am NOT volunteering ;) -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 3 01:20:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23713 for ; Fri, 3 Jan 2003 01:20:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h036TZg22479 for sip-archive@odin.ietf.org; Fri, 3 Jan 2003 01:29:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h036QAJ22365; Fri, 3 Jan 2003 01:26:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h036PMJ22323 for ; Fri, 3 Jan 2003 01:25:22 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23677 for ; Fri, 3 Jan 2003 01:16:13 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.143]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h036JLYH024723; Fri, 3 Jan 2003 01:19:22 -0500 (EST) Message-ID: <3E152B67.9000409@dynamicsoft.com> Date: Fri, 03 Jan 2003 01:19:19 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Adam Roach , "'Neil Deason'" , sip@ietf.org Subject: Re: [Sip] INFO considered harmful References: <9BF66EBF6BEFD942915B4D4D45C051F3A643C3@DYN-TX-EXCH-001.dynamicsoft.com> <3E14E655.9030805@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Henning is dead on. I think we will always need MESSAGE for this reason exactly. It may be, that as messaging sessions are completed, and we understand the problem space better, we would revise MESSAGE to impose further restrictions on it. For now, I think its pretty good as written. -Jonathan R. Henning Schulzrinne wrote: > Actually, there's an important difference: MESSAGE can use the SIP > features outside an established session, while INFO is within a session > (and thus there are other SDP-negotiated, options available). Within a > session, the only real reason for a follow-the-INVITE SIP message is > that a direct IP-level connection can't be made to work. > > From an efficiency standpoint, if you only have very occasional > messages, you gain by a "connectionless" approach. After all, an INVITE > transaction for a single MESSAGE doesn't buy you much and doesn't > conserve the oh-so-precious proxy cycles. While such short sessions are > probably not common for human-to-human communication (except spam...), > they may well be common for the type of things that SMS and pagers are > popular for: machine-to-human or machine-to-machine communications > announcing infrequent and unpredictable events ("your flight is now > leaving on gate 37", "your FedEx just arrived", "Server 42 is on fire"). > > Adam Roach wrote: > >>> From: Neil Deason [mailto:ndeason@ubiquity.net] >>> >>> Actually if we want to police protocol usage closely we had better >>> look at deprecating MESSAGE too. >> >> >> >> Come back when SIMPLE has finished defining the message sessions, >> and I'll throw my voice behind yours in advocating this. >> >> /a >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 3 01:36:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23879 for ; Fri, 3 Jan 2003 01:36:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h036j3r23731 for sip-archive@odin.ietf.org; Fri, 3 Jan 2003 01:45:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h036fOJ23626; Fri, 3 Jan 2003 01:41:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h036ebJ23594 for ; Fri, 3 Jan 2003 01:40:37 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23856 for ; Fri, 3 Jan 2003 01:31:28 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.143]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h036YgYH024736; Fri, 3 Jan 2003 01:34:42 -0500 (EST) Message-ID: <3E152EFF.8080105@dynamicsoft.com> Date: Fri, 03 Jan 2003 01:34:39 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: peter.paeppinghaus@siemens.com, sip@ietf.org Subject: Re: Repost: [Sip] Buggy example in RFC 3261 References: <2038BCC78B1AD641891A0D1AE133DBB7FE70A3@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Well, a decision needs to be made one way or another. Since its already in 3261, I would propose that we declare the example as buggy, and go with the existing normative text, even though it works differently than for requests. -Jonathan R. hisham.khartabil@nokia.com wrote: > This is an extract from a discussion I had with Robert Sparks: > > >>>Yes, that was exactly what I asked. If its not so, what does an Expires >>>header in a 200 OK for a REGISTER mean? >> >> >>As I note above, with the current text an Expire header field has no meaning >>if it appears in a 200 response to a REGISTER request. > > > http://www.ietf.org/mail-archive/working-groups/sip/current/msg03602.html > > Regards, > Hisham > > >>-----Original Message----- >>From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>Sent: Thursday, January 02, 2003 7:01 AM >>To: Peter Päppinghaus >>Cc: sip@ietf.org >>Subject: Re: Repost: [Sip] Buggy example in RFC 3261 >> >> >>Sorry for not responding. I did notice this. There is an >>error here, as >>you point out. What is NOT clear is whether the error is in >>the example, >>or in the normative text. For REGISTER requests, you can use >>either the >>Expires header field or the expires contact header field >>parameter. It >>seems odd that this same rule would not apply to REGISTER >>responses. My >>personal recollection was that either the Expires header field or the >>expires contact param was OK for either request or response. This >>doesn't match the normative text though. >> >>Does anyone use the Expires header field and NOT the expires contact >>param in REGISTER responses? >> >>-Jonathan R. >> >>Peter Päppinghaus wrote: >> >>>I have posted this earlier, but it seems to have gone >>>unnoticed. >>> >>>Hi, >>> >>>I believe to have stumbled on a buggy example in RFC 3261. >>> >>>The 200 OK in the REGISTER example of RFC 3261, sec. 24.1 contains >>>an Expires header, but no expires parameter in the Contact header. >>> >>>This violates RFC 3261, sec. 10.3, bullet 8: >>>"Each Contact value MUST feature an "expires" parameter >>> indicating its expiration interval chosen by the registrar." >>> >>>Regards, >>> >>>Peter Paeppinghaus >>> >> >>-- >>Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >>Chief Scientist First Floor >>dynamicsoft East Hanover, NJ 07936 >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 3 08:24:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08656 for ; Fri, 3 Jan 2003 08:24:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03DX7S24818 for sip-archive@odin.ietf.org; Fri, 3 Jan 2003 08:33:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03DTEJ24696; Fri, 3 Jan 2003 08:29:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03DQ3J24510 for ; Fri, 3 Jan 2003 08:26:03 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08586 for ; Fri, 3 Jan 2003 08:16:44 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h03DJIjS007966; Fri, 3 Jan 2003 05:19:18 -0800 (PST) Received: from [10.32.254.182] (stealth-10-32-254-182.cisco.com [10.32.254.182]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id HDS00182; Fri, 3 Jan 2003 05:20:18 -0800 (PST) Date: Fri, 03 Jan 2003 08:19:37 -0500 From: "David R. Oran" To: Michael Thomas , Adam Roach cc: "'George Foti (LMC)'" , Eric Burger , Dean Willis , Jonathan Rosenberg , sip@ietf.org Subject: RE: [Sip] INFO considered harmful Message-ID: <2053401194.1041581977@[10.32.254.182]> In-Reply-To: <15892.53657.358186.315527@thomasm-u1.cisco.com> References: <9BF66EBF6BEFD942915B4D4D45C051F3A643BD@DYN-TX-EXCH-001.dynamicso ft.com> <15892.53657.358186.315527@thomasm-u1.cisco.com> X-Mailer: Mulberry/3.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I have nothing substantive to contribute to this discussion, except to observe that among my silly "Oran's laws of protocols", about five years ago I coined the following law: "any application protocol which works sufficiently well to be widely deployed eventually gets hijacked and used as a transport protocol" The fact that we are having this discussion is a testament to the success of SIP. History also seems to tell us that we may be fighting a losing battle in attempting to ban INFO and friends. Happy New Year, to the whole SI community. Dave. --On Thursday, January 02, 2003 3:56 PM -0800 Michael Thomas wrote: > > Right, but my personal bugaboo is modularity. > Like Don's FTPoSIP example, the more junk you > throw into one protocol, the more entangled it > becomes to the point that you have a deep dark > morass. In any case, we already have a real live > kitchen sink protocol: HTTP; you even run IP over > HTTP these days. I'd be surprised to hear that > just about anything that runs SIP doesn't also > have web kruft in it as well. > > Mike > > Adam Roach writes: > > A new method would be okay for new SIP-related functionality. > > > > But that's not what you proposed. > > > > You said, "The application is SIP based, we dont need yet > > another protocol to convey what needs to be conveyed e2e," > > which is an argument that we should use SIP as a general > > purpose RPC mechanism for any application that already has > > a SIP stack. > > > > Doing what you propose with INFO is inappropriate. > > > > Doing what you propose with a new method is inappropriate. > > > > Doing what you propose with SIP is inappropriate. > > > > Since you keep harping on technical, as opposed to > > philosophical, arguments, here's a couple: > > > > - The SIP protocol was designed for session initiation, > > negotiation, and teardown. The timing characteristics > > are not generally appropriate for application control. > > For example, with typical SIP networks, latency and > > jitter of messages are too high to provide any sort > > of reasonable user experience for floor control > > or DTMF transport. > > > > - Many proxies stay in the signalling path for the purposes > > of providing services. By sending unnecessary application- > > level information throught these proxies, you reduce the > > capacity and increase possible congestion of the network. > > > > I could go on, but this topic has had extensive airing on > > the list in years past. There's really no reason to beat > > this particular dead horse any longer. > > > > /a > > > > > -----Original Message----- > > > From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] > > > Sent: Thursday, January 02, 2003 16:05 > > > To: 'Adam Roach'; George Foti (LMC); 'Michael Thomas'; Eric Burger > > > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > > > Subject: RE: [Sip] INFO considered harmful > > > > > > > > > This should not be a philosophical discusion. > > > If a new SIP method is okay, why is INFO not okay. > > > > > > What is the difference? > > > Please explain in technical terms? > > > > > > /gf > > > > > > -----Original Message----- > > > From: Adam Roach [mailto:adam@dynamicsoft.com] > > > Sent: Thursday, January 02, 2003 2:36 PM > > > To: 'George Foti (LMC)'; 'Michael Thomas'; Eric Burger > > > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > > > Subject: RE: [Sip] INFO considered harmful > > > > > > > > > The argument of "but I'm already holding a hammer and *want* > > > to treat everything like a nail!" comes up on about an annual > > > basis, and is rejected outright each time. > > > > > > Just because you have a SIP stack in your application does > > > *not* mean that it is appropriate to use that stack for > > > all general network access. You're allowing laziness to > > > overwhelm good application design. > > > > > > /a > > > > > > > -----Original Message----- > > > > From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] > > > > Sent: Thursday, January 02, 2003 12:55 > > > > To: 'Michael Thomas'; Eric Burger > > > > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > > > > Subject: RE: [Sip] INFO considered harmful > > > > > > > > > > > > The application is SIP based, we dont need yet another > > > > protocol to convey what needs to be conveyed e2e. > > > > No need to go around the bush. > > > > Lets find *real* arguments against using INFO for that > > > > purpopse rather than philosphical ones. > > > > > > > > /gf > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Michael Thomas [mailto:mat@cisco.com] > > > > Sent: Thursday, January 02, 2003 12:53 PM > > > > To: Eric Burger > > > > Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org > > > > Subject: RE: [Sip] INFO considered harmful > > > > > > > > > > > > > > > > I don't get it. If you want "100% application > > > > specific", why not pick an unused port and roll > > > > your own protocol? Then all of the crufty SIPism > > > > don't get in the way, and the hue and cry from > > > > this working group ceases immediately. Do the bits > > > > on the wire keep warmer if they're dressed in SIP? > > > > > > > > Mike > > > > > > > > Eric Burger writes: > > > > > I fully agree with Dean on this one. > > > > > > > > > > One point to consider (I'm on the fence on this one) is > > > > whether we would say that INFO is 100% application-specific. > > > > That is, the WG will not publish standard body types. > > > > > > > > > > A reason for doing that is to let people know that INFO > > > > really is just, as Dean points out, > > > > application-to-application communication. If you want > > > > applications to interoperate, take it either to an > > > > Application Area WG or take it outside the IETF. > > > > > > > > > > One reason to not do this is SIP-T should use a method > > > > other than INFO. That said, I don't think there are that > > > > many SIP-T implementations extant. > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > > > > Sent: Tuesday, December 31, 2002 1:48 AM > > > > > > To: Jonathan Rosenberg; Orit Levin > > > > > > Cc: sip@ietf.org > > > > > > Subject: Re: [Sip] INFO considered harmful > > > > > > > > > > > > > > > > > > At 12:48 AM 12/31/2002 -0500, Jonathan Rosenberg wrote: > > > > > > >Orit Levin wrote: > > > > > > >>>The big huge difference I have been trying to point out is > > > > > > that EVENTS > > > > > > >>>DEFINES SEMANTICS, whereas INFO doesnt. > > > > > > >>>MIME provides semantics and syntax that are independent of > > > > > > the type. > > > > > > >>>SIP events provides semantics and syntax that are > > > > > > independent of the > > > > > > >>>package. > > > > > > >>>INFO provides nothing. > > > > > > >> > > > > > > >>INFO provides "minimal" but very important semantics: > > > > > > asynchronous data > > > > > > >>reliably follows the established SIP path. > > > > > > > > > > > > > >Huh? > > > > > > > > > > > > > >Every new SIP method is reliable, it inherits the SIP > > > > > > transaction state > > > > > > >machine for non-invite. Follows the established path? Every > > > > > > in-dialog > > > > > > >method would have this property, it is method independent. > > > > > > >Asynchronous? You can send any method at any time. > > > > > > > > > > > > > >Thus, nothing you have pointed out above is different > > > > > > between INFO and any > > > > > > >other new method we might introduce. > > > > > > > > > > > > I think the key point is that there is a difference > > > > between transport > > > > > > protocol semantic and application semantic. The transport > > > > > > protocol semantic > > > > > > expressed in INFO is "Here is some data that will be > > > used by the > > > > > > application. It is not important to the transport protocol, > > > > > > except that the > > > > > > transport protocol is expected to deliver it reliably". INFO > > > > > > says NOTHING > > > > > > about the APPLICATION level semantic -- that's up to what > > > > > > goes IN the INFO > > > > > > payloads. The question is -- do we try to rigidly define > > > > > > application-level > > > > > > semantics here? Do we define that there ARE no such > > > > > > applications possible? > > > > > > Or do we design a framework by which application-level > > > > > > semantics can be > > > > > > expressed outside of the protocol definition? > > > > > > > > > > > > And as for "Just add another method to your SIP stack". Let's > > > > > > say I have a > > > > > > mobile phone and the SIP stack is burned into ROM and > > > > exposes only a > > > > > > simplistic transactional API. This is only likely to > > > > happen, oh, 100 > > > > > > million times or so over the next two years . . . Now, just > > > > > > exactly how is > > > > > > my BREW or JTME application going to go about extending the > > > > > > SIP stack to > > > > > > support another method? Will the evil wireless operator > > > > > > networks even pass > > > > > > another method? Neither is happening anytime soon, I > > > think . . . > > > > > > > > > > > > -- > > > > > > 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 > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP 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 ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 3 11:28:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12307 for ; Fri, 3 Jan 2003 11:28:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03Gb1H04189 for sip-archive@odin.ietf.org; Fri, 3 Jan 2003 11:37:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03GXEJ03977; Fri, 3 Jan 2003 11:33:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03GQmJ03591 for ; Fri, 3 Jan 2003 11:26:48 -0500 Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12121 for ; Fri, 3 Jan 2003 11:17:27 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h03GKbJ19383 for ; Fri, 3 Jan 2003 11:20:37 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Jan 2003 16:20:33 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB006FFB3FF@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Jonathan Rosenberg , Henning Schulzrinne Cc: Adam Roach , "'Neil Deason'" , sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Fri, 3 Jan 2003 16:20:25 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , And I will support that. There may be a place for session based messaging, but for all those uses where cellphone SMS constraints work today, MESSAGE seems to be the appropriate solution. By the way, when we do get session based messaging, it will probably be impossible to write scoping rules that prevent someone sending two MESSAGE requests to the same destination, rather than setting up a session and sending two PDUs within that session. All we will be able to do is provide guidance. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 03 January 2003 06:19 > To: Henning Schulzrinne > Cc: Adam Roach; 'Neil Deason'; sip@ietf.org > Subject: Re: [Sip] INFO considered harmful > > > Henning is dead on. > > I think we will always need MESSAGE for this reason exactly. > It may be, > that as messaging sessions are completed, and we understand > the problem > space better, we would revise MESSAGE to impose further > restrictions on > it. For now, I think its pretty good as written. > > -Jonathan R. > > Henning Schulzrinne wrote: > > Actually, there's an important difference: MESSAGE can use the SIP > > features outside an established session, while INFO is > within a session > > (and thus there are other SDP-negotiated, options > available). Within a > > session, the only real reason for a follow-the-INVITE SIP > message is > > that a direct IP-level connection can't be made to work. > > > > From an efficiency standpoint, if you only have very occasional > > messages, you gain by a "connectionless" approach. After > all, an INVITE > > transaction for a single MESSAGE doesn't buy you much and doesn't > > conserve the oh-so-precious proxy cycles. While such short > sessions are > > probably not common for human-to-human communication > (except spam...), > > they may well be common for the type of things that SMS and > pagers are > > popular for: machine-to-human or machine-to-machine communications > > announcing infrequent and unpredictable events ("your flight is now > > leaving on gate 37", "your FedEx just arrived", "Server 42 > is on fire"). > > > > Adam Roach wrote: > > > >>> From: Neil Deason [mailto:ndeason@ubiquity.net] > >>> > >>> Actually if we want to police protocol usage closely we > had better > >>> look at deprecating MESSAGE too. > >> > >> > >> > >> Come back when SIMPLE has finished defining the message sessions, > >> and I'll throw my voice behind yours in advocating this. > >> > >> /a > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 3 11:30:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12364 for ; Fri, 3 Jan 2003 11:30:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03GcuI04893 for sip-archive@odin.ietf.org; Fri, 3 Jan 2003 11:38:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03GZSJ04102; Fri, 3 Jan 2003 11:35:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03GR7J03617 for ; Fri, 3 Jan 2003 11:27:07 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12131 for ; Fri, 3 Jan 2003 11:17:45 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.143]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h03GKsYH024887; Fri, 3 Jan 2003 11:20:54 -0500 (EST) Message-ID: <3E15B862.6090201@dynamicsoft.com> Date: Fri, 03 Jan 2003 11:20:50 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David R. Oran" CC: Michael Thomas , Adam Roach , "'George Foti (LMC)'" , Eric Burger , Dean Willis , sip@ietf.org Subject: Re: [Sip] INFO considered harmful References: <9BF66EBF6BEFD942915B4D4D45C051F3A643BD@DYN-TX-EXCH-001.dynamicso ft.com> <15892.53657.358186.315527@thomasm-u1.cisco.com> <2053401194.1041581977@[10.32.254.182]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit David R. Oran wrote: > I have nothing substantive to contribute to this discussion, except to > observe that among my silly "Oran's laws of protocols", about five years > ago I coined the following law: > > "any application protocol which works sufficiently well to be widely > deployed eventually gets hijacked and used as a transport protocol" Definitely true. Please do enumerate the others... would make a nice I-D I think. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 3 11:34:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12463 for ; Fri, 3 Jan 2003 11:34:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03GgvZ05147 for sip-archive@odin.ietf.org; Fri, 3 Jan 2003 11:42:57 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03GdRJ04919; Fri, 3 Jan 2003 11:39:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03GbMJ04607 for ; Fri, 3 Jan 2003 11:37:22 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12305 for ; Fri, 3 Jan 2003 11:28:02 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id h03GV6fm008932; Fri, 3 Jan 2003 08:31:06 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id ABA45836; Fri, 3 Jan 2003 08:24:04 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA27053; Fri, 3 Jan 2003 08:31:00 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15893.47811.844017.344903@thomasm-u1.cisco.com> Date: Fri, 3 Jan 2003 08:30:59 -0800 (PST) To: Jonathan Rosenberg Cc: "David R. Oran" , Michael Thomas , Adam Roach , "'George Foti (LMC)'" , Eric Burger , Dean Willis , sip@ietf.org Subject: Re: [Sip] INFO considered harmful In-Reply-To: <3E15B862.6090201@dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F3A643BD@DYN-TX-EXCH-001.dynamicso ft.com> <15892.53657.358186.315527@thomasm-u1.cisco.com> <2053401194.1041581977@[10.32.254.182]> <3E15B862.6090201@dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > > > David R. Oran wrote: > > I have nothing substantive to contribute to this discussion, except to > > observe that among my silly "Oran's laws of protocols", about five years > > ago I coined the following law: > > > > "any application protocol which works sufficiently well to be widely > > deployed eventually gets hijacked and used as a transport protocol" > > Definitely true. > > Please do enumerate the others... would make a nice I-D I think. I don't think anybody should be under the illusion that SIP won't be misused. What's at issue here specifically is whether the WG actually sanctions a free for all. One distinct downside is that there may actually be some gems that ought to be salvaged from the fetid swamp, but that will be extremely difficult if they work well enough. It just seems like a poor idea and precedent. 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 mailnull@www1.ietf.org Fri Jan 3 13:11:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15101 for ; Fri, 3 Jan 2003 13:11:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03IKIl12611 for sip-archive@odin.ietf.org; Fri, 3 Jan 2003 13:20:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03IFsJ12419; Fri, 3 Jan 2003 13:15:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03ID6J12122 for ; Fri, 3 Jan 2003 13:13:06 -0500 Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14898 for ; Fri, 3 Jan 2003 13:03:43 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] INFO considered harmful Date: Fri, 3 Jan 2003 13:06:55 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D2DF635@zoe.office.snowshore.com> Thread-Topic: [Sip] INFO considered harmful Thread-Index: AcKzRsyzwK8zmt6bRdCqtgcjgXqoNwAC1bmg From: "Eric Burger" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h03ID6J12123 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit The ironic part of the example: SMS is given as one of the reasons that wireless is so cool and why wireless operators can make money. SMS, in its present form, that is, not what "it could be", but what it IS, is given as an example of how to melt-down a signaling infrastructure. SMS was supposed to be very infrequent, so it was thought to be OK to run it on the SS7 infrastructure. No one anticipated the volume of point-to-point traffic SMS would generate. One reason SMS took a long time to deploy in the US is because the Bellheads running the US wireless networks said, "SMS will overrun our poor STPs -- we can never deploy such a service." Replace SMS with INFO, replace SS7 with SIP, and replace STP with SIP Proxy. Not a value judgment, just an interesting look at how people that did the "wrong" thing made a boatload of money and managed not to melt the network (when there is a will and lots of money, a way gets found), and people doing the "right" thing are still trying to figure out if they should go Chapter 11... > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Friday, January 03, 2003 11:20 AM > To: Jonathan Rosenberg; Henning Schulzrinne > Cc: Adam Roach; 'Neil Deason'; sip@ietf.org > Subject: RE: [Sip] INFO considered harmful > > > And I will support that. > > There may be a place for session based messaging, but for all > those uses where cellphone SMS constraints work today, > MESSAGE seems to be the appropriate solution. > > By the way, when we do get session based messaging, it will > probably be impossible to write scoping rules that prevent > someone sending two MESSAGE requests to the same destination, > rather than setting up a session and sending two PDUs within > that session. All we will be able to do is provide guidance. > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: 03 January 2003 06:19 > > To: Henning Schulzrinne > > Cc: Adam Roach; 'Neil Deason'; sip@ietf.org > > Subject: Re: [Sip] INFO considered harmful > > > > > > Henning is dead on. > > > > I think we will always need MESSAGE for this reason exactly. > > It may be, > > that as messaging sessions are completed, and we understand > > the problem > > space better, we would revise MESSAGE to impose further > > restrictions on > > it. For now, I think its pretty good as written. > > > > -Jonathan R. > > > > Henning Schulzrinne wrote: > > > Actually, there's an important difference: MESSAGE can > use the SIP > > > features outside an established session, while INFO is > > within a session > > > (and thus there are other SDP-negotiated, options > > available). Within a > > > session, the only real reason for a follow-the-INVITE SIP > > message is > > > that a direct IP-level connection can't be made to work. > > > > > > From an efficiency standpoint, if you only have very occasional > > > messages, you gain by a "connectionless" approach. After > > all, an INVITE > > > transaction for a single MESSAGE doesn't buy you much and doesn't > > > conserve the oh-so-precious proxy cycles. While such short > > sessions are > > > probably not common for human-to-human communication > > (except spam...), > > > they may well be common for the type of things that SMS and > > pagers are > > > popular for: machine-to-human or machine-to-machine > communications > > > announcing infrequent and unpredictable events ("your > flight is now > > > leaving on gate 37", "your FedEx just arrived", "Server 42 > > is on fire"). > > > > > > Adam Roach wrote: > > > > > >>> From: Neil Deason [mailto:ndeason@ubiquity.net] > > >>> > > >>> Actually if we want to police protocol usage closely we > > had better > > >>> look at deprecating MESSAGE too. > > >> > > >> > > >> > > >> Come back when SIMPLE has finished defining the message sessions, > > >> and I'll throw my voice behind yours in advocating this. > > >> > > >> /a > > >> _______________________________________________ > > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >> This list is for NEW development of the core SIP Protocol > > >> Use sip-implementors@cs.columbia.edu for questions on current sip > > >> Use sipping@ietf.org for new developments on the > application of sip > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the > application of sip > > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 3 13:43:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15836 for ; Fri, 3 Jan 2003 13:43:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03IqTI15294 for sip-archive@odin.ietf.org; Fri, 3 Jan 2003 13:52:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03ImgJ15046; Fri, 3 Jan 2003 13:48:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03IlvJ14970 for ; Fri, 3 Jan 2003 13:47:57 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15684 for ; Fri, 3 Jan 2003 13:38:33 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id h03IfcKv008794; Fri, 3 Jan 2003 10:41:38 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id ABA49198; Fri, 3 Jan 2003 10:34:41 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA27060; Fri, 3 Jan 2003 10:41:36 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15893.55647.713333.376664@thomasm-u1.cisco.com> Date: Fri, 3 Jan 2003 10:41:35 -0800 (PST) To: Juha Heinanen Cc: Michael Thomas , Robert Sparks , Jonathan Rosenberg , Cullen Jennings , sip@ietf.org Subject: Re: [Sip] Enrollment in SIP services (and should we undeprecate basic auth) In-Reply-To: <15889.35402.270711.303036@lohi.eng.song.fi> References: <004401c2a85e$99855700$618d6b80@amer.cisco.com> <3E0375E7.1080608@dynamicsoft.com> <1040415671.949.161.camel@RjS.localdomain> <15888.48291.700746.59246@thomasm-u1.cisco.com> <15889.35402.270711.303036@lohi.eng.song.fi> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Juha Heinanen writes: > Michael Thomas writes: > > > The problem is that AAA's expect either a CHAP or > > PAP formated authenticator. Digest, while it > > doesn't chip the cleartext password ain't the same > > format so you have a problem. Basic allows you to > > hack up an authenticator at the proxy. Maybe > > EAP+digest is our friend. Or maybe not. > > what is wrong with draft-sterman-aaa-sip-00.txt? we use it with digets > authentication without any problems. leading radius servers support it > as well as all good sip proxies. Well, it seems to be expried for one... is the jist that AAA's have been hacked to deal with digest auth types directly (or, say, as an EAP type)? If so, that's certainly a possibility, and would have the obvious benefit of being useable for the web as well. 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 mailnull@www1.ietf.org Fri Jan 3 14:05:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16689 for ; Fri, 3 Jan 2003 14:05:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03JEox17998 for sip-archive@odin.ietf.org; Fri, 3 Jan 2003 14:14:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03JAkJ17830; Fri, 3 Jan 2003 14:10:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03J9eJ17750 for ; Fri, 3 Jan 2003 14:09:40 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16576 for ; Fri, 3 Jan 2003 14:00:16 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 18UX6M-00035p-00; Fri, 03 Jan 2003 21:03:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15893.56958.498359.867714@harjus.eng.song.fi> Date: Fri, 3 Jan 2003 21:03:26 +0200 To: Michael Thomas Cc: Robert Sparks , Jonathan Rosenberg , Cullen Jennings , sip@ietf.org Subject: Re: [Sip] Enrollment in SIP services (and should we undeprecate basic auth) In-Reply-To: <15893.55647.713333.376664@thomasm-u1.cisco.com> References: <004401c2a85e$99855700$618d6b80@amer.cisco.com> <3E0375E7.1080608@dynamicsoft.com> <1040415671.949.161.camel@RjS.localdomain> <15888.48291.700746.59246@thomasm-u1.cisco.com> <15889.35402.270711.303036@lohi.eng.song.fi> <15893.55647.713333.376664@thomasm-u1.cisco.com> X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Michael Thomas writes: > Well, it seems to be expried for one... is the jist > that AAA's have been hacked to deal with digest auth > types directly (or, say, as an EAP type)? i made draft-sterman-aaa-sip-00.txt available as ftp://lohi.eng.song.fi/tmp/draft-sterman-aaa-sip-00.txt the directory is not listable. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 3 14:24:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17099 for ; Fri, 3 Jan 2003 14:24:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03JWwh18713 for sip-archive@odin.ietf.org; Fri, 3 Jan 2003 14:32:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03JSuJ18568; Fri, 3 Jan 2003 14:28:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03JRTJ18503 for ; Fri, 3 Jan 2003 14:27:29 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16928 for ; Fri, 3 Jan 2003 14:18:03 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h03JLEZ5000543 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 3 Jan 2003 14:21:15 -0500 (EST) Message-ID: <3E15E302.80508@cs.columbia.edu> Date: Fri, 03 Jan 2003 14:22:42 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Burger CC: sip@ietf.org Subject: Re: [Sip] INFO considered harmful References: <4A3384433CE2AB46A63468CB207E209D2DF635@zoe.office.snowshore.com> In-Reply-To: <4A3384433CE2AB46A63468CB207E209D2DF635@zoe.office.snowshore.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit To add additional perspective: In 2001, 200 billion SMS were sent (for GSM, http://www.idg.net/idgns/2001/05/29/UPDATE2StudySMSMessagesWillTop200.shtml). Comes to about 6400/second. Assuming that a reasonably well tuned server can handle 100/messages a second, that requires about 100 servers, multiplied by the number of network hops (residential and small-business end hops don't matter since they are not likely to be congested). Total cost some small multiple of $100k. This total would be sufficient to handle the service for all GSM carriers, worldwide. I don't think that's a major factor in any protocol debate. In general, I just don't buy server load arguments. If it's a useful service, server cost is usually the least of the problem. In any event, one should take this as a fraction of the existing signaling load, not as some absolute number. I'm worried about stuff that multiplies the signaling load by a factor of 10; I find 20 or 50% load increase uninteresting as an argument. (Thus, while I find 'INFO-for-DTMF' distasteful, the signaling load is the least of the problems, given that most phone calls will see at most a handful of touch tone digits.) Eric Burger wrote: > The ironic part of the example: > > SMS is given as one of the reasons that wireless is so cool and why wireless operators can make money. > > SMS, in its present form, that is, not what "it could be", but what it IS, is given as an example of how to melt-down a signaling infrastructure. SMS was supposed to be very infrequent, so it was thought to be OK to run it on the SS7 infrastructure. No one anticipated the volume of point-to-point traffic SMS would generate. One reason SMS took a long time to deploy in the US is because the Bellheads running the US wireless networks said, "SMS will overrun our poor STPs -- we can never deploy such a service." > > Replace SMS with INFO, replace SS7 with SIP, and replace STP with SIP Proxy. > > Not a value judgment, just an interesting look at how people that did the "wrong" thing made a boatload of money and managed not to melt the network (when there is a will and lots of money, a way gets found), and people doing the "right" thing are still trying to figure out if they should go Chapter 11... > > >>-----Original Message----- >>From: Drage, Keith (Keith) [mailto:drage@lucent.com] >>Sent: Friday, January 03, 2003 11:20 AM >>To: Jonathan Rosenberg; Henning Schulzrinne >>Cc: Adam Roach; 'Neil Deason'; sip@ietf.org >>Subject: RE: [Sip] INFO considered harmful >> >> >>And I will support that. >> >>There may be a place for session based messaging, but for all >>those uses where cellphone SMS constraints work today, >>MESSAGE seems to be the appropriate solution. >> >>By the way, when we do get session based messaging, it will >>probably be impossible to write scoping rules that prevent >>someone sending two MESSAGE requests to the same destination, >>rather than setting up a session and sending two PDUs within >>that session. All we will be able to do is provide guidance. >> >>Keith >> >>Keith Drage >>Lucent Technologies >>Tel: +44 1793 776249 >>Email: drage@lucent.com >> >> >>>-----Original Message----- >>>From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>>Sent: 03 January 2003 06:19 >>>To: Henning Schulzrinne >>>Cc: Adam Roach; 'Neil Deason'; sip@ietf.org >>>Subject: Re: [Sip] INFO considered harmful >>> >>> >>>Henning is dead on. >>> >>>I think we will always need MESSAGE for this reason exactly. >>>It may be, >>>that as messaging sessions are completed, and we understand >>>the problem >>>space better, we would revise MESSAGE to impose further >>>restrictions on >>>it. For now, I think its pretty good as written. >>> >>>-Jonathan R. >>> >>>Henning Schulzrinne wrote: >>> >>>>Actually, there's an important difference: MESSAGE can >> >>use the SIP >> >>>>features outside an established session, while INFO is >>> >>>within a session >>> >>>>(and thus there are other SDP-negotiated, options >>> >>>available). Within a >>> >>>>session, the only real reason for a follow-the-INVITE SIP >>> >>>message is >>> >>>>that a direct IP-level connection can't be made to work. >>>> >>>> From an efficiency standpoint, if you only have very occasional >>>>messages, you gain by a "connectionless" approach. After >>> >>>all, an INVITE >>> >>>>transaction for a single MESSAGE doesn't buy you much and doesn't >>>>conserve the oh-so-precious proxy cycles. While such short >>> >>>sessions are >>> >>>>probably not common for human-to-human communication >>> >>>(except spam...), >>> >>>>they may well be common for the type of things that SMS and >>> >>>pagers are >>> >>>>popular for: machine-to-human or machine-to-machine >> >>communications >> >>>>announcing infrequent and unpredictable events ("your >> >>flight is now >> >>>>leaving on gate 37", "your FedEx just arrived", "Server 42 >>> >>>is on fire"). >>> >>>>Adam Roach wrote: >>>> >>>> >>>>>>From: Neil Deason [mailto:ndeason@ubiquity.net] >>>>>> >>>>>>Actually if we want to police protocol usage closely we >>> >>>had better >>> >>>>>>look at deprecating MESSAGE too. >>>>> >>>>> >>>>> >>>>>Come back when SIMPLE has finished defining the message sessions, >>>>>and I'll throw my voice behind yours in advocating this. >>>>> >>>>>/a >>>>>_______________________________________________ >>>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>This list is for NEW development of the core SIP Protocol >>>>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>>>Use sipping@ietf.org for new developments on the >> >>application of sip >> >>>> >>>>_______________________________________________ >>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>This list is for NEW development of the core SIP Protocol >>>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>>Use sipping@ietf.org for new developments on the >> >>application of sip >> >>>-- >>>Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >>>Chief Scientist First Floor >>>dynamicsoft East Hanover, NJ 07936 >>>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>>http://www.jdrosen.net PHONE: (973) 952-5000 >>>http://www.dynamicsoft.com >>> >>>_______________________________________________ >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sipping@ietf.org for new developments on the application of sip >>> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Fri Jan 3 15:18:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18203 for ; Fri, 3 Jan 2003 15:18:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03KRfp22148 for sip-archive@odin.ietf.org; Fri, 3 Jan 2003 15:27:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03KNeJ21961; Fri, 3 Jan 2003 15:23:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03KL6J21897 for ; Fri, 3 Jan 2003 15:21:06 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18040 for ; Fri, 3 Jan 2003 15:11:40 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h03KDNSK012889; Fri, 3 Jan 2003 15:13:23 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Jan 2003 14:14:45 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A643C6@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Henning Schulzrinne'" , Eric Burger Cc: sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Fri, 3 Jan 2003 14:14:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > In general, I just don't buy server load arguments. If it's a > useful service, server cost is usually the least of the problem. > In any event, one should take this as a fraction of the existing > signaling load, not as some absolute number. I'm worried about > stuff that multiplies the signaling load by a factor of 10; I find > 20 or 50% load increase uninteresting as an argument. You don't buy server load arguments? Real-world experience notwithstanding? I'm recalling the rise in popularity of Real Media Player and its ability to set up an audio stream through an HTTP proxy. In particular, I'm recalling conversations shortly thereafter with some friends over in MIS about how they just couldn't add capacity to the HTTP proxy pool fast enough to keep up with demand. Access to external web documents sometimes creeped up to the order of minutes before everything was finally stabilized. How long do you guess it will be before Real player (or a similar product) includes a "SIP Proxy:" field right next to its "HTTP Proxy:" field for firewall circumvention? /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 3 15:21:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18289 for ; Fri, 3 Jan 2003 15:21:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03KUhS22341 for sip-archive@odin.ietf.org; Fri, 3 Jan 2003 15:30:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03KRCJ22130; Fri, 3 Jan 2003 15:27:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03KQrJ22066 for ; Fri, 3 Jan 2003 15:26:53 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18110 for ; Fri, 3 Jan 2003 15:17:27 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h03KKbDT001457 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 3 Jan 2003 15:20:37 -0500 (EST) Message-ID: <3E15F0ED.7070002@cs.columbia.edu> Date: Fri, 03 Jan 2003 15:22:05 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: Eric Burger , sip@ietf.org Subject: Re: [Sip] INFO considered harmful References: <9BF66EBF6BEFD942915B4D4D45C051F3A643C6@DYN-TX-EXCH-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A643C6@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Your example clearly falls into the "> 10" category as the poor web server had to deal with every Real audio or video packet. Not that it would surprise me, but I don't think anybody *here* has suggested RTP-over-INFO so far. Adam Roach wrote: >>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> >>In general, I just don't buy server load arguments. If it's a >>useful service, server cost is usually the least of the problem. >>In any event, one should take this as a fraction of the existing >>signaling load, not as some absolute number. I'm worried about >>stuff that multiplies the signaling load by a factor of 10; I find >>20 or 50% load increase uninteresting as an argument. > > > You don't buy server load arguments? Real-world experience > notwithstanding? > > I'm recalling the rise in popularity of Real Media Player and > its ability to set up an audio stream through an HTTP proxy. > In particular, I'm recalling conversations shortly thereafter > with some friends over in MIS about how they just couldn't add > capacity to the HTTP proxy pool fast enough to keep up with > demand. > > Access to external web documents sometimes creeped up to the > order of minutes before everything was finally stabilized. > > How long do you guess it will be before Real player > (or a similar product) includes a "SIP Proxy:" field right > next to its "HTTP Proxy:" field for firewall circumvention? > > /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 3 16:41:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19724 for ; Fri, 3 Jan 2003 16:41:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03LodG27049 for sip-archive@odin.ietf.org; Fri, 3 Jan 2003 16:50:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03Ll6J26906; Fri, 3 Jan 2003 16:47:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03LiOJ26801 for ; Fri, 3 Jan 2003 16:44:24 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19567 for ; Fri, 3 Jan 2003 16:34:56 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h03Lbp8a001416; Fri, 3 Jan 2003 15:37:53 -0600 From: "Dean Willis" To: "'Michael Thomas'" , "'Eric Burger'" Cc: "'Jonathan Rosenberg'" , Subject: RE: [Sip] INFO considered harmful Date: Fri, 3 Jan 2003 15:37:29 -0600 Message-ID: <004301c2b370$525868f0$73036e3f@txdwillis> 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.4510 Importance: Normal In-Reply-To: <15892.31891.956251.196024@thomasm-u1.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mike asked: > I don't get it. If you want "100% application > specific", why not pick an unused port and roll > your own protocol? Then all of the crufty SIPism > don't get in the way, and the hue and cry from > this working group ceases immediately. Do the bits > on the wire keep warmer if they're dressed in SIP? Not only do they keep warmer, but they get to take advantage of all those nifty SIP functions, like rendezvous, delivery delegation, security, and MOST IMPORTANTLY, name-space correlation with the application naming provided by SIP. In short, all of the same reasons why PUBLISH-type methods kep getting suggested. -- 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 mailnull@www1.ietf.org Fri Jan 3 16:41:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19726 for ; Fri, 3 Jan 2003 16:41:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03LodK27061 for sip-archive@odin.ietf.org; Fri, 3 Jan 2003 16:50:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03LkbJ26881; Fri, 3 Jan 2003 16:46:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03LiEJ26782 for ; Fri, 3 Jan 2003 16:44:14 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19563 for ; Fri, 3 Jan 2003 16:34:45 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h03Lbp8Y001416; Fri, 3 Jan 2003 15:37:52 -0600 From: "Dean Willis" To: "'Jonathan Rosenberg'" Cc: Subject: RE: [Sip] INFO considered harmful Date: Fri, 3 Jan 2003 15:37:29 -0600 Message-ID: <004101c2b370$51db22a0$73036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <3E14A98F.3070803@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h03LiEJ26783 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > Just one moment. SIP is not a transport protocol as its defined in my > book. Although SIP is generic in that it can support lots of > applications (conferencing, IVR, gaming, etc.), it is not unbounded. > SIP's messages provide semantics common to all applications which > require person-to-person communications. That does NOT make it a > transport prorotocol for arbitrary data communication. Well, I think that's exactly where we disagree, and I believe that the vast majority of people using SIP think of it a lot more like I do. At least the ones in 3G-space seem to. Here's what I think I believe: SIP provides for the establishment of a session (dialog) between two or more end points, optionally intermediated by proxies, and the exchange of information between those end points. This information is applied by applications to provide application functionality. SIP provides several methods for relaying application information, including relaying a text message, requesting notification of changes in the state of a named element, reporting a change in the state of some named element, and so on. It is either a historical accident that the dialog-initiation request (INVITE) is non-transparently overloaded with media session negotiation OR that the media session negotiation method (INVITE) establishes a dialog on which other requests may be relayed. > The stack has to allow extensibility to pass unknown INFO > bodies up to > the application for handling. Why this is any different than having > extensibility to handle unknown methods up to the application, is a > mystery to me. Nope. There's no extension required to the protocol stack to deliver one type of MIME body versus deliverying another type of MIME body. It's just a vyte-vector in a buffer. Otherwise, we'd be rewriting sendmail and httpd every 47 minutes to support a new body type. -- 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 mailnull@www1.ietf.org Fri Jan 3 16:41:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19750 for ; Fri, 3 Jan 2003 16:41:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03LoiC27075 for sip-archive@odin.ietf.org; Fri, 3 Jan 2003 16:50:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03LlGJ26930; Fri, 3 Jan 2003 16:47:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03LiPJ26805 for ; Fri, 3 Jan 2003 16:44:25 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19570 for ; Fri, 3 Jan 2003 16:34:56 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h03Lbp8X001416; Fri, 3 Jan 2003 15:37:51 -0600 From: "Dean Willis" To: "'Adam Roach'" , "'George Foti \(LMC\)'" , "'Michael Thomas'" , "'Eric Burger'" Cc: "'Jonathan Rosenberg'" , Subject: RE: [Sip] INFO considered harmful Date: Fri, 3 Jan 2003 15:37:29 -0600 Message-ID: <004001c2b370$51b65c90$73036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A643BD@DYN-TX-EXCH-001.dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h03LiQJ26808 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Adam said: > You said, "The application is SIP based, we dont need yet > another protocol to convey what needs to be conveyed e2e," > which is an argument that we should use SIP as a general > purpose RPC mechanism for any application that already has a > SIP stack. > > Doing what you propose with INFO is inappropriate. > > Doing what you propose with a new method is inappropriate. > > Doing what you propose with SIP is inappropriate. The key point is that we already have two applications talking to each other on a SIP dialog. The SIP intermediaries are providing the routing function between those applications. The ONLY routing knowledge those applications have about each other is that expressed in the SIP channel. Therefore, the existing SIP dialog makes an awfully handy mechanism for exchanging data between those two aplications. -- 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 mailnull@www1.ietf.org Fri Jan 3 16:41:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19764 for ; Fri, 3 Jan 2003 16:41:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03Lonj27088 for sip-archive@odin.ietf.org; Fri, 3 Jan 2003 16:50:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03LlMJ26949; Fri, 3 Jan 2003 16:47:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03LiPJ26807 for ; Fri, 3 Jan 2003 16:44:25 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19571 for ; Fri, 3 Jan 2003 16:34:56 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h03Lbp8Z001416; Fri, 3 Jan 2003 15:37:52 -0600 From: "Dean Willis" To: "'Don Stanwyck'" , "'George Foti \(LMC\)'" , "'Michael Thomas'" , "'Eric Burger'" Cc: "'Jonathan Rosenberg'" , Subject: RE: [Sip] INFO considered harmful Date: Fri, 3 Jan 2003 15:37:29 -0600 Message-ID: <004201c2b370$5216a500$73036e3f@txdwillis> 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.4510 Importance: Normal In-Reply-To: <003001c2b29b$560fb460$0300000a@DONGWLAPTOP> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Don said: > 2) If the apps need to talk directly to each other there are > a host of protocols that are extremely trivial that can do > the job. The apps can even just open a port over any > transport protocol and exchange information as they please. > There is no reason to bother all the routing proxies in the > network with your e2e private chatter. Not really, because the only thing that one app knows about another is its SIP URL. Yeah, I suppose you could use another INVITE transaction to establish a new dialog to convey the e2e stuff, but since we ALREADY have a dialog established (INFO runs on an existing dialog, right?) it's a hell of lot easier to just use the existing dialog. Especially given that the existing dialog has the property of being connected to exactly the right instance of the remote application. In short, we can ratehr obviously use SIP to talk to a SIP-enabled application that we're already talking to using 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 mailnull@www1.ietf.org Fri Jan 3 17:04:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20150 for ; Fri, 3 Jan 2003 17:04:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03MDHX28975 for sip-archive@odin.ietf.org; Fri, 3 Jan 2003 17:13:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03M9PJ28867; Fri, 3 Jan 2003 17:09:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03M8OJ28832 for ; Fri, 3 Jan 2003 17:08:24 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20084 for ; Fri, 3 Jan 2003 16:58:55 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id h03M22Kv029970; Fri, 3 Jan 2003 14:02:02 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id ABA55061; Fri, 3 Jan 2003 13:55:05 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA27074; Fri, 3 Jan 2003 14:02:01 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15894.2137.269501.112914@thomasm-u1.cisco.com> Date: Fri, 3 Jan 2003 14:02:01 -0800 (PST) To: "Dean Willis" Cc: "'Michael Thomas'" , "'Eric Burger'" , "'Jonathan Rosenberg'" , Subject: RE: [Sip] INFO considered harmful In-Reply-To: <004301c2b370$525868f0$73036e3f@txdwillis> References: <15892.31891.956251.196024@thomasm-u1.cisco.com> <004301c2b370$525868f0$73036e3f@txdwillis> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dean Willis writes: > Mike asked: > > I don't get it. If you want "100% application > > specific", why not pick an unused port and roll > > your own protocol? Then all of the crufty SIPism > > don't get in the way, and the hue and cry from > > this working group ceases immediately. Do the bits > > on the wire keep warmer if they're dressed in SIP? > > Not only do they keep warmer, but they get to take advantage of all those > nifty SIP functions, like rendezvous, delivery delegation, security, and > MOST IMPORTANTLY, name-space correlation with the application naming > provided by SIP. In short, all of the same reasons why PUBLISH-type methods > kep getting suggested. Dean, It's patently obvious _why_ people want to do this not unlike Mallory and Everest ("because it's there!"). The question is whether it's a Good Idea. The thing that squicks me is the anything goes attitude parading around as "application data". Well, SIP is already chock full of various bits and pieces of "application data" and they have well defined syntax and semantics. Why is it OK to have INFO bits which are completely unspecified but all the rest are well specified? It's just inviting interoperability problems and ad hoc standards making. Now I have no doubt that this is going to happen no matter what, but it doesn't mean that IETF needs to build and maintain its kitty litter box. Others have brought up SMS as an example. In fact, I think that SMS argues *exactly* the opposite: that sort of functionality needs to be very well specified so that interoperablity is achieved. Leaving it up to individual vendors, or providers or whatever would be a huge mess. For less interesting things... well, proprietary methods, X-blahblahblah's and all of the rest can be hacked up without any help whatsoever from IETF. If they become interesting, we can then standardize them. What I just don't see any value to is an officially sanctioned free for all. What purpose does it serve other than people getting to point to a nice shiny RFC number for their proprietary extensions? 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 mailnull@www1.ietf.org Fri Jan 3 17:11:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20266 for ; Fri, 3 Jan 2003 17:11:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03MJxm29210 for sip-archive@odin.ietf.org; Fri, 3 Jan 2003 17:19:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03MGLJ29100; Fri, 3 Jan 2003 17:16:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03MDhJ28996 for ; Fri, 3 Jan 2003 17:13:43 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20147 for ; Fri, 3 Jan 2003 17:04:14 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h03M7K8W001699; Fri, 3 Jan 2003 16:07:20 -0600 From: "Dean Willis" To: "'Adam Roach'" , "'Frank W. Miller'" , "'Jonathan Rosenberg'" Cc: Date: Fri, 3 Jan 2003 16:06:58 -0600 Message-ID: <004401c2b374$6fdd2f60$73036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A643C0@DYN-TX-EXCH-001.dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h03MDhJ28997 Subject: [Sip] Restatement: INFO considered harmful Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit My mother said I should stop inflaming things, but here I go again anyhow. Sorry, Mom. Adam said, responding to Frank in our long-winded exchange: > Perhaps using some sort of protocol to initate this session > would be appropriate. You'll also needs a protocol of some > sort to describe it, probably carried as a payload in this > session initation protocol. Ideally, this session description > protocol could leverage IANA-registered media types to > describe the content of such sessions, so that an infinite > number of types of sessions can be described. Actually, Adam and I just had a conversation about this argument. I think actually that there is something hiding in here which is THE HEART of almost every philosophical debate we've ever had in SIP. If we can get this nailed down now, we'll be preventing a HUGE number of future fights. Or in short: Boom! Epiphany! I think I understand what we're arguing about. I'll admit -- Adam's been philosophically consistent in his arguments since day 1. He believes that SIP should start sessions, stop sessions, and nothing else. Examples: Lets look at "events". By Adam's logic, the event system should consist of sending an INVITE (instead of a SUBSCRIBE) to the event source. The SDP body (Only SDP should be allowed in INVITE) would descibe the events being requested and the protocol, IP address and port number on which the subscriber would be listening. The 200 OK response from the event source would then contain the protocol, IP address and port number to which the subscriber should send acknowledgements of notifications, assuming that the notification-transport protocol (clearly, not SIP). And Whoa! Look at REGISTER. That doesn't set up any kind of session! It's clearly not a SIP function. We should instead use an INVITE to set up a "registration session", over which we would then use a registration protocol to establish registrations. MESSAGE is clearly divergent. By Adam's logic, only message sessions should be used. By similar reasoning, INFO is also off, and instead SIP-T should use INVITE to establish a sigtran session. This actually all makes sense and hangs together philosophically. The problem is, the working group diverted from that philosophy a long time ago. What we have now is a combination of three transactional protocols (REGISTER, OPTIONS, MESSAGE) with a session-establishment protocol (INVITE) which supports several in-session request verbs (UPDATE, OPTIONS, ACK, INFO, MESSAGE, BYE, PRACK, etc.) and another session-establishment protocol (SUBSCRIBE) which supports an in-session request verb (NOTIFY). We've also defined an intermediation framework (the SIP Proxy) and a set of end-to-end and hop-by-hop authentication and integrity protection mechanisms that can be used for all these protocols. Really, it's the intermediation framework that gives SIP most of its utility. Ok, it could be tidier. But it is very powerful, fairly complete, and actually works. And yes, the combination effectively provides a very useful transport protocol that does all sorts of things that HTTP alone can't do, such as intermediated rendezvous. And no, it DOESN'T just do phone calls (making attempts to model proxy load based on telephone switch metrics hopelessly bogus). So my humble suggestion: Get over it. Iron out any kruft that makes SIP less desirable as a transport protocol (like UDP), and get on with the business of making stuff that people can use to get their jobs done. Stop complaining that your proxies are getting loaded down by serving a useful purpose to somebody, and start understanding what that purpose is and how to charge for it. If you don't like it, fine. Let's take out a poll on deprecating REGISTER, MESSAGE, SUBSCRIBE, INFO, PRACK, SUBSCRIBE, NOTIFY, and all that other stuff. Or hey, just toss it all out and add session negotiation to XMPP. -- 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 mailnull@www1.ietf.org Fri Jan 3 17:13:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20334 for ; Fri, 3 Jan 2003 17:13:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03MMmx29337 for sip-archive@odin.ietf.org; Fri, 3 Jan 2003 17:22:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03MJDJ29186; Fri, 3 Jan 2003 17:19:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03MINJ29156 for ; Fri, 3 Jan 2003 17:18:23 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20217 for ; Fri, 3 Jan 2003 17:08:53 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h03MC2md029565 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 3 Jan 2003 17:12:02 -0500 (EST) Message-ID: <3E160B09.6030803@cs.columbia.edu> Date: Fri, 03 Jan 2003 17:13:29 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: "'Jonathan Rosenberg'" , sip@ietf.org Subject: Re: [Sip] INFO considered harmful References: <004101c2b370$51db22a0$73036e3f@txdwillis> In-Reply-To: <004101c2b370$51db22a0$73036e3f@txdwillis> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit INFO = BEEP-like functionality over SIP :-)? To amplify one part of what Dean said: Part of the functionality that an SDP-negotiated channel does not (readily) provide is different degrees of specificity. In SDP, I have to include a single IP address or an A-record. In SIP, Contact can be significantly more general, since it allows different degrees of binding detail and much more resolution functionality (SRV, NAPTR), including using the same old generic address that started the session and thus redoing the resolution with every request. This makes life much easier for sparse sessions with user mobility (same user, different device). This matters less when you already have a set of media sessions that need to be re-negotiated anyway when things change. Dean Willis wrote: > > SIP provides for the establishment of a session (dialog) between two or more > end points, optionally intermediated by proxies, and the exchange of > information between those end points. This information is applied by > applications to provide application functionality. SIP provides several > methods for relaying application information, including relaying a text > message, requesting notification of changes in the state of a named element, > reporting a change in the state of some named element, and so on. It is > either a historical accident that the dialog-initiation request (INVITE) is > non-transparently overloaded with media session negotiation OR that the > media session negotiation method (INVITE) establishes a dialog on which > other requests may be relayed. > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 3 17:36:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20734 for ; Fri, 3 Jan 2003 17:36:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03MjS030865 for sip-archive@odin.ietf.org; Fri, 3 Jan 2003 17:45:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03MfRJ30790; Fri, 3 Jan 2003 17:41:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03MeeJ30743 for ; Fri, 3 Jan 2003 17:40:40 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20669 for ; Fri, 3 Jan 2003 17:31:12 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.143]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h03MYIYH025062; Fri, 3 Jan 2003 17:34:20 -0500 (EST) Message-ID: <3E160FE7.2000907@dynamicsoft.com> Date: Fri, 03 Jan 2003 17:34:15 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Eric Burger , sip@ietf.org Subject: Re: [Sip] INFO considered harmful References: <4A3384433CE2AB46A63468CB207E209D2DF635@zoe.office.snowshore.com> <3E15E302.80508@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Henning Schulzrinne wrote: > In general, I just don't buy server load arguments. If it's a useful > service, server cost is usually the least of the problem. In any event, > one should take this as a fraction of the existing signaling load, not > as some absolute number. I'm worried about stuff that multiplies the > signaling load by a factor of 10; I find 20 or 50% load increase > uninteresting as an argument. My firsthand experience with selling stuff to carriers is that this is most definitely not the way they see it. Remember, the equipment purchases are made up front before the service is activated. If you can sell a carrier a solution that requires 50% or even 20% fewer boxes, thats a big win. Its not just the equipment cost, its the management cost too that increases with the box counts. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 3 17:46:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20926 for ; Fri, 3 Jan 2003 17:46:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03MtPu31220 for sip-archive@odin.ietf.org; Fri, 3 Jan 2003 17:55:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03MpqJ31046; Fri, 3 Jan 2003 17:51:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03Mo3J30989 for ; Fri, 3 Jan 2003 17:50:03 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20810 for ; Fri, 3 Jan 2003 17:40:34 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.143]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h03MhjYH025065; Fri, 3 Jan 2003 17:43:46 -0500 (EST) Message-ID: <3E16121D.6070809@dynamicsoft.com> Date: Fri, 03 Jan 2003 17:43:41 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: "'Adam Roach'" , "'Frank W. Miller'" , sip@ietf.org References: <004401c2b374$6fdd2f60$73036e3f@txdwillis> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Restatement: INFO considered harmful Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dean, The lines are not always so black and white. Its not a choice between "do anything" and "do nothing but INVITE". There is a line somewhere about what is a good use of sip, and what is not. We have some documents, even, which help to identify that line (SIP guidelines), and no doubt it has moved over time. Indeed, there were even arguments about whether BYE belonged in SIP, since clearly its not needed for "initiation". However, if you buy the assertion that SIP needs to at least manage the session, that clearly includes termination as well as initiation. These days, I know of very few folks (only one in fact) that would argue against BYE as part of SIP. I still stand by my assertion that many of the usages of SIP INFO are over that line, and that in order to keep the usages in a line we are comfortable with, something has to be done. -Jonathan R. Dean Willis wrote: > My mother said I should stop inflaming things, but here I go again anyhow. > Sorry, Mom. > > Adam said, responding to Frank in our long-winded exchange: > >>Perhaps using some sort of protocol to initate this session >>would be appropriate. You'll also needs a protocol of some >>sort to describe it, probably carried as a payload in this >>session initation protocol. Ideally, this session description >>protocol could leverage IANA-registered media types to >>describe the content of such sessions, so that an infinite >>number of types of sessions can be described. > > > Actually, Adam and I just had a conversation about this argument. I think > actually that there is something hiding in here which is THE HEART of almost > every philosophical debate we've ever had in SIP. If we can get this nailed > down now, we'll be preventing a HUGE number of future fights. > > Or in short: Boom! Epiphany! I think I understand what we're arguing about. > > I'll admit -- Adam's been philosophically consistent in his arguments since > day 1. He believes that SIP should start sessions, stop sessions, and > nothing else. > > Examples: > > Lets look at "events". By Adam's logic, the event system should consist of > sending an INVITE (instead of a SUBSCRIBE) to the event source. The SDP body > (Only SDP should be allowed in INVITE) would descibe the events being > requested and the protocol, IP address and port number on which the > subscriber would be listening. The 200 OK response from the event source > would then contain the protocol, IP address and port number to which the > subscriber should send acknowledgements of notifications, assuming that the > notification-transport protocol (clearly, not SIP). > > And Whoa! Look at REGISTER. That doesn't set up any kind of session! It's > clearly not a SIP function. We should instead use an INVITE to set up a > "registration session", over which we would then use a registration protocol > to establish registrations. > > MESSAGE is clearly divergent. By Adam's logic, only message sessions should > be used. By similar reasoning, INFO is also off, and instead SIP-T should > use INVITE to establish a sigtran session. > > This actually all makes sense and hangs together philosophically. > > The problem is, the working group diverted from that philosophy a long time > ago. What we have now is a combination of three transactional protocols > (REGISTER, OPTIONS, MESSAGE) with a session-establishment protocol (INVITE) > which supports several in-session request verbs (UPDATE, OPTIONS, ACK, INFO, > MESSAGE, BYE, PRACK, etc.) and another session-establishment protocol > (SUBSCRIBE) which supports an in-session request verb (NOTIFY). We've also > defined an intermediation framework (the SIP Proxy) and a set of end-to-end > and hop-by-hop authentication and integrity protection mechanisms that can > be used for all these protocols. Really, it's the intermediation framework > that gives SIP most of its utility. > > Ok, it could be tidier. But it is very powerful, fairly complete, and > actually works. And yes, the combination effectively provides a very useful > transport protocol that does all sorts of things that HTTP alone can't do, > such as intermediated rendezvous. And no, it DOESN'T just do phone calls > (making attempts to model proxy load based on telephone switch metrics > hopelessly bogus). > > So my humble suggestion: Get over it. Iron out any kruft that makes SIP less > desirable as a transport protocol (like UDP), and get on with the business > of making stuff that people can use to get their jobs done. Stop complaining > that your proxies are getting loaded down by serving a useful purpose to > somebody, and start understanding what that purpose is and how to charge for > it. > > If you don't like it, fine. Let's take out a poll on deprecating REGISTER, > MESSAGE, SUBSCRIBE, INFO, PRACK, SUBSCRIBE, NOTIFY, and all that other > stuff. > > Or hey, just toss it all out and add session negotiation to XMPP. > > -- > Dean > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 3 18:16:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21456 for ; Fri, 3 Jan 2003 18:16:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03NPBh00650 for sip-archive@odin.ietf.org; Fri, 3 Jan 2003 18:25:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03NLQJ00454; Fri, 3 Jan 2003 18:21:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03NK6J00374 for ; Fri, 3 Jan 2003 18:20:06 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21377 for ; Fri, 3 Jan 2003 18:10:37 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h03NDg8X002217; Fri, 3 Jan 2003 17:13:42 -0600 From: "Dean Willis" To: "'Neil Deason'" , "'Adam Roach'" Cc: Subject: RE: [Sip] INFO considered harmful Date: Fri, 3 Jan 2003 17:13:20 -0600 Message-ID: <004601c2b37d$b55dc320$73036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h03NK7J00375 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > What I was actually advocating here was ppl wanting to keep > INFO around write up something to illuminate INFO packages > and provide example usage. > > The MESSAGE cf INFO was just an attempt to highlight an > apparent limitation with the ban INFO approach. Every MIME > type in an INFO can be moved into MESSAGE rather than go > away. Maybe through exploring INFO packages we evolve the > collective understanding that this is/isn't a necessary thing. > > Cheers, > Neil. This is an excellent suggestion, and very similar to the one Jonathan made to me on the phone yesterday (actually, I think he more tersely worded it as "Send Text!") -- 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 mailnull@www1.ietf.org Fri Jan 3 18:17:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21479 for ; Fri, 3 Jan 2003 18:17:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03NQlT00717 for sip-archive@odin.ietf.org; Fri, 3 Jan 2003 18:26:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03NNEJ00590; Fri, 3 Jan 2003 18:23:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03NMBJ00502 for ; Fri, 3 Jan 2003 18:22:11 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21435 for ; Fri, 3 Jan 2003 18:12:42 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h03NFl8W002251; Fri, 3 Jan 2003 17:15:47 -0600 From: "Dean Willis" To: "'Jonathan Rosenberg'" Cc: Subject: RE: [Sip] INFO considered harmful Date: Fri, 3 Jan 2003 17:15:25 -0600 Message-ID: <004901c2b37d$ff8b2c30$73036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <3E10BF75.9030902@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h03NMBJ00503 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > The big huge difference I have been trying to point out is > that EVENTS > DEFINES SEMANTICS, whereas INFO doesn't. No, EVENTS doesn't define semantics. Event PACKAGES define the semantics of particular instances of the event methods. All that 3265 gives us is subscription to and notification of otherwise undefined blobs, and a framework for defining event packages. It is up to a specific event package to define a specific blob, including how it is named, how it is encoded, and what it means. And one of the interesting things is that 3265 and sipchange establishes a lower threshold-of-review over event packages (which are NOT considered protocol extensions) than for new SIP methods (which obviously ARE protocol extensions). INFO also needs a blob-describing-and-encoding framework, so that the various uses of INFO can, as appropriate, be effectively documented and negotiated. -- 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 mailnull@www1.ietf.org Fri Jan 3 18:21:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21549 for ; Fri, 3 Jan 2003 18:21:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03NUtS00887 for sip-archive@odin.ietf.org; Fri, 3 Jan 2003 18:30:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03NRJJ00764; Fri, 3 Jan 2003 18:27:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03NQJJ00697 for ; Fri, 3 Jan 2003 18:26:19 -0500 Received: from dgesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21472 for ; Fri, 3 Jan 2003 18:16:49 -0500 (EST) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0H8500F23VEJYB@firewall.wcom.com> for sip@ietf.org; Fri, 03 Jan 2003 23:18:19 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H8500K01VE5EL@dgismtp02.wcomnet.com>; Fri, 03 Jan 2003 23:18:19 +0000 (GMT) Received: from hsinnreich2 ([166.50.97.223]) by dgismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H8500IE2VEDDJ@dgismtp02.wcomnet.com>; Fri, 03 Jan 2003 23:18:14 +0000 (GMT) Date: Fri, 03 Jan 2003 17:18:13 -0600 From: Henry Sinnreich Subject: RE: [Sip] INFO considered harmful In-reply-to: <3E15B862.6090201@dynamicsoft.com> To: "'Jonathan Rosenberg'" , "'David R. Oran'" Cc: "'Michael Thomas'" , "'Adam Roach'" , "'George Foti (LMC)'" , "'Eric Burger'" , "'Dean Willis'" , sip@ietf.org Message-id: <000601c2b37e$6436f650$1002a8c0@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1097 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >would make a nice I-D I think. This whole discussion would make a very USEFUL I-D. Anyone contemplating to do the work? Thanks, Henry > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Jonathan Rosenberg > Sent: Friday, January 03, 2003 10:21 AM > To: David R. Oran > Cc: Michael Thomas; Adam Roach; 'George Foti (LMC)'; Eric > Burger; Dean Willis; sip@ietf.org > Subject: Re: [Sip] INFO considered harmful > > > > > David R. Oran wrote: > > I have nothing substantive to contribute to this > discussion, except to > > observe that among my silly "Oran's laws of protocols", > about five years > > ago I coined the following law: > > > > "any application protocol which works sufficiently well to be widely > > deployed eventually gets hijacked and used as a transport protocol" > > Definitely true. > > Please do enumerate the others... would make a nice I-D I think. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 3 19:04:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22011 for ; Fri, 3 Jan 2003 19:04:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h040DnZ03387 for sip-archive@odin.ietf.org; Fri, 3 Jan 2003 19:13:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0409tJ03269; Fri, 3 Jan 2003 19:09:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0408hJ03237 for ; Fri, 3 Jan 2003 19:08:43 -0500 Received: from face.sentitonetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21941 for ; Fri, 3 Jan 2003 18:59:13 -0500 (EST) Received: (qmail 81113 invoked from network); 4 Jan 2003 00:02:25 -0000 Received: from unknown (HELO overhill) (10.0.0.159) by face.sentito.com with SMTP; 4 Jan 2003 00:02:25 -0000 Message-ID: <008901c2b384$90122b40$9f00000a@overhill> From: "Frank W. Miller" To: "Dean Willis" Cc: References: <004601c2b37d$b55dc320$73036e3f@txdwillis> Subject: Re: [Sip] INFO considered harmful Date: Fri, 3 Jan 2003 19:02:24 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Well, any illusion of reasonableness I may have garnered in the past is about to be shattered. I would refer folks to: http://www.ietf.org/internet-drafts/draft-miller-sip-isup-annex-00.txt This draft is about to receive a major -01 update that recodes the entire syntax in XML. In addition, we (I) have another draft that does something very similar for ANSI TCAP that I'll be submitting in short order. I guess its only appropriate that I bring peoples attention to these drafts under the current subject heading... FM Frank W. Miller, Ph.D. Chief Technical Officer sentitO Networks, Inc. fmiller@sentito.com ----- Original Message ----- From: "Dean Willis" To: "'Neil Deason'" ; "'Adam Roach'" Cc: Sent: Friday, January 03, 2003 6:13 PM Subject: RE: [Sip] INFO considered harmful > > What I was actually advocating here was ppl wanting to keep > > INFO around write up something to illuminate INFO packages > > and provide example usage. > > > > The MESSAGE cf INFO was just an attempt to highlight an > > apparent limitation with the ban INFO approach. Every MIME > > type in an INFO can be moved into MESSAGE rather than go > > away. Maybe through exploring INFO packages we evolve the > > collective understanding that this is/isn't a necessary thing. > > > > Cheers, > > Neil. > > This is an excellent suggestion, and very similar to the one Jonathan made > to me on the phone yesterday (actually, I think he more tersely worded it as > "Send Text!") > > -- > 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 mailnull@www1.ietf.org Fri Jan 3 22:06:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24356 for ; Fri, 3 Jan 2003 22:06:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h043FUQ11617 for sip-archive@odin.ietf.org; Fri, 3 Jan 2003 22:15:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h043BYJ11515; Fri, 3 Jan 2003 22:11:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0439VJ11453 for ; Fri, 3 Jan 2003 22:09:31 -0500 Received: from mtiwmhc13.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24297 for ; Fri, 3 Jan 2003 21:59:57 -0500 (EST) Received: from cs.columbia.edu ([12.85.3.253]) by mtiwmhc13.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030104030309.OVGI20003.mtiwmhc13.worldnet.att.net@cs.columbia.edu>; Sat, 4 Jan 2003 03:03:09 +0000 Message-ID: <3E164E5C.50307@cs.columbia.edu> Date: Fri, 03 Jan 2003 22:00:44 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Eric Burger , sip@ietf.org Subject: Re: [Sip] INFO considered harmful References: <4A3384433CE2AB46A63468CB207E209D2DF635@zoe.office.snowshore.com> <3E15E302.80508@cs.columbia.edu> <3E160FE7.2000907@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'd imagine they do care when they talk to you since that's the cost element that they can control during that conversation. They probably also try to bargain hard with the copy paper people. Why would anybody buy extra servers for demand that isn't going to materialize for (say) months? Stocking up on servers isn't exactly the best return on investment - it's not like OPEC is going to raise their prices next year. I suspect that the major cost is not the hardware but the per-server software licenses :-) If you can get a service deployed today rather than waiting for a new protocol to be standardized and deployed, and if you're paying interest on your 3G license loan, I'd imagine that speed-to-working beats request counts. Since this is all hypotheticals, we can probably agree that server cost is just one of many factors. Deployability, system management complexity (more protocols=more MIBs), staff training and maturity of the alternatives and time-to-market all matter, but are hard to quantify. Jonathan Rosenberg wrote: > inline. > > Henning Schulzrinne wrote: > >> In general, I just don't buy server load arguments. If it's a useful >> service, server cost is usually the least of the problem. In any >> event, one should take this as a fraction of the existing signaling >> load, not as some absolute number. I'm worried about stuff that >> multiplies the signaling load by a factor of 10; I find 20 or 50% load >> increase uninteresting as an argument. > > > My firsthand experience with selling stuff to carriers is that this is > most definitely not the way they see it. Remember, the equipment > purchases are made up front before the service is activated. If you can > sell a carrier a solution that requires 50% or even 20% fewer boxes, > thats a big win. Its not just the equipment cost, its the management > cost too that increases with the box counts. > > -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 mailnull@www1.ietf.org Fri Jan 3 22:23:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24525 for ; Fri, 3 Jan 2003 22:23:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h043X3e12167 for sip-archive@odin.ietf.org; Fri, 3 Jan 2003 22:33:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h043THJ12043; Fri, 3 Jan 2003 22:29:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h043SoJ12008 for ; Fri, 3 Jan 2003 22:28:50 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24475 for ; Fri, 3 Jan 2003 22:19:15 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h043KxSK013948; Fri, 3 Jan 2003 22:21:00 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Jan 2003 21:22:21 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A643D1@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Henning Schulzrinne'" , Jonathan Rosenberg Cc: Eric Burger , sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Fri, 3 Jan 2003 21:22:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > system management complexity (more protocols=more MIBs)... Red herring alert. A kitchen-sink protocol will require a kitchen-sink MIB. You're not reducing management complexity by turning a single protocol into a Swiss army knife; you're just consolidating it. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 3 22:55:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24955 for ; Fri, 3 Jan 2003 22:55:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h04452E13886 for sip-archive@odin.ietf.org; Fri, 3 Jan 2003 23:05:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0441GJ13728; Fri, 3 Jan 2003 23:01:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0440DJ13663 for ; Fri, 3 Jan 2003 23:00:13 -0500 Received: from mtiwmhc11.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24902 for ; Fri, 3 Jan 2003 22:50:37 -0500 (EST) Received: from cs.columbia.edu ([12.85.3.253]) by mtiwmhc11.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030104035350.ZFWV9286.mtiwmhc11.worldnet.att.net@cs.columbia.edu>; Sat, 4 Jan 2003 03:53:50 +0000 Message-ID: <3E165A3D.90004@cs.columbia.edu> Date: Fri, 03 Jan 2003 22:51:25 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: Jonathan Rosenberg , Eric Burger , sip@ietf.org Subject: Re: [Sip] INFO considered harmful References: <9BF66EBF6BEFD942915B4D4D45C051F3A643D1@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit If there's no common functionality, I agree. If the non-INFO, non-SIP mechanism needs to replicate parts of the SIP functionality, such as request routing or proxies, you do end up with extra effort. Adam Roach wrote: >>-----Original Message----- >>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> >>system management complexity (more protocols=more MIBs)... > > > Red herring alert. A kitchen-sink protocol will require > a kitchen-sink MIB. You're not reducing management > complexity by turning a single protocol into a Swiss > army knife; you're just consolidating it. > > /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Sat Jan 4 15:17:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15408 for ; Sat, 4 Jan 2003 15:17:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h04KQZ905861 for sip-archive@odin.ietf.org; Sat, 4 Jan 2003 15:26:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04KMgJ05725; Sat, 4 Jan 2003 15:22:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h04KFDJ05529 for ; Sat, 4 Jan 2003 15:15:13 -0500 Received: from pmesmtp01.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15251 for ; Sat, 4 Jan 2003 15:05:18 -0500 (EST) Received: from dgismtp05.wcomnet.com ([166.38.58.88]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0H8700K9WHA7R8@firewall.wcom.com> for sip@ietf.org; Sat, 04 Jan 2003 20:08:31 +0000 (GMT) Received: from dgismtp05.wcomnet.com by dgismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H8700I01HA6GK@dgismtp05.wcomnet.com>; Sat, 04 Jan 2003 20:08:30 +0000 (GMT) Received: from hsinnreich2 ([166.50.112.64]) by dgismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H8700H3THA5S3@dgismtp05.wcomnet.com>; Sat, 04 Jan 2003 20:08:30 +0000 (GMT) Date: Sat, 04 Jan 2003 14:08:29 -0600 From: Henry Sinnreich Subject: RE: [Sip] INFO considered harmful In-reply-to: <3E164E5C.50307@cs.columbia.edu> To: "'Henning Schulzrinne'" , "'Jonathan Rosenberg'" Cc: "'Eric Burger'" , sip@ietf.org Message-id: <000301c2b42d$0d07acd0$407032a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1097 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The server hardware cost is probably the least to worry about, rather it is as mentioned here: >Deployability, system management, complexity > (more protocols=more MIBs), staff training and maturity of the > alternatives and time-to-market. Signaling load is also not too much a problem, if not excessive. I would rather worry about servers with geographic diversity and the most effective DNS schema for fast response. My two cents, Henry > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Henning Schulzrinne > Sent: Friday, January 03, 2003 9:01 PM > To: Jonathan Rosenberg > Cc: Eric Burger; sip@ietf.org > Subject: Re: [Sip] INFO considered harmful > > > I'd imagine they do care when they talk to you since that's the cost > element that they can control during that conversation. They probably > also try to bargain hard with the copy paper people. > > Why would anybody buy extra servers for demand that isn't going to > materialize for (say) months? Stocking up on servers isn't > exactly the > best return on investment - it's not like OPEC is going to > raise their > prices next year. I suspect that the major cost is not the > hardware but > the per-server software licenses :-) > > If you can get a service deployed today rather than waiting for a new > protocol to be standardized and deployed, and if you're > paying interest > on your 3G license loan, I'd imagine that speed-to-working > beats request > counts. > > Since this is all hypotheticals, we can probably agree that > server cost > is just one of many factors. Deployability, system management > complexity > (more protocols=more MIBs), staff training and maturity of the > alternatives and time-to-market all matter, but are hard to quantify. > > Jonathan Rosenberg wrote: > > inline. > > > > Henning Schulzrinne wrote: > > > >> In general, I just don't buy server load arguments. If > it's a useful > >> service, server cost is usually the least of the problem. In any > >> event, one should take this as a fraction of the existing > signaling > >> load, not as some absolute number. I'm worried about stuff that > >> multiplies the signaling load by a factor of 10; I find 20 > or 50% load > >> increase uninteresting as an argument. > > > > > > My firsthand experience with selling stuff to carriers is > that this is > > most definitely not the way they see it. Remember, the equipment > > purchases are made up front before the service is > activated. If you can > > sell a carrier a solution that requires 50% or even 20% > fewer boxes, > > thats a big win. Its not just the equipment cost, its the > management > > cost too that increases with the box counts. > > > > -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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Sun Jan 5 00:07:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20503 for ; Sun, 5 Jan 2003 00:07:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h055HAk28947 for sip-archive@odin.ietf.org; Sun, 5 Jan 2003 00:17:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h055DNJ28792; Sun, 5 Jan 2003 00:13:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0558UJ28680 for ; Sun, 5 Jan 2003 00:08:30 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20233 for ; Sat, 4 Jan 2003 23:58:23 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id h0551cfm002742; Sat, 4 Jan 2003 21:01:42 -0800 (PST) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id HIH00095; Sat, 4 Jan 2003 21:02:04 -0800 (PST) From: "Cullen Jennings" To: , Date: Sat, 4 Jan 2003 21:06:07 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Anohter possible slution for draft-shenoy-sip-via-validation Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I doubt that doing this will help reduce DDOS or DOS attacks. For example consider a request with a pre loaded route. There's lots more. Anyways, on a more useful note ... I'm suspect that we can accomplish what you are suggesting without any protocol changes. Imagine your scheme would create a VIA that looks like: Via: SIP/2.0/UDP foo.com:5060;branch=1234;cookie=abcd Instead just create a branch that has the cookie embedded in it. It would look like: Via: SIP/2.0/UDP foo.com:5060;branch=1234-abcd This trick is being used by proxies to embed other state that they might want to get back later. You should have a look at HMAC. Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Sun Jan 5 09:05:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05479 for ; Sun, 5 Jan 2003 09:05:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h05EFZI01951 for sip-archive@odin.ietf.org; Sun, 5 Jan 2003 09:15:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h05EBkJ01777; Sun, 5 Jan 2003 09:11:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h05E4pJ00970 for ; Sun, 5 Jan 2003 09:04:51 -0500 Received: from gorilla.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05357 for ; Sun, 5 Jan 2003 08:54:34 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id OAA28488; Sun, 5 Jan 2003 14:57:42 +0100 (MET) Received: from siemens.com ([149.246.220.8]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id OAA20892; Sun, 5 Jan 2003 14:57:42 +0100 (MET) Message-ID: <3E183A16.8070302@siemens.com> Date: Sun, 05 Jan 2003 14:58:46 +0100 From: Peter =?UTF-8?B?UMOkcHBpbmdoYXVz?= Organization: Siemens AG User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en,de MIME-Version: 1.0 To: Jonathan Rosenberg CC: hisham.khartabil@nokia.com, sip@ietf.org Subject: Re: Repost: [Sip] Buggy example in RFC 3261 References: <2038BCC78B1AD641891A0D1AE133DBB7FE70A3@esebe019.ntc.nokia.com> <3E152EFF.8080105@dynamicsoft.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Two more remarks inline. Jonathan Rosenberg wrote: > Well, a decision needs to be made one way or another. Since its already > in 3261, I would propose that we declare the example as buggy, and go > with the existing normative text, even though it works differently than > for requests. > > -Jonathan R. > > hisham.khartabil@nokia.com wrote: > >> This is an extract from a discussion I had with Robert Sparks: >> >> >>>> Yes, that was exactly what I asked. If its not so, what does an Expires >>>> header in a 200 OK for a REGISTER mean? >>> >>> >>> >>> As I note above, with the current text an Expire header field has no >>> meaning >>> if it appears in a 200 response to a REGISTER request. This remark is not in line with the following text from RFC 3261, section 10.2.4 Refreshing Bindings: "The 200 (OK) response from the registrar contains a list of Contact fields enumerating all current bindings. The UA compares each contact address to see if it created the contact address, using comparison rules in Section 19.1.4. If so, it updates the expiration time interval according to the expires parameter or, if absent, the Expires field value." This clearly gives a meaning to the Expire header field in 200 for REGISTER. >> >> http://www.ietf.org/mail-archive/working-groups/sip/current/msg03602.html >> >> Regards, >> Hisham >> >> >>> -----Original Message----- >>> From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>> Sent: Thursday, January 02, 2003 7:01 AM >>> To: Peter Päppinghaus >>> Cc: sip@ietf.org >>> Subject: Re: Repost: [Sip] Buggy example in RFC 3261 >>> >>> >>> Sorry for not responding. I did notice this. There is an error here, >>> as you point out. What is NOT clear is whether the error is in the >>> example, or in the normative text. For REGISTER requests, you can use >>> either the Expires header field or the expires contact header field >>> parameter. It seems odd that this same rule would not apply to >>> REGISTER responses. My personal recollection was that either the To me this asymmetry between REGISTER and its 200 responses does not seem so odd. On the one hand it is very likely that a UA registering a set of contact addresses in one REGISTER would suggest the same expiration interval for all of them. On the other hand the 200 for such a REGISTER is required to list all current bindings, and there is no reason why the bindings should all have the same expiration time. >>> Expires header field or the expires contact param was OK for either >>> request or response. This doesn't match the normative text though. >>> >>> Does anyone use the Expires header field and NOT the expires contact >>> param in REGISTER responses? >>> >>> -Jonathan R. >>> >>> Peter Päppinghaus wrote: >>> >>>> I have posted this earlier, but it seems to have gone >>>> unnoticed. >>>> >>>> Hi, >>>> >>>> I believe to have stumbled on a buggy example in RFC 3261. >>>> >>>> The 200 OK in the REGISTER example of RFC 3261, sec. 24.1 contains >>>> an Expires header, but no expires parameter in the Contact header. >>>> >>>> This violates RFC 3261, sec. 10.3, bullet 8: >>>> "Each Contact value MUST feature an "expires" parameter >>>> indicating its expiration interval chosen by the registrar." >>>> >>>> Regards, >>>> >>>> Peter Paeppinghaus >>>> >>> >>> -- >>> Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >>> Chief Scientist First Floor >>> dynamicsoft East Hanover, NJ 07936 >>> jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>> http://www.jdrosen.net PHONE: (973) 952-5000 >>> http://www.dynamicsoft.com -- Dr. Peter Päppinghaus Siemens AG | Phone: +49 89 - 722 40065 ICM N PG U ID A1 | Fax: +49 89 - 722 58726 Hofmannstr. 51 | Visitors: Building 1713 / Room 714 D - 81359 München | Email: peter.paeppinghaus@siemens.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Sun Jan 5 09:22:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05589 for ; Sun, 5 Jan 2003 09:22:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h05EWFv02252 for sip-archive@odin.ietf.org; Sun, 5 Jan 2003 09:32:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h05ESTJ02168; Sun, 5 Jan 2003 09:28:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h05ENXJ02092 for ; Sun, 5 Jan 2003 09:23:33 -0500 Received: from nt-mail.RADVISION.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05550 for ; Sun, 5 Jan 2003 09:13:15 -0500 (EST) Received: by nt-mail.tlv.radvision.com with Internet Mail Service (5.5.2653.19) id ; Sun, 5 Jan 2003 16:15:51 +0200 Message-ID: From: Sarit Galanos Mekler To: sip@ietf.org Date: Sun, 5 Jan 2003 16:15:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Subject: [Sip] Terminating BYE transaction when the session is terminated. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, If a UA receives BYE and respond with 200, should he keep the BYE transaction alive according to timer J or can he terminate the transaction and respond with 481 to BYE retransmissions? Thanks, Sarit. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Sun Jan 5 12:34:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08506 for ; Sun, 5 Jan 2003 12:34:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h05HibN11480 for sip-archive@odin.ietf.org; Sun, 5 Jan 2003 12:44:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h05HebJ11391; Sun, 5 Jan 2003 12:40:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h05HYjJ10611 for ; Sun, 5 Jan 2003 12:34:45 -0500 Received: from tomts12-srv.bellnexxia.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08391 for ; Sun, 5 Jan 2003 12:24:23 -0500 (EST) Received: from comp1 ([206.172.131.176]) by tomts12-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20030105172735.UUQP26669.tomts12-srv.bellnexxia.net@comp1>; Sun, 5 Jan 2003 12:27:35 -0500 Message-ID: <000501c2b4f9$d459b360$0200a8c0@comp1> From: "T A Gray" To: , "TA Gray" References: <20030105170000.8967.56963.Mailman@www1.ietf.org> Subject: RE: [Sip] INFO considered harmful Date: Sun, 5 Jan 2003 12:34:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit If the provider could charge per INFO message, would this not put an entirely new light on this discussion. Isn't that the real significance of SMS rather than the load it puts on the signalling servers. Tom Gray Pinetel > Date: Sat, 04 Jan 2003 14:08:29 -0600 > From: Henry Sinnreich > Subject: RE: [Sip] INFO considered harmful > To: "'Henning Schulzrinne'" , > "'Jonathan Rosenberg'" > Cc: "'Eric Burger'" , sip@ietf.org > Organization: WorldCom, Inc. > > The server hardware cost is probably the least to worry about, rather it > is as mentioned here: > > >Deployability, system management, complexity > > (more protocols=more MIBs), staff training and maturity of the > > alternatives and time-to-market. > > Signaling load is also not too much a problem, if not excessive. I would > rather worry about servers with geographic diversity and the most > effective DNS schema for fast response. > > My two cents, Henry > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > > Behalf Of Henning Schulzrinne > > Sent: Friday, January 03, 2003 9:01 PM > > To: Jonathan Rosenberg > > Cc: Eric Burger; sip@ietf.org > > Subject: Re: [Sip] INFO considered harmful > > > > > > I'd imagine they do care when they talk to you since that's the cost > > element that they can control during that conversation. They probably > > also try to bargain hard with the copy paper people. > > > > Why would anybody buy extra servers for demand that isn't going to > > materialize for (say) months? Stocking up on servers isn't > > exactly the > > best return on investment - it's not like OPEC is going to > > raise their > > prices next year. I suspect that the major cost is not the > > hardware but > > the per-server software licenses :-) > > > > If you can get a service deployed today rather than waiting for a new > > protocol to be standardized and deployed, and if you're > > paying interest > > on your 3G license loan, I'd imagine that speed-to-working > > beats request > > counts. > > > > Since this is all hypotheticals, we can probably agree that > > server cost > > is just one of many factors. Deployability, system management > > complexity > > (more protocols=more MIBs), staff training and maturity of the > > alternatives and time-to-market all matter, but are hard to quantify. > > > > Jonathan Rosenberg wrote: > > > inline. > > > > > > Henning Schulzrinne wrote: > > > > > >> In general, I just don't buy server load arguments. If > > it's a useful > > >> service, server cost is usually the least of the problem. In any > > >> event, one should take this as a fraction of the existing > > signaling > > >> load, not as some absolute number. I'm worried about stuff that > > >> multiplies the signaling load by a factor of 10; I find 20 > > or 50% load > > >> increase uninteresting as an argument. > > > > > > > > > My firsthand experience with selling stuff to carriers is > > that this is > > > most definitely not the way they see it. Remember, the equipment > > > purchases are made up front before the service is > > activated. If you can > > > sell a carrier a solution that requires 50% or even 20% > > fewer boxes, > > > thats a big win. Its not just the equipment cost, its the > > management > > > cost too that increases with the box counts. > > > > > > -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 > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Sun Jan 5 12:50:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08642 for ; Sun, 5 Jan 2003 12:50:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h05I0Yl11869 for sip-archive@odin.ietf.org; Sun, 5 Jan 2003 13:00:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h05HuSJ11707; Sun, 5 Jan 2003 12:56:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h05HpcJ11617 for ; Sun, 5 Jan 2003 12:51:38 -0500 Received: from hclnpd.hclt.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08565 for ; Sun, 5 Jan 2003 12:41:15 -0500 (EST) Received: from blaze.hcltech.com (blaze.hclt-ntl.co.in [192.168.19.30]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y1WD2T67; Sun, 5 Jan 2003 23:15:21 +0530 Received: from sachinhome ([192.168.19.43]) by blaze.hcltech.com (8.9.3/8.9.3) with SMTP id XAA21157; Sun, 5 Jan 2003 23:14:52 +0530 Message-ID: <000001c2b4e3$fca45840$a5f1fea9@sachinhome> From: "Sachin Shenoy" To: "Cullen Jennings" Cc: References: Subject: Re: [Sip] Anohter possible slution for draft-shenoy-sip-via-validation Date: Sun, 5 Jan 2003 23:25:11 +0530 Organization: HCL Technologies MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Cullen, Thanks for you comments. Please find my comments inline. > I doubt that doing this will help reduce DDOS or DOS attacks. For example > consider a request with a pre loaded route. There's lots more. Anyways, on a > more useful note ... Requests with pre-loaded route set can be authenticated at proxies. This, I think, can ward off DDoS attack using tailor made route set. For requests there are mechanisms to authenticate and validate it. But in the case of responses, it seems that, there is no way in which proxies can authenticate or validate it. The mechanism given in the draft try to provide one. > I'm suspect that we can accomplish what you are suggesting without any > protocol changes. Imagine your scheme would create a VIA that looks like: > Via: SIP/2.0/UDP foo.com:5060;branch=1234;cookie=abcd > > Instead just create a branch that has the cookie embedded in it. It would > look like: > Via: SIP/2.0/UDP foo.com:5060;branch=1234-abcd I had reservations in reusing the branch parameter. That is why I thought a new paramter would serve better. Having this parameter should not require any change in protocol as such. As far as I know Proxies and UAs are supposed to keep the Via's intact (i.e. they are not supposed to remove any parameters from it), so this cookie parameter would be retained when the response reaches proxy. > This trick is being used by proxies to embed other state that they might > want to get back later. You should have a look at HMAC. I will do that. Thanks again. Sachin _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Sun Jan 5 13:15:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08903 for ; Sun, 5 Jan 2003 13:15:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h05IPDC13032 for sip-archive@odin.ietf.org; Sun, 5 Jan 2003 13:25:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h05ILOJ12905; Sun, 5 Jan 2003 13:21:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h05ID4J12720 for ; Sun, 5 Jan 2003 13:13:04 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08750 for ; Sun, 5 Jan 2003 13:02:41 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 18VF9n-00066W-00; Sun, 05 Jan 2003 20:05:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15896.29698.930237.88735@harjus.eng.song.fi> Date: Sun, 5 Jan 2003 20:05:54 +0200 To: "T A Gray" Cc: Subject: RE: [Sip] INFO considered harmful In-Reply-To: <000501c2b4f9$d459b360$0200a8c0@comp1> References: <20030105170000.8967.56963.Mailman@www1.ietf.org> <000501c2b4f9$d459b360$0200a8c0@comp1> X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit T A Gray writes: > If the provider could charge per INFO message, would this not put an > entirely new light on this discussion. Isn't that the real significance of > SMS rather than the load it puts on the signalling servers. it doesn't make much sense for providers to start charging per info message, because sip works fine without any provider. sms is different, because there is no way for me to send an sms message from a gsm phone without using the provider's sms service. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Sun Jan 5 13:20:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08983 for ; Sun, 5 Jan 2003 13:20:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h05ITvD13202 for sip-archive@odin.ietf.org; Sun, 5 Jan 2003 13:29:57 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h05IQMJ13082; Sun, 5 Jan 2003 13:26:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h05IKsJ12894 for ; Sun, 5 Jan 2003 13:20:54 -0500 Received: from tomts22-srv.bellnexxia.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08775 for ; Sun, 5 Jan 2003 13:10:31 -0500 (EST) Received: from comp1 ([206.172.131.176]) by tomts22-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20030105181345.ZOBI7938.tomts22-srv.bellnexxia.net@comp1>; Sun, 5 Jan 2003 13:13:45 -0500 Message-ID: <004e01c2b500$468bf500$0200a8c0@comp1> From: "T A Gray" To: Cc: References: <20030105170000.8967.56963.Mailman@www1.ietf.org><000501c2b4f9$d459b360$0200a8c0@comp1> <15896.29698.930237.88735@harjus.eng.song.fi> Subject: Re: [Sip] INFO considered harmful Date: Sun, 5 Jan 2003 13:20:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Most people will have to have a proxy agent that will take care of this concern. However your point is a very valid one in eh argument about the load on signalling servers. ----- Original Message ----- From: To: T A Gray Cc: Sent: Sunday, January 05, 2003 10:05 AM Subject: RE: [Sip] INFO considered harmful > T A Gray writes: > > > If the provider could charge per INFO message, would this not put an > > entirely new light on this discussion. Isn't that the real significance of > > SMS rather than the load it puts on the signalling servers. > > it doesn't make much sense for providers to start charging per info > message, because sip works fine without any provider. sms is different, > because there is no way for me to send an sms message from a gsm phone > without using the provider's sms service. > > -- juha > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Sun Jan 5 13:33:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09115 for ; Sun, 5 Jan 2003 13:33:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h05IhLB14194 for sip-archive@odin.ietf.org; Sun, 5 Jan 2003 13:43:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h05IdSJ14065; Sun, 5 Jan 2003 13:39:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h05IYQJ13324 for ; Sun, 5 Jan 2003 13:34:26 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09020 for ; Sun, 5 Jan 2003 13:24:05 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 18VFUS-00068S-00; Sun, 05 Jan 2003 20:27:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15896.30980.465859.70319@harjus.eng.song.fi> Date: Sun, 5 Jan 2003 20:27:16 +0200 To: "T A Gray" Cc: Subject: Re: [Sip] INFO considered harmful In-Reply-To: <004e01c2b500$468bf500$0200a8c0@comp1> References: <20030105170000.8967.56963.Mailman@www1.ietf.org> <000501c2b4f9$d459b360$0200a8c0@comp1> <15896.29698.930237.88735@harjus.eng.song.fi> <004e01c2b500$468bf500$0200a8c0@comp1> X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit T A Gray writes: > Most people will have to have a proxy agent that will take care of this > concern. However your point is a very valid one in eh argument about the > load on signalling servers. sure, similarly most people have an email server somewhere, but very few actually pay per sent or received email message. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Sun Jan 5 21:32:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13836 for ; Sun, 5 Jan 2003 21:32:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h062gfS03518 for sip-archive@odin.ietf.org; Sun, 5 Jan 2003 21:42:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h062cfJ03385; Sun, 5 Jan 2003 21:38:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h062ZfJ02677 for ; Sun, 5 Jan 2003 21:35:41 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13763 for ; Sun, 5 Jan 2003 21:25:10 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.11]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h062SMYH025527; Sun, 5 Jan 2003 21:28:22 -0500 (EST) Message-ID: <3E18E9C4.5030405@dynamicsoft.com> Date: Sun, 05 Jan 2003 21:28:21 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: sip@ietf.org Subject: Re: [Sip] INFO considered harmful References: <004901c2b37d$ff8b2c30$73036e3f@txdwillis> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dean Willis wrote: >>The big huge difference I have been trying to point out is >>that EVENTS >>DEFINES SEMANTICS, whereas INFO doesn't. > > > No, EVENTS doesn't define semantics. Of course it does. There are lots of MAYS, MUSTS and SHOULDs in there. There is behavior dealing with subscription refreshes, rules on when to send NOTIFY, and so on and so on. How can you say that none of those qualify as semantics? > Event PACKAGES define the semantics of > particular instances of the event methods. Within a well defined framework. 3265 defines clear rules on what each package has to specify, and what it can and cannot due ontop of rfc3265. > INFO also needs a blob-describing-and-encoding framework, so that the > various uses of INFO can, as appropriate, be effectively documented and > negotiated. Well, I'll try one more time, since I am clearly not getting my point across. RFC3265 defines semantics above and beyond RFC3261. All of those MAY/MUST/SHOULD I was talking about. If you had a choice between defining a new package, and defining your own sub/not mechanisms, it would be a LOT more work to define your own sub/not mechanisms. Not so for INFO. WHen deciding whether to specify an INFO usage, or a new method, there is no additional work to do (specification-wise) when specifying a new method as opposed to a new INFO usage. To me, that means that INFO is devoid of semantics. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Sun Jan 5 21:48:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13992 for ; Sun, 5 Jan 2003 21:48:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h062w8u03948 for sip-archive@odin.ietf.org; Sun, 5 Jan 2003 21:58:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h062sIJ03799; Sun, 5 Jan 2003 21:54:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h062ruJ03781 for ; Sun, 5 Jan 2003 21:53:56 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13962 for ; Sun, 5 Jan 2003 21:43:24 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.11]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h062kdYH025537; Sun, 5 Jan 2003 21:46:40 -0500 (EST) Message-ID: <3E18EE0E.1070700@dynamicsoft.com> Date: Sun, 05 Jan 2003 21:46:38 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?UTF-8?B?UGV0ZXIgUMOkcHBpbmdoYXVz?= CC: hisham.khartabil@nokia.com, sip@ietf.org Subject: Re: Repost: [Sip] Buggy example in RFC 3261 References: <2038BCC78B1AD641891A0D1AE133DBB7FE70A3@esebe019.ntc.nokia.com> <3E152EFF.8080105@dynamicsoft.com> <3E183A16.8070302@siemens.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit inline. Peter Päppinghaus wrote: > Two more remarks inline. > > Jonathan Rosenberg wrote: > >> Well, a decision needs to be made one way or another. Since its >> already in 3261, I would propose that we declare the example as buggy, >> and go with the existing normative text, even though it works >> differently than for requests. >> >> -Jonathan R. >> >> hisham.khartabil@nokia.com wrote: >> >>> This is an extract from a discussion I had with Robert Sparks: >>> >>> >>>>> Yes, that was exactly what I asked. If its not so, what does an >>>>> Expires >>>>> header in a 200 OK for a REGISTER mean? >>>> >>>> >>>> >>>> >>>> As I note above, with the current text an Expire header field has no >>>> meaning >>>> if it appears in a 200 response to a REGISTER request. >>> > > > This remark is not in line with the following text from RFC 3261, > section 10.2.4 Refreshing Bindings: > "The 200 (OK) response from the registrar contains a list of Contact > fields enumerating all current bindings. The UA compares each > contact address to see if it created the contact address, using > comparison rules in Section 19.1.4. If so, it updates the expiration > time interval according to the expires parameter or, if absent, the > Expires field value." > > This clearly gives a meaning to the Expire header field in > 200 for REGISTER. Yes, another inconsistency here. > > >>> >>> http://www.ietf.org/mail-archive/working-groups/sip/current/msg03602.html >>> >>> >>> Regards, >>> Hisham >>> >>> >>>> -----Original Message----- >>>> From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>>> Sent: Thursday, January 02, 2003 7:01 AM >>>> To: Peter Päppinghaus >>>> Cc: sip@ietf.org >>>> Subject: Re: Repost: [Sip] Buggy example in RFC 3261 >>>> >>>> >>>> Sorry for not responding. I did notice this. There is an error here, >>>> as you point out. What is NOT clear is whether the error is in the >>>> example, or in the normative text. For REGISTER requests, you can >>>> use either the Expires header field or the expires contact header >>>> field parameter. It seems odd that this same rule would not apply to >>>> REGISTER responses. My personal recollection was that either the >>> > > To me this asymmetry between REGISTER and its 200 responses does not > seem so odd. On the one hand it is very likely that a UA registering > a set of contact addresses in one REGISTER would suggest the same > expiration interval for all of them. On the other hand the 200 for > such a REGISTER is required to list all current bindings, and there > is no reason why the bindings should all have the same expiration > time. True enough, but the same processing would still work in either case. Anyway, I would still propose to follow my suggestion and go with the normative text in bullet 8 of 10.3. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Sun Jan 5 21:48:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14006 for ; Sun, 5 Jan 2003 21:48:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h062wqu03983 for sip-archive@odin.ietf.org; Sun, 5 Jan 2003 21:58:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h062t8J03843; Sun, 5 Jan 2003 21:55:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h062scJ03808 for ; Sun, 5 Jan 2003 21:54:38 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13966 for ; Sun, 5 Jan 2003 21:44:06 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.11]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h062diYH025531; Sun, 5 Jan 2003 21:39:45 -0500 (EST) Message-ID: <3E18EC6F.2020603@dynamicsoft.com> Date: Sun, 05 Jan 2003 21:39:43 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sachin Shenoy CC: Cullen Jennings , sip@ietf.org Subject: Re: [Sip] Anohter possible slution for draft-shenoy-sip-via-validation References: <000001c2b4e3$fca45840$a5f1fea9@sachinhome> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Sachin Shenoy wrote: > Hi Cullen, > > Thanks for you comments. Please find my comments inline. > > >>I doubt that doing this will help reduce DDOS or DOS attacks. For example >>consider a request with a pre loaded route. There's lots more. Anyways, on >> a more useful note ... > > > Requests with pre-loaded route set can be authenticated at proxies. > This, I think, can ward off DDoS attack using tailor made route set. The responses can be validated too, if you choose to use the security mechanisms specified in SIP. SPecifically, TLS connections between proxies would prevent the attack you describe. DOn't get me wrong, I think what you have proposed is generally a fine idea and I suspect is something people may already be doing. As cullen said, it can be done without standardization. Indeed, you could even use a new Via parameter for this, and it would interoperate, since it does not require processing by any element but the one which inserted it. In that regard, its very similar in concept to my predictive nonce idea: http://www.jdrosen.net/papers/draft-rosenberg-sip-http-pnonce-00.txt for which we also decided not to standardize - there was no need. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Sun Jan 5 21:57:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14159 for ; Sun, 5 Jan 2003 21:57:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0637wf04949 for sip-archive@odin.ietf.org; Sun, 5 Jan 2003 22:07:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0634JJ04227; Sun, 5 Jan 2003 22:04:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0633IJ04192 for ; Sun, 5 Jan 2003 22:03:18 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14103 for ; Sun, 5 Jan 2003 21:52:46 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.11]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h062u1YH025541; Sun, 5 Jan 2003 21:56:02 -0500 (EST) Message-ID: <3E18F040.2000302@dynamicsoft.com> Date: Sun, 05 Jan 2003 21:56:00 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: loretosa@vizzavi.it CC: sip@ietf.org, Antonio.FERRIERI@vodafoneomnitel.it Subject: Re: [SIP] INFO Contact References: <47b301c2a9ca$1f05ffd0$5cde010a@omnitel.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Correction inline. loretosa@vizzavi.it wrote: > Hi Antonio, > > in a REGISTER message, > > the "To" Header Field contains the address of Record whose > registration it to be created. > > The "Contact" Field MAY be present in REGISTER REQUEST and it may > contain "zero or more values" containg address bindings. > > > If Contact Header is absent, the only contact address for the user is > the Address present in the "To" Header. No. If no Contact header field is present in a REGISTER request, the result is NO CHANGE on the current set of bindings. > > > What do you mean about the binding between IP address in VIA field > and the Request-URI? I'm not understand the question and what do you > mean. The Via header field is used to route responses only. It is not used to route inbound requests. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Jan 6 10:43:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05775 for ; Mon, 6 Jan 2003 10:43:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06Frma25450 for sip-archive@odin.ietf.org; Mon, 6 Jan 2003 10:53:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06FiDJ25049; Mon, 6 Jan 2003 10:44:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06FfCJ24939 for ; Mon, 6 Jan 2003 10:41:12 -0500 Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05532 for ; Mon, 6 Jan 2003 10:30:24 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Re: Restatement: INFO considered harmful Date: Mon, 6 Jan 2003 10:33:38 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D097BC8@zoe.office.snowshore.com> Thread-Topic: [Sip] Re: Restatement: INFO considered harmful Thread-Index: AcKzfE3opM2U+JXFSVqiVRrSNmto9wCGuqXQ From: "Eric Burger" To: "Jonathan Rosenberg" , "Dean Willis" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h06FfCJ24940 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I actually think the lines are that black and white. Said differently, we now have three years of experience with SIP. There's been a lot of pulling and stretching that has made the vision of a simple, text-based protocol for initiating multimedia sessions a lost dream. A serious question is, "Which has more pages, H.323 et. al. or RFC 3261 et. al.?". Reading Dean's posting, I was thinking, "It is time for SIP 3.0". For that matter, for marketing reasons, it would need a different name. A much simpler protocol that does one thing well (the IETF mantra) would NOT be backwards compatible with the bloat that we have today. I don't think there is a middle ground. To mix my metaphors, The line in the sand is being washed away by the tide of features. Now that we have brushed away the session initiation simplicity (e.g., REGISTER, MESSAGE, SUBSCRIBE, NOTIFY, INFO), I cannot see how one can, with a straight face, say, "My child is cute, but your child is ugly" [substitute method/body for child]. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, January 03, 2003 5:44 PM > To: Dean Willis > Cc: 'Adam Roach'; 'Frank W. Miller'; sip@ietf.org > Subject: [Sip] Re: Restatement: INFO considered harmful > > > Dean, > > The lines are not always so black and white. Its not a choice between > "do anything" and "do nothing but INVITE". There is a line somewhere > about what is a good use of sip, and what is not. We have some > documents, even, which help to identify that line (SIP > guidelines), and > no doubt it has moved over time. Indeed, there were even > arguments about > whether BYE belonged in SIP, since clearly its not needed for > "initiation". However, if you buy the assertion that SIP needs to at > least manage the session, that clearly includes termination > as well as > initiation. These days, I know of very few folks (only one in > fact) that > would argue against BYE as part of SIP. > > I still stand by my assertion that many of the usages of SIP INFO are > over that line, and that in order to keep the usages in a line we are > comfortable with, something has to be done. > > -Jonathan R. > > Dean Willis wrote: > > My mother said I should stop inflaming things, but here I > go again anyhow. > > Sorry, Mom. > > > > Adam said, responding to Frank in our long-winded exchange: > > > >>Perhaps using some sort of protocol to initate this session > >>would be appropriate. You'll also needs a protocol of some > >>sort to describe it, probably carried as a payload in this > >>session initation protocol. Ideally, this session description > >>protocol could leverage IANA-registered media types to > >>describe the content of such sessions, so that an infinite > >>number of types of sessions can be described. > > > > > > Actually, Adam and I just had a conversation about this > argument. I think > > actually that there is something hiding in here which is > THE HEART of almost > > every philosophical debate we've ever had in SIP. If we can > get this nailed > > down now, we'll be preventing a HUGE number of future fights. > > > > Or in short: Boom! Epiphany! I think I understand what > we're arguing about. > > > > I'll admit -- Adam's been philosophically consistent in his > arguments since > > day 1. He believes that SIP should start sessions, stop > sessions, and > > nothing else. > > > > Examples: > > > > Lets look at "events". By Adam's logic, the event system > should consist of > > sending an INVITE (instead of a SUBSCRIBE) to the event > source. The SDP body > > (Only SDP should be allowed in INVITE) would descibe the > events being > > requested and the protocol, IP address and port number on which the > > subscriber would be listening. The 200 OK response from the > event source > > would then contain the protocol, IP address and port number > to which the > > subscriber should send acknowledgements of notifications, > assuming that the > > notification-transport protocol (clearly, not SIP). > > > > And Whoa! Look at REGISTER. That doesn't set up any kind of > session! It's > > clearly not a SIP function. We should instead use an INVITE > to set up a > > "registration session", over which we would then use a > registration protocol > > to establish registrations. > > > > MESSAGE is clearly divergent. By Adam's logic, only message > sessions should > > be used. By similar reasoning, INFO is also off, and > instead SIP-T should > > use INVITE to establish a sigtran session. > > > > This actually all makes sense and hangs together philosophically. > > > > The problem is, the working group diverted from that > philosophy a long time > > ago. What we have now is a combination of three > transactional protocols > > (REGISTER, OPTIONS, MESSAGE) with a session-establishment > protocol (INVITE) > > which supports several in-session request verbs (UPDATE, > OPTIONS, ACK, INFO, > > MESSAGE, BYE, PRACK, etc.) and another > session-establishment protocol > > (SUBSCRIBE) which supports an in-session request verb > (NOTIFY). We've also > > defined an intermediation framework (the SIP Proxy) and a > set of end-to-end > > and hop-by-hop authentication and integrity protection > mechanisms that can > > be used for all these protocols. Really, it's the > intermediation framework > > that gives SIP most of its utility. > > > > Ok, it could be tidier. But it is very powerful, fairly > complete, and > > actually works. And yes, the combination effectively > provides a very useful > > transport protocol that does all sorts of things that HTTP > alone can't do, > > such as intermediated rendezvous. And no, it DOESN'T just > do phone calls > > (making attempts to model proxy load based on telephone > switch metrics > > hopelessly bogus). > > > > So my humble suggestion: Get over it. Iron out any kruft > that makes SIP less > > desirable as a transport protocol (like UDP), and get on > with the business > > of making stuff that people can use to get their jobs done. > Stop complaining > > that your proxies are getting loaded down by serving a > useful purpose to > > somebody, and start understanding what that purpose is and > how to charge for > > it. > > > > If you don't like it, fine. Let's take out a poll on > deprecating REGISTER, > > MESSAGE, SUBSCRIBE, INFO, PRACK, SUBSCRIBE, NOTIFY, and all > that other > > stuff. > > > > Or hey, just toss it all out and add session negotiation to XMPP. > > > > -- > > Dean > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Jan 6 13:14:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09257 for ; Mon, 6 Jan 2003 13:14:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06IOja02922 for sip-archive@odin.ietf.org; Mon, 6 Jan 2003 13:24:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06IHCJ02581; Mon, 6 Jan 2003 13:17:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06IF4J02535 for ; Mon, 6 Jan 2003 13:15:04 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09059 for ; Mon, 6 Jan 2003 13:04:12 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h06I7Lo24467; Mon, 6 Jan 2003 18:07:21 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Jan 2003 18:07:21 -0000 Message-ID: From: "Mark Watson" To: "'Frank W. Miller'" , Dean Willis Cc: sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Mon, 6 Jan 2003 18:07:18 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B5AE.17E41BFC" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2B5AE.17E41BFC Content-Type: text/plain; charset="iso-8859-1" Looks at first glance like the Generic Transparency Descriptor which has been proposed within ITU-T Study Group 11 and ANSI T1S1. Just out of interest, what would be the MIME type for carrying this in SIP ? Is recoding of ISUP into text format exactly in the scope of the IETF SIP group ? ...Mark > -----Original Message----- > From: Frank W. Miller [mailto:fmiller@sentito.com] > Sent: 04 January 2003 00:02 > To: Dean Willis > Cc: sip@ietf.org > Subject: Re: [Sip] INFO considered harmful > > > > > Well, any illusion of reasonableness I may have garnered in > the past is > about to be shattered. I would refer folks to: > > http://www.ietf.org/internet-drafts/draft-miller-sip-isup-annex-00.txt > > This draft is about to receive a major -01 update that > recodes the entire > syntax in XML. In addition, we (I) have another draft that > does something > very similar for ANSI TCAP that I'll be submitting in short > order. I guess > its only appropriate that I bring peoples attention to these > drafts under > the current subject heading... > > FM > > Frank W. Miller, Ph.D. > Chief Technical Officer > sentitO Networks, Inc. > fmiller@sentito.com > > ----- Original Message ----- > From: "Dean Willis" > To: "'Neil Deason'" ; "'Adam Roach'" > > Cc: > Sent: Friday, January 03, 2003 6:13 PM > Subject: RE: [Sip] INFO considered harmful > > > > > What I was actually advocating here was ppl wanting to keep > > > INFO around write up something to illuminate INFO packages > > > and provide example usage. > > > > > > The MESSAGE cf INFO was just an attempt to highlight an > > > apparent limitation with the ban INFO approach. Every MIME > > > type in an INFO can be moved into MESSAGE rather than go > > > away. Maybe through exploring INFO packages we evolve the > > > collective understanding that this is/isn't a necessary thing. > > > > > > Cheers, > > > Neil. > > > > This is an excellent suggestion, and very similar to the > one Jonathan made > > to me on the phone yesterday (actually, I think he more > tersely worded it > as > > "Send Text!") > > > > -- > > 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 > ------_=_NextPart_001_01C2B5AE.17E41BFC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] INFO considered harmful

Looks at first glance like the Generic Transparency = Descriptor which has been proposed within ITU-T Study Group 11 and ANSI = T1S1. Just out of interest, what would be the MIME type for carrying = this in SIP ?

Is recoding of ISUP into text format exactly in the = scope of the IETF SIP group ?

...Mark

> -----Original Message-----
> From: Frank W. Miller [mailto:fmiller@sentito.com]
> Sent: 04 January 2003 00:02
> To: Dean Willis
> Cc: sip@ietf.org
> Subject: Re: [Sip] INFO considered = harmful
>
>
>
>
> Well, any illusion of reasonableness I may have = garnered in
> the past is
> about to be shattered.  I would refer = folks to:
>
> http://www.ietf.org/internet-drafts/draft-miller-sip-i= sup-annex-00.txt
>
> This draft is about to receive a major -01 = update that
> recodes the entire
> syntax in XML.  In addition, we (I) have = another draft that
> does something
> very similar for ANSI TCAP that I'll be = submitting in short
> order.  I guess
> its only appropriate that I bring peoples = attention to these
> drafts under
> the current subject heading...
>
> FM
>
> Frank W. Miller, Ph.D.
> Chief Technical Officer
> sentitO Networks, Inc.
> fmiller@sentito.com
>
> ----- Original Message -----
> From: "Dean Willis" = <dean.willis@softarmor.com>
> To: "'Neil Deason'" = <ndeason@ubiquity.net>; "'Adam Roach'"
> <adam@dynamicsoft.com>
> Cc: <sip@ietf.org>
> Sent: Friday, January 03, 2003 6:13 PM
> Subject: RE: [Sip] INFO considered = harmful
>
>
> > > What I was actually advocating here = was ppl wanting to keep
> > > INFO around write up something to = illuminate INFO packages
> > > and provide example usage.
> > >
> > > The MESSAGE cf INFO was just an = attempt to highlight an
> > > apparent limitation with the ban INFO = approach. Every MIME
> > > type in an INFO can be moved into = MESSAGE rather than go
> > > away. Maybe through exploring INFO = packages we evolve the
> > > collective understanding that this = is/isn't a necessary thing.
> > >
> > > Cheers,
> > > Neil.
> >
> > This is an excellent suggestion, and very = similar to the
> one Jonathan made
> > to me on the phone yesterday (actually, I = think he more
> tersely worded it
> as
> > "Send Text!")
> >
> > --
> > 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
>

------_=_NextPart_001_01C2B5AE.17E41BFC-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Jan 6 13:41:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09963 for ; Mon, 6 Jan 2003 13:41:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06Ipx904981 for sip-archive@odin.ietf.org; Mon, 6 Jan 2003 13:51:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06IjYJ04669; Mon, 6 Jan 2003 13:45:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06IiDJ04601 for ; Mon, 6 Jan 2003 13:44:13 -0500 Received: from face.sentitonetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09751 for ; Mon, 6 Jan 2003 13:33:20 -0500 (EST) Received: (qmail 57966 invoked from network); 6 Jan 2003 18:36:36 -0000 Received: from unknown (HELO overhill) (10.0.0.159) by face.sentito.com with SMTP; 6 Jan 2003 18:36:36 -0000 Message-ID: <007201c2b5b2$8cfc8240$9f00000a@overhill> From: "Frank W. Miller" To: "Mark Watson" Cc: References: Subject: Re: [Sip] INFO considered harmful Date: Mon, 6 Jan 2003 13:36:38 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006F_01C2B588.A3D8A860" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_006F_01C2B588.A3D8A860 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] INFO considered harmfulWe just arbitarily picked: Content-type: applicaton/isupxml That is in the -01 version of this document that I referred to earlier. = Sorry, I'll get it up on the IETF site as quick as I can, hopefully = within the week. It is explictly outside the scope of the group, by choice I believe. = But this and the TCAP stuff are good examples of what I've been = advocating, the need for some mechanism to allow stuff thats "related" = but not necessarily appropriate (and in this case explictly shunned) for = the mainline standard. We actually looked at using SOAP for this (as = was suggested by Adam) and decided against it for simple expedience = (read development cost) reasons. The mechanism present in our = (third-party) SIP implementation was so compelling coupled with an off = the shelf XML parser, that it didnt make sense to do anything else... Furthermore, I would argue that you really never want anything like this = to be included in the mainline standard for a couple of reasons. First, = it is very application specific. Second, hopefully as SIP gains = momentum and SS7 loses momentum with the large carriers, this stuff will = just fade away... FM Frank W. Miller Chief Technical Officer sentitO Networks, Inc. fmiller@sentitio.com ----- Original Message -----=20 From: Mark Watson=20 To: 'Frank W. Miller' ; Dean Willis=20 Cc: sip@ietf.org=20 Sent: Monday, January 06, 2003 1:07 PM Subject: RE: [Sip] INFO considered harmful Looks at first glance like the Generic Transparency Descriptor which = has been proposed within ITU-T Study Group 11 and ANSI T1S1. Just out of = interest, what would be the MIME type for carrying this in SIP ? Is recoding of ISUP into text format exactly in the scope of the IETF = SIP group ?=20 ------=_NextPart_000_006F_01C2B588.A3D8A860 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] INFO considered harmful
We just arbitarily picked:
 
Content-type: = applicaton/isupxml
 
That is in the -01 version of this = document that I=20 referred to earlier.  Sorry, I'll get it up on the IETF site as = quick as I=20 can, hopefully within the week.
 
It is explictly outside the scope of = the group, by=20 choice I believe.  But this and the TCAP stuff are good = examples of=20 what I've been advocating, the need for some mechanism to allow = stuff thats=20 "related" but not necessarily appropriate (and in this case = explictly=20 shunned) for the mainline standard.  We actually looked at = using SOAP=20 for this (as was suggested by Adam) and decided against it for simple = expedience=20 (read development cost) reasons.  The mechanism present in our=20 (third-party) SIP implementation was so compelling coupled with an off = the shelf=20 XML parser, that it didnt make sense to do anything else...
 
Furthermore, I would argue that you = really never=20 want anything like this to be included in the mainline standard for a = couple of=20 reasons.  First, it is very application specific.  Second, = hopefully=20 as SIP gains momentum and SS7 loses momentum with the large carriers, = this stuff=20 will just fade away...
 
FM
 
Frank W. Miller
Chief Technical Officer
sentitO Networks, Inc.
fmiller@sentitio.com
 
----- Original Message -----
From:=20 Mark Watson
To: 'Frank W. Miller' ; Dean=20 Willis
Sent: Monday, January 06, 2003 = 1:07=20 PM
Subject: RE: [Sip] INFO = considered=20 harmful

Looks at first glance like the Generic Transparency = Descriptor=20 which has been proposed within ITU-T Study Group 11 and ANSI T1S1. = Just out of=20 interest, what would be the MIME type for carrying this in SIP = ?

Is recoding of ISUP into text format exactly in the = scope of=20 the IETF SIP group ?

 

------=_NextPart_000_006F_01C2B588.A3D8A860-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Jan 6 18:57:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19269 for ; Mon, 6 Jan 2003 18:57:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0707X826799 for sip-archive@odin.ietf.org; Mon, 6 Jan 2003 19:07:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0701UJ25949; Mon, 6 Jan 2003 19:01:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06NsqJ25724 for ; Mon, 6 Jan 2003 18:54:52 -0500 Received: from gamma.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19014; Mon, 6 Jan 2003 18:43:36 -0500 (EST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h06NkpD27924; Mon, 6 Jan 2003 15:46:51 -0800 (PST) Message-Id: <200301062346.h06NkpD27924@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, sip@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 06 Jan 2003 15:46:51 -0800 Subject: [Sip] RFC 3329 on Security Mechanism Agreement for the Session Initiation Protocol (SIP) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3329 Title: Security Mechanism Agreement for the Session Initiation Protocol (SIP) Author(s): J. Arkko, V. Torvinen, G. Camarillo, A. Niemi, T. Haukka Status: Standards Track Date: January 2003 Mailbox: jari.arkko@ericsson.com, vesa.torvinen@ericsson.fi, Gonzalo.Camarillo@ericsson.com, aki.niemi@nokia.com, tao.haukka@nokia.com Pages: 24 Characters: 51503 Updates/Obsoletes/See Also: None I-D Tag: draft-ietf-sip-sec-agree-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3329.txt This document defines new functionality for negotiating the security mechanisms used between a Session Initiation Protocol (SIP) user agent and its next-hop SIP entity. This new functionality supplements the existing methods of choosing security mechanisms between SIP entities. This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030106154456.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3329 --OtherAccess Content-Type: Message/External-body; name="rfc3329.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030106154456.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Jan 7 03:32:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07010 for ; Tue, 7 Jan 2003 03:32:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h078gpL02233 for sip-archive@odin.ietf.org; Tue, 7 Jan 2003 03:42:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h078e8J02137; Tue, 7 Jan 2003 03:40:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h078aaJ01346 for ; Tue, 7 Jan 2003 03:36:36 -0500 Received: from beamer.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06924 for ; Tue, 7 Jan 2003 03:25:28 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id JAA25766; Tue, 7 Jan 2003 09:28:41 +0100 (MET) Received: from siemens.com ([139.21.4.37]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id JAA00222; Tue, 7 Jan 2003 09:28:41 +0100 (MET) Message-ID: <3E1A8FB9.60302@siemens.com> Date: Tue, 07 Jan 2003 09:28:41 +0100 From: Peter =?UTF-8?B?UMOkcHBpbmdoYXVz?= Organization: Siemens AG User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en,de MIME-Version: 1.0 To: Jonathan Rosenberg CC: hisham.khartabil@nokia.com, sip@ietf.org Subject: Re: Repost: [Sip] Buggy example in RFC 3261 References: <2038BCC78B1AD641891A0D1AE133DBB7FE70A3@esebe019.ntc.nokia.com> <3E152EFF.8080105@dynamicsoft.com> <3E183A16.8070302@siemens.com> <3E18EE0E.1070700@dynamicsoft.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit inline. Jonathan Rosenberg wrote: > inline. > > Peter Päppinghaus wrote: > >> Two more remarks inline. >> >> Jonathan Rosenberg wrote: >> >>> Well, a decision needs to be made one way or another. Since its >>> already in 3261, I would propose that we declare the example as >>> buggy, and go with the existing normative text, even though it works >>> differently than for requests. >>> >>> -Jonathan R. [snip] >> To me this asymmetry between REGISTER and its 200 responses does not >> seem so odd. On the one hand it is very likely that a UA registering >> a set of contact addresses in one REGISTER would suggest the same >> expiration interval for all of them. On the other hand the 200 for >> such a REGISTER is required to list all current bindings, and there >> is no reason why the bindings should all have the same expiration >> time. > > > True enough, but the same processing would still work in either case. > > Anyway, I would still propose to follow my suggestion and go with the > normative text in bullet 8 of 10.3. > > -Jonathan R. This is also my personal preference. -- Dr. Peter Päppinghaus Siemens AG | Phone: +49 89 - 722 40065 ICM N PG U ID A1 | Fax: +49 89 - 722 58726 Hofmannstr. 51 | Visitors: Building 1713 / Room 714 D - 81359 München | Email: peter.paeppinghaus@siemens.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Jan 7 05:13:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08485 for ; Tue, 7 Jan 2003 05:13:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07AOHn08216 for sip-archive@odin.ietf.org; Tue, 7 Jan 2003 05:24:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07AISJ07991; Tue, 7 Jan 2003 05:18:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07AD1J07801 for ; Tue, 7 Jan 2003 05:13:01 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08289 for ; Tue, 7 Jan 2003 05:01:50 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h07A52A14953; Tue, 7 Jan 2003 10:05:02 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Jan 2003 10:05:02 -0000 Message-ID: From: "Mark Watson" To: "'Frank W. Miller'" Cc: sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Tue, 7 Jan 2003 10:04:58 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B634.3C727E6A" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2B634.3C727E6A Content-Type: text/plain; charset="iso-8859-1" Frank, I guess my concern is that there is an important difference between transparently carrying ISUP information between 'ISUP capable' devices (which we have a way to do with SIP-T), and defining new formats for 'ISUP-style' information to be processed by non-ISUP-capable nodes in the SIP network. This second just sounds like defining extensions to SIP. There's been lots of discussion about processes for defining extensions to SIP - both standard and 'proprietary/preliminary ...'. Don't want to repeat these here, but usually there is some opposition to just importing things from ISUP. Was your intention that this approach be published as Informational, or rolled in to the GTD work in ITU ? ...Mark -----Original Message----- From: Frank W. Miller [mailto:fmiller@sentito.com] Sent: 06 January 2003 18:37 To: Watson, Mark [MOP:EP10:EXCH] Cc: sip@ietf.org Subject: Re: [Sip] INFO considered harmful We just arbitarily picked: Content-type: applicaton/isupxml That is in the -01 version of this document that I referred to earlier. Sorry, I'll get it up on the IETF site as quick as I can, hopefully within the week. It is explictly outside the scope of the group, by choice I believe. But this and the TCAP stuff are good examples of what I've been advocating, the need for some mechanism to allow stuff thats "related" but not necessarily appropriate (and in this case explictly shunned) for the mainline standard. We actually looked at using SOAP for this (as was suggested by Adam) and decided against it for simple expedience (read development cost) reasons. The mechanism present in our (third-party) SIP implementation was so compelling coupled with an off the shelf XML parser, that it didnt make sense to do anything else... Furthermore, I would argue that you really never want anything like this to be included in the mainline standard for a couple of reasons. First, it is very application specific. Second, hopefully as SIP gains momentum and SS7 loses momentum with the large carriers, this stuff will just fade away... FM Frank W. Miller Chief Technical Officer sentitO Networks, Inc. fmiller@sentitio.com ----- Original Message ----- From: Mark Watson To: 'Frank W. Miller' ; Dean Willis Cc: sip@ietf.org Sent: Monday, January 06, 2003 1:07 PM Subject: RE: [Sip] INFO considered harmful Looks at first glance like the Generic Transparency Descriptor which has been proposed within ITU-T Study Group 11 and ANSI T1S1. Just out of interest, what would be the MIME type for carrying this in SIP ? Is recoding of ISUP into text format exactly in the scope of the IETF SIP group ? ------_=_NextPart_001_01C2B634.3C727E6A Content-Type: text/html; charset="iso-8859-1" RE: [Sip] INFO considered harmful
Frank,
 
I guess my concern is that there is an important difference between transparently carrying ISUP information between 'ISUP capable' devices (which we have a way to do with SIP-T), and defining new formats for 'ISUP-style' information to be processed by non-ISUP-capable nodes in the SIP network. This second just sounds like defining extensions to SIP.
 
There's been lots of discussion about processes for defining extensions to SIP - both standard and 'proprietary/preliminary ...'. Don't want to repeat these here, but usually there is some opposition to just importing things from ISUP.
 
Was your intention that this approach be published as Informational, or rolled in to the GTD work in ITU ?
 
...Mark
-----Original Message-----
From: Frank W. Miller [mailto:fmiller@sentito.com]
Sent: 06 January 2003 18:37
To: Watson, Mark [MOP:EP10:EXCH]
Cc: sip@ietf.org
Subject: Re: [Sip] INFO considered harmful

We just arbitarily picked:
 
Content-type: applicaton/isupxml
 
That is in the -01 version of this document that I referred to earlier.  Sorry, I'll get it up on the IETF site as quick as I can, hopefully within the week.
 
It is explictly outside the scope of the group, by choice I believe.  But this and the TCAP stuff are good examples of what I've been advocating, the need for some mechanism to allow stuff thats "related" but not necessarily appropriate (and in this case explictly shunned) for the mainline standard.  We actually looked at using SOAP for this (as was suggested by Adam) and decided against it for simple expedience (read development cost) reasons.  The mechanism present in our (third-party) SIP implementation was so compelling coupled with an off the shelf XML parser, that it didnt make sense to do anything else...
 
Furthermore, I would argue that you really never want anything like this to be included in the mainline standard for a couple of reasons.  First, it is very application specific.  Second, hopefully as SIP gains momentum and SS7 loses momentum with the large carriers, this stuff will just fade away...
 
FM
 
Frank W. Miller
Chief Technical Officer
sentitO Networks, Inc.
fmiller@sentitio.com
 
----- Original Message -----
Sent: Monday, January 06, 2003 1:07 PM
Subject: RE: [Sip] INFO considered harmful

Looks at first glance like the Generic Transparency Descriptor which has been proposed within ITU-T Study Group 11 and ANSI T1S1. Just out of interest, what would be the MIME type for carrying this in SIP ?

Is recoding of ISUP into text format exactly in the scope of the IETF SIP group ?

 

------_=_NextPart_001_01C2B634.3C727E6A-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Jan 7 08:40:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12793 for ; Tue, 7 Jan 2003 08:40:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07DpQw20697 for sip-archive@odin.ietf.org; Tue, 7 Jan 2003 08:51:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07DiqJ20370; Tue, 7 Jan 2003 08:44:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07DeMJ20116 for ; Tue, 7 Jan 2003 08:40:22 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12083; Tue, 7 Jan 2003 08:29:07 -0500 (EST) Message-Id: <200301071329.IAA12083@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 07 Jan 2003 08:29:07 -0500 Subject: [Sip] I-D ACTION:draft-rosenberg-sip-info-harmful-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Session Initiation Protocol (SIP) INFO Method Considered Harmful Author(s) : J. Rosenberg Filename : draft-rosenberg-sip-info-harmful-00.txt Pages : 11 Date : 2003-1-6 The Session Initiation Protocol (SIP) INFO method defines a means for transporting mid-dialog application layer data between user agents. Its initial use was to support the transport of ISUP mid-call messages which could not be mapped to any other SIP request method. However, since its initial usage for that purpose, INFO has seen widespread abuse as a means for introducing non-standard and non-interoperable extensions to SIP. For this reason, we now believe INFO should be considered harmful, and therefore, deprecated in its current form. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-info-harmful-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rosenberg-sip-info-harmful-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-rosenberg-sip-info-harmful-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-6152445.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-sip-info-harmful-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosenberg-sip-info-harmful-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-6152445.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Jan 7 10:13:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16872 for ; Tue, 7 Jan 2003 10:13:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07FNpl27579 for sip-archive@odin.ietf.org; Tue, 7 Jan 2003 10:23:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07FGYJ27085; Tue, 7 Jan 2003 10:16:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07FCKJ26849 for ; Tue, 7 Jan 2003 10:12:20 -0500 Received: from face.sentitonetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15999 for ; Tue, 7 Jan 2003 10:01:03 -0500 (EST) Received: (qmail 66761 invoked from network); 7 Jan 2003 15:04:17 -0000 Received: from unknown (HELO overhill) (10.0.0.159) by face.sentito.com with SMTP; 7 Jan 2003 15:04:17 -0000 Message-ID: <004b01c2b65e$0cb4c5f0$9f00000a@overhill> From: "Frank W. Miller" To: "Mark Watson" Cc: References: Subject: Re: [Sip] INFO considered harmful Date: Tue, 7 Jan 2003 10:04:17 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0048_01C2B634.239D2110" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0048_01C2B634.239D2110 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] INFO considered harmful The main issue with SIP-T is that it requires some portion of the SS7 = stack to be present in the IP elements of the network. I see SIP-T as = being primarily useful as an IP network transport of ISUP between SS7 = "islands". If an SS7 element wants to control say a T-1 that happens to = be SIP terminated, I feel that a translation is a better approach. It = limits the need to deploy (very expensive from a dollar and point code = point of view) ISUP protocol elements. Also, if done right, it can = eliminate the country variant problem that is IMHO a huge problem for = SS7. As far as my intentions with these drafts, I have none, other than a = desire for this protocol information to be in the public domain. I've = heard rumblings about addressing SIP interaction in the ITU and also = Telcordia. I have not participated in the ITU forums actively to date. = If IETF takes it up, thats fine. If there's synergy with ITU, thats = fine too. I like IETF because there's a mechanism for making things = public without having to really go though all the pain of committees. = It doesnt mean its sanctioned by IETF but the openness of the forum is = more appealing to me than some of the other standards groups I've been = involved with over time. FM ----- Original Message -----=20 From: Mark Watson=20 To: 'Frank W. Miller'=20 Cc: sip@ietf.org=20 Sent: Tuesday, January 07, 2003 5:04 AM Subject: RE: [Sip] INFO considered harmful Frank, I guess my concern is that there is an important difference between = transparently carrying ISUP information between 'ISUP capable' devices = (which we have a way to do with SIP-T), and defining new formats for = 'ISUP-style' information to be processed by non-ISUP-capable nodes in = the SIP network. This second just sounds like defining extensions to = SIP. There's been lots of discussion about processes for defining = extensions to SIP - both standard and 'proprietary/preliminary ...'. = Don't want to repeat these here, but usually there is some opposition to = just importing things from ISUP. Was your intention that this approach be published as Informational, = or rolled in to the GTD work in ITU ? ------=_NextPart_000_0048_01C2B634.239D2110 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] INFO considered harmful
 
The main issue with SIP-T is that it = requires some=20 portion of the SS7 stack to be present in the IP elements of the = network. =20 I see SIP-T as being primarily useful as an IP network = transport of=20 ISUP between SS7 "islands".  If an SS7 element wants to control say = a T-1=20 that happens to be SIP terminated, I feel that a translation is a better = approach.  It limits the need to deploy (very expensive from a = dollar and=20 point code point of view) ISUP protocol elements.  Also, if done = right, it=20 can eliminate the country variant problem that is IMHO a huge problem = for=20 SS7.
 
As far as my intentions with these = drafts, I have=20 none, other than a desire for this protocol information to be in the = public=20 domain.  I've heard rumblings about addressing SIP interaction in = the ITU=20 and also Telcordia.  I have not participated in the ITU forums = actively to=20 date.  If IETF takes it up, thats fine.  If there's synergy = with ITU,=20 thats fine too.  I like IETF because there's a mechanism for making = things=20 public without having to really go though all the pain of = committees.  It=20 doesnt mean its sanctioned by IETF but the openness of the forum is more = appealing to me than some of the other standards groups I've been = involved with=20 over time.
 
FM
 
 
----- Original Message -----
From:=20 Mark Watson
Sent: Tuesday, January 07, 2003 = 5:04=20 AM
Subject: RE: [Sip] INFO = considered=20 harmful

Frank,
 
I=20 guess my concern is that there is an important difference between=20 transparently carrying ISUP information between 'ISUP capable' devices = (which=20 we have a way to do with SIP-T), and defining new formats for = 'ISUP-style'=20 information to be processed by non-ISUP-capable nodes in the SIP = network. This=20 second just sounds like defining extensions to = SIP.
 
There's been lots of discussion about = processes for=20 defining extensions to SIP - both standard and = 'proprietary/preliminary ...'.=20 Don't want to repeat these here, but usually there is some opposition = to just=20 importing things from ISUP.
 
Was your intention that this approach be = published as=20 Informational, or rolled in to the GTD work in ITU = ?
 
 
------=_NextPart_000_0048_01C2B634.239D2110-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Jan 7 12:16:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21392 for ; Tue, 7 Jan 2003 12:16:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07HQpl04130 for sip-archive@odin.ietf.org; Tue, 7 Jan 2003 12:26:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07HPqJ04079; Tue, 7 Jan 2003 12:25:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07HMfJ03953 for ; Tue, 7 Jan 2003 12:22:41 -0500 Received: from ihemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21236 for ; Tue, 7 Jan 2003 12:11:22 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h07HEaD20800 for ; Tue, 7 Jan 2003 12:14:36 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Jan 2003 18:14:35 +0100 Message-ID: <5160DD6EC1C0D41196D700508B5C167101F7FF09@it2020exch001u.it.lucent.com> From: "Pianigiani, Jacopo (Jacopo)" To: "'Jonathan Rosenberg'" , Mukul Purohit Cc: sip@ietf.org Subject: RE: [Sip] resource reservation Date: Tue, 7 Jan 2003 18:14:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Jonathan & Mukul, as far as I know, referring to 3GPP, Rel.5 (frozen) and rel. 6 (being written almost now) specs the following QoS alternatives mechanisms to pure RSVP reservation mechanism will be available: a) Go Diameter interface on the GGSN (traffic gating & shaping + CAC) + conditioning of the Radio Access Bearer b) Diffserv and E/L-LSP QoS transport across RAN (but not for reservation, just for PHB treatment) c) as you correctly stated, end to end RSVP signalling (inheritance of Signalled SIP QoS parameters) Jac -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Monday, December 30, 2002 5:37 PM To: Mukul Purohit Cc: sip@ietf.org Subject: Re: [Sip] resource reservation Mukul Purohit wrote: > hi, > I have a basic question after going through RFC 3312, "Integration of > Resource Management and SIP". > > Has the actual resource reservation mechanism been specified (mandated > or suggested) by IETF? There is no mandatory resource reservation scheme. The primary one specified so far is RSVP. nsis is another one under development. Groups like packetcable have specified their own QoS protocols. > Also, has it been specified by any other body like 3GPP which has chosen > SIP for signaling? Yes, 3gpp has its own mechanisms that are specific to 3gpp. As I understand they are built into the GPRS procedures, and reservation occurs only on the wireless link. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Jan 7 14:50:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26232 for ; Tue, 7 Jan 2003 14:50:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07K0vv13626 for sip-archive@odin.ietf.org; Tue, 7 Jan 2003 15:00:57 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07JuMJ13485; Tue, 7 Jan 2003 14:56:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07JqfJ13361 for ; Tue, 7 Jan 2003 14:52:41 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26107 for ; Tue, 7 Jan 2003 14:41:18 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h07Jh453008201; Tue, 7 Jan 2003 14:43:05 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Jan 2003 13:44:28 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A643E9@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Frank W. Miller'" , Mark Watson Cc: sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Tue, 7 Jan 2003 13:44:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , From: Frank W. Miller [mailto:fmiller@sentito.com] > The main issue with SIP-T is that it requires some portion > of the SS7 stack to be present in the IP elements of the network. Huh? I beleive you've completely misunderstood the purpose of SIP-T. If you have an IP element (pure IP, not your gateway) that's interpreting the ISUP bodies present in SIP-T messages, you're violating the spirit of what was intended. I'm not making a value judgement; I'm just saying that your reading of the documents appears to have been a bit off. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Jan 7 17:52:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01933 for ; Tue, 7 Jan 2003 17:52:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07N3sx25077 for sip-archive@odin.ietf.org; Tue, 7 Jan 2003 18:03:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07N3TJ24992; Tue, 7 Jan 2003 18:03:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07MilJ24336 for ; Tue, 7 Jan 2003 17:44:47 -0500 Received: from face.sentitonetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01533 for ; Tue, 7 Jan 2003 17:33:21 -0500 (EST) Received: (qmail 12955 invoked from network); 7 Jan 2003 22:36:37 -0000 Received: from unknown (HELO overhill) (10.0.0.159) by face.sentito.com with SMTP; 7 Jan 2003 22:36:37 -0000 Message-ID: <009401c2b69d$3d02a760$9f00000a@overhill> From: "Frank W. Miller" To: "Adam Roach" Cc: References: <9BF66EBF6BEFD942915B4D4D45C051F3A643E9@DYN-TX-EXCH-001.dynamicsoft.com> Subject: Re: [Sip] INFO considered harmful Date: Tue, 7 Jan 2003 17:36:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'm not talking about how it was intended for use, I'm talking about how it can and is being used in some instances (seems to be a theme here lately). FM ----- Original Message ----- From: "Adam Roach" To: "'Frank W. Miller'" ; "Mark Watson" Cc: Sent: Tuesday, January 07, 2003 2:44 PM Subject: RE: [Sip] INFO considered harmful > From: Frank W. Miller [mailto:fmiller@sentito.com] > > > The main issue with SIP-T is that it requires some portion > > of the SS7 stack to be present in the IP elements of the network. > > Huh? > > I beleive you've completely misunderstood the purpose of SIP-T. > If you have an IP element (pure IP, not your gateway) that's > interpreting the ISUP bodies present in SIP-T messages, you're > violating the spirit of what was intended. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Jan 7 18:12:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02564 for ; Tue, 7 Jan 2003 18:12:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07NNfw26707 for sip-archive@odin.ietf.org; Tue, 7 Jan 2003 18:23:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07NMuJ26661; Tue, 7 Jan 2003 18:22:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07NHjJ26402 for ; Tue, 7 Jan 2003 18:17:45 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02351 for ; Tue, 7 Jan 2003 18:06:18 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h07N8853009412; Tue, 7 Jan 2003 18:08:08 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Jan 2003 17:09:32 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A643F0@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Frank W. Miller'" , Adam Roach Cc: sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Tue, 7 Jan 2003 17:09:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Sorry for being pedantic, but under the circumstances you describe, it would cause far less confusion and help limit disinformation if you were to phrase such things as "The main issue with our proprietary use of SIP-T..." Your original statement asserted (presumably unintentionally) that using SIP-T *requires* SIP proxies to understand ISUP, which is clearly not true. /a P.S. The expensive part of your ISUP stacks is not the encoding; it's the state machines. The syntactical transformation you propose actually gains you very little. ISUP encoding is delightfully simple to code. In fact, five years ago, I could do it in my head for the most common operations. > -----Original Message----- > From: Frank W. Miller [mailto:fmiller@sentito.com] > Sent: Tuesday, January 07, 2003 16:37 > To: Adam Roach > Cc: sip@ietf.org > Subject: Re: [Sip] INFO considered harmful > > > > I'm not talking about how it was intended for use, I'm > talking about how it > can and is being used in some instances (seems to be a theme > here lately). > > FM > > > ----- Original Message ----- > From: "Adam Roach" > To: "'Frank W. Miller'" ; "Mark Watson" > > Cc: > Sent: Tuesday, January 07, 2003 2:44 PM > Subject: RE: [Sip] INFO considered harmful > > > > From: Frank W. Miller [mailto:fmiller@sentito.com] > > > > > The main issue with SIP-T is that it requires some portion > > > of the SS7 stack to be present in the IP elements of the network. > > > > Huh? > > > > I beleive you've completely misunderstood the purpose of SIP-T. > > If you have an IP element (pure IP, not your gateway) that's > > interpreting the ISUP bodies present in SIP-T messages, you're > > violating the spirit of what was intended. > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Jan 8 04:48:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15342 for ; Wed, 8 Jan 2003 04:48:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h089xYw09019 for sip-archive@odin.ietf.org; Wed, 8 Jan 2003 04:59:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h089woJ08998; Wed, 8 Jan 2003 04:58:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h089uHJ08871 for ; Wed, 8 Jan 2003 04:56:17 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15287 for ; Wed, 8 Jan 2003 04:44:38 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h089kt008457 for ; Wed, 8 Jan 2003 11:46:55 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 8 Jan 2003 11:47:48 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Jan 2003 11:47:48 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Jan 2003 11:47:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 8 Jan 2003 11:47:47 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE70C8@esebe019.ntc.nokia.com> Thread-Topic: Can INVITE overlap SUBSCRIBE Thread-Index: AcK2+v+1H4bNu7BXTzKIVzHkX8/oWw== To: X-OriginalArrivalTime: 08 Jan 2003 09:47:47.0964 (UTC) FILETIME=[0067BBC0:01C2B6FB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h089uHJ08872 Subject: [Sip] Can INVITE overlap SUBSCRIBE Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit If a dialog is already established with a SUBSCRIBE, that SUBSCRIBE is being refreshed (SUBSCRIBE in progress). Can an INVITE, within the same dialog, be sent while the SUBSCRIBE refresh is in progress? Another question: Can SUBSCRIBEs overlap in the following 2 scenarios? Scenario 1: (1) SUBSCRIBE event:presence ----------------------------> (2) SUBSCRIBE event:presence ----------------------------> (1) and (2) are requests within the same dialog and are the same association with the dialog. Can (2) be sent before (1) completes. This is like INVITEs overlapping. Scenario 2: (3) SUBSCRIBE event:presence ----------------------------> (4) SUBSCRIBE event:winfo ----------------------------> (3) and (4) are requests within the same dialog but are in different associations with the dialog. Can (4) be sent before (3) completes. This is like INVITE and SUBSCRIBE overlapping, I think. A similar example of this is 2 SUBSCRIBEs with the same event package but different event ids. 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 mailnull@www1.ietf.org Wed Jan 8 06:34:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17037 for ; Wed, 8 Jan 2003 06:34:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08Bk9615607 for sip-archive@odin.ietf.org; Wed, 8 Jan 2003 06:46:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08BjSJ15584; Wed, 8 Jan 2003 06:45:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08BiqJ15556 for ; Wed, 8 Jan 2003 06:44:52 -0500 Received: from bot.orange.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16996 for ; Wed, 8 Jan 2003 06:33:11 -0500 (EST) From: joanne.higgens@orange.co.uk Received: from ruddick (notes-gw.orange.co.uk [172.16.133.18]) by bot.orange.co.uk with SMTP id h08BaQm09215 for ; Wed, 8 Jan 2003 11:36:26 GMT X-Lotus-FromDomain: HTLUK To: sip@ietf.org Message-ID: <80256CA8.00401720.00@ruddick> Date: Wed, 8 Jan 2003 11:41:42 +0000 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Sip] SIP de-registration Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , All Is it valid to reject a de-registration request? For example 'If a SIP terminal sends a de-registration request to a network while it still has an active session established, and the network rejects this request , is this correct behaviour. Jo Higgens Orange UK ******************************************************************************* Important. Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of the company. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. Monitoring/Viruses Orange may monitor all incoming and outgoing emails in line with current legislation. Although we have taken steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. Orange PCS Limited is a subsidiary of Orange SA and is registered in England No 2178917, with its address at St James Court, Great Park Road, Almondsbury Park, Bradley Stoke, Bristol BS32 4QJ. ******************************************************************************* _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Jan 8 06:47:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17288 for ; Wed, 8 Jan 2003 06:47:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08Bwj615994 for sip-archive@odin.ietf.org; Wed, 8 Jan 2003 06:58:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08BwDJ15983; Wed, 8 Jan 2003 06:58:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08BvNJ15935 for ; Wed, 8 Jan 2003 06:57:23 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17257 for ; Wed, 8 Jan 2003 06:45:40 -0500 (EST) Received: from prasannacl1105 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H8E007A28QOOM@mta0.huawei.com> for sip@ietf.org; Wed, 08 Jan 2003 19:47:15 +0800 (CST) Date: Wed, 08 Jan 2003 17:20:38 +0530 From: Prasanna Venkatesh Subject: RE: [Sip] SIP de-registration In-reply-to: <80256CA8.00401720.00@ruddick> To: joanne.higgens@orange.co.uk, sip@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Any registrar can reject a de-registration request anytime. But rejecting a de-registration for the fact that a session is active is a local implementation. In general the registration is used to locate an entity and theoritically after the session is established, the registration is immaterial. Cheers, Prasanna -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of joanne.higgens@orange.co.uk Sent: Wednesday, January 08, 2003 5:12 PM To: sip@ietf.org Subject: [Sip] SIP de-registration All Is it valid to reject a de-registration request? For example 'If a SIP terminal sends a de-registration request to a network while it still has an active session established, and the network rejects this request , is this correct behaviour. Jo Higgens Orange UK **************************************************************************** *** Important. Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of the company. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. Monitoring/Viruses Orange may monitor all incoming and outgoing emails in line with current legislation. Although we have taken steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. Orange PCS Limited is a subsidiary of Orange SA and is registered in England No 2178917, with its address at St James Court, Great Park Road, Almondsbury Park, Bradley Stoke, Bristol BS32 4QJ. **************************************************************************** *** _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Jan 8 06:49:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17326 for ; Wed, 8 Jan 2003 06:49:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08C0Ys16110 for sip-archive@odin.ietf.org; Wed, 8 Jan 2003 07:00:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08C0FJ16098; Wed, 8 Jan 2003 07:00:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08Bx2J16020 for ; Wed, 8 Jan 2003 06:59:02 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17280 for ; Wed, 8 Jan 2003 06:47:19 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h08BoHA07086; Wed, 8 Jan 2003 11:50:17 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 11:50:17 -0000 Message-ID: From: "Mark Watson" To: "'Pianigiani, Jacopo (Jacopo)'" , "'Jonathan Rosenberg'" , Mukul Purohit Cc: sip@ietf.org Subject: RE: [Sip] resource reservation Date: Wed, 8 Jan 2003 11:50:15 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B70C.1B9DB5AA" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2B70C.1B9DB5AA Content-Type: text/plain; charset="iso-8859-1" Well, for the avoidance of confusion: 1) GPRS terminals need to perform a GPRS-specific resource reservation mechanims to get resources on the radio network/GPRS core network. This is known as a PDP Context. 3GPP IMS uses the "Integration of Resource Management and SIP" mechanisms to delay completion of the SIP session establishment until this GPRS-specific procedure has been completed. 2) Various mechanism can be used within the GPRS network/RAN to ensure that the traffic receives the QoS agreed in the PDP Context establishment negotiation. This could include Diffserv/MPLS but is internal to the GPRS network and not visible to the terminal 3) The Go interface is COPS-PR, not Diameter. It is used to authorise PDP Context establishements which are related to SIP sessions. 4) The terminal is free to attempt RSVP reservations, but these will have no effect on the GPRS network, unless the Layer 2 in the terminal is trapping them and firing off appropriate PDP Context requests. The RSVP may of course affect 'downstream' networks outside GPRS. ...Mark > -----Original Message----- > From: Pianigiani, Jacopo (Jacopo) [mailto:jpianigiani@lucent.com] > Sent: 07 January 2003 17:15 > To: 'Jonathan Rosenberg'; Mukul Purohit > Cc: sip@ietf.org > Subject: RE: [Sip] resource reservation > > > Jonathan & Mukul, > as far as I know, referring to 3GPP, Rel.5 (frozen) and rel. > 6 (being written almost now) specs the following QoS > alternatives mechanisms to pure RSVP reservation mechanism > will be available: > a) Go Diameter interface on the GGSN (traffic gating & > shaping + CAC) + conditioning of the Radio Access Bearer > b) Diffserv and E/L-LSP QoS transport across RAN (but not for > reservation, just for PHB treatment) > c) as you correctly stated, end to end RSVP signalling > (inheritance of Signalled SIP QoS parameters) > > Jac > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, December 30, 2002 5:37 PM > To: Mukul Purohit > Cc: sip@ietf.org > Subject: Re: [Sip] resource reservation > > > > > Mukul Purohit wrote: > > hi, > > I have a basic question after going through RFC 3312, > "Integration of > > Resource Management and SIP". > > > > Has the actual resource reservation mechanism been > specified (mandated > > or suggested) by IETF? > > There is no mandatory resource reservation scheme. The primary one > specified so far is RSVP. nsis is another one under > development. Groups > like packetcable have specified their own QoS protocols. > > > Also, has it been specified by any other body like 3GPP > which has chosen > > SIP for signaling? > > Yes, 3gpp has its own mechanisms that are specific to 3gpp. As I > understand they are built into the GPRS procedures, and reservation > occurs only on the wireless link. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------_=_NextPart_001_01C2B70C.1B9DB5AA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] resource reservation

Well, for the avoidance of confusion:

1) GPRS terminals need to perform a GPRS-specific = resource reservation mechanims to get resources on the radio = network/GPRS core network. This is known as a PDP Context. 3GPP IMS = uses the "Integration of Resource Management and SIP" = mechanisms to delay completion of the SIP session establishment until = this GPRS-specific procedure has been completed.

2) Various mechanism can be used within the GPRS = network/RAN to ensure that the traffic receives the QoS agreed in the = PDP Context establishment negotiation. This could include Diffserv/MPLS = but is internal to the GPRS network and not visible to the = terminal

3) The Go interface is COPS-PR, not Diameter. It is = used to authorise PDP Context establishements which are related to SIP = sessions.

4) The terminal is free to attempt RSVP reservations, = but these will have no effect on the GPRS network, unless the Layer 2 = in the terminal is trapping them and firing off appropriate PDP Context = requests. The RSVP may of course affect 'downstream' networks outside = GPRS.

...Mark

> -----Original Message-----
> From: Pianigiani, Jacopo (Jacopo) [mailto:jpianigiani@lucent.com= ]
> Sent: 07 January 2003 17:15
> To: 'Jonathan Rosenberg'; Mukul Purohit
> Cc: sip@ietf.org
> Subject: RE: [Sip] resource reservation
>
>
> Jonathan & Mukul,
> as far as I know, referring to 3GPP, Rel.5 = (frozen) and rel.
> 6 (being written almost now) specs the = following QoS
> alternatives mechanisms to pure RSVP = reservation mechanism
> will be available:
> a) Go Diameter interface on the GGSN (traffic = gating &
> shaping + CAC) + conditioning of the Radio = Access Bearer
> b) Diffserv and E/L-LSP QoS transport across = RAN (but not for
> reservation, just for PHB treatment)
> c) as you correctly stated, end to end RSVP = signalling
> (inheritance of Signalled SIP QoS = parameters)
>
> Jac
>
> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Monday, December 30, 2002 5:37 PM
> To: Mukul Purohit
> Cc: sip@ietf.org
> Subject: Re: [Sip] resource reservation
>
>
>
>
> Mukul Purohit wrote:
> > hi,
> > I have a basic question after going = through RFC 3312,
> "Integration of
> > Resource Management and SIP".
> >
> > Has the actual resource reservation = mechanism been
> specified (mandated
> > or suggested) by IETF?
>
> There is no mandatory resource reservation = scheme. The primary one
> specified so far is RSVP. nsis is another one = under
> development. Groups
> like packetcable have specified their own QoS = protocols.
>
> > Also, has it been specified by any other = body like 3GPP
> which has chosen
> > SIP for signaling?
>
> Yes, 3gpp has its own mechanisms that are = specific to 3gpp. As I
> understand they are built into the GPRS = procedures, and reservation
> occurs only on the wireless link.
>
> -Jonathan R.
>
> --
> Jonathan D. Rosenberg, = Ph.D.           &= nbsp;    72 Eagle Rock Ave.
> Chief = Scientist          &nb= sp;           &nb= sp;      First Floor
> = dynamicsoft          &= nbsp;           &= nbsp;          East = Hanover, NJ 07936
> = jdrosen@dynamicsoft.com        &= nbsp;            = FAX:   (973) 952-5050
> http://www.jdrosen.net    &nbs= p;           &nbs= p;     PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
> = _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP Protocol
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sipping@ietf.org for new developments on = the application of sip
> = _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP Protocol
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sipping@ietf.org for new developments on = the application of sip
>

------_=_NextPart_001_01C2B70C.1B9DB5AA-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Jan 8 10:09:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21832 for ; Wed, 8 Jan 2003 10:09:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08FKU828425 for sip-archive@odin.ietf.org; Wed, 8 Jan 2003 10:20:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08FK2J28401; Wed, 8 Jan 2003 10:20:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08FIZJ28327 for ; Wed, 8 Jan 2003 10:18:35 -0500 Received: from dgesmtp01.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21789 for ; Wed, 8 Jan 2003 10:06:49 -0500 (EST) Received: from dgismtp05.wcomnet.com ([166.38.58.88]) by firewall.wcom.com (Iplanet MTA) with ESMTP id <0H8E0085NI28I5@firewall.wcom.com> for sip@ietf.org; Wed, 08 Jan 2003 15:08:32 +0000 (GMT) Received: from dgismtp05.wcomnet.com by dgismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H8E00I01I2733@dgismtp05.wcomnet.com>; Wed, 08 Jan 2003 15:08:32 +0000 (GMT) Received: from hsinnreich2 ([166.50.112.93]) by dgismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H8E00G3YI25WC@dgismtp05.wcomnet.com>; Wed, 08 Jan 2003 15:08:32 +0000 (GMT) Date: Wed, 08 Jan 2003 09:08:29 -0600 From: Henry Sinnreich Subject: RE: [Sip] resource reservation In-reply-to: To: "'Mark Watson'" , "'Pianigiani, Jacopo (Jacopo)'" , "'Jonathan Rosenberg'" , "'Mukul Purohit'" Cc: sip@ietf.org Message-id: <003001c2b727$cef622c0$5d7032a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1097 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >3) The Go interface is COPS-PR, not Diameter. yes, and RADIUS in wireline systems. Also not DIAMETER. Thanks, Henry -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Mark Watson Sent: Wednesday, January 08, 2003 5:50 AM To: 'Pianigiani, Jacopo (Jacopo)'; 'Jonathan Rosenberg'; Mukul Purohit Cc: sip@ietf.org Subject: RE: [Sip] resource reservation Well, for the avoidance of confusion: 1) GPRS terminals need to perform a GPRS-specific resource reservation mechanims to get resources on the radio network/GPRS core network. This is known as a PDP Context. 3GPP IMS uses the "Integration of Resource Management and SIP" mechanisms to delay completion of the SIP session establishment until this GPRS-specific procedure has been completed. 2) Various mechanism can be used within the GPRS network/RAN to ensure that the traffic receives the QoS agreed in the PDP Context establishment negotiation. This could include Diffserv/MPLS but is internal to the GPRS network and not visible to the terminal 3) The Go interface is COPS-PR, not Diameter. It is used to authorise PDP Context establishements which are related to SIP sessions. 4) The terminal is free to attempt RSVP reservations, but these will have no effect on the GPRS network, unless the Layer 2 in the terminal is trapping them and firing off appropriate PDP Context requests. The RSVP may of course affect 'downstream' networks outside GPRS. ...Mark > -----Original Message----- > From: Pianigiani, Jacopo (Jacopo) [mailto:jpianigiani@lucent.com] > Sent: 07 January 2003 17:15 > To: 'Jonathan Rosenberg'; Mukul Purohit > Cc: sip@ietf.org > Subject: RE: [Sip] resource reservation > > > Jonathan & Mukul, > as far as I know, referring to 3GPP, Rel.5 (frozen) and rel. > 6 (being written almost now) specs the following QoS > alternatives mechanisms to pure RSVP reservation mechanism > will be available: > a) Go Diameter interface on the GGSN (traffic gating & > shaping + CAC) + conditioning of the Radio Access Bearer > b) Diffserv and E/L-LSP QoS transport across RAN (but not for > reservation, just for PHB treatment) > c) as you correctly stated, end to end RSVP signalling > (inheritance of Signalled SIP QoS parameters) > > Jac > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, December 30, 2002 5:37 PM > To: Mukul Purohit > Cc: sip@ietf.org > Subject: Re: [Sip] resource reservation > > > > > Mukul Purohit wrote: > > hi, > > I have a basic question after going through RFC 3312, > "Integration of > > Resource Management and SIP". > > > > Has the actual resource reservation mechanism been > specified (mandated > > or suggested) by IETF? > > There is no mandatory resource reservation scheme. The primary one > specified so far is RSVP. nsis is another one under > development. Groups > like packetcable have specified their own QoS protocols. > > > Also, has it been specified by any other body like 3GPP > which has chosen > > SIP for signaling? > > Yes, 3gpp has its own mechanisms that are specific to 3gpp. As I > understand they are built into the GPRS procedures, and reservation > occurs only on the wireless link. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Jan 8 10:41:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22744 for ; Wed, 8 Jan 2003 10:41:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08FrAI30601 for sip-archive@odin.ietf.org; Wed, 8 Jan 2003 10:53:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08FqVJ30562; Wed, 8 Jan 2003 10:52:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08FpnJ30532 for ; Wed, 8 Jan 2003 10:51:49 -0500 Received: from hoemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22703 for ; Wed, 8 Jan 2003 10:40:01 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h08FhCJ21529 for ; Wed, 8 Jan 2003 10:43:13 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 16:43:11 +0100 Message-ID: <5160DD6EC1C0D41196D700508B5C167101F7FF20@it2020exch001u.it.lucent.com> From: "Pianigiani, Jacopo (Jacopo)" To: "'Mark Watson'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] resource reservation Date: Wed, 8 Jan 2003 16:43:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B72C.A56F8B30" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2B72C.A56F8B30 Content-Type: text/plain; charset="iso-8859-1" Mark, I've written some thoughts inline along your mail. Thanks for your comments and regards. Jac -----Original Message----- From: Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: Wednesday, January 08, 2003 12:50 PM To: 'Pianigiani, Jacopo (Jacopo)'; 'Jonathan Rosenberg'; Mukul Purohit Cc: sip@ietf.org Subject: RE: [Sip] resource reservation Well, for the avoidance of confusion: 1) GPRS terminals need to perform a GPRS-specific resource reservation mechanims to get resources on the radio network/GPRS core network. This is known as a PDP Context. 3GPP IMS uses the "Integration of Resource Management and SIP" mechanisms to delay completion of the SIP session establishment until this GPRS-specific procedure has been completed. 2) Various mechanism can be used within the GPRS network/RAN to ensure that the traffic receives the QoS agreed in the PDP Context establishment negotiation. This could include Diffserv/MPLS but is internal to the GPRS network and not visible to the terminal 3) The Go interface is COPS-PR, not Diameter. It is used to authorise PDP Context establishements which are related to SIP sessions. Sorry for the confusion in writing. What i meant is that both Go (COPS-PR) and Diameter are used netween IMS and HSS and IMS and GGSN (Diameter is used to perform AAA function toward the HSS and this is applied whenever a PDP context with specific QoS constraint is requested from the IMS then Go implements the policy decisions. ). 4) The terminal is free to attempt RSVP reservations, but these will have no effect on the GPRS network, unless the Layer 2 in the terminal is trapping them and firing off appropriate PDP Context requests. The RSVP may of course affect 'downstream' networks outside GPRS. Agreed. But if we consider a scenario where there is a mechanism to reserve QoS for SIP sessions is in place within the GPRS network, then it could be relevant to have a method to extend QoS from the edge of the GPRS network (GGSN) onward, to the other end (external bearer transport QoS and interworking of QoS parameters across distinct QoS domains) ...Mark > -----Original Message----- > From: Pianigiani, Jacopo (Jacopo) [ mailto:jpianigiani@lucent.com ] > Sent: 07 January 2003 17:15 > To: 'Jonathan Rosenberg'; Mukul Purohit > Cc: sip@ietf.org > Subject: RE: [Sip] resource reservation > > > Jonathan & Mukul, > as far as I know, referring to 3GPP, Rel.5 (frozen) and rel. > 6 (being written almost now) specs the following QoS > alternatives mechanisms to pure RSVP reservation mechanism > will be available: > a) Go Diameter interface on the GGSN (traffic gating & > shaping + CAC) + conditioning of the Radio Access Bearer > b) Diffserv and E/L-LSP QoS transport across RAN (but not for > reservation, just for PHB treatment) > c) as you correctly stated, end to end RSVP signalling > (inheritance of Signalled SIP QoS parameters) > > Jac > > -----Original Message----- > From: Jonathan Rosenberg [ mailto:jdrosen@dynamicsoft.com ] > Sent: Monday, December 30, 2002 5:37 PM > To: Mukul Purohit > Cc: sip@ietf.org > Subject: Re: [Sip] resource reservation > > > > > Mukul Purohit wrote: > > hi, > > I have a basic question after going through RFC 3312, > "Integration of > > Resource Management and SIP". > > > > Has the actual resource reservation mechanism been > specified (mandated > > or suggested) by IETF? > > There is no mandatory resource reservation scheme. The primary one > specified so far is RSVP. nsis is another one under > development. Groups > like packetcable have specified their own QoS protocols. > > > Also, has it been specified by any other body like 3GPP > which has chosen > > SIP for signaling? > > Yes, 3gpp has its own mechanisms that are specific to 3gpp. As I > understand they are built into the GPRS procedures, and reservation > occurs only on the wireless link. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------_=_NextPart_001_01C2B72C.A56F8B30 Content-Type: text/html; charset="iso-8859-1" RE: [Sip] resource reservation
Mark,
I've written some thoughts inline along your mail.
Thanks for your comments and regards.
Jac
 -----Original Message-----
From: Mark Watson [mailto:mwatson@nortelnetworks.com]
Sent: Wednesday, January 08, 2003 12:50 PM
To: 'Pianigiani, Jacopo (Jacopo)'; 'Jonathan Rosenberg'; Mukul Purohit
Cc: sip@ietf.org
Subject: RE: [Sip] resource reservation

Well, for the avoidance of confusion:

1) GPRS terminals need to perform a GPRS-specific resource reservation mechanims to get resources on the radio network/GPRS core network. This is known as a PDP Context. 3GPP IMS uses the "Integration of Resource Management and SIP" mechanisms to delay completion of the SIP session establishment until this GPRS-specific procedure has been completed. 

2) Various mechanism can be used within the GPRS network/RAN to ensure that the traffic receives the QoS agreed in the PDP Context establishment negotiation. This could include Diffserv/MPLS but is internal to the GPRS network and not visible to the terminal     

 3) The Go interface is COPS-PR, not Diameter. It is used to authorise PDP Context establishements which are related to SIP sessions. 

Sorry for the confusion in writing. What i meant is that both Go (COPS-PR) and Diameter are used netween IMS and HSS and IMS and GGSN (Diameter is used to perform AAA function toward the HSS and this is applied whenever a PDP context with specific QoS constraint is requested from the IMS then Go implements the policy decisions. ).

4) The terminal is free to attempt RSVP reservations, but these will have no effect on the GPRS network, unless the Layer 2 in the terminal is trapping them and firing off appropriate PDP Context requests. The RSVP may of course affect 'downstream' networks outside GPRS. 

Agreed. But if we consider a scenario where there is a mechanism to reserve QoS for SIP sessions is in place within the GPRS network, then it could be relevant to have a method to extend QoS from the edge of the GPRS network (GGSN) onward, to the other end (external bearer transport QoS and interworking of QoS parameters across distinct QoS domains)

...Mark

> -----Original Message-----
> From: Pianigiani, Jacopo (Jacopo) [mailto:jpianigiani@lucent.com]
> Sent: 07 January 2003 17:15
> To: 'Jonathan Rosenberg'; Mukul Purohit
> Cc: sip@ietf.org
> Subject: RE: [Sip] resource reservation
>
>
> Jonathan & Mukul,
> as far as I know, referring to 3GPP, Rel.5 (frozen) and rel.
> 6 (being written almost now) specs the following QoS
> alternatives mechanisms to pure RSVP reservation mechanism
> will be available:
> a) Go Diameter interface on the GGSN (traffic gating &
> shaping + CAC) + conditioning of the Radio Access Bearer
> b) Diffserv and E/L-LSP QoS transport across RAN (but not for
> reservation, just for PHB treatment)
> c) as you correctly stated, end to end RSVP signalling
> (inheritance of Signalled SIP QoS parameters)
>
> Jac
>
> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Monday, December 30, 2002 5:37 PM
> To: Mukul Purohit
> Cc: sip@ietf.org
> Subject: Re: [Sip] resource reservation
>
>
>
>
> Mukul Purohit wrote:
> > hi,
> > I have a basic question after going through RFC 3312,
> "Integration of
> > Resource Management and SIP".
> >
> > Has the actual resource reservation mechanism been
> specified (mandated
> > or suggested) by IETF?
>
> There is no mandatory resource reservation scheme. The primary one
> specified so far is RSVP. nsis is another one under
> development. Groups
> like packetcable have specified their own QoS protocols.
>
> > Also, has it been specified by any other body like 3GPP
> which has chosen
> > SIP for signaling?
>
> Yes, 3gpp has its own mechanisms that are specific to 3gpp. As I
> understand they are built into the GPRS procedures, and reservation
> occurs only on the wireless link.
>
> -Jonathan R.
>
> --
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>

------_=_NextPart_001_01C2B72C.A56F8B30-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Jan 8 11:01:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23184 for ; Wed, 8 Jan 2003 11:01:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08GCjE32094 for sip-archive@odin.ietf.org; Wed, 8 Jan 2003 11:12:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08GCMJ32073; Wed, 8 Jan 2003 11:12:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08GBTJ32025 for ; Wed, 8 Jan 2003 11:11:29 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23101 for ; Wed, 8 Jan 2003 10:59:43 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h08G2sT15268; Wed, 8 Jan 2003 11:02:54 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 11:02:55 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E10C@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Frank W. Miller'" , Dean Willis Cc: sip@ietf.org, "James McEachern" , "Joe Zebarth" Subject: RE: [Sip] INFO considered harmful Date: Wed, 8 Jan 2003 11:02:53 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I don't know if there is a relationship, but Cisco brought just such a text-encoding proposal to ITU-T Study Group 11. I very much agree that if this proposal goes forward, it should use XML rather than some arbitrary TL-1-like language. > -----Original Message----- > From: Frank W. Miller [mailto:fmiller@sentito.com] > Sent: Friday, January 03, 2003 7:02 PM > To: Dean Willis > Cc: sip@ietf.org > Subject: Re: [Sip] INFO considered harmful > > > > > Well, any illusion of reasonableness I may have garnered in > the past is about to be shattered. I would refer folks to: > > http://www.ietf.org/internet-drafts/draft-miller-sip-isup-annex-00.txt > > This draft is about to receive a major -01 update that > recodes the entire syntax in XML. In addition, we (I) have > another draft that does something very similar for ANSI TCAP > that I'll be submitting in short order. I guess its only > appropriate that I bring peoples attention to these drafts > under the current subject heading... > > FM > > Frank W. Miller, Ph.D. > Chief Technical Officer > sentitO Networks, Inc. > fmiller@sentito.com > > ----- Original Message ----- > From: "Dean Willis" > To: "'Neil Deason'" ; "'Adam Roach'" > > Cc: > Sent: Friday, January 03, 2003 6:13 PM > Subject: RE: [Sip] INFO considered harmful > > > > > What I was actually advocating here was ppl wanting to keep INFO > > > around write up something to illuminate INFO packages and provide > > > example usage. > > > > > > The MESSAGE cf INFO was just an attempt to highlight an apparent > > > limitation with the ban INFO approach. Every MIME type in an INFO > > > can be moved into MESSAGE rather than go away. Maybe through > > > exploring INFO packages we evolve the collective > understanding that > > > this is/isn't a necessary thing. > > > > > > Cheers, > > > Neil. > > > > This is an excellent suggestion, and very similar to the > one Jonathan > > made to me on the phone yesterday (actually, I think he > more tersely > > worded it > as > > "Send Text!") > > > > -- > > 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 mailnull@www1.ietf.org Wed Jan 8 15:09:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05216 for ; Wed, 8 Jan 2003 15:09:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08KKM318779 for sip-archive@odin.ietf.org; Wed, 8 Jan 2003 15:20:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08KIEJ18629; Wed, 8 Jan 2003 15:18:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08KCdJ18424 for ; Wed, 8 Jan 2003 15:12:39 -0500 Received: from pots.cmguc.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04798 for ; Wed, 8 Jan 2003 15:00:47 -0500 (EST) Received: from nattyw2k ([10.239.68.217]) by pots.cmguc.com (Mirapoint Messaging Server MOS 3.2.0.52-EA) with ESMTP id ABX02469; Wed, 8 Jan 2003 15:02:39 -0500 (EST) From: "Louis Alexander" To: Date: Wed, 8 Jan 2003 15:03:44 -0500 Message-ID: <003701c2b751$0c0344d0$d944ef0a@nattyw2k> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0038_01C2B727.232D3CD0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Sip] Bulk registration Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0038_01C2B727.232D3CD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello Everyone, Can anyone point me to a draft that proposes a method for bulk registration? That is, a UA performing a bulk registration for a domain address, or a telephone number wild card? Louis G. Alexander Software Engineer CMG Wireless Data Solutions +1 804 935 4707 (SNR) louis.alexander@cmg.com ------=_NextPart_000_0038_01C2B727.232D3CD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hello=20 Everyone,
    Can anyone point me to a draft that proposes a method for bulk=20 registration?  That is, a UA performing a bulk registration for a = domain=20 address, or a telephone number wild card? 
 
Louis G. = Alexander
Software = Engineer
CMG Wireless Data = Solutions
+1 804 935 4707 = (SNR)
louis.alexander@cmg.com
 
------=_NextPart_000_0038_01C2B727.232D3CD0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Jan 8 16:27:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07964 for ; Wed, 8 Jan 2003 16:27:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08LdC123976 for sip-archive@odin.ietf.org; Wed, 8 Jan 2003 16:39:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08LabJ23268; Wed, 8 Jan 2003 16:36:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08LYFJ23172 for ; Wed, 8 Jan 2003 16:34:15 -0500 Received: from fox.iptel.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07731 for ; Wed, 8 Jan 2003 16:22:21 -0500 (EST) Received: from jku07.iptel.org (port-212-202-200-57.reverse.qdsl-home.de [212.202.200.57]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id h08LOs316498; Wed, 8 Jan 2003 22:24:54 +0100 Message-Id: <5.2.0.9.0.20030108222456.027fceb8@iptel.org> X-Sender: jiri@iptel.org (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 08 Jan 2003 22:25:00 +0100 To: Henry Sinnreich , "'Mark Watson'" , "'Pianigiani, Jacopo (Jacopo)'" , "'Jonathan Rosenberg'" , "'Mukul Purohit'" From: Jiri Kuthan Subject: RE: [Sip] resource reservation Cc: sip@ietf.org In-Reply-To: <003001c2b727$cef622c0$5d7032a6@hsinnreich2> References: < Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , At 04:08 PM 1/8/2003, Henry Sinnreich wrote: >>3) The Go interface is COPS-PR, not Diameter. >yes, and RADIUS in wireline systems. Also not DIAMETER. Let my add my two cents: quite many our users are interesterd in use of RADIUS for SIP accounting, and there is zero interest in diameter. The reason is there is a widely deployed RADIUS base. To operators, diameter benefits are apparently less compelling than the upgrade inconvenience. I'm sort of surprised, that the WG has ignored this situation and has not produced any document on use of RADIUS for SIP. -Jiri _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Jan 8 17:33:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10375 for ; Wed, 8 Jan 2003 17:33:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08Mia528710 for sip-archive@odin.ietf.org; Wed, 8 Jan 2003 17:44:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08MgYJ28658; Wed, 8 Jan 2003 17:42:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08MfVJ28556 for ; Wed, 8 Jan 2003 17:41:31 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10106 for ; Wed, 8 Jan 2003 17:29:37 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h08MVQ53014592; Wed, 8 Jan 2003 17:31:26 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 16:32:51 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A643F5@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Louis Alexander'" , sip@ietf.org Subject: RE: [Sip] Bulk registration Date: Wed, 8 Jan 2003 16:32:49 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , What you want is TRIP, not SIP. See . /a -----Original Message----- From: Louis Alexander [mailto:louis.alexander@cmg.com] Sent: Wednesday, January 08, 2003 14:04 To: sip@ietf.org Subject: [Sip] Bulk registration Hello Everyone, Can anyone point me to a draft that proposes a method for bulk registration? That is, a UA performing a bulk registration for a domain address, or a telephone number wild card? Louis G. Alexander Software Engineer CMG Wireless Data Solutions +1 804 935 4707 (SNR) louis.alexander@cmg.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 mailnull@www1.ietf.org Wed Jan 8 17:52:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11535 for ; Wed, 8 Jan 2003 17:52:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08N3d429609 for sip-archive@odin.ietf.org; Wed, 8 Jan 2003 18:03:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08N1aJ29548; Wed, 8 Jan 2003 18:01:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08N0tJ29496 for ; Wed, 8 Jan 2003 18:00:55 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11338 for ; Wed, 8 Jan 2003 17:49:00 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h08MpejS005537; Wed, 8 Jan 2003 14:51:41 -0800 (PST) Received: from [10.32.254.182] (stealth-10-32-254-182.cisco.com [10.32.254.182]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id HSR00327; Wed, 8 Jan 2003 14:52:45 -0800 (PST) Date: Wed, 08 Jan 2003 17:52:01 -0500 From: "David R. Oran" To: Louis Alexander , sip@ietf.org Subject: Re: [Sip] Bulk registration Message-ID: <187373689.1042048321@[10.32.254.182]> In-Reply-To: <003701c2b751$0c0344d0$d944ef0a@nattyw2k> References: <003701c2b751$0c0344d0$d944ef0a@nattyw2k> X-Mailer: Mulberry/3.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --On Wednesday, January 08, 2003 3:03 PM -0500 Louis Alexander wrote: > > Hello Everyone, > Can anyone point me to a draft that proposes a method for bulk > registration? That is, a UA performing a bulk registration for a domain > address, or a telephone number wild card? There is none, because SIP does not support "bulk registrations". There are very good reasons why. This comes up periodically, so perhaps we should have an entry on this subject in the SIP FAQ if there is not one already. Instead, you probably want to look at TRIP or TGRP depending on exactly what you want to accomplish. > Louis G. Alexander > Software Engineer > CMG Wireless Data Solutions > +1 804 935 4707 (SNR) > louis.alexander@cmg.com > ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Jan 8 17:55:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11696 for ; Wed, 8 Jan 2003 17:55:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08N6Xs29707 for sip-archive@odin.ietf.org; Wed, 8 Jan 2003 18:06:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08N4RJ29662; Wed, 8 Jan 2003 18:04:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08N3xJ29625 for ; Wed, 8 Jan 2003 18:03:59 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11526 for ; Wed, 8 Jan 2003 17:52:04 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h08Mt08W032052; Wed, 8 Jan 2003 16:55:09 -0600 From: "Dean Willis" To: "'Prasanna Venkatesh'" , , Subject: RE: [Sip] SIP de-registration Date: Wed, 8 Jan 2003 16:54:53 -0600 Message-ID: <002301c2b768$fdac1430$100112ac@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h08N40J29626 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Prasanna said: >Jo said: >> Is it valid to reject a de-registration request? >> >> For example 'If a SIP terminal sends a de-registration >> request to a network while it still has an active session >> established, and the network rejects this request , is this >> correct behaviour. > Any registrar can reject a de-registration request anytime. > But rejecting a de-registration for the fact that a session > is active is a local implementation. In general the > registration is used to locate an entity and theoritically > after the session is established, the registration is > immaterial. Cheers, Prasanna I believe Prasanna is correct here, in general. SIP does not view REGISTER as a "log on for service" -- rather, it is an address binding function that makes a temporary association between a (presumbaly temporary) local instance address and a (presumbaly long-lived) address-of-record. In particular, SIP does not require that a UA have a current registration or execute a REGISTER transaction before executing an INVITE transaction request. 3GPP (and consequently 3GPP2) have however layered some extra roles on top of the SIP REGISTER transaction. In these environments, REGISTER is a sort of "log on" operation in that it establishes the security association between a client and registrar that will be used for (some) future interactions between that client and registrar. Consequently, answering the question that Jo asked requires knowing whether the 3GPP system discards the security association established by a REGISTER request if the registration created by that request is destroyed. The answer, unfortunately, is "I don't know. The IETF doesn't know. Maybe somebody more conversant with that particular bit of 3GPPP knows (and they're probably reading this)." But in short, it is an environment specific question related to a specific implementation having done something just a bit different from generic SIP. In straight SIP, the registrar can terminate a registration without impacting any sessions that a UA is participating in. In fact, the registrar usually doesn't know or care whether a UA has or will ever have participated in a session. My guess is that this would probably be implementation-depdendent in the S-CSCF, and that if I were designing an S-CSCF, I'd have it not discard SA-state until after all transacations on that SA had terminated. A second choice would be to design it to use network-initiated-termination procedures to force-terminate any sessions before discarding the security associations. -- 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 mailnull@www1.ietf.org Wed Jan 8 17:58:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11773 for ; Wed, 8 Jan 2003 17:58:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08N9Uq30427 for sip-archive@odin.ietf.org; Wed, 8 Jan 2003 18:09:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08N7QJ30065; Wed, 8 Jan 2003 18:07:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08N4BJ29639 for ; Wed, 8 Jan 2003 18:04:11 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11538 for ; Wed, 8 Jan 2003 17:52:16 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h08Mt08Y032052; Wed, 8 Jan 2003 16:55:24 -0600 From: "Dean Willis" To: "'Jonathan Rosenberg'" Cc: Subject: RE: [Sip] INFO considered harmful Date: Wed, 8 Jan 2003 16:54:53 -0600 Message-ID: <002501c2b769$03dfc180$100112ac@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <3E18E9C4.5030405@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h08N4BJ29640 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > > No, EVENTS doesn't define semantics. > > Of course it does. There are lots of MAYS, MUSTS and SHOULDs > in there. > There is behavior dealing with subscription refreshes, rules > on when to > send NOTIFY, and so on and so on. How can you say that none of those > qualify as semantics? That's called a "protocol specification", not a specification of the semanticsd of the delivered content. What does a NOTIFY mean? Does it mean that I have voice mail and I should poll it? Does it mean that somebody has subscribed to my presence and I should adjust my authorization policy? Does it mean that my laundry is done and I should go pick it up? Does it mean that the IRS is going to audit my books and I should flee for the border? You can't answer this question, in general, because those semantics are NOT defined in RFC 3265. They're defined in event packages. Similarly, we complain because the INFO spec doen't tell us what an INFO means. Should we convert the body to ISUP? Should we execute the operator now? Should the phone explode? The INFO spec should no more answer this than does the Events spec. The semantic encoding is a separate problem. Now, here's the difference. I don't think you're talking about the presence of semantic information. I think you're talking about the absence of a mechanism for documenting the semantic information. Event packages give us this mechanism for events. We don't have anything like that for INFO. You're not talking semantics -- you're talking tools for exchanging meta-semantics. > > > Event PACKAGES define the semantics of > > particular instances of the event methods. > > Within a well defined framework. 3265 defines clear rules on > what each > package has to specify, and what it can and cannot due ontop > of rfc3265. > > > > INFO also needs a blob-describing-and-encoding framework, > so that the > > various uses of INFO can, as appropriate, be effectively documented > > and negotiated. > > Well, I'll try one more time, since I am clearly not getting my point > across. > > RFC3265 defines semantics above and beyond RFC3261. All of those > MAY/MUST/SHOULD I was talking about. If you had a choice between > defining a new package, and defining your own sub/not mechanisms, it > would be a LOT more work to define your own sub/not mechanisms. huh? It would be much more work to independently reimplement the functionality of INFO than it is to encode some information into MIME and ship it via INFO, especially given that the main functionality of INFO is correlated resolution with an existing dialog (identical rendezvous). > Not so for INFO. WHen deciding whether to specify an INFO usage, or a > new method, there is no additional work to do > (specification-wise) when > specifying a new method as opposed to a new INFO usage. To me, that > means that INFO is devoid of semantics. No, it just means that the process for defining a new INFO usage is broken. -- 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 mailnull@www1.ietf.org Wed Jan 8 21:01:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16864 for ; Wed, 8 Jan 2003 21:01:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h092DOA07654 for sip-archive@odin.ietf.org; Wed, 8 Jan 2003 21:13:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h092BHJ07580; Wed, 8 Jan 2003 21:11:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0929pJ07511 for ; Wed, 8 Jan 2003 21:09:51 -0500 Received: from mtiwmhc12.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16804 for ; Wed, 8 Jan 2003 20:57:52 -0500 (EST) Received: from cs.columbia.edu ([12.92.123.173]) by mtiwmhc12.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030109020108.UOZT12483.mtiwmhc12.worldnet.att.net@cs.columbia.edu>; Thu, 9 Jan 2003 02:01:08 +0000 Message-ID: <3E1CD751.2020606@cs.columbia.edu> Date: Wed, 08 Jan 2003 20:58:41 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jiri Kuthan CC: sip@ietf.org Subject: Re: [Sip] resource reservation References: < <5.2.0.9.0.20030108222456.027fceb8@iptel.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit There is a long-expired document on this topic; draft-schulzrinne-sipping-radius-accounting-00.txt You can find it in the musty corners of http://www.cs.columbia.edu/sip/drafts/ By reading it, you will lose all your political correctness points. Jiri Kuthan wrote: > At 04:08 PM 1/8/2003, Henry Sinnreich wrote: > >>>3) The Go interface is COPS-PR, not Diameter. >> >>yes, and RADIUS in wireline systems. Also not DIAMETER. > > > Let my add my two cents: quite many our users are interesterd > in use of RADIUS for SIP accounting, and there is zero interest > in diameter. The reason is there is a widely deployed RADIUS > base. To operators, diameter benefits are apparently less > compelling than the upgrade inconvenience. I'm sort of > surprised, that the WG has ignored this situation and has > not produced any document on use of RADIUS for SIP. > > -Jiri > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Jan 9 02:01:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24613 for ; Thu, 9 Jan 2003 02:01:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h097DXr28217 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 02:13:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h097BKJ25503; Thu, 9 Jan 2003 02:11:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBV1PHJ09055 for ; Mon, 30 Dec 2002 20:25:17 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05098 for ; Mon, 30 Dec 2002 20:17:44 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gBV1KMjS029808 for ; Mon, 30 Dec 2002 17:20:22 -0800 (PST) Received: from bhadoria-lnx.cisco.com (bhadoria-lnx.cisco.com [128.107.140.160]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABS41358; Mon, 30 Dec 2002 17:20:50 -0800 (PST) Date: Mon, 30 Dec 2002 17:20:50 -0800 (PST) From: Amit Bhadoria To: sip@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] [TLS] how to validate multiple domains with single certificate Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , hi, i have some questions based on rfc 3263 "locating sip services". in rfc 3263 it is mentioned that: "For NAPTR records with SIPS protocol fields, (if the server is using a site certificate), the domain name in the query and the domain name in the replacement field MUST both be valid based on the site certificate handed out by the server in the TLS exchange. Similarly, the domain name in the SRV query and the domain name in the target in the SRV record MUST both be valid based on the same site certificate. Otherwise, an attacker could modify the DNS records to contain replacement values in a different domain, and the client could not validate that this was the desired behavior or the result of an attack." now, there are three potentially different domains in concern while processing a SIPS request: 1. domain used in NAPTR querry: this is the target domain for this request 2. domain mentioned in replacement field of NAPTR records: this is the domain used in the SRV querry, obtained from replacement field of NAPTR records 3. domain mentioned in target in the SRV record: the domain mentioned in the SRV record selected for final A lookup is it possible to have all the three domains different, or is it just a bad example (due to my limited knowledge of DNS setups), and in practical cases the three domains will either be same as TARGET or a subdomain of it? incase my imagination is correct, and it is possible to have a setup where all three domains (from three steps of DNS procedures) are different, then how can a client validate these three domains using the same certificate? i'd appreciate your comments/explanation to my querries. thanks, -amit. ---------------------------------------------------------------------------- I have hardly ever known a mathematician who was capable of reasoning. -- gnulib _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 9 02:03:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27011 for ; Thu, 9 Jan 2003 02:03:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h097FNU30244 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 02:15:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h097DJJ26406; Thu, 9 Jan 2003 02:13:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h01CYcJ28678 for ; Wed, 1 Jan 2003 07:34:38 -0500 Received: from www.postmark.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03312 for ; Wed, 1 Jan 2003 07:26:19 -0500 (EST) Received: (qmail 13447 invoked by uid 500); 1 Jan 2003 12:29:30 -0000 Message-ID: <20030101122930.13446.qmail@www.postmark.net> Received: from 210.210.49.173 by www.postmark.net with HTTP; 01 Jan 2003 12:29:30 -0000 Mime-Version: 1.0 From: CS To: sip@ietf.org Date: Wed, 01 Jan 2003 12:29:30 +0000 Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Sip REGISTRATION Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi I am new to SIP Registration process. I have the following doubt: In a UA REGISTERation process with a proxy/registrar, the Unauthourized(407) is posed against the To OR the From header of the Register request? i.e, the Registrar tries to authorize the to hreader URI or the From header URI ( in the case when ther are different as in for a third party registration )? Please help! Thanks CS __________________________________ csa@postmark.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 mailnull@www1.ietf.org Thu Jan 9 02:07:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02053 for ; Thu, 9 Jan 2003 02:07:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h097JDO31557 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 02:19:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h097H8J30956; Thu, 9 Jan 2003 02:17:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03HvhJ10654 for ; Fri, 3 Jan 2003 12:57:43 -0500 Received: from exchange.cedarpointcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14332 for ; Fri, 3 Jan 2003 12:48:21 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 3 Jan 2003 12:52:22 -0500 Message-ID: <66F2ACFAB4E7764EAF85274020DD5342573110@exchange.cedarpointcom.com> Thread-Topic: free SIP stack? Thread-Index: AcKzUN2Ypdik2wlGQw+HgoGkMI5Mgw== From: "Yuyong Zhang" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h03HvhJ10655 Subject: [Sip] free SIP stack? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi there, Could anybody please recommend a good and free SIP stack? Regards, Yuyong _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 9 02:09:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02176 for ; Thu, 9 Jan 2003 02:09:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h097LKH31692 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 02:21:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h097J3J31551; Thu, 9 Jan 2003 02:19:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h066ejJ16208 for ; Mon, 6 Jan 2003 01:40:45 -0500 Received: from web13310.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA17542 for ; Mon, 6 Jan 2003 01:30:07 -0500 (EST) Message-ID: <20030106063322.85884.qmail@web13310.mail.yahoo.com> Received: from [61.11.48.16] by web13310.mail.yahoo.com via HTTP; Sun, 05 Jan 2003 22:33:22 PST Date: Sun, 5 Jan 2003 22:33:22 -0800 (PST) From: kamaraju krishna Subject: [Sip] about md5 algorithm for authorization header To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , HELLO SIR, I read document in RFC 1321 .But i have some ploblem i don't understand in request-digest =<"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) ><"> request-digest = "KD(H(A1),unq(nonce-value) ":" H(A2) )" A1 = unq(username-value) ":" unq(realm-value) ":" passwd A2 = Method ":" digest-uri-value what KD?,H? weather This equation is correct or not ? KD(H(A1), unq(nonce-value) ":" H(A2)) = MD5(H (A1), unq(nonce-value) ":" H(A2)) Thanking you.. Regards krishna __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 9 02:17:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02385 for ; Thu, 9 Jan 2003 02:17:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h097TJa32563 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 02:29:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h097RHJ32410; Thu, 9 Jan 2003 02:27:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h097LFJ31688 for ; Thu, 9 Jan 2003 02:21:15 -0500 Received: from fthsmtp01.cbsinc.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02157 for ; Thu, 9 Jan 2003 02:09:09 -0500 (EST) Received: by fthsmtp01 with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 02:12:37 -0500 Message-ID: From: KANUMURI Sreeram To: "'Yuyong Zhang'" , sip@ietf.org Subject: RE: [Sip] free SIP stack? Date: Thu, 9 Jan 2003 02:12:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , see www.vovida.org you can get the source code in C++ -Sreeram -----Original Message----- From: Yuyong Zhang [mailto:yzhang@cedarpointcom.com] Sent: Friday, January 03, 2003 11:22 PM To: sip@ietf.org Subject: [Sip] free SIP stack? Hi there, Could anybody please recommend a good and free SIP stack? Regards, Yuyong _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Jan 9 03:42:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03944 for ; Thu, 9 Jan 2003 03:42:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h098rms05971 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 03:53:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h098peJ05914; Thu, 9 Jan 2003 03:51:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h098oHJ05836 for ; Thu, 9 Jan 2003 03:50:17 -0500 Received: from iisc.ernet.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03873 for ; Thu, 9 Jan 2003 03:38:06 -0500 (EST) Received: from hirp.iisc.ernet.in (hirp.iisc.ernet.in [144.16.94.229]) by iisc.ernet.in (8.9.2/8.9.0) with ESMTP id OAA23088; Thu, 9 Jan 2003 14:13:39 +0530 (IST) Received: from localhost (john@localhost) by hirp.iisc.ernet.in (8.11.2/8.8.7) with ESMTP id h098mCC32275; Thu, 9 Jan 2003 14:18:13 +0530 Date: Thu, 9 Jan 2003 14:18:12 +0530 (IST) From: John J C To: KANUMURI Sreeram cc: "'Yuyong Zhang'" , Subject: RE: [Sip] free SIP stack? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , try osip. The source code is in C . U can get it at the following URL. http://freesoftware.fsf.org/download/osip/libosip-0.8.0.tar.gz John John J Chooracken Senior Engineer - R&D HFCL-IISC Research Program IISc Campus - Bangalore - 560 012 Voice: (+91)-80-3562062 Email: john@hirp.iisc.ernet.in chooracken@yahoo.com On Thu, 9 Jan 2003, KANUMURI Sreeram wrote: > > see www.vovida.org you can get the source code in C++ > > > -Sreeram > > -----Original Message----- > From: Yuyong Zhang [mailto:yzhang@cedarpointcom.com] > Sent: Friday, January 03, 2003 11:22 PM > To: sip@ietf.org > Subject: [Sip] free SIP stack? > > > Hi there, > > Could anybody please recommend a good and free SIP stack? > > Regards, > > Yuyong > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Jan 9 03:45:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04073 for ; Thu, 9 Jan 2003 03:45:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h098vDk06158 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 03:57:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h098tAJ06086; Thu, 9 Jan 2003 03:55:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h098slJ06044 for ; Thu, 9 Jan 2003 03:54:47 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03984 for ; Thu, 9 Jan 2003 03:42:39 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h098jqAv022109; Thu, 9 Jan 2003 09:45:52 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZQ1FSL89; Thu, 9 Jan 2003 09:45:49 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h098jmu4017114; Thu, 9 Jan 2003 10:45:48 +0200 (EET) Message-ID: <3E1D36BD.65F07CB6@lmf.ericsson.se> Date: Thu, 09 Jan 2003 10:45:49 +0200 X-Sybari-Trust: 68ce2973 1864f774 d5511081 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: Adam Roach , Eric Burger , sip@ietf.org Subject: Re: [Sip] INFO considered harmful References: <9BF66EBF6BEFD942915B4D4D45C051F3A643C6@DYN-TX-EXCH-001.dynamicsoft.com> <3E15F0ED.7070002@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, > Your example clearly falls into the "> 10" category as the poor web > server had to deal with every Real audio or video packet. Not that it > would surprise me, but I don't think anybody *here* has suggested > RTP-over-INFO so far. Isn't that part of the missuse problem we are talking about here - that someone actually COULD start using INFO for sending RTP (or whatever else that would creating frequent message sending)? Regards, Christer Holmberg Ericsson Finland > > > Adam Roach wrote: > >>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >> > >>In general, I just don't buy server load arguments. If it's a > >>useful service, server cost is usually the least of the problem. > >>In any event, one should take this as a fraction of the existing > >>signaling load, not as some absolute number. I'm worried about > >>stuff that multiplies the signaling load by a factor of 10; I find > >>20 or 50% load increase uninteresting as an argument. > > > > > > You don't buy server load arguments? Real-world experience > > notwithstanding? > > > > I'm recalling the rise in popularity of Real Media Player and > > its ability to set up an audio stream through an HTTP proxy. > > In particular, I'm recalling conversations shortly thereafter > > with some friends over in MIS about how they just couldn't add > > capacity to the HTTP proxy pool fast enough to keep up with > > demand. > > > > Access to external web documents sometimes creeped up to the > > order of minutes before everything was finally stabilized. > > > > How long do you guess it will be before Real player > > (or a similar product) includes a "SIP Proxy:" field right > > next to its "HTTP Proxy:" field for firewall circumvention? > > > > /a > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 9 03:48:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04227 for ; Thu, 9 Jan 2003 03:48:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0990Bt06354 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 04:00:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h098wBJ06242; Thu, 9 Jan 2003 03:58:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h098vfJ06211 for ; Thu, 9 Jan 2003 03:57:41 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04071 for ; Thu, 9 Jan 2003 03:45:33 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h098mkAv022826; Thu, 9 Jan 2003 09:48:46 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZQ1FSM4Y; Thu, 9 Jan 2003 09:48:46 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h098mku4017189; Thu, 9 Jan 2003 10:48:46 +0200 (EET) Message-ID: <3E1D376F.EF4CCCFF@lmf.ericsson.se> Date: Thu, 09 Jan 2003 10:48:47 +0200 X-Sybari-Trust: 6e188ce7 1864f774 d5511081 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: Adam Roach , "'Neil Deason'" , sip@ietf.org Subject: Re: [Sip] INFO considered harmful References: <9BF66EBF6BEFD942915B4D4D45C051F3A643C3@DYN-TX-EXCH-001.dynamicsoft.com> <3E14E655.9030805@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, > Actually, there's an important difference: MESSAGE can use the SIP > features outside an established session, while INFO is within a session > (and thus there are other SDP-negotiated, options available). Within a > session, the only real reason for a follow-the-INVITE SIP message is > that a direct IP-level connection can't be made to work. [CHH] Please remember that in SIP-T there are needs to send INFO BEFORE the 200 OK has been sent for INVITE, which means the SDP negoatiation MAY not be finished yet. I don't know about any other mechanisms using INFO which require to be able to do the same, but just to keep in mind... Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 9 04:35:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05288 for ; Thu, 9 Jan 2003 04:35:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h099lXF09694 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 04:47:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h099ZoJ08587; Thu, 9 Jan 2003 04:35:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h099WtJ08459 for ; Thu, 9 Jan 2003 04:32:55 -0500 Received: from mailgate.siemenscomms.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05033 for ; Thu, 9 Jan 2003 04:20:45 -0500 (EST) Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #45905) id <0H8F00201WRONR@siemenscomms.co.uk> for sip@ietf.org; Thu, 09 Jan 2003 09:23:48 +0000 (GMT) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0H8F0023ZWROG3@siemenscomms.co.uk>; Thu, 09 Jan 2003 09:23:48 +0000 (GMT) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Thu, 09 Jan 2003 09:24:01 +0000 Content-return: allowed Date: Thu, 09 Jan 2003 09:24:13 +0000 From: "Elwell, John" Subject: RE: [Sip] I-D ACTION:draft-rosenberg-sip-info-harmful-00.txt To: "'jdrosen@dynamicsoft.com'" Cc: sip@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Jonathan, I would appreciate some clarification on the scope of solution 3, i.e., the scope of INFO usage for SIP-T. INFO usage for SIP-T is for transparently conveying ISUP messages across a SIP network between two ISUP gateways. There is a similar requirement for conveying other protocols between peer gateways: QSIG (for which a MIME type is already defined) and also DPNSS (for which there is a proposal for a MIME type). Both of these require the transport of messages of the protocol concerned at times when no other SIP request or response is being sent, and INFO would be the obvious candidate for this. It would be inappropriate to invent different solutions for what is basically the same problem but just different transported protocols. John Elwell e-mail: mailto:john.elwell@siemens.com > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: 07 January 2003 13:29 > Cc: sip@ietf.org > Subject: [Sip] I-D ACTION:draft-rosenberg-sip-info-harmful-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : The Session Initiation Protocol (SIP) > INFO Method > Considered Harmful > Author(s) : J. Rosenberg > Filename : draft-rosenberg-sip-info-harmful-00.txt > Pages : 11 > Date : 2003-1-6 > > The Session Initiation Protocol (SIP) INFO method defines a means for > transporting mid-dialog application layer data between user agents. > Its initial use was to support the transport of ISUP mid-call > messages which could not be mapped to any other SIP request method. > However, since its initial usage for that purpose, INFO has seen > widespread abuse as a means for introducing non-standard and > non-interoperable extensions to SIP. For this reason, we now believe > INFO should be considered harmful, and therefore, deprecated in its > current form. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-info-h armful-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rosenberg-sip-info-harmful-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-rosenberg-sip-info-harmful-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. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 9 04:40:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05392 for ; Thu, 9 Jan 2003 04:40:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h099qR309902 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 04:52:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h099oKJ09818; Thu, 9 Jan 2003 04:50:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h099nsJ09767 for ; Thu, 9 Jan 2003 04:49:54 -0500 Received: from fox.iptel.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05310 for ; Thu, 9 Jan 2003 04:37:44 -0500 (EST) Received: from jku07.fokus.fraunhofer.de (port-212-202-168-133.reverse.qdsl-home.de [212.202.168.133]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id h099em304520; Thu, 9 Jan 2003 10:40:48 +0100 Message-Id: <5.2.0.9.0.20030109103823.02cfee60@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 09 Jan 2003 10:40:50 +0100 To: Henning Schulzrinne , Jiri Kuthan From: Jiri Kuthan Subject: radius (was Re: [Sip] resource reservation Cc: sip@ietf.org In-Reply-To: <3E1CD751.2020606@cs.columbia.edu> References: < <5.2.0.9.0.20030108222456.027fceb8@iptel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Actually, we have implemented it and it is fine. I'm just concerned about lack of a standard -- that makes interaction of accounting apps with SIP servers difficult. I would really like to see it as a WG item. -Jiri At 02:58 AM 1/9/2003, Henning Schulzrinne wrote: >There is a long-expired document on this topic; draft-schulzrinne-sipping-radius-accounting-00.txt > >You can find it in the musty corners of http://www.cs.columbia.edu/sip/drafts/ > >By reading it, you will lose all your political correctness points. > >Jiri Kuthan wrote: >>At 04:08 PM 1/8/2003, Henry Sinnreich wrote: >> >>>>3) The Go interface is COPS-PR, not Diameter. >>> >>>yes, and RADIUS in wireline systems. Also not DIAMETER. >> >>Let my add my two cents: quite many our users are interesterd >>in use of RADIUS for SIP accounting, and there is zero interest >>in diameter. The reason is there is a widely deployed RADIUS >>base. To operators, diameter benefits are apparently less >>compelling than the upgrade inconvenience. I'm sort of >>surprised, that the WG has ignored this situation and has >>not produced any document on use of RADIUS for SIP. >>-Jiri >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Jan 9 04:46:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05490 for ; Thu, 9 Jan 2003 04:46:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h099wVC10173 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 04:58:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h099uOJ10089; Thu, 9 Jan 2003 04:56:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h099rKJ09941 for ; Thu, 9 Jan 2003 04:53:20 -0500 Received: from mailhost.wellx.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA05413 for ; Thu, 9 Jan 2003 04:41:09 -0500 (EST) Received: from mail.wellx.com by mailhost.wellx.com via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 9 Jan 2003 09:31:48 UT Received: from wellx.com (192.168.1.66 [192.168.1.66]) by srvwellx.wellx.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CFK770L3; Thu, 9 Jan 2003 10:44:54 +0100 Message-ID: <3E1D4794.EFF000E3@wellx.com> Date: Thu, 09 Jan 2003 10:57:40 +0100 From: Aymeric MOIZARD Organization: WellX X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.20 i686) X-Accept-Language: en MIME-Version: 1.0 To: John J C CC: KANUMURI Sreeram , "'Yuyong Zhang'" , sip@ietf.org Subject: Re: [Sip] free SIP stack? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This is a very old version of osip. The latest is: http://ftp.gnu.org/gnu/osip/libosip-0.9.3.tar.gz Thanks Aymeric John J C wrote: > > try osip. The source code is in C . U can get it at the following URL. > > http://freesoftware.fsf.org/download/osip/libosip-0.8.0.tar.gz > > John > > John J Chooracken > Senior Engineer - R&D > HFCL-IISC Research Program > IISc Campus - Bangalore - 560 012 > Voice: (+91)-80-3562062 > Email: john@hirp.iisc.ernet.in > chooracken@yahoo.com > > On Thu, 9 Jan 2003, KANUMURI Sreeram wrote: > > > > > see www.vovida.org you can get the source code in C++ > > > > > > -Sreeram > > > > -----Original Message----- > > From: Yuyong Zhang [mailto:yzhang@cedarpointcom.com] > > Sent: Friday, January 03, 2003 11:22 PM > > To: sip@ietf.org > > Subject: [Sip] free SIP stack? > > > > > > Hi there, > > > > Could anybody please recommend a good and free SIP stack? > > > > Regards, > > > > Yuyong > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Jan 9 05:55:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06597 for ; Thu, 9 Jan 2003 05:55:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09B7Ue14579 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 06:07:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09B5AJ14000; Thu, 9 Jan 2003 06:05:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09AxNJ13806 for ; Thu, 9 Jan 2003 05:59:23 -0500 Received: from ihemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06542 for ; Thu, 9 Jan 2003 05:47:14 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h09AoTN05805 for ; Thu, 9 Jan 2003 05:50:29 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 10:50:28 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EB89@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Dean Willis'" , "'Jonathan Rosenberg'" Cc: sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Thu, 9 Jan 2003 10:50:17 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Maybe Adam wrote the original slightly stronger than I would, but the NOTIFY method itself does carry semantics. Those semantics are that it is carrying information defined as an event. Obviously you need to read the relevant headers and the body to find out what sort of event, but until you read the string "NOTIFY" at the start of the received PDU, you do not know you are looking for an event. Obviously there are also normative requirements to understanding how it fits in a dialog, but I agree, that is part of the protocol specification rather than semantics of the method. As such it is not carried unstructured information (INFO), or information defined as fulfilling instant messaging requirements (MESSAGE). Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 08 January 2003 22:55 > To: 'Jonathan Rosenberg' > Cc: sip@ietf.org > Subject: RE: [Sip] INFO considered harmful > > > > > No, EVENTS doesn't define semantics. > > > > Of course it does. There are lots of MAYS, MUSTS and SHOULDs > > in there. > > There is behavior dealing with subscription refreshes, rules > > on when to > > send NOTIFY, and so on and so on. How can you say that none > of those > > qualify as semantics? > > > That's called a "protocol specification", not a specification of the > semanticsd of the delivered content. > > What does a NOTIFY mean? Does it mean that I have voice mail > and I should > poll it? Does it mean that somebody has subscribed to my > presence and I > should adjust my authorization policy? Does it mean that my > laundry is done > and I should go pick it up? Does it mean that the IRS is > going to audit my > books and I should flee for the border? > > You can't answer this question, in general, because those > semantics are NOT > defined in RFC 3265. They're defined in event packages. > > Similarly, we complain because the INFO spec doen't tell us > what an INFO > means. Should we convert the body to ISUP? Should we execute > the operator > now? Should the phone explode? The INFO spec should no more > answer this than > does the Events spec. The semantic encoding is a separate problem. > > Now, here's the difference. I don't think you're talking > about the presence > of semantic information. I think you're talking about the absence of a > mechanism for documenting the semantic information. Event > packages give us > this mechanism for events. We don't have anything like that > for INFO. You're > not talking semantics -- you're talking tools for exchanging > meta-semantics. > > > > > > Event PACKAGES define the semantics of > > > particular instances of the event methods. > > > > Within a well defined framework. 3265 defines clear rules on > > what each > > package has to specify, and what it can and cannot due ontop > > of rfc3265. > > > > > > > INFO also needs a blob-describing-and-encoding framework, > > so that the > > > various uses of INFO can, as appropriate, be effectively > documented > > > and negotiated. > > > > Well, I'll try one more time, since I am clearly not > getting my point > > across. > > > > RFC3265 defines semantics above and beyond RFC3261. All of those > > MAY/MUST/SHOULD I was talking about. If you had a choice between > > defining a new package, and defining your own sub/not > mechanisms, it > > would be a LOT more work to define your own sub/not mechanisms. > > huh? > > It would be much more work to independently reimplement the > functionality of > INFO than it is to encode some information into MIME and ship > it via INFO, > especially given that the main functionality of INFO is correlated > resolution with an existing dialog (identical rendezvous). > > > Not so for INFO. WHen deciding whether to specify an INFO > usage, or a > > new method, there is no additional work to do > > (specification-wise) when > > specifying a new method as opposed to a new INFO usage. To me, that > > means that INFO is devoid of semantics. > > No, it just means that the process for defining a new INFO > usage is broken. > > -- > 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 mailnull@www1.ietf.org Thu Jan 9 07:53:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08303 for ; Thu, 9 Jan 2003 07:53:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09D53L20902 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 08:05:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09D2vJ20808; Thu, 9 Jan 2003 08:02:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09CxJJ20602 for ; Thu, 9 Jan 2003 07:59:19 -0500 Received: from mtiwmhc12.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08120 for ; Thu, 9 Jan 2003 07:47:07 -0500 (EST) Received: from cs.columbia.edu ([12.92.125.222]) by mtiwmhc12.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030109125023.CWIJ12483.mtiwmhc12.worldnet.att.net@cs.columbia.edu>; Thu, 9 Jan 2003 12:50:23 +0000 Message-ID: <3E1D6F7B.6060304@cs.columbia.edu> Date: Thu, 09 Jan 2003 07:47:55 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christer Holmberg CC: Adam Roach , Eric Burger , sip@ietf.org Subject: Re: [Sip] INFO considered harmful References: <9BF66EBF6BEFD942915B4D4D45C051F3A643C6@DYN-TX-EXCH-001.dynamicsoft.com> <3E15F0ED.7070002@cs.columbia.edu> <3E1D36BD.65F07CB6@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The same is true for any message. Heck, you could probably encapsulate RTP in ACK or (intentionally rejected) INVITE, if ACK or INVITE doesn't get charged. Christer Holmberg wrote: > Hi, > > >>Your example clearly falls into the "> 10" category as the poor web >>server had to deal with every Real audio or video packet. Not that it >>would surprise me, but I don't think anybody *here* has suggested >>RTP-over-INFO so far. > > > Isn't that part of the missuse problem we are talking about here - that > someone actually COULD start using INFO for sending RTP (or whatever else > that would creating frequent message sending)? > > Regards, > > Christer Holmberg > Ericsson Finland > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 9 08:09:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08610 for ; Thu, 9 Jan 2003 08:09:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09DLNh22037 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 08:21:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09DJKJ21960; Thu, 9 Jan 2003 08:19:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09DIaJ21911 for ; Thu, 9 Jan 2003 08:18:36 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08551 for ; Thu, 9 Jan 2003 08:06:23 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h09D93Av003353; Thu, 9 Jan 2003 14:09:03 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNLSWRJ; Thu, 9 Jan 2003 14:09:03 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h09D93u4002416; Thu, 9 Jan 2003 15:09:03 +0200 (EET) Message-ID: <3E1D7475.64386290@lmf.ericsson.se> Date: Thu, 09 Jan 2003 15:09:09 +0200 X-Sybari-Trust: 810ee10c 1864f774 d5511081 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: Adam Roach , Eric Burger , sip@ietf.org Subject: Re: [Sip] INFO considered harmful References: <9BF66EBF6BEFD942915B4D4D45C051F3A643C6@DYN-TX-EXCH-001.dynamicsoft.com> <3E15F0ED.7070002@cs.columbia.edu> <3E1D36BD.65F07CB6@lmf.ericsson.se> <3E1D6F7B.6060304@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, > The same is true for any message. Heck, you could probably encapsulate > RTP in ACK or (intentionally rejected) INVITE, if ACK or INVITE doesn't > get charged. That was exactly my point in the beginning of the thread, when I asked if we need to define what kind of message bodies/information we are allowed to include in INVITE and UPDATE. Regards, Christer Holmberg Ericsson Finland > > > Christer Holmberg wrote: > > Hi, > > > > > >>Your example clearly falls into the "> 10" category as the poor web > >>server had to deal with every Real audio or video packet. Not that it > >>would surprise me, but I don't think anybody *here* has suggested > >>RTP-over-INFO so far. > > > > > > Isn't that part of the missuse problem we are talking about here - that > > someone actually COULD start using INFO for sending RTP (or whatever else > > that would creating frequent message sending)? > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 9 09:17:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10547 for ; Thu, 9 Jan 2003 09:17:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09ETPk25803 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 09:29:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09ESIJ25738; Thu, 9 Jan 2003 09:28:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09EQpJ25666 for ; Thu, 9 Jan 2003 09:26:51 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10318; Thu, 9 Jan 2003 09:14:37 -0500 (EST) Message-Id: <200301091414.JAA10318@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org, sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 09 Jan 2003 09:14:37 -0500 Subject: [Sip] I-D ACTION:draft-miller-sip-tcap-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Carrying TCAP in SIP Messages (SIP-TCAP) Author(s) : F. Miller et al. Filename : draft-miller-sip-tcap-00.txt Pages : 0 Date : 2003-1-8 SIP-TCAP is a mechanism by which an XML representation of TCAP messages can be transported in the body of SIP INFO messages. This mechanism can be used to allow SIP elements to access features implemented by PSTN equipment without having to implement the binary TCAP protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-miller-sip-tcap-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-miller-sip-tcap-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-miller-sip-tcap-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-9092045.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-miller-sip-tcap-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-miller-sip-tcap-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-9092045.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 9 10:11:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13908 for ; Thu, 9 Jan 2003 10:11:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09FNRl30312 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 10:23:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FMOJ30178; Thu, 9 Jan 2003 10:22:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FLLJ30090 for ; Thu, 9 Jan 2003 10:21:21 -0500 Received: from mail.aastra.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13804 for ; Thu, 9 Jan 2003 10:09:06 -0500 (EST) Received: by mail.aastra.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 10:04:13 -0500 Message-ID: From: Vijay Gaur To: sip@ietf.org Date: Thu, 9 Jan 2003 10:03:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Handling for ACK for 400 Response Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, When a UAS received a malformed Invite Request, it would send back a 400 Response after parsing the message. It would not (or may not be able to) create a Transaction for the same. The Client on recieving this Response would respond with an ACK. The UAS would drop this ACK as an unhandled message, and would be reflected as an error on the same. The question is - Do we need a particular response code which would tell the client that an ACK for this should not be 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 mailnull@www1.ietf.org Thu Jan 9 10:29:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14591 for ; Thu, 9 Jan 2003 10:29:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09FfZJ32182 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 10:41:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FeZJ31987; Thu, 9 Jan 2003 10:40:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FaGJ30982 for ; Thu, 9 Jan 2003 10:36:16 -0500 Received: from mtiwmhc13.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14304 for ; Thu, 9 Jan 2003 10:24:00 -0500 (EST) Received: from cs.columbia.edu ([12.92.123.81]) by mtiwmhc13.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030109152717.ZCEE20003.mtiwmhc13.worldnet.att.net@cs.columbia.edu>; Thu, 9 Jan 2003 15:27:17 +0000 Message-ID: <3E1D9441.3060809@cs.columbia.edu> Date: Thu, 09 Jan 2003 10:24:49 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christer Holmberg CC: sip@ietf.org Subject: Re: [Sip] INFO considered harmful References: <9BF66EBF6BEFD942915B4D4D45C051F3A643C6@DYN-TX-EXCH-001.dynamicsoft.com> <3E15F0ED.7070002@cs.columbia.edu> <3E1D36BD.65F07CB6@lmf.ericsson.se> <3E1D6F7B.6060304@cs.columbia.edu> <3E1D7475.64386290@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The good guys don't need the restriction, the bad guys will ignore it. This all comes down to economic incentives: if it costs less to send a message of type foo than type bar (where 'costs less' may mean that the alternative has infinite cost, since the firewall won't let it pass), users will find that interesting, whether we proscribe it or not. We don't worry about what you can attach to an email message, even though this also consumes precious server resources. (We obviously should and do worry what you do to the shared network resources.) If a proxy wants to reject all INFO messager or rate-limit a particular sender or restrict the size or content of messages, that's its privilege. Christer Holmberg wrote: > Hi, > > >>The same is true for any message. Heck, you could probably encapsulate >>RTP in ACK or (intentionally rejected) INVITE, if ACK or INVITE doesn't >>get charged. > > > That was exactly my point in the beginning of the thread, when I asked if we > need to define what kind of message bodies/information we are allowed to > include in INVITE and UPDATE. > > Regards, > > Christer Holmberg > Ericsson Finland > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 9 10:38:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14967 for ; Thu, 9 Jan 2003 10:38:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09Fo6J00309 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 10:50:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FnJJ32744; Thu, 9 Jan 2003 10:49:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FmKJ32692 for ; Thu, 9 Jan 2003 10:48:20 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14938 for ; Thu, 9 Jan 2003 10:36:03 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h09FdJKV015606; Thu, 9 Jan 2003 16:39:19 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGM075W1; Thu, 9 Jan 2003 16:39:19 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h09FdJu4010583; Thu, 9 Jan 2003 17:39:19 +0200 (EET) Message-ID: <3E1D97AE.7516DBDC@lmf.ericsson.se> Date: Thu, 09 Jan 2003 17:39:26 +0200 X-Sybari-Trust: e09c71f3 1864f774 d5511081 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: sip@ietf.org Subject: Re: [Sip] INFO considered harmful References: <9BF66EBF6BEFD942915B4D4D45C051F3A643C6@DYN-TX-EXCH-001.dynamicsoft.com> <3E15F0ED.7070002@cs.columbia.edu> <3E1D36BD.65F07CB6@lmf.ericsson.se> <3E1D6F7B.6060304@cs.columbia.edu> <3E1D7475.64386290@lmf.ericsson.se> <3E1D9441.3060809@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, > The good guys don't need the restriction, the bad guys will ignore it. > This all comes down to economic incentives: if it costs less to send a > message of type foo than type bar (where 'costs less' may mean that the > alternative has infinite cost, since the firewall won't let it pass), > users will find that interesting, whether we proscribe it or not. > > We don't worry about what you can attach to an email message, even > though this also consumes precious server resources. (We obviously > should and do worry what you do to the shared network resources.) If a > proxy wants to reject all INFO messager or rate-limit a particular > sender or restrict the size or content of messages, that's its privilege. If that is the solution, I see no reason for this whole thread :) There is no idea to put any restrictions on INFO either, because the bad guys will ignore it anyway... Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 9 11:15:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16297 for ; Thu, 9 Jan 2003 11:15:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09GRYZ03173 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 11:27:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09GQRJ03112; Thu, 9 Jan 2003 11:26:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09GP8J03032 for ; Thu, 9 Jan 2003 11:25:08 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16190 for ; Thu, 9 Jan 2003 11:12:52 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h09GEU53017760; Thu, 9 Jan 2003 11:14:30 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 10:15:54 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A643F8@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Christer Holmberg'" , Henning Schulzrinne Cc: sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Thu, 9 Jan 2003 10:15:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > If that is the solution, I see no reason for this whole > thread :) There is no idea to put any restrictions on INFO > either, because the bad guys will ignore it anyway... Yes, people will do it. Unless we take up arms and start a massive intelligence effort, there's nothing we can do about that simple fact. The overarching question is: should the IETF lend these noninteroperable, potentially network-crippling approaches credibility? Allison? Does the IESG generally condone that sort of thing? /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 9 12:57:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19138 for ; Thu, 9 Jan 2003 12:57:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09I9d210882 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 13:09:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09I8YJ10817; Thu, 9 Jan 2003 13:08:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09I7pJ10761 for ; Thu, 9 Jan 2003 13:07:51 -0500 Received: from menelao.polito.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19047 for ; Thu, 9 Jan 2003 12:55:33 -0500 (EST) Received: (qmail 1937 invoked from network); 9 Jan 2003 17:58:49 -0000 Received: from unknown (HELO vaio) (130.192.1.123) by menelao.polito.it with SMTP; 9 Jan 2003 17:58:49 -0000 Message-ID: <001801c2b808$982d7400$7b01c082@vaio> From: "Roberto Tealdi" To: Subject: [SIP] Authentication based on SIP request Date: Thu, 9 Jan 2003 18:57:34 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C2B810.F84A94A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C2B810.F84A94A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi to All I'm new in SIP and I have a question: In draft "draft-ietf-sipping-aaa-req-01" is specified that the Home AAA = server must be able to authenticate a user based on any SIP Request = (except CANCEL): this means that ANY SIP request message (from client to = sip proxy) must contains a user's credentials, for example an = authentication token?=20 Thanks a lot. Roby. ------=_NextPart_000_0015_01C2B810.F84A94A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi to All
 
I'm new in SIP and I have a = question:
 
In draft = "draft-ietf-sipping-aaa-req-01" is=20 specified that the Home AAA server must be able to authenticate a user = based on=20 any SIP Request (except CANCEL): this means that ANY SIP=20 request message (from client to sip proxy) must contains a user's=20 credentials, for example an authentication token?
 
Thanks a lot.
Roby.
 
------=_NextPart_000_0015_01C2B810.F84A94A0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 9 14:34:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23693 for ; Thu, 9 Jan 2003 14:34:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09JkjI19017 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 14:46:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09JjhJ18949; Thu, 9 Jan 2003 14:45:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09JiRJ18873 for ; Thu, 9 Jan 2003 14:44:27 -0500 Received: from dgesmtp01.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23619 for ; Thu, 9 Jan 2003 14:32:07 -0500 (EST) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.wcom.com (Iplanet MTA) with ESMTP id <0H8G00MHRP12OB@firewall.wcom.com> for sip@ietf.org; Thu, 09 Jan 2003 19:34:14 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H8G00C01P11MD@dgismtp04.wcomnet.com>; Thu, 09 Jan 2003 19:34:14 +0000 (GMT) Received: from hsinnreich2 ([166.50.104.16]) by dgismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H8G00ALROYK5A@dgismtp04.wcomnet.com>; Thu, 09 Jan 2003 19:34:14 +0000 (GMT) Date: Thu, 09 Jan 2003 13:33:34 -0600 From: Henry Sinnreich Subject: RE: radius (was Re: [Sip] resource reservation In-reply-to: <5.2.0.9.0.20030109103823.02cfee60@mailhost.fokus.gmd.de> To: "'Jiri Kuthan'" , "'Henning Schulzrinne'" , "'Jiri Kuthan'" Cc: sip@ietf.org Message-id: <002c01c2b816$17487110$106832a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1097 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >I would really >like to see it as a WG item. Yes, it would be a good idea to start with >draft-schulzrinne-sipping-radius-accounting-00.txt> and make it a WG item. This is very useful. Thanks, Henry > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Jiri Kuthan > Sent: Thursday, January 09, 2003 3:41 AM > To: Henning Schulzrinne; Jiri Kuthan > Cc: sip@ietf.org > Subject: radius (was Re: [Sip] resource reservation > > > Actually, we have implemented it and it is fine. I'm just > concerned about lack of a standard -- that makes interaction > of accounting apps with SIP servers difficult. I would really > like to see it as a WG item. > > -Jiri > > At 02:58 AM 1/9/2003, Henning Schulzrinne wrote: > >There is a long-expired document on this topic; > >draft-schulzrinne-sipping-radius-accounting-00.txt > > > >You can find it in the musty corners of > >http://www.cs.columbia.edu/sip/drafts/ > > > >By reading it, you will lose all your political correctness points. > > > >Jiri Kuthan wrote: > >>At 04:08 PM 1/8/2003, Henry Sinnreich wrote: > >> > >>>>3) The Go interface is COPS-PR, not Diameter. > >>> > >>>yes, and RADIUS in wireline systems. Also not DIAMETER. > >> > >>Let my add my two cents: quite many our users are > interesterd in use > >>of RADIUS for SIP accounting, and there is zero interest in > diameter. > >>The reason is there is a widely deployed RADIUS base. To operators, > >>diameter benefits are apparently less compelling than the upgrade > >>inconvenience. I'm sort of surprised, that the WG has ignored this > >>situation and has not produced any document on use of > RADIUS for SIP. > >>-Jiri > >>_______________________________________________ > >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Jan 9 14:36:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23790 for ; Thu, 9 Jan 2003 14:36:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09Jm3Y19155 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 14:48:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09Jl8J19069; Thu, 9 Jan 2003 14:47:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09JjqJ18958 for ; Thu, 9 Jan 2003 14:45:52 -0500 Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23653 for ; Thu, 9 Jan 2003 14:33:31 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] INFO considered harmful Date: Thu, 9 Jan 2003 14:36:48 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D2DF681@zoe.office.snowshore.com> Thread-Topic: [Sip] INFO considered harmful Thread-Index: AcK3/H2hjp2CO9FIQ0eVpkthPqMXPQAGeW5A From: "Eric Burger" To: "Adam Roach" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h09JjqJ18959 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Funny, none of the existing uses of INFO has melted the network. Counterexamples? > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Thursday, January 09, 2003 11:16 AM > To: 'Christer Holmberg'; Henning Schulzrinne > Cc: sip@ietf.org > Subject: RE: [Sip] INFO considered harmful > > > > If that is the solution, I see no reason for this whole > > thread :) There is no idea to put any restrictions on INFO > > either, because the bad guys will ignore it anyway... > > Yes, people will do it. Unless we take up arms and start a massive > intelligence effort, there's nothing we can do about that simple > fact. > > The overarching question is: should the IETF lend these > noninteroperable, potentially network-crippling approaches > credibility? Allison? Does the IESG generally condone that > sort of thing? > > /a > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 9 15:48:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25860 for ; Thu, 9 Jan 2003 15:48:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09L05q24586 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 16:00:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09Kx5J24471; Thu, 9 Jan 2003 15:59:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09KutJ24334 for ; Thu, 9 Jan 2003 15:56:55 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25713 for ; Thu, 9 Jan 2003 15:44:32 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h09KkN53019635; Thu, 9 Jan 2003 15:46:24 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 14:47:49 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A643FE@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Eric Burger'" , Adam Roach Cc: sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Thu, 9 Jan 2003 14:47:48 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I said "potentially network-crippling," for the exact reason that I don't have examples of this happening specifically with SIP. What I do have, as I've cited before, is examples of the whacked-out kind of things that people will do and have done to appliation-level protocols. The potential exists, and there is a demonstrated will to exploit it. I'll repeat the example here. I'm recalling the rise in popularity of Real Media Player and its ability to set up an audio stream through an HTTP proxy. In particular, I'm recalling conversations shortly thereafter with some friends over in MIS about how they just couldn't add capacity to the HTTP proxy pool fast enough to keep up with demand. Access to external web documents sometimes creeped up to the order of minutes before everything was finally stabilized. It would be difficult to argue that such a mode of operation represents anything other than a crippled network. How long do you guess it will be before Real player (or a similar product) includes a "SIP Proxy:" field right next to its "HTTP Proxy:" field for firewall circumvention? And, lest we lose sight of why I'm saying this in the first place (this conversation has shown signs of extreme ADHD): Yes, people *will* abuse the protocol. There's nothing we can do about that simple fact. It is, however, irresponsible for the IETF to lend these noninteroperable, potentially network-crippling approaches credibility. /a > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Thursday, January 09, 2003 13:37 > To: Adam Roach > Cc: sip@ietf.org > Subject: RE: [Sip] INFO considered harmful > > > Funny, none of the existing uses of INFO has melted the network. > > Counterexamples? > > > -----Original Message----- > > From: Adam Roach [mailto:adam@dynamicsoft.com] > > Sent: Thursday, January 09, 2003 11:16 AM > > To: 'Christer Holmberg'; Henning Schulzrinne > > Cc: sip@ietf.org > > Subject: RE: [Sip] INFO considered harmful > > > > > > > If that is the solution, I see no reason for this whole > > > thread :) There is no idea to put any restrictions on INFO > > > either, because the bad guys will ignore it anyway... > > > > Yes, people will do it. Unless we take up arms and start a massive > > intelligence effort, there's nothing we can do about that simple > > fact. > > > > The overarching question is: should the IETF lend these > > noninteroperable, potentially network-crippling approaches > > credibility? Allison? Does the IESG generally condone that > > sort of thing? > > > > /a > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 9 16:34:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27156 for ; Thu, 9 Jan 2003 16:34:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09LkQf28189 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 16:46:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09LjOJ28119; Thu, 9 Jan 2003 16:45:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09LhPJ28048 for ; Thu, 9 Jan 2003 16:43:25 -0500 Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26989 for ; Thu, 9 Jan 2003 16:31:00 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] INFO considered harmful Date: Thu, 9 Jan 2003 16:34:17 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D2DF683@zoe.office.snowshore.com> Thread-Topic: [Sip] INFO considered harmful Thread-Index: AcK4IGPyP1NGnJHKT6Ktv64e06x00wABhrww From: "Eric Burger" To: "Adam Roach" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h09LhPJ28049 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I guess the rat hole is "noninteroperable, potentially network-crippling approaches credibility." A number of drafts have proposed interoperable, non-network-crippling payloads for INFO. Rewind 20 years. Replace INFO with UDP. The arguments are IDENTICAL. Unless you want to keep X.25 alive, who today would live without UDP? RTP would be bumming :-) > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Thursday, January 09, 2003 3:48 PM > To: Eric Burger; Adam Roach > Cc: sip@ietf.org > Subject: RE: [Sip] INFO considered harmful > > > I said "potentially network-crippling," for the exact reason > that I don't have examples of this happening specifically > with SIP. What I do have, as I've cited before, is examples > of the whacked-out kind of things that people will do and > have done to appliation-level protocols. The potential exists, > and there is a demonstrated will to exploit it. > > I'll repeat the example here. > > I'm recalling the rise in popularity of Real Media Player and > its ability to set up an audio stream through an HTTP proxy. > In particular, I'm recalling conversations shortly thereafter > with some friends over in MIS about how they just couldn't add > capacity to the HTTP proxy pool fast enough to keep up with > demand. > > Access to external web documents sometimes creeped up to the > order of minutes before everything was finally stabilized. > It would be difficult to argue that such a mode of operation > represents anything other than a crippled network. > > How long do you guess it will be before Real player > (or a similar product) includes a "SIP Proxy:" field right > next to its "HTTP Proxy:" field for firewall circumvention? > > And, lest we lose sight of why I'm saying this in the > first place (this conversation has shown signs of extreme > ADHD): Yes, people *will* abuse the protocol. There's > nothing we can do about that simple fact. It is, however, > irresponsible for the IETF to lend these noninteroperable, > potentially network-crippling approaches credibility. > > /a > > > -----Original Message----- > > From: Eric Burger [mailto:eburger@snowshore.com] > > Sent: Thursday, January 09, 2003 13:37 > > To: Adam Roach > > Cc: sip@ietf.org > > Subject: RE: [Sip] INFO considered harmful > > > > > > Funny, none of the existing uses of INFO has melted the network. > > > > Counterexamples? > > > > > -----Original Message----- > > > From: Adam Roach [mailto:adam@dynamicsoft.com] > > > Sent: Thursday, January 09, 2003 11:16 AM > > > To: 'Christer Holmberg'; Henning Schulzrinne > > > Cc: sip@ietf.org > > > Subject: RE: [Sip] INFO considered harmful > > > > > > > > > > If that is the solution, I see no reason for this whole > > > > thread :) There is no idea to put any restrictions on INFO > > > > either, because the bad guys will ignore it anyway... > > > > > > Yes, people will do it. Unless we take up arms and start a massive > > > intelligence effort, there's nothing we can do about that simple > > > fact. > > > > > > The overarching question is: should the IETF lend these > > > noninteroperable, potentially network-crippling approaches > > > credibility? Allison? Does the IESG generally condone that > > > sort of thing? > > > > > > /a > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the > application of sip > > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 9 17:16:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28185 for ; Thu, 9 Jan 2003 17:16:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09MSgf30824 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 17:28:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09MRhJ30807; Thu, 9 Jan 2003 17:27:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09MQrJ30746 for ; Thu, 9 Jan 2003 17:26:53 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28142 for ; Thu, 9 Jan 2003 17:14:28 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h09MGJ53020066; Thu, 9 Jan 2003 17:16:19 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 16:17:45 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A643FF@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Eric Burger'" , Adam Roach Cc: sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Thu, 9 Jan 2003 16:17:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , The #1 issue is that the INFO RFC, today, just says, "here's a method; do with it what you will. Everything's allowed." On re-reading my arguments, all I'm doing is reinforcing this point, which I beleive is relatively uncontentious. (Relative, that is, to...) The more subtle point is whether to turn the free-for-all into an organized effort that involves IANA registration, or whether to completely close the doors. That leads us to... > A number of > drafts have proposed interoperable, non-network-crippling > payloads for INFO. Okay, there's your draft, which is apparently just an informational publication, instead of any proposal for a standard. Beyond, that, RFC 2967 is mentioned only in the following internet drafts: - draft-ietf-sip-serverfeatures-05 - draft-gurbani-sin-02 Only mention INFO as an example method - draft-ietf-sip-message-01 Only mentions INFO in the context of "MESSAGE has this in common with INFO". - draft-ietf-sipping-sigcomp-sip-dictionary-05 Mentions INFO because, well, it's a dictionary that includes all the SIP methods - draft-garcia-sip-associated-uri-04 - draft-henrikson-sip-original-dialog-id-02 - draft-ietf-sip-join-00 - draft-ietf-sip-replaces-02 - draft-ietf-sip-callerprefs-07 Only mention INFO in an attempt to be complete when expanding table 2 in RFC 3261 - draft-mahy-sipping-signaled-digits-01 Uses INFO for RTP transport, but questions this practice in the open issues section By my count, that's exactly one draft that's currently proposing to use INFO for something nonproprietary, and even that draft isn't so certain that INFO is the right approach. Did I miss something? Where are the applications that must take advantage of INFO to work? INFO has been an RFC for over two years now, and was first published as an ID almost four years ago. Has that been insufficient time to come up with the killer app that makes keeping INFO around worth the effort of updating it instead of scrapping it? /a > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Thursday, January 09, 2003 15:34 > To: Adam Roach > Cc: sip@ietf.org > Subject: RE: [Sip] INFO considered harmful > > > I guess the rat hole is "noninteroperable, potentially > network-crippling approaches credibility." A number of > drafts have proposed interoperable, non-network-crippling > payloads for INFO. > > Rewind 20 years. Replace INFO with UDP. The arguments are > IDENTICAL. Unless you want to keep X.25 alive, who today > would live without UDP? RTP would be bumming :-) > > > -----Original Message----- > > From: Adam Roach [mailto:adam@dynamicsoft.com] > > Sent: Thursday, January 09, 2003 3:48 PM > > To: Eric Burger; Adam Roach > > Cc: sip@ietf.org > > Subject: RE: [Sip] INFO considered harmful > > > > > > I said "potentially network-crippling," for the exact reason > > that I don't have examples of this happening specifically > > with SIP. What I do have, as I've cited before, is examples > > of the whacked-out kind of things that people will do and > > have done to appliation-level protocols. The potential exists, > > and there is a demonstrated will to exploit it. > > > > I'll repeat the example here. > > > > I'm recalling the rise in popularity of Real Media Player and > > its ability to set up an audio stream through an HTTP proxy. > > In particular, I'm recalling conversations shortly thereafter > > with some friends over in MIS about how they just couldn't add > > capacity to the HTTP proxy pool fast enough to keep up with > > demand. > > > > Access to external web documents sometimes creeped up to the > > order of minutes before everything was finally stabilized. > > It would be difficult to argue that such a mode of operation > > represents anything other than a crippled network. > > > > How long do you guess it will be before Real player > > (or a similar product) includes a "SIP Proxy:" field right > > next to its "HTTP Proxy:" field for firewall circumvention? > > > > And, lest we lose sight of why I'm saying this in the > > first place (this conversation has shown signs of extreme > > ADHD): Yes, people *will* abuse the protocol. There's > > nothing we can do about that simple fact. It is, however, > > irresponsible for the IETF to lend these noninteroperable, > > potentially network-crippling approaches credibility. > > > > /a > > > > > -----Original Message----- > > > From: Eric Burger [mailto:eburger@snowshore.com] > > > Sent: Thursday, January 09, 2003 13:37 > > > To: Adam Roach > > > Cc: sip@ietf.org > > > Subject: RE: [Sip] INFO considered harmful > > > > > > > > > Funny, none of the existing uses of INFO has melted the network. > > > > > > Counterexamples? > > > > > > > -----Original Message----- > > > > From: Adam Roach [mailto:adam@dynamicsoft.com] > > > > Sent: Thursday, January 09, 2003 11:16 AM > > > > To: 'Christer Holmberg'; Henning Schulzrinne > > > > Cc: sip@ietf.org > > > > Subject: RE: [Sip] INFO considered harmful > > > > > > > > > > > > > If that is the solution, I see no reason for this whole > > > > > thread :) There is no idea to put any restrictions on INFO > > > > > either, because the bad guys will ignore it anyway... > > > > > > > > Yes, people will do it. Unless we take up arms and > start a massive > > > > intelligence effort, there's nothing we can do about that simple > > > > fact. > > > > > > > > The overarching question is: should the IETF lend these > > > > noninteroperable, potentially network-crippling approaches > > > > credibility? Allison? Does the IESG generally condone that > > > > sort of thing? > > > > > > > > /a > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on > current sip > > > > Use sipping@ietf.org for new developments on the > > application of sip > > > > > > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 9 18:01:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29293 for ; Thu, 9 Jan 2003 18:01:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09NDQ201472 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 18:13:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09NCWJ01409; Thu, 9 Jan 2003 18:12:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09NC1J01383 for ; Thu, 9 Jan 2003 18:12:01 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29216 for ; Thu, 9 Jan 2003 17:59:37 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h09N2Z802121; Thu, 9 Jan 2003 23:02:35 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 18:04:59 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB50E@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Eric Burger'" , Adam Roach Cc: sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Thu, 9 Jan 2003 18:04:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Comparing the projected use of SIP INFO with UDP is very apt. However, we already have a UDP, and we don't need SIP to become a more cumbersome surrogate. This argument has gone around and around to little profit. There is no question that SIP can be used as a transport protocol, and we cannot prevent implementers from doing that. Indeed, any protocol can be misapplied. The real argument here is just about what the specifications should present as the correct application of the protocol. While you can argue, Eric, that SIP has lost sight of its original goals, and therefore that it doesn't matter what ugliness we introduce now, I disagree. There are two functions that SIP is intended to provide - discovery and session management. Generic data delivery is not one of these functions. Your arguments that SIP is bloated, or what have you, would encourage us to reduce the scope of the standard, not to condone mistakes that clearly conflict with SIP's mission. I also do not agree that SIP needs any method that is designed for experimentation. You are welcome to implement any experiments you would like - but the standard does not need to detail any particular way of experimenting with SIP in order to enable you to do so. If we did believe this was necessary, we could create an EXPERIMENTAL method - clearly, we chose not to give INFO that name for some reason. We do not need to standardize a method for experimentation because standards exist to foster interoperability - experiments will necessarily run between experimental user agents that do not need a standard specification describing their experimental behavior. It is hard for me to understand why the unregulated use of INFO is being defended so vehemently. A correction to INFO that regulated its usage, and provided some guidelines for what can legitimately be standardized as uses of the INFO method, would be a big improvement over what we have now, and it would not conflict with any future appropriate use of the method. Is even that being rejected here? Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Thursday, January 09, 2003 1:34 PM > To: Adam Roach > Cc: sip@ietf.org > Subject: RE: [Sip] INFO considered harmful > > > I guess the rat hole is "noninteroperable, potentially > network-crippling approaches credibility." A number of > drafts have proposed interoperable, non-network-crippling > payloads for INFO. > > Rewind 20 years. Replace INFO with UDP. The arguments are > IDENTICAL. Unless you want to keep X.25 alive, who today > would live without UDP? RTP would be bumming :-) > > > -----Original Message----- > > From: Adam Roach [mailto:adam@dynamicsoft.com] > > Sent: Thursday, January 09, 2003 3:48 PM > > To: Eric Burger; Adam Roach > > Cc: sip@ietf.org > > Subject: RE: [Sip] INFO considered harmful > > > > > > I said "potentially network-crippling," for the exact reason > > that I don't have examples of this happening specifically > > with SIP. What I do have, as I've cited before, is examples > > of the whacked-out kind of things that people will do and > > have done to appliation-level protocols. The potential exists, > > and there is a demonstrated will to exploit it. > > > > I'll repeat the example here. > > > > I'm recalling the rise in popularity of Real Media Player and > > its ability to set up an audio stream through an HTTP proxy. > > In particular, I'm recalling conversations shortly thereafter > > with some friends over in MIS about how they just couldn't add > > capacity to the HTTP proxy pool fast enough to keep up with > > demand. > > > > Access to external web documents sometimes creeped up to the > > order of minutes before everything was finally stabilized. > > It would be difficult to argue that such a mode of operation > > represents anything other than a crippled network. > > > > How long do you guess it will be before Real player > > (or a similar product) includes a "SIP Proxy:" field right > > next to its "HTTP Proxy:" field for firewall circumvention? > > > > And, lest we lose sight of why I'm saying this in the > > first place (this conversation has shown signs of extreme > > ADHD): Yes, people *will* abuse the protocol. There's > > nothing we can do about that simple fact. It is, however, > > irresponsible for the IETF to lend these noninteroperable, > > potentially network-crippling approaches credibility. > > > > /a > > > > > -----Original Message----- > > > From: Eric Burger [mailto:eburger@snowshore.com] > > > Sent: Thursday, January 09, 2003 13:37 > > > To: Adam Roach > > > Cc: sip@ietf.org > > > Subject: RE: [Sip] INFO considered harmful > > > > > > > > > Funny, none of the existing uses of INFO has melted the network. > > > > > > Counterexamples? > > > > > > > -----Original Message----- > > > > From: Adam Roach [mailto:adam@dynamicsoft.com] > > > > Sent: Thursday, January 09, 2003 11:16 AM > > > > To: 'Christer Holmberg'; Henning Schulzrinne > > > > Cc: sip@ietf.org > > > > Subject: RE: [Sip] INFO considered harmful > > > > > > > > > > > > > If that is the solution, I see no reason for this whole > > > > > thread :) There is no idea to put any restrictions on INFO > > > > > either, because the bad guys will ignore it anyway... > > > > > > > > Yes, people will do it. Unless we take up arms and > start a massive > > > > intelligence effort, there's nothing we can do about that simple > > > > fact. > > > > > > > > The overarching question is: should the IETF lend these > > > > noninteroperable, potentially network-crippling approaches > > > > credibility? Allison? Does the IESG generally condone that > > > > sort of thing? > > > > > > > > /a > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on > current sip > > > > Use sipping@ietf.org for new developments on the > > application of sip > > > > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Jan 9 19:13:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01181 for ; Thu, 9 Jan 2003 19:13:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0A0PVa05344 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 19:25:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A0OcJ05254; Thu, 9 Jan 2003 19:24:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A0NBJ05201 for ; Thu, 9 Jan 2003 19:23:11 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01140 for ; Thu, 9 Jan 2003 19:10:45 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h0A0Dt8W013732; Thu, 9 Jan 2003 18:13:55 -0600 From: "Dean Willis" To: "'Peterson, Jon'" , "'Eric Burger'" , "'Adam Roach'" Cc: Subject: RE: [Sip] INFO considered harmful Date: Thu, 9 Jan 2003 18:13:49 -0600 Message-ID: <000001c2b83d$26a83970$240112ac@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <15A2739B7DAA624D8091C65981D7DA815EB50E@stntexch2.va.neustar.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0A0NBJ05202 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > Jon says: > There are two > functions that SIP is intended to provide - discovery and > session management. Generic data delivery is not one of these > functions. Perhaps you overlook the "rendezvous" function, which is not quite the same as "discovery". The utility of INFO is that it delivers data to the endpoints of a specific dialog, while respecting the SIP-level anonymity, security, and routing functionality of that dialog. Nothing BUT an in-dialog SIP method has that property, as we discovered in the extended discssion of binding HTTP URLS to SIP. > It is hard for me to understand why the unregulated use of > INFO is being defended so vehemently. A correction to INFO > that regulated its usage, and provided some guidelines for > what can legitimately be standardized as uses of the INFO > method, would be a big improvement over what we have now, and > it would not conflict with any future appropriate use of the > method. Is even that being rejected here? No, what's being rejected out-of-hand is the notion that INFO is horribly dangerous and busily eating the internet like a giant space-amoeba, requiring us immediately to allocate resources to expurgate it. I suspect that the participants are simply enjoying the debate, much as my dog enjoys chewing a piece of rawhide. There is probably an undercurrent of debate on exactly what sorts of constraints, guidances, and registrations should be applied, but that discussion could probably be readily diverteed into a "send text" instruction. -- 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 mailnull@www1.ietf.org Thu Jan 9 19:13:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01195 for ; Thu, 9 Jan 2003 19:13:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0A0PfN05359 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 19:25:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A0OoJ05294; Thu, 9 Jan 2003 19:24:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A0NIJ05209 for ; Thu, 9 Jan 2003 19:23:18 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01147 for ; Thu, 9 Jan 2003 19:10:52 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h0A0Dt8Y013732; Thu, 9 Jan 2003 18:13:56 -0600 From: "Dean Willis" To: "'Adam Roach'" , "'Christer Holmberg'" , "'Henning Schulzrinne'" Cc: Subject: RE: [Sip] INFO considered harmful Date: Thu, 9 Jan 2003 18:13:49 -0600 Message-ID: <000201c2b83d$276bd790$240112ac@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A643F8@DYN-TX-EXCH-001.dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0A0NJJ05210 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > The overarching question is: should the IETF lend these > noninteroperable, potentially network-crippling approaches > credibility? Allison? Does the IESG generally condone that > sort of thing? My, that's seriously humorous rhetoric. You continued deluge of non interoperable network crippling bytes has overwhelmed my mail server far more quickly than the tens of unsolicited (and often unknown and indecipherable) MIME objects that get delivered to my mailbox each day, and I'm sure it does more harm to the network than the thousands of MIME objects not (specified by HTTP) that I retrieve with HTYP each day . . . We need to get a little perspective here, folks. -- 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 mailnull@www1.ietf.org Thu Jan 9 19:13:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01218 for ; Thu, 9 Jan 2003 19:13:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0A0PiQ05383 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 19:25:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A0OtJ05313; Thu, 9 Jan 2003 19:24:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A0NJJ05213 for ; Thu, 9 Jan 2003 19:23:19 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01148 for ; Thu, 9 Jan 2003 19:10:53 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h0A0Dt8Z013732; Thu, 9 Jan 2003 18:13:57 -0600 From: "Dean Willis" To: "'Henning Schulzrinne'" , "'Christer Holmberg'" Cc: "'Adam Roach'" , "'Eric Burger'" , Subject: RE: [Sip] INFO considered harmful Date: Thu, 9 Jan 2003 18:13:49 -0600 Message-ID: <000301c2b83d$27b51590$240112ac@txdwillis> 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.4510 Importance: Normal In-Reply-To: <3E1D6F7B.6060304@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Yep. Several university hacker groups tunneled IP over DNS back when firewalls first reared their eugly heads in the early '90s. You know, it doesn't specifically say "Thou shalt not tunnel IP over domain xfer requests" in the DNS spec, and I'm sure if it had, that they would not have done this. -- Dean > The same is true for any message. Heck, you could probably > encapsulate > RTP in ACK or (intentionally rejected) INVITE, if ACK or > INVITE doesn't > get charged. > > Christer Holmberg wrote: > > Hi, > > > > > >>Your example clearly falls into the "> 10" category as the poor web > >>server had to deal with every Real audio or video packet. > Not that it > >>would surprise me, but I don't think anybody *here* has suggested > >>RTP-over-INFO so far. > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 9 20:10:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01196 for ; Thu, 9 Jan 2003 19:13:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0A0Pfm05369 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 19:25:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A0OkJ05275; Thu, 9 Jan 2003 19:24:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A0NCJ05205 for ; Thu, 9 Jan 2003 19:23:12 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01142 for ; Thu, 9 Jan 2003 19:10:46 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h0A0Dt8X013732; Thu, 9 Jan 2003 18:13:55 -0600 From: "Dean Willis" To: "'Adam Roach'" , "'Eric Burger'" Cc: Subject: RE: [Sip] INFO considered harmful Date: Thu, 9 Jan 2003 18:13:49 -0600 Message-ID: <000101c2b83d$26f32520$240112ac@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A643FF@DYN-TX-EXCH-001.dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0A0NCJ05206 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > Where are the applications that must take advantage of INFO > to work? INFO has been an RFC for over two years now, and was > first published as an ID almost four years ago. Has that been > insufficient time to come up with the killer app that makes > keeping INFO around worth the effort of updating it instead > of scrapping it? I suspect that they (the applications) are buried behind the chanted rhetoric of the fanatic disciples of the anti-INFO cult, famed for their monologous exposition and persistent derogatory exculpation of infidels proposing the heretical practice of INFOlogy in the time-honored tradition that theocracies throughout history have used to suppress dissent. Or maybe the protocol has just gotten sufficiently convoluted that nobody is really exercising it with new applications? Or maybe they're using it and not telling you . . . Yes that's it, everybody is using INFO and deliberately hiding it. It's deliberate, and they're doing it just to spite you (Adam). In fact, if you check the phone on your desk that you use every day, I'll bet you find that it's committing the heresy of DTMF-INFO on every dialed call. There's no place to hide, Adam, INFO is coming for you . . . Seriously, is this thread pointless, or what? -- 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 mailnull@www1.ietf.org Thu Jan 9 20:14:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02880 for ; Thu, 9 Jan 2003 20:14:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0A1Q1U08865 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 20:26:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A1P8J08836; Thu, 9 Jan 2003 20:25:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A1NSJ08730 for ; Thu, 9 Jan 2003 20:23:28 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02843 for ; Thu, 9 Jan 2003 20:11:00 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h0A1E4803957; Fri, 10 Jan 2003 01:14:04 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 20:16:27 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB515@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Dean Willis'" , "'Eric Burger'" , "'Adam Roach'" Cc: sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Thu, 9 Jan 2003 20:16:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , A small note below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Thursday, January 09, 2003 4:14 PM > To: 'Peterson, Jon'; 'Eric Burger'; 'Adam Roach' > Cc: sip@ietf.org > Subject: RE: [Sip] INFO considered harmful > > > > Jon says: > > There are two > > functions that SIP is intended to provide - discovery and > > session management. Generic data delivery is not one of these > > functions. > > Perhaps you overlook the "rendezvous" function, which is not quite the same > as "discovery". The utility of INFO is that it delivers data to the > endpoints of a specific dialog, while respecting the SIP-level anonymity, > security, and routing functionality of that dialog. Nothing BUT an in-dialog > SIP method has that property, as we discovered in the extended discssion of > binding HTTP URLS to SIP. By discovery I meant what one would generally consider to be the rendezvous function - all of the registration and events mechanisms, URI resolution and so on that goes into allowing user agents to find the right place and time on the network to establish a dialog with their targets. SIP connects user agents in a dialog, however, so that they can have a session. Sessions are the way SIP delivers data between endpoints in a specific dialog. The anonymity, security and routing of session data can indeed run afoul of problems - but we don't solve those problems for, say, RTP by sending RTP over INFO. MESSAGE has already been discussed in this thread, so I won't rehash it (MESSAGE is not a dialog, etc) - suffice it to say that I think the unregulated standardization of INFO gives SIP some capabilities that it doesn't have otherwise, which don't serve either of SIP's core functions, which confuse and complicate SIP's applicability. I agree that INFO is not a space amoeba, but it is a superfluous bifurcation of SIP's direction that we can prune without diminishing the protocol's core assets. [snip] > > -- > 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 mailnull@www1.ietf.org Thu Jan 9 21:05:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03714 for ; Thu, 9 Jan 2003 21:05:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0A2HL012017 for sip-archive@odin.ietf.org; Thu, 9 Jan 2003 21:17:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A2GSJ12000; Thu, 9 Jan 2003 21:16:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A2FrJ11972 for ; Thu, 9 Jan 2003 21:15:53 -0500 Received: from mtiwmhc12.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03704 for ; Thu, 9 Jan 2003 21:03:24 -0500 (EST) Received: from cs.columbia.edu ([12.92.113.231]) by mtiwmhc12.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030110020641.YOFK12483.mtiwmhc12.worldnet.att.net@cs.columbia.edu>; Fri, 10 Jan 2003 02:06:41 +0000 Message-ID: <3E1E2A1E.7050601@cs.columbia.edu> Date: Thu, 09 Jan 2003 21:04:14 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'Christer Holmberg'" , sip@ietf.org Subject: Re: [Sip] INFO considered harmful References: <9BF66EBF6BEFD942915B4D4D45C051F3A643F8@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Before I get misunderstood: I don't suggest standardizing applications (of INFO or anything else) that shouldn't be. We don't have to legitimize dumb designs. On the other hand, I'm not aware of any (successfull) attempt to limit Content-Type to a specific, approved set. Also, generally the IETF has worried about network load. Thus, mandating various rules for use of TCP or congestion-control protocols seems perfectly in line with experience. Prohibiting things for the benefit of CPU load has no precedent that I can think of. Adam Roach wrote: >>If that is the solution, I see no reason for this whole >>thread :) There is no idea to put any restrictions on INFO >>either, because the bad guys will ignore it anyway... > > > Yes, people will do it. Unless we take up arms and start a massive > intelligence effort, there's nothing we can do about that simple > fact. > > The overarching question is: should the IETF lend these > noninteroperable, potentially network-crippling approaches > credibility? Allison? Does the IESG generally condone that > sort of thing? > > /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 10 00:45:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08303 for ; Fri, 10 Jan 2003 00:45:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0A5vQd23514 for sip-archive@odin.ietf.org; Fri, 10 Jan 2003 00:57:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A5v0J23500; Fri, 10 Jan 2003 00:57:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A5tNJ23432 for ; Fri, 10 Jan 2003 00:55:23 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08257 for ; Fri, 10 Jan 2003 00:42:50 -0500 (EST) Received: from sponge (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h0A5jx8W015631; Thu, 9 Jan 2003 23:45:59 -0600 From: "Dean Willis" To: "'Peterson, Jon'" , "'Eric Burger'" , "'Adam Roach'" Cc: Subject: RE: [Sip] INFO considered harmful Date: Thu, 9 Jan 2003 23:46:14 -0600 Message-ID: <007f01c2b86b$96e078a0$1a02a8c0@sponge> 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.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <15A2739B7DAA624D8091C65981D7DA815EB515@stntexch2.va.neustar.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jon said: > By discovery I meant what one would generally consider to be > the rendezvous function - all of the registration and events > mechanisms, URI resolution and so on that goes into allowing > user agents to find the right place and time on the network > to establish a dialog with their targets. SIP connects user > agents in a dialog, however, so that they can have a session. > Sessions are the way SIP delivers data between endpoints in a > specific dialog. The anonymity, security and routing of > session data can indeed run afoul of problems - but we don't > solve those problems for, say, RTP by sending RTP over INFO. > MESSAGE has already been discussed in this thread, so I won't > rehash it (MESSAGE is not a dialog, etc) - suffice it to say > that I think the unregulated standardization of INFO gives > SIP some capabilities that it doesn't have otherwise, which > don't serve either of SIP's core functions, which confuse and > complicate SIP's applicability. I agree that INFO is not a > space amoeba, but it is a superfluous bifurcation of SIP's > direction that we can prune without diminishing the > protocol's core assets. We solve the rendezvous/discovery problems for events and message with SIP routing, and this functionality of SIP is clearly applicable to application-data such as ISUP processing in SIP-T (currently done via INFO routing). I really don't understand what part of "the data carried in INFO has the semantic of being associated with the application driving this dialog, not the SIP state machine itself" that isn't clear. The SIP layer fundamentally neither knows nor cares what that application is. -- 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 mailnull@www1.ietf.org Fri Jan 10 07:43:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26471 for ; Fri, 10 Jan 2003 07:43:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0ACtof28278 for sip-archive@odin.ietf.org; Fri, 10 Jan 2003 07:55:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ACtIJ28254; Fri, 10 Jan 2003 07:55:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ACqcJ28170 for ; Fri, 10 Jan 2003 07:52:38 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26440 for ; Fri, 10 Jan 2003 07:39:57 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 10 Jan 2003 13:41:36 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Jan 2003 13:41:36 +0100 Message-Id: <953B9B08F98DD61183F8000347AE66011ACBA6@G8PPV.blf01.telekom.de> From: "Jesske, R" To: sip@ietf.org, fmiller@sentito.com Cc: "Poetzl, Joachim" , "Tolksdorf, Christian" , "Alexeitsev, D" , Robert.Benz@telekom.de, "Pinker, Gerold" Date: Fri, 10 Jan 2003 13:41:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Question draft-miller-sip-isup-annex-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, In a Mail regarding the issue: "Re: [Sip] INFO considered harmful" you pointed to a draft regarding a textual representation of SS7 in SIP INFO. After a short view at your draft I'm confused now. You are describing for SS7 Blocking (BLO) messages a text description to transport BLO over a SIP network. Why? The SS7 BLO/UBL Messages are only exchanged between two exchanges within the SS7 world to say the circuits are now blocked/unblocked. Within SIP there are no Circuits, why do you need such kind of messages within the SIP world. Best Regards Roland Deutsche Telekom AG T Com Zentrale Roland Jesske, T38a12 Section T38; Signalling, Gateways and Switching Systems Am Kavalleriesand 3, 64295 Darmstadt, Germany Phone: +49 6151 83-5940 Fax: +49 6151 83-4577 Well, any illusion of reasonableness I may have garnered in the past is about to be shattered. I would refer folks to: http://www.ietf.org/internet-drafts/draft-miller-sip-isup-annex-00.txt This draft is about to receive a major -01 update that recodes the entire syntax in XML. In addition, we (I) have another draft that does something very similar for ANSI TCAP that I'll be submitting in short order. I guess its only appropriate that I bring peoples attention to these drafts under the current subject heading... FM Frank W. Miller, Ph.D. Chief Technical Officer sentitO Networks, Inc. fmiller@sentito.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 mailnull@www1.ietf.org Fri Jan 10 09:45:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29396 for ; Fri, 10 Jan 2003 09:45:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0AEvtK04106 for sip-archive@odin.ietf.org; Fri, 10 Jan 2003 09:57:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AEuwJ04044; Fri, 10 Jan 2003 09:56:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AEtUJ03958 for ; Fri, 10 Jan 2003 09:55:30 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29299 for ; Fri, 10 Jan 2003 09:42:45 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0AEk0l05118; Fri, 10 Jan 2003 06:46:00 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0AEkBD08863; Fri, 10 Jan 2003 08:46:12 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Jan 2003 08:45:58 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7CBD4@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Peterson, Jon'" , "'Eric Burger'" , Adam Roach Cc: sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Fri, 10 Jan 2003 08:45:56 -0600 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi all, Typically wanting to avoid these types of debate, I thought I would just respond to this one point in Jon's posting (I've deleted the rest of the thread), which I think gets to the crux of the primary concern. ----beginning of thread snipped---- >It is hard for me to understand why the unregulated use of INFO is being >defended so vehemently. A correction to INFO that regulated its usage, and >provided some guidelines for what can legitimately be standardized as uses >of the INFO method, would be a big improvement over what we have now, and it >would not conflict with any future appropriate use of the method. Is even >that being rejected here? >Jon Peterson >NeuStar, Inc. ----rest of thread deleted----- I think the initial reaction and what folks were originally most concerned over was the deprecation of the use of INFO (for other than SIP-T), which was the preferred approach identified in Jonathan's draft. I would think that most people would not object to some guidelines around the use of INFO, although I would think many would be more in favor of a 1.5 versus the "completeness" proposed by the second approach in the draft. Basically, I'm suggesting providing a venue (i.e. as part of SIPPING WG charter, perhaps) to review individual usages of INFO. The reality is that if you want your use of INFO to interwork with a 3rd party, some level of specification is required and in the end some of the usages might indeed converge to a widely deployed approach or perhaps put the spotlight on the need for a new method. As others have suggested, deprecating INFO or being too stringent in enforcing it's usage would likely move the policing of the protocol problem elsewhere, perhaps where the guidelines are less stringent (e.g. the lack of registration with IANA is only discouraged). And, as others have said the "bad" guys will likely to continue using it regardless (not caring that it impacts their particular "seal of IETF approval"). Regards, Mary H. Barnes mbarnes@nortelnetworks.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 mailnull@www1.ietf.org Fri Jan 10 10:22:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00454 for ; Fri, 10 Jan 2003 10:22:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0AFYII06635 for sip-archive@odin.ietf.org; Fri, 10 Jan 2003 10:34:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AFXdJ06578; Fri, 10 Jan 2003 10:33:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AFU9J06416 for ; Fri, 10 Jan 2003 10:30:09 -0500 Received: from ihemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00338 for ; Fri, 10 Jan 2003 10:17:23 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0AFKeE19524 for ; Fri, 10 Jan 2003 10:20:40 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Jan 2003 15:20:39 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EB9A@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Mary Barnes'" , "'Peterson, Jon'" , "'Eric Burger'" , Adam Roach Cc: sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Fri, 10 Jan 2003 15:20:38 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Perhaps it would be appropriate to have the same review mechanism and restrictions on INFO usage as provided for P-headers and event definitions. If the sip changes draft is still active, maybe we need some text in there. There would additionally need to be some text in the sip guidelines document. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Mary Barnes [mailto:mbarnes@nortelnetworks.com] > Sent: 10 January 2003 14:46 > To: 'Peterson, Jon'; 'Eric Burger'; Adam Roach > Cc: sip@ietf.org > Subject: RE: [Sip] INFO considered harmful > > > Hi all, > > Typically wanting to avoid these types of debate, I thought I > would just > respond to this one point in Jon's posting (I've deleted the > rest of the > thread), which I think gets to the crux of the primary concern. > > ----beginning of thread snipped---- > > >It is hard for me to understand why the unregulated use of > INFO is being > >defended so vehemently. A correction to INFO that regulated > its usage, and > >provided some guidelines for what can legitimately be > standardized as uses > >of the INFO method, would be a big improvement over what we > have now, and > it > >would not conflict with any future appropriate use of the > method. Is even > >that being rejected here? > > >Jon Peterson > >NeuStar, Inc. > > ----rest of thread deleted----- > > > I think the initial reaction and what folks were originally > most concerned > over was the deprecation of the use of INFO (for other than > SIP-T), which > was the preferred approach identified in Jonathan's draft. I > would think > that most people would not object to some guidelines around > the use of INFO, > although I would think many would be more in favor of a 1.5 versus the > "completeness" proposed by the second approach in the draft. > Basically, I'm > suggesting providing a venue (i.e. as part of SIPPING WG > charter, perhaps) > to review individual usages of INFO. The reality is that if > you want your > use of INFO to interwork with a 3rd party, some level of > specification is > required and in the end some of the usages might indeed > converge to a widely > deployed approach or perhaps put the spotlight on the need > for a new method. > > > As others have suggested, deprecating INFO or being too stringent in > enforcing it's usage would likely move the policing of the > protocol problem > elsewhere, perhaps where the guidelines are less stringent > (e.g. the lack of > registration with IANA is only discouraged). And, as others > have said the > "bad" guys will likely to continue using it regardless (not > caring that it > impacts their particular "seal of IETF approval"). > > Regards, > Mary H. Barnes > mbarnes@nortelnetworks.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 mailnull@www1.ietf.org Fri Jan 10 11:47:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03396 for ; Fri, 10 Jan 2003 11:47:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0AGxYB12975 for sip-archive@odin.ietf.org; Fri, 10 Jan 2003 11:59:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AGxCJ12957; Fri, 10 Jan 2003 11:59:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AGu6J12824 for ; Fri, 10 Jan 2003 11:56:06 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03209 for ; Fri, 10 Jan 2003 11:43:19 -0500 (EST) Received: from RjS.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h0AGkaK04934; Fri, 10 Jan 2003 10:46:36 -0600 From: Robert Sparks To: sip@ietf.org, sip-implementors@cs.columbia.edu Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 10 Jan 2003 10:45:45 -0600 Message-Id: <1042217145.930.40.camel@RjS.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Sip] SIPIT registration closing soon Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit If you are planning to attend SIPIT 12 but have not yet registered, please do so soon. Registration closes January 20th. See http://www.hotsip.com/sipit12 for more information. RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 10 11:52:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03505 for ; Fri, 10 Jan 2003 11:52:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0AH4cn13606 for sip-archive@odin.ietf.org; Fri, 10 Jan 2003 12:04:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AH4MJ13596; Fri, 10 Jan 2003 12:04:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AH0cJ13074 for ; Fri, 10 Jan 2003 12:00:38 -0500 Received: from face.sentitonetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03432 for ; Fri, 10 Jan 2003 11:47:50 -0500 (EST) Received: (qmail 69661 invoked from network); 10 Jan 2003 16:51:08 -0000 Received: from unknown (HELO overhill) (10.0.0.35) by face.sentito.com with SMTP; 10 Jan 2003 16:51:08 -0000 Message-ID: <00a901c2b8c8$790c89b0$2300000a@overhill> From: "Frank W. Miller" To: "Jesske, R" Cc: References: <953B9B08F98DD61183F8000347AE66011ACBA6@G8PPV.blf01.telekom.de> Date: Fri, 10 Jan 2003 11:51:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Question draft-miller-sip-isup-annex-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Jesske, R" To: ; Cc: "Poetzl, Joachim" ; "Tolksdorf, Christian" ; "Alexeitsev, D" ; ; "Pinker, Gerold" Sent: Friday, January 10, 2003 7:41 AM Subject: Question draft-miller-sip-isup-annex-00.txt > In a Mail regarding the issue: "Re: [Sip] INFO considered harmful" you pointed to a draft regarding a textual representation of SS7 in SIP INFO. > After a short view at your draft I'm confused now. You are describing for SS7 Blocking (BLO) messages a text description to transport BLO over a SIP network. Why? > The SS7 BLO/UBL Messages are only exchanged between two exchanges within the SS7 world to say the circuits are now blocked/unblocked. Within SIP there are no Circuits, why do you need such kind of messages within the SIP world. > We're seeing an architectural evolution whereby TDM access lines like T's in the U.S. are are terminated at the access point in favor of SIP controlled transport. What this does is inject SIP "islands" in an existing TDM access delivery network. The key to this work (the ISUP and recently release TCAP drafts) is to prevent those "islands" from having to deal with any kind of SS7 binary protocol (read pay for SS7 stacks) inside the SIP "island". Its strictly a cost argument. The idea is that existing SS7 elements can still be used to provision channels but the SIP "islands" don't have to pay for an SS7 (both $$ and point codes, whose name space is more congested the IPV4). If you have some specific implementation level questions, I suggest we take the discussion off the IETF board... 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 mailnull@www1.ietf.org Fri Jan 10 14:01:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12059 for ; Fri, 10 Jan 2003 14:01:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0AJDn722737 for sip-archive@odin.ietf.org; Fri, 10 Jan 2003 14:13:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AJDCJ22726; Fri, 10 Jan 2003 14:13:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AJBnJ22644 for ; Fri, 10 Jan 2003 14:11:49 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11743 for ; Fri, 10 Jan 2003 13:58:58 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h0AJ0c53024082; Fri, 10 Jan 2003 14:00:38 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Jan 2003 13:02:04 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64401@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Dean Willis'" , Adam Roach , "'Eric Burger'" Cc: sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Fri, 10 Jan 2003 13:02:00 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > It's deliberate, and they're doing it just to spite you (Adam). > In fact, if you check the phone on your desk that you use every > day, I'll bet you find that it's committing the heresy of DTMF-INFO > on every dialed call. Just checked. AVT tones payload, actually. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 10 17:41:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18759 for ; Fri, 10 Jan 2003 17:41:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0AMs0j03723 for sip-archive@odin.ietf.org; Fri, 10 Jan 2003 17:54:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AMrYJ03709; Fri, 10 Jan 2003 17:53:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AMpXJ03580 for ; Fri, 10 Jan 2003 17:51:33 -0500 Received: from acmepacket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18654 for ; Fri, 10 Jan 2003 17:38:38 -0500 (EST) Received: from BPenfield [127.0.0.1] by acmepacket.com (SMTPD32-7.07) id AC347B3F0050; Fri, 10 Jan 2003 17:41:56 -0500 Message-ID: <003601c2b8f9$71da3ad0$6701a8c0@BPenfield> From: "Bob Penfield" To: "Vijay Gaur" , References: Subject: Re: [Sip] Handling for ACK for 400 Response Date: Fri, 10 Jan 2003 17:41:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline ----- Original Message ----- From: "Vijay Gaur" > Hi, > When a UAS received a malformed Invite Request, > it would send back a 400 Response after parsing > the message. It would not (or may not be able to) > create a Transaction for the same. > The Client on recieving this Response would respond > with an ACK. > > The UAS would drop this ACK as an unhandled message, > and would be reflected as an error on the same. The ACK is just dropped, there is no error. > > The question is - Do we need a particular response code > which would tell the client that an ACK for this should > not be sent? > I don't think that is necessary. The ACK is really harmless. The UAS can respond statelessly (as described in section 8.2.7) for the malformed request. As far as the unhandled ACK, the UAS could form the to-tag of the response such that the UAS could recognize it in the ACK and just ignore the ACK. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 10 19:57:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21340 for ; Fri, 10 Jan 2003 19:57:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0B1A2D10692 for sip-archive@odin.ietf.org; Fri, 10 Jan 2003 20:10:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0B19UJ10653; Fri, 10 Jan 2003 20:09:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0B17FJ10319 for ; Fri, 10 Jan 2003 20:07:15 -0500 Received: from broadsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21290 for ; Fri, 10 Jan 2003 19:54:19 -0500 (EST) Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.12.6) id h0B0vbYn021688; Fri, 10 Jan 2003 19:57:37 -0500 (EST) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] Can INVITE overlap SUBSCRIBE Date: Fri, 10 Jan 2003 19:59:12 -0500 Message-ID: <000501c2b90c$a87f5b20$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7FE70C8@esebe019.ntc.nokia.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > If a dialog is already established with a > SUBSCRIBE, that SUBSCRIBE is being refreshed > (SUBSCRIBE in progress). Can an INVITE, within > the same dialog, be sent while the SUBSCRIBE > refresh is in progress? Yes. However the requests might be received out of order. Thus it might lead to a 500 response for the subscribe. However caution should be observed when overlapping requests towards devices that authenticate each request with a new nonce and only remember the last nonce. Such a situation can lead to a continual challenge situation where UAC appears to keep sending non-latest nonce. > Another question: Can SUBSCRIBEs overlap in > the following 2 scenarios? > > Scenario 1: > > (1) SUBSCRIBE event:presence > ----------------------------> > > (2) SUBSCRIBE event:presence > ----------------------------> > > (1) and (2) are requests within the same dialog > and are the same association with the dialog. > Can (2) be sent before (1) completes. This is > like INVITEs overlapping. Yes, assuming the dialog has already been establish. However the requests might be received out of order. Thus it might lead to a 500 response for 1. > Scenario 2: > > (3) SUBSCRIBE event:presence > ----------------------------> > > (4) SUBSCRIBE event:winfo > ----------------------------> > > (3) and (4) are requests within the same dialog > but are in different associations with the dialog. > Can (4) be sent before (3) completes. This is like > INVITE and SUBSCRIBE overlapping, I think. I'm not positive about what you mean by different associations. Thus I'll assume you mean different event types. Assuming the dialog has already been establish, yes it is legal to send. However the requests might be received out of order. Thus it might lead to a 500 response for 3. > A similar example of this is 2 SUBSCRIBEs with the > same event package but different event ids. Yes it is legal to send. However the requests might be received out of order. Thus it might lead to a 500 response for 3. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Jan 13 03:52:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04725 for ; Mon, 13 Jan 2003 03:52:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0D95tN05727 for sip-archive@odin.ietf.org; Mon, 13 Jan 2003 04:05:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0D95LJ05693; Mon, 13 Jan 2003 04:05:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0D90mJ05217 for ; Mon, 13 Jan 2003 04:00:49 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04593 for ; Mon, 13 Jan 2003 03:46:43 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0D8q8t24532 for ; Mon, 13 Jan 2003 10:52:08 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 13 Jan 2003 10:50:01 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Jan 2003 10:50:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Can INVITE overlap SUBSCRIBE Date: Mon, 13 Jan 2003 10:50:01 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7105@esebe019.ntc.nokia.com> Thread-Topic: [Sip] Can INVITE overlap SUBSCRIBE Thread-Index: AcK5DiU/Mj9MNsaGSTCmaZ3JXZR7dwB0idYw To: , X-OriginalArrivalTime: 13 Jan 2003 08:50:01.0712 (UTC) FILETIME=[C26C6700:01C2BAE0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0D90nJ05218 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit To avoid all this confusion, would it be a good idea to forbid overlapping of target refresh requests within a dialog? i.e. requests that create dialogs are not allowed to overlap. In this way, we avoid the 500 response and the confusion of the race condition of the responses as well that might carry different remote targets. Regards, Hisham > -----Original Message----- > From: ext Brett Tate [mailto:brett@broadsoft.com] > Sent: Saturday, January 11, 2003 2:59 AM > To: sip@ietf.org > Subject: RE: [Sip] Can INVITE overlap SUBSCRIBE > > > > If a dialog is already established with a > > SUBSCRIBE, that SUBSCRIBE is being refreshed > > (SUBSCRIBE in progress). Can an INVITE, within > > the same dialog, be sent while the SUBSCRIBE > > refresh is in progress? > > Yes. However the requests might be received > out of order. Thus it might lead to a 500 > response for the subscribe. > > However caution should be observed when > overlapping requests towards devices that > authenticate each request with a new nonce > and only remember the last nonce. Such a > situation can lead to a continual challenge > situation where UAC appears to keep sending > non-latest nonce. > > > Another question: Can SUBSCRIBEs overlap in > > the following 2 scenarios? > > > > Scenario 1: > > > > (1) SUBSCRIBE event:presence > > ----------------------------> > > > > (2) SUBSCRIBE event:presence > > ----------------------------> > > > > (1) and (2) are requests within the same dialog > > and are the same association with the dialog. > > Can (2) be sent before (1) completes. This is > > like INVITEs overlapping. > > Yes, assuming the dialog has already been establish. > However the requests might be received out of order. > Thus it might lead to a 500 response for 1. > > > Scenario 2: > > > > (3) SUBSCRIBE event:presence > > ----------------------------> > > > > (4) SUBSCRIBE event:winfo > > ----------------------------> > > > > (3) and (4) are requests within the same dialog > > but are in different associations with the dialog. > > Can (4) be sent before (3) completes. This is like > > INVITE and SUBSCRIBE overlapping, I think. > > I'm not positive about what you mean by different > associations. Thus I'll assume you mean different > event types. > > Assuming the dialog has already been establish, > yes it is legal to send. However the requests might > be received out of order. Thus it might lead to a > 500 response for 3. > > > A similar example of this is 2 SUBSCRIBEs with the > > same event package but different event ids. > > Yes it is legal to send. However the requests might > be received out of order. Thus it might lead to a > 500 response for 3. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Jan 13 11:58:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16644 for ; Mon, 13 Jan 2003 11:58:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DHBss07177 for sip-archive@odin.ietf.org; Mon, 13 Jan 2003 12:11:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DHB5J07147; Mon, 13 Jan 2003 12:11:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DH8HJ07061 for ; Mon, 13 Jan 2003 12:08:17 -0500 Received: from broadsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16594 for ; Mon, 13 Jan 2003 11:54:03 -0500 (EST) Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.12.6) id h0DGvNF7053977; Mon, 13 Jan 2003 11:57:23 -0500 (EST) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] Can INVITE overlap SUBSCRIBE Date: Mon, 13 Jan 2003 11:59:02 -0500 Message-ID: <000601c2bb25$1367d0b0$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7FE7105@esebe019.ntc.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > To avoid all this confusion, would it be a > good idea to forbid overlapping of target > refresh requests within a dialog? > i.e. requests that create dialogs are not > allowed to overlap. In this way, we avoid > the 500 response and the confusion of the > race condition of the responses as well that > might carry different remote targets. RFC 3261 section 12.2.2 already defines what must happen when requests are received out of order; a 500 response MUST be sent. Thus retargeting requests from the same direction are already accommodated. There are numerous race conditions associated with devices using responses to re-target. Device Y should not be confident that a re-target response will be processed correctly by device X when device Y is currently awaiting a response for request containing the Contact of prior target. Using a retarget sequence number or Date header potentially could help solve the problem; however it is likely not worth the extra specification to define it. Some issues with dialog sharing and retargeting were captured within the following: http://www.ietf.org/mail-archive/working-groups/sip/current/msg06767.html _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Jan 13 21:21:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01778 for ; Mon, 13 Jan 2003 21:21:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0E2ZkN09875 for sip-archive@odin.ietf.org; Mon, 13 Jan 2003 21:35:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E2ZMJ09850; Mon, 13 Jan 2003 21:35:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E2XFJ09753 for ; Mon, 13 Jan 2003 21:33:15 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01686 for ; Mon, 13 Jan 2003 21:18:48 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h0E2LvTI003332 for ; Mon, 13 Jan 2003 20:22:09 -0600 From: "Dean Willis" To: Date: Mon, 13 Jan 2003 20:21:45 -0600 Message-ID: <003301c2bb73$b6528650$fe0c0c42@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0E2XFJ09754 Subject: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit It only seemed appropriate to follow up my previous assumably eloquent but frequently misspelled exhortations by following my own advice and "sending text". The resulting draft has been submitted to the archive and should be announced in due course. In the interim, you may wish to retrieve it from: http://www.softarmor.com/sipwg/drafts/draft-willis-sip-infopackage-00.html or http://www.softarmor.com/sipwg/drafts/draft-willis-sip-infopackage-00.txt Or, if you just LIKE looking at XML source or wish to fix some of my probable glaring errors, http://www.softarmor.com/sipwg/drafts/draft-willis-sip-infopackage-00.xml I'd like to caveat that this is a rough first draft -- I just sat down and banged it out this afternoon, and only Adam Roach has seen any of it so far, and that was in small bits. thanks -- 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 mailnull@www1.ietf.org Tue Jan 14 09:45:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25505 for ; Tue, 14 Jan 2003 09:45:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EF09M01619 for sip-archive@odin.ietf.org; Tue, 14 Jan 2003 10:00:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EExRJ01511; Tue, 14 Jan 2003 09:59:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EEuBJ01375 for ; Tue, 14 Jan 2003 09:56:11 -0500 Received: from face.sentitonetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25415 for ; Tue, 14 Jan 2003 09:41:29 -0500 (EST) Received: (qmail 4256 invoked from network); 14 Jan 2003 14:44:50 -0000 Received: from unknown (HELO overhill) (10.0.0.35) by face.sentito.com with SMTP; 14 Jan 2003 14:44:50 -0000 Message-ID: <002901c2bbdb$7e4d9200$2300000a@overhill> From: "Frank W. Miller" To: "Dean Willis" Cc: References: <003301c2bb73$b6528650$fe0c0c42@txdwillis> Subject: Re: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 Date: Tue, 14 Jan 2003 09:44:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Looks like a good compromise. FM Frank W. Miller, Ph.D. Chief Technical Officer sentitO Network, Inc. fmiller@sentito.com ----- Original Message ----- From: "Dean Willis" To: Sent: Monday, January 13, 2003 9:21 PM Subject: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 > > It only seemed appropriate to follow up my previous assumably eloquent but > frequently misspelled exhortations by following my own advice and "sending > text". > > The resulting draft has been submitted to the archive and should be > announced in due course. In the interim, you may wish to retrieve it from: > > http://www.softarmor.com/sipwg/drafts/draft-willis-sip-infopackage-00.html > > or > > http://www.softarmor.com/sipwg/drafts/draft-willis-sip-infopackage-00.txt > > Or, if you just LIKE looking at XML source or wish to fix some of my > probable glaring errors, > > http://www.softarmor.com/sipwg/drafts/draft-willis-sip-infopackage-00.xml > > > I'd like to caveat that this is a rough first draft -- I just sat down and > banged it out this afternoon, and only Adam Roach has seen any of it so far, > and that was in small bits. > > thanks > > -- > 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 mailnull@www1.ietf.org Tue Jan 14 09:51:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25743 for ; Tue, 14 Jan 2003 09:51:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EF5fw01917 for sip-archive@odin.ietf.org; Tue, 14 Jan 2003 10:05:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EF5IJ01880; Tue, 14 Jan 2003 10:05:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EF4OJ01828 for ; Tue, 14 Jan 2003 10:04:24 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25698 for ; Tue, 14 Jan 2003 09:49:42 -0500 (EST) Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h0EEr3uP017583 for ; Tue, 14 Jan 2003 07:53:04 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id HAA00953 for ; Tue, 14 Jan 2003 07:53:03 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Tue, 14 Jan 2003 08:53:03 -0600 Message-ID: <796456A0F96AD511A0AC009027B0F7410B89FF16@IL27EXM08.cig.mot.com> From: Idnani Ajaykumar-AIDNANI1 To: sip@ietf.org Date: Tue, 14 Jan 2003 08:52:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BBDC.9358B028" Subject: [Sip] Question about Redirect Server Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2BBDC.9358B028 Content-Type: text/plain Hi All, I have a very simple question about the operation of Redirect Servers. Me and colleague out here can not seem to convince each other on this, so I thought I will email all the SIP experts here :-). When a Redirect Server gets a request, it is supposed to return back the Contacts for the called party. Where does it pick the address of the called party from. Is it the To address or the Request-URI? The assumption here is that the Redirect Server is co-located with the Registrar, and has access to the database of the Registrar. When the Redirect Server is searching within this database, what does it use as the key for searching - To Address or the Request-URI. Appreciate your help. Thanks and Regards - Ajay ------_=_NextPart_001_01C2BBDC.9358B028 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Hi All,

 

I have a very simple question about the operation of Redirect Servers. Me and colleague out here can not seem to convince = each other on this, so I thought I will email all the SIP experts here J.

 

When a Redirect Server gets a request, it is = supposed to return back the Contacts for the called party. Where does it pick the = address of the called party from. Is it the To address or the Request-URI? The assumption here is that the Redirect = Server is co-located with the Registrar, and has access to the database of the Registrar. = When the Redirect Server is searching within this database, what does it use as = the key for searching - To Address or the Request-URI.

 

Appreciate your help.

 

Thanks and Regards

- Ajay

------_=_NextPart_001_01C2BBDC.9358B028-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Jan 14 11:02:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29798 for ; Tue, 14 Jan 2003 11:02:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EGGf108176 for sip-archive@odin.ietf.org; Tue, 14 Jan 2003 11:16:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EGGCJ08162; Tue, 14 Jan 2003 11:16:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EGEBJ08073 for ; Tue, 14 Jan 2003 11:14:11 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29718 for ; Tue, 14 Jan 2003 10:59:29 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0EG1PKW021469; Tue, 14 Jan 2003 17:02:45 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZQ1GS8Y1; Tue, 14 Jan 2003 17:01:25 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h0EG1Pu4019453; Tue, 14 Jan 2003 18:01:25 +0200 (EET) Message-ID: <3E243454.3B30B59F@lmf.ericsson.se> Date: Tue, 14 Jan 2003 18:01:24 +0200 X-Sybari-Trust: f11c97eb 1864f774 32da6779 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: sip@ietf.org Subject: Re: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 References: <003301c2bb73$b6528650$fe0c0c42@txdwillis> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, To negotiate what INFO can be used for between nodes is good thing, and at least on a theoretical level it solves one issue. But, is the biggest problem we have today end-nodes receiving INFOs with data they don't know to handle? And, how is this going to solve the problem of having people using INFO for whatever purpose? All they have to do is to define a package for their who-knows-what data, right? Or, does defining a package allow one to use INFO for whatever he/she wants? Or, do we accept Henning's rule about the "bad guys", and do NOT try to define any rules on exactly what kind of data INFO should be used for in the first place? I am not saying that this draft should solve anything, but I would like to know exactly which issues regarding INFO we are going to try solving :) Regards, Christer Holmberg Ericsson Finland Dean Willis wrote: > It only seemed appropriate to follow up my previous assumably eloquent but > frequently misspelled exhortations by following my own advice and "sending > text". > > The resulting draft has been submitted to the archive and should be > announced in due course. In the interim, you may wish to retrieve it from: > > http://www.softarmor.com/sipwg/drafts/draft-willis-sip-infopackage-00.html > > or > > http://www.softarmor.com/sipwg/drafts/draft-willis-sip-infopackage-00.txt > > Or, if you just LIKE looking at XML source or wish to fix some of my > probable glaring errors, > > http://www.softarmor.com/sipwg/drafts/draft-willis-sip-infopackage-00.xml > > I'd like to caveat that this is a rough first draft -- I just sat down and > banged it out this afternoon, and only Adam Roach has seen any of it so far, > and that was in small bits. > > thanks > > -- > 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 mailnull@www1.ietf.org Tue Jan 14 11:03:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29832 for ; Tue, 14 Jan 2003 11:03:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EGHTK08268 for sip-archive@odin.ietf.org; Tue, 14 Jan 2003 11:17:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EGH6J08208; Tue, 14 Jan 2003 11:17:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EGFVJ08120 for ; Tue, 14 Jan 2003 11:15:32 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29759 for ; Tue, 14 Jan 2003 11:00:46 -0500 (EST) Received: from prasannacl1105 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H8P00HNROJMAN@mta0.huawei.com> for sip@ietf.org; Wed, 15 Jan 2003 00:02:12 +0800 (CST) Date: Tue, 14 Jan 2003 21:35:30 +0530 From: Prasanna Venkatesh Subject: RE: [Sip] Question about Redirect Server In-reply-to: <796456A0F96AD511A0AC009027B0F7410B89FF16@IL27EXM08.cig.mot.com> To: Idnani Ajaykumar-AIDNANI1 , sip@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi, As per the RFC-3261 on the first hop it is expected that the To and the Request-URI are same. In this case your query does not have any problem. If some intermediate proxy has changed the request-URI then, the request-uri being the latest should be used to search the registrar. However it depends on the design of the registry database also. If the database caters only to one domain, then just the user part of the request-uri is taken and the address can be resolved. If the database caters to more than one domain, and if by chance the host part of the request-uri is an IP then, the host part of the To along with the user part of the request-uri is taken as the key. Cheers, Prasanna -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Idnani Ajaykumar-AIDNANI1 Sent: Tuesday, January 14, 2003 8:23 PM To: sip@ietf.org Subject: [Sip] Question about Redirect Server Hi All, I have a very simple question about the operation of Redirect Servers. Me and colleague out here can not seem to convince each other on this, so I thought I will email all the SIP experts here J. When a Redirect Server gets a request, it is supposed to return back the Contacts for the called party. Where does it pick the address of the called party from. Is it the To address or the Request-URI? The assumption here is that the Redirect Server is co-located with the Registrar, and has access to the database of the Registrar. When the Redirect Server is searching within this database, what does it use as the key for searching - To Address or the Request-URI. Appreciate your help. Thanks and Regards - Ajay _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Jan 14 11:27:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01899 for ; Tue, 14 Jan 2003 11:27:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EGg1L11242 for sip-archive@odin.ietf.org; Tue, 14 Jan 2003 11:42:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EGfAJ11217; Tue, 14 Jan 2003 11:41:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EGbxJ11012 for ; Tue, 14 Jan 2003 11:37:59 -0500 Received: from ihemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01453 for ; Tue, 14 Jan 2003 11:23:16 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0EGQYj08411 for ; Tue, 14 Jan 2003 11:26:35 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jan 2003 16:26:33 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EBA5@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Dean Willis'" , sip@ietf.org Subject: RE: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 Date: Tue, 14 Jan 2003 16:26:31 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , In principle, the idea looks good to me. I would note that the proposal invalidates existing usages of the INFO method, as presumably all usages of INFO carry the new header Info-Type and the dialog should presumably be created carrying the Allow-Info header. Assuming we allow this constraint, which is OK by me but some people who have already implemented it might shout, then it would seem better to document this by obsoleting the existing version of INFO (RFC 2976) and creating a new one; this would allow the method specification to be aligned with RFC 3261 rather than RFC 2543 (and also allow its interaction with all the other new RFCs to be specified - although I assume this interaction is fairly minimal - the only impact I can see is the inclusion of the Allow-Events header in INFO). From this proposal there is possibly a minor impact on RFC 3398. This document requires a gateway to support the INFO method. Presumably it would be appropropriate that the gateway now advertises the type of INFO usage that it supports (i.e. ISUP encapsulation), and this would be a requirement that should be in RFC 3398 rather than elsewhere. Strangely enough, we seem to have absolutely no examples of the use of INFO to carry mid call information, so no changes are generated as a result of this. However the advertising of the capability would have impact on http://www.ietf.org/internet-drafts/draft-ietf-sipping-pstn-call-flows-01.txt, as might be expected. The example in section 4.1 of RFC 3204 would also be invalidated by the proposal as it stands. Detailed comments: 1) I assume that reference [5] should be to RFC 3261, rather than RFC 3162. Correction required both in the body of the document and in the references themselves. 2) In section 4 and 5, I am unsure why the Supported header needs to be in all requests. Surely INFO can only be used in an INVITE dialog, therefore it is sufficient to put it in the INVITE (and of course OPTIONS). Also why is the same requirement duplicated in both sections. Perhaps the use of the option-tags should be brought out to a separate section, e.g. incorporated into 7.1. Note that there is a typo at the end of the clause 5 text on the option-tags. It is also not practice to put header names in quotation marks. 3) Figure 1 and figure 2 should really be tables rather than figures, and should show all the methods currently defined - see RFC 3455 for an example. 4) The Allow-Events header only appears in requests. I assume the same considerations apply to the new Allow-Info header and this should be appropriately indicated in figure 1. 5) In figure 2, surely the Info-Type header only applies to requests and this should be indicated appropriately, as only the INFO request can carry the data. 6) The IANA considerations section is missing the Info-Type header. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 14 January 2003 02:22 > To: sip@ietf.org > Subject: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 > > > > It only seemed appropriate to follow up my previous assumably > eloquent but > frequently misspelled exhortations by following my own advice > and "sending > text". > > The resulting draft has been submitted to the archive and should be > announced in due course. In the interim, you may wish to > retrieve it from: > > http://www.softarmor.com/sipwg/drafts/draft-willis-sip-infopac kage-00.html or http://www.softarmor.com/sipwg/drafts/draft-willis-sip-infopackage-00.txt Or, if you just LIKE looking at XML source or wish to fix some of my probable glaring errors, http://www.softarmor.com/sipwg/drafts/draft-willis-sip-infopackage-00.xml I'd like to caveat that this is a rough first draft -- I just sat down and banged it out this afternoon, and only Adam Roach has seen any of it so far, and that was in small bits. thanks -- 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 mailnull@www1.ietf.org Tue Jan 14 11:28:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01948 for ; Tue, 14 Jan 2003 11:28:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EGghx11346 for sip-archive@odin.ietf.org; Tue, 14 Jan 2003 11:42:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EGgAJ11267; Tue, 14 Jan 2003 11:42:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EGc0J11018 for ; Tue, 14 Jan 2003 11:38:00 -0500 Received: from brazilnut.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01455 for ; Tue, 14 Jan 2003 11:23:17 -0500 (EST) Received: from cs.columbia.edu (nas-cbv-6-62-147-149-122.dial.proxad.net [62.147.149.122]) (user=hgs10 mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0EGQCLM011064 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 14 Jan 2003 11:26:28 -0500 (EST) Message-ID: <3E24398F.8090205@cs.columbia.edu> Date: Tue, 14 Jan 2003 11:23:43 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christer Holmberg CC: Dean Willis , sip@ietf.org Subject: Re: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 References: <003301c2bb73$b6528650$fe0c0c42@txdwillis> <3E243454.3B30B59F@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > To negotiate what INFO can be used for between nodes is good thing, and at least > on a theoretical level it solves one issue. It would be nice to motivate how this differs and intersects with the Content-* indication and negotiation mechanism. After all, if INFO transports objects that are opaque to the "SIP layer" (e.g., session state), the logical indication of use is via the various Content-* indications. > > But, is the biggest problem we have today end-nodes receiving INFOs with data > they don't know to handle? And, how is this going to solve the problem of having > people using INFO for whatever purpose? All they have to do is to define a > package for their who-knows-what data, right? Or, does defining a package allow > one to use INFO for whatever he/she wants? Beyond ISUP and maybe DTMF, what is INFO used for today, by both the good and bad guys? What proposals are out there? Last time this was discussed, the list seemed pretty short. I think we agree that DTMF has better, non-INFO solutions. With events, we have a whole set of examples and applications to draw on. Building a mechanism on an example space of one seems a bit dangerous. > > Or, do we accept Henning's rule about the "bad guys", and do NOT try to define > any rules on exactly what kind of data INFO should be used for in the first > place? I do think it would be helpful if this draft or some other draft indicated where SIP INFO *may* be appropriate. As discussed, this seems to involve things where SIP routing and proxies are needed or useful, for example. > > I am not saying that this draft should solve anything, but I would like to know > exactly which issues regarding INFO we are going to try solving :) > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > Dean Willis wrote: > > >>It only seemed appropriate to follow up my previous assumably eloquent but >>frequently misspelled exhortations by following my own advice and "sending >>text". >> >>The resulting draft has been submitted to the archive and should be >>announced in due course. In the interim, you may wish to retrieve it from: >> >>http://www.softarmor.com/sipwg/drafts/draft-willis-sip-infopackage-00.html >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Jan 14 13:57:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06984 for ; Tue, 14 Jan 2003 13:57:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EJC7a22712 for sip-archive@odin.ietf.org; Tue, 14 Jan 2003 14:12:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJBaJ22659; Tue, 14 Jan 2003 14:11:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJ9BJ22566 for ; Tue, 14 Jan 2003 14:09:11 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06863 for ; Tue, 14 Jan 2003 13:54:24 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h0EIvhTF009158; Tue, 14 Jan 2003 12:57:43 -0600 From: "Dean Willis" To: "'Drage, Keith \(Keith\)'" , Date: Tue, 14 Jan 2003 12:57:31 -0600 Message-ID: <001701c2bbfe$caaf7960$fe0c0c42@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439EBA5@en0033exch001u.uk.lucent.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0EJ9BJ22568 Subject: [Sip] Table 2 and INFO Packaging -- draft-willis-sip-infopackage-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Keith said: > 3) Figure 1 and figure 2 should really be tables rather > than figures, and should show all the methods currently > defined - see RFC 3455 for an example. . . . > 5) In figure 2, surely the Info-Type header only applies > to requests and this should be indicated appropriately, as > only the INFO request can carry the data. We have SO got to stop trying to to update these tables. It's a cubic expansion problem, and I don't think it's actually possible to get right, as new stuff appears between the writing and the publishing. Any ideas on alternatives? Can we simply stop tracking this? Does it need to be turned into some kind of IANA registry? How could we approach the problem if we made it a registry? -- 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 mailnull@www1.ietf.org Tue Jan 14 13:57:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07001 for ; Tue, 14 Jan 2003 13:57:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EJCCs22735 for sip-archive@odin.ietf.org; Tue, 14 Jan 2003 14:12:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJBpJ22689; Tue, 14 Jan 2003 14:11:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJ9BJ22567 for ; Tue, 14 Jan 2003 14:09:11 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06862 for ; Tue, 14 Jan 2003 13:54:24 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h0EIvhTG009158; Tue, 14 Jan 2003 12:57:44 -0600 From: "Dean Willis" To: "'Christer Holmberg'" Cc: Subject: RE: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 Date: Tue, 14 Jan 2003 12:57:31 -0600 Message-ID: <001901c2bbfe$cafbebb0$fe0c0c42@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3E243454.3B30B59F@lmf.ericsson.se> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0EJ9BJ22570 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > To negotiate what INFO can be used for between nodes is good > thing, and at least on a theoretical level it solves one issue. > > But, is the biggest problem we have today end-nodes receiving > INFOs with data they don't know to handle? Well, the "I don't know what this means" problem is really there. SIP-T basically requires configuration to "know" that the other end understands and wants ISUP. That's a little bit clumsy. > And, how is this > going to solve the problem of having people using INFO for > whatever purpose? All they have to do is to define a package > for their who-knows-what data, right? Or, does defining a > package allow one to use INFO for whatever he/she wants? Welll, this draft basically induces the same sort of review process that is in place for P-headers and event packages -- to get a registered info-package "name", you have to document this usage as an RFC (any track) that receives expert review from SIP. The goal here is to help make sure that anything widely deployed is at least documented in a reasonable fashion. My basic philosphy is that if something is going be be a kitchen sink, we should at least make it a sturdy kitchen sink, try to keep it from getting plugged up with garbage, and establish some communications between the users of the sink. > Or, do we accept Henning's rule about the "bad guys", and do > NOT try to define any rules on exactly what kind of data INFO > should be used for in the first place? Personally, I don't really care what kind of data INFO gets used for. Market reality is going to shape the usages towards "stuff that works" -- for example, I believe the world has realized that using INFO for floor control over 3G wireless networks just doesn't work. But somebody had to try it before we really knew. It seems to me that INFO is reasonably useful wherever one needs to send application data along a relationship path established by a SIP dialog, AND that data has no particular relationship with the SIP state machine, AND the timing, load, and capacity characteristics of the SIP network are appropriate for that sort of application. People will probably come up with some downright weird usages. Some may work. Some probably won't. But as long as they don't step on each other, they're probably only hurting themselves. This draft (like the congestion safety work) is about keeping people from stepping on each other. -- 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 mailnull@www1.ietf.org Tue Jan 14 14:15:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07929 for ; Tue, 14 Jan 2003 14:15:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EJTsn23858 for sip-archive@odin.ietf.org; Tue, 14 Jan 2003 14:29:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJTPJ23827; Tue, 14 Jan 2003 14:29:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJSUJ23748 for ; Tue, 14 Jan 2003 14:28:30 -0500 Received: from ihemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07804 for ; Tue, 14 Jan 2003 14:13:43 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0EJH3I23312 for ; Tue, 14 Jan 2003 14:17:03 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jan 2003 19:17:01 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EBA9@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Dean Willis'" , "Drage, Keith (Keith)" , sip@ietf.org Date: Tue, 14 Jan 2003 19:17:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sip] RE: Table 2 and INFO Packaging -- draft-willis-sip-infopackage- 00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , The problem is that these tables are the only place where some of this information appears. By all means find some other mechanism, but the information is still in general necessary. For example, my comment 5) that the header only applies to a request could quite easily be written in text, but is normally shown only by an "R" in the tables. However it is specified, it still seems to me to be a fairly important bit of information, and if it is not followed could lead to a number of incompatibilities wehre one side provides the information and the other side says it is unnecessary to follow it. In general, there is a very common pattern to the entries in the tables. One possible solution would be to replace the existing method columns by a set of columns that relate to - initial method of dialog - target refresh for a dialog - subsequent method of dialog - method outside dialog unfortunately ACK and CANCEL seem to have their own special set of inconsistencies with regard to the use of various headers, but this can probably be dealt with entirely in RFC 3261. Similarly REGISTER creates its own problems, but could be dealt with by saying that new headers are handled as "method outside dialog" unless explicit requirements are stated elsewhere. Such a change would get rid of the 2nd dimension, where the table extends further to the right as new methods are added, and may actually introduce a bit more consistency into the usages. Note that the where and proxy columns should continue to be used as is. [Aside - alternatively we could just stop adding new methods and use INFO for everything :-) ] Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 14 January 2003 18:58 > To: 'Drage, Keith (Keith)'; sip@ietf.org > Subject: Table 2 and INFO Packaging -- draft-willis-sip-infopackage-00 > > > Keith said: > > 3) Figure 1 and figure 2 should really be tables rather > > than figures, and should show all the methods currently > > defined - see RFC 3455 for an example. > . . . > > 5) In figure 2, surely the Info-Type header only applies > > to requests and this should be indicated appropriately, as > > only the INFO request can carry the data. > > We have SO got to stop trying to to update these tables. It's a cubic > expansion problem, and I don't think it's actually possible > to get right, as > new stuff appears between the writing and the publishing. > > Any ideas on alternatives? Can we simply stop tracking this? > Does it need to > be turned into some kind of IANA registry? How could we > approach the problem > if we made it a registry? > > > -- > 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 mailnull@www1.ietf.org Tue Jan 14 14:49:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09272 for ; Tue, 14 Jan 2003 14:49:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EK3lZ26635 for sip-archive@odin.ietf.org; Tue, 14 Jan 2003 15:03:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJxSJ26428; Tue, 14 Jan 2003 14:59:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJwIJ26372 for ; Tue, 14 Jan 2003 14:58:18 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09102 for ; Tue, 14 Jan 2003 14:43:30 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id h0EJkqfm027324; Tue, 14 Jan 2003 11:46:52 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADE18033; Tue, 14 Jan 2003 11:43:37 -0800 (PST) Date: Tue, 14 Jan 2003 11:46:41 -0800 Subject: Re: [Sip] Enrollment in SIP services (and should we undeprecate basic auth) Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Michael Thomas , Robert Sparks , Jonathan Rosenberg , Cullen Jennings , sip@ietf.org To: jh@lohi.eng.song.fi From: Rohan Mahy In-Reply-To: <15893.56958.498359.867714@harjus.eng.song.fi> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit thanks juha, i also reposted in the morgue on softarmor http://kevlar.softarmor.com/sipping/drafts/morgue/draft-sterman-aaa- sip-00.txt thx, -r On Friday, January 3, 2003, at 11:03 AM, jh@lohi.eng.song.fi wrote: > Michael Thomas writes: > >> Well, it seems to be expried for one... is the jist >> that AAA's have been hacked to deal with digest auth >> types directly (or, say, as an EAP type)? > > i made draft-sterman-aaa-sip-00.txt available as > > ftp://lohi.eng.song.fi/tmp/draft-sterman-aaa-sip-00.txt > > the directory is not listable. > > -- juha > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Jan 14 15:01:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09725 for ; Tue, 14 Jan 2003 15:01:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EKFUg28006 for sip-archive@odin.ietf.org; Tue, 14 Jan 2003 15:15:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EK7BJ27109; Tue, 14 Jan 2003 15:07:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EK6oJ26819 for ; Tue, 14 Jan 2003 15:06:50 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09362 for ; Tue, 14 Jan 2003 14:52:01 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h0EJtFTF009556; Tue, 14 Jan 2003 13:55:16 -0600 From: "Dean Willis" To: "'Henning Schulzrinne'" , "'Christer Holmberg'" Cc: Subject: RE: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 Date: Tue, 14 Jan 2003 13:55:03 -0600 Message-ID: <001f01c2bc06$d4609400$fe0c0c42@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3E24398F.8090205@cs.columbia.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0EK6oJ26820 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Henning said: > It would be nice to motivate how this differs and intersects with the > Content-* indication and negotiation mechanism. After all, if INFO > transports objects that are opaque to the "SIP layer" (e.g., session > state), the logical indication of use is via the various Content-* > indications. I'm not sure I understand this. Are you saying that we could replace INFO usage with a Content-Indirected MIME type? > Beyond ISUP and maybe DTMF, what is INFO used for today, by both the > good and bad guys? What proposals are out there? Last time this was > discussed, the list seemed pretty short. I think we agree > that DTMF has > better, non-INFO solutions. Well, people have also used or mentioned using INFO for * conference control (instructing a conference server to add and delete legs) * floor control in a conference bridge (which has timing issues for 3G) * gaming applications (like transmitting chess moves in parallel to a voice call) * pushing user interface components, like data entry forms, keypad layouts (kpml type stuff), and java applets * delivering SOAP * delivering vCards * delivering calendar data Some of these are probably bogus. Others may be better-implemented other ways. All, if implemented usingINFO, could benefit from negotiation (Does the other guy SUPPORT sending chess moves?) and documentation (Does she mean the same thing I mean when I send her a application/xchess INFO . . . -- 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 mailnull@www1.ietf.org Tue Jan 14 15:30:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10529 for ; Tue, 14 Jan 2003 15:30:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EKiI330442 for sip-archive@odin.ietf.org; Tue, 14 Jan 2003 15:44:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKhjJ30402; Tue, 14 Jan 2003 15:43:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKgwJ30345 for ; Tue, 14 Jan 2003 15:42:58 -0500 Received: from brazilnut.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10498 for ; Tue, 14 Jan 2003 15:28:09 -0500 (EST) Received: from cs.columbia.edu (nas-cbv-6-62-147-149-122.dial.proxad.net [62.147.149.122]) (user=hgs10 mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0EKVRLM014833 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 14 Jan 2003 15:31:30 -0500 (EST) Message-ID: <3E24730B.2050707@cs.columbia.edu> Date: Tue, 14 Jan 2003 15:28:59 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: "'Christer Holmberg'" , sip@ietf.org Subject: Re: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 References: <001f01c2bc06$d4609400$fe0c0c42@txdwillis> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > I'm not sure I understand this. Are you saying that we could replace INFO > usage with a Content-Indirected MIME type? No. We currently negotiate above-SIP content with Content-Type, Content-Language and all the other Content-Headers, just like HTTP, SMTP and other MIME users. If the body contains message/isup, it is an ISUP message. It is not clear to me what value an additional, semi-orthogonal negotiation mechanism offers. (Semi-orthogonal, since most INFO types will have exactly one valid Content-Type.) > Well, people have also used or mentioned using INFO for > > * conference control (instructing a conference server to add and delete > legs) > > * floor control in a conference bridge (which has timing issues for 3G) > > * gaming applications (like transmitting chess moves in parallel to a voice > call) > > * pushing user interface components, like data entry forms, keypad layouts > (kpml type stuff), and java applets > > * delivering SOAP > > * delivering vCards > > * delivering calendar data > > Some of these are probably bogus. Others may be better-implemented other > ways. All, if implemented usingINFO, could benefit from negotiation (Does > the other guy SUPPORT sending chess moves?) and documentation (Does she mean > the same thing I mean when I send her a application/xchess INFO . . . It seems that the meaning should precisely depend on the content type and the content disposition. > > > -- > 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 mailnull@www1.ietf.org Tue Jan 14 18:40:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16226 for ; Tue, 14 Jan 2003 18:40:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0ENsYl13031 for sip-archive@odin.ietf.org; Tue, 14 Jan 2003 18:54:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ENsFJ13017; Tue, 14 Jan 2003 18:54:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ENpvJ12957 for ; Tue, 14 Jan 2003 18:51:57 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16069 for ; Tue, 14 Jan 2003 18:37:05 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h0ENeHTF010881; Tue, 14 Jan 2003 17:40:18 -0600 From: "Dean Willis" To: "'Henning Schulzrinne'" Cc: "'Christer Holmberg'" , Subject: RE: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 Date: Tue, 14 Jan 2003 17:40:04 -0600 Message-ID: <004701c2bc26$44627ec0$fe0c0c42@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3E24730B.2050707@cs.columbia.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0ENpwJ12958 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > could replace > > INFO usage with a Content-Indirected MIME type? > > No. We currently negotiate above-SIP content with Content-Type, > Content-Language and all the other Content-Headers, just like > HTTP, SMTP > and other MIME users. If the body contains message/isup, it > is an ISUP > message. It is not clear to me what value an additional, > semi-orthogonal > negotiation mechanism offers. (Semi-orthogonal, since most INFO types > will have exactly one valid Content-Type.) Ah. Actually, that is the direction that I initially started taking things in the draft -- basically, I associated MIME content-types with usages, and didn't have the Info-Type. Then I briefly talked it over with Adam, and he talked me into the separate semantic indicator. I believe that the assertion that "most INFO types will have exactly one valid Content-Type" is the breaker. Let's look at text. Is the text I just sent you indicative of a move in the chess game we are playing? Is it something I want you to post on a web page for me? Should you just read it? Is it a javascript that you should use to remap your keyboard? Is it C code that you should compile and execute? Is it a credit card number that you should debit for the price of this call? Why the heck AM I sending it to you? There are probably much better examples, but I think that a one-to-one mapping between content-type and expected function is more constraining than the way I think people are trying to use INFO, perhaps overly constraining. -- 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 mailnull@www1.ietf.org Wed Jan 15 03:28:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19913 for ; Wed, 15 Jan 2003 03:28:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0F8guG22706 for sip-archive@odin.ietf.org; Wed, 15 Jan 2003 03:42:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F8gTJ22672; Wed, 15 Jan 2003 03:42:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F8eMJ22555 for ; Wed, 15 Jan 2003 03:40:22 -0500 Received: from gw-nl6.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19841; Wed, 15 Jan 2003 03:25:18 -0500 (EST) From: frank.derks@philips.com Received: from smtpscan-nl4.philips.com (smtpscan-nl4.philips.com [130.139.36.24]) by gw-nl6.philips.com (Postfix) with ESMTP id 56D03A4603; Wed, 15 Jan 2003 09:28:36 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl4.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id JAA26945; Wed, 15 Jan 2003 09:28:35 +0100 (MET) Received: from ehv001soh.diamond.philips.com (e2soh01.diamond.philips.com [130.139.52.13]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id JAA25233; Wed, 15 Jan 2003 09:28:34 +0100 (MET) To: Henning Schulzrinne Cc: Christer Holmberg , Dean Willis , sip@ietf.org, sip-admin@ietf.org Subject: Re: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 15 Jan 2003 09:26:53 +0100 X-MIMETrack: Serialize by Router on ehv001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 15/01/2003 09:26:55, Serialize complete at 15/01/2003 09:26:55 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Henning, >> >> But, is the biggest problem we have today end-nodes receiving INFOs with data >> they don't know to handle? And, how is this going to solve the problem of having >> people using INFO for whatever purpose? All they have to do is to define a >> package for their who-knows-what data, right? Or, does defining a package allow >> one to use INFO for whatever he/she wants? > >Beyond ISUP and maybe DTMF, what is INFO used for today, by both the >good and bad guys? What proposals are out there? Last time this was >discussed, the list seemed pretty short. I think we agree that DTMF has >better, non-INFO solutions. Like for ISUP, ECMA is also in the process of defining the use of INFO for QSIG. Regards, Frank _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Jan 15 08:01:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24615 for ; Wed, 15 Jan 2003 08:01:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FDFln08213 for sip-archive@odin.ietf.org; Wed, 15 Jan 2003 08:15:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FDFHJ08121; Wed, 15 Jan 2003 08:15:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FDDDJ08009 for ; Wed, 15 Jan 2003 08:13:13 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24301; Wed, 15 Jan 2003 07:58:04 -0500 (EST) Message-Id: <200301151258.HAA24301@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org, sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 15 Jan 2003 07:58:03 -0500 Subject: [Sip] I-D ACTION:draft-willis-sip-infopackage-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Packaging and Negotiation of INFO Methods for the Session Initiation Protocol (SIP) Author(s) : D. Willis Filename : draft-willis-sip-infopackage-00.txt Pages : 11 Date : 2003-1-14 The SIP INFO method (RFC 2976) establishes a method by which applications may transfer application-specific information within a SIP dialog. However, RFC 2976 does not provide a mechanism for describing and documenting an application of INFO, nor does it provide a mechanism by which applications may negotiate such uses. This document provides a framework for documenting and naming specific uses of INFO (called INFO packages), for registering those package names with IANA, and for negotiating the support for various INFO packages between applications using SIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-willis-sip-infopackage-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-willis-sip-infopackage-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-willis-sip-infopackage-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-14150945.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-willis-sip-infopackage-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-willis-sip-infopackage-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-14150945.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Jan 15 09:00:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27506 for ; Wed, 15 Jan 2003 09:00:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FEF5S12488 for sip-archive@odin.ietf.org; Wed, 15 Jan 2003 09:15:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FEEfJ12471; Wed, 15 Jan 2003 09:14:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FEDFJ12421 for ; Wed, 15 Jan 2003 09:13:15 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27465 for ; Wed, 15 Jan 2003 08:58:05 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0FE1QAv013577 for ; Wed, 15 Jan 2003 15:01:26 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNDDA0V; Wed, 15 Jan 2003 15:01:25 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.40]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h0FE1Ou4025126 for ; Wed, 15 Jan 2003 16:01:24 +0200 (EET) Message-ID: <3E2569B3.B26F4A6@lmf.ericsson.se> Date: Wed, 15 Jan 2003 16:01:23 +0200 X-Sybari-Trust: 0db90a94 1864f774 206fc897 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Via maddr Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I appologise if this has been discussed before, but at least I didn't find it in my mail box (I admit I didn't check the archieve on the web). Anyway... Chapter 18.2.2 in RFC3261 talks about the routing of responses, using the Via maddr, received and sent-by parameters. My question is regarding maddr. When reading the text, I get the picture that only IP addresses are used in maddr. At least the text doesn't mention the SRV RFC, which it does for sent-by, and it says that the default port is 5060. However, the ABNF defines maddr as "host", which can also be a domain name. So, is there a bug in the ABNF, or have I missunderstood something? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Jan 15 09:33:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28500 for ; Wed, 15 Jan 2003 09:33:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FEmHN14790 for sip-archive@odin.ietf.org; Wed, 15 Jan 2003 09:48:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FElsJ14763; Wed, 15 Jan 2003 09:47:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FEkPJ14679 for ; Wed, 15 Jan 2003 09:46:25 -0500 Received: from hoemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28457 for ; Wed, 15 Jan 2003 09:31:15 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0FEYZk02459 for ; Wed, 15 Jan 2003 09:34:35 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Jan 2003 14:34:33 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EBAE@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Dean Willis'" , "'Henning Schulzrinne'" Cc: sip@ietf.org Subject: RE: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 Date: Wed, 15 Jan 2003 14:34:31 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I nearly made the same comment as Henning when I made my comments, but decided I did not know enough about Content-Type etc usage to make the comment sensibly. I would like to see some more discussion on this as I am not yet convinced either way. If we end up following Deans proposal for a new header Info-Type, then at least we will need to capture some of this discussion in order that: - specifiers of new packages make sensible choices of values for Info-Type - implementers choose values of Content-* that are consistent with the Info-Type value. Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 14 January 2003 23:40 > To: 'Henning Schulzrinne' > Cc: 'Christer Holmberg'; sip@ietf.org > Subject: RE: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 > > > > could replace > > > INFO usage with a Content-Indirected MIME type? > > > > No. We currently negotiate above-SIP content with Content-Type, > > Content-Language and all the other Content-Headers, just like > > HTTP, SMTP > > and other MIME users. If the body contains message/isup, it > > is an ISUP > > message. It is not clear to me what value an additional, > > semi-orthogonal > > negotiation mechanism offers. (Semi-orthogonal, since most > INFO types > > will have exactly one valid Content-Type.) > > Ah. Actually, that is the direction that I initially started > taking things > in the draft -- basically, I associated MIME content-types > with usages, and > didn't have the Info-Type. Then I briefly talked it over with > Adam, and he > talked me into the separate semantic indicator. > > I believe that the assertion that "most INFO types will have > exactly one > valid Content-Type" is the breaker. Let's look at text. Is > the text I just > sent you indicative of a move in the chess game we are playing? Is it > something I want you to post on a web page for me? Should you > just read it? > Is it a javascript that you should use to remap your > keyboard? Is it C code > that you should compile and execute? Is it a credit card > number that you > should debit for the price of this call? Why the heck AM I > sending it to > you? > > There are probably much better examples, but I think that a one-to-one > mapping between content-type and expected function is more > constraining than > the way I think people are trying to use INFO, perhaps overly > constraining. > > -- > 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 mailnull@www1.ietf.org Wed Jan 15 10:15:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29481 for ; Wed, 15 Jan 2003 10:15:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FFUG917447 for sip-archive@odin.ietf.org; Wed, 15 Jan 2003 10:30:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FFTiJ17385; Wed, 15 Jan 2003 10:29:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FFRhJ17240 for ; Wed, 15 Jan 2003 10:27:43 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29373 for ; Wed, 15 Jan 2003 10:12:31 -0500 (EST) Received: from cs.columbia.edu (toulouse-1-a7-62-147-220-84.dial.proxad.net [62.147.220.84]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0FFFHli016711 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 15 Jan 2003 10:15:39 -0500 (EST) Message-ID: <3E257A6F.6020802@cs.columbia.edu> Date: Wed, 15 Jan 2003 10:12:47 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: "'Dean Willis'" , sip@ietf.org Subject: Re: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 References: <475FF955A05DD411980D00508B6D5FB00439EBAE@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >>Ah. Actually, that is the direction that I initially started >>taking things >>in the draft -- basically, I associated MIME content-types >>with usages, and >>didn't have the Info-Type. Then I briefly talked it over with >>Adam, and he >>talked me into the separate semantic indicator. >> >>I believe that the assertion that "most INFO types will have >>exactly one >>valid Content-Type" is the breaker. Let's look at text. Is >>the text I just >>sent you indicative of a move in the chess game we are playing? Is it >>something I want you to post on a web page for me? Should you >>just read it? >>Is it a javascript that you should use to remap your >>keyboard? Is it C code >>that you should compile and execute? Is it a credit card The mistake would be specifying all of them as text/plain. They should be specified as the correct media type to begin with. After all, I may want to save the content and saving a C file as .txt instead of .c is not very helpful. If this is application data, it should be labeled as application/chess. In addition, there is Content-Disposition to look at. >>number that you >>should debit for the price of this call? Why the heck AM I >>sending it to >>you? >> >>There are probably much better examples, but I think that a one-to-one >>mapping between content-type and expected function is more >>constraining than >>the way I think people are trying to use INFO, perhaps overly >>constraining. >> >>-- >>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 mailnull@www1.ietf.org Wed Jan 15 10:35:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00202 for ; Wed, 15 Jan 2003 10:35:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FFoTQ19306 for sip-archive@odin.ietf.org; Wed, 15 Jan 2003 10:50:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FFnuJ19249; Wed, 15 Jan 2003 10:49:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FFmaJ19179 for ; Wed, 15 Jan 2003 10:48:36 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00150 for ; Wed, 15 Jan 2003 10:33:23 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0FFaGK26792; Wed, 15 Jan 2003 10:36:17 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Jan 2003 10:36:16 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400E166@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Henning Schulzrinne'" , "Drage, Keith (Keith)" Cc: "'Dean Willis'" , sip@ietf.org Subject: RE: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 Date: Wed, 15 Jan 2003 10:36:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BCAB.D4EDF30E" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2BCAB.D4EDF30E Content-Type: text/plain I really agree with Henning's viewpoint. The mechanisms are already there. Quite frankly, I don't want to have to redo my SIP-T implementation of INFO unless a really good case can be made for it. > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, January 15, 2003 10:13 AM > To: Drage, Keith (Keith) > Cc: 'Dean Willis'; sip@ietf.org > Subject: Re: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 > > > > >>Ah. Actually, that is the direction that I initially started > >>taking things > >>in the draft -- basically, I associated MIME content-types > >>with usages, and > >>didn't have the Info-Type. Then I briefly talked it over with > >>Adam, and he > >>talked me into the separate semantic indicator. > >> > >>I believe that the assertion that "most INFO types will have > >>exactly one > >>valid Content-Type" is the breaker. Let's look at text. Is > >>the text I just > >>sent you indicative of a move in the chess game we are > playing? Is it > >>something I want you to post on a web page for me? Should you > >>just read it? > >>Is it a javascript that you should use to remap your > >>keyboard? Is it C code > >>that you should compile and execute? Is it a credit card > > The mistake would be specifying all of them as text/plain. > They should > be specified as the correct media type to begin with. After > all, I may > want to save the content and saving a C file as .txt instead of .c is > not very helpful. > > If this is application data, it should be labeled as > application/chess. > > In addition, there is Content-Disposition to look at. > > > >>number that you > >>should debit for the price of this call? Why the heck AM I > >>sending it to > >>you? > >> > >>There are probably much better examples, but I think that a > one-to-one > >>mapping between content-type and expected function is more > >>constraining than the way I think people are trying to use INFO, > >>perhaps overly constraining. > >> > >>-- > >>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 > ------_=_NextPart_001_01C2BCAB.D4EDF30E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sip] INFO Packaging -- = draft-willis-sip-infopackage-00

I really agree with Henning's viewpoint.  The = mechanisms are already there.  Quite frankly, I don't want to have = to redo my SIP-T implementation of INFO unless a really good case can = be made for it.

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] =
> Sent: Wednesday, January 15, 2003 10:13 = AM
> To: Drage, Keith (Keith)
> Cc: 'Dean Willis'; sip@ietf.org
> Subject: Re: [Sip] INFO Packaging -- = draft-willis-sip-infopackage-00
>
>
>
> >>Ah. Actually, that is the direction = that I initially started
> >>taking things
> >>in the draft -- basically, I associated = MIME content-types
> >>with usages, and
> >>didn't have the Info-Type. Then I = briefly talked it over with
> >>Adam, and he
> >>talked me into the separate semantic = indicator.
> >>
> >>I believe that the assertion that = "most INFO types will have
> >>exactly one
> >>valid Content-Type" is the = breaker. Let's look at text. Is
> >>the text I just
> >>sent you indicative of a move in the = chess game we are
> playing? Is it
> >>something I want you to post on a web = page for me? Should you
> >>just read it?
> >>Is it a javascript that you should use = to remap your
> >>keyboard? Is it C code
> >>that you should compile and execute? Is = it a credit card
>
> The mistake would be specifying all of them as = text/plain.
> They should
> be specified as the correct media type to begin = with. After
> all, I may
> want to save the content and saving a C file as = .txt instead of .c is
> not very helpful.
>
> If this is application data, it should be = labeled as
> application/chess.
>
> In addition, there is Content-Disposition to = look at.
>
>
> >>number that you
> >>should debit for the price of this = call? Why the heck AM I
> >>sending it to
> >>you?
> >>
> >>There are probably much better = examples, but I think that a
> one-to-one
> >>mapping between content-type and = expected function is more
> >>constraining than the way I think = people are trying to use INFO,
> >>perhaps overly constraining.
> >>
> >>--
> >>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
>

------_=_NextPart_001_01C2BCAB.D4EDF30E-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Jan 15 10:46:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00587 for ; Wed, 15 Jan 2003 10:46:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FG1Zc20017 for sip-archive@odin.ietf.org; Wed, 15 Jan 2003 11:01:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FG1DJ19995; Wed, 15 Jan 2003 11:01:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FG11J19928 for ; Wed, 15 Jan 2003 11:01:01 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00552 for ; Wed, 15 Jan 2003 10:45:47 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0FFmuYH001153; Wed, 15 Jan 2003 10:49:01 -0500 (EST) Message-ID: <3E249FB1.3060404@dynamicsoft.com> Date: Tue, 14 Jan 2003 18:39:29 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: "'Prasanna Venkatesh'" , joanne.higgens@orange.co.uk, sip@ietf.org Subject: Re: [Sip] SIP de-registration References: <002301c2b768$fdac1430$100112ac@txdwillis> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Catching up after a week of "real work": I have one bit to add to what Dean is saying. If a registrar should reject a request because, say, there is an "active session" and the policy of the registrar prohibits de-registration during an active session, you really must use an appropriate response code to have a hope of interop. The appropriate response is a 500 (not any 500 class). The reason is that the 500 can contain a Retry-After, informing the UA that it should try again later. Otherwise, when the registration is rejected, what should it do? Should it try again? When should it try again? If, however, the intent is that the registration is accepted, but will take affect later, that is something quite different, and would require some standardization activity to make interoperable. Of course, that said, I agree with Dean that the intention of REGISTER is merely to establish an address binding, and not to be a "log in" in the sense that it is frequently mis-interpreted. -Jonathan R. Dean Willis wrote: > Prasanna said: > >>Jo said: >> >>>Is it valid to reject a de-registration request? >>> >>>For example 'If a SIP terminal sends a de-registration >>>request to a network while it still has an active session >>>established, and the network rejects this request , is this >>>correct behaviour. >> > >>Any registrar can reject a de-registration request anytime. >>But rejecting a de-registration for the fact that a session >>is active is a local implementation. In general the >>registration is used to locate an entity and theoritically >>after the session is established, the registration is >>immaterial. Cheers, Prasanna > > > I believe Prasanna is correct here, in general. SIP does not view REGISTER > as a "log on for service" -- rather, it is an address binding function that > makes a temporary association between a (presumbaly temporary) local > instance address and a (presumbaly long-lived) address-of-record. In > particular, SIP does not require that a UA have a current registration or > execute a REGISTER transaction before executing an INVITE transaction > request. > > 3GPP (and consequently 3GPP2) have however layered some extra roles on top > of the SIP REGISTER transaction. In these environments, REGISTER is a sort > of "log on" operation in that it establishes the security association > between a client and registrar that will be used for (some) future > interactions between that client and registrar. > > Consequently, answering the question that Jo asked requires knowing whether > the 3GPP system discards the security association established by a REGISTER > request if the registration created by that request is destroyed. > > The answer, unfortunately, is "I don't know. The IETF doesn't know. Maybe > somebody more conversant with that particular bit of 3GPPP knows (and > they're probably reading this)." But in short, it is an environment specific > question related to a specific implementation having done something just a > bit different from generic SIP. In straight SIP, the registrar can terminate > a registration without impacting any sessions that a UA is participating in. > In fact, the registrar usually doesn't know or care whether a UA has or will > ever have participated in a session. > > My guess is that this would probably be implementation-depdendent in the > S-CSCF, and that if I were designing an S-CSCF, I'd have it not discard > SA-state until after all transacations on that SA had terminated. A second > choice would be to design it to use network-initiated-termination procedures > to force-terminate any sessions before discarding the security associations. > > -- > 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. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Jan 15 15:06:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08468 for ; Wed, 15 Jan 2003 15:06:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FKL4J06369 for sip-archive@odin.ietf.org; Wed, 15 Jan 2003 15:21:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FKKOJ06332; Wed, 15 Jan 2003 15:20:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FKHLJ06206 for ; Wed, 15 Jan 2003 15:17:21 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08242 for ; Wed, 15 Jan 2003 15:02:04 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h0FK5DTG018288; Wed, 15 Jan 2003 14:05:14 -0600 From: "Dean Willis" To: "'Henning Schulzrinne'" , "'Drage, Keith \(Keith\)'" Cc: Subject: RE: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 Date: Wed, 15 Jan 2003 14:04:59 -0600 Message-ID: <001401c2bcd1$62b3ea20$fe0c0c42@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <3E257A6F.6020802@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0FKHLJ06207 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > The mistake would be specifying all of them as text/plain. > They should > be specified as the correct media type to begin with. After > all, I may > want to save the content and saving a C file as .txt instead of .c is > not very helpful. > > If this is application data, it should be labeled as > application/chess. > > In addition, there is Content-Disposition to look at. Consider XML. Do we end up with a different MIME registration for every different XML schema? Or would we have to re-extend INFO to say "If the data you've gotten is XML, then you must parse the schema declaration to know which application reistered on this dialog gets the data?" -- 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 mailnull@www1.ietf.org Wed Jan 15 16:22:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10515 for ; Wed, 15 Jan 2003 16:22:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FLbie11443 for sip-archive@odin.ietf.org; Wed, 15 Jan 2003 16:37:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FLbIJ11232; Wed, 15 Jan 2003 16:37:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FLZoJ10686 for ; Wed, 15 Jan 2003 16:35:50 -0500 Received: from broadsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10468 for ; Wed, 15 Jan 2003 16:20:31 -0500 (EST) Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.12.6) id h0FLNsQm004066; Wed, 15 Jan 2003 16:23:54 -0500 (EST) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] Via maddr Date: Wed, 15 Jan 2003 16:25:37 -0500 Message-ID: <003601c2bcdc$a61d99e0$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: <3E2569B3.B26F4A6@lmf.ericsson.se> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > I appologise if this has been discussed > before, but at least I didn't find it in > my mail box (I admit I didn't check the > archieve on the web). I posted a related question to sip-implementors; however I never got a reply. http://lists.cs.columbia.edu/pipermail/sip-implementors/2002-October/004052. html > Chapter 18.2.2 in RFC3261 talks about the > routing of responses, using the Via maddr, > received and sent-by parameters. > > My question is regarding maddr. When reading > the text, I get the picture that only > IP addresses are used in maddr. At least the > text doesn't mention the SRV RFC, which it does > for sent-by, and it says that the default port > is 5060. However, the ABNF defines maddr as > "host", which can also be a domain name. maddr can be a domain name. The text appears to disable the ability to perform an SRV query associated with the Via maddr. However I never got an answer concerning if this was intentional. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Jan 15 16:27:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10605 for ; Wed, 15 Jan 2003 16:27:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FLgfT11676 for sip-archive@odin.ietf.org; Wed, 15 Jan 2003 16:42:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FLgKJ11665; Wed, 15 Jan 2003 16:42:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FLfLJ11620 for ; Wed, 15 Jan 2003 16:41:21 -0500 Received: from brazilnut.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10582 for ; Wed, 15 Jan 2003 16:26:02 -0500 (EST) Received: from cs.columbia.edu (APh-Aug-102-2-1-12.abo.wanadoo.fr [193.252.40.12]) (user=hgs10 mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0FLTLOE019831 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 15 Jan 2003 16:29:23 -0500 (EST) Message-ID: <3E25D21B.6020104@cs.columbia.edu> Date: Wed, 15 Jan 2003 16:26:51 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: "'Drage, Keith \(Keith\)'" , sip@ietf.org Subject: Re: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 References: <001401c2bcd1$62b3ea20$fe0c0c42@txdwillis> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Consider XML. Do we end up with a different MIME registration for every > different XML schema? Or would we have to re-extend INFO to say "If the data > you've gotten is XML, then you must parse the schema declaration to know > which application reistered on this dialog gets the data?" I thought we used things like application/xml+cpl for different schema? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Jan 15 18:25:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14450 for ; Wed, 15 Jan 2003 18:25:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FNeQa21490 for sip-archive@odin.ietf.org; Wed, 15 Jan 2003 18:40:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FNe1J21455; Wed, 15 Jan 2003 18:40:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FNcLJ21346 for ; Wed, 15 Jan 2003 18:38:21 -0500 Received: from dyn-tx-app-007.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14390 for ; Wed, 15 Jan 2003 18:23:01 -0500 (EST) Received: from TXADAM (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.12.5/8.12.5) with SMTP id h0FNPK9Z005345; Wed, 15 Jan 2003 17:25:41 -0600 Message-ID: <021d01c2bced$75d1ccf0$bd346b83@dynamicsoft.com> From: "Adam Roach" To: "Drage, Keith \(Keith\)" , "'Dean Willis'" , References: <475FF955A05DD411980D00508B6D5FB00439EBA5@en0033exch001u.uk.lucent.com> Subject: Re: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 Date: Wed, 15 Jan 2003 17:25:16 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Drage, Keith (Keith)" > I would note that the proposal invalidates existing usages > of the INFO method, as presumably all usages of INFO > carry the new header Info-Type and the dialog should > presumably be created carrying the Allow-Info header. Note well that we had a completely congruent situation with SIP events (PINT had already made it to RFC), and the solution was both straightforward and uncontroversial. Dean: you should probably add a section that's a cut, paste, and tiny edit from section 3.3.8 of RFC 3265. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Jan 15 18:31:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14592 for ; Wed, 15 Jan 2003 18:31:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FNkRJ21775 for sip-archive@odin.ietf.org; Wed, 15 Jan 2003 18:46:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FNkAJ21768; Wed, 15 Jan 2003 18:46:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FNjsJ21738 for ; Wed, 15 Jan 2003 18:45:54 -0500 Received: from dyn-tx-app-007.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14562 for ; Wed, 15 Jan 2003 18:30:33 -0500 (EST) Received: from TXADAM (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.12.5/8.12.5) with SMTP id h0FNWL9Z005378; Wed, 15 Jan 2003 17:32:42 -0600 Message-ID: <026601c2bcee$79c70680$bd346b83@dynamicsoft.com> From: "Adam Roach" To: "Henning Schulzrinne" , "Dean Willis" Cc: "'Christer Holmberg'" , References: <001f01c2bc06$d4609400$fe0c0c42@txdwillis> <3E24730B.2050707@cs.columbia.edu> Subject: Re: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 Date: Wed, 15 Jan 2003 17:32:17 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit From: "Henning Schulzrinne" > > No. We currently negotiate above-SIP content with Content-Type, > Content-Language and all the other Content-Headers, just like HTTP, SMTP > and other MIME users. If the body contains message/isup, it is an ISUP > message. It is not clear to me what value an additional, semi-orthogonal > negotiation mechanism offers. (Semi-orthogonal, since most INFO types > will have exactly one valid Content-Type.) Not so sure about this. To take your example, we already have proposals for application/isup and application/vnd.sentito.isup-text (or whatever draft-miller-sip-isup-annex-00 plans to propose). /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Jan 15 18:35:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14691 for ; Wed, 15 Jan 2003 18:35:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FNocs22018 for sip-archive@odin.ietf.org; Wed, 15 Jan 2003 18:50:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FNoFJ22004; Wed, 15 Jan 2003 18:50:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FNnhJ21951 for ; Wed, 15 Jan 2003 18:49:43 -0500 Received: from dyn-tx-app-007.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14655 for ; Wed, 15 Jan 2003 18:34:23 -0500 (EST) Received: from TXADAM (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.12.5/8.12.5) with SMTP id h0FNa69Z005401; Wed, 15 Jan 2003 17:36:27 -0600 Message-ID: <032601c2bcef$02c473f0$bd346b83@dynamicsoft.com> From: "Adam Roach" To: "Tom-PT Taylor" , "'Henning Schulzrinne'" , "Drage, Keith \(Keith\)" Cc: "'Dean Willis'" , References: <4D79C746863DD51197690002A52CDA000400E166@zcard0kc.ca.nortel.com> Subject: Re: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 Date: Wed, 15 Jan 2003 17:36:02 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit RE: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 You don't have to re-do it, as long as we grandfather its usage like we did with PINT in RFC 3265. /a ----- Original Message ----- From: Tom-PT Taylor To: 'Henning Schulzrinne' ; Drage, Keith (Keith) Cc: 'Dean Willis' ; sip@ietf.org Sent: Wednesday, January 15, 2003 9:36 Subject: RE: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 I really agree with Henning's viewpoint. The mechanisms are already there. Quite frankly, I don't want to have to redo my SIP-T implementation of INFO unless a really good case can be made for it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Jan 15 19:02:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15312 for ; Wed, 15 Jan 2003 19:02:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0G0Hdf23936 for sip-archive@odin.ietf.org; Wed, 15 Jan 2003 19:17:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G0HHJ23928; Wed, 15 Jan 2003 19:17:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G0G7J23894 for ; Wed, 15 Jan 2003 19:16:07 -0500 Received: from dyn-tx-app-007.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15251 for ; Wed, 15 Jan 2003 19:00:46 -0500 (EST) Received: from TXADAM (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.12.5/8.12.5) with SMTP id h0G02T9Z005509; Wed, 15 Jan 2003 18:02:49 -0600 Message-ID: <047801c2bcf2$aecc0930$bd346b83@dynamicsoft.com> From: "Adam Roach" To: "Henning Schulzrinne" , "Dean Willis" Cc: "'Christer Holmberg'" , References: <001f01c2bc06$d4609400$fe0c0c42@txdwillis> <3E24730B.2050707@cs.columbia.edu> Subject: Re: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 Date: Wed, 15 Jan 2003 18:02:25 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit "Henning Schulzrinne" writes: > We currently negotiate above-SIP content with Content-Type, > Content-Language and all the other Content-Headers, just like HTTP, SMTP > and other MIME users. If the body contains message/isup, it is an ISUP > message. It is not clear to me what value an additional, semi-orthogonal > negotiation mechanism offers. Upon further reflection, I realise that my previous response addressed the wrong half of this objection (multiple content types per application, instead of multiple applications per content type). Take, for example, the content type of "image/jpeg". It is quite conceivable that someone might define an INFO package of "app-icon" that uses "image/jpeg" to send a 32x32 pixel image that should be used as the icon for the application for the duration of the session. It is also completely beleivable that someone else might define an INFO package of "set-pointer" that uses "image/jpeg" to send a 16x16 bitmap that is to be used as the mouse pointer when said pointer is in the window associated with the application. Now, I'm not advocating these usages of INFO or even the ability to do either of these things with SIP, but I'm certain that you will agree that these are the *sort* of content-type collisions that you will encounter if you don't have the orthagonal mechanism that Dean includes in his draft. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Jan 15 20:47:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17590 for ; Wed, 15 Jan 2003 20:47:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0G22ps31489 for sip-archive@odin.ietf.org; Wed, 15 Jan 2003 21:02:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G22MJ31480; Wed, 15 Jan 2003 21:02:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G20KJ31389 for ; Wed, 15 Jan 2003 21:00:20 -0500 Received: from imr1.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17539 for ; Wed, 15 Jan 2003 20:44:55 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id h0G1mHd23787 for ; Wed, 15 Jan 2003 19:48:17 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h0G1mGH13870 for ; Wed, 15 Jan 2003 19:48:16 -0600 (CST) Received: from eammlex033.lmc.ericsson.se (eammlex033.lmc.ericsson.se [142.133.1.133]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id h0G1mGh20430 for ; Wed, 15 Jan 2003 20:48:16 -0500 (EST) Received: by eammlex033.lmc.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 15 Jan 2003 20:49:28 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C037C20@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: sip@ietf.org Date: Wed, 15 Jan 2003 20:48:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BD01.52A0C4C0" Subject: [Sip] Comments RFC 3329 Security Mechanism Agreement for SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This 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_01C2BD01.52A0C4C0 Content-Type: text/plain; charset="ISO-8859-1" Hi Gonzalo & company, Some comments on RFC 3329: * Section 2.4 Security mechanisms: You dont specify the behavior w.r.to a proxy when it comes to headers such as Security-Client. You only specify the proxy behavior towards the Require and Proxy-Require headers. Also, what should the proxy do to a Supported header if it is present * Section 2.3.2 Server initiated : It is stated: "A server that by policy requires the use of this specification and receives a request that does not have the sec-agree option tag in a Require, Proxy-Require or Supported header field MUST return a 421 (Extension Required) response" I read the text that it mandates the presence of the 3 headers for the server to accept the request. Is that the case? If the answer is yes, then I dont see that it is mandated in the RFC that the client MUST include Supported header. The strength used for the client w.r.to Supported header is SHOULD. If the answer is no, then please clarify the text to eliminate any ambinguity. * Section 2.6 The table indicates that a proxy can add a Security-Client, and a Security-Verify. This looks like an error. Also, I beleive that 421, 494 response can add a Security-Server. Please verify the table Rgds/gf ------_=_NextPart_001_01C2BD01.52A0C4C0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Comments RFC 3329 Security Mechanism Agreement for SIP

Hi Gonzalo & company,
Some comments on RFC 3329:

  • Section 2.4 Security = mechanisms:

You dont specify the behavior w.r.to a = proxy when it comes to headers such as Security-Client. You only = specify the proxy behavior towards the Require and Proxy-Require = headers.

Also,  what should the proxy do = to a Supported header if it is present

  • Section 2.3.2 Server initiated = :

It is stated:
"A server that by policy = requires the use of this specification and receives a request that does = not have the sec-agree option tag in a Require, Proxy-Require or = Supported header field MUST return a 421 (Extension Required) = response"

I read the text that it mandates the = presence of the 3 headers for the server to accept the request.
Is that the case?
If the answer is yes, then I dont = see that it is mandated in the RFC that the client MUST include = Supported header. The strength used for the client w.r.to Supported = header is SHOULD.

If the answer is no, then please = clarify the text to eliminate any ambinguity.

  • Section 2.6

The table indicates that a proxy can = add a Security-Client, and a Security-Verify. This looks like an = error.
Also, I beleive that 421, 494 = response can add a Security-Server.
Please verify the table
Rgds/gf




 


------_=_NextPart_001_01C2BD01.52A0C4C0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 16 03:43:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04862 for ; Thu, 16 Jan 2003 03:43:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0G8wrx01947 for sip-archive@odin.ietf.org; Thu, 16 Jan 2003 03:58:53 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G8tKJ01679; Thu, 16 Jan 2003 03:55:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G8oeJ01482 for ; Thu, 16 Jan 2003 03:50:40 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04725 for ; Thu, 16 Jan 2003 03:35:08 -0500 (EST) Received: from cs.columbia.edu (APh-Aug-102-2-1-12.abo.wanadoo.fr [193.252.40.12]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0G8cMG8019869 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 16 Jan 2003 03:38:27 -0500 (EST) Message-ID: <3E266EE8.5050401@cs.columbia.edu> Date: Thu, 16 Jan 2003 03:35:52 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: Dean Willis , "'Christer Holmberg'" , sip@ietf.org Subject: Re: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 References: <001f01c2bc06$d4609400$fe0c0c42@txdwillis> <3E24730B.2050707@cs.columbia.edu> <047801c2bcf2$aecc0930$bd346b83@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Consider the interaction with Content-Disposition. Adam Roach wrote: > "Henning Schulzrinne" writes: > > >>We currently negotiate above-SIP content with Content-Type, >>Content-Language and all the other Content-Headers, just like HTTP, SMTP >>and other MIME users. If the body contains message/isup, it is an ISUP >>message. It is not clear to me what value an additional, semi-orthogonal >>negotiation mechanism offers. > > > Upon further reflection, I realise that my previous response addressed > the wrong half of this objection (multiple content types per application, > instead of multiple applications per content type). > > Take, for example, the content type of "image/jpeg". > > It is quite conceivable that someone might define an INFO > package of "app-icon" that uses "image/jpeg" to send > a 32x32 pixel image that should be used as the icon for the > application for the duration of the session. > > It is also completely beleivable that someone else might > define an INFO package of "set-pointer" that uses "image/jpeg" > to send a 16x16 bitmap that is to be used as the mouse pointer > when said pointer is in the window associated with the > application. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 16 07:43:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08388 for ; Thu, 16 Jan 2003 07:43:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GCwKF18091 for sip-archive@odin.ietf.org; Thu, 16 Jan 2003 07:58:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GCshJ17937; Thu, 16 Jan 2003 07:54:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GCqvJ17860 for ; Thu, 16 Jan 2003 07:52:57 -0500 Received: from fmis401r.omnitel.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08314 for ; Thu, 16 Jan 2003 07:37:20 -0500 (EST) From: loretosa@vizzavi.it Received: from fmis440.omnitel.it by fmis401r.omnitel.it via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 16 Jan 2003 12:40:42 UT Received: (private information removed) Received: (private information removed) Content-Class: urn:content-classes:message To: , , Date: Thu, 16 Jan 2003 13:36:28 +0100 Message-ID: <613601c2bd5b$e41a5600$5dde010a@omnitel.it> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft CDO for Windows 2000 Thread-Index: AcK9W+QaIKTBPENZQDaLvnJrhN84Zg== X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] Extension to Assure Congestion Safety Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi are there news about the Congestion problem ? I read some weeks ago that work is frozen. But your draft expires at the end of January. Will be some change in new release? If it will be resubmitted. About the change with TCP as Transport Protocol default, someone can tell me some news? Sal _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 16 10:08:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13325 for ; Thu, 16 Jan 2003 10:08:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GFO3r29543 for sip-archive@odin.ietf.org; Thu, 16 Jan 2003 10:24:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFKGJ29297; Thu, 16 Jan 2003 10:20:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFIWJ29177 for ; Thu, 16 Jan 2003 10:18:32 -0500 Received: from face.sentitonetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13104 for ; Thu, 16 Jan 2003 10:02:51 -0500 (EST) Received: (qmail 40698 invoked from network); 16 Jan 2003 15:06:13 -0000 Received: from unknown (HELO overhill) (10.0.0.159) by face.sentito.com with SMTP; 16 Jan 2003 15:06:13 -0000 Message-ID: <005401c2bd70$ce1bcb30$9f00000a@overhill> From: "Frank W. Miller" To: Cc: References: <65256CB0.004BD998.00@sampark.hss.hns.com> Date: Thu, 16 Jan 2003 10:06:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Comments: I-D ACTION:draft-miller-sip-tcap-00.txt : Reposting Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit My apologies, I missed this one... The difference here is that TCAP binary messages do not traverse the IP portion of the network. The impetus is similar to that for translating the ISUP maintenance commands, SS7 stacks cost a lot (both $$ and point codes). It makes more sense to implement a simple text representation that traverses the IP portion of the network and is converted to binary TCAP at the gateway to the SS7 cloud. Also, from a philosophical point of view, since I believe that SIP will supplant SS7 over the long run, limiting the need to implement SS7 in new network elements is "a good thing". This last point is of course, just MHO. FM Frank W. Miller, Ph.D. Chief Technical Officer sentitO Network, Inc. fmiller@sentito.com ----- Original Message ----- From: To: Cc: Sent: Thursday, January 16, 2003 8:48 AM Subject: Comments: I-D ACTION:draft-miller-sip-tcap-00.txt : Reposting > > > Reposting this mail as it did not receive a response on the list the first > time. > > > > > > hbhondwe@hss.hns.com on 01/10/2003 11:13:02 AM > > To: sipping@ietf.org > cc: (bcc: Harsh Bhondwe/HSSBLR) > > Subject: [Sipping] Comments: I-D ACTION:draft-miller-sip-tcap-00.txt > > > > > > > Hi , > > I have a fundamental question on the the usage of SIP for > transporting TCAP messages. > > If I understand correctly the figure 1 in the draft, is > something like the following: > > > SIP Element Signaling Gateway SS7 Node > > TCAP applications PSTN Services > TCAP TCAP > SIP--------IP----------SIP||SS7--------SS7------SS7 > > > Here a TCAP peer will be running on the SIP Element and will > use SIP to exchange TCAP messages with peers(i.e other TCAPs) > in the PSTN network. > > However, SIGTRAN protocols defined also by the SIGTRAN > Working group of the IETF have been especially designed > for transporting Trunk/Access signaling over IP. > > So, could one not better accomplish this by the > following configuration using SIGTRAN? > > > SIP Element Signaling Gateway PSTN Node > > TCAP applications PSTN Services > TCAP TCAP > SIGTRAN---------IP-------------SIGTRAN||SS7 ---SS7-----SS7 > (SUA over SCTP) (SUA over SCTP) > > > The difference of course is that in this case the SIP > Element and the Signaling Gateway will have to (also) > support SIGTRAN.They could continue to support SIP as well. > > Or am i missing something? > > thanks > harsh > > > > > > _______________________________________________ > 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 mailnull@www1.ietf.org Thu Jan 16 11:27:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15326 for ; Thu, 16 Jan 2003 11:27:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GGh2G03353 for sip-archive@odin.ietf.org; Thu, 16 Jan 2003 11:43:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GGgUJ03315; Thu, 16 Jan 2003 11:42:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GGcVJ03056 for ; Thu, 16 Jan 2003 11:38:31 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15150 for ; Thu, 16 Jan 2003 11:22:48 -0500 (EST) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h0GGQ5TF027376; Thu, 16 Jan 2003 10:26:05 -0600 Received: (from dwillis@localhost) by bdsl.greycouncil.com (8.12.5/8.12.5/Submit) id h0GGQ5NS027374; Thu, 16 Jan 2003 10:26:05 -0600 X-Authentication-Warning: bdsl.greycouncil.com: dwillis set sender to dean.willis@softarmor.com using -f Subject: Re: [Sip] Extension to Assure Congestion Safety From: Dean Willis To: loretosa@vizzavi.it Cc: bcampbell@dynamicsoft.com, sip@ietf.org In-Reply-To: <613601c2bd5b$e41a5600$5dde010a@omnitel.it> References: <613601c2bd5b$e41a5600$5dde010a@omnitel.it> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1042734364.27238.14.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 16 Jan 2003 10:26:04 -0600 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thu, 2003-01-16 at 06:36, loretosa@vizzavi.it wrote: > Hi > > are there news about the Congestion problem ? > I read some weeks ago that work is frozen. > But your draft expires at the end of January. > Will be some change in new release? If it will be resubmitted. > > About the change with TCP as Transport Protocol default, > someone can tell me some news? > Thanks, Sal. Actually, we haven't talked much about this lately, and we probably should. When conversation last stopped, we had just realized that although we could use this sort of mechanism in the forward direction, it doesn't do anything about the reverse direction. So, let's say somebody S/MIME signs a 200 OK, making it perhaps 4KB in size (That doesn't necessarily happen, but it MIGHT if they include their cert). Since this is a response, it MUST follow the path laid out in the Via header field, even if this takes it across non-congestion safe UDP links. Is this a problem that we should worry about? If so, can we address it short of jut deprecating UDP? One approach that came up is essentially tagging the Via values so that we know which are congestion safe. Under this approach, the receiving UA would be able to recognize that the large response it is generating could not be returned safely. What should it do then? Could such a mechanism be made backward compatible? How much additional triggerwork are we willing to put into the protocol just to continue accommodating UDP? I know a number of people believe that a lot of the complexity of SIP stems from its concurrent support for UDP and TCP, and that we'd be better off just ripping the UDP out and consequently greatly simplifying the state machines than adding more complexity to the core protocol. So, we don't really have a group consensus about where to go with this, and we need one. Ladies, gentleman, and those to whom these terms are irrelevant, the floor is open for discussion. -- 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 mailnull@www1.ietf.org Fri Jan 17 06:54:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18696 for ; Fri, 17 Jan 2003 06:54:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HCAWm24819 for sip-archive@odin.ietf.org; Fri, 17 Jan 2003 07:10:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HC9wJ24796; Fri, 17 Jan 2003 07:09:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HC7jJ24674 for ; Fri, 17 Jan 2003 07:07:45 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18614 for ; Fri, 17 Jan 2003 06:51:41 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0HBt1KV001919; Fri, 17 Jan 2003 12:55:01 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZQ1HJGYX; Fri, 17 Jan 2003 12:55:00 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.40]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h0HBt1TM012954; Fri, 17 Jan 2003 13:55:01 +0200 (EET) Message-ID: <3E27EF16.B7312454@lmf.ericsson.se> Date: Fri, 17 Jan 2003 13:55:03 +0200 X-Sybari-Trust: b70aaed6 9ffcebbb 6f685166 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org CC: antti.vaha-sipila@nokia.com, schulzrinne@cs.columbia.edu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] TEL-URL local numbers Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, When reading the latest (-07) of the 2806bis draft, I see that the "+" prefix is mandatory for both global- and local numbers. I assume this means that if a SIP-URI has the user=phone parameter set, the userpart is not valid unless there is a "+" prefix (since RFC3261 says the userpart shall be parsed as a TEL-URL telephone-uri in this case)? The reason I am confused about this because in the examples (chapter 6) in 2806bis there is no "+" sign in front of the local numbers. Is this a leftover from previous versions, when there were no "+" in front of local numbers, or is there a bug in the ABNF? I also wonder why there has to be a "+" sign in front of a local number in the first place? When reading chapter 5.1.3 and 5.1.4 I find nowhere an explanation for this (5.1.3 even says that global numbers are identified by the "+" prefix). Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 17 07:32:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19737 for ; Fri, 17 Jan 2003 07:32:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HClfW26850 for sip-archive@odin.ietf.org; Fri, 17 Jan 2003 07:47:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HClKJ26833; Fri, 17 Jan 2003 07:47:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HCkuJ26797 for ; Fri, 17 Jan 2003 07:46:56 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19674 for ; Fri, 17 Jan 2003 07:30:50 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 18ZVh3-0007PA-00; Fri, 17 Jan 2003 14:33:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15911.63537.627963.460641@harjus.eng.song.fi> Date: Fri, 17 Jan 2003 14:33:53 +0200 To: Christer Holmberg Cc: sip@ietf.org, antti.vaha-sipila@nokia.com, schulzrinne@cs.columbia.edu Subject: [Sip] TEL-URL local numbers In-Reply-To: <3E27EF16.B7312454@lmf.ericsson.se> References: <3E27EF16.B7312454@lmf.ericsson.se> X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit looks to me that the syntax has a bug, i.e., local numbers don't need start with +. i have another question. why is context mandatory in local numbers? i would like to make it optional and if it is missing, the context would be derived from the from uri. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 17 07:46:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20637 for ; Fri, 17 Jan 2003 07:46:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HD24J27802 for sip-archive@odin.ietf.org; Fri, 17 Jan 2003 08:02:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HD1eJ27746; Fri, 17 Jan 2003 08:01:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HD0lJ27669 for ; Fri, 17 Jan 2003 08:00:47 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20455 for ; Fri, 17 Jan 2003 07:44:40 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0HCm0Av007205; Fri, 17 Jan 2003 13:48:00 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNNLWS2; Fri, 17 Jan 2003 13:47:59 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.40]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h0HClxTM016286; Fri, 17 Jan 2003 14:47:59 +0200 (EET) Message-ID: <3E27FB81.2465A12E@lmf.ericsson.se> Date: Fri, 17 Jan 2003 14:48:01 +0200 X-Sybari-Trust: 05185277 9ffcebbb 6f685166 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: jh@lohi.eng.song.fi CC: sip@ietf.org, antti.vaha-sipila@nokia.com, schulzrinne@cs.columbia.edu Subject: Re: [Sip] TEL-URL local numbers References: <3E27EF16.B7312454@lmf.ericsson.se> <15911.63537.627963.460641@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, > looks to me that the syntax has a bug, i.e., local numbers don't need > start with +. Local numbers MUST NOT start with "+", I'd say. I also wonder a little about the syntax for local numbers: local-number = local-number-digits *par context *par I wonder why context is "surrounded" by optional pars. I guess there is nothing wrong with it from an ABNF point of view, but wouldn't it look better to have the opional pars either before or after the context? That is how it used to be, so I wonder what the reason for changing this is? > i have another question. why is context mandatory in local numbers? i > would like to make it optional and if it is missing, the context would > be derived from the from uri. I was going to ask the same, but forgot, so good that you brought it up :) In previous versions of the draft the context is optional, so I also wonder what the reason for making it mandatory is? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 17 08:06:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21239 for ; Fri, 17 Jan 2003 08:06:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HDLeB29532 for sip-archive@odin.ietf.org; Fri, 17 Jan 2003 08:21:40 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HDLDJ29513; Fri, 17 Jan 2003 08:21:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HDJqJ29377 for ; Fri, 17 Jan 2003 08:19:52 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21107; Fri, 17 Jan 2003 08:03:46 -0500 (EST) Received: from cs.columbia.edu (APh-Aug-102-2-1-12.abo.wanadoo.fr [193.252.40.12]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0HD756V016195 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 17 Jan 2003 08:07:07 -0500 (EST) Message-ID: <3E27FF63.4030601@cs.columbia.edu> Date: Fri, 17 Jan 2003 08:04:35 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jh@lohi.eng.song.fi CC: Christer Holmberg , sip@ietf.org, antti.vaha-sipila@nokia.com, iptel@ietf.org Subject: Re: [Sip] TEL-URL local numbers References: <3E27EF16.B7312454@lmf.ericsson.se> <15911.63537.627963.460641@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit [This discussion should be on iptel, not sip.] Yes, it's a bug which crept in due to other revisions. It will be fixed in 08. jh@lohi.eng.song.fi wrote: > looks to me that the syntax has a bug, i.e., local numbers don't need > start with +. > > i have another question. why is context mandatory in local numbers? i > would like to make it optional and if it is missing, the context would > be derived from the from uri. How would it be uniquely and unambiguously derived? > > -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 17 08:12:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21451 for ; Fri, 17 Jan 2003 08:12:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HDSSB30048 for sip-archive@odin.ietf.org; Fri, 17 Jan 2003 08:28:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HDSBJ30007; Fri, 17 Jan 2003 08:28:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HDRAJ29929 for ; Fri, 17 Jan 2003 08:27:10 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21391; Fri, 17 Jan 2003 08:11:03 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 18ZWKG-0007Sq-00; Fri, 17 Jan 2003 15:14:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15912.432.180748.674189@harjus.eng.song.fi> Date: Fri, 17 Jan 2003 15:14:24 +0200 To: Henning Schulzrinne Cc: Christer Holmberg , sip@ietf.org, antti.vaha-sipila@nokia.com, iptel@ietf.org Subject: Re: [Sip] TEL-URL local numbers In-Reply-To: <3E27FF63.4030601@cs.columbia.edu> References: <3E27EF16.B7312454@lmf.ericsson.se> <15911.63537.627963.460641@harjus.eng.song.fi> <3E27FF63.4030601@cs.columbia.edu> X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Henning Schulzrinne writes: > > i have another question. why is context mandatory in local numbers? i > > would like to make it optional and if it is missing, the context would > > be derived from the from uri. > > How would it be uniquely and unambiguously derived? if my from uri is +358-3-1234567 and i make a call to 03-2345678, the user agent or proxy could figure out that the missing country code is +358. this is normal dial plan stuff. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 17 08:17:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21562 for ; Fri, 17 Jan 2003 08:17:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HDWZC30491 for sip-archive@odin.ietf.org; Fri, 17 Jan 2003 08:32:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HDWGJ30453; Fri, 17 Jan 2003 08:32:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HDVGJ30282 for ; Fri, 17 Jan 2003 08:31:16 -0500 Received: from brazilnut.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21502; Fri, 17 Jan 2003 08:15:09 -0500 (EST) Received: from cs.columbia.edu (APh-Aug-102-2-1-12.abo.wanadoo.fr [193.252.40.12]) (user=hgs10 mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0HDIS9Q007269 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 17 Jan 2003 08:18:30 -0500 (EST) Message-ID: <3E28020E.4080805@cs.columbia.edu> Date: Fri, 17 Jan 2003 08:15:58 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jh@lohi.eng.song.fi CC: Christer Holmberg , sip@ietf.org, antti.vaha-sipila@nokia.com, iptel@ietf.org Subject: Re: [Sip] TEL-URL local numbers References: <3E27EF16.B7312454@lmf.ericsson.se> <15911.63537.627963.460641@harjus.eng.song.fi> <3E27FF63.4030601@cs.columbia.edu> <15912.432.180748.674189@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > if my from uri is +358-3-1234567 and i make a call to 03-2345678, the > user agent or proxy could figure out that the missing country code is > +358. this is normal dial plan stuff. tel URIs, as has been discussed a few times, do no incorporate dial plans. They are *generated* by dial plans. > > -- juha > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 17 08:22:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21637 for ; Fri, 17 Jan 2003 08:22:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HDbga31374 for sip-archive@odin.ietf.org; Fri, 17 Jan 2003 08:37:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HDbJJ31147; Fri, 17 Jan 2003 08:37:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HDaMJ30641 for ; Fri, 17 Jan 2003 08:36:22 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21604; Fri, 17 Jan 2003 08:20:14 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 18ZWTA-0007Tj-00; Fri, 17 Jan 2003 15:23:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15912.984.540036.277317@harjus.eng.song.fi> Date: Fri, 17 Jan 2003 15:23:36 +0200 To: Henning Schulzrinne Cc: Christer Holmberg , sip@ietf.org, antti.vaha-sipila@nokia.com, iptel@ietf.org Subject: Re: [Sip] TEL-URL local numbers In-Reply-To: <3E28020E.4080805@cs.columbia.edu> References: <3E27EF16.B7312454@lmf.ericsson.se> <15911.63537.627963.460641@harjus.eng.song.fi> <3E27FF63.4030601@cs.columbia.edu> <15912.432.180748.674189@harjus.eng.song.fi> <3E28020E.4080805@cs.columbia.edu> X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Henning Schulzrinne writes: > > if my from uri is +358-3-1234567 and i make a call to 03-2345678, the > > user agent or proxy could figure out that the missing country code is > > +358. this is normal dial plan stuff. > > tel URIs, as has been discussed a few times, do no incorporate dial > plans. They are *generated* by dial plans. if the tel uri must be always fully qualified then the ua must have a dial plan and generate the fully qualified tel uri. in some cases it would be easier to let the proxy to run the dial plan code on the message and fully qualify the tel uri. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 17 08:26:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21753 for ; Fri, 17 Jan 2003 08:26:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HDfkU31593 for sip-archive@odin.ietf.org; Fri, 17 Jan 2003 08:41:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HDfRJ31579; Fri, 17 Jan 2003 08:41:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HDeuJ31512 for ; Fri, 17 Jan 2003 08:40:56 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21713; Fri, 17 Jan 2003 08:24:48 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0HDS3Av020473; Fri, 17 Jan 2003 14:28:03 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNBVMPS; Fri, 17 Jan 2003 14:28:03 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.40]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h0HDS3TM018608; Fri, 17 Jan 2003 15:28:04 +0200 (EET) Message-ID: <3E2804E5.5ED969EF@lmf.ericsson.se> Date: Fri, 17 Jan 2003 15:28:05 +0200 X-Sybari-Trust: 40ac1e8a 9ffcebbb 6f685166 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: jh@lohi.eng.song.fi CC: Henning Schulzrinne , sip@ietf.org, antti.vaha-sipila@nokia.com, iptel@ietf.org Subject: Re: [Sip] TEL-URL local numbers References: <3E27EF16.B7312454@lmf.ericsson.se> <15911.63537.627963.460641@harjus.eng.song.fi> <3E27FF63.4030601@cs.columbia.edu> <15912.432.180748.674189@harjus.eng.song.fi> <3E28020E.4080805@cs.columbia.edu> <15912.984.540036.277317@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, > >>if my from uri is +358-3-1234567 and i make a call to 03-2345678, the > >>user agent or proxy could figure out that the missing country code is > >>+358. this is normal dial plan stuff. > > > >tel URIs, as has been discussed a few times, do no incorporate dial > >plans. They are *generated* by dial plans. > > if the tel uri must be always fully qualified then the ua must have a > dial plan and generate the fully qualified tel uri. in some cases it > would be easier to let the proxy to run the dial plan code on the > message and fully qualify the tel uri. I agree with Juha. I don't think we have any requirements on having dial plans in the SIP phones, do we? I know there is a discussion ongoing about it, but still... Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 17 08:26:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21805 for ; Fri, 17 Jan 2003 08:26:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HDgYM31654 for sip-archive@odin.ietf.org; Fri, 17 Jan 2003 08:42:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HDgAJ31627; Fri, 17 Jan 2003 08:42:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HDfhJ31587 for ; Fri, 17 Jan 2003 08:41:43 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21744 for ; Fri, 17 Jan 2003 08:25:36 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 18ZWYM-0007U5-00 for ; Fri, 17 Jan 2003 15:28:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15912.1306.421750.967768@harjus.eng.song.fi> Date: Fri, 17 Jan 2003 15:28:58 +0200 To: sip@ietf.org X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Subject: [Sip] any restrictions on characters in user part of sip uri? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit the syntax of user part of sip uri is: user = 1*( unreserved / escaped / user-unreserved ) user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" escaped is %hexhex and can thus be used to include any character in user. is it really so that there is no restrictions on what chars may be include in user using escaped? for example, is %0000 valid in user? if so, it makes implementations "interesting". -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 17 08:55:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22474 for ; Fri, 17 Jan 2003 08:55:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HEAiJ01402 for sip-archive@odin.ietf.org; Fri, 17 Jan 2003 09:10:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HEAMJ01383; Fri, 17 Jan 2003 09:10:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HE9bJ01312 for ; Fri, 17 Jan 2003 09:09:37 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22414 for ; Fri, 17 Jan 2003 08:53:28 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP for sip@ietf.org; Fri, 17 Jan 2003 14:41:11 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Jan 2003 14:41:10 +0100 Message-Id: <53CD1252F68ED61183F5000347AE5F550120425E@G8PPZ.blf01.telekom.de> From: "Poetzl, Joachim" To: sip@ietf.org Subject: AW: [Sip] Re: Comments: I-D ACTION:draft-miller-sip-tcap-00.txt : Reposting Date: Fri, 17 Jan 2003 14:41:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0HE9bJ01313 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, by seeking a solution for a technical problem we should not consider philosophical approaches. For the transport of SS7-signalling information the SIGTRAN protocols have been especially defined by the SIGTRAN working group of the IETF. In this scenario SUA over SCTP could transport the TCAP information. For the time being PSTNs still exist and in converged scenarios we should use the same straight forward approach defined by the SIGTRAN group for each SS7 user part - why special treatment for TCAP???. Why defining another approach when everythhing neccesary is already defined. Or are there doubts about the maturity in the SIGTRAN protocols? You won´t need additional point codes and even the textbased TCAP-Endpoint in the IP cloud will cost some bucks. Some questions on the proposed solution: -- How is adressing beeing resolved? -- TCAP dialoges are mainly used for call unrelated signalling, means no dialog exists. But one has to have an open SIP-Dialog before exchanging Info-Messages. How is that going to be resolved? -- For what kind of services this should be used? Is this solution anticipated for call completion services instead of usage of subscribe/notify? Thanks Joachim -----Ursprüngliche Nachricht----- Von: Frank W. Miller [mailto:fmiller@sentito.com] Gesendet: Donnerstag, 16. Januar 2003 16:06 An: hbhondwe@hss.hns.com Cc: sip@ietf.org Betreff: [Sip] Re: Comments: I-D ACTION:draft-miller-sip-tcap-00.txt : Reposting My apologies, I missed this one... The difference here is that TCAP binary messages do not traverse the IP portion of the network. The impetus is similar to that for translating the ISUP maintenance commands, SS7 stacks cost a lot (both $$ and point codes). It makes more sense to implement a simple text representation that traverses the IP portion of the network and is converted to binary TCAP at the gateway to the SS7 cloud. Also, from a philosophical point of view, since I believe that SIP will supplant SS7 over the long run, limiting the need to implement SS7 in new network elements is "a good thing". This last point is of course, just MHO. FM Frank W. Miller, Ph.D. Chief Technical Officer sentitO Network, Inc. fmiller@sentito.com ----- Original Message ----- From: To: Cc: Sent: Thursday, January 16, 2003 8:48 AM Subject: Comments: I-D ACTION:draft-miller-sip-tcap-00.txt : Reposting > > > Reposting this mail as it did not receive a response on the list the first > time. > > > > > > hbhondwe@hss.hns.com on 01/10/2003 11:13:02 AM > > To: sipping@ietf.org > cc: (bcc: Harsh Bhondwe/HSSBLR) > > Subject: [Sipping] Comments: I-D ACTION:draft-miller-sip-tcap-00.txt > > > > > > > Hi , > > I have a fundamental question on the the usage of SIP for > transporting TCAP messages. > > If I understand correctly the figure 1 in the draft, is > something like the following: > > > SIP Element Signaling Gateway SS7 Node > > TCAP applications PSTN Services > TCAP TCAP > SIP--------IP----------SIP||SS7--------SS7------SS7 > > > Here a TCAP peer will be running on the SIP Element and will > use SIP to exchange TCAP messages with peers(i.e other TCAPs) > in the PSTN network. > > However, SIGTRAN protocols defined also by the SIGTRAN > Working group of the IETF have been especially designed > for transporting Trunk/Access signaling over IP. > > So, could one not better accomplish this by the > following configuration using SIGTRAN? > > > SIP Element Signaling Gateway PSTN Node > > TCAP applications PSTN Services > TCAP TCAP > SIGTRAN---------IP-------------SIGTRAN||SS7 ---SS7-----SS7 > (SUA over SCTP) (SUA over SCTP) > > > The difference of course is that in this case the SIP > Element and the Signaling Gateway will have to (also) > support SIGTRAN.They could continue to support SIP as well. > > Or am i missing something? > > thanks > harsh > > > > > > _______________________________________________ > 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 mailnull@www1.ietf.org Fri Jan 17 10:09:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25048 for ; Fri, 17 Jan 2003 10:09:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HFP9M06839 for sip-archive@odin.ietf.org; Fri, 17 Jan 2003 10:25:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HFOaJ06699; Fri, 17 Jan 2003 10:24:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HFLmJ06498 for ; Fri, 17 Jan 2003 10:21:48 -0500 Received: from face.sentitonetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24717 for ; Fri, 17 Jan 2003 10:05:38 -0500 (EST) Received: (qmail 63680 invoked from network); 17 Jan 2003 15:09:01 -0000 Received: from unknown (HELO overhill) (10.0.0.159) by face.sentito.com with SMTP; 17 Jan 2003 15:09:01 -0000 Message-ID: <002201c2be3a$5cef9160$9f00000a@overhill> From: "Frank W. Miller" To: "Poetzl, Joachim" Cc: References: <53CD1252F68ED61183F5000347AE5F550120425E@G8PPZ.blf01.telekom.de> Subject: Re: [Sip] Re: Comments: I-D ACTION:draft-miller-sip-tcap-00.txt : Reposting Date: Fri, 17 Jan 2003 10:08:59 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thanks for the questions! Comments inline. > For the transport of SS7-signalling information the SIGTRAN protocols have been especially defined by the SIGTRAN > working group of the IETF. In this scenario SUA over SCTP could transport the TCAP information. For the time being PSTNs still exist and in converged scenarios we should use the same straight forward approach defined by the SIGTRAN group for each SS7 user part - why special treatment for TCAP???. > We have a similar mechanism for the ISUP maintenance commands. An early version of that draft is on the IETF site and a major update that changes the INFO body contents to an XML representation will be released within days. TCAP is not special in this regard. IMHO, ISUP and TCAP are the best place to do translations because the "semantic level" appears to me to be the closest to where SIP session semantic level is. These two works are designed to augment the basic SIP-ISUP translation draft to include the ability to control PSTN access trunks (e.g. PRI's and IMTs on T-1s) from the PSTN and to do service delivery from existing PSTN elements (i.e. SCPs) to SIP endpoints, both without having to implement SS7 protocol stacks in the SIP elements. The goal is make sharper the demarcation between SIP and SS7. This is primarily a cost argument. SS7 stacks are more expensive in the marketplace than SIP stacks, so limiting the number of SS7 deployments saves costs for the carriers. > Why defining another approach when everythhing neccesary is already defined. Or are there doubts about the maturity in the SIGTRAN protocols? > No, SIGTRAN is very mature and very useful for certain applications. This is just a different approach. I see no reason why tunneling and translation approaches cannot coexist in IETF standards. Both have their applications. > Some questions on the proposed solution: > -- How is adressing beeing resolved? One of the nice things about translation is that it limits addressing problems to the mapping of addresses. You can do about anything you want on the SIP side as long as the mappings at the SIP UA and the GW are handled appropriately. Addressing is certainly an area that is ripe for discussion in any standardization activity. > -- TCAP dialoges are mainly used for call unrelated signalling, means no dialog exists. But one has to have an open SIP-Dialog before exchanging Info-Messages. How is that going to be resolved? The element with the UA maintains a persistent session with the GW for TCAP interactions. I believe this is discussed in the draft. > -- For what kind of services this should be used? Is this solution anticipated for call completion services instead of usage of subscribe/notify? > There are several service examples detailed in the draft. Calling Name Delivery is the one that leaps to mind. FM Frank W. Miller, Ph.D. Chief Technical Officer sentitO Network, Inc. fmiller@sentito.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 mailnull@www1.ietf.org Fri Jan 17 18:21:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07198 for ; Fri, 17 Jan 2003 18:21:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HNbRj06280 for sip-archive@odin.ietf.org; Fri, 17 Jan 2003 18:37:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HNadJ05608; Fri, 17 Jan 2003 18:36:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HNXSJ05507 for ; Fri, 17 Jan 2003 18:33:28 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07139 for ; Fri, 17 Jan 2003 18:17:03 -0500 (EST) From: jean-luc.bouthemy@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0HNKIB08832 for ; Fri, 17 Jan 2003 17:20:28 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 17 Jan 2003 17:20:11 -0600 Received: from daebe001.NOE.Nokia.com ([172.18.242.222]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 17 Jan 2003 15:20:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] any restrictions on characters in user part of sip uri? Date: Fri, 17 Jan 2003 17:20:10 -0600 Message-ID: <8F698F0DD0B49A48BDA9F451A7A68CAE019E6764@daebe001.americas.nokia.com> Thread-Topic: [Sip] any restrictions on characters in user part of sip uri? Thread-Index: AcK+L1ZR/XTR6hmATiu/ovdBSDhbwwAKjVvA To: , X-OriginalArrivalTime: 17 Jan 2003 23:20:10.0997 (UTC) FILETIME=[FB3C1250:01C2BE7E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0HNXSJ05508 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Juha and all: Comment: What about using escaped is %hexhex for support to unicode which can be used for languages such as Japanese. Regards -- Jean-Luc -----Original Message----- From: ext jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] Sent: Friday, January 17, 2003 5:29 AM To: sip@ietf.org Subject: [Sip] any restrictions on characters in user part of sip uri? the syntax of user part of sip uri is: user = 1*( unreserved / escaped / user-unreserved ) user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" escaped is %hexhex and can thus be used to include any character in user. is it really so that there is no restrictions on what chars may be include in user using escaped? for example, is %0000 valid in user? if so, it makes implementations "interesting". -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Jan 20 08:55:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20282 for ; Mon, 20 Jan 2003 08:55:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KECtZ21758 for sip-archive@odin.ietf.org; Mon, 20 Jan 2003 09:12:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KECaJ21750; Mon, 20 Jan 2003 09:12:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HFrUJ09025 for ; Fri, 17 Jan 2003 10:53:30 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26265 for ; Fri, 17 Jan 2003 10:37:18 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0HFeeAv003549; Fri, 17 Jan 2003 16:40:40 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 17 Jan 2003 16:40:40 +0100 Message-ID: <4E85E49D1F0CBF4F96EA08E335750D7D02838A59@Esealnt877.al.sw.ericsson.se> From: "Elisabetta Carrara (EAB)" To: "'Steffen Fries'" , sip@ietf.org Cc: "Fredrik Lindholm (EAB)" Date: Fri, 17 Jan 2003 16:41:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: SRTP and MIKEY usage in SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi Steffen the public-key based methods are most suitable for client-to-client communications. The pre-shared could be for ex a good choice for client(s)-to-server communications. So, for SIP the public-key based may be more suitable, generally speaking. Cheers, /E > -----Original Message----- > From: Steffen Fries [mailto:steffen.fries@siemens.com] > Sent: den 17 januari 2003 16:20 > To: sip@ietf.org > Cc: Elisabetta.Carrara@era.ericsson.se > Subject: SRTP and MIKEY usage in SIP > > > Hi, > > I'm not quite sure, which working group fits best for this > question, thus I'm starting with the SIP WG ;-) > > When SIP and SRTP are used in conjunction, an appropriate > key management is necessary for SRTP. Within the MSEC WG > MIKEY has been defined, which is thought to be used (also) > for SRTP. > > MIKEY and an related draft (draft-ietf-msec-MIKEY-DHHMAC- > 01.txt) offer 4 different key management methods based on: > - pre-shared secrets > - public key encryption > - Diffie Hellman protected with signatures > - Diffie Hellman protected with pre-shared secrets > > When MIKEY and SRTP are to be used in a SIP environment, > what would be a suitable choice out of the four options? > > I'm not sure if the pre-shared secret pased methods are > suitable, since this would assume, that all users who want to > communicate need to exchange a shared secret before. Well, this > could be done by puting a shared secret in the SIP message and > securing this by S/MIME, but then MIKEY would be protected by > symmetric methods, although asymmetric technology was used to > secure the shared secret transport, namely S/MIME. One could > also use the certificates and private keys to secure MIKEY > right from the beginning. > > There might be scenarios where the symmetric case is > appropriate, but I'm not sure if this is a rather general case. > > Is MIKEY generally considered for key management in SIP or will > this rather be done using draft-baugher-mmusic-sdpmediasec- > 00.txt secured by S/MIME? > > The usage of MIKEY and SRTP is especially interesting in > conjunction with other multimedia protocols like H.323. Voice > encryption and associated key management could be performed > across the different signaling protocols. > > Was there already a discussion related to this question, which > I may be missed? > > Regards > Steffen > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Jan 20 09:41:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20284 for ; Mon, 20 Jan 2003 08:55:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KECtq21770 for sip-archive@odin.ietf.org; Mon, 20 Jan 2003 09:12:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KECHJ21709; Mon, 20 Jan 2003 09:12:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HFWgJ07205 for ; Fri, 17 Jan 2003 10:32:42 -0500 Received: from david.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25433 for ; Fri, 17 Jan 2003 10:16:31 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id h0HFJrO24305; Fri, 17 Jan 2003 16:19:53 +0100 (MET) Received: from mars.cert.siemens.de (ust.mchp.siemens.de [139.23.201.17]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id h0HFJqL04988; Fri, 17 Jan 2003 16:19:52 +0100 (MET) Received: from mail-k.mchp.siemens.de (mail-k.mchp.siemens.de [139.23.202.237]) by mars.cert.siemens.de (8.12.7/8.12.7/$SiemensCERT: mail/cert.mc,v 1.40 2003/01/07 15:49:50 ust Exp $) with ESMTP id h0HFJpuB092879; Fri, 17 Jan 2003 16:19:51 +0100 (CET) Received: from mhpaba5c (mhpaba5c [139.23.204.46]) by mail-k.mchp.siemens.de with ESMTP id h0HFKBg4016627; Fri, 17 Jan 2003 16:20:11 +0100 (MET) From: "Steffen Fries" Organization: Siemens AG To: sip@ietf.org Date: Fri, 17 Jan 2003 16:19:49 +0100 MIME-Version: 1.0 Reply-to: steffen.fries@siemens.com CC: Elisabetta.Carrara@era.ericsson.se Message-ID: <3E282D25.14384.17A03F6@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (v4.02a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Content-Transfer-Encoding: 7BIT Subject: [Sip] SRTP and MIKEY usage in SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi, I'm not quite sure, which working group fits best for this question, thus I'm starting with the SIP WG ;-) When SIP and SRTP are used in conjunction, an appropriate key management is necessary for SRTP. Within the MSEC WG MIKEY has been defined, which is thought to be used (also) for SRTP. MIKEY and an related draft (draft-ietf-msec-MIKEY-DHHMAC- 01.txt) offer 4 different key management methods based on: - pre-shared secrets - public key encryption - Diffie Hellman protected with signatures - Diffie Hellman protected with pre-shared secrets When MIKEY and SRTP are to be used in a SIP environment, what would be a suitable choice out of the four options? I'm not sure if the pre-shared secret pased methods are suitable, since this would assume, that all users who want to communicate need to exchange a shared secret before. Well, this could be done by puting a shared secret in the SIP message and securing this by S/MIME, but then MIKEY would be protected by symmetric methods, although asymmetric technology was used to secure the shared secret transport, namely S/MIME. One could also use the certificates and private keys to secure MIKEY right from the beginning. There might be scenarios where the symmetric case is appropriate, but I'm not sure if this is a rather general case. Is MIKEY generally considered for key management in SIP or will this rather be done using draft-baugher-mmusic-sdpmediasec- 00.txt secured by S/MIME? The usage of MIKEY and SRTP is especially interesting in conjunction with other multimedia protocols like H.323. Voice encryption and associated key management could be performed across the different signaling protocols. Was there already a discussion related to this question, which I may be missed? Regards Steffen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Jan 20 12:31:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24946 for ; Mon, 20 Jan 2003 12:31:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KHmEW02078 for sip-archive@odin.ietf.org; Mon, 20 Jan 2003 12:48:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KHlAJ02012; Mon, 20 Jan 2003 12:47:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KHj0J01908 for ; Mon, 20 Jan 2003 12:45:00 -0500 Received: from hotsip.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24769; Mon, 20 Jan 2003 12:27:20 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Jan 2003 18:30:45 +0100 Message-ID: Thread-Topic: SIPit registration time extended Thread-Index: AcLAqanTmh13NaQSR/+3nYBqRZc8WQ== From: "Christian Jansson" To: , , Reply-To: "Sipit 12" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0KHj0J01910 Subject: [Sip] SIPit registration time extended Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, Don't forget to register with the 12th SIPit event. The registration time has been extended until January 24th to give the last minute planners some more time. Everyone implementing products that are up to date with the most recent SIMPLE work should consider to participate since there will be breakout sessions testing against these specifications to let interoperability become a reality also among presence and IM systems! Registration and other useful information is found at: http://www.hotsip.com/sipit12/ If you have questions, contact sipit12@hotsip.com Welcome! The SIPit 12 team. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Jan 20 12:51:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25361 for ; Mon, 20 Jan 2003 12:51:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KI8dP03467 for sip-archive@odin.ietf.org; Mon, 20 Jan 2003 13:08:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KI7tJ03410; Mon, 20 Jan 2003 13:07:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KI65J02702 for ; Mon, 20 Jan 2003 13:06:05 -0500 Received: from hotsip.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25299; Mon, 20 Jan 2003 12:48:25 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Jan 2003 18:51:49 +0100 Message-ID: Thread-Topic: SIPit registration time extended Thread-Index: AcLArJu7uMGtcxaUT1qHfZ2tYaJ1WA== From: "Christian Jansson" To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0KI65J02703 Subject: [Sip] SIPit registration time extended Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, Don't forget to register with the 12th SIPit event. The registration time has been extended until January 24th to give the last minute planners some more time. Everyone implementing products that are up to date with the most recent SIMPLE work should consider to participate since there will be breakout sessions testing against these specifications to let interoperability become a reality also among presence and IM systems! Registration and other useful information is found at: http://www.hotsip.com/sipit12/ If you have questions, contact sipit12@hotsip.com Welcome! The SIPit 12 team. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Jan 20 12:53:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25420 for ; Mon, 20 Jan 2003 12:53:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KIB5Q03593 for sip-archive@odin.ietf.org; Mon, 20 Jan 2003 13:11:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KIALJ03573; Mon, 20 Jan 2003 13:10:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KI9WJ03529 for ; Mon, 20 Jan 2003 13:09:32 -0500 Received: from fmis402r.omnitel.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25384 for ; Mon, 20 Jan 2003 12:51:50 -0500 (EST) From: loretosa@vizzavi.it Received: from fmis439.omnitel.it by fmis402r.omnitel.it via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 20 Jan 2003 17:55:16 UT Received: (private information removed) Received: (private information removed) Content-Class: urn:content-classes:message To: Date: Mon, 20 Jan 2003 18:55:13 +0100 Message-ID: <187101c2c0ad$15386d90$5ade010a@omnitel.it> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Microsoft CDO for Windows 2000 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Thread-Index: AcLArRU4rkHDoSrsRlCnZ3g16vpaRg== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0KI9WJ03530 Subject: [Sip] SIP and Congestion Safety Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, about SIP and Congetion Safety, i've observed there isn't a great interest. I don't know why. I think that will be a giant problem. And the mainly question for it is: what protocol use for transport SIP signals ??? others wg in IETF are working about congestion control algorithms for real-time or, more generally, delay sensitive applications... see DCCP (Datagram Congestion Control Protocol - http://www.ietf.org/html.charters/dccp-charter.html). sometime ago there was a proposal about SCTP use for Instant Messaging with SIP... in other mail i read a proposal about Connection Transport Protocol as default protocol for SIP in the "Session Initiation Protocol Extension to Assure Congestion Safety" draft-ietf-sip-congestsafe-00 there's only a proposal for define and check a CONGESTION-SAFE hop... but it isn't enough Sal _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Jan 20 14:22:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28251 for ; Mon, 20 Jan 2003 14:22:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KJdHM09307 for sip-archive@odin.ietf.org; Mon, 20 Jan 2003 14:39:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KJchJ09241; Mon, 20 Jan 2003 14:38:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KJaWJ08494 for ; Mon, 20 Jan 2003 14:36:32 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28111 for ; Mon, 20 Jan 2003 14:18:49 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0KJMFFp020247 for ; Mon, 20 Jan 2003 11:22:15 -0800 (PST) Received: from bhadoria-lnx.cisco.com (bhadoria-lnx.cisco.com [128.107.140.160]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ACI49574; Mon, 20 Jan 2003 11:22:14 -0800 (PST) Date: Mon, 20 Jan 2003 11:22:14 -0800 (PST) From: Amit Bhadoria To: sip@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] TLS and "sip:" scheme Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , hi, on page 152 section 19.1.2, rfc3261 says that default port for "sip:" using TLS over TCP is 5061. does this mean that a url with "sip:" scheme and transport=tls is a valid url, i.e., is the following url admissible: sip:bhadoria@cisco.com;transport=tls i understand that use of transport=tls has been deprecated, but due to the above mentioned guidelines in rfc, do we still need to accept urls with sip: scheme and transport=tls? thanks. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Jan 21 04:02:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24032 for ; Tue, 21 Jan 2003 04:02:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0L9K3Q00716 for sip-archive@odin.ietf.org; Tue, 21 Jan 2003 04:20:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L9HSJ00607; Tue, 21 Jan 2003 04:17:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L9DoJ00512 for ; Tue, 21 Jan 2003 04:13:51 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23886 for ; Tue, 21 Jan 2003 03:55:52 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0L91Wt10120 for ; Tue, 21 Jan 2003 11:01:32 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 21 Jan 2003 10:59:07 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 21 Jan 2003 10:59:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] SIP and Congestion Safety Date: Tue, 21 Jan 2003 10:59:06 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7166@esebe019.ntc.nokia.com> Thread-Topic: [Sip] SIP and Congestion Safety Thread-Index: AcLArRU4rkHDoSrsRlCnZ3g16vpaRgAfdEeg To: , X-OriginalArrivalTime: 21 Jan 2003 08:59:07.0832 (UTC) FILETIME=[5B3DB380:01C2C12B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0L9DpJ00513 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Please take a look at http://www.ietf.org/internet-drafts/draft-khartabil-sip-congestionsafe-ci-01.txt I'm planning to update this to include a UA posting (eg: contents for PUBLISH or MESSAGE). Regards, Hisham > -----Original Message----- > From: ext loretosa@vizzavi.it [mailto:loretosa@vizzavi.it] > Sent: Monday, January 20, 2003 7:55 PM > To: sip@ietf.org > Subject: [Sip] SIP and Congestion Safety > > > > Hi all, > > about SIP and Congetion Safety, i've observed there isn't a > great interest. > > I don't know why. > I think that will be a giant problem. > > And the mainly question for it is: what protocol use for > transport SIP signals ??? > > > others wg in IETF are working about congestion control > algorithms for real-time > or, more generally, delay sensitive applications... > see DCCP (Datagram Congestion Control Protocol - http://www.ietf.org/html.charters/dccp-charter.html). sometime ago there was a proposal about SCTP use for Instant Messaging with SIP... in other mail i read a proposal about Connection Transport Protocol as default protocol for SIP in the "Session Initiation Protocol Extension to Assure Congestion Safety" draft-ietf-sip-congestsafe-00 there's only a proposal for define and check a CONGESTION-SAFE hop... but it isn't enough Sal _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Jan 21 06:19:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25934 for ; Tue, 21 Jan 2003 06:19:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LBauN08572 for sip-archive@odin.ietf.org; Tue, 21 Jan 2003 06:36:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LBXQJ08431; Tue, 21 Jan 2003 06:33:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LBVFJ08357 for ; Tue, 21 Jan 2003 06:31:15 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25793 for ; Tue, 21 Jan 2003 06:13:14 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0LBGZAw008290; Tue, 21 Jan 2003 12:16:38 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id DL6G9H14; Tue, 21 Jan 2003 12:16:34 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.92]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h0LBGYH7015828; Tue, 21 Jan 2003 13:16:34 +0200 (EET) Message-ID: <3E2D2C10.BF220D2A@lmf.ericsson.se> Date: Tue, 21 Jan 2003 13:16:32 +0200 X-Sybari-Trust: 1cdc4543 9ffcebbb cd1bde24 00000138 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Roberto Tealdi CC: sip@ietf.org Subject: Re: [SIP] Authentication based on SIP request References: <001801c2b808$982d7400$7b01c082@vaio> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Roberto, It means that you can challenge any request (but CANCEL) in order to get credentials for the UAC. Gonzalo Roberto Tealdi wrote: > > Hi to All > > I'm new in SIP and I have a question: > > In draft "draft-ietf-sipping-aaa-req-01" is specified that the Home > AAA server must be able to authenticate a user based on any SIP > Request (except CANCEL): this means that ANY SIP request message (from > client to sip proxy) must contains a user's credentials, for example > an authentication token? > > Thanks a lot. > Roby. > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Jan 21 19:44:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16539 for ; Tue, 21 Jan 2003 19:44:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0M122430487 for sip-archive@odin.ietf.org; Tue, 21 Jan 2003 20:02:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M11MJ30444; Tue, 21 Jan 2003 20:01:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M0wRJ30240 for ; Tue, 21 Jan 2003 19:58:27 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16459 for ; Tue, 21 Jan 2003 19:40:09 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h0M0hT829403; Wed, 22 Jan 2003 00:43:29 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Jan 2003 19:46:11 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214D2D@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Amit Bhadoria'" , sip@ietf.org Subject: RE: [Sip] TLS and "sip:" scheme Date: Tue, 21 Jan 2003 19:46:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , For backwards compatibility, it might be worth supporting that construction, sure. But that URL is not considered RFC3261 compliant - RFC3261 implementations shouldn't generate it, anyway. The section in 19.1.2, I suspect, refers to sending a request for a SIP URI scheme (and no ;transport=tls parameter) over TLS, which is permissable - there's no requirement to append ;transport=tls to the Request-URI when you send a SIP request over TLS. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Amit Bhadoria [mailto:bhadoria@cisco.com] > Sent: Monday, January 20, 2003 11:22 AM > To: sip@ietf.org > Subject: [Sip] TLS and "sip:" scheme > > > hi, > > on page 152 section 19.1.2, rfc3261 says that default port for > "sip:" using TLS over TCP is 5061. does this mean that a url with > "sip:" scheme and transport=tls is a valid url, i.e., is the > following url > admissible: > > sip:bhadoria@cisco.com;transport=tls > > i understand that use of transport=tls has been deprecated, but due to the > above mentioned guidelines in rfc, do we still need to accept urls with > sip: scheme and transport=tls? > > 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Jan 22 03:02:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18515 for ; Wed, 22 Jan 2003 03:02:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0M8KiD01558 for sip-archive@odin.ietf.org; Wed, 22 Jan 2003 03:20:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M8KQJ01551; Wed, 22 Jan 2003 03:20:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M8ILJ01425 for ; Wed, 22 Jan 2003 03:18:21 -0500 Received: from wire.cs.nthu.edu.tw (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18426; Wed, 22 Jan 2003 02:59:53 -0500 (EST) From: shunchao@wire.cs.nthu.edu.tw Received: (from shunchao@localhost) by wire.cs.nthu.edu.tw (8.11.6/8.11.6) id h0M83SK20521; Wed, 22 Jan 2003 16:03:28 +0800 Date: Wed, 22 Jan 2003 16:03:28 +0800 To: sip@ietf.org, sipping@ietf.org Message-ID: <20030122160328.A20304@wire.cs.nthu.edu.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Subject: [Sip] IEEE JSAC - All-IP WIRELESS NETWORKS , CALL FOR PAPERS Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , CALL FOR PAPERS IEEE Journal on Selected Areas in Communications ALL-IP WIRELESS NETWORKS IP (Internet Protocol), which is already a universal network-layer protocol for wireline packet networks, is becoming a promising universal network-layer protocol over all wireless systems. IP provides a globally successful open infrastructure for creating and providing services and applications. An all-IP wireless and wireline network could make wireless networks more robust, scalable, and cost effective. It will also enable the abundant applications and software technologies developed for IP networks to be used over wireless networks. Today's many different wireless systems, ranging from PANs (Personal Area Networks), wireless LANs (Local Area Networks) to wide-area cellular systems, are often not compatible with each other which makes it difficult for a user to roam from one radio system to another. No wireless technology has emerged as a common and long-term universal solution. With IP as the common network layer protocol, an IP-based mobile device (with multiple radio interfaces or software defined radio) could roam between different wireless systems. The papers in this issue will focus on state-of-the-art research in all-IP wireless networks. Submission for Beyond 3G (B3G) systems will be included. We solicit papers covering a variety of topics including, but not limited to, the following topics: o Systems and Architecture o Access Protocols o Transport Protocols o Signaling Protocols o Resource Management o Power Control and Management o QoS Provisioning o Security o Mobile VoIP o Video over Wireless Internet o Network Performance Analysis o Internetworking o System Integration Only original and unpublished research papers will be considered. Authors should follow the IEEE J-SAC manuscript format described in the Information for Authors on the inside back cover of any issue of J-SAC. There will be one round of reviews and acceptance will be limited to papers needing only moderate revisions. Prospective authors should submit a pdf version of their complete manuscript (which should be compressed if the file size exceeds 1 Mbyte) online via http://wire.cs.nthu.edu.tw/~jsac according to the following timetable: Manuscript Submission: FEBRUARY 1, 2003 Acceptance Notification: June 1, 2003 Final Manuscript Due: September 1, 2003 Publication: 1st Quarter 2004 Prathima Agrawal Telcordia Technologies Room 1J244B 445 South St Morristown, NJ 07960 USA Tao Zhang Telcordia Technologies Room 1J214B 445 South St Morristown, NJ 07960 USA Cormac J. Sreenan Dept of Computer Science University College Cork Cork, Ireland Jyh-Cheng Chen Dept of Computer Science and Inst of Communications Engineering National Tsing Hua Univ Hsinchu, Taiwan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Jan 22 03:34:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18983 for ; Wed, 22 Jan 2003 03:34:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0M8qpm03260 for sip-archive@odin.ietf.org; Wed, 22 Jan 2003 03:52:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M8qUJ03242; Wed, 22 Jan 2003 03:52:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M8k2J03093 for ; Wed, 22 Jan 2003 03:46:02 -0500 Received: from gsp04-c21d2.vodafone.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18900 for ; Wed, 22 Jan 2003 03:27:34 -0500 (EST) From: loretosa@vodafone.it Received: from vodafone.it (127.0.0.1) by gsp04-c21d2.vodafone.it (NPlex 5.1.046) id 3E2D97CB0000005F; Wed, 22 Jan 2003 09:30:55 +0100 X-CNS-Auth: Date: Wed, 22 Jan 2003 09:30:55 +0100 Message-Id: Subject: Ri: RE: [Sip] SIP and Congestion Safety MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" To: hisham.khartabil@nokia.com To: sip@ietf.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0M8k2J03094 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Hisham, I've read your draft "draft-khartabil-sip-congestionsafe-ci-01.txt" It's an interesting draft, but not cover all my questions. In any case about your draft i've some observations: in the section -5.0- You write that the proxy affect for Congestion Safe in 3GPP architecture is S-CSCF. I think that P-CSCF is the most critical Proxy. This one is the closest proxy to the UA. And in a Visited UA scenario, I think that it's preferable, for an Operator 3G, not forward information about his link capacity to another Operator 3G. Morover I think that are also performance problem for which P-CSCF have know information about Max-Size SIP message that UAS can handle. In the section 5.5. "Home Proxy Receiving 413 Response from UA" What's advantage for a UA to reject a request, also if is a large SIP request, when it's already received? When arrived to UA, the large message already has congestioned the link. The main problem is avoided and prevent the congestion link. Sal > Please take a look at > > http://www.ietf.org/internet-drafts/draft-khartabil-sip-congestionsafe-ci-01.txt > > I'm planning to update this to include a UA posting (eg: contents for PUBLISH or MESSAGE). > > Regards, > Hisham > > > -----Original Message----- > > From: ext loretosa@vizzavi.it [mailto:loretosa@vizzavi.it] > > Sent: Monday, January 20, 2003 7:55 PM > > To: sip@ietf.org > > Subject: [Sip] SIP and Congestion Safety > > > > > > > > Hi all, > > > > about SIP and Congetion Safety, i've observed there isn't a > > great interest. > > > > I don't know why. > > I think that will be a giant problem. > > > > And the mainly question for it is: what protocol use for > > transport SIP signals ??? > > > > > > others wg in IETF are working about congestion control > > algorithms for real-time > > or, more generally, delay sensitive applications... > > see DCCP (Datagram Congestion Control Protocol - > http://www.ietf.org/html.charters/dccp-charter.html). > > sometime ago there was a proposal about SCTP use for Instant Messaging with SIP... > > in other mail i read a proposal about Connection Transport Protocol as default protocol for SIP > > in the "Session Initiation Protocol Extension to Assure Congestion Safety" draft-ietf-sip-congestsafe-00 > there's only a proposal for define and check a CONGESTION-SAFE hop... but it isn't enough > > > Sal > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 > Per registrarti gratuitamente a Vodafone Mail vai su www.190.it _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Jan 22 05:08:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20892 for ; Wed, 22 Jan 2003 05:08:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MAQ7G09706 for sip-archive@odin.ietf.org; Wed, 22 Jan 2003 05:26:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MAPeJ09666; Wed, 22 Jan 2003 05:25:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MAFIJ09292 for ; Wed, 22 Jan 2003 05:15:18 -0500 Received: from sonim-india.com ([164.164.94.98]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20550 for ; Wed, 22 Jan 2003 04:47:36 -0500 (EST) Received: (from root@localhost) by sonim-india.com (8.11.6/8.11.6) id h0M9FUj16605 for ; Wed, 22 Jan 2003 14:45:30 +0530 Received: from boxer (boxer.sonim-india.com [192.168.2.88]) by sonim-india.com (8.11.6/8.11.6) with SMTP id h0M9FLU16519 for ; Wed, 22 Jan 2003 14:45:29 +0530 Message-ID: <006701c2c1fb$e1072890$5802a8c0@boxer> From: "Vishal Verma" To: Date: Wed, 22 Jan 2003 15:21:39 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-AntiVirus: Scanned for Viruses at sonim communications (india) pvt. ltd. Content-Transfer-Encoding: 7bit Subject: [Sip] query for compact headers Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi , what are the compact header notations for Max-Forward,CSeq fields ?.Is there any draft available which lists down sip fields vs their compact header notations ? regards, vishal _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Jan 22 09:43:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25980 for ; Wed, 22 Jan 2003 09:43:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MF1wk26672 for sip-archive@odin.ietf.org; Wed, 22 Jan 2003 10:01:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MF1QJ26634; Wed, 22 Jan 2003 10:01:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MExYJ26506 for ; Wed, 22 Jan 2003 09:59:34 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25890 for ; Wed, 22 Jan 2003 09:40:58 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0MEhP022195 for ; Wed, 22 Jan 2003 16:43:25 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 22 Jan 2003 16:44:23 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 22 Jan 2003 16:44:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: RE: [Sip] SIP and Congestion Safety Date: Wed, 22 Jan 2003 16:44:23 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7175@esebe019.ntc.nokia.com> Thread-Topic: RE: [Sip] SIP and Congestion Safety Thread-Index: AcLB8JlwAKt/Y0doSCqSvhU/iB+A8gAMnMvw To: , X-OriginalArrivalTime: 22 Jan 2003 14:44:24.0211 (UTC) FILETIME=[C1940630:01C2C224] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0MExYJ26507 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext loretosa@vodafone.it [mailto:loretosa@vodafone.it] > Sent: Wednesday, January 22, 2003 10:31 AM > To: Khartabil Hisham (NMP/Helsinki); sip@ietf.org > Subject: Ri: RE: [Sip] SIP and Congestion Safety > > > > Hi Hisham, > > I've read your draft "draft-khartabil-sip-congestionsafe-ci-01.txt" > It's an interesting draft, but not cover all my questions. > > In any case about your draft i've some observations: > > in the section -5.0- > You write that the proxy affect for Congestion Safe in 3GPP > architecture is S-CSCF. > I think that P-CSCF is the most critical Proxy. > This one is the closest proxy to the UA. And in a Visited UA > scenario, I think that it's preferable, for an Operator 3G, > not forward information about his link capacity to another > Operator 3G. The document does say "the S-CSCF closest to the UA". I think the use of the word "home" confused you. > Morover I think that are also performance problem for which > P-CSCF have know information about Max-Size SIP message that > UAS can handle. Perhaps, but to my knowledge, S-CSCFs have the intelligence. P-CSCFs are nothing but outbound proxies to the sending UA. In any case, where 3GPP decides to put the intelligence is out of the scope of this document. The sentence you refer to is just an example (and perhaps should be removed). > > In the section 5.5. "Home Proxy Receiving 413 Response from UA" > What's advantage for a UA to reject a request, also if is a > large SIP request, when it's already received? When arrived > to UA, the large message already has congestioned the link. > > The main problem is avoided and prevent the congestion link. The solution is not just limited to the congestion of the network, it also tries to handle out-of-memory situations for a terminal, even when using TCP. If a terminal is receiving TCP packets for a sip message and knows it can't handle anymore packets, it can stop receiving and send 413 error response. Regards, Hisham > > > > > > Sal > > > > Please take a look at > > > > > http://www.ietf.org/internet-drafts/draft-khartabil-sip-conges > tionsafe-ci-01.txt > > > > I'm planning to update this to include a UA posting (eg: > contents for PUBLISH or MESSAGE). > > > > Regards, > > Hisham > > > > > -----Original Message----- > > > From: ext loretosa@vizzavi.it [mailto:loretosa@vizzavi.it] > > > Sent: Monday, January 20, 2003 7:55 PM > > > To: sip@ietf.org > > > Subject: [Sip] SIP and Congestion Safety > > > > > > > > > > > > Hi all, > > > > > > about SIP and Congetion Safety, i've observed there isn't a > > > great interest. > > > > > > I don't know why. > > > I think that will be a giant problem. > > > > > > And the mainly question for it is: what protocol use for > > > transport SIP signals ??? > > > > > > > > > others wg in IETF are working about congestion control > > > algorithms for real-time > > > or, more generally, delay sensitive applications... > > > see DCCP (Datagram Congestion Control Protocol - > > http://www.ietf.org/html.charters/dccp-charter.html). > > > > sometime ago there was a proposal about SCTP use for > Instant Messaging with SIP... > > > > in other mail i read a proposal about Connection Transport > Protocol as default protocol for SIP > > > > in the "Session Initiation Protocol Extension to Assure > Congestion Safety" draft-ietf-sip-congestsafe-00 > > there's only a proposal for define and check a > CONGESTION-SAFE hop... but it isn't enough > > > > > > Sal > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 > > > > Per registrarti gratuitamente a Vodafone Mail vai su www.190.it > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Jan 22 10:19:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27406 for ; Wed, 22 Jan 2003 10:19:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MFb6B29380 for sip-archive@odin.ietf.org; Wed, 22 Jan 2003 10:37:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MFakJ29212; Wed, 22 Jan 2003 10:36:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MFZYJ29120 for ; Wed, 22 Jan 2003 10:35:34 -0500 Received: from broadsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27329 for ; Wed, 22 Jan 2003 10:16:57 -0500 (EST) Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.12.6) id h0MFKOwp002061; Wed, 22 Jan 2003 10:20:24 -0500 (EST) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] query for compact headers Date: Wed, 22 Jan 2003 10:22:15 -0500 Message-ID: <000401c2c22a$0bc351c0$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <006701c2c1fb$e1072890$5802a8c0@boxer> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > what are the compact header notations for > Max-Forward, CSeq fields ?. Neither has a compact form. The CSeq name was considered small enough. The Max-Forwards was not a required header within rfc 2543; thus I guess that it was not considered common enough for a compact form. The compact form was not added to rfc 3261 since it would not be backward compatible with rfc 2543. > Is there any draft available which lists > down sip fields vs their compact header > notations ? The compact forms are listed with the header definition within the associated rfc's. The following link consolidates the definitions from various drafts and rfc's. http://www.iana.org/assignments/sip-parameters _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Jan 22 16:43:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08435 for ; Wed, 22 Jan 2003 16:43:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MM1NZ23181 for sip-archive@odin.ietf.org; Wed, 22 Jan 2003 17:01:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MM0mJ22940; Wed, 22 Jan 2003 17:00:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MLviJ22507 for ; Wed, 22 Jan 2003 16:57:44 -0500 Received: from hopper.funtv.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08223 for ; Wed, 22 Jan 2003 16:39:00 -0500 (EST) Received: from skim (sns.funtv.com [206.19.96.100]) by hopper.funtv.com (8.11.6+Sun/8.11.6) with SMTP id h0MLgRh01709 for ; Wed, 22 Jan 2003 13:42:27 -0800 (PST) Message-ID: <01b201c2c25f$473f5610$400015ac@skim> From: "Seonman Kim" To: Date: Wed, 22 Jan 2003 13:43:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Subject: [Sip] Multiple SDP descriptions for conferencing Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I am trying to implement a SIP-based multi-point conferencing based on "Centralized Signaling, Distributed Media" model (draft-ietf-sipping-conferencing-models-01.txt). In this model, each participant UA gets updated SDP descriptions using "re-INVITE" whenever a user enters to (or exits from) the conference. If the number of participants becomes more than two, then the re-INVITE message should contain two or more SDP descriptions. For example, if user A, B and C are in the conference, then a re-INVITE to user A should contain two SDP description, one for user B and the other for user C. My question here is: how to describe multiple SDP descriptions in the content body of INVITE (or 200 OK) message? Do we just concatenate them? For example, if the conference server sends re-INVITE to user A with SDPs of user B and C, the content body will look like this: v=0 o=user-b 0 0 IN IP4 192.168.1.100 s=session c=IN IP4 192.168.1.100 b=CT:1000 t=0 0 m=audio 30001 RTP/AVP 0 a=rtpmap:0 PCMU/8000 v=0 o=user-c 0 0 IN IP4 192.168.1.101 s=session c=IN IP4 192.168.1.101 b=CT:1000 t=0 0 m=audio 30002 RTP/AVP 0 a=rtpmap:0 PCMU/8000 Is this correct implementation for multiple SDP sessions? I could not find any descriptions in RTF 3261 that say UA should handle multiple SDP sessions. Thanks, Seonman _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 23 12:18:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13796 for ; Thu, 23 Jan 2003 12:18:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0NHarK09758 for sip-archive@odin.ietf.org; Thu, 23 Jan 2003 12:36:53 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NHaLJ09734; Thu, 23 Jan 2003 12:36:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NHWnJ09605 for ; Thu, 23 Jan 2003 12:32:49 -0500 Received: from menelao.polito.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13680 for ; Thu, 23 Jan 2003 12:13:42 -0500 (EST) Received: (qmail 21259 invoked from network); 23 Jan 2003 17:17:07 -0000 Received: from sl123.polito.it (HELO vaio) (130.192.1.123) by menelao.polito.it with SMTP; 23 Jan 2003 17:17:07 -0000 Message-ID: <006401c2c303$10190ab0$7b01c082@vaio> From: "Roberto Tealdi" To: Subject: [SIP] JAIN SIP open source user agents Date: Thu, 23 Jan 2003 18:15:41 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0061_01C2C30B.702D0390" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0061_01C2C30B.702D0390 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, does anyone indicate me a free open source user agent implementation = based on JAIN SIP? Thanks a lot. Roby. ------=_NextPart_000_0061_01C2C30B.702D0390 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All,
 
does anyone indicate me a free open = source user=20 agent implementation based on JAIN SIP?
 
Thanks a lot.
 
Roby.
------=_NextPart_000_0061_01C2C30B.702D0390-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 23 12:44:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14678 for ; Thu, 23 Jan 2003 12:44:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0NI39k11712 for sip-archive@odin.ietf.org; Thu, 23 Jan 2003 13:03:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NI20J11643; Thu, 23 Jan 2003 13:02:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NI0UJ11521 for ; Thu, 23 Jan 2003 13:00:30 -0500 Received: from gamma.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14540; Thu, 23 Jan 2003 12:41:21 -0500 (EST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0NHilD09938; Thu, 23 Jan 2003 09:44:47 -0800 (PST) Message-Id: <200301231744.h0NHilD09938@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, sip@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 23 Jan 2003 09:44:47 -0800 Subject: [Sip] RFC 3313 on Private Session Initiation Protocol (SIP) Extensions for Media Authorization Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3313 Title: Private Session Initiation Protocol (SIP) Extensions for Media Authorization Author(s): W. Marshall, Ed. Status: Informational Date: January 2003 Mailbox: wtm@research.att.com Pages: 16 Characters: 36866 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sip-call-auth-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3313.txt This document describes the need for Quality of Service (QoS) and media authorization and defines a Session Initiation Protocol (SIP) extension that can be used to integrate QoS admission control with call signaling and help guard against denial of service attacks. The use of this extension is only applicable in administrative domains, or among federations of administrative domains with previously agreed-upon policies, where both the SIP proxy authorizing the QoS, and the policy control of the underlying network providing the QoS, belong to that administrative domain or federation of domains. This document is a product of the Session Initiation Protocol Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030123094237.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3313 --OtherAccess Content-Type: Message/External-body; name="rfc3313.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030123094237.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 23 17:05:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21587 for ; Thu, 23 Jan 2003 17:05:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0NMOdX29868 for sip-archive@odin.ietf.org; Thu, 23 Jan 2003 17:24:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NMNrJ29835; Thu, 23 Jan 2003 17:23:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NMJhJ29662 for ; Thu, 23 Jan 2003 17:19:43 -0500 Received: from pmesmtp01.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21459 for ; Thu, 23 Jan 2003 17:00:30 -0500 (EST) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0H9600G32T5WDX@firewall.wcom.com> for sip@ietf.org; Thu, 23 Jan 2003 22:01:08 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H9600701SZYTV@pmismtp01.wcomnet.com>; Thu, 23 Jan 2003 22:01:08 +0000 (GMT) Received: from ajohnston.wcom.com ([166.42.33.61]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H96007GTT3VIL@pmismtp01.wcomnet.com>; Thu, 23 Jan 2003 21:59:57 +0000 (GMT) Date: Thu, 23 Jan 2003 15:59:52 -0600 From: Alan Johnston Subject: Re: [Sip] Multiple SDP descriptions for conferencing In-reply-to: <01b201c2c25f$473f5610$400015ac@skim> X-Sender: Alan.Johnston@pop.mcit.com To: Seonman Kim , sip@ietf.org Message-id: <5.1.1.6.0.20030123154639.03e95c68@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; charset=us-ascii; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi Seonman, You will find more updated work on SIP conferencing with the SIPPING Conferencing Design Team: http://www.softarmor.com/sipping/teams/conf/ The framework document includes a discussion of the this model: http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-conferencing-framework-00.txt Instead of multiple SDP message bodies, the re-INVITE would add an extra media line for each participant that enters the conference. See below for an example. For other valid offer/answer examples of SDP, see: http://www.ietf.org/internet-drafts/draft-johnston-mmusic-offer-answer-examples-00.txt Thanks, Alan Johnston WorldCom sip:alan@digitalari.com At 01:43 PM 1/22/2003 -0800, Seonman Kim wrote: >Hi, > >I am trying to implement a SIP-based multi-point conferencing based on >"Centralized Signaling, Distributed Media" model >(draft-ietf-sipping-conferencing-models-01.txt). In this model, each >participant UA gets updated SDP descriptions using "re-INVITE" whenever a >user enters to (or exits from) the conference. If the number of participants >becomes more than two, >then the re-INVITE message should contain two or more SDP descriptions. >For example, if user A, B and C are in the conference, then a re-INVITE to >user A should contain two SDP description, one for user B and the other for >user C. > >My question here is: how to describe multiple SDP descriptions in the >content body >of INVITE (or 200 OK) message? Do we just concatenate them? >For example, if the conference server sends re-INVITE to user A with SDPs of >user B and C, the content body will look like this: > >v=0 >o=user-b 0 0 IN IP4 192.168.1.100 >s=session >c=IN IP4 192.168.1.100 >b=CT:1000 >t=0 0 >m=audio 30001 RTP/AVP 0 >a=rtpmap:0 PCMU/8000 >v=0 >o=user-c 0 0 IN IP4 192.168.1.101 >s=session >c=IN IP4 192.168.1.101 >b=CT:1000 >t=0 0 >m=audio 30002 RTP/AVP 0 >a=rtpmap:0 PCMU/8000 > >Is this correct implementation for multiple SDP sessions? No, I think it would look like this: v=0 o=user-b 0 0 IN IP4 192.168.1.100 s=session b=CT:1000 t=0 0 m=audio 30001 RTP/AVP 0 c=IN IP4 192.168.1.100 a=rtpmap:0 PCMU/8000 m=audio 30002 RTP/AVP 0 c=IN IP4 192.168.1.101 a=rtpmap:0 PCMU/8000 >I could not find any descriptions in RTF 3261 that say UA should handle >multiple SDP sessions. > >Thanks, >Seonman > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Jan 23 21:24:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27621 for ; Thu, 23 Jan 2003 21:24:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0O2hT314233 for sip-archive@odin.ietf.org; Thu, 23 Jan 2003 21:43:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O2h3J14222; Thu, 23 Jan 2003 21:43:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O2dKJ14077 for ; Thu, 23 Jan 2003 21:39:20 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27597 for ; Thu, 23 Jan 2003 21:20:01 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h0O2NQLc007196 for ; Thu, 23 Jan 2003 20:23:26 -0600 From: "Dean Willis" To: Date: Thu, 23 Jan 2003 20:23:23 -0600 Message-ID: <001101c2c34f$91959fd0$ee036e3f@txdwillis> 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.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Subject: [Sip] FW: SIP patent infringement warning Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit FYI -----Original Message----- From: pierobon [mailto:pierobon@sympatico.ca] Sent: Thursday, January 23, 2003 7:06 PM To: dean.willis@softarmor.com; rohan@cisco.com; jon.peterson@neustar.biz Cc: sob@harvard.edu; mankin@psg.com; dromasca@avaya.com; sip@ietf.org Subject: SIP patent infringement warning Dear Sirs, Having examined your specs and use of SIP, I'm must point out that your company may be infringing on my patent rights. You can verify for yourself by examining the patent at http://massive-array-cellular-system.com Thanks, Victor Pierobon 416 221-2340 Pierobon@attcanada.ca To: Dean Willis Rohan Mahy Jon Peterson Scott Bradner Allison Mankin Allison Mankin Dan Romascanu _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 24 05:02:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14634 for ; Fri, 24 Jan 2003 05:02:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OALbH18620 for sip-archive@odin.ietf.org; Fri, 24 Jan 2003 05:21:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OAKwJ18591; Fri, 24 Jan 2003 05:20:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OAFsJ18419 for ; Fri, 24 Jan 2003 05:15:54 -0500 Received: from david.sae.siemens.com.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14549 for ; Fri, 24 Jan 2003 04:56:26 -0500 (EST) X-Envelope-Sender-Is: qing.gao@siemens.com (at relayer david.sae.siemens.com.sg) Received: from mail.sae.siemens.com.sg (mail.sae.siemens.com.sg [194.138.237.14]) by david.sae.siemens.com.sg (8.11.6/8.11.6) with ESMTP id h0O9uhl05234 for ; Fri, 24 Jan 2003 17:56:43 +0800 (SGT) Received: from sgpk001a.sae.siemens.com.sg (sgpk001a.sae.siemens.com.sg [140.231.107.1]) by mail.sae.siemens.com.sg (8.11.6/8.11.6) with ESMTP id h0O9w8E17679 for ; Fri, 24 Jan 2003 17:58:08 +0800 (SGT) Received: by sgpk001a.sae.siemens.com.sg with Internet Mail Service (5.5.2655.55) id ; Fri, 24 Jan 2003 17:49:49 +0800 Message-ID: <7319EDDDE0CD7C458023FF64886CB177038FF620@sgpk001a.sae.siemens.com.sg> From: Gao Qing To: sip@ietf.org Date: Fri, 24 Jan 2003 17:49:47 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C38D.EE69A060" Subject: [Sip] target set Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2C38D.EE69A060 Content-Type: text/plain; charset="iso-8859-1" Dear Sirs, Who can explain me what exactly is "target set" in RFC3261? Is there a definition of it somewhere? Thanks in advance! Gao Qing ------_=_NextPart_001_01C2C38D.EE69A060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable target set

Dear Sirs,

Who can explain me what = exactly is "target set" in RFC3261? Is there a definition of = it somewhere?

Thanks in advance!

Gao Qing

------_=_NextPart_001_01C2C38D.EE69A060-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 24 05:15:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14889 for ; Fri, 24 Jan 2003 05:15:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OAYcK19276 for sip-archive@odin.ietf.org; Fri, 24 Jan 2003 05:34:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OAYKJ19267; Fri, 24 Jan 2003 05:34:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OAUlJ19115 for ; Fri, 24 Jan 2003 05:30:47 -0500 Received: from menelao.polito.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14815 for ; Fri, 24 Jan 2003 05:11:17 -0500 (EST) Received: (qmail 3048 invoked from network); 24 Jan 2003 10:14:45 -0000 Received: from sl123.polito.it (HELO vaio) (130.192.1.123) by menelao.polito.it with SMTP; 24 Jan 2003 10:14:45 -0000 Message-ID: <004201c2c391$3a131ac0$7b01c082@vaio> From: "Roberto Tealdi" To: "Tom Scott" Cc: References: <3E307E20.50001@vedatel.com> Subject: Re: [SIP] JAIN SIP open source user agents Date: Fri, 24 Jan 2003 11:12:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Try http://www.siptrex.net/downloads/ Roberto. ----- Original Message ----- From: "Tom Scott" To: "Roberto Tealdi" Sent: Friday, January 24, 2003 12:43 AM Subject: [Fwd: [SIP] JAIN SIP open source user agents] > Roberto, > > If you find an free open source UA based on SIP JAIN, please post > the location on the list or send to me. > > -- TIA, TT > > > -------- Original Message -------- > Subject: [SIP] JAIN SIP open source user agents > Date: Thu, 23 Jan 2003 18:15:41 +0100 > From: "Roberto Tealdi" > To: > > > > Hi All, > > does anyone indicate me a free open source user agent implementation > based on JAIN SIP? > > Thanks a lot. > > Roby. > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 24 05:25:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15096 for ; Fri, 24 Jan 2003 05:25:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OAik420459 for sip-archive@odin.ietf.org; Fri, 24 Jan 2003 05:44:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OAiRJ20437; Fri, 24 Jan 2003 05:44:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OAebJ20259 for ; Fri, 24 Jan 2003 05:40:37 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15017 for ; Fri, 24 Jan 2003 05:21:07 -0500 (EST) Received: from Natarajucl1127 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H9700921RI7VN@mta0.huawei.com> for sip@ietf.org; Fri, 24 Jan 2003 18:22:58 +0800 (CST) Date: Fri, 24 Jan 2003 15:55:09 +0530 From: "Nataraju A.B.(huawei)" Subject: Re: [Sip] target set To: Gao Qing , sip@ietf.org Message-id: <000f01c2c392$e072d9e0$5d02120a@in.huawei.com> Organization: Huawei Technologies India Pvt. Ltd., MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_y7yN2XXz7AzwPRYCMEYJlg)" X-Priority: 3 X-MSMail-priority: Normal References: <7319EDDDE0CD7C458023FF64886CB177038FF620@sgpk001a.sae.siemens.com.sg> Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_y7yN2XXz7AzwPRYCMEYJlg) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT target setHi, I guess the target set (contact addressses) means the set of URI's returned by the redirect server. these are the request uri for the next request send by teh UAC to reach the intended user. Regards, ------------------------------------------- Nataraju A.B. Huawei Technologies India Pvt. Ltd., Tel : +91-80-5217152 / 4 Xtn 142 ------------------------------------------- ----- Original Message ----- From: Gao Qing To: sip@ietf.org Sent: Friday, January 24, 2003 3-19 Subject: [Sip] target set Dear Sirs, Who can explain me what exactly is "target set" in RFC3261? Is there a definition of it somewhere? Thanks in advance! Gao Qing --Boundary_(ID_y7yN2XXz7AzwPRYCMEYJlg) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT target set
Hi,
I guess the target set (contact addressses) means the set of URI's returned by the redirect server.
these are the request uri for the next request send by teh UAC to reach the intended user.
Regards,
-------------------------------------------
Nataraju A.B.
Huawei Technologies India Pvt. Ltd.,
Tel : +91-80-5217152 / 4 Xtn 142
-------------------------------------------
----- Original Message -----
From: Gao Qing
Sent: Friday, January 24, 2003 3-19
Subject: [Sip] target set

Dear Sirs,

Who can explain me what exactly is "target set" in RFC3261? Is there a definition of it somewhere?

Thanks in advance!

Gao Qing

--Boundary_(ID_y7yN2XXz7AzwPRYCMEYJlg)-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 24 06:42:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16038 for ; Fri, 24 Jan 2003 06:42:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OC1uU24491 for sip-archive@odin.ietf.org; Fri, 24 Jan 2003 07:01:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OC18J24467; Fri, 24 Jan 2003 07:01:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OBrrJ24218 for ; Fri, 24 Jan 2003 06:53:53 -0500 Received: from btlmail.bplmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15939 for ; Fri, 24 Jan 2003 06:34:14 -0500 (EST) Received: from [10.10.13.58] (helo=rkumar) by btlmail.bplmail.com with smtp (Exim 3.22 #1 (Red Hat Linux)) id 18c20j-0004xV-00; Fri, 24 Jan 2003 16:58:37 +0530 Reply-To: From: "Ranjit Kumar Avasarala" To: "Gao Qing" , Subject: RE: [Sip] target set Date: Fri, 24 Jan 2003 17:06:35 +0530 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C2C3CA.F37ED1A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <7319EDDDE0CD7C458023FF64886CB177038FF620@sgpk001a.sae.siemens.com.sg> Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C2C3CA.F37ED1A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit target setHI 'target set' is a set of uris which the client sets to try incase it receives a 3xx response. so to start with the client will have only one uri in the target set ile the target it intends to reach. now say it receives 3xx (300 Moved) response then it receives a new URI in the contact header. so it can place this URI in its target set and send the request to that URI. so this way the target set grows. -Ranjit -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Gao Qing Sent: Friday, January 24, 2003 3:20 PM To: sip@ietf.org Subject: [Sip] target set Dear Sirs, Who can explain me what exactly is "target set" in RFC3261? Is there a definition of it somewhere? Thanks in advance! Gao Qing ------=_NextPart_000_0005_01C2C3CA.F37ED1A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable target set
HI
 
'target set' is a set of uris which the = client sets to=20 try incase it receives a 3xx response.
so to=20 start with the client will have only one uri in the target set ile the = target it=20 intends to reach.
 
now=20 say it receives 3xx (300 Moved) response then it receives a new URI in = the=20 contact header. so it can place this URI in its target set and send the = request=20 to that URI.
 
so=20 this way the target set grows.
 
-Ranjit
-----Original Message-----
From: sip-admin@ietf.org = [mailto:sip-admin@ietf.org]On Behalf Of Gao = Qing
Sent:=20 Friday, January 24, 2003 3:20 PM
To: = sip@ietf.org
Subject:=20 [Sip] target set

Dear Sirs,

Who can explain me what exactly is = "target set" in=20 RFC3261? Is there a definition of it somewhere?

Thanks in advance!

Gao Qing=20

------=_NextPart_000_0005_01C2C3CA.F37ED1A0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 24 06:55:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16258 for ; Fri, 24 Jan 2003 06:55:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OCEDk25835 for sip-archive@odin.ietf.org; Fri, 24 Jan 2003 07:14:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OCDvJ25805; Fri, 24 Jan 2003 07:13:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OCCxJ25734 for ; Fri, 24 Jan 2003 07:12:59 -0500 Received: from rsys001a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16232; Fri, 24 Jan 2003 06:53:29 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Jan 2003 11:56:56 -0000 Received: from percy.roke.co.uk ([193.118.192.111]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CN3C00KX; Fri, 24 Jan 2003 11:56:51 -0000 From: "Conroy, Lawrence (SMTP)" To: Christer Holmberg Cc: jh@lohi.eng.song.fi, Henning Schulzrinne , sip@ietf.org, iptel@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <3E311F6C.AE17B814@lmf.ericsson.se> References: <3E27EF16.B7312454@lmf.ericsson.se> <15911.63537.627963.460641@harjus.eng.song.fi> <3E27FF63.4030601@cs.columbia.edu> <15912.432.180748.674189@harjus.eng.song.fi> <3E28020E.4080805@cs.columbia.edu> <15912.984.540036.277317@harjus.eng.song.fi> <3E311F6C.AE17B814@lmf.ericsson.se> Date: Fri, 24 Jan 2003 11:56:48 +0000 Subject: Re: [Iptel] Re: [Sip] TEL-URL local numbers Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , At 1:11 pm +0200 24/1/03, Christer Holmberg wrote: >Hi, > >> At 3:23 pm +0200 17/1/03, jh@lohi.eng.song.fi wrote: >> >Henning Schulzrinne writes: >> > >> > > > if my from uri is +358-3-1234567 and i make a call to 03-2345678, the >> > > > user agent or proxy could figure out that the missing country code is >> > > > +358. this is normal dial plan stuff. >> > > >> > > tel URIs, as has been discussed a few times, do no incorporate dial >> > > plans. They are *generated* by dial plans. >> > >> >if the tel uri must be always fully qualified then the ua must have a >> >dial plan and generate the fully qualified tel uri. in some cases it >> >would be easier to let the proxy to run the dial plan code on the >> >message and fully qualify the tel uri. >> > >> >-- juha > >[Lawrence said:] > > Hi Folks, >> ...sigh... >> >> If I receive a tel URL containing a local number, without >> and idea of the context *in the place that the URL was constructed* >> then I don't know whether or not I'm in that context. > >[CHH] In this case you could reject it. If the sender didn't insert it, and >there was no intermediate node inserting it, there is a network architecture >problem. > >My point, I guess Juha's too, was not that there should not be a context when >the URL reaches the UAS, but that it MAY be inserted by another node than the >UAC. > >I agree on that. However, my SIP phone may not know to which context they >belong, for whatever reason, but the outbound proxy they communicate with DO >know. To which I reply:: Aha! Thanks for the clarification - I'm being slow today. This is a pure SIP issue - usage of tel URLs in SIP, and request modification by intermediate nodes. Interesting issue. However, IMHO there are other uses for tel URLs, so I'd suggest that draft-antti-rfc2916bis is correct in mandating this behaviour. If there's a separate draft for "SIP usage of tel URLs" that qualifies the main tel URL RFC, relaxing the requirement, that's fine; I'm not sure if it's a SIP or SIPPING job, but I think that's where it lives. I just don't want to nail this down in the general 2916 update. all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 24 07:38:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16982 for ; Fri, 24 Jan 2003 07:38:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OCvR828085 for sip-archive@odin.ietf.org; Fri, 24 Jan 2003 07:57:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OCv3J28069; Fri, 24 Jan 2003 07:57:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OCtLJ28011 for ; Fri, 24 Jan 2003 07:55:21 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16956 for ; Fri, 24 Jan 2003 07:35:47 -0500 (EST) Received: from Natarajucl1127 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H9700A70XQ67R@mta0.huawei.com> for sip@ietf.org; Fri, 24 Jan 2003 20:37:21 +0800 (CST) Date: Fri, 24 Jan 2003 18:09:32 +0530 From: "Nataraju A.B.(huawei)" Subject: Re: [Sip] target set To: ranjit.avasarala@bplmail.com, Gao Qing , sip@ietf.org Message-id: <001701c2c3a5$a65f9fa0$5d02120a@in.huawei.com> Organization: Huawei Technologies India Pvt. Ltd., MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_V+DIqRKwyKwlgcQRooJPqg)" X-Priority: 3 X-MSMail-priority: Normal References: Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_V+DIqRKwyKwlgcQRooJPqg) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT target set----- Original Message ----- From: Ranjit Kumar Avasarala To: Gao Qing ; sip@ietf.org Sent: Friday, January 24, 2003 5-06 Subject: RE: [Sip] target set HI 'target set' is a set of uris which the client sets to try incase it receives a 3xx response. so to start with the client will have only one uri in the target set ile the target it intends to reach. This sentance is quiet confusing. In the initial request what the UAC tries out is not the target set (there is only one URI). its the URI which UAC intends to reach out. the target set (contact addresses in 3xx response ) implies the URI's where the target user could be reached. these addresses can be contacted in either linear or parallel search technique. now say it receives 3xx (300 Moved) response then it receives a new URI in the contact header. so it can place this URI in its target set and send the request to that URI. so this way the target set grows. -Ranjit -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Gao Qing Sent: Friday, January 24, 2003 3:20 PM To: sip@ietf.org Subject: [Sip] target set Dear Sirs, Who can explain me what exactly is "target set" in RFC3261? Is there a definition of it somewhere? Thanks in advance! Gao Qing Regards, ------------------------------------------- Nataraju A.B. Huawei Technologies India Pvt. Ltd., Tel : +91-80-5217152 / 4 Xtn 142 ------------------------------------------- --Boundary_(ID_V+DIqRKwyKwlgcQRooJPqg) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT target set
----- Original Message -----
Sent: Friday, January 24, 2003 5-06
Subject: RE: [Sip] target set

HI
 
'target set' is a set of uris which the client sets to try incase it receives a 3xx response.
so to start with the client will have only one uri in the target set ile the target it intends to reach.
 
This sentance is quiet confusing. In the initial request what the UAC tries out is not the target set (there is only one URI). its the URI which UAC intends to reach out. the target set (contact addresses in 3xx response ) implies the URI's where the target user could be reached. these addresses can be contacted in either linear or parallel search technique.
 
now say it receives 3xx (300 Moved) response then it receives a new URI in the contact header. so it can place this URI in its target set and send the request to that URI.
 
so this way the target set grows.
 
-Ranjit
-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Gao Qing
Sent: Friday, January 24, 2003 3:20 PM
To: sip@ietf.org
Subject: [Sip] target set

Dear Sirs,

Who can explain me what exactly is "target set" in RFC3261? Is there a definition of it somewhere?

Thanks in advance!

Gao Qing

Regards,
-------------------------------------------
Nataraju A.B.
Huawei Technologies India Pvt. Ltd.,
Tel : +91-80-5217152 / 4 Xtn 142
-------------------------------------------
--Boundary_(ID_V+DIqRKwyKwlgcQRooJPqg)-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 24 08:37:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18917 for ; Fri, 24 Jan 2003 08:37:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0ODujP31774 for sip-archive@odin.ietf.org; Fri, 24 Jan 2003 08:56:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ODu3J31744; Fri, 24 Jan 2003 08:56:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ODrLJ31640 for ; Fri, 24 Jan 2003 08:53:21 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18846; Fri, 24 Jan 2003 08:33:48 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0ODbEAv005737; Fri, 24 Jan 2003 14:37:14 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id DLW0JNJ0; Fri, 24 Jan 2003 14:37:13 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.137]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h0ODbDH7001485; Fri, 24 Jan 2003 15:37:13 +0200 (EET) Message-ID: <3E31418B.D7DDE7D6@lmf.ericsson.se> Date: Fri, 24 Jan 2003 15:37:15 +0200 X-Sybari-Trust: 9ba71256 9ffcebbb c096fb41 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Conroy, Lawrence (SMTP)" CC: jh@lohi.eng.song.fi, Henning Schulzrinne , sip@ietf.org, iptel@ietf.org Subject: Re: [Iptel] Re: [Sip] TEL-URL local numbers References: <3E27EF16.B7312454@lmf.ericsson.se> <15911.63537.627963.460641@harjus.eng.song.fi> <3E27FF63.4030601@cs.columbia.edu> <15912.432.180748.674189@harjus.eng.song.fi> <3E28020E.4080805@cs.columbia.edu> <15912.984.540036.277317@harjus.eng.song.fi> <3E311F6C.AE17B814@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit H, > >>If I receive a tel URL containing a local number, without > >>and idea of the context *in the place that the URL was constructed* > >>then I don't know whether or not I'm in that context. > > > >[CHH] In this case you could reject it. If the sender didn't insert it, and > >there was no intermediate node inserting it, there is a network architecture > >problem. > > > >My point, I guess Juha's too, was not that there should not be a context when > >the URL reaches the UAS, but that it MAY be inserted by another node than the > >UAC. > > > > >I agree on that. However, my SIP phone may not know to which context they > >belong, for whatever reason, but the outbound proxy they communicate with DO > >know. > > To which I reply:: > > Aha! Thanks for the clarification - I'm being slow today. > This is a pure SIP issue - usage of tel URLs in SIP, and request > modification by intermediate nodes. Interesting issue. > > However, IMHO there are other uses for tel URLs, so I'd suggest that > draft-antti-rfc2916bis is correct in mandating this behaviour. > > If there's a separate draft for "SIP usage of tel URLs" that qualifies > the main tel URL RFC, relaxing the requirement, that's fine; I'm not sure > if it's a SIP or SIPPING job, but I think that's where it lives. > > I just don't want to nail this down in the general 2916 update. [CHH] 2916 doesn't have to say anything about SIP. 2916 can make the context optional, and "users" (eg SIP) and network architectures can then mandate the use of the context. There may also be other parameters, which are optional in 2916, but still are mandatory for specific users/architectures/applications. Another option, which you mentioned, is to write a separate "SIP usage of tel URL" draft (this is pretty much what has been done for SDP in H.248/Megaco), but I am not sure that is the best solution for this specific purpose. Have a nice weekend! Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 24 08:54:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19320 for ; Fri, 24 Jan 2003 08:54:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OEDil00542 for sip-archive@odin.ietf.org; Fri, 24 Jan 2003 09:13:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OEDQJ00497; Fri, 24 Jan 2003 09:13:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OEBRJ00436 for ; Fri, 24 Jan 2003 09:11:27 -0500 Received: from rsys001a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19247; Fri, 24 Jan 2003 08:51:55 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Jan 2003 13:55:22 -0000 Received: from percy.roke.co.uk ([193.118.192.111]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CN3C00RZ; Fri, 24 Jan 2003 13:55:21 -0000 From: "Conroy, Lawrence (SMTP)" To: Christer Holmberg Cc: jh@lohi.eng.song.fi, Henning Schulzrinne , sip@ietf.org, iptel@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <3E31418B.D7DDE7D6@lmf.ericsson.se> References: <3E27EF16.B7312454@lmf.ericsson.se> <15911.63537.627963.460641@harjus.eng.song.fi> <3E27FF63.4030601@cs.columbia.edu> <15912.432.180748.674189@harjus.eng.song.fi> <3E28020E.4080805@cs.columbia.edu> <15912.984.540036.277317@harjus.eng.song.fi> <3E311F6C.AE17B814@lmf.ericsson.se> <3E31418B.D7DDE7D6@lmf.ericsson.se> Date: Fri, 24 Jan 2003 13:55:17 +0000 Subject: Re: [Iptel] Re: [Sip] TEL-URL local numbers Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi folks, comments below - lwc - At 3:37 pm +0200 24/1/03, Christer Holmberg wrote: > > >> >I agree on that. However, my SIP phone may not know to which context they >> >belong, for whatever reason, but the outbound proxy they >>communicate with DO >> >know. >> >> To which I reply:: >> >> Aha! Thanks for the clarification - I'm being slow today. >> This is a pure SIP issue - usage of tel URLs in SIP, and request >> modification by intermediate nodes. Interesting issue. >> >> However, IMHO there are other uses for tel URLs, so I'd suggest that >> draft-antti-rfc2916bis is correct in mandating this behaviour. >> >> If there's a separate draft for "SIP usage of tel URLs" that qualifies >> the main tel URL RFC, relaxing the requirement, that's fine; I'm not sure >> if it's a SIP or SIPPING job, but I think that's where it lives. >> >> I just don't want to nail this down in the general 2916 update. > >[CHH] 2916 doesn't have to say anything about SIP. 2916 can make the context >optional, and "users" (eg SIP) and network architectures can then >mandate the use of >the context. There may also be other parameters, which are optional >in 2916, but >still are mandatory for specific users/architectures/applications. >Another option, which you mentioned, is to write a separate "SIP >usage of tel URL" >draft (this is pretty much what has been done for SDP in >H.248/Megaco), but I am not >sure that is the best solution for this specific purpose. > >Have a nice weekend! > - lwc - [BTW, folks, apologies for cross-posting - this seems to relevant both to SIP and IPTEL] A SIP proxy can have a mechanism to insert a context, so disambiguating the tel URL. So can other systems, I suspect. However... if there is no such mechanism, then the DEFAULT behaviour is to require a context as part of a "local number" tel URL (or bounce the URL). I think that this "default" should be in RFC2916bis, whilst the relaxation of the rule should be in the areas where there are mechanisms to avoid the potential mistakes. Otherwise we can have unsafe but standard-conforming implementations. My opinion only, but I need to be convinced. Nice weekend to one and all. Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 24 09:09:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19716 for ; Fri, 24 Jan 2003 09:09:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OESsm01237 for sip-archive@odin.ietf.org; Fri, 24 Jan 2003 09:28:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OESOJ01188; Fri, 24 Jan 2003 09:28:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OEQ4J01091 for ; Fri, 24 Jan 2003 09:26:04 -0500 Received: from hss.hns.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19658 for ; Fri, 24 Jan 2003 09:06:25 -0500 (EST) From: hbhondwe@hss.hns.com Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hss.hns.com (8.11.6/8.11.2) with SMTP id h0ODfga16415 for ; Fri, 24 Jan 2003 19:11:46 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256CB8.004D55E4 ; Fri, 24 Jan 2003 19:34:42 +0530 X-Lotus-FromDomain: HSSBLR To: sip@ietf.org Message-ID: <65256CB8.004D55AC.00@sampark.hss.hns.com> Date: Fri, 24 Jan 2003 19:34:41 +0530 Subject: RE: RE: [Sip] SIP and Congestion Safety Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, I'm assuming that it won't be possible , for various reasons, to deprecate UDP. Therefore even though it may not be possible to assure 100% congestion safety when UDP is used, some mechanisms such as those already presented in 2 existing drafts may be used to prevent congestion to some extent. Both the drafts(draft-khartabil-sip-congestionsafe-ci-01.txt and draft-ietf-sip-congestsafe-00) propose using a max-size header to indicate to the previous hop SIP entity the max size that it(the SIP entity sending the 403, 503 response) would allow on the next hop. Both the drats also assume that the proxies know the MTU of the next hop by some means. Its not very difficult to encounter the following problem in this mechanism: UA1--(MTU1)--P1--(MTU2)---P2--(MTU3)--P3--(MTU4)--P4--(MTU5)--P5--(MTU6)--U A2 MTU1>MTU2>MTU3>MTU4>MTU5>MTU6 In such a case it might take UA1, 6 attempts to finally get a request through to UA2. And since the MTU for a link is dynamic this could get even worse. Considering such a scenario, I was wondering if it might be a good idea to adopt a mechanism similar to the one used for the session timer, i.e allow proxies in the path to insert or update a min MTU similar to the way the session timer value is inserted/updated. Proxies need not reject requests that exceed the MTU of the next hop(hence avoiding the problem enumurated above). And like with session timer, the UA that initiated the request would get to know the min MTU for the complete path in the response, instead of having to converge on a value through trial and error. Comments? thanks Harsh hisham.khartabil@nokia.com on 01/22/2003 08:14:23 PM To: loretosa@vodafone.it, sip@ietf.org cc: (bcc: Harsh Bhondwe/HSSBLR) Subject: RE: RE: [Sip] SIP and Congestion Safety > -----Original Message----- > From: ext loretosa@vodafone.it [mailto:loretosa@vodafone.it] > Sent: Wednesday, January 22, 2003 10:31 AM > To: Khartabil Hisham (NMP/Helsinki); sip@ietf.org > Subject: Ri: RE: [Sip] SIP and Congestion Safety > > > > Hi Hisham, > > I've read your draft "draft-khartabil-sip-congestionsafe-ci-01.txt" > It's an interesting draft, but not cover all my questions. > > In any case about your draft i've some observations: > > in the section -5.0- > You write that the proxy affect for Congestion Safe in 3GPP > architecture is S-CSCF. > I think that P-CSCF is the most critical Proxy. > This one is the closest proxy to the UA. And in a Visited UA > scenario, I think that it's preferable, for an Operator 3G, > not forward information about his link capacity to another > Operator 3G. The document does say "the S-CSCF closest to the UA". I think the use of the word "home" confused you. > Morover I think that are also performance problem for which > P-CSCF have know information about Max-Size SIP message that > UAS can handle. Perhaps, but to my knowledge, S-CSCFs have the intelligence. P-CSCFs are nothing but outbound proxies to the sending UA. In any case, where 3GPP decides to put the intelligence is out of the scope of this document. The sentence you refer to is just an example (and perhaps should be removed). > > In the section 5.5. "Home Proxy Receiving 413 Response from UA" > What's advantage for a UA to reject a request, also if is a > large SIP request, when it's already received? When arrived > to UA, the large message already has congestioned the link. > > The main problem is avoided and prevent the congestion link. The solution is not just limited to the congestion of the network, it also tries to handle out-of-memory situations for a terminal, even when using TCP. If a terminal is receiving TCP packets for a sip message and knows it can't handle anymore packets, it can stop receiving and send 413 error response. Regards, Hisham > > > > > > Sal > > > > Please take a look at > > > > > http://www.ietf.org/internet-drafts/draft-khartabil-sip-conges > tionsafe-ci-01.txt > > > > I'm planning to update this to include a UA posting (eg: > contents for PUBLISH or MESSAGE). > > > > Regards, > > Hisham > > > > > -----Original Message----- > > > From: ext loretosa@vizzavi.it [mailto:loretosa@vizzavi.it] > > > Sent: Monday, January 20, 2003 7:55 PM > > > To: sip@ietf.org > > > Subject: [Sip] SIP and Congestion Safety > > > > > > > > > > > > Hi all, > > > > > > about SIP and Congetion Safety, i've observed there isn't a > > > great interest. > > > > > > I don't know why. > > > I think that will be a giant problem. > > > > > > And the mainly question for it is: what protocol use for > > > transport SIP signals ??? > > > > > > > > > others wg in IETF are working about congestion control > > > algorithms for real-time > > > or, more generally, delay sensitive applications... > > > see DCCP (Datagram Congestion Control Protocol - > > http://www.ietf.org/html.charters/dccp-charter.html). > > > > sometime ago there was a proposal about SCTP use for > Instant Messaging with SIP... > > > > in other mail i read a proposal about Connection Transport > Protocol as default protocol for SIP > > > > in the "Session Initiation Protocol Extension to Assure > Congestion Safety" draft-ietf-sip-congestsafe-00 > > there's only a proposal for define and check a > CONGESTION-SAFE hop... but it isn't enough > > > > > > Sal > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 > > > > Per registrarti gratuitamente a Vodafone Mail vai su www.190.it > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Fri Jan 24 10:34:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22622 for ; Fri, 24 Jan 2003 10:34:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OFrXN07524 for sip-archive@odin.ietf.org; Fri, 24 Jan 2003 10:53:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OFquJ07473; Fri, 24 Jan 2003 10:52:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OFo5J07325 for ; Fri, 24 Jan 2003 10:50:05 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22498; Fri, 24 Jan 2003 10:30:30 -0500 (EST) Received: from rshockeybox.shockey.us (inetgw.va.neustar.com [209.173.53.225]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id HAA19593; Fri, 24 Jan 2003 07:33:40 -0800 Message-Id: <5.2.0.9.2.20030124101540.015d6418@shockey.us> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 24 Jan 2003 10:21:25 -0500 To: "Conroy, Lawrence (SMTP)" From: Richard Shockey Subject: Re: [Iptel] Re: [Sip] TEL-URL local numbers Cc: sip@ietf.org, iptel@ietf.org In-Reply-To: References: <3E31418B.D7DDE7D6@lmf.ericsson.se> <3E27EF16.B7312454@lmf.ericsson.se> <15911.63537.627963.460641@harjus.eng.song.fi> <3E27FF63.4030601@cs.columbia.edu> <15912.432.180748.674189@harjus.eng.song.fi> <3E28020E.4080805@cs.columbia.edu> <15912.984.540036.277317@harjus.eng.song.fi> <3E311F6C.AE17B814@lmf.ericsson.se> <3E31418B.D7DDE7D6@lmf.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , >> >>[CHH] 2916 doesn't have to say anything about SIP. 2916 can make the context >>optional, and "users" (eg SIP) and network architectures can then mandate >>the use of >>the context. There may also be other parameters, which are optional in >>2916, but >>still are mandatory for specific users/architectures/applications. >>Another option, which you mentioned, is to write a separate "SIP usage of >>tel URL" >>draft (this is pretty much what has been done for SDP in H.248/Megaco), >>but I am not >>sure that is the best solution for this specific purpose. >> >>Have a nice weekend! Well some of this discussion might be relevant for the ENUM WG as well but I do not see any need for 2916 to have any information about context at all. This thread is somewhat confusing to me. What 2916 is explicit about is that is dealing with fully qualified e164 numbers only. You will have noticed that references or examples of partial e164 numbers have been removed from 2916bis 03. Queries to partial e164 numbers ( local numbers ) or private dialing plans are assumed not to be in the context of e164.arpa at all. UAC ore the relevant proxyshould be able to understand their context and reformulate the URL into the e164 number before any other action is taken. As some one else mentioned this is old stuff to most of us... as a old developer of outbound IVR systems we always had to have a local text configuration file. >- lwc - >[BTW, folks, apologies for cross-posting - this seems to relevant both to >SIP and IPTEL] > >A SIP proxy can have a mechanism to insert a context, so disambiguating the >tel URL. So can other systems, I suspect. >However... if there is no such mechanism, then the DEFAULT behaviour is to >require a context as part of a "local number" tel URL (or bounce the URL). > >I think that this "default" should be in RFC2916bis, whilst the relaxation >of the rule should be in the areas where there are mechanisms to avoid the >potential mistakes. Otherwise we can have unsafe but standard-conforming >implementations. My opinion only, but I need to be convinced. For my information are you suggesting that this behavior be documented in a enumservice field registration for the tel URL or as part of the overall use of ENUM in SIP. I dont see how documenting this in 2916bis is relevant..or am I missing something here > Nice weekend to one and all. > Lawrence >-- >----------------------------------------------------------------------- >Roke Manor Research : This information is provided "as is" and is not >: intended to create any contractual or legal > : relationship. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, 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 mailnull@www1.ietf.org Fri Jan 24 10:55:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23211 for ; Fri, 24 Jan 2003 10:55:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OGEhf09210 for sip-archive@odin.ietf.org; Fri, 24 Jan 2003 11:14:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OGENJ09167; Fri, 24 Jan 2003 11:14:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OGBOJ09009 for ; Fri, 24 Jan 2003 11:11:24 -0500 Received: from rsys001a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23104; Fri, 24 Jan 2003 10:51:49 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Jan 2003 15:55:16 -0000 Received: from percy.roke.co.uk ([193.118.192.111]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CN3C00YY; Fri, 24 Jan 2003 15:55:11 -0000 From: "Conroy, Lawrence (SMTP)" To: Richard Shockey Cc: sip@ietf.org, iptel@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <5.2.0.9.2.20030124101540.015d6418@shockey.us> References: <3E31418B.D7DDE7D6@lmf.ericsson.se> <3E27EF16.B7312454@lmf.ericsson.se> <15911.63537.627963.460641@harjus.eng.song.fi> <3E27FF63.4030601@cs.columbia.edu> <15912.432.180748.674189@harjus.eng.song.fi> <3E28020E.4080805@cs.columbia.edu> <15912.984.540036.277317@harjus.eng.song.fi> <3E311F6C.AE17B814@lmf.ericsson.se> <3E31418B.D7DDE7D6@lmf.ericsson.se> <5.2.0.9.2.20030124101540.015d6418@shockey.us> Date: Fri, 24 Jan 2003 15:55:09 +0000 Subject: Re: [Iptel] Re: [Sip] TEL-URL local numbers Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , At 10:21 am -0500 24/1/03, Richard Shockey wrote: > >Well some of this discussion might be relevant for the ENUM WG as >well but I do not see any need for 2916 to have any information >about context at all. This thread is somewhat confusing to me. To which I reply: Arghh!!!! My bad - for 2916bis in the thread, please read 2806bis. It's time for the weekend. That will teach me to respond to mailing lists during a teleconference - duh! Sorry for the confusion - we return you to your normal service. atb, Lawrence _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 24 11:55:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24734 for ; Fri, 24 Jan 2003 11:55:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OHEwK13753 for sip-archive@odin.ietf.org; Fri, 24 Jan 2003 12:14:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OHEQJ13714; Fri, 24 Jan 2003 12:14:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OH2DJ12282 for ; Fri, 24 Jan 2003 12:02:13 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24488 for ; Fri, 24 Jan 2003 11:42:31 -0500 (EST) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h0OGjFLc014451; Fri, 24 Jan 2003 10:45:15 -0600 Received: (from dwillis@localhost) by bdsl.greycouncil.com (8.12.5/8.12.5/Submit) id h0OGjEN9014449; Fri, 24 Jan 2003 10:45:15 -0600 X-Authentication-Warning: bdsl.greycouncil.com: dwillis set sender to dean.willis@softarmor.com using -f Subject: RE: RE: [Sip] SIP and Congestion Safety From: Dean Willis To: hbhondwe@hss.hns.com Cc: sip@ietf.org In-Reply-To: <65256CB8.004D55AC.00@sampark.hss.hns.com> References: <65256CB8.004D55AC.00@sampark.hss.hns.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1043426713.13899.45.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 24 Jan 2003 10:45:14 -0600 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Fri, 2003-01-24 at 08:04, hbhondwe@hss.hns.com wrote: > Both the drafts(draft-khartabil-sip-congestionsafe-ci-01.txt > and draft-ietf-sip-congestsafe-00) propose using a max-size > header to indicate to the previous hop SIP entity the max > size that it(the SIP entity sending the 403, 503 response) > would allow on the next hop. Both the drats also assume that > the proxies know the MTU of the next hop by some means. > > Its not very difficult to encounter the following problem > in this mechanism: > UA1--(MTU1)--P1--(MTU2)---P2--(MTU3)--P3--(MTU4)--P4--(MTU5)--P5--(MTU6)--U > A2 > > MTU1>MTU2>MTU3>MTU4>MTU5>MTU6 > > In such a case it might take UA1, 6 attempts to finally > get a request through to UA2. And since the MTU for a > link is dynamic this could get even worse. yep. Actually, it's worse than that, since as you point out it is possible for dynamic rerouting to occur. That makes the absolute worst case even more entertaining. Assuming that every reduction reduces the size of the message by 1 byte, then the worst case number of retries is given by the equation Size(Max) - Size(Min), where Max is the largest message ever sent, and Min is the smallest MTU allowed. Assuming common values of 1300 and 576, that gives us more than 700 retries before a message gets through. But at least it's deterministic. > Considering such a scenario, I was wondering if it might be > a good idea to adopt a mechanism similar to the one used > for the session timer, i.e allow proxies in the path to > insert or update a min MTU similar to the way the session > timer value is inserted/updated. Proxies need not reject > requests that exceed the MTU of the next hop(hence > avoiding the problem enumurated above). And like with > session timer, the UA that initiated the request would > get to know the min MTU for the complete path in the > response, instead of having to converge on a value > through trial and error. If I understand this, you're proposing that we complete one round-trip in order to establish a route size for future use within the dialog, and that we assume that the route does not vary over the course of the dialog. The main problem here -- what if the first request is 64kB long and blows up on the UDP network just past the first proxy? And of course, there's the problem of route dynamicity. Here's an alternative proposal. Rather than negotiating size, could we "just say no"? Any proxy that finds it cannot congestion-safely transmit a message simply kicks back a 5xx "cannot send safely" response, and it's up to the sender to find another route? -- 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 mailnull@www1.ietf.org Fri Jan 24 12:38:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26000 for ; Fri, 24 Jan 2003 12:38:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OHw1v16632 for sip-archive@odin.ietf.org; Fri, 24 Jan 2003 12:58:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OHveJ16602; Fri, 24 Jan 2003 12:57:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OHs0J16472 for ; Fri, 24 Jan 2003 12:54:00 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25891 for ; Fri, 24 Jan 2003 12:34:22 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0OHeCt25022 for ; Fri, 24 Jan 2003 19:40:12 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 24 Jan 2003 19:37:50 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 24 Jan 2003 19:37:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: RE: [Sip] SIP and Congestion Safety Date: Fri, 24 Jan 2003 19:37:48 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7192@esebe019.ntc.nokia.com> Thread-Topic: RE: [Sip] SIP and Congestion Safety Thread-Index: AcLDy0ckGw1ubyKGS7yqSYNHRfQpzQAA8Psw To: , Cc: X-OriginalArrivalTime: 24 Jan 2003 17:37:49.0913 (UTC) FILETIME=[50AFA490:01C2C3CF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0OHs0J16475 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, January 24, 2003 6:45 PM > To: hbhondwe@hss.hns.com > Cc: sip@ietf.org > Subject: RE: RE: [Sip] SIP and Congestion Safety > > > On Fri, 2003-01-24 at 08:04, hbhondwe@hss.hns.com wrote: > > Both the drafts(draft-khartabil-sip-congestionsafe-ci-01.txt > > and draft-ietf-sip-congestsafe-00) propose using a max-size > > header to indicate to the previous hop SIP entity the max > > size that it(the SIP entity sending the 403, 503 response) > > would allow on the next hop. Both the drats also assume that > > the proxies know the MTU of the next hop by some means. > > > > Its not very difficult to encounter the following problem > > in this mechanism: > > > UA1--(MTU1)--P1--(MTU2)---P2--(MTU3)--P3--(MTU4)--P4--(MTU5)-- > P5--(MTU6)--U > > A2 > > > > MTU1>MTU2>MTU3>MTU4>MTU5>MTU6 > > > > In such a case it might take UA1, 6 attempts to finally > > get a request through to UA2. And since the MTU for a > > link is dynamic this could get even worse. > > yep. Actually, it's worse than that, since as you point out it is > possible for dynamic rerouting to occur. That makes the > absolute worst > case even more entertaining. Assuming that every reduction reduces the > size of the message by 1 byte, then the worst case number of > retries is > given by the equation Size(Max) - Size(Min), where Max is the largest > message ever sent, and Min is the smallest MTU allowed. > Assuming common > values of 1300 and 576, that gives us more than 700 retries before a > message gets through. But at least it's deterministic. I believe the drafts do say the max MTU en route to the UAS. How that en route is discovered is outside the scope of sip, IMO. > > > > Considering such a scenario, I was wondering if it might be > > a good idea to adopt a mechanism similar to the one used > > for the session timer, i.e allow proxies in the path to > > insert or update a min MTU similar to the way the session > > timer value is inserted/updated. Proxies need not reject > > requests that exceed the MTU of the next hop(hence > > avoiding the problem enumurated above). And like with > > session timer, the UA that initiated the request would > > get to know the min MTU for the complete path in the > > response, instead of having to converge on a value > > through trial and error. > > > If I understand this, you're proposing that we complete one round-trip > in order to establish a route size for future use within the > dialog, and > that we assume that the route does not vary over the course of the > dialog. > > The main problem here -- what if the first request is 64kB long and > blows up on the UDP network just past the first proxy? > > And of course, there's the problem of route dynamicity. > > Here's an alternative proposal. Rather than negotiating size, could we > "just say no"? > > Any proxy that finds it cannot congestion-safely transmit a message > simply kicks back a 5xx "cannot send safely" response, and it's up to > the sender to find another route? What's wrong with content indirection? /Hisham > > -- > 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 mailnull@www1.ietf.org Fri Jan 24 13:41:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28241 for ; Fri, 24 Jan 2003 13:41:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OJ0Lw20678 for sip-archive@odin.ietf.org; Fri, 24 Jan 2003 14:00:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OIxxJ20587; Fri, 24 Jan 2003 13:59:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OIuSJ20406 for ; Fri, 24 Jan 2003 13:56:28 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28019; Fri, 24 Jan 2003 13:36:50 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0OIeHKV007933; Fri, 24 Jan 2003 19:40:17 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNPAYHW; Fri, 24 Jan 2003 19:40:17 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h0OIeHH7017620; Fri, 24 Jan 2003 20:40:17 +0200 (EET) Message-ID: <3E3188A1.DEB044D9@lmf.ericsson.se> Date: Fri, 24 Jan 2003 20:40:33 +0200 X-Sybari-Trust: f3d8f3b5 9ffcebbb c096fb41 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Richard Shockey CC: "Conroy, Lawrence (SMTP)" , sip@ietf.org, iptel@ietf.org Subject: Re: [Iptel] Re: [Sip] TEL-URL local numbers References: <3E31418B.D7DDE7D6@lmf.ericsson.se> <3E27EF16.B7312454@lmf.ericsson.se> <15911.63537.627963.460641@harjus.eng.song.fi> <3E27FF63.4030601@cs.columbia.edu> <15912.432.180748.674189@harjus.eng.song.fi> <3E28020E.4080805@cs.columbia.edu> <15912.984.540036.277317@harjus.eng.song.fi> <3E311F6C.AE17B814@lmf.ericsson.se> <3E31418B.D7DDE7D6@lmf.ericsson.se> <5.2.0.9.2.20030124101540.015d6418@shockey.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, > >>[CHH] 2916 doesn't have to say anything about SIP. 2916 can make the >>context > optional, and "users" (eg SIP) and network architectures can then >>mandate the > use of > >>the context. There may also be other parameters, which are optional in > >>2916, but > >>still are mandatory for specific users/architectures/applications. > >>Another option, which you mentioned, is to write a separate "SIP usage of > >>tel URL" > >>draft (this is pretty much what has been done for SDP in H.248/Megaco), > >>but I am not > >>sure that is the best solution for this specific purpose. > >> > >>Have a nice weekend! > > Well some of this discussion might be relevant for the ENUM WG as well but > I do not see any need for 2916 to have any information about context at > all. This thread is somewhat confusing to me. [CHH] I was actually thinking about that. If I have a E.164 number, do an ENUM DNS lookup, and receive a TEL-URL with a local number in the lookup answer, shall that TEL-URL contain the context, or shall my node add it? > What 2916 is explicit about is that is dealing with fully qualified e164 > numbers only. You will have noticed that references or examples of partial > e164 numbers have been removed from 2916bis 03. Queries to partial e164 > numbers ( local numbers ) or private dialing plans are assumed not to be in > the context of e164.arpa at all. [CHH] So, possible TEL-URL(s) received in the ENUM lookup MUST be in international format? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 24 13:47:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28396 for ; Fri, 24 Jan 2003 13:47:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OJ6ZU20970 for sip-archive@odin.ietf.org; Fri, 24 Jan 2003 14:06:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OJ6BJ20951; Fri, 24 Jan 2003 14:06:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OJ0LJ20692 for ; Fri, 24 Jan 2003 14:00:21 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28228 for ; Fri, 24 Jan 2003 13:40:44 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0OIiAKV008288; Fri, 24 Jan 2003 19:44:11 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id DLW0LP0C; Fri, 24 Jan 2003 19:44:10 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h0OIiBH7017675; Fri, 24 Jan 2003 20:44:11 +0200 (EET) Message-ID: <3E31898B.AEE3A4F8@lmf.ericsson.se> Date: Fri, 24 Jan 2003 20:44:27 +0200 X-Sybari-Trust: 1d23b5dd 9ffcebbb c096fb41 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: brett@broadsoft.com CC: sip@ietf.org Subject: Re: [Sip] Via maddr References: <003601c2bcdc$a61d99e0$2b01a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Any comments on this? Regards, Christer Holmberg Ericsson Finland Brett Tate wrote: > > I appologise if this has been discussed > > before, but at least I didn't find it in > > my mail box (I admit I didn't check the > > archieve on the web). > > I posted a related question to sip-implementors; > however I never got a reply. > > http://lists.cs.columbia.edu/pipermail/sip-implementors/2002-October/004052. > html > > > Chapter 18.2.2 in RFC3261 talks about the > > routing of responses, using the Via maddr, > > received and sent-by parameters. > > > > My question is regarding maddr. When reading > > the text, I get the picture that only > > IP addresses are used in maddr. At least the > > text doesn't mention the SRV RFC, which it does > > for sent-by, and it says that the default port > > is 5060. However, the ABNF defines maddr as > > "host", which can also be a domain name. > > maddr can be a domain name. The text appears > to disable the ability to perform an SRV query > associated with the Via maddr. However I never > got an answer concerning if this was intentional. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 24 14:12:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29145 for ; Fri, 24 Jan 2003 14:12:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OJVqd22646 for sip-archive@odin.ietf.org; Fri, 24 Jan 2003 14:31:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OJVOJ22631; Fri, 24 Jan 2003 14:31:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OJSqJ22468 for ; Fri, 24 Jan 2003 14:28:52 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29067; Fri, 24 Jan 2003 14:09:13 -0500 (EST) Received: from rshockeybox.shockey.us (inetgw.va.neustar.com [209.173.53.225]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id LAA30754; Fri, 24 Jan 2003 11:12:20 -0800 Message-Id: <5.2.0.9.2.20030124140417.022abff0@shockey.us> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 24 Jan 2003 14:14:36 -0500 To: Christer Holmberg From: Richard Shockey Subject: Re: [Iptel] Re: [Sip] TEL-URL local numbers Cc: "Conroy, Lawrence (SMTP)" , sip@ietf.org, iptel@ietf.org In-Reply-To: <3E3188A1.DEB044D9@lmf.ericsson.se> References: <3E31418B.D7DDE7D6@lmf.ericsson.se> <3E27EF16.B7312454@lmf.ericsson.se> <15911.63537.627963.460641@harjus.eng.song.fi> <3E27FF63.4030601@cs.columbia.edu> <15912.432.180748.674189@harjus.eng.song.fi> <3E28020E.4080805@cs.columbia.edu> <15912.984.540036.277317@harjus.eng.song.fi> <3E311F6C.AE17B814@lmf.ericsson.se> <3E31418B.D7DDE7D6@lmf.ericsson.se> <5.2.0.9.2.20030124101540.015d6418@shockey.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > > > > > Well some of this discussion might be relevant for the ENUM WG as well but > > I do not see any need for 2916 to have any information about context at > > all. This thread is somewhat confusing to me. > >[CHH] I was actually thinking about that. If I have a E.164 number, do an >ENUM DNS >lookup, and receive a TEL-URL with a local number in the lookup answer, >shall that >TEL-URL contain the context, or shall my node add it? why would ENUM return a local number is my question? What is the application scenario you have in mind .. For Instance the presumption is that you would have a return of URL' one sip maybe one tel this is the old call forwarding application ..if you cannot reach sip: then try tel: easy to do with the modification of the preference field..then certainly the tel should be a FQe164. > > What 2916 is explicit about is that is dealing with fully qualified e164 > > numbers only. You will have noticed that references or examples of partial > > e164 numbers have been removed from 2916bis 03. Queries to partial e164 > > numbers ( local numbers ) or private dialing plans are assumed not to be in > > the context of e164.arpa at all. > >[CHH] So, possible TEL-URL(s) received in the ENUM lookup MUST be in >international >format? Thats certainly what I would recommend and that has always been the parameters of 2916 no partial e164 numbers . but you could point to a private dialing plan as in a domain other than e164.arpa. In fact you can create any terminal or non terminal redirection you want if you write up a RFC describing it using the procedure in 2916bis >Regards, > >Christer Holmberg >Ericsson Finland >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, 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 mailnull@www1.ietf.org Fri Jan 24 16:52:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03503 for ; Fri, 24 Jan 2003 16:52:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OMBrl00728 for sip-archive@odin.ietf.org; Fri, 24 Jan 2003 17:11:53 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OM9hJ00661; Fri, 24 Jan 2003 17:09:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OM6PJ32403 for ; Fri, 24 Jan 2003 17:06:25 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03398 for ; Fri, 24 Jan 2003 16:46:42 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.40]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0OLo8YH008293; Fri, 24 Jan 2003 16:50:12 -0500 (EST) Message-ID: <3E31B509.90900@dynamicsoft.com> Date: Fri, 24 Jan 2003 16:50:01 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Prasanna Venkatesh CC: Idnani Ajaykumar-AIDNANI1 , sip@ietf.org Subject: Re: [Sip] Question about Redirect Server References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This answer is not accurate. Servers always use the request URI in determining next hops, looking up in registration databases, and so on. The To and request-uri can be divergent at the very first hop due to security concerns, for example. Furthermore, a server can only perform a location database lookup on the request uri if it is authoritatively responsible for the domain in the request uri. -Jonathan R. Prasanna Venkatesh wrote: > Hi, > As per the RFC-3261 on the first hop it is expected that the To and the > Request-URI are same. In this case your query does not have any problem. > If some intermediate proxy has changed the request-URI then, the request-uri > being the latest should be used to search the registrar. However it depends > on the design of the registry database also. > If the database caters only to one domain, then just the user part of the > request-uri is taken and the address can be resolved. > If the database caters to more than one domain, and if by chance the host > part of the request-uri is an IP then, the host part of the To along with > the user part of the request-uri is taken as the key. > Cheers, > Prasanna > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Idnani > Ajaykumar-AIDNANI1 > Sent: Tuesday, January 14, 2003 8:23 PM > To: sip@ietf.org > Subject: [Sip] Question about Redirect Server > > > Hi All, > > I have a very simple question about the operation of Redirect Servers. Me > and colleague out here can not seem to convince each other on this, so I > thought I will email all the SIP experts here J. > > When a Redirect Server gets a request, it is supposed to return back the > Contacts for the called party. Where does it pick the address of the called > party from. Is it the To address or the Request-URI? The assumption here is > that the Redirect Server is co-located with the Registrar, and has access to > the database of the Registrar. When the Redirect Server is searching within > this database, what does it use as the key for searching - To Address or the > Request-URI. > > Appreciate your help. > > Thanks and Regards > - Ajay > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 24 17:02:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03710 for ; Fri, 24 Jan 2003 17:02:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OMM8s01081 for sip-archive@odin.ietf.org; Fri, 24 Jan 2003 17:22:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OMLdJ01040; Fri, 24 Jan 2003 17:21:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OMIlJ00896 for ; Fri, 24 Jan 2003 17:18:47 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03598 for ; Fri, 24 Jan 2003 16:59:04 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.40]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0OM2YYH008336; Fri, 24 Jan 2003 17:02:35 -0500 (EST) Message-ID: <3E31B7F3.9000001@dynamicsoft.com> Date: Fri, 24 Jan 2003 17:02:27 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christer Holmberg CC: brett@broadsoft.com, sip@ietf.org Subject: Re: [Sip] Via maddr References: <003601c2bcdc$a61d99e0$2b01a8c0@broadsoft.com> <3E31898B.AEE3A4F8@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The intent of 18.2.2 is indeed NOT to use the SRV processing. In fact, if you look at 18.1, the only way that the maddr gets set is through multicast, and thus the intent is that maddr is really for multicast. THis need not be an IP address, since DNS names can refer to multicast addresses (sip.mcast.net). Originally, the maddr in the URI was the same - meant just for multicast. However, in the absence of a suitable loose routing mechanism, it got continually abused until the common case was for that, and not for multicast at all. Doing that properly required SRV processing. Now, we have thankfully deprecated the usage of maddr for that purpose, but older rfc2543 elements might construct such URIs, and so RFC3263 continues to perform the SRV processing for the maddr in the request URI, when present. Thus the asymetry. -Jonathan R. Christer Holmberg wrote: > Any comments on this? > > Regards, > > Christer Holmberg > Ericsson Finland > > Brett Tate wrote: > > >>>I appologise if this has been discussed >>>before, but at least I didn't find it in >>>my mail box (I admit I didn't check the >>>archieve on the web). >> >>I posted a related question to sip-implementors; >>however I never got a reply. >> >>http://lists.cs.columbia.edu/pipermail/sip-implementors/2002-October/004052. >>html >> >> >>>Chapter 18.2.2 in RFC3261 talks about the >>>routing of responses, using the Via maddr, >>>received and sent-by parameters. >>> >>>My question is regarding maddr. When reading >>>the text, I get the picture that only >>>IP addresses are used in maddr. At least the >>>text doesn't mention the SRV RFC, which it does >>>for sent-by, and it says that the default port >>>is 5060. However, the ABNF defines maddr as >>>"host", which can also be a domain name. >> >>maddr can be a domain name. The text appears >>to disable the ability to perform an SRV query >>associated with the Via maddr. However I never >>got an answer concerning if this was intentional. >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 24 17:12:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03886 for ; Fri, 24 Jan 2003 17:12:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OMVZp01412 for sip-archive@odin.ietf.org; Fri, 24 Jan 2003 17:31:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OMVBJ01399; Fri, 24 Jan 2003 17:31:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OMSHJ01274 for ; Fri, 24 Jan 2003 17:28:17 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03813 for ; Fri, 24 Jan 2003 17:08:34 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.40]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0OMBxYH008349; Fri, 24 Jan 2003 17:11:59 -0500 (EST) Message-ID: <3E31BA28.8010903@dynamicsoft.com> Date: Fri, 24 Jan 2003 17:11:52 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Nataraju A.B.(huawei)" CC: ranjit.avasarala@bplmail.com, Gao Qing , sip@ietf.org Subject: Re: [Sip] target set References: <001701c2c3a5$a65f9fa0$5d02120a@in.huawei.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The target set is a set of URIs, used by proxies or UAC, which represent a set of destinations that are to be tried. A proxy creates such a set by contacting location services, but it can be changed by many factors through the duration of a transaction, such as a redirect response. A UAC creates a target set when it is redirected to multipicity of contacts. -Jonathan R. Nataraju A.B.(huawei) wrote: > > ----- Original Message ----- > *From:* Ranjit Kumar Avasarala > *To:* Gao Qing ; sip@ietf.org > > *Sent:* Friday, January 24, 2003 5-06 > *Subject:* RE: [Sip] target set > > HI > > 'target set' is a set of uris which the client sets to try incase it > receives a 3xx response. > so to start with the client will have only one uri in the target set > ile the target it intends to reach. > > This sentance is quiet confusing. In the initial request what the > UAC tries out is not the target set (there is only one URI). its the > URI which UAC intends to reach out. the target set (contact > addresses in 3xx response ) implies the URI's where the target user > could be reached. these addresses can be contacted in either linear > or parallel search technique. > > now say it receives 3xx (300 Moved) response then it receives a new > URI in the contact header. so it can place this URI in its target > set and send the request to that URI. > > so this way the target set grows. > > -Ranjit > > -----Original Message----- > *From:* sip-admin@ietf.org [mailto:sip-admin@ietf.org]*On Behalf > Of *Gao Qing > *Sent:* Friday, January 24, 2003 3:20 PM > *To:* sip@ietf.org > *Subject:* [Sip] target set > > Dear Sirs, > > Who can explain me what exactly is "target set" in RFC3261? Is > there a definition of it somewhere? > > Thanks in advance! > > Gao Qing > > Regards, > ------------------------------------------- > Nataraju A.B. > Huawei Technologies India Pvt. Ltd., > Tel : +91-80-5217152 / 4 Xtn 142 > ------------------------------------------- > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 24 17:26:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04159 for ; Fri, 24 Jan 2003 17:26:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OMjYf02576 for sip-archive@odin.ietf.org; Fri, 24 Jan 2003 17:45:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OMjFJ02569; Fri, 24 Jan 2003 17:45:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OMgOJ02459 for ; Fri, 24 Jan 2003 17:42:24 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04105 for ; Fri, 24 Jan 2003 17:22:41 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.40]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0OMQCYH008353; Fri, 24 Jan 2003 17:26:12 -0500 (EST) Message-ID: <3E31BD7D.7000901@dynamicsoft.com> Date: Fri, 24 Jan 2003 17:26:05 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jean-luc.bouthemy@nokia.com CC: jh@lohi.eng.song.fi, sip@ietf.org Subject: Re: [Sip] any restrictions on characters in user part of sip uri? References: <8F698F0DD0B49A48BDA9F451A7A68CAE019E6764@daebe001.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Well, the spec is currently quiet on this point. According to rfc2396, definitions of URI schemes are supposed to define the character set that is used to map from the octet sequence to the original character sequence. SIP doesn't say what this is. It ought to, though, and clearly UTF-8 is the appropriate choice. That would allow you to escape-encode Japanese characters, for example. This has been logged in bugzilla for some time: http://www.sipwg.org/sipwg/show_bug.cgi?id=678 Concerning Juha's example, UTF-8 has the property that 00 never occurs in a UTF-8 sequence except to represent NULL, so you shuoldn't be seeing it except in the "normal" US-ASCII way. -Jonathan R. jean-luc.bouthemy@nokia.com wrote: > Juha and all: > > Comment: > > What about using escaped is %hexhex for support to unicode which can > be used for languages such as Japanese. > > Regards > > -- Jean-Luc -----Original Message----- From: ext jh@lohi.eng.song.fi > [mailto:jh@lohi.eng.song.fi] Sent: Friday, January 17, 2003 5:29 AM > To: sip@ietf.org Subject: [Sip] any restrictions on characters in > user part of sip uri? > > > the syntax of user part of sip uri is: > > user = 1*( unreserved / escaped / user-unreserved ) user-unreserved = > "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" > > escaped is %hexhex and can thus be used to include any character in > user. is it really so that there is no restrictions on what chars > may be include in user using escaped? for example, is %0000 valid in > user? if so, it makes implementations "interesting". > > -- juha > > _______________________________________________ Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip This list is for NEW > development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip This list is for NEW > development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 24 22:41:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09299 for ; Fri, 24 Jan 2003 22:41:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0P40fw19038 for sip-archive@odin.ietf.org; Fri, 24 Jan 2003 23:00:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P407J19020; Fri, 24 Jan 2003 23:00:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P3uaJ18922 for ; Fri, 24 Jan 2003 22:56:36 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09206 for ; Fri, 24 Jan 2003 22:36:46 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.40]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0P3eBYH008494; Fri, 24 Jan 2003 22:40:11 -0500 (EST) Message-ID: <3E320717.9050808@dynamicsoft.com> Date: Fri, 24 Jan 2003 22:40:07 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Frank W. Miller" CC: "Poetzl, Joachim" , sip@ietf.org Subject: Re: [Sip] Re: Comments: I-D ACTION:draft-miller-sip-tcap-00.txt : Reposting References: <53CD1252F68ED61183F5000347AE5F550120425E@G8PPZ.blf01.telekom.de> <002201c2be3a$5cef9160$9f00000a@overhill> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit You won't be surprised to hear me say that I think this is an entirely inappropriate use of SIP, whether you use the INFO method or not. There is nothing in your usage that derives any benefit from SIP. There are no sessions, no calls, no nothing. You are merely using an INFO method as a way to send data from A to B. TCAP is closer to an RPC protocol than anything else, and SIP is certainly NOT an RPC protocol. Tunneling ISUP over SIP (SIP-T) does make a lot of sense, since ISUP, functionally, is very close to SIP. We are therefore able to use SIP semantics for the exchange, and augment the flows with additional data (the tunneled ISUP message) that provides information of interest to gateways. The key to the utility of SIP-T is that its still SIP. If you want an XML encoding of TCAP, I have no beef with that concept, but its not SIP. Have you considered SOAP? SOAP over HTTP seems a much better match. -Jonathan R. Frank W. Miller wrote: > Thanks for the questions! > > Comments inline. > > > >>For the transport of SS7-signalling information the SIGTRAN protocols have > > been especially defined by the SIGTRAN > >>working group of the IETF. In this scenario SUA over SCTP could transport > > the TCAP information. For the time being PSTNs still exist and in converged > scenarios we should use the same straight forward approach defined by the > SIGTRAN group for each SS7 user part - why special treatment for TCAP???. > > > We have a similar mechanism for the ISUP maintenance commands. An early > version of that draft is on the IETF site and a major update that changes > the INFO body contents to an XML representation will be released within > days. TCAP is not special in this regard. IMHO, ISUP and TCAP are the best > place to do translations because the "semantic level" appears to me to be > the closest to where SIP session semantic level is. These two works are > designed to augment the basic SIP-ISUP translation draft to include the > ability to control PSTN access trunks (e.g. PRI's and IMTs on T-1s) from the > PSTN and to do service delivery from existing PSTN elements (i.e. SCPs) to > SIP endpoints, both without having to implement SS7 protocol stacks in the > SIP elements. The goal is make sharper the demarcation between SIP and SS7. > This is primarily a cost argument. SS7 stacks are more expensive in the > marketplace than SIP stacks, so limiting the number of SS7 deployments saves > costs for the carriers. > > > >>Why defining another approach when everythhing neccesary is already > > defined. Or are there doubts about the maturity in the SIGTRAN protocols? > > > No, SIGTRAN is very mature and very useful for certain applications. This > is just a different approach. I see no reason why tunneling and translation > approaches cannot coexist in IETF standards. Both have their applications. > > > >>Some questions on the proposed solution: >>-- How is adressing beeing resolved? > > > One of the nice things about translation is that it limits addressing > problems to the mapping of addresses. You can do about anything you want on > the SIP side as long as the mappings at the SIP UA and the GW are handled > appropriately. Addressing is certainly an area that is ripe for discussion > in any standardization activity. > > > >>-- TCAP dialoges are mainly used for call unrelated signalling, means no > > dialog exists. But one has to have an open SIP-Dialog before exchanging > Info-Messages. How is that going to be resolved? > > The element with the UA maintains a persistent session with the GW for TCAP > interactions. I believe this is discussed in the draft. > > > >>-- For what kind of services this should be used? Is this solution > > anticipated for call completion services instead of usage of > subscribe/notify? > > > There are several service examples detailed in the draft. Calling Name > Delivery is the one that leaps to mind. > > FM > > > Frank W. Miller, Ph.D. > Chief Technical Officer > sentitO Network, Inc. > fmiller@sentito.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 > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Sat Jan 25 01:11:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11006 for ; Sat, 25 Jan 2003 01:11:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0P6URt26010 for sip-archive@odin.ietf.org; Sat, 25 Jan 2003 01:30:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P6HOJ25769; Sat, 25 Jan 2003 01:17:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P5tdJ24790 for ; Sat, 25 Jan 2003 00:55:39 -0500 Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10779 for ; Sat, 25 Jan 2003 00:35:42 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.40]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0P5XQYH008516; Sat, 25 Jan 2003 00:33:27 -0500 (EST) Message-ID: <3E3221A3.3050403@dynamicsoft.com> Date: Sat, 25 Jan 2003 00:33:23 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Christer Holmberg , Dean Willis , sip@ietf.org Subject: Re: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 References: <003301c2bb73$b6528650$fe0c0c42@txdwillis> <3E243454.3B30B59F@lmf.ericsson.se> <3E24398F.8090205@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The point I have been trying to make all along here is similar to what Henning is saying. Everything in this draft can also be done with the Allow mechanism, and then you use the method registry for "usages". Now, Dean has argued that this is somehow fundamentally different due to some perceived software layering problem in implementations, but functionally speaking, its the same. THis is what I mean when I have been saying "INFO has no semantics, whereas rfc3265 does". There is protocol functionality provided by SUB/NOT, independent of any package, and above rfc3261, which makes it useful. Not so here. -Jonathan R. Henning Schulzrinne wrote: >> To negotiate what INFO can be used for between nodes is good thing, >> and at least >> on a theoretical level it solves one issue. > > > It would be nice to motivate how this differs and intersects with the > Content-* indication and negotiation mechanism. After all, if INFO > transports objects that are opaque to the "SIP layer" (e.g., session > state), the logical indication of use is via the various Content-* > indications. > >> >> But, is the biggest problem we have today end-nodes receiving INFOs >> with data >> they don't know to handle? And, how is this going to solve the problem >> of having >> people using INFO for whatever purpose? All they have to do is to >> define a >> package for their who-knows-what data, right? Or, does defining a >> package allow >> one to use INFO for whatever he/she wants? > > > Beyond ISUP and maybe DTMF, what is INFO used for today, by both the > good and bad guys? What proposals are out there? Last time this was > discussed, the list seemed pretty short. I think we agree that DTMF has > better, non-INFO solutions. > > With events, we have a whole set of examples and applications to draw > on. Building a mechanism on an example space of one seems a bit dangerous. > >> >> Or, do we accept Henning's rule about the "bad guys", and do NOT try >> to define >> any rules on exactly what kind of data INFO should be used for in the >> first >> place? > > > I do think it would be helpful if this draft or some other draft > indicated where SIP INFO *may* be appropriate. As discussed, this seems > to involve things where SIP routing and proxies are needed or useful, > for example. > >> >> I am not saying that this draft should solve anything, but I would >> like to know >> exactly which issues regarding INFO we are going to try solving :) >> >> Regards, >> >> Christer Holmberg >> Ericsson Finland >> >> >> >> >> >> Dean Willis wrote: >> >> >>> It only seemed appropriate to follow up my previous assumably >>> eloquent but >>> frequently misspelled exhortations by following my own advice and >>> "sending >>> text". >>> >>> The resulting draft has been submitted to the archive and should be >>> announced in due course. In the interim, you may wish to retrieve it >>> from: >>> >>> http://www.softarmor.com/sipwg/drafts/draft-willis-sip-infopackage-00.html >>> >>> >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Sat Jan 25 01:36:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11184 for ; Sat, 25 Jan 2003 01:36:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0P6twe27129 for sip-archive@odin.ietf.org; Sat, 25 Jan 2003 01:55:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P6d1J26797; Sat, 25 Jan 2003 01:39:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P68nJ25652 for ; Sat, 25 Jan 2003 01:08:50 -0500 Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10848 for ; Sat, 25 Jan 2003 00:48:44 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.40]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0P5n7YH008520 for ; Sat, 25 Jan 2003 00:49:07 -0500 (EST) Message-ID: <3E32254F.6050605@dynamicsoft.com> Date: Sat, 25 Jan 2003 00:49:03 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] trimming "implicit preferences for media and priority" from caller prefs Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I have been working on yet-another revision of caller preferences, in my continuing attempts to get this thing finished. Just when I thought it was done, and all the changes were happily applied, I ran into another issue. Grr. The issue is an interaction between the implicit preferences mechanism in the draft, and the desire to reach a user wherever they are. Anyway, let me explain the problem by an example. Lets say I send an INVITE with audio and video in the SDP. The called party has two devices, a PC w/ audio and video, and a cell phone with audio. They are not at their PC right now, but are available by cell. The desired behavior, and the intent of the caller (since they did not specify a preference), is that the call would reach both devices and ring both, and the user answers at the cell phone with audio only. However, the implicit preferences will cause the PC to ring first (because its a better match to the "implicit preference" to have video), and then the cell phone. THis will increase call setup time and worsen the user experience. This problem is a specific case of a more genreal issue, which is that the implicit caller preferences mechanism is at odds with the proposed fix to HERFP (see http://www.jdrosen.net/papers/draft-rosenberg-sip-unify-00.txt if you forget what HERFP is). They cannot co-exist. The whole idea with the HERFP fix is to let the request go everywhere it can, since the called party could be at any one of the devices. But, the caller prefs implicit preferences would prioritize and select only the matching devices. The called party may not be at that device, though. The essence of the problem, I think, is that there is no such thing as implicit preferences. Just because I list audio and video in my SDP, does not mean I want the call to be routed to a device which supports those. It just means that those are the media types I want to try to use for this call. Generally, danger lurks wherever the network tries to assume something about caller intent, when it should not have assumed it. So, my proposed solution is to remove the implicit preferences computation for media types, and also for priority (sections 7.2.2.1 and 7.2.2.4 of caller prefs -07). The priority one is good to remove since we were never sure it was right to begin with. That would leave implicit preferences computations ONLY for methods, languages and event packages. There are issues there too, but of a somewhat different sort, which I will post in a separate note. So, unless someone screams really soon, consider those two features removed. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Sun Jan 26 12:35:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19978 for ; Sun, 26 Jan 2003 12:35:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0QHt4u14673 for sip-archive@odin.ietf.org; Sun, 26 Jan 2003 12:55:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0QHsOJ14651; Sun, 26 Jan 2003 12:54:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0QHkLJ14461 for ; Sun, 26 Jan 2003 12:46:21 -0500 Received: from face.sentitonetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19898 for ; Sun, 26 Jan 2003 12:25:46 -0500 (EST) Received: (qmail 58281 invoked from network); 26 Jan 2003 17:29:16 -0000 Received: from unknown (HELO overhill) (10.0.0.159) by face.sentito.com with SMTP; 26 Jan 2003 17:29:16 -0000 Message-ID: <003701c2c560$72ff9540$9f00000a@overhill> From: "Frank W. Miller" To: "Jonathan Rosenberg" Cc: References: <53CD1252F68ED61183F5000347AE5F550120425E@G8PPZ.blf01.telekom.de> <002201c2be3a$5cef9160$9f00000a@overhill> <3E320717.9050808@dynamicsoft.com> Subject: Re: [Sip] Re: Comments: I-D ACTION:draft-miller-sip-tcap-00.txt : Reposting Date: Sun, 26 Jan 2003 12:29:15 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thanks Jonathan for the response. Your reaction is indeed expected. I would make only two comments on your response. First, I do not agree with your unequivocal statement that TCAP has nothing to do with a session. There are several applications of TCAP (CNAME and LNP come to mind) where there is clearly at least a fledgling session in progress when TCAP is required. Second, I've tried to get across to other responders that there is a practical issue that is very important here, that being cost. Current PSTN protocol implementations are very expensive to implement. By this, I mean that the cost of protocol stacks must be passed onto the end customer in some form. I believe that this is at least in part due to the fact that these protocols are "closed" when compared with SIP. The cost-effectiveness of SIP yields a desire to limit the use of the PSTN protocol implementations in order to minimize the cost of the equipment into which they are built. This is why tunneling can be problematic, it requires at least some part of these protocol stacks to be in place on a larger base of equipment. FM Frank W. Miller, Ph.D. Chief Technical Officer sentitO Network, Inc. fmiller@sentito.com ----- Original Message ----- From: "Jonathan Rosenberg" To: "Frank W. Miller" Cc: "Poetzl, Joachim" ; Sent: Friday, January 24, 2003 10:40 PM Subject: Re: [Sip] Re: Comments: I-D ACTION:draft-miller-sip-tcap-00.txt : Reposting > You won't be surprised to hear me say that I think this is an entirely > inappropriate use of SIP, whether you use the INFO method or not. > > There is nothing in your usage that derives any benefit from SIP. There > are no sessions, no calls, no nothing. You are merely using an INFO > method as a way to send data from A to B. TCAP is closer to an RPC > protocol than anything else, and SIP is certainly NOT an RPC protocol. > > Tunneling ISUP over SIP (SIP-T) does make a lot of sense, since ISUP, > functionally, is very close to SIP. We are therefore able to use SIP > semantics for the exchange, and augment the flows with additional data > (the tunneled ISUP message) that provides information of interest to > gateways. The key to the utility of SIP-T is that its still 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 mailnull@www1.ietf.org Sun Jan 26 14:20:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20838 for ; Sun, 26 Jan 2003 14:20:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0QJeU419661 for sip-archive@odin.ietf.org; Sun, 26 Jan 2003 14:40:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0QJe2J19629; Sun, 26 Jan 2003 14:40:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0QJZwJ18767 for ; Sun, 26 Jan 2003 14:35:58 -0500 Received: from dyn-tx-app-007.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20746 for ; Sun, 26 Jan 2003 14:15:22 -0500 (EST) Received: from TXADAM (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.12.5/8.12.5) with SMTP id h0QJIn9Z019228; Sun, 26 Jan 2003 13:18:49 -0600 Message-ID: <004801c2c56f$b965e660$6601a8c0@dynamicsoft.com> From: "Adam Roach" To: "Frank W. Miller" , "Jonathan Rosenberg" Cc: References: <53CD1252F68ED61183F5000347AE5F550120425E@G8PPZ.blf01.telekom.de> <002201c2be3a$5cef9160$9f00000a@overhill> <3E320717.9050808@dynamicsoft.com> <003701c2c560$72ff9540$9f00000a@overhill> Subject: Re: [Sip] Re: Comments: I-D ACTION:draft-miller-sip-tcap-00.txt : Reposting Date: Sun, 26 Jan 2003 13:18:35 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit "Frank W. Miller" writes: > First, I do not agree with your unequivocal statement that TCAP > has nothing to do with a session. There are several applications of TCAP > (CNAME and LNP come to mind) where there is clearly at least a fledgling > session in progress when TCAP is required. For those readers not familiar with TCAP, the above argument is analogous to claiming something like, "There are several applications of DNS (SIP SRV comes to mind) where there is clearly at least a fledgling session in progress when DNS is required". CNAME and LNP are nothing more than database dips. Now, imagine someone using this argument as justification for a proposal to tunnel XML formatted DNS queries over SIP. > Second, I've tried to get across > to other responders that there is a practical issue that is very important > here, that being cost. Current PSTN protocol implementations are very > expensive to implement. By this, I mean that the cost of protocol stacks > must be passed onto the end customer in some form. And you've steadfastly ignored responses pointing out that the expensive part of PSTN protocol stacks is *not* the syntactical decoding, but the implementation of the necessary protocol semantics. A syntactic transformation gains you little or nothing in terms of implementation complexity and total cost of solution. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Sun Jan 26 14:39:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21033 for ; Sun, 26 Jan 2003 14:39:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0QJxwG20386 for sip-archive@odin.ietf.org; Sun, 26 Jan 2003 14:59:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0QJxdJ20370; Sun, 26 Jan 2003 14:59:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0QJtgJ20238 for ; Sun, 26 Jan 2003 14:55:42 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20992 for ; Sun, 26 Jan 2003 14:35:05 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0QJcVUP025443 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 26 Jan 2003 14:38:32 -0500 (EST) Message-ID: <3E343957.3010008@cs.columbia.edu> Date: Sun, 26 Jan 2003 14:39:03 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] trimming "implicit preferences for media and priority" from caller prefs References: <3E32254F.6050605@dynamicsoft.com> In-Reply-To: <3E32254F.6050605@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Caller preferences seems to mandate being explicit rather than assuming things, so I agree that this should go. This is partially a lack of expressiveness of SDP (and the media preferences in caller-prefs), which can't distinguish between three subtly different things: - capabilities that the device has (things that are possible) - things the user would like to do now (which may be smaller or larger than the current capabilities); - things that the user might want to do later (e.g., after reaching a higher-bandwidth area or transferring a conference mid-call to a more capable device). Also, this is really a symptom of two non-commensurate quantities (preference for multiple media and preference for quickly reaching the destination) being at odds. Without a script, we can't really express all the subleties here, from "I'm willing to wait for the most desirable device to become available" at one extreme to "all devices being available, I choose X" at the other. The problem would not occur if only devices where the user is available are reachable. In this example, the correct solution would be that the PC would not be in the reachable set at all. Jonathan Rosenberg wrote: > I have been working on yet-another revision of caller preferences, in my > continuing attempts to get this thing finished. Just when I thought it > was done, and all the changes were happily applied, I ran into another > issue. Grr. > > The issue is an interaction between the implicit preferences mechanism > in the draft, and the desire to reach a user wherever they are. > > Anyway, let me explain the problem by an example. Lets say I send an > INVITE with audio and video in the SDP. The called party has two > devices, a PC w/ audio and video, and a cell phone with audio. They are > not at their PC right now, but are available by cell. The desired > behavior, and the intent of the caller (since they did not specify a > preference), is that the call would reach both devices and ring both, > and the user answers at the cell phone with audio only. However, the > implicit preferences will cause the PC to ring first (because its a > better match to the "implicit preference" to have video), and then the > cell phone. THis will increase call setup time and worsen the user > experience. > > This problem is a specific case of a more genreal issue, which is that > the implicit caller preferences mechanism is at odds with the proposed > fix to HERFP (see > http://www.jdrosen.net/papers/draft-rosenberg-sip-unify-00.txt if you > forget what HERFP is). They cannot co-exist. The whole idea with the > HERFP fix is to let the request go everywhere it can, since the called > party could be at any one of the devices. But, the caller prefs implicit > preferences would prioritize and select only the matching devices. The > called party may not be at that device, though. > > The essence of the problem, I think, is that there is no such thing as > implicit preferences. Just because I list audio and video in my SDP, > does not mean I want the call to be routed to a device which supports > those. It just means that those are the media types I want to try to use > for this call. Generally, danger lurks wherever the network tries to > assume something about caller intent, when it should not have assumed it. > > So, my proposed solution is to remove the implicit preferences > computation for media types, and also for priority (sections 7.2.2.1 and > 7.2.2.4 of caller prefs -07). The priority one is good to remove since > we were never sure it was right to begin with. That would leave implicit > preferences computations ONLY for methods, languages and event packages. > There are issues there too, but of a somewhat different sort, which I > will post in a separate note. > > So, unless someone screams really soon, consider those two features > removed. > > -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 mailnull@www1.ietf.org Sun Jan 26 14:53:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21142 for ; Sun, 26 Jan 2003 14:53:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0QKDQQ21393 for sip-archive@odin.ietf.org; Sun, 26 Jan 2003 15:13:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0QKD8J21384; Sun, 26 Jan 2003 15:13:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0QKACJ21312 for ; Sun, 26 Jan 2003 15:10:12 -0500 Received: from face.sentitonetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21127 for ; Sun, 26 Jan 2003 14:49:35 -0500 (EST) Received: (qmail 68421 invoked from network); 26 Jan 2003 19:53:04 -0000 Received: from unknown (HELO overhill) (10.0.0.159) by face.sentito.com with SMTP; 26 Jan 2003 19:53:04 -0000 Message-ID: <005e01c2c574$89f41c30$9f00000a@overhill> From: "Frank W. Miller" To: "Adam Roach" Cc: References: <53CD1252F68ED61183F5000347AE5F550120425E@G8PPZ.blf01.telekom.de> <002201c2be3a$5cef9160$9f00000a@overhill> <3E320717.9050808@dynamicsoft.com> <003701c2c560$72ff9540$9f00000a@overhill> <004801c2c56f$b965e660$6601a8c0@dynamicsoft.com> Subject: Re: [Sip] Re: Comments: I-D ACTION:draft-miller-sip-tcap-00.txt : Reposting Date: Sun, 26 Jan 2003 14:53:03 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit WRT to sessions, while I can make at least some kind of weak argument about TCAP. Its clear that using a similar mechanism for ISUP maintenance commands can be characterized exactly as Jonathan has described. The only reason for using SIP at all is the fact that its already there. Its there because its being used to establish sessions for phone calls. ISUP and TCAP are used in the PSTN for establishing calls/maintaining trunks and service creation. My view is that this underlying semantic similarity is enough to justify the use of SIP. I'd go even further, IMHO the acceptance of SIP as a signaling protocol for the big carriers will not be embraced wholeheartedly until these "corners" can be addressed. Its clear that any installation of SIP for signaling in the incumbents will have to interoperate with existing SS7 signaling networks for the forseeable future and that means all of SS7, not just call setup and teardown. Interoperability can of course be addressed by tunneling as has been described. It can also be addressed by translation at the SIP/SS7 border. This translation could be done to something other than SIP, e.g. SOAP as you and Jonathan have mentioned, but why? Why should I add another protocol, with its missing functionality btw, when I can just do it all in the context of SIP? > > And you've steadfastly ignored responses pointing out > that the expensive part of PSTN protocol stacks is *not* > the syntactical decoding, but the implementation of the > necessary protocol semantics. A syntactic transformation gains > you little or nothing in terms of implementation complexity > and total cost of solution. > You are correct, the implemenation of the state machines associated with these features is an expensive proposition. However, the state machine remains the same regardless of whether you're en/decoding a binary encoded TCAP message or an XML encoded version of the same message in an INFO body. The difference is I don't have to pay an SS7 vendor as many times for licenses to SS7 stack instances. This is a very significant cost savings. FM Frank W. Miller, Ph.D. Chief Technical Officer sentitO Network, Inc. fmiller@sentito.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 mailnull@www1.ietf.org Sun Jan 26 15:55:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21698 for ; Sun, 26 Jan 2003 15:55:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0QLFqL24148 for sip-archive@odin.ietf.org; Sun, 26 Jan 2003 16:15:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0QLFQJ24138; Sun, 26 Jan 2003 16:15:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0QL8mJ23976 for ; Sun, 26 Jan 2003 16:08:48 -0500 Received: from dyn-tx-app-007.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21584 for ; Sun, 26 Jan 2003 15:48:09 -0500 (EST) Received: from TXADAM (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.12.5/8.12.5) with SMTP id h0QKpc9Z019618; Sun, 26 Jan 2003 14:51:38 -0600 Message-ID: <009d01c2c57c$b0580410$6601a8c0@dynamicsoft.com> From: "Adam Roach" To: "Frank W. Miller" Cc: References: <53CD1252F68ED61183F5000347AE5F550120425E@G8PPZ.blf01.telekom.de> <002201c2be3a$5cef9160$9f00000a@overhill> <3E320717.9050808@dynamicsoft.com> <003701c2c560$72ff9540$9f00000a@overhill> <004801c2c56f$b965e660$6601a8c0@dynamicsoft.com> <005e01c2c574$89f41c30$9f00000a@overhill> Subject: Re: [Sip] Re: Comments: I-D ACTION:draft-miller-sip-tcap-00.txt : Reposting Date: Sun, 26 Jan 2003 14:51:23 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit "Frank W. Miller" writes: > Its clear that any > installation of SIP for signaling in the incumbents will have to > interoperate with existing SS7 signaling networks for the forseeable future > and that means all of SS7, not just call setup and teardown. > Interoperability can of course be addressed by tunneling as has been > described. It can also be addressed by translation at the SIP/SS7 border. The translation you are describing, though, has no benefit. It's not like you're suggesting that the commands are translated into something that performs analogous operations in the SIP network; you're just suggesting that we perform syntactic translations, slap them in a SIP INFO, and send them on their way. There's no benefit over tunneling. > This translation could be done to something other than SIP, e.g. SOAP as you > and Jonathan have mentioned, but why? Why should I add another protocol, > with its missing functionality btw, when I can just do it all in the context > of SIP? I'm still trying to build a conceptual model of the netowork you have in mind; however, based on the descriptions you give in this note, it sounds like what you really want is probably sigtran. The goal there, of course, was explicitly to not have any missing functionality when carrying SS7 information over an IP network. And I have long said that using SIP to establish sigtran sessions would be an elegant solution to that sort of problem. > > And you've steadfastly ignored responses pointing out > > that the expensive part of PSTN protocol stacks is *not* > > the syntactical decoding, but the implementation of the > > necessary protocol semantics. A syntactic transformation gains > > you little or nothing in terms of implementation complexity > > and total cost of solution. > > You are correct, the implemenation of the state machines associated with > these features is an expensive proposition. No, not the state machines of the features -- the state machines of the *protocols* themselves. In SIP terms, you're considering changing out the parser and re-coding the application without taking into consideration all the other "stuff" in between: the "stuff" that makes the SIP spec 269 pages instead of a 10-page listing of ABNF. > However, the state machine > remains the same regardless of whether you're en/decoding a binary encoded > TCAP message or an XML encoded version of the same message in an INFO body. > The difference is I don't have to pay an SS7 vendor as many times for > licenses to SS7 stack instances. This is a very significant cost savings. It sounds to me like you're saying, "by inventing new syntax that no one has implemented yet, I'll be forced to develop a stack in-house, at a substantial savings over licensing a third party stack." With your own assertion that it's just as complicated regardless of the syntax chosen, isn't it clear that you can develop an actual honest-to-God TCAP stack just as cheaply in-house as you can implement your own "TCAP-with-a-syntax-transform"? /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Jan 27 06:28:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12192 for ; Mon, 27 Jan 2003 06:28:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RBn7L14580 for sip-archive@odin.ietf.org; Mon, 27 Jan 2003 06:49:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RBlmJ14523; Mon, 27 Jan 2003 06:47:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RBhxJ14408 for ; Mon, 27 Jan 2003 06:43:59 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12144 for ; Mon, 27 Jan 2003 06:23:02 -0500 (EST) Received: from cisco.com (desh.cisco.com [192.122.173.43]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0RBQUSQ007098 for ; Mon, 27 Jan 2003 03:26:31 -0800 (PST) Received: from rkalshet-w2k.cisco.com ([10.77.138.171]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id QAA20893 for ; Mon, 27 Jan 2003 16:56:06 +0530 (IST) Message-Id: <4.3.2.7.2.20030127162940.027bfb40@desh.cisco.com> X-Sender: rkalshet@desh.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 27 Jan 2003 16:56:28 +0530 To: sip@ietf.org From: "Rajesh Kalshetty (rkalshet)" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_787146697==_.ALT" Subject: [Sip] Regarding 305 Redirection message .... Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --=====================_787146697==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Everyone, I am looking for a real time scenario in which 305(Use proxy) message is generated by a redirect server. I find it hard to think of an example where a pure redirect server would send a USE PROXY instead of simply issuing a 300-302 messages. It is also said in the RFC that the 305(use proxy) "MUST ONLY" be generated by user agent servers. This is a bit unclear to me. thanks. Rajesh k. --=====================_787146697==_.ALT Content-Type: text/html; charset="us-ascii"
Hi Everyone,

I am looking for a real time scenario in which 305(Use proxy) message is generated by a redirect server.
I find it hard to think of an example where a pure redirect server would send a USE PROXY instead of simply issuing a 300-302 messages.

It is also said in the RFC that the 305(use proxy) "MUST ONLY" be generated by user agent servers. This is a bit unclear to me.

thanks.

Rajesh k.
--=====================_787146697==_.ALT-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Jan 27 09:25:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16388 for ; Mon, 27 Jan 2003 09:25:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0REjpb25729 for sip-archive@odin.ietf.org; Mon, 27 Jan 2003 09:45:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0REjKJ25717; Mon, 27 Jan 2003 09:45:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O1XEJ09721 for ; Thu, 23 Jan 2003 20:33:14 -0500 Received: from tomts15-srv.bellnexxia.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26565 for ; Thu, 23 Jan 2003 20:13:58 -0500 (EST) Received: from ccc.sympatico.ca ([64.229.215.89]) by tomts15-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP id <20030124011725.TTAU29922.tomts15-srv.bellnexxia.net@ccc.sympatico.ca>; Thu, 23 Jan 2003 20:17:25 -0500 Message-Id: <5.1.0.14.0.20030123210037.00a16370@pop2.sympatico.ca> X-Sender: b1cwfq65@pop2.sympatico.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 23 Jan 2003 21:06:22 -0400 To: , , From: pierobon Cc: , , , sip@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Sip] SIP patent infringement warning Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Dear Sirs, Having examined your specs and use of SIP, I'm must point out that your company may be infringing on my patent rights. You can verify for yourself by examining the patent at http://massive-array-cellular-system.com Thanks, Victor Pierobon 416 221-2340 Pierobon@attcanada.ca To: Dean Willis Rohan Mahy Jon Peterson Scott Bradner Allison Mankin Allison Mankin Dan Romascanu _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Jan 27 14:30:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23659 for ; Mon, 27 Jan 2003 14:30:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RJojc12309 for sip-archive@odin.ietf.org; Mon, 27 Jan 2003 14:50:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RJo5J12282; Mon, 27 Jan 2003 14:50:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RJj0J12152 for ; Mon, 27 Jan 2003 14:45:00 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23550 for ; Mon, 27 Jan 2003 14:23:52 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0RJRPYH009731 for ; Mon, 27 Jan 2003 14:27:25 -0500 (EST) Message-ID: <3E358815.2050806@dynamicsoft.com> Date: Mon, 27 Jan 2003 14:27:17 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Error reporting in caller prefs Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This is the second note of two that describes some recently encountered issues while trying to wrap caller prefs. The issue here is error reporting. Lets say a caller lists a bunch of caller preferences, which include Reject-Contacts and Require-Contacts (now removed in -08 and replaced with a require parameter on Accept-Contact, but I'll use the -07 terminology). It is entirely possible that these preferences will result in ALL registered contacts getting discarded. The current behavior will be that the proxy acts as if there were no registered contacts, and returns a 480. Now, this means that the caller has no way to determine if the request failed because of their preferences, or because there really were no registered contacts. At first, I thought that this was a bad thing. But, thinking abuot it more, I concluded it was a good thing, for privacy reasons. The proxy is the one performing the caller preferences computation. The proxy will frequently not be the one authenticating the caller, or authorizing them to make calls or learn information abuot the called party. But, if a proxy reported information on call failures because of preference mismatches, a client would be able to "probe" the network using caller preferences, and learn detailed ifnormation on the capabilities of the devices associated with a user, without authentication. The current behavior prevents that, and I think thats good. OK, so whats the problem? Well, its those implicit preferences again. Lets say a user sends a SUBSCRIBE request, without caller preferences parameters. The called party has one UA, and it doesnt support SUBSCRIBE. Its registration to its proxy indicated such. The proxy supports caller preferences. So, it wuold compute an implicit preference to route the request to a UA that supports SUBSCRIBE, and give it the require strength (meaning, contacts which don't support SUBSCRIBE are discarded). Since none do, the one registered contact is discarded, and the caller receives a 480. A similar thing happens for event packages. This is a change in behavior if caller preferences were not used, in which case either (1) the UAS would authenticate and authorize the caller, and then return a 405 with the allowed methods, (2) the UAS would not authenticate or authorize the UAC, and thus genreate a 403 or 401. As a result, even though the caller did not use caller preferences, they have suffered from a loss of information, just because the proxy used caller prefs. The 405 would be useful for the UAC to perhaps try another method, or report the failure to the user. I dont mind a loss of information with EXPLICIT preferences, since the caller knows what they are getting into. But for implicit, we shouldn't be changing basic SIP behavior as seen by the UAC. There are a small number of solutions: 1. eliminate Require-Contact entirely (or, in -08 terms, eliminate the require parameter to Accept-Contact). This solves the problem, because the proxy will simply set the un-matching contacts to have a q-value of zero, and try them last. In the above example, the one registered contact remains with q=0, and is tried, resulting in a 405. 2.eliminate implicit preferences that use the Require-Contact semantic. So, if the request fails with a 480, its because the client explicitly asked for soemthing they couldnt get. 3. If a proxy uses caller prefs, and the result is the eliminatin of all contacts, AND if the reason they were eliminated was that there was an implicit Require-Contact for a specific method or event package, the proxy generates a 405 or 489 as if it were the UAS. 4. modify the semantics of require-contact so that, in the case where all contacts would be eliminated, instead of eliminating them, it sets the q-value to zero. This avoids the error condition. I didn't see any other approaches. None of these seem perfect: 1. Approach 1 is a non-starter; we have applications which need the Require semantic. 2. Approach 2 is better than approach 1. However, it will result in SUBSCRIBE and other methods being sent to a UAS that indicated that it didn't support those methods. On the list, Juha had complained loudly about this, and this thread was one of the motivations for adding require-contact. Now, the client can add the explicit Require-Contact with this solution, but that adds somewhat of a burden. 3. Appraoch 3 has a potential security issue. The proxy will generate a 405 or 489 on behalf of the UAS. So, if the UAS would generally not want to reveal this information (supported methods and event packages) unless the UAC would be authorized and authenticated, this approach will "leak" this information. One might argue that if the UAS uses caller prefs, and tells the proxy which methods and event packages it supports, it has forfeited its right to explicitly authenticate and authorize the caller before this information is divulged. If the UAS has these privacy concerns, it should not register these caller preferences parameters. 4. Approach 4 has similar problems to approach 2. I am inclined to go with approach 3, adding the appropriate discussions on the privacy considerations. The specific algorithm I would propose is this. If the caller prefs selection process results in zero contact, the proxy re-runs the algorithms without the implicit preferences. If now, there are contacts remaining, it concludes that the implicit preferences caused the problem. It then checks to see if the problem was methods or event packages, and generates a 405 or 489 accordingly. Comments? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Jan 27 16:36:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27693 for ; Mon, 27 Jan 2003 16:36:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RLudf19605 for sip-archive@odin.ietf.org; Mon, 27 Jan 2003 16:56:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RLuHJ19597; Mon, 27 Jan 2003 16:56:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RLpnJ19445 for ; Mon, 27 Jan 2003 16:51:49 -0500 Received: from dyn-tx-app-007.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27589 for ; Mon, 27 Jan 2003 16:30:41 -0500 (EST) Received: from TXADAM (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.12.5/8.12.5) with SMTP id h0RLY99Z026037; Mon, 27 Jan 2003 15:34:09 -0600 Message-ID: <015c01c2c64b$c67e5490$6601a8c0@dynamicsoft.com> From: "Adam Roach" To: "Jonathan Rosenberg" , References: <3E358815.2050806@dynamicsoft.com> Subject: Re: [Sip] Error reporting in caller prefs Date: Mon, 27 Jan 2003 15:33:46 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit "Jonathan Rosenberg" writes: > I am inclined to go with approach 3, adding the appropriate discussions > on the privacy considerations. The specific algorithm I would propose is > this. If the caller prefs selection process results in zero contact, the > proxy re-runs the algorithms without the implicit preferences. If now, > there are contacts remaining, it concludes that the implicit preferences > caused the problem. It then checks to see if the problem was methods or > event packages, and generates a 405 or 489 accordingly. Two comments; one con, one "interesting": 1. It seems to me that this approach adds a substantial burden to the proxy. 2. This has the interesting effect of forcing the proxy to aggregate the methods and the event-packages available for an address-of-record. (e.g. if I have a client registered that supports MESSAGE, and one that supports INVITE, the proxy-generated 405 will ostensibly indicate both INVITE and MESSAGE as acceptable methods.) Of course, this may well exacerbate the security problems you discuss -- but it also might be a useful feature. It also has the odd consequence that I can get a more accurate picture of your capabilities by intentionally sending an invalid method than I can by sending an OPTIONS... /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Jan 28 04:01:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19515 for ; Tue, 28 Jan 2003 04:01:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0S9MkE03694 for sip-archive@odin.ietf.org; Tue, 28 Jan 2003 04:22:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0S9M1J03676; Tue, 28 Jan 2003 04:22:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0S9JeJ03528 for ; Tue, 28 Jan 2003 04:19:40 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19421 for ; Tue, 28 Jan 2003 03:58:05 -0500 (EST) Received: from prasannacl1105 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H9F000NA2B855@mta0.huawei.com> for sip@ietf.org; Tue, 28 Jan 2003 16:59:44 +0800 (CST) Date: Tue, 28 Jan 2003 14:32:49 +0530 From: Prasanna Venkatesh Subject: RE: [Sip] Regarding 305 Redirection message .... In-reply-to: <4.3.2.7.2.20030127162940.027bfb40@desh.cisco.com> To: "Rajesh Kalshetty (rkalshet)" , sip@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: multipart/alternative; boundary="Boundary_(ID_oOc8nb7+50T8v9hOOIxUnQ)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_oOc8nb7+50T8v9hOOIxUnQ) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi, In a simple scenario where an UA is behind an "authenticating" proxy, and where the UA trusts requests from the proxy only, if an INVITE is directly send to the UA, it may request the sender of the UA to go through the proxy to get authenticated and the trust relationship. 305 is a requirement for specific network toplogies and an UAS which sends this is never a redirect server. Cheers, Prasanna -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Rajesh Kalshetty (rkalshet) Sent: Monday, January 27, 2003 4:56 PM To: sip@ietf.org Subject: [Sip] Regarding 305 Redirection message .... Hi Everyone, I am looking for a real time scenario in which 305(Use proxy) message is generated by a redirect server. I find it hard to think of an example where a pure redirect server would send a USE PROXY instead of simply issuing a 300-302 messages. It is also said in the RFC that the 305(use proxy) "MUST ONLY" be generated by user agent servers. This is a bit unclear to me. thanks. Rajesh k. --Boundary_(ID_oOc8nb7+50T8v9hOOIxUnQ) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT
Hi,
    In a simple scenario where an UA is behind an "authenticating" proxy, and where the UA trusts requests from the proxy only, if an INVITE is directly send to the UA, it may request the sender of the UA to go through the proxy to get authenticated and the trust relationship.
    305 is a requirement for specific network toplogies and an UAS which sends this is never a redirect server.
 
Cheers,
Prasanna
-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Rajesh Kalshetty (rkalshet)
Sent: Monday, January 27, 2003 4:56 PM
To: sip@ietf.org
Subject: [Sip] Regarding 305 Redirection message ....


Hi Everyone,

I am looking for a real time scenario in which 305(Use proxy) message is generated by a redirect server.
I find it hard to think of an example where a pure redirect server would send a USE PROXY instead of simply issuing a 300-302 messages.

It is also said in the RFC that the 305(use proxy) "MUST ONLY" be generated by user agent servers. This is a bit unclear to me.

thanks.

Rajesh k.
--Boundary_(ID_oOc8nb7+50T8v9hOOIxUnQ)-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Jan 28 05:21:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20308 for ; Tue, 28 Jan 2003 05:21:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SAgQZ08395 for sip-archive@odin.ietf.org; Tue, 28 Jan 2003 05:42:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SAg1J08381; Tue, 28 Jan 2003 05:42:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SAeYJ08341 for ; Tue, 28 Jan 2003 05:40:34 -0500 Received: from tms002bb.han.telia.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20289 for ; Tue, 28 Jan 2003 05:19:09 -0500 (EST) From: Carl.A.Wickbom@telia.se Received: from tms041mb.han.telia.se ([131.115.230.167]) by tms002bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.5329); Tue, 28 Jan 2003 11:22:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C6B7.2F4B87A8" Date: Tue, 28 Jan 2003 11:22:39 +0100 Message-ID: <57EFD03667AB294D8161FDB1A46B4093F5E31C@TMS041MB.tcad.telia.se> Thread-Topic: SIP-units in a IPv4/IPv6 dual-stack world Thread-Index: AcLGty62EdQ8UOz2SM6730BTQ+Y1kg== To: X-OriginalArrivalTime: 28 Jan 2003 10:22:39.0719 (UTC) FILETIME=[2F733770:01C2C6B7] Subject: [Sip] SIP-units in a IPv4/IPv6 dual-stack world Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C2C6B7.2F4B87A8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The behavior or a SIP client and server in IPv4 is quite clear and analogous in IPv6. However, the behavior of SIP clients and servers in an environment with both IPv4 and IPv6 is to me unclear (dual-stack). Do anyone know if there has been any work done about this, and in that case what the result of that work was? Best regards, Carl ------_=_NextPart_001_01C2C6B7.2F4B87A8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable SIP-units in a IPv4/IPv6 dual-stack world

Hi,

The behavior or a SIP = client and server in IPv4 is quite clear and analogous in = IPv6.
However, the = behavior of SIP clients and servers in an environment with both IPv4 and = IPv6 is to me unclear (dual-stack). Do anyone know if there has been any = work done about this, and in that case what the result of that work = was?

Best = regards,
Carl

------_=_NextPart_001_01C2C6B7.2F4B87A8-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Jan 28 07:38:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23798 for ; Tue, 28 Jan 2003 07:38:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SCx7S16672 for sip-archive@odin.ietf.org; Tue, 28 Jan 2003 07:59:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SCvwJ16638; Tue, 28 Jan 2003 07:57:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SCtEJ16381 for ; Tue, 28 Jan 2003 07:55:14 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23465 for ; Tue, 28 Jan 2003 07:33:44 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0SCdgg15805 for ; Tue, 28 Jan 2003 14:39:42 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 28 Jan 2003 14:37:08 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 28 Jan 2003 14:37:07 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Error reporting in caller prefs X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Tue, 28 Jan 2003 14:37:06 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE71C4@esebe019.ntc.nokia.com> Thread-Topic: [Sip] Error reporting in caller prefs Thread-Index: AcLGPCugooVmeehvT1OLRbdzWhNQ1gAjYOmw To: , X-OriginalArrivalTime: 28 Jan 2003 12:37:07.0804 (UTC) FILETIME=[F86749C0:01C2C6C9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0SCtEJ16382 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Can all this be fixed with a Require/Supported tag indicating that a UA understands the caller preferences extensions? Basically eliminating implicit preferences. Regards, Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, January 27, 2003 9:27 PM > To: sip@ietf.org > Subject: [Sip] Error reporting in caller prefs > > > This is the second note of two that describes some recently > encountered > issues while trying to wrap caller prefs. > > The issue here is error reporting. > > Lets say a caller lists a bunch of caller preferences, which include > Reject-Contacts and Require-Contacts (now removed in -08 and replaced > with a require parameter on Accept-Contact, but I'll use the -07 > terminology). It is entirely > possible that these preferences will result in ALL registered contacts > getting discarded. The current behavior will be that the proxy acts as > if there were no registered contacts, and returns a 480. Now, > this means > that the caller has no way to determine if the request failed > because of > their preferences, or because there really were no registered > contacts. > > At first, I thought that this was a bad thing. But, thinking abuot it > more, I concluded it was a good thing, for privacy reasons. > The proxy is > the one performing the caller preferences computation. The proxy will > frequently not be the one authenticating the caller, or > authorizing them > to make calls or learn information abuot the called party. But, if a > proxy reported information on call failures because of preference > mismatches, a client would be able to "probe" the network using caller > preferences, and learn detailed ifnormation on the capabilities of the > devices associated with a user, without authentication. The current > behavior prevents that, and I think thats good. > > OK, so whats the problem? Well, its those implicit preferences again. > Lets say a user sends a SUBSCRIBE request, without caller preferences > parameters. The called party has one UA, and it doesnt support > SUBSCRIBE. Its registration to its proxy indicated such. The proxy > supports caller preferences. So, it wuold compute an implicit > preference > to route the request to a UA that supports SUBSCRIBE, and give it the > require strength (meaning, contacts which don't support SUBSCRIBE are > discarded). Since none do, the > one registered contact is discarded, and the caller receives a 480. > > A similar thing happens for event packages. > > This is a change in behavior if caller preferences were not used, in > which case either (1) the UAS would authenticate and authorize the > caller, and then return a 405 with the allowed methods, (2) the UAS > would not authenticate or authorize the UAC, and thus > genreate a 403 or 401. > > As a result, even though the caller did not use caller > preferences, they > have suffered from a loss of information, just because the proxy used > caller prefs. The 405 would be useful for the UAC to perhaps > try another > method, or report the failure to the user. I dont mind a loss of > information with EXPLICIT preferences, since the caller knows > what they > are getting into. But for implicit, we shouldn't be changing basic SIP > behavior as seen by the UAC. > > There are a small number of solutions: > > 1. eliminate Require-Contact entirely (or, in -08 terms, > eliminate the > require parameter to Accept-Contact). This solves the > problem, because > the proxy will simply set the un-matching contacts to have a > q-value of > zero, and try them last. In the above example, the one registered > contact remains with q=0, and is tried, resulting in a 405. > > 2.eliminate implicit preferences that use the Require-Contact > semantic. > So, if the request fails with a 480, its because the client > explicitly > asked for soemthing they couldnt get. > > 3. If a proxy uses caller prefs, and the result is the > eliminatin of all > contacts, AND if the reason they were eliminated was that > there was an > implicit Require-Contact for a specific method or event package, the > proxy generates a 405 or 489 as if it were the UAS. > > 4. modify the semantics of require-contact so that, in the case where > all contacts would be eliminated, instead of eliminating them, it sets > the q-value to zero. This avoids the error condition. > > > I didn't see any other approaches. None of these seem perfect: > > 1. Approach 1 is a non-starter; we have applications which need the > Require semantic. > > 2. Approach 2 is better than approach 1. However, it will result in > SUBSCRIBE and other methods being sent to a UAS that > indicated that it > didn't support those methods. On the list, Juha had complained loudly > about this, and this thread was one of the motivations for adding > require-contact. Now, the client can add the explicit Require-Contact > with this solution, but that adds somewhat of a burden. > > 3. Appraoch 3 has a potential security issue. The proxy will > generate a > 405 or 489 on behalf of the UAS. So, if the UAS would > generally not want > to reveal this information (supported methods and event > packages) unless > the UAC would be authorized and authenticated, this approach > will "leak" > this information. One might argue that if the UAS uses caller > prefs, and > tells the proxy which methods and event packages it supports, it has > forfeited its right to explicitly authenticate and authorize > the caller > before this information is divulged. If the UAS has these privacy > concerns, it should not register these caller preferences parameters. > > 4. Approach 4 has similar problems to approach 2. > > > I am inclined to go with approach 3, adding the appropriate > discussions > on the privacy considerations. The specific algorithm I would > propose is > this. If the caller prefs selection process results in zero > contact, the > proxy re-runs the algorithms without the implicit > preferences. If now, > there are contacts remaining, it concludes that the implicit > preferences > caused the problem. It then checks to see if the problem was > methods or > event packages, and generates a 405 or 489 accordingly. > > Comments? > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Jan 28 18:09:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11050 for ; Tue, 28 Jan 2003 18:09:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SNV2K28762 for sip-archive@odin.ietf.org; Tue, 28 Jan 2003 18:31:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SNU0J28705; Tue, 28 Jan 2003 18:30:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SNQIJ28571 for ; Tue, 28 Jan 2003 18:26:18 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10853 for ; Tue, 28 Jan 2003 18:04:38 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0SN88YH010617; Tue, 28 Jan 2003 18:08:09 -0500 (EST) Message-ID: <3E370D52.2030001@dynamicsoft.com> Date: Tue, 28 Jan 2003 18:08:02 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: sip@ietf.org Subject: Re: [Sip] Error reporting in caller prefs References: <2038BCC78B1AD641891A0D1AE133DBB7FE71C4@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Implicit preferences has the benefit that it requires only one "side" to support it - the UAS and its proxy. Thus, if the terminating domain desires that SUBSCRIBE requests are routed to the PCs and not to the phones, it can do that by deploying caller prefs without the subscriber/watcher domain deploying it. This particular feature of caller prefs - only routing requests to UAs which support that method, is particularly useful. There was a long thread on the list about this feature, with some strong advocates behind it. -Jonathan R. hisham.khartabil@nokia.com wrote: > Can all this be fixed with a Require/Supported tag indicating that a > UA understands the caller preferences extensions? Basically > eliminating implicit preferences. > > Regards, Hisham > > >> -----Original Message----- From: ext Jonathan Rosenberg >> [mailto:jdrosen@dynamicsoft.com] Sent: Monday, January 27, 2003 >> 9:27 PM To: sip@ietf.org Subject: [Sip] Error reporting in caller >> prefs >> >> >> This is the second note of two that describes some recently >> encountered issues while trying to wrap caller prefs. >> >> The issue here is error reporting. >> >> Lets say a caller lists a bunch of caller preferences, which >> include Reject-Contacts and Require-Contacts (now removed in -08 >> and replaced with a require parameter on Accept-Contact, but I'll >> use the -07 terminology). It is entirely possible that these >> preferences will result in ALL registered contacts getting >> discarded. The current behavior will be that the proxy acts as if >> there were no registered contacts, and returns a 480. Now, this >> means that the caller has no way to determine if the request failed >> because of their preferences, or because there really were no >> registered contacts. >> >> At first, I thought that this was a bad thing. But, thinking abuot >> it more, I concluded it was a good thing, for privacy reasons. The >> proxy is the one performing the caller preferences computation. The >> proxy will frequently not be the one authenticating the caller, or >> authorizing them to make calls or learn information abuot the >> called party. But, if a proxy reported information on call failures >> because of preference mismatches, a client would be able to "probe" >> the network using caller preferences, and learn detailed >> ifnormation on the capabilities of the devices associated with a >> user, without authentication. The current behavior prevents that, >> and I think thats good. >> >> OK, so whats the problem? Well, its those implicit preferences >> again. Lets say a user sends a SUBSCRIBE request, without caller >> preferences parameters. The called party has one UA, and it doesnt >> support SUBSCRIBE. Its registration to its proxy indicated such. >> The proxy supports caller preferences. So, it wuold compute an >> implicit preference to route the request to a UA that supports >> SUBSCRIBE, and give it the require strength (meaning, contacts >> which don't support SUBSCRIBE are discarded). Since none do, the >> one registered contact is discarded, and the caller receives a 480. >> >> >> A similar thing happens for event packages. >> >> This is a change in behavior if caller preferences were not used, >> in which case either (1) the UAS would authenticate and authorize >> the caller, and then return a 405 with the allowed methods, (2) the >> UAS would not authenticate or authorize the UAC, and thus genreate >> a 403 or 401. >> >> As a result, even though the caller did not use caller preferences, >> they have suffered from a loss of information, just because the >> proxy used caller prefs. The 405 would be useful for the UAC to >> perhaps try another method, or report the failure to the user. I >> dont mind a loss of information with EXPLICIT preferences, since >> the caller knows what they are getting into. But for implicit, we >> shouldn't be changing basic SIP behavior as seen by the UAC. >> >> There are a small number of solutions: >> >> 1. eliminate Require-Contact entirely (or, in -08 terms, eliminate >> the require parameter to Accept-Contact). This solves the problem, >> because the proxy will simply set the un-matching contacts to have >> a q-value of zero, and try them last. In the above example, the one >> registered contact remains with q=0, and is tried, resulting in a >> 405. >> >> 2.eliminate implicit preferences that use the Require-Contact >> semantic. So, if the request fails with a 480, its because the >> client explicitly asked for soemthing they couldnt get. >> >> 3. If a proxy uses caller prefs, and the result is the eliminatin >> of all contacts, AND if the reason they were eliminated was that >> there was an implicit Require-Contact for a specific method or >> event package, the proxy generates a 405 or 489 as if it were the >> UAS. >> >> 4. modify the semantics of require-contact so that, in the case >> where all contacts would be eliminated, instead of eliminating >> them, it sets the q-value to zero. This avoids the error condition. >> >> >> >> I didn't see any other approaches. None of these seem perfect: >> >> 1. Approach 1 is a non-starter; we have applications which need the >> Require semantic. >> >> 2. Approach 2 is better than approach 1. However, it will result in >> SUBSCRIBE and other methods being sent to a UAS that indicated >> that it didn't support those methods. On the list, Juha had >> complained loudly about this, and this thread was one of the >> motivations for adding require-contact. Now, the client can add the >> explicit Require-Contact with this solution, but that adds somewhat >> of a burden. >> >> 3. Appraoch 3 has a potential security issue. The proxy will >> generate a 405 or 489 on behalf of the UAS. So, if the UAS would >> generally not want to reveal this information (supported methods >> and event packages) unless the UAC would be authorized and >> authenticated, this approach will "leak" this information. One >> might argue that if the UAS uses caller prefs, and tells the proxy >> which methods and event packages it supports, it has forfeited its >> right to explicitly authenticate and authorize the caller before >> this information is divulged. If the UAS has these privacy >> concerns, it should not register these caller preferences >> parameters. >> >> 4. Approach 4 has similar problems to approach 2. >> >> >> I am inclined to go with approach 3, adding the appropriate >> discussions on the privacy considerations. The specific algorithm I >> would propose is this. If the caller prefs selection process >> results in zero contact, the proxy re-runs the algorithms without >> the implicit preferences. If now, there are contacts remaining, it >> concludes that the implicit preferences caused the problem. It then >> checks to see if the problem was methods or event packages, and >> generates a 405 or 489 accordingly. >> >> Comments? >> >> -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 >> Eagle Rock Ave. Chief Scientist First >> Floor dynamicsoft East Hanover, NJ >> 07936 jdrosen@dynamicsoft.com FAX: (973) >> 952-5050 http://www.jdrosen.net PHONE: (973) >> 952-5000 http://www.dynamicsoft.com >> >> >> _______________________________________________ Sip mailing list >> https://www1.ietf.org/mailman/listinfo/sip This list is for NEW >> development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip Use >> sipping@ietf.org for new developments on the application of sip >> > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Jan 28 19:32:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12563 for ; Tue, 28 Jan 2003 19:32:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0T0rOo01509 for sip-archive@odin.ietf.org; Tue, 28 Jan 2003 19:53:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0T0qrJ01481; Tue, 28 Jan 2003 19:52:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0T0pcJ01385 for ; Tue, 28 Jan 2003 19:51:38 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12505 for ; Tue, 28 Jan 2003 19:29:56 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0T0XNYH010700; Tue, 28 Jan 2003 19:33:26 -0500 (EST) Message-ID: <3E37214D.7030307@dynamicsoft.com> Date: Tue, 28 Jan 2003 19:33:17 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: sip@ietf.org Subject: Re: [Sip] Error reporting in caller prefs References: <3E358815.2050806@dynamicsoft.com> <015c01c2c64b$c67e5490$6601a8c0@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Adam Roach wrote: > "Jonathan Rosenberg" writes: > >>I am inclined to go with approach 3, adding the appropriate discussions >>on the privacy considerations. The specific algorithm I would propose is >>this. If the caller prefs selection process results in zero contact, the >>proxy re-runs the algorithms without the implicit preferences. If now, >>there are contacts remaining, it concludes that the implicit preferences >>caused the problem. It then checks to see if the problem was methods or >>event packages, and generates a 405 or 489 accordingly. > > > Two comments; one con, one "interesting": > > 1. It seems to me that this approach adds a substantial burden > to the proxy. Well, its definitely more than zero. Caller prefs as it stands is, by definition, something a proxy spends cycles doing. How much more it will take to add this piece of processing, I am not certain. > > 2. This has the interesting effect of forcing the proxy to > aggregate the methods and the event-packages > available for an address-of-record. (e.g. if I have > a client registered that supports MESSAGE, > and one that supports INVITE, the proxy-generated > 405 will ostensibly indicate both INVITE and MESSAGE > as acceptable methods.) Of course, this may well exacerbate > the security problems you discuss -- but it also might > be a useful feature. It also has the odd consequence that > I can get a more accurate picture of your capabilities > by intentionally sending an invalid method than > I can by sending an OPTIONS... Interesting indeed. I would rather not reveal information which would otherwise not be revealed. I'd propose that the proxy reveal only the supported methods of the UA that would have otherwise received the request. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Jan 28 20:54:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13871 for ; Tue, 28 Jan 2003 20:54:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0T2GAT06909 for sip-archive@odin.ietf.org; Tue, 28 Jan 2003 21:16:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0T2FkJ06846; Tue, 28 Jan 2003 21:15:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0T2CkJ06692 for ; Tue, 28 Jan 2003 21:12:46 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13790 for ; Tue, 28 Jan 2003 20:51:02 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h0T1sNap019506; Tue, 28 Jan 2003 17:54:23 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADR13106; Tue, 28 Jan 2003 17:50:45 -0800 (PST) Date: Tue, 28 Jan 2003 17:54:28 -0800 Subject: Re: [Sip] Re: Comments: I-D ACTION:draft-miller-sip-tcap-00.txt : Reposting Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Frank W. Miller" , "Poetzl, Joachim" , sip@ietf.org To: Jonathan Rosenberg From: Rohan Mahy In-Reply-To: <3E320717.9050808@dynamicsoft.com> Message-Id: <9A3BFB30-332C-11D7-B309-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I would actually recommend a BEEP package to carry TCAP instead. thanks, -rohan On Friday, January 24, 2003, at 07:40 PM, Jonathan Rosenberg wrote: > You won't be surprised to hear me say that I think this is an entirely > inappropriate use of SIP, whether you use the INFO method or not. > > There is nothing in your usage that derives any benefit from SIP. > There are no sessions, no calls, no nothing. You are merely using an > INFO method as a way to send data from A to B. TCAP is closer to an > RPC protocol than anything else, and SIP is certainly NOT an RPC > protocol. > > Tunneling ISUP over SIP (SIP-T) does make a lot of sense, since ISUP, > functionally, is very close to SIP. We are therefore able to use SIP > semantics for the exchange, and augment the flows with additional data > (the tunneled ISUP message) that provides information of interest to > gateways. The key to the utility of SIP-T is that its still SIP. > > If you want an XML encoding of TCAP, I have no beef with that concept, > but its not SIP. Have you considered SOAP? SOAP over HTTP seems a much > better match. > > -Jonathan R. > > > > Frank W. Miller wrote: >> Thanks for the questions! >> Comments inline. >>> For the transport of SS7-signalling information the SIGTRAN >>> protocols have >> been especially defined by the SIGTRAN >>> working group of the IETF. In this scenario SUA over SCTP could >>> transport >> the TCAP information. For the time being PSTNs still exist and in >> converged >> scenarios we should use the same straight forward approach defined by >> the >> SIGTRAN group for each SS7 user part - why special treatment for >> TCAP???. >> We have a similar mechanism for the ISUP maintenance commands. An >> early >> version of that draft is on the IETF site and a major update that >> changes >> the INFO body contents to an XML representation will be released >> within >> days. TCAP is not special in this regard. IMHO, ISUP and TCAP are >> the best >> place to do translations because the "semantic level" appears to me >> to be >> the closest to where SIP session semantic level is. These two works >> are >> designed to augment the basic SIP-ISUP translation draft to include >> the >> ability to control PSTN access trunks (e.g. PRI's and IMTs on T-1s) >> from the >> PSTN and to do service delivery from existing PSTN elements (i.e. >> SCPs) to >> SIP endpoints, both without having to implement SS7 protocol stacks >> in the >> SIP elements. The goal is make sharper the demarcation between SIP >> and SS7. >> This is primarily a cost argument. SS7 stacks are more expensive in >> the >> marketplace than SIP stacks, so limiting the number of SS7 >> deployments saves >> costs for the carriers. >>> Why defining another approach when everythhing neccesary is already >> defined. Or are there doubts about the maturity in the SIGTRAN >> protocols? >> No, SIGTRAN is very mature and very useful for certain applications. >> This >> is just a different approach. I see no reason why tunneling and >> translation >> approaches cannot coexist in IETF standards. Both have their >> applications. >>> Some questions on the proposed solution: >>> -- How is adressing beeing resolved? >> One of the nice things about translation is that it limits addressing >> problems to the mapping of addresses. You can do about anything you >> want on >> the SIP side as long as the mappings at the SIP UA and the GW are >> handled >> appropriately. Addressing is certainly an area that is ripe for >> discussion >> in any standardization activity. >>> -- TCAP dialoges are mainly used for call unrelated signalling, >>> means no >> dialog exists. But one has to have an open SIP-Dialog before >> exchanging >> Info-Messages. How is that going to be resolved? >> The element with the UA maintains a persistent session with the GW >> for TCAP >> interactions. I believe this is discussed in the draft. >>> -- For what kind of services this should be used? Is this solution >> anticipated for call completion services instead of usage of >> subscribe/notify? >> There are several service examples detailed in the draft. Calling >> Name >> Delivery is the one that leaps to mind. >> FM >> Frank W. Miller, Ph.D. >> Chief Technical Officer >> sentitO Network, Inc. >> fmiller@sentito.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 > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Jan 28 20:55:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13905 for ; Tue, 28 Jan 2003 20:55:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0T2GZW06967 for sip-archive@odin.ietf.org; Tue, 28 Jan 2003 21:16:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0T2GDJ06924; Tue, 28 Jan 2003 21:16:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0T2FYJ06828 for ; Tue, 28 Jan 2003 21:15:34 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13843 for ; Tue, 28 Jan 2003 20:53:49 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h0T1v8sv022634; Tue, 28 Jan 2003 17:57:08 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADR13289; Tue, 28 Jan 2003 17:53:37 -0800 (PST) Date: Tue, 28 Jan 2003 17:57:19 -0800 Subject: Re: [Sip] trimming "implicit preferences for media and priority" from caller prefs Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: sip@ietf.org To: Jonathan Rosenberg From: Rohan Mahy In-Reply-To: <3E32254F.6050605@dynamicsoft.com> Message-Id: <00065160-332D-11D7-B309-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I agree. I believe it also unsafe to use implicit schemes (sip:, tel:, sips:, etc...). thx, -r On Friday, January 24, 2003, at 09:49 PM, Jonathan Rosenberg wrote: > I have been working on yet-another revision of caller preferences, in > my continuing attempts to get this thing finished. Just when I thought > it was done, and all the changes were happily applied, I ran into > another issue. Grr. > > The issue is an interaction between the implicit preferences mechanism > in the draft, and the desire to reach a user wherever they are. > > Anyway, let me explain the problem by an example. Lets say I send an > INVITE with audio and video in the SDP. The called party has two > devices, a PC w/ audio and video, and a cell phone with audio. They > are not at their PC right now, but are available by cell. The desired > behavior, and the intent of the caller (since they did not specify a > preference), is that the call would reach both devices and ring both, > and the user answers at the cell phone with audio only. However, the > implicit preferences will cause the PC to ring first (because its a > better match to the "implicit preference" to have video), and then the > cell phone. THis will increase call setup time and worsen the user > experience. > > This problem is a specific case of a more genreal issue, which is that > the implicit caller preferences mechanism is at odds with the proposed > fix to HERFP (see > http://www.jdrosen.net/papers/draft-rosenberg-sip-unify-00.txt if you > forget what HERFP is). They cannot co-exist. The whole idea with the > HERFP fix is to let the request go everywhere it can, since the called > party could be at any one of the devices. But, the caller prefs > implicit preferences would prioritize and select only the matching > devices. The called party may not be at that device, though. > > The essence of the problem, I think, is that there is no such thing as > implicit preferences. Just because I list audio and video in my SDP, > does not mean I want the call to be routed to a device which supports > those. It just means that those are the media types I want to try to > use for this call. Generally, danger lurks wherever the network tries > to assume something about caller intent, when it should not have > assumed it. > > So, my proposed solution is to remove the implicit preferences > computation for media types, and also for priority (sections 7.2.2.1 > and 7.2.2.4 of caller prefs -07). The priority one is good to remove > since we were never sure it was right to begin with. That would leave > implicit preferences computations ONLY for methods, languages and > event packages. There are issues there too, but of a somewhat > different sort, which I will post in a separate note. > > So, unless someone screams really soon, consider those two features > removed. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Jan 28 21:04:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14032 for ; Tue, 28 Jan 2003 21:04:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0T2PYp07311 for sip-archive@odin.ietf.org; Tue, 28 Jan 2003 21:25:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0T2PFJ07302; Tue, 28 Jan 2003 21:25:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0T2OxJ07262 for ; Tue, 28 Jan 2003 21:24:59 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14028 for ; Tue, 28 Jan 2003 21:03:14 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h0T26VB6002426; Tue, 28 Jan 2003 18:06:32 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADR13984; Tue, 28 Jan 2003 18:02:58 -0800 (PST) Date: Tue, 28 Jan 2003 18:06:41 -0800 Subject: Re: [Sip] Error reporting in caller prefs Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: sip@ietf.org To: Jonathan Rosenberg From: Rohan Mahy In-Reply-To: <3E358815.2050806@dynamicsoft.com> Message-Id: <4EAF1BB2-332E-11D7-B309-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I vote for option 4 with a subtle variation. Accept-contact w/ require will still match contacts (with q=0) if all the explicit preferences match but the implicit ones do not. The difference is that you still get a 480 if you eliminated all contacts using an *explicit* match, but an ordinary 405 or 489 if all contacts were eliminated using implicit preferences only. thanks, -rohan On Monday, January 27, 2003, at 11:27 AM, Jonathan Rosenberg wrote: > This is the second note of two that describes some recently encountered > issues while trying to wrap caller prefs. > > The issue here is error reporting. > > Lets say a caller lists a bunch of caller preferences, which include > Reject-Contacts and Require-Contacts (now removed in -08 and replaced > with a require parameter on Accept-Contact, but I'll use the -07 > terminology). It is entirely > possible that these preferences will result in ALL registered contacts > getting discarded. The current behavior will be that the proxy acts as > if there were no registered contacts, and returns a 480. Now, this > means > that the caller has no way to determine if the request failed because > of > their preferences, or because there really were no registered contacts. > > At first, I thought that this was a bad thing. But, thinking abuot it > more, I concluded it was a good thing, for privacy reasons. The proxy > is > the one performing the caller preferences computation. The proxy will > frequently not be the one authenticating the caller, or authorizing > them > to make calls or learn information abuot the called party. But, if a > proxy reported information on call failures because of preference > mismatches, a client would be able to "probe" the network using caller > preferences, and learn detailed ifnormation on the capabilities of the > devices associated with a user, without authentication. The current > behavior prevents that, and I think thats good. > > OK, so whats the problem? Well, its those implicit preferences again. > Lets say a user sends a SUBSCRIBE request, without caller preferences > parameters. The called party has one UA, and it doesnt support > SUBSCRIBE. Its registration to its proxy indicated such. The proxy > supports caller preferences. So, it wuold compute an implicit > preference > to route the request to a UA that supports SUBSCRIBE, and give it the > require strength (meaning, contacts which don't support SUBSCRIBE are > discarded). Since none do, the > one registered contact is discarded, and the caller receives a 480. > > A similar thing happens for event packages. > > This is a change in behavior if caller preferences were not used, in > which case either (1) the UAS would authenticate and authorize the > caller, and then return a 405 with the allowed methods, (2) the UAS > would not authenticate or authorize the UAC, and thus genreate a 403 > or 401. > > As a result, even though the caller did not use caller preferences, > they > have suffered from a loss of information, just because the proxy used > caller prefs. The 405 would be useful for the UAC to perhaps try > another > method, or report the failure to the user. I dont mind a loss of > information with EXPLICIT preferences, since the caller knows what they > are getting into. But for implicit, we shouldn't be changing basic SIP > behavior as seen by the UAC. > > There are a small number of solutions: > > 1. eliminate Require-Contact entirely (or, in -08 terms, eliminate the > require parameter to Accept-Contact). This solves the problem, because > the proxy will simply set the un-matching contacts to have a q-value > of zero, and try them last. In the above example, the one registered > contact remains with q=0, and is tried, resulting in a 405. > > 2.eliminate implicit preferences that use the Require-Contact semantic. > So, if the request fails with a 480, its because the client explicitly > asked for soemthing they couldnt get. > > 3. If a proxy uses caller prefs, and the result is the eliminatin of > all contacts, AND if the reason they were eliminated was that there > was an implicit Require-Contact for a specific method or event > package, the proxy generates a 405 or 489 as if it were the UAS. > > 4. modify the semantics of require-contact so that, in the case where > all contacts would be eliminated, instead of eliminating them, it sets > the q-value to zero. This avoids the error condition. > > > I didn't see any other approaches. None of these seem perfect: > > 1. Approach 1 is a non-starter; we have applications which need the > Require semantic. > > 2. Approach 2 is better than approach 1. However, it will result in > SUBSCRIBE and other methods being sent to a UAS that indicated that it > didn't support those methods. On the list, Juha had complained loudly > about this, and this thread was one of the motivations for adding > require-contact. Now, the client can add the explicit Require-Contact > with this solution, but that adds somewhat of a burden. > > 3. Appraoch 3 has a potential security issue. The proxy will generate > a 405 or 489 on behalf of the UAS. So, if the UAS would generally not > want to reveal this information (supported methods and event packages) > unless the UAC would be authorized and authenticated, this approach > will "leak" this information. One might argue that if the UAS uses > caller prefs, and tells the proxy which methods and event packages it > supports, it has forfeited its right to explicitly authenticate and > authorize the caller before this information is divulged. If the UAS > has these privacy concerns, it should not register these caller > preferences parameters. > > 4. Approach 4 has similar problems to approach 2. > > > I am inclined to go with approach 3, adding the appropriate > discussions on the privacy considerations. The specific algorithm I > would propose is this. If the caller prefs selection process results > in zero contact, the proxy re-runs the algorithms without the implicit > preferences. If now, there are contacts remaining, it concludes that > the implicit preferences caused the problem. It then checks to see if > the problem was methods or event packages, and generates a 405 or 489 > accordingly. > > Comments? > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Jan 29 10:59:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22544 for ; Wed, 29 Jan 2003 10:59:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0TGKb804269 for sip-archive@odin.ietf.org; Wed, 29 Jan 2003 11:20:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TGJNJ04196; Wed, 29 Jan 2003 11:19:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TGFbJ04075 for ; Wed, 29 Jan 2003 11:15:37 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22420 for ; Wed, 29 Jan 2003 10:53:36 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 29 Jan 2003 07:53:49 -0800 Received: from 212.143.185.30 by lw15fd.law15.hotmail.msn.com with HTTP; Wed, 29 Jan 2003 15:53:49 GMT X-Originating-IP: [212.143.185.30] From: "James Ford" To: sip@ietf.org Date: Wed, 29 Jan 2003 15:53:49 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 29 Jan 2003 15:53:49.0547 (UTC) FILETIME=[9D341BB0:01C2C7AE] Subject: [Sip] TCP sides and TLS sides Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, When implementing TLS as a secure means of communications for "sips" scheme, I have the following question: Does the TCP client has to be (or can I assume it is) the TLS client in the handshake process? Can it be that a TCP client will assume the role of a TLS server in the handshake process (or vice versa)? Thanks in Advance, James S. Ford. _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Jan 29 12:45:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24397 for ; Wed, 29 Jan 2003 12:45:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0TI6YM10756 for sip-archive@odin.ietf.org; Wed, 29 Jan 2003 13:06:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TI65J10739; Wed, 29 Jan 2003 13:06:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TI2LJ10622 for ; Wed, 29 Jan 2003 13:02:21 -0500 Received: from romeo.rtfm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24337 for ; Wed, 29 Jan 2003 12:40:18 -0500 (EST) Received: by romeo.rtfm.com (Postfix, from userid 556) id 2407AAB15; Wed, 29 Jan 2003 09:48:29 -0800 (PST) To: "James Ford" Cc: sip@ietf.org Subject: Re: [Sip] TCP sides and TLS sides References: Reply-To: EKR From: Eric Rescorla Date: 29 Jan 2003 09:48:28 -0800 In-Reply-To: Message-ID: Lines: 23 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , "James Ford" writes: > When implementing TLS as a secure means of communications for "sips" > scheme, I have the following question: > > Does the TCP client has to be (or can I assume it is) the TLS client > in the handshake process? The concept of TCP client isn't necessarily as clear as one might like since the TCP specification allows for simultaneous open. RFC 793 in fact doesn't even contain the word "client". Which TLS peer takes the role of "client" must be specified by the TLS-using protocol. However, in most cases one party does the TCP active OPEN and that's the TLS client and the other does the TCP passive OPEN and that's the TLS server. You could, however, write a protocol that specified things differently. SIPS is not such a protocol. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.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 mailnull@www1.ietf.org Wed Jan 29 15:14:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28522 for ; Wed, 29 Jan 2003 15:14:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0TKaOR20478 for sip-archive@odin.ietf.org; Wed, 29 Jan 2003 15:36:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TKZVJ20417; Wed, 29 Jan 2003 15:35:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TKUIJ20210 for ; Wed, 29 Jan 2003 15:30:18 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28204 for ; Wed, 29 Jan 2003 15:08:09 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.113]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0TKBdYH011193; Wed, 29 Jan 2003 15:11:40 -0500 (EST) Message-ID: <3E383574.6040808@dynamicsoft.com> Date: Wed, 29 Jan 2003 15:11:32 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy CC: sip@ietf.org Subject: Re: [Sip] Error reporting in caller prefs References: <4EAF1BB2-332E-11D7-B309-0003938AF740@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > Hi, > > I vote for option 4 with a subtle variation. Accept-contact w/ require > will still match contacts (with q=0) if all the explicit preferences > match but the implicit ones do not. The difference is that you still > get a 480 if you eliminated all contacts using an *explicit* match, but > an ordinary 405 or 489 if all contacts were eliminated using implicit > preferences only. I don't quite follow the second sentence above, but I do understand the desired property in the third. Indeed, in my analysis below, I had simply declared approach 4 as being the same as 2, but its not so. In the case where there is at least one matching contact, approach 4 will make sure that implicit preferences are honored at require strength, so that a UA which doesn't support SUBSCRIBE never gets one if there is a UA that does, for example. The only case that a UA will get a method it doesnt support is when none of the registered contacts support that method. I think thats actually a reasonable compromise. It also has less burden on proxies than my original proposal to go with option 3. So, I am now inclined to agree with Rohan and go with option 4. -Jonathan R. > On Monday, January 27, 2003, at 11:27 AM, Jonathan Rosenberg wrote: > >> This is the second note of two that describes some recently encountered >> issues while trying to wrap caller prefs. >> >> The issue here is error reporting. >> >> Lets say a caller lists a bunch of caller preferences, which include >> Reject-Contacts and Require-Contacts (now removed in -08 and replaced >> with a require parameter on Accept-Contact, but I'll use the -07 >> terminology). It is entirely >> possible that these preferences will result in ALL registered contacts >> getting discarded. The current behavior will be that the proxy acts as >> if there were no registered contacts, and returns a 480. Now, this means >> that the caller has no way to determine if the request failed because of >> their preferences, or because there really were no registered contacts. >> >> At first, I thought that this was a bad thing. But, thinking abuot it >> more, I concluded it was a good thing, for privacy reasons. The proxy is >> the one performing the caller preferences computation. The proxy will >> frequently not be the one authenticating the caller, or authorizing them >> to make calls or learn information abuot the called party. But, if a >> proxy reported information on call failures because of preference >> mismatches, a client would be able to "probe" the network using caller >> preferences, and learn detailed ifnormation on the capabilities of the >> devices associated with a user, without authentication. The current >> behavior prevents that, and I think thats good. >> >> OK, so whats the problem? Well, its those implicit preferences again. >> Lets say a user sends a SUBSCRIBE request, without caller preferences >> parameters. The called party has one UA, and it doesnt support >> SUBSCRIBE. Its registration to its proxy indicated such. The proxy >> supports caller preferences. So, it wuold compute an implicit preference >> to route the request to a UA that supports SUBSCRIBE, and give it the >> require strength (meaning, contacts which don't support SUBSCRIBE are >> discarded). Since none do, the >> one registered contact is discarded, and the caller receives a 480. >> >> A similar thing happens for event packages. >> >> This is a change in behavior if caller preferences were not used, in >> which case either (1) the UAS would authenticate and authorize the >> caller, and then return a 405 with the allowed methods, (2) the UAS >> would not authenticate or authorize the UAC, and thus genreate a 403 >> or 401. >> >> As a result, even though the caller did not use caller preferences, they >> have suffered from a loss of information, just because the proxy used >> caller prefs. The 405 would be useful for the UAC to perhaps try another >> method, or report the failure to the user. I dont mind a loss of >> information with EXPLICIT preferences, since the caller knows what they >> are getting into. But for implicit, we shouldn't be changing basic SIP >> behavior as seen by the UAC. >> >> There are a small number of solutions: >> >> 1. eliminate Require-Contact entirely (or, in -08 terms, eliminate the >> require parameter to Accept-Contact). This solves the problem, because >> the proxy will simply set the un-matching contacts to have a q-value >> of zero, and try them last. In the above example, the one registered >> contact remains with q=0, and is tried, resulting in a 405. >> >> 2.eliminate implicit preferences that use the Require-Contact semantic. >> So, if the request fails with a 480, its because the client explicitly >> asked for soemthing they couldnt get. >> >> 3. If a proxy uses caller prefs, and the result is the eliminatin of >> all contacts, AND if the reason they were eliminated was that there >> was an implicit Require-Contact for a specific method or event >> package, the proxy generates a 405 or 489 as if it were the UAS. >> >> 4. modify the semantics of require-contact so that, in the case where >> all contacts would be eliminated, instead of eliminating them, it sets >> the q-value to zero. This avoids the error condition. >> >> >> I didn't see any other approaches. None of these seem perfect: >> >> 1. Approach 1 is a non-starter; we have applications which need the >> Require semantic. >> >> 2. Approach 2 is better than approach 1. However, it will result in >> SUBSCRIBE and other methods being sent to a UAS that indicated that it >> didn't support those methods. On the list, Juha had complained loudly >> about this, and this thread was one of the motivations for adding >> require-contact. Now, the client can add the explicit Require-Contact >> with this solution, but that adds somewhat of a burden. >> >> 3. Appraoch 3 has a potential security issue. The proxy will generate >> a 405 or 489 on behalf of the UAS. So, if the UAS would generally not >> want to reveal this information (supported methods and event packages) >> unless the UAC would be authorized and authenticated, this approach >> will "leak" this information. One might argue that if the UAS uses >> caller prefs, and tells the proxy which methods and event packages it >> supports, it has forfeited its right to explicitly authenticate and >> authorize the caller before this information is divulged. If the UAS >> has these privacy concerns, it should not register these caller >> preferences parameters. >> >> 4. Approach 4 has similar problems to approach 2. >> >> >> I am inclined to go with approach 3, adding the appropriate >> discussions on the privacy considerations. The specific algorithm I >> would propose is this. If the caller prefs selection process results >> in zero contact, the proxy re-runs the algorithms without the implicit >> preferences. If now, there are contacts remaining, it concludes that >> the implicit preferences caused the problem. It then checks to see if >> the problem was methods or event packages, and generates a 405 or 489 >> accordingly. >> >> Comments? >> >> -Jonathan R. >> -- >> Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >> Chief Scientist First Floor >> dynamicsoft East Hanover, NJ 07936 >> jdrosen@dynamicsoft.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.dynamicsoft.com >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Jan 29 15:15:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28540 for ; Wed, 29 Jan 2003 15:15:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0TKacf20507 for sip-archive@odin.ietf.org; Wed, 29 Jan 2003 15:36:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TKaCJ20462; Wed, 29 Jan 2003 15:36:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TKXQJ20347 for ; Wed, 29 Jan 2003 15:33:26 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28439 for ; Wed, 29 Jan 2003 15:11:20 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.113]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0TKEhYH011218; Wed, 29 Jan 2003 15:14:47 -0500 (EST) Message-ID: <3E38362C.2040302@dynamicsoft.com> Date: Wed, 29 Jan 2003 15:14:36 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: sip@ietf.org Subject: Re: [Sip] trimming "implicit preferences for media and priority" from caller prefs References: <3E32254F.6050605@dynamicsoft.com> <3E343957.3010008@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Henning Schulzrinne wrote: > Caller preferences seems to mandate being explicit rather than assuming > things, so I agree that this should go. This is partially a lack of > expressiveness of SDP (and the media preferences in caller-prefs), which > can't distinguish between three subtly different things: > > - capabilities that the device has (things that are possible) > > - things the user would like to do now (which may be smaller or larger > than the current capabilities); > > - things that the user might want to do later (e.g., after reaching a > higher-bandwidth area or transferring a conference mid-call to a more > capable device). > > Also, this is really a symptom of two non-commensurate quantities > (preference for multiple media and preference for quickly reaching the > destination) being at odds. Right. This is exactly what I was trying to say. > Without a script, we can't really express > all the subleties here, from "I'm willing to wait for the most desirable > device to become available" at one extreme to "all devices being > available, I choose X" at the other. Indeed. WHich is why I think its good to not try and infer what the user is tryign to do. That would only get in the way of some kind of explicit script or other mechanism developed to achieve the desired processing. ANyway, given Rohan's and Henning's agreement, I think we are closed on this particular point. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 30 00:43:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09254 for ; Thu, 30 Jan 2003 00:43:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0U65W025205 for sip-archive@odin.ietf.org; Thu, 30 Jan 2003 01:05:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U64NJ25039; Thu, 30 Jan 2003 01:04:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U5u7J24558 for ; Thu, 30 Jan 2003 00:56:07 -0500 Received: from hss.hns.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09148 for ; Thu, 30 Jan 2003 00:33:47 -0500 (EST) From: hbhondwe@hss.hns.com Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hss.hns.com (8.11.6/8.11.2) with SMTP id h0U58Ha22388; Thu, 30 Jan 2003 10:38:21 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256CBE.001E612B ; Thu, 30 Jan 2003 11:01:49 +0530 X-Lotus-FromDomain: HSSBLR To: Dean Willis cc: sip@ietf.org Message-ID: <65256CBE.001E6085.00@sampark.hss.hns.com> Date: Thu, 30 Jan 2003 11:01:47 +0530 Subject: RE: RE: [Sip] SIP and Congestion Safety Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi Dean, Are you suggesting,in your alternative proposal, that proxies that send back a 5xx response will not indicate any MTU in it? If so, then we should also place a restriction that MTU should not be used as a basis for such an action. Otherwise the originator of the request will have no clue what is it supposed to do, retry the request or reduce the size and if so to what value? However with UDP , MTU does seem a valid basis for preventing congestion and it may not be possible to place such a restriction. This is assuming that congestion due to UDP messages could be trigerred both due to fragmentation as well as due to a high message rate. How about the following? UA1-------->P1(MTU1)--->P2.......Pn------->UA2(MTU2). Let checks on MTU be enforced only at the entry and exit points. P1 will reject requests exceeding MTU1, and indicate MTU1 in the 5xx sent back to UA1. Let the intermediate proxies pass requests without checking on the MTU of their next hop. At the edge proxy, Pn, let there be another check based on the max MTU size that UA2 is willing to accept(such as using the mechanism specified in Hisham's draft). That way the second rejection could occur at the edge proxy. This limits the number of attempts to at most 2, and prevents large messages from entering the network in the first place. As an addition, if we want to allow intermediate proxies to limit message sizes to the MTUs for the intermediate paths, we might consider having a mechanism to establish route size for a dialog. Let proxies not reject messages exceeding the next hop MTU. Agreed that this does not take care of route dynamicity nor does it take care of dynamic MTU changes, but attempting to address these issues would amount to trying to redefine a PMTU discovery mechanism at the application level. thanks Harsh Bhondwe Hughes Software Systems Dean Willis on 01/24/2003 10:15:14 PM To: Harsh Bhondwe/HSSBLR cc: sip@ietf.org Subject: RE: RE: [Sip] SIP and Congestion Safety On Fri, 2003-01-24 at 08:04, hbhondwe@hss.hns.com wrote: > Both the drafts(draft-khartabil-sip-congestionsafe-ci-01.txt > and draft-ietf-sip-congestsafe-00) propose using a max-size > header to indicate to the previous hop SIP entity the max > size that it(the SIP entity sending the 403, 503 response) > would allow on the next hop. Both the drats also assume that > the proxies know the MTU of the next hop by some means. > > Its not very difficult to encounter the following problem > in this mechanism: > UA1--(MTU1)--P1--(MTU2)---P2--(MTU3)--P3--(MTU4)--P4--(MTU5)--P5--(MTU6)--U > A2 > > MTU1>MTU2>MTU3>MTU4>MTU5>MTU6 > > In such a case it might take UA1, 6 attempts to finally > get a request through to UA2. And since the MTU for a > link is dynamic this could get even worse. yep. Actually, it's worse than that, since as you point out it is possible for dynamic rerouting to occur. That makes the absolute worst case even more entertaining. Assuming that every reduction reduces the size of the message by 1 byte, then the worst case number of retries is given by the equation Size(Max) - Size(Min), where Max is the largest message ever sent, and Min is the smallest MTU allowed. Assuming common values of 1300 and 576, that gives us more than 700 retries before a message gets through. But at least it's deterministic. > Considering such a scenario, I was wondering if it might be > a good idea to adopt a mechanism similar to the one used > for the session timer, i.e allow proxies in the path to > insert or update a min MTU similar to the way the session > timer value is inserted/updated. Proxies need not reject > requests that exceed the MTU of the next hop(hence > avoiding the problem enumurated above). And like with > session timer, the UA that initiated the request would > get to know the min MTU for the complete path in the > response, instead of having to converge on a value > through trial and error. If I understand this, you're proposing that we complete one round-trip in order to establish a route size for future use within the dialog, and that we assume that the route does not vary over the course of the dialog. The main problem here -- what if the first request is 64kB long and blows up on the UDP network just past the first proxy? And of course, there's the problem of route dynamicity. Here's an alternative proposal. Rather than negotiating size, could we "just say no"? Any proxy that finds it cannot congestion-safely transmit a message simply kicks back a 5xx "cannot send safely" response, and it's up to the sender to find another route? -- 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 mailnull@www1.ietf.org Thu Jan 30 10:45:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01901 for ; Thu, 30 Jan 2003 10:44:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UFm4Y09918 for sip-archive@odin.ietf.org; Thu, 30 Jan 2003 10:48:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UFlRJ09776; Thu, 30 Jan 2003 10:47:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UFieJ09657 for ; Thu, 30 Jan 2003 10:44:40 -0500 Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01802 for ; Thu, 30 Jan 2003 10:41:05 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Extension to Assure Congestion Safety Date: Thu, 30 Jan 2003 10:44:40 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D248717@zoe.office.snowshore.com> Thread-Topic: [Sip] Extension to Assure Congestion Safety Thread-Index: AcK9f+xaTvTCliEFRPaRNjT7Fxu4OwKZOxSA From: "Eric Burger" To: "Dean Willis" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0UFifJ09658 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I'll bite :-) How long will it take to setup a call in a far-from-the-antenna 3G scenario using TCP? That is, at 14.4kb/s, I'm looking at least 3RTT's just to say "INVITE". > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Thursday, January 16, 2003 11:26 AM > To: loretosa@vizzavi.it > Cc: bcampbell@dynamicsoft.com; sip@ietf.org > Subject: Re: [Sip] Extension to Assure Congestion Safety > > > On Thu, 2003-01-16 at 06:36, loretosa@vizzavi.it wrote: > > Hi > > > > are there news about the Congestion problem ? > > I read some weeks ago that work is frozen. > > But your draft expires at the end of January. > > Will be some change in new release? If it will be resubmitted. > > > > About the change with TCP as Transport Protocol default, > > someone can tell me some news? > > > > Thanks, Sal. Actually, we haven't talked much about this > lately, and we > probably should. > > When conversation last stopped, we had just realized that although we > could use this sort of mechanism in the forward direction, it > doesn't do > anything about the reverse direction. > > So, let's say somebody S/MIME signs a 200 OK, making it perhaps 4KB in > size (That doesn't necessarily happen, but it MIGHT if they include > their cert). Since this is a response, it MUST follow the > path laid out > in the Via header field, even if this takes it across non-congestion > safe UDP links. > > Is this a problem that we should worry about? > > If so, can we address it short of jut deprecating UDP? > > One approach that came up is essentially tagging the Via > values so that > we know which are congestion safe. Under this approach, the > receiving UA > would be able to recognize that the large response it is generating > could not be returned safely. What should it do then? Could such a > mechanism be made backward compatible? > > How much additional triggerwork are we willing to put into > the protocol > just to continue accommodating UDP? I know a number of people believe > that a lot of the complexity of SIP stems from its concurrent support > for UDP and TCP, and that we'd be better off just ripping the UDP out > and consequently greatly simplifying the state machines than > adding more > complexity to the core protocol. > > So, we don't really have a group consensus about where to go > with this, > and we need one. > > Ladies, gentleman, and those to whom these terms are irrelevant, the > floor is open for discussion. > > -- > 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 mailnull@www1.ietf.org Thu Jan 30 10:45:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01926 for ; Thu, 30 Jan 2003 10:45:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UFm8M09947 for sip-archive@odin.ietf.org; Thu, 30 Jan 2003 10:48:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UFlnJ09820; Thu, 30 Jan 2003 10:47:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UFigJ09666 for ; Thu, 30 Jan 2003 10:44:42 -0500 Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01806 for ; Thu, 30 Jan 2003 10:41:07 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 Date: Thu, 30 Jan 2003 10:44:40 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D248719@zoe.office.snowshore.com> Thread-Topic: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 Thread-Index: AcK7ddiiY9jbDnI/S8yVkiD6lt+/AwMcLGOQ From: "Eric Burger" To: "Dean Willis" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0UFigJ09667 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit If this goes forward, I would also suggest that wording to the effect of "INFO packages MUST describe congestion control mechanisms, or why congestion control mechanisms will not be an issue (e.g., we're talking about only ever sending a single, small message)". > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Monday, January 13, 2003 9:22 PM > To: sip@ietf.org > Subject: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 > > > > It only seemed appropriate to follow up my previous assumably > eloquent but > frequently misspelled exhortations by following my own advice > and "sending > text". > > The resulting draft has been submitted to the archive and should be > announced in due course. In the interim, you may wish to > retrieve it from: > > http://www.softarmor.com/sipwg/drafts/draft-willis-sip-infopac > kage-00.html > > or > > http://www.softarmor.com/sipwg/drafts/draft-willis-sip-infopac kage-00.txt Or, if you just LIKE looking at XML source or wish to fix some of my probable glaring errors, http://www.softarmor.com/sipwg/drafts/draft-willis-sip-infopackage-00.xml I'd like to caveat that this is a rough first draft -- I just sat down and banged it out this afternoon, and only Adam Roach has seen any of it so far, and that was in small bits. thanks -- 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 mailnull@www1.ietf.org Thu Jan 30 10:45:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01940 for ; Thu, 30 Jan 2003 10:45:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UFmFb09967 for sip-archive@odin.ietf.org; Thu, 30 Jan 2003 10:48:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UFltJ09839; Thu, 30 Jan 2003 10:47:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UFihJ09670 for ; Thu, 30 Jan 2003 10:44:43 -0500 Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01809 for ; Thu, 30 Jan 2003 10:41:07 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 Date: Thu, 30 Jan 2003 10:44:40 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D24871B@zoe.office.snowshore.com> Thread-Topic: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 Thread-Index: AcK89WPsi/8qLohuR3OO9Q4MXm6UvgK8dFcg From: "Eric Burger" To: "Adam Roach" , "Henning Schulzrinne" , "Dean Willis" Cc: "Christer Holmberg" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0UFihJ09671 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit [Lot's of discussion; I'm just catching up.] The whole issue of 'what this message means' versus 'what this object is' was dealt with to great extent in the VPIM work group. Adam gave the excellent example of "what does image/jpeg mean?". We grappled with "what does audio/basic mean?". The answer is you absolutely cannot determine what the message context (meaning) is from the types of bodies in the message. Moreover, registering lots of application/mumbles doesn't work either. There is little value to registering a bunch of things that have the same semantics. That also has interaction with things like multipart/alternative or multipart/mixed. You can find a *very* detailed explanation of this problem, and the solution, in RFC 3458. > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Wednesday, January 15, 2003 7:02 PM > To: Henning Schulzrinne; Dean Willis > Cc: 'Christer Holmberg'; sip@ietf.org > Subject: Re: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 > > > "Henning Schulzrinne" writes: > > > We currently negotiate above-SIP content with Content-Type, > > Content-Language and all the other Content-Headers, just > like HTTP, SMTP > > and other MIME users. If the body contains message/isup, it > is an ISUP > > message. It is not clear to me what value an additional, > semi-orthogonal > > negotiation mechanism offers. > > Upon further reflection, I realise that my previous response addressed > the wrong half of this objection (multiple content types per > application, > instead of multiple applications per content type). > > Take, for example, the content type of "image/jpeg". > > It is quite conceivable that someone might define an INFO > package of "app-icon" that uses "image/jpeg" to send > a 32x32 pixel image that should be used as the icon for the > application for the duration of the session. > > It is also completely beleivable that someone else might > define an INFO package of "set-pointer" that uses "image/jpeg" > to send a 16x16 bitmap that is to be used as the mouse pointer > when said pointer is in the window associated with the > application. > > Now, I'm not advocating these usages of INFO or even the > ability to do either of these things with SIP, but I'm certain > that you will agree that these are the *sort* of content-type > collisions that you will encounter if you don't have the > orthagonal mechanism that Dean includes in his draft. > > /a > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 30 11:43:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01903 for ; Thu, 30 Jan 2003 10:45:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UFm4Y09932 for sip-archive@odin.ietf.org; Thu, 30 Jan 2003 10:48:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UFlkJ09801; Thu, 30 Jan 2003 10:47:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UFifJ09662 for ; Thu, 30 Jan 2003 10:44:41 -0500 Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01804 for ; Thu, 30 Jan 2003 10:41:06 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 Date: Thu, 30 Jan 2003 10:44:40 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D248718@zoe.office.snowshore.com> Thread-Topic: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 Thread-Index: AcK8rqCcOFKtR7xpQ+OuWKdtxXTmJQLN49uQ From: "Eric Burger" To: "Tom-PT Taylor" Cc: "Dean Willis" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0UFifJ09663 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Don't worry: your existing SIP-T implementations will still work. They won't ask for or accept the info-package offer, which means that raw INFO should still work. -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Wednesday, January 15, 2003 10:36 AM To: 'Henning Schulzrinne'; Drage, Keith (Keith) Cc: 'Dean Willis'; sip@ietf.org Subject: RE: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 I really agree with Henning's viewpoint. The mechanisms are already there. Quite frankly, I don't want to have to redo my SIP-T implementation of INFO unless a really good case can be made for it. > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, January 15, 2003 10:13 AM > To: Drage, Keith (Keith) > Cc: 'Dean Willis'; sip@ietf.org > Subject: Re: [Sip] INFO Packaging -- draft-willis-sip-infopackage-00 > > > > >>Ah. Actually, that is the direction that I initially started > >>taking things > >>in the draft -- basically, I associated MIME content-types > >>with usages, and > >>didn't have the Info-Type. Then I briefly talked it over with > >>Adam, and he > >>talked me into the separate semantic indicator. > >> > >>I believe that the assertion that "most INFO types will have > >>exactly one > >>valid Content-Type" is the breaker. Let's look at text. Is > >>the text I just > >>sent you indicative of a move in the chess game we are > playing? Is it > >>something I want you to post on a web page for me? Should you > >>just read it? > >>Is it a javascript that you should use to remap your > >>keyboard? Is it C code > >>that you should compile and execute? Is it a credit card > > The mistake would be specifying all of them as text/plain. > They should > be specified as the correct media type to begin with. After > all, I may > want to save the content and saving a C file as .txt instead of .c is > not very helpful. > > If this is application data, it should be labeled as > application/chess. > > In addition, there is Content-Disposition to look at. > > > >>number that you > >>should debit for the price of this call? Why the heck AM I > >>sending it to > >>you? > >> > >>There are probably much better examples, but I think that a > one-to-one > >>mapping between content-type and expected function is more > >>constraining than the way I think people are trying to use INFO, > >>perhaps overly constraining. > >> > >>-- > >>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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jan 30 13:55:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06721 for ; Thu, 30 Jan 2003 13:55:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UIwMn21730 for sip-archive@odin.ietf.org; Thu, 30 Jan 2003 13:58:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UIvRJ21695; Thu, 30 Jan 2003 13:57:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UIorJ21528 for ; Thu, 30 Jan 2003 13:50:53 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06553 for ; Thu, 30 Jan 2003 13:47:13 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h0UIohLd019910; Thu, 30 Jan 2003 12:50:44 -0600 From: "Dean Willis" To: "'Eric Burger'" Cc: Subject: RE: [Sip] Extension to Assure Congestion Safety Date: Thu, 30 Jan 2003 12:50:19 -0600 Message-ID: <003601c2c890$70340b60$ee036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <4A3384433CE2AB46A63468CB207E209D248717@zoe.office.snowshore.com> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0UIorJ21529 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Eric chewed on: > I'll bite :-) > > How long will it take to setup a call in a > far-from-the-antenna 3G scenario using TCP? That is, at > 14.4kb/s, I'm looking at least 3RTT's just to say "INVITE". Well, consider that you should be using a long-lived TCP session established back when you turned your phone on. Consequently, there's little further overhead for TCP -- just some ack fields in the TCP headers on the INVITE, 200OK, and ACK. There's probably a final null-ack TCP packet on the ACK message, but that's after call setup has completed. Given this, the constraint is still the three-way handshake of SIP, which means you have at least 3 RTTs whether you use UDP or TCP. So, let's say each request, using compression, is 400 bytes (that's 3200 bits). At 14.4, that makes a total serialization delay of 222 ms per each mobile link. Two mobile links give us 444ms. Add 150ms of core network delays (50ms each hop), and we're at 372ms. Not too shabby so far. Now, add aother 50 ms each for the P-CSCF, I-CSCF, S-CSCF, I-CSCF, S-CSCF, P-CSCF processing and we get another 300 ms for each hop, or 900ms. Add a little more for topology hiding gateways and the like, and we're at around 1800 ms. So much for the math. The problem is, current 3G systems have a lot more transmission latency than one would think based on the bandwidth. Assuming there's an active connection, it still tends to be a couple of hundred ms before a mobile can actually send anything. Consequently, real world performance with today's system adds another 2 seconds or so to the call setup. We're working on that from the network side. On the other hand, that's still not any worse than the 10-15 second call setup dealys I always have on my TDMA phone . . . Now, lets think about the specific impact of TCP vs UDP here. The BIG delays in SIP setup happen if a request or response gets lost and we use the SIP backoff timers to resend. TCP, giving us a smoother-running network, is less likely to give us a network in which packets get lost. Furthermore, its recovery timers (especially in the wireless-tuned TCP) are likely to give smoother, quicker recovery than does SIP in the event of a loss-burst. So, all in all, I don't think we lose anything by using TCP to the mobile, and we potentially gain quite a bit. Server-to-server operations have to think about head-of-line blocking issues, and that's wehre SCTP comes in as a better alternative. -- 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 mailnull@www1.ietf.org Thu Jan 30 13:55:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06749 for ; Thu, 30 Jan 2003 13:55:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UIwlx21777 for sip-archive@odin.ietf.org; Thu, 30 Jan 2003 13:58:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UIwQJ21745; Thu, 30 Jan 2003 13:58:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UIp5J21544 for ; Thu, 30 Jan 2003 13:51:05 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06560 for ; Thu, 30 Jan 2003 13:47:25 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h0UIohLc019910; Thu, 30 Jan 2003 12:50:43 -0600 From: "Dean Willis" To: Cc: Subject: RE: RE: [Sip] SIP and Congestion Safety Date: Thu, 30 Jan 2003 12:50:19 -0600 Message-ID: <003501c2c890$6ffea380$ee036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <65256CBE.001E6085.00@sampark.hss.hns.com> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0UIp5J21545 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > Hi Dean, > > Are you suggesting,in your alternative proposal, that proxies > that send back a 5xx response will not indicate any MTU in > it? If so, then we should also place a restriction that MTU > should not be used as a basis for such an action. Otherwise > the originator of the request will have no clue what is it > supposed to do, retry the request or reduce the size and if > so to what value? However with UDP , MTU does seem a valid > basis for preventing congestion and it may not be possible to > place such a restriction. Right. MTU is not a basis in response processing, because responses MUST follow the path of the request. The comparison factor I'm suggesting is "if the response is bigger than the request AND the request was not marked congestion-safe, send a 5XX "cannot respond safely". > This is assuming that congestion due to UDP messages could > be trigerred both due to fragmentation as well as due to a > high message rate. > > How about the following? > > UA1-------->P1(MTU1)--->P2.......Pn------->UA2(MTU2). > > Let checks on MTU be enforced only at the entry and exit > points. P1 will reject requests exceeding MTU1, and indicate > MTU1 in the 5xx sent back to UA1. Let the intermediate > proxies pass requests without checking on the MTU of their > next hop. At the edge proxy, Pn, let there be another check > based on the max MTU size that UA2 is willing to accept(such > as using the mechanism specified in Hisham's draft). That > way the second rejection could occur at the edge proxy. This > limits the number of attempts to at most 2, and prevents > large messages from entering the network in the first place. > > As an addition, if we want to allow intermediate proxies to > limit message sizes to the MTUs for the intermediate paths, > we might consider having a mechanism to establish route size > for a dialog. Let proxies not reject messages exceeding the > next hop MTU. Agreed that this does not take care of route > dynamicity nor does it take care of dynamic MTU changes, but > attempting to address these issues would amount to trying to > redefine a PMTU discovery mechanism at the application level. > Your suggestions seem applicable to REQUEST processing, although I don't see a real gain over the somewhat simpler approach in draft-ietf-sip-congestsafe-00. The big piece missing from that draft was the RESPONSE processing. I also continue to worry about path dynamicity. Part of the difference may be a matter of intent. Personally, I really don't want to reinvent TCP flow control on top of UDP for SIP. The TCP folks have been working on that problem for a long time already. I'm more interested in a way to keep UDP implementations, where we think we MUST have them, from breaking things. So, open question -- exactly what is it we're trying to solve here, and how much mechanism is it reasonable to have? -- 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 mailnull@www1.ietf.org Thu Jan 30 23:08:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17823 for ; Thu, 30 Jan 2003 23:08:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0V4BcA20017 for sip-archive@odin.ietf.org; Thu, 30 Jan 2003 23:11:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0V4B9J19994; Thu, 30 Jan 2003 23:11:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0V48dJ19928 for ; Thu, 30 Jan 2003 23:08:39 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17773 for ; Thu, 30 Jan 2003 23:04:48 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.6/8.12.6) with ESMTP id h0V489wH010777; Thu, 30 Jan 2003 21:08:10 -0700 (MST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 30 Jan 2003 21:08:09 -0700 Message-ID: Thread-Topic: RequestUri to Host Matching and proxy servers Thread-Index: AcLI3lwut0O4I4X4R0q69Adeu0k9xA== From: "Jean-Francois Mule" To: Cc: "Kevin" , "Jean-Francois Mule" , "Kavitha" X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0V48dJ19929 Subject: [Sip] RequestUri to Host Matching and proxy servers Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Updating the sip mib ID with Kevin & Kavitha, we have a quick question re: Request-URI and host matching for proxy servers. Is there any application where not requiring request-uri host matching makes sense for a proxy? We thought about the outbound proxy case where requests are usually targetted for external proxies, therefore request-uri to host matching may potentially not be the default action. We have a sipRequestUriHostMatching mib object (true/false value) that is currently applicable to UAs and proxies and we're wondering whether to keep it as a common configuration object or move it to the UA config section of the mib. Additionally, if request-URI to host matching is enforced, is it ok for the object description to state something like: "If the value of this object is 'true', then the server requires a match, and if the RequestURI doesn't match the server's host name, a Location Service may be used to obtain information about a callee's possible location(s) or a 404 Not Found status code is returned by the server." Thanks, Jean-Francois. sipRequestUriHostMatching OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies whether or not the host in RequestURI must match server's host name. If the value of this object is 'true', then the server requires a match, and if the RequestURI doesn't match the server's host name, a Location Service may be used to obtain information about a callee's possible location(s) or a 404 Not Found status code is returned by the server. If the value is 'false', then no match is required." REFERENCE "RFC 3261, Section 8.2.2.1" ::= { sipCommonCfgEntry 8 } _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 31 01:02:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19861 for ; Fri, 31 Jan 2003 01:02:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0V66Jk24568 for sip-archive@odin.ietf.org; Fri, 31 Jan 2003 01:06:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0V65uJ24558; Fri, 31 Jan 2003 01:05:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0V647J24513 for ; Fri, 31 Jan 2003 01:04:07 -0500 Received: from server2.fastmail.fm (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19841 for ; Fri, 31 Jan 2003 01:00:16 -0500 (EST) Received: from www.fastmail.fm (server1.internal [10.202.2.132]) by fastmail.fm (Postfix) with ESMTP id 936EE46B66 for ; Fri, 31 Jan 2003 01:03:47 -0500 (EST) Received: from 127.0.0.1 ([127.0.0.1] helo=www.fastmail.fm) by fastmail.fm with SMTP; Fri, 31 Jan 2003 01:03:47 -0500 Received: by www.fastmail.fm (Postfix, from userid 99) id 8BDA31F8FE; Fri, 31 Jan 2003 01:03:47 -0500 (EST) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "KumarS" To: sip@ietf.org Date: Thu, 30 Jan 2003 22:03:47 -0800 X-Epoch: 1043993027 X-Sasl-enc: CeV6RBolCTYkfmA8cZlcJw References: <003601c2c890$70340b60$ee036e3f@txdwillis> In-Reply-To: <003601c2c890$70340b60$ee036e3f@txdwillis> Message-Id: <20030131060347.8BDA31F8FE@www.fastmail.fm> Content-Transfer-Encoding: 7bit Subject: [Sip] Re-Invite supported SIP implementation Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi All, I am looking for Re-Invite supported SIP implementation. May I get any pointer to Re-Invite (rfc 3261) implemented downloadable SIP code. Thanks in advance Suman -- KumarS knowsip@fastmail.fm -- http://fastmail.fm - A no graphics, no pop-ups email service _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jan 31 09:21:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07358 for ; Fri, 31 Jan 2003 09:21:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0VEOuh28870 for sip-archive@odin.ietf.org; Fri, 31 Jan 2003 09:24:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VEOPJ28860; Fri, 31 Jan 2003 09:24:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VEMhJ28798 for ; Fri, 31 Jan 2003 09:22:43 -0500 Received: from proxy-blr.primus-india.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07289 for ; Fri, 31 Jan 2003 09:18:38 -0500 (EST) Received: from dexceldesigns.com (ptil-67-160-ind.primus-india.net [203.196.160.67] (may be forged)) by proxy-blr.primus-india.com (8.11.2/8.11.2) with ESMTP id h0VJp4V11096 for ; Sat, 1 Feb 2003 01:21:04 +0530 Message-ID: <000a01c2c92e$4c548000$dd9a83ca@DOMAIN.dexceldesigns.com> From: margaretmary To: Date: Fri, 31 Jan 2003 19:10:20 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C2C95C.66051AE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailserver: Sent using PostMaster (v4.1.13) Subject: [Sip] query on redirect server Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C2C95C.66051AE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello sir, With respect to draft-ietf-sip-rfc2543bis-09.ps for Redirect server " A = redirect server does not issue any SIP requests or its own. Ater = receiving a request other than CANCEL, the server either refuses the = request or gathers the list of alternative locations from the location = service and returns a final response of class 3xx". This statement tells for all methods of (INVITE, ACK, BYE, REGISTER, = OPTIONS) other then CANCEL or only for INVITE. Its quite confusing. Please try to provide a solution for this. Regards, Margaret, ------=_NextPart_000_0007_01C2C95C.66051AE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello  sir,
 
With respect to = draft-ietf-sip-rfc2543bis-09.ps for=20 Redirect server " A redirect server does not issue any SIP requests or = its own.=20 Ater receiving a request other than CANCEL, the server either = refuses=20 the request or gathers the list of alternative locations from the = location=20 service and returns a final response of class = 3xx".
This statement  tells for all = methods of=20 (INVITE, ACK, BYE, REGISTER, OPTIONS) other then CANCEL or only for=20 INVITE.
 
Its quite confusing.
Please try to provide a solution for=20 this.
 
 
Regards,
Margaret,

--------------------------------------------------------------
Dexcel Electronics Designs (P) Ltd., Bangalore, India
------=_NextPart_000_0007_01C2C95C.66051AE0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip