From sip-bounces@ietf.org Fri Oct 1 00:25:30 2004 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 AAA04075 for ; Fri, 1 Oct 2004 00:25:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDF7V-0004EU-R1 for sip-web-archive@ietf.org; Fri, 01 Oct 2004 00:34:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDEuk-0004Uj-R2; Fri, 01 Oct 2004 00:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDEfC-0008LJ-13 for sip@megatron.ietf.org; Fri, 01 Oct 2004 00:04:58 -0400 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 AAA02261 for ; Fri, 1 Oct 2004 00:04:54 -0400 (EDT) Received: from s-utl01-slpop.stsn.com ([12.168.96.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CDEnZ-0003nm-Ju for sip@ietf.org; Fri, 01 Oct 2004 00:13:37 -0400 Received: from slpop.smtp.stsn.com ([127.0.0.1]) by s-utl01-slpop.stsn.com (SAVSMTP 3.1.0.29) with SMTP id M2004093022042622821 for ; Thu, 30 Sep 2004 22:04:26 -0600 Received: from dynamicsoft.com ([10.2.175.167]) by slpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 30 Sep 2004 22:04:26 -0600 Message-ID: <415CAE1F.1030401@dynamicsoft.com> Date: Thu, 30 Sep 2004 21:08:47 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Stredicke Subject: Re: [Sip] Symmetric NAT issue References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Oct 2004 04:04:26.0428 (UTC) FILETIME=[BE00CFC0:01C4A76B] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Christian Stredicke wrote: > IMVHO SBC that use ICE are a smart alternative to using TURN. I don't really understand what this means. I would not expect an SBC to implement ICE, in the sense that it would do the p2p STUN pings, connectivity checks, etc., or are you proposing that it does? Also, ICE makes use of TURN, to deal with the symmetric NAT case. SO I don't understand what you mean when you say ICE is an alternative to TURN. Can you explain? UA that > are not aware of ICE, STUN, TURN or NAT will run media through the B2BUA > while ICE-aware devices can bypass them. That I agree with. > IMEHO ist much easier to > implement STUN/ICE than TURN (well, we did/tried it) and it solves the > problem with the "dumb" devices. ICE without TURN will not help in the symmetric NAT case. > Paired with DNS SRV and STUN its > possible to automatically detect the nearest SBC, in case the SBC is > necessary to relay media for symmetrical NAT. Detect an SBC? I don't follow. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 1 04:35:03 2004 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 EAA05848 for ; Fri, 1 Oct 2004 04:35:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDJ0v-0001OV-Db for sip-web-archive@ietf.org; Fri, 01 Oct 2004 04:43:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDIlz-0001kc-Oe; Fri, 01 Oct 2004 04:28:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDIVw-0006PI-MA for sip@megatron.ietf.org; Fri, 01 Oct 2004 04:11:40 -0400 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 EAA04648 for ; Fri, 1 Oct 2004 04:11:39 -0400 (EDT) Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDIeJ-0000tz-4i for sip@ietf.org; Fri, 01 Oct 2004 04:20:22 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0I4W00501BYNUV@siemenscomms.co.uk> for sip@ietf.org; Fri, 01 Oct 2004 09:08:52 +0100 (BST) Received: from ntht206e.siemenscomms.co.uk ([137.223.247.52]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0I4W0052GBX11D@siemenscomms.co.uk>; Fri, 01 Oct 2004 09:07:49 +0100 (BST) Received: by ntht206e.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 01 Oct 2004 09:09:36 +0100 Content-return: allowed Date: Fri, 01 Oct 2004 09:09:35 +0100 From: "Elwell, John" Subject: RE: [Sip] Proposed bug fix to RFC3261 arising from draft-elwell-s ip-state-u pdate-02 To: "'Paul Kyzivat'" Message-id: <50B1CBA96870A34799A506B2313F26670252D41B@ntht201e> 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: 932cba6e0228cc603da43d861a7e09d8 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: 200d029292fbb60d25b263122ced50fc Content-Transfer-Encoding: 7BIT Paul, Thanks for your comment. You have made it clear before that there is a distinction between call state and dialog state, and that there is not always a 1:1 relationship between them. However, there are moves to deprecate dialog re-use. So although there are examples of dialog re-use today (the REFER case being the prime example), I don't anticipate new applications of this technique to be endorsed and there is likely to be a move to phase out existing forms of re-use. Moreover there cannot be more than one call per dialog. Therefore if a dialog supports a call, there is not a lot of difference in principle between dialog state and call state, although if the dialog also supports a subscription, call state information will not survive after a BYE, even though dialog state will survive if the subscription survives. With these considerations in mind, perhaps we don't need to put an excessive amount of effort into distinguishing between call state and dialog state. Call state just becomes a part of dialog state, existing on dialogs that support calls but not on dialogs that support subscriptions. I eliminated some of the elements such as Call-Info, the updating of which did not appear to be of great interest to anyone and which, as you say, are call state. Yes, session information I guess is also call state. I forgot to add Required/Supported/Allowed headers, which I guess are in fact part of the dialog state. From other specifications, PAI is an example of data that is part of dialog state. I guess the main question we need to answer is whether this proposed clarification to RFC3261 (and eventually RFC3311) should embrace dialog state change, call state change or both. One difficulty is that the term "call" is not well-defined in RFC3261 (the Call-Id header unfortunately is dialog state, not call state). Then the question arises whether we should embark on trying to define the term call and hence call state. So I see the following options, and I would like some feedback from the list: 1. Do nothing. 2. Do not attempt to distinguish between call state and dialog state, on the basis that the desire is to phase out dialog re-use (some dialogs will of course also be calls, but a dialog should not serve two purposes: subscription and call). In other words, continue as proposed in my previous email (possibly restoring things like Call-Info if there is interest). 3. Stick rigidly to dialog state (so session information would be removed from my proposal). 4. Define "call" and "call state" and distinguish them from "dialog" and "dialog state". Handle both call state update and dialog state update. Opinions please. John Elwell (john.elwell@siemens.com) Paul Kyzivat wrote: I agree with what you are trying to do. But one rather significant detail with what you propose is that I don't believe the session description (SDP) is dialog state. It is call state. (A dialog that exists for the purpose of a SUBSCRIBE would not have this.) That in some sense guts this proposal, since now there are no examples in this document of additional dialog state. However I still think the clarification is needed. In addition, 3261 sweeps the distinction between dialog state and call state under the rug. Once alternative uses of dialogs are in play it is important to make this distinction clear, and to identify those items that are part of call state. This includes the session description info (the negotiated offer and answer as well as potentially another proposed change to offer and answer). It also includes the data associated with session timer, and possibly Call-Info, Alert-Info, Subject. (Which if any of these is truly call state remains to be discussed.) Paul Elwell, John wrote: > At the SIP meeting in San Diego, I was asked to raise on the mailing list > the individual bug fixes proposed in the state-update draft, so that each > can be given due scrutiny. I decided to start with RFC3261. Here only a few > changes are proposed and it does not seem sensible to consider these > separately, so I propose them here as a single bug fix. If we can gain > consensus on those, I will follow it up with messages proposing bug fixes to > the other documents (mainly RFC3311). > > As a result of comments by Paul Kyzivat raised on the list recently, I have > modified the proposed changes slightly. In particular, I have dropped any > headers that are not obviously dialog state changes, including those that > might not be considered state at all (e.g., Alert-Info) and those that might > be considered call state rather than dialog state (e.g., Call-Info, > Subject). If anyone wants these re-instating, please say so. > > Proposed bug fix to RFC3261: > > Add the following paragraph to the end of 12 (prior to 12.1): > > "A dialog can also have certain other state information that can change > during the lifetime of the dialog. This includes the session description (as > negotiated by SDP offer/answer), information from certain other headers and > information from certain other bodies. There are no examples from this RFC. > However, extensions may define other headers or bodies containing > information that contributes to the state of a dialog and can change during > the lifetime of the dialog." > > Add two new paragraphs to the end of 12.2 (prior to 12.2.1): > > "A request, whether or not it is a target refresh request, MAY update > certain other information transmitted at the time of dialog establishment. > Although there are no examples in this RFC, other extensions may define > headers or bodies that are appropriate for updating during a dialog. > > "In this RFC, the only request defined that is suitable for updating > information during a dialog is re-INVITE (see section 14). Other extensions > may define different requests suitable for updating information during a > dialog." > > Add to the end of the first paragraph of 14.1: > > "A UAC MAY send a session description that is unchanged, if the purpose of > the re-INVITE is solely for updating dialog-related information." > > John Elwell (john.elwell@siemens.com) > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailman-bounces@ietf.org Fri Oct 1 09:30:17 2004 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 JAA28259 for ; Fri, 1 Oct 2004 09:30:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDNcl-0007GX-Np for sip-web-archive@ietf.org; Fri, 01 Oct 2004 09:39:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDK5u-0003Nd-5u for sip-web-archive@ietf.org; Fri, 01 Oct 2004 05:52:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: sip-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Oct 2004 05:20:27 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for sip-web-archive@ietf.org: List Password // URL ---- -------- sip@ietf.org toufat https://www1.ietf.org/mailman/options/sip/sip-web-archive%40ietf.org From sip-bounces@ietf.org Fri Oct 1 13:09:28 2004 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 NAA26008 for ; Fri, 1 Oct 2004 13:09:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDR2v-0003y9-4P for sip-web-archive@ietf.org; Fri, 01 Oct 2004 13:18:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDQ9T-00078O-P9; Fri, 01 Oct 2004 12:20:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDOAl-0000R4-7E for sip@megatron.ietf.org; Fri, 01 Oct 2004 10:14:11 -0400 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 KAA02763 for ; Fri, 1 Oct 2004 10:14:09 -0400 (EDT) Received: from [61.16.171.234] (helo=HRISHIKESH) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDOJC-00087M-7z for sip@ietf.org; Fri, 01 Oct 2004 10:22:56 -0400 Received: from [127.0.0.1] by HRISHIKESH (ArGoSoft Mail Server Freeware, Version 1.8 (1.8.6.1)); Mon, 27 Sep 2004 19:48:26 Message-ID: <41582130.2060000@mistralsoftware.com> Date: Mon, 27 Sep 2004 19:48:24 +0530 From: Gautham User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Paul D.Smith" Subject: Re: [Sip] Problem with an intial SIP INVITE server transa ction. References: <53F74F5A7B94D511841C00B0D0AB16F803E52FE9@baker.datcon.co.uk> In-Reply-To: <53F74F5A7B94D511841C00B0D0AB16F803E52FE9@baker.datcon.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 Content-Transfer-Encoding: 7bit Cc: SIP WG , "'Roman Shpount'" X-BeenThere: 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: 40161b1d86420e0807d771943d981d25 Content-Transfer-Encoding: 7bit Hi, The scenario given by Roman could happen at either a proxy or a endpoint. At a proxy, the appropriate thing would be to create a new transaction. Like Roman has mentioned in his mail, this retransmission may be because the 1xx responses and the 2xx responses were lost. In such a case, I believe, it would be correct for the proxy to create a new transaction and forward the INVITE downstream, as if it were a new transaction. In anycase, a proxy would not know better. At an endpoint too, it should not be a problem if a new server transaction gets created for the retransmitted INVITE. The UA core can look at the From tag, Call-Id and possibly CSeq to determine that it is not a new dialog request i.e., that it matches an ongoing dialog. If the UA core is still retransmitting the 2xx, it would send the 2xx to the transaction which would terminate it. If the UA core has finished retransmitting the 2xx (and has received the ACK) it could treat the INVITE as an out-of-sequence request. Hope this helps. Regards, A. N. Gautham Paul D.Smith wrote: >Roman, > >I believe you have strayed into a poorly specified area of SIP here. I have >also found nothing in the specs. that directly answers your question however >I can tell you what is observed: the duplication INVITEs are simply >ignored. One option is to keep track of the INVITE transaction until the >ACK arrives. Although logically there is no transaction layer interaction >(as per section 17, RFC 3261), you can then identify the INVITE as a >duplicate and discard it. > >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: Roman Shpount [mailto:roman@atelo.com] >Sent: 19 September 2004 08:15 >To: SIP Public Folder (E-mail) >Subject: Re: RE: RE: [Sip] Problem with an intial SIP INVITE server >transaction. > > >Thomas, > >The problem is that retransmitted INVITE message does not have the To-tag. >Thus it does not match the dialog and UAC is not even informed about this >message. The only way I could think to deal with this, as I described in my >original email, was to add a timer which keeps the server INVITE transaction >open for T4 after 2XX response is sent. If retransmitted INVITE message >arrives within this time, it matches the transaction and is ignored. By the >way, this discussion is not academic, this is the real problem that we >encountered while dealing with large volumes of SIP transactions over Wi-Fi. >___________________________________ >Roman Shpount, VP of Technology >aTelo, Inc. -- www.atelo.com > >------ Original message ------ > > > >>From: Thomas Gal >>Subject: RE: RE: [Sip] Problem with an intial SIP INVITE server >> >> >transaction. > > >>Date: 31 Aug 04, 04:44 PM >>To: 'Roman Shpount' , , >> >> > > >Maybe some people were just trying to help without scouring the spec for all >the details. I have read the spec quite a few times, thanks, but here, maybe >this will help(17): > > In the case of a transaction where the > request was an INVITE (known as an INVITE transaction), the > transaction also includes the ACK only if the final response was not > a 2xx response. If the response was a 2xx, the ACK is not considered > part of the transaction. > > The reason for this separation is rooted in the importance of > delivering all 200 (OK) responses to an INVITE to the UAC. To > deliver them all to the UAC, the UAS alone takes responsibility > for retransmitting them (see Section 13.3.1.4), and the UAC alone > takes responsibility for acknowledging them with ACK (see Section > 13.2.2.4). Since this ACK is retransmitted only by the UAC, it is > effectively considered its own transaction. > >You gotta wait til you get the ACK. > >-Tom > > >-----Original Message----- >From: Roman Shpount [mailto:roman@atelo.com] >Sent: Tuesday, August 31, 2004 8:38 AM >To: gledgard@iperia.com; ThomasGal@LumenVox.com; sip@ietf.org >Subject: Re: RE: [Sip] Problem with an intial SIP INVITE server transaction. > >Hi All, > >I got quite a few answers like: "there is a magic key which prevents this" >or "there is a timer that prevents this", or "you cannot get an INVITE once >you sent the 1XX or 2XX response". I would suggest that you would read the >RFC (Section 17.2.1) before rushing to answer my question. RFC clearly >spells out that INVITE server transaction is terminated when 2XX response is >sent. There is even a picture (Figure 7) that shows just that. There are no >timers. There are no special transaction IDs. Transaction is ended, clear >and simple. Once transaction is ended, re-transmitted INVITE message should >start the new transaction. >___________________________________ >Roman Shpount, VP of Technology >aTelo, Inc. -- www.atelo.com > >------ Original message ------ > > > >>From: Gordon Ledgard >>Subject: RE: [Sip] Problem with an intial SIP INVITE server transaction. >>Date: 31 Aug 04, 12:40 PM >>To: , Roman Shpount , >> >> >> > > >Read the stuff about timers in the transaction layer. It spells out how you >need to hold on to transactions for messages over unreliable transports for >just this sort of reason. > > >Gordon > > > >-----Original Message----- >From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Thomas >Gal >Sent: Monday, August 30, 2004 7:54 PM >To: 'Roman Shpount'; sip@ietf.org >Subject: RE: [Sip] Problem with an intial SIP INVITE server transaction. > > >I'm not an expert on this protocol (only read through the spec a few times >so it blurs together with some of the other ones) but even without looking >I'm SURE there's supposed to be a unique request-ID generated by the client >to avoid just such a confusion. Of course in this case any stateful UA would >ignore the already processed invite request. Also (sure about this one) if >the client received the provisional(100) response it wouldn't re-transmit >the INVITE either as that's the whole point. > >-Tom > >-----Original Message----- >From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Roman >Shpount >Sent: Tuesday, August 17, 2004 7:05 PM >To: sip@ietf.org >Subject: [Sip] Problem with an intial SIP INVITE server transaction. > >I run into the problem with handling of retransmitted SIP INVITE message >based on the RFC 3621. > >Imagine the following situation > >INVITE 1 >-----------------------> >100 ><----------------------- >2XX ><----------------------- >re-transmitted INVITE 1 >-----------------------> > >Based on RFC 3261, server INVITE transaction terminates as soon as 2XX >response is sent. This means that re-transmitted INVITE will be treated as a >new transaction. This INVITE message will not match the existing dialog, >since its To tag is empty. This means it will be treated as new dialog >creating message and phone will treat this message as a new call, which is >clearly not intended. > >This situation can occur if both 100 and 2XX responses were lost by the >unreliable transport, and INVITE continues to be re-transmitted. The fact >that, 100 and 2XX responses were lost is unknown to the server transaction >and INVITE re-transmit can arrive before the 2XX re-transmit is sent. > >Majority of the transaction state machines in SIP are designed to handle >messages, that are received after the response is sent. It seems that >something simular is required in this case as well. > >In our implementation of SIP stack, server transaction is not terminated >when the 2XX response is sent. Instead, transaction is moved into the >"ConfirmedBis" state and timer, which is set to fire in T4, is started. If >the stack receives an INVITE message which matches the server transaction in >this state, it ignores it. If stack receives a 2XX response, which matches >the server transaction, it passes it to TU. Once the T4 timer is fired, the >transaction is terminated. > >There is also an additional issue related to this problem. It looks like, >for the sake of consistency, some type of response should be sent >immediately to the transport layer when INVITE re-transmit is received. If >multiple 2XX responses has been sent, it is unclear what the behavior should >be: should all the 2XX messages be sent, should the last 2XX message be >resent or should the INVITE be plainly ignored. > >___________________________________ >Roman Shpount, VP of Technology >aTelo, Inc. -- www.atelo.com > > > > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use >sip-implementors@cs.columbia.edu for questions on current sip Use >sipping@ietf.org for new developments on the application of sip > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use >sip-implementors@cs.columbia.edu for questions on current sip Use >sipping@ietf.org for new developments on the application of sip > > > > > > > > > > > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 1 13:42:23 2004 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 NAA29295 for ; Fri, 1 Oct 2004 13:42:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDRYd-00059Y-BY for sip-web-archive@ietf.org; Fri, 01 Oct 2004 13:51:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDQo6-0003I1-Ad; Fri, 01 Oct 2004 13:02:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDPr0-0005h5-LE for sip@megatron.ietf.org; Fri, 01 Oct 2004 12:01:54 -0400 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 MAA16581 for ; Fri, 1 Oct 2004 12:01:52 -0400 (EDT) Received: from airwolf.sentito.com ([65.202.222.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CDPzJ-0001sk-Tr for sip@ietf.org; Fri, 01 Oct 2004 12:10:41 -0400 Received: (qmail 3231 invoked by uid 1014); 1 Oct 2004 16:01:09 -0000 Received: from shanlu@sentito.com by airwolf.sentito.com by uid 1002 with qmail-scanner-1.22 (clamdscan: 0.75. spamassassin: 2.63. Clear:RC:1(65.202.222.2):. Processed in 0.041379 secs); 01 Oct 2004 16:01:09 -0000 Received: from unknown (HELO SAJAK) (65.202.222.2) by airwolf.sentito.com with SMTP; 1 Oct 2004 16:01:08 -0000 From: "Shan Lu" To: "'Christer Holmberg \(JO/LMF\)'" , "'IETF SIP Mailing List'" Subject: RE: [Sip] Question on RFC3261 Merged Requests Date: Fri, 1 Oct 2004 12:02:26 -0400 Message-ID: <007a01c4a7d0$0b9496e0$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 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: 29dc808194f5fb921c09d0040806d6eb Content-Transfer-Encoding: quoted-printable Christer, I appreciate your comments. After thinking over the point you raised = (why old transaction mapping rules have to be used in 3261-compliant environment), I came to the conclusion that 8.2.2.2 is completely = broken.=20 My gateway example showed that at least when R-URI is different, second INVITE should not be automatically rejected on the basis that it shares = same call-id, cseq, and the from tag with an INVITE in a different = transaction. Even when the two INVITEs have identical R-URI, the fact that they may = have visited different proxies after being forked could make one of them more desirable than the other. The order they arrive at the UAS should not determine which one gets presented to user and which one gets discarded. = The protocol can not make that distinction. The forking proxy and calling UA both have built-in mechanisms to avoid = one single INVITE leading to two established dialogs. When it works, Section 8.2.2.2 is an optimization on top of that. And there are plenty of cases = it simply does not work. I propose two options moving forward: 1. strike out 8.2.2.2 completely, or 2. replace it with a note to say that UAS may receive INVITEs in = different transactions but with identical call-id, cseq, from tag, and possibly = same R-URI. UAS should be prepared to handle this situation as it would with = any other incoming INVITEs. I like to hear the list's opinion on this and whether it is a bug that should be logged. Regards, Shan Lu sentitO Networks =20 >-----Original Message----- >From: Christer Holmberg (JO/LMF)=20 >[mailto:christer.holmberg@ericsson.com]=20 >Sent: Thursday, September 30, 2004 1:41 AM >To: 'Shan Lu'; 'IETF SIP Mailing List' >Subject: RE: [Sip] Question on RFC3261 Merged Requests > > > >Hi, > >Interesting point. > >One could argue that the existing text is ok for a normal SIP=20 >phone, because there is really no idea in receiving multiple=20 >"calls" (multiple "instances" of the same forked INVITE) from=20 >the same caller (in most cases the SIP phone can handle only=20 >one call at a time anyway, no matter if the incoming INVITEs=20 >origin from the same user or different users). > >However, for a gateway that may not be a valid case. Even if=20 >the gateway from a SIP perspective is a single SIP endpoint=20 >there are multiple end-users behind it, so IF we want to allow=20 >"forking" into the PSTN network (or whatever is on the other=20 >side) you are correct, I think. > >The problem I have with merged requests is that it takes away=20 >the advantages of only using the RFC3261 Via branch cookie=20 >from transaction identification. A node compliant with RFC3261=20 >will basically still have to use the "old" transaction mapping=20 >mechanism, in order the to the merge check... > >Regards, > >Christer Holmberg >Ericsson Finland > > > > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of >> Shan Lu >> Sent: 30. syyskuuta 2004 1:22 >> To: 'IETF SIP Mailing List' >> Subject: [Sip] Question on RFC3261 Merged Requests >>=20 >>=20 >> Hi, >>=20 >> RFC3261 has following text: >>=20 >> 8.2.2.2 Merged Requests >>=20 >> If the request has no tag in the To header field, the UAS=20 >core MUST >> check the request against ongoing transactions. If the From tag, >> Call-ID, and CSeq exactly match those associated with an ongoing >> transaction, but the request does not match that=20 >transaction (based >> on the matching rules in Section 17.2.3), the UAS core SHOULD >> generate a 482 (Loop Detected) response and pass it to the server >> transaction. >>=20 >> Assume that calls to support@example.com is forked to two=20 >> phone numbers on >> PSTN, say, 555-1111 and 555-2222. Further assume that there=20 >> is only one >> SIP-PSTN gateway. The two INVITEs arriving at the gw are=20 >> identical except >> for R-URI userinfo and top VIA branch (assuming forking proxy=20 >> is the only >> proxy).=20 >>=20 >> My question is: why should GW 482 second INVITE? Isn't that=20 >> the purpose of >> forking? Should 8.2.2.2 be modified as: >>=20 >> ... If request URI, the From tag, Call-ID, and CSeq exactly match ... >> ^^^^^^^^^^^^=20 >>=20 >> Regards,=20 >>=20 >> Shan Lu >> sentitO Networks >>=20 >>=20 >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >>=20 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 4 04:12:20 2004 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 EAA09949 for ; Mon, 4 Oct 2004 04:12:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEO6J-0004Wb-Kq for sip-web-archive@ietf.org; Mon, 04 Oct 2004 04:21:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CENsN-0005Zp-Rh; Mon, 04 Oct 2004 04:07:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CENlH-000485-Uh for sip@megatron.ietf.org; Mon, 04 Oct 2004 04:00:00 -0400 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 DAA09168 for ; Mon, 4 Oct 2004 03:59:57 -0400 (EDT) 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 1CENuJ-0001kT-FG for sip@ietf.org; Mon, 04 Oct 2004 04:09:20 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 04 Oct 2004 01:06:50 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i947xVdV029359; Mon, 4 Oct 2004 00:59:32 -0700 (PDT) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AXR46779; Mon, 4 Oct 2004 01:01:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) To: "sip@ietf.org WG" Message-Id: <6992A891-15DB-11D9-A60F-0003938AF740@cisco.com> From: Rohan Mahy Date: Mon, 4 Oct 2004 16:00:09 +0800 X-Mailer: Apple Mail (2.619) X-Spam-Score: 1.1 (+) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Rohan Mahy Subject: [Sip] New contact and availability info for 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: , Content-Type: multipart/mixed; boundary="===============0341537270==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 --===============0341537270== Content-Type: multipart/alternative; boundary=Apple-Mail-34-458009153 --Apple-Mail-34-458009153 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hello Everyone, My last day at Cisco is October 8th. I will be starting a new position at Airespace on November 1st. In the interim, you can contact me at the following email address: r o h a n ( a t ) e k a b a l ( d o t ) c o m Please also be aware that I will be traveling in Guatemala from October 12 till October 27 (Note that this period includes both draft deadlines). I will be only checking email irregularly during this time. See you all in Washington, DC. many thanks, -rohan --Apple-Mail-34-458009153 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit HelveticaHello Everyone, My last day at Cisco is October 8th. I will be starting a new position at Airespace on November 1st. In the interim, you can contact me at the following email address: r o h a n ( a t ) e k a b a l ( d o t ) c o m Please also be aware that I will be traveling in Guatemala from October 12 till October 27 (Note that this period includes both draft deadlines). I will be only checking email irregularly during this time. See you all in Washington, DC. many thanks, -rohan --Apple-Mail-34-458009153-- --===============0341537270== 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 --===============0341537270==-- From sip-bounces@ietf.org Tue Oct 5 11:33:47 2004 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 LAA08063 for ; Tue, 5 Oct 2004 11:33:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CErTK-00060j-Nw for sip-web-archive@ietf.org; Tue, 05 Oct 2004 11:43:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CErEa-0000Ps-L5; Tue, 05 Oct 2004 11:28:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEr90-00088h-TS for sip@megatron.ietf.org; Tue, 05 Oct 2004 11:22:26 -0400 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 LAA07307 for ; Tue, 5 Oct 2004 11:22:25 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CErIL-0004g4-Ag for sip@ietf.org; Tue, 05 Oct 2004 11:32:05 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i95FLtR13029 for ; Tue, 5 Oct 2004 11:21:55 -0400 (EDT) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Oct 2004 11:21:55 -0400 Message-ID: From: "Mary Barnes" To: "'sip@ietf.org'" Date: Tue, 5 Oct 2004 11:21:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Subject: [Sip] History-Info: Processing of Reason header in responses X-BeenThere: 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="===============1263634987==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d 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. --===============1263634987== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4AAEF.04A67099" 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_01C4AAEF.04A67099 Content-Type: text/plain Hi all, Per my posting on the SIPPING list, the currently agreed option for the Reason header proposal for redirection would impact the History-Info processing because it was never considered to capture the Reason header from a response as part of the History-Info entries, but rather the SIP response codes are used to generate a new Reason header associated with a specific retargeted-uri. Independent of whether the WG progresses the redirection reason proposal, there is a general issue as to whether the History-Info should use the Reason header in the responses in the case of retargeting. Per RFC 3328, you can have multiple Reason headers, however, only one SIP reason header. And, while the typical scenario for Reason header was for requests, it doesn't preclude the use of the header in responses. So, it does seem in terms of completeness, History-Info should specify the general processing if there is a Reason header in the response. I'm proposing to add some discussion to section 4.3.3.1.2 replacing the existing 1st sentence of the 1st paragraph: "For retargets that are the result of an explicit SIP response, the SIP Response Code that triggered the retargeting MUST be included in the Reason header field of the Request URI that has been retargeted." with something like the following: "For retargets that are the result of an explicit SIP response, a Reason header field MUST be included. If the SIP response does not include a Reason header, the SIP Response Code that triggered the retargeting MUST be included in the Reason header field of the Request URI that has been retargeted. If the response contains a non-SIP Reason header, it MUST be captured as an additional Reason associated with the Request URI that has been retargeted, along with the SIP Response Code. If the Reason header is a SIP reason, then it MUST be used rather than the SIP response code." I'd appreciate any concerns be raised by the end of this week (Oct. 8). Thanks, Mary H. Barnes mary.barnes@nortelnetworks.com ------_=_NextPart_001_01C4AAEF.04A67099 Content-Type: text/html Content-Transfer-Encoding: quoted-printable History-Info: Processing of Reason header in responses

Hi all,

Per my posting on the SIPPING list, = the currently agreed option for the Reason header proposal for = redirection would impact the History-Info processing because it was = never considered to capture the Reason header from a response as part = of the History-Info entries,  but rather the SIP response codes = are used to generate a new Reason header associated with a specific = retargeted-uri.  Independent of whether the WG progresses the = redirection reason proposal, there is a general issue as to whether the = History-Info should use the Reason header in the responses in the case = of retargeting.  Per RFC 3328, you can have multiple Reason = headers, however, only one SIP reason header.  And, while the = typical scenario for Reason header was for requests, it doesn't = preclude the use of the header in responses. 

So, it does seem in terms of = completeness, History-Info should specify the general processing if = there is a Reason header in the response.  I'm proposing to add = some discussion to section 4.3.3.1.2 replacing the existing 1st = sentence of the 1st paragraph:

"For retargets that are the = result of an explicit SIP response, the SIP Response Code that = triggered the retargeting MUST be included in the Reason header field = of the Request URI that has been retargeted."

 with something like the = following:
"For retargets that are the = result of an explicit SIP response, a Reason header field MUST be = included.  If the SIP response does not include a Reason header, = the SIP Response Code that triggered the retargeting MUST be included = in the Reason header field of the Request URI that has been = retargeted.  If the response = contains a non-SIP Reason header, it MUST be captured as an additional = Reason associated with the Request URI that has been retargeted, along = with the SIP Response Code.  If the Reason header is a SIP reason, = then it MUST be used rather than the SIP response code." =

I'd appreciate any concerns be raised = by the end of this week (Oct. 8).

Thanks,
Mary H. Barnes
mary.barnes@nortelnetworks.com

------_=_NextPart_001_01C4AAEF.04A67099-- --===============1263634987== 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 --===============1263634987==-- From sip-bounces@ietf.org Tue Oct 5 12:57:06 2004 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 MAA14323 for ; Tue, 5 Oct 2004 12:57:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEslz-00006p-Qf for sip-web-archive@ietf.org; Tue, 05 Oct 2004 13:06:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEsX0-0006CA-Qj; Tue, 05 Oct 2004 12:51:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEsQn-00059t-BL for sip@megatron.ietf.org; Tue, 05 Oct 2004 12:44:53 -0400 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 MAA13351 for ; Tue, 5 Oct 2004 12:44:50 -0400 (EDT) Received: from grads.ece.mcmaster.ca ([130.113.10.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEsa6-0006Ep-Vp for sip@ietf.org; Tue, 05 Oct 2004 12:54:31 -0400 Received: from power.eng.mcmaster.ca (PC-T13-Mohammed.Eng.McMaster.CA [130.113.184.38]) by grads.ece.mcmaster.ca (8.12.8/8.12.8) with ESMTP id i95GiHFW005821 for ; Tue, 5 Oct 2004 12:44:17 -0400 Message-ID: <4162CF84.9050509@power.eng.mcmaster.ca> Date: Tue, 05 Oct 2004 12:44:52 -0400 From: "m. smadi" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040115 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "sip@ietf.org WG" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Content-Transfer-Encoding: 7bit Subject: [Sip] SIP state diagram X-BeenThere: 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: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Is anyone aware of an existing state diagram for the current rfc? thanks moe smadi _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 5 14:37:59 2004 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 OAA23554 for ; Tue, 5 Oct 2004 14:37:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEuLb-0006uZ-5g for sip-web-archive@ietf.org; Tue, 05 Oct 2004 14:47:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEu5v-0006Rn-09; Tue, 05 Oct 2004 14:31:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEttv-0004mV-8o for sip@megatron.ietf.org; Tue, 05 Oct 2004 14:19:03 -0400 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 OAA22208 for ; Tue, 5 Oct 2004 14:18:57 -0400 (EDT) Received: from [206.176.144.210] (helo=kevlar.softarmor.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEu3B-0004UO-H9 for sip@ietf.org; Tue, 05 Oct 2004 14:28:38 -0400 Received: from [63.110.3.195] (dhcp195.dfw.dynamicsoft.com [63.110.3.195]) (authenticated bits=0) by kevlar.softarmor.com (8.12.11/8.12.11) with ESMTP id i95IIKJf009745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 5 Oct 2004 13:18:21 -0500 Message-ID: <4162E555.6000801@softarmor.com> Date: Tue, 05 Oct 2004 13:17:57 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) 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: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Subject: [Sip] Anybody planning on submitting a new -00 WG draft soon? X-BeenThere: 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 I've been asked to pre-approve any new working group (draft-ietf-sip-stuff-00) drafts in this submission cycle. Currently, I'm not aware of any. Anybody know better? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 6 04:27:49 2004 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 EAA01174 for ; Wed, 6 Oct 2004 04:27:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF7In-00009L-Rv for sip-web-archive@ietf.org; Wed, 06 Oct 2004 04:37:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF73z-0003Zu-7h; Wed, 06 Oct 2004 04:22:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF72r-0003NP-Gz for sip@megatron.ietf.org; Wed, 06 Oct 2004 04:21:09 -0400 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 EAA00767 for ; Wed, 6 Oct 2004 04:21:07 -0400 (EDT) Received: from smtp.dataconnection.com ([192.91.191.4] helo=smtp.datcon.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF7CG-0008Ct-O0 for sip@ietf.org; Wed, 06 Oct 2004 04:30:56 -0400 Received: by goodman.datcon.co.uk with Internet Mail Service (5.5.2657.72) id <4DP5KLLM>; Wed, 6 Oct 2004 09:20:29 +0100 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F803E53062@baker.datcon.co.uk> From: "Paul D.Smith" To: "'Jonathan Rosenberg'" Subject: RE: FW: [Sip-implementors] RE: [Sip] rfc3263 and rfc2915: trying next transport upon failure Date: Wed, 6 Oct 2004 09:20:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 1.0 (+) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 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: 1.0 (+) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Jonathan, Thanks for the clarification regarding the use of NAPTR records. Just so that we are 100% clear on the other cases, can you first confirm that an implementation is allowed to pick any transport it prefers, look for an SRV record and if one is found, use that transport? And as per the NAPTR example, if that transport fails, then no further transports are tried? But if no SRV records were found for the chosen transport, another transport may be chosen until either SRV records are found, or there are no further transports to try. And finally the final case of no SRV records. In this case the transport to use is UDP for SIP: URIs and TLS (over TCP) for SIPS: URIs. Agreed? Thanks, Paul D Smith Network Protocols Group Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com Fax: +44 20 8363 1039 Web: http://www.dataconnection.com -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: 29 September 2004 07:38 To: SIP Public Folder (E-mail) Subject: Re: FW: [Sip-implementors] RE: [Sip] rfc3263 and rfc2915: trying next transport upon failure Thanks for prodding me to answer this. I agree this is confusing. RFC 3261 seems to refer to the notion that you can change transports on different attempts (end of 8.1.2). However, RFC 3263 would seem to indicate that the NAPTR result would be a single service, and therefore, a single transport. The correct behavior is the latter. That is, the NAPTR processing will select a single transport, and that's what gets used. Previously, we were allowing attempts across transports because we were combining addresses from different SRV records and merging them. This was deemed a no-no by the DNS folks, due to the operational issues with comparing preference values across records. Once we eliminated this merging, the updated procedures in RFC 3263 effectively resulted in selection of a single transport, but this wasn't made fully consistent with RFC 3261. I've logged a bug against 3261 to clarify (http://bugs.sipit.net/sipwg/show_bug.cgi?id=760). Thanks, Jonathan R. Paul D.Smith wrote: > Jonathan, > > Can I please ask you to comment on the discussion Brett and I have been > having > via the WG regarding the use of NAPTR records? > > The question is whether the use of multiple transports, indicated by > multiple > NAPTR records, SRV records or client support for multiple transports should > be attempted or not. > > I can see an advantage to defining, say "TLS preferred over TCP over UDP" > but > this would only be useful under the "just try one transport" idea if the > client only supported one of the less preferred options. > > However the "try all in order" idea allows for, for example, a separate TLS > connection server to be preferred but for TCP to be acceptable (possibly > with > some restrictions imposed through other means) if the TLS server is > unavailable. > > So what is the intended processing? Also in either case, would you like to > raise a bugzilla report to ensure this is clarified in a future release of > the > specification? > > Thanks, > 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: Brett Tate [mailto:brett@broadsoft.com] > Sent: 17 September 2004 18:31 > To: SIP Public Folder (E-mail) > Subject: RE: [Sip-implementors] RE: [Sip] rfc3263 and rfc2915: trying > next transport upon failure > > > Hi Jonathan, > > Do you agree with Paul's interpretation > concerning advancement to the next transport > (next NAPTR record or set of SRV records)? > > My interpretation was that advancing > between transports has been removed. > > There are likely good reasons for and > against advancing between transports. > I am just trying to understand what > rfc3263, rfc2915, and rfc3261 indicate > or should have indicated. > > Thanks in advance, > Brett Tate > > > >>RFC3263, section 4.1, contains the following text >> >> If no NAPTR records are found, the client >> constructs SRV queries for those transport >> protocols it supports, and does a query for >> each. Queries are done using the service >> identifier "_sip" for SIP URIs and "_sips" >> for SIPS URIs. A particular transport is >> supported if the query is successful. The >> client MAY use any transport protocol it >> desires which is supported by the server. >> >>This means that potentially the set of >>SRV records covers multiple protocols in >>the case that no NAPTR records are returned. > > > I interpret the text as indicating that one > transport should be selected instead of > potentially combining the multiple sets of > srv records. > > >>It therefore seems only sensible to me >>that if multiple transports are indicated >>by NAPTR records, that they too should be >>tried, in the order indicated by the NAPTR >>records. > > > Hopefully there would have been a statement > indicating when to advance to the next NAPTR > record. Or there could have been a statement > indicating the combining of all the SRV records > for each NAPTR record. > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 6 04:46:09 2004 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 EAA02593 for ; Wed, 6 Oct 2004 04:46:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF7aX-0001MS-Vm for sip-web-archive@ietf.org; Wed, 06 Oct 2004 04:55:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF7Lg-0006ah-Ie; Wed, 06 Oct 2004 04:40:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF7Cg-000503-6n for sip@megatron.ietf.org; Wed, 06 Oct 2004 04:31:18 -0400 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 EAA01464 for ; Wed, 6 Oct 2004 04:31:14 -0400 (EDT) Received: from eukaryote123.gprs.suomen2g.fi ([62.78.106.123] helo=rautu.tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF7Lz-0000M7-Td for sip@ietf.org; Wed, 06 Oct 2004 04:41:03 -0400 Received: from rautu.tutpro.com (jh@localhost [127.0.0.1]) by rautu.tutpro.com (8.12.3/8.12.3/Debian-7.1) with ESMTP id i968UVXQ001718 for ; Wed, 6 Oct 2004 11:30:31 +0300 Received: (from jh@localhost) by rautu.tutpro.com (8.12.3/8.12.3/Debian-7.1) id i968UTsn001714; Wed, 6 Oct 2004 11:30:29 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16739.44325.802638.401548@rautu.tutpro.com> Date: Wed, 6 Oct 2004 11:30:29 +0300 From: Juha Heinanen To: sip@ietf.org X-Mailer: VM 7.17 under Emacs 21.2.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Subject: [Sip] verifying identity of sender X-BeenThere: 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: 7bit i read draft-ietf-sip-identity-03 and noticed that in order to use it, the domains must still have private/public certificates that are "valid back to a trusted CA". my domain tutpro.com has not purchased such certificate and i would bet that the same holds true for a VERY large percent of all internet domains. as long as this is true, the proposed identity verification solution may work in theory but not is practice. when thinking about this, i started to wonder if it would be possible for the UAS to verify the identity of the UAC from the domain via a few sip requests, i.e., by breaking this requirement: User agents that receive identity assurances must be able to validate these assurances without performing any network lookup. by the way, i don't think that this requirement holds true in the proposed solution either, since the uas must acquire the certificate of the signing domain, which may mean network lookup. so how about a certificate free system where the UAS authenticates the request with the domain by sending to the proxy of the domain a verification request? when the proxy receives the verification request it challenges the UAC and then replies to the UAS. comments? -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 6 08:20:12 2004 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 IAA17643 for ; Wed, 6 Oct 2004 08:20:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFAvi-0005th-O7 for sip-web-archive@ietf.org; Wed, 06 Oct 2004 08:30:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFAeZ-0002aP-Jf; Wed, 06 Oct 2004 08:12:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFAdR-0002Ah-Uo for sip@megatron.ietf.org; Wed, 06 Oct 2004 08:11:10 -0400 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 IAA16832 for ; Wed, 6 Oct 2004 08:11:07 -0400 (EDT) Received: from vmail.vsnl.com ([203.199.113.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFAml-0005EH-R4 for sip@ietf.org; Wed, 06 Oct 2004 08:20:58 -0400 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 <0I55006HHWHC93@vmail.vsnl.com> for sip@ietf.org; Wed, 06 Oct 2004 17:40:25 +0530 (IST) Received: from ([tataelxsi.co.in (203.197.168.145)]) by vmail.vsnl.com (InterScan E-Mail VirusWall Unix); Wed, 06 Oct 2004 17:40:25 +0530 (IST) Date: Wed, 06 Oct 2004 17:40:37 +0530 From: Rajeew Kumar Singh To: sip@ietf.org Message-id: <001501c4ab9d$7e0860f0$2f01080a@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: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7BIT Subject: [Sip] Far End Camera Control in SIP 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7BIT Hi, Can anybody provide some info on Far End Camera Control in SIP. Regards Rajeew _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 6 11:27:23 2004 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 LAA06686 for ; Wed, 6 Oct 2004 11:27:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFDqu-0001Zt-1l for sip-web-archive@ietf.org; Wed, 06 Oct 2004 11:37:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFDX6-0001Hl-UO; Wed, 06 Oct 2004 11:16:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFDTC-0000eq-HO for sip@megatron.ietf.org; Wed, 06 Oct 2004 11:12:46 -0400 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 LAA05717 for ; Wed, 6 Oct 2004 11:12:43 -0400 (EDT) Received: from [206.176.144.210] (helo=kevlar.softarmor.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFDcY-0000eM-FS for sip@ietf.org; Wed, 06 Oct 2004 11:22:37 -0400 Received: from [63.110.3.195] (dhcp195.dfw.dynamicsoft.com [63.110.3.195]) (authenticated bits=0) by kevlar.softarmor.com (8.12.11/8.12.11) with ESMTP id i96FBspK010806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Oct 2004 10:11:56 -0500 Message-ID: <41640B27.6000101@softarmor.com> Date: Wed, 06 Oct 2004 10:11:35 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] verifying identity of sender References: <16739.44325.802638.401548@rautu.tutpro.com> In-Reply-To: <16739.44325.802638.401548@rautu.tutpro.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Juha Heinanen wrote: > >so how about a certificate free system where the UAS authenticates the >request with the domain by sending to the proxy of the domain a >verification request? when the proxy receives the verification request >it challenges the UAC and then replies to the UAS. comments? > > > How would one authenticate the domain's proxy, such that a MITM could not substitute a proxy that would then falsely vouch for the UA? The usual answer for this is "check the proxy's cert" which of course circles us back onto the original argument. Other alternatives that might work would include something like a Kerberos model, but that leaves us with a problem of interdomain authentication which essentially boils down to the cert problem. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 6 11:43:25 2004 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 LAA07798 for ; Wed, 6 Oct 2004 11:43:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFE6Q-0002cD-Nu for sip-web-archive@ietf.org; Wed, 06 Oct 2004 11:53:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFDtB-0005N5-RM; Wed, 06 Oct 2004 11:39:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFDqE-0004pb-8O for sip@megatron.ietf.org; Wed, 06 Oct 2004 11:36:34 -0400 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 LAA07272 for ; Wed, 6 Oct 2004 11:36:31 -0400 (EDT) Received: from allozyme116.gprs.suomen2g.fi ([62.78.104.116] helo=rautu.tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFDzh-0002Ad-Ke for sip@ietf.org; Wed, 06 Oct 2004 11:46:24 -0400 Received: from rautu.tutpro.com (jh@localhost [127.0.0.1]) by rautu.tutpro.com (8.12.3/8.12.3/Debian-7.1) with ESMTP id i96FZoIT000915; Wed, 6 Oct 2004 18:35:50 +0300 Received: (from jh@localhost) by rautu.tutpro.com (8.12.3/8.12.3/Debian-7.1) id i96FZoru000911; Wed, 6 Oct 2004 18:35:50 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16740.4310.12199.820636@rautu.tutpro.com> Date: Wed, 6 Oct 2004 18:35:50 +0300 From: Juha Heinanen To: Dean Willis Subject: Re: [Sip] verifying identity of sender In-Reply-To: <41640B27.6000101@softarmor.com> References: <16739.44325.802638.401548@rautu.tutpro.com> <41640B27.6000101@softarmor.com> X-Mailer: VM 7.17 under Emacs 21.2.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Dean Willis writes: > How would one authenticate the domain's proxy, such that a MITM could > not substitute a proxy that would then falsely vouch for the UA? yes, my proposal doesn't offer 100 % security. but considering how much you get, it would still be good thing to do. very few sip users today authenticate the proxy they talk to. if that would be have been a requirement from the start, we would have very little sip usage in the first place. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 6 14:23:27 2004 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 OAA19655 for ; Wed, 6 Oct 2004 14:23:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFGbI-0004BW-4J for sip-web-archive@ietf.org; Wed, 06 Oct 2004 14:33:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFGNF-0007Vr-JX; Wed, 06 Oct 2004 14:18:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFGMH-0007An-KD for sip@megatron.ietf.org; Wed, 06 Oct 2004 14:17:49 -0400 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 OAA18856 for ; Wed, 6 Oct 2004 14:17:47 -0400 (EDT) Received: from [206.176.144.210] (helo=kevlar.softarmor.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFGVe-0003f2-0v for sip@ietf.org; Wed, 06 Oct 2004 14:27:41 -0400 Received: from [63.110.3.195] (dhcp195.dfw.dynamicsoft.com [63.110.3.195]) (authenticated bits=0) by kevlar.softarmor.com (8.12.11/8.12.11) with ESMTP id i96IGtdQ012170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Oct 2004 13:16:57 -0500 Message-ID: <41643684.3050407@softarmor.com> Date: Wed, 06 Oct 2004 13:16:36 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] verifying identity of sender References: <16739.44325.802638.401548@rautu.tutpro.com> <41640B27.6000101@softarmor.com> <16740.4310.12199.820636@rautu.tutpro.com> In-Reply-To: <16740.4310.12199.820636@rautu.tutpro.com> 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 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: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Juha Heinanen wrote: >Dean Willis writes: > > > How would one authenticate the domain's proxy, such that a MITM could > > not substitute a proxy that would then falsely vouch for the UA? > >yes, my proposal doesn't offer 100 % security. but considering how much >you get, it would still be good thing to do. very few sip users today >authenticate the proxy they talk to. if that would be have been a >requirement from the start, we would have very little sip usage in the >first place. > > Why? It works for HTTP. You wouldn't think of buying from a web site, doing banking, stock trades, or anything else sensitive without looking for the little padlock icon, would you? And if somebodody else did, and got ripped off, you'd laugh at them, right?. Well, I would, but you're probably a nicer guy and would just point out their security fault. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 6 14:32:38 2004 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 OAA20596 for ; Wed, 6 Oct 2004 14:32:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFGkC-0004xT-IG for sip-web-archive@ietf.org; Wed, 06 Oct 2004 14:42:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFGYx-0001wO-VT; Wed, 06 Oct 2004 14:30:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFGVn-0001G9-N6 for sip@megatron.ietf.org; Wed, 06 Oct 2004 14:27:41 -0400 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 OAA20159 for ; Wed, 6 Oct 2004 14:27:37 -0400 (EDT) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFGfL-0004Xz-9f for sip@ietf.org; Wed, 06 Oct 2004 14:37:31 -0400 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id i96IR6Pm006755; Wed, 6 Oct 2004 18:27:06 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Wed, 6 Oct 2004 14:27:05 -0400 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF422F@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'Juha Heinanen'" , sip@ietf.org Subject: RE: [Sip] verifying identity of sender Date: Wed, 6 Oct 2004 14:27:04 -0400 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: 0fa76816851382eb71b0a882ccdc29ac X-BeenThere: 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 Juha, Fundamentally, in the only context in which certificates are widely used today, a certificate is a contract that binds a set of keying material to a domain name. What we need here for sip-identity is a way of binding a set of keying material to a domain name. There are, of course, alternatives to certificates, like putting keying material in the DNS, and, I guess, relying on the DNS to "make a few SIP requests", as you suggest. However, the insecurity of the DNS at the moment makes these sorts of approaches problematic. Also, I think the security community is deeply suspicious of attempts to reinvent the certificate construct in some other way. This is what certificates are for: if we need this property, we should use certificates. Perhaps even more fundamentally, without TLS, sip-identity-03 would not work at all. TLS assumes that your SIP proxies have a domain certificate. People must be able to verify this certificate. TLS is mandatory-to-implement for SIP proxy servers according to RFC3261. In other words, I'm not requiring anything that isn't required of proxy servers by RFC3261 already. Finally, I don't really think certificates are prohibitively expensive, and so on. > by the way, i don't think that this requirement holds true in the > proposed solution either, since the uas must acquire the certificate of > the signing domain, which may mean network lookup. Yes, it may mean network lookup, but doesn't necessarily. There are certainly other ways for the UAS to acquire certificates. This system does not require a network lookup to work because certificates are self-verifying. Any system that relies on a network lookup is troublesome, generally, because caching credentials because very problematic. That much said, probably I should probably make the phrasing of that requirement more precise. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com] > Sent: Wednesday, October 06, 2004 1:30 AM > To: sip@ietf.org > Subject: [Sip] verifying identity of sender > > > i read draft-ietf-sip-identity-03 and noticed that in order to use it, > the domains must still have private/public certificates that are "valid > back to a trusted CA". > > my domain tutpro.com has not purchased such certificate and i would bet > that the same holds true for a VERY large percent of all internet > domains. as long as this is true, the proposed identity verification > solution may work in theory but not is practice. > > when thinking about this, i started to wonder if it would be possible > for the UAS to verify the identity of the UAC from the domain via a few > sip requests, i.e., by breaking this requirement: > > User agents that receive identity assurances must be able to > validate these assurances without performing any network lookup. > > by the way, i don't think that this requirement holds true in the > proposed solution either, since the uas must acquire the certificate of > the signing domain, which may mean network lookup. > > so how about a certificate free system where the UAS authenticates the > request with the domain by sending to the proxy of the domain a > verification request? when the proxy receives the verification request > it challenges the UAC and then replies to the UAS. comments? > > -- juha > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 6 14:47:29 2004 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 OAA21938 for ; Wed, 6 Oct 2004 14:47:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFGyZ-0005vo-9v for sip-web-archive@ietf.org; Wed, 06 Oct 2004 14:57:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFGkB-0003Ss-MR; Wed, 06 Oct 2004 14:42:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFGgd-0003A0-AL for sip@megatron.ietf.org; Wed, 06 Oct 2004 14:38:51 -0400 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 OAA21184 for ; Wed, 6 Oct 2004 14:38:49 -0400 (EDT) Received: from allozyme116.gprs.suomen2g.fi ([62.78.104.116] helo=rautu.tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFGq7-0005Cq-S1 for sip@ietf.org; Wed, 06 Oct 2004 14:48:43 -0400 Received: from rautu.tutpro.com (jh@localhost [127.0.0.1]) by rautu.tutpro.com (8.12.3/8.12.3/Debian-7.1) with ESMTP id i96Ic9IT001764; Wed, 6 Oct 2004 21:38:09 +0300 Received: (from jh@localhost) by rautu.tutpro.com (8.12.3/8.12.3/Debian-7.1) id i96Ic9IG001760; Wed, 6 Oct 2004 21:38:09 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16740.15249.191729.128450@rautu.tutpro.com> Date: Wed, 6 Oct 2004 21:38:09 +0300 From: Juha Heinanen To: Dean Willis Subject: Re: [Sip] verifying identity of sender In-Reply-To: <41643684.3050407@softarmor.com> References: <16739.44325.802638.401548@rautu.tutpro.com> <41640B27.6000101@softarmor.com> <16740.4310.12199.820636@rautu.tutpro.com> <41643684.3050407@softarmor.com> X-Mailer: VM 7.17 under Emacs 21.2.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Dean Willis writes: > Why? It works for HTTP. You wouldn't think of buying from a web site, > doing banking, stock trades, or anything else sensitive without looking > for the little padlock icon, would you? And if somebodody else did, and > got ripped off, you'd laugh at them, right?. Well, I would, but you're > probably a nicer guy and would just point out their security fault. online shopping is very much different application than sip applications. when you sell something, you can justify going through the trouble of buying a certificate (although i have heard that those are available under very loose basis and don't really prove much), but i don't see it a viable option for each sip proxy. take email as an example. it is an old application and still very few email servers use certificates to verify senders. i just repeat that a certificate free identity solution would prevent a very large percent of sip requests coming from faked senders. it would not protect against mitm attacks or dns hijacking, but those are much more difficult things to do that simply faking the from field of the request that is within the reach of anybody. it would thus make more sense to me to have a imperfect deployable solution rather than a "correct" solution that very few can deploy. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 6 14:53:53 2004 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 OAA22552 for ; Wed, 6 Oct 2004 14:53:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFH4l-0006PO-1k for sip-web-archive@ietf.org; Wed, 06 Oct 2004 15:03:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFGtE-0005Kr-6Y; Wed, 06 Oct 2004 14:51:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFGrV-0004uq-M3 for sip@megatron.ietf.org; Wed, 06 Oct 2004 14:50:05 -0400 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 OAA22182 for ; Wed, 6 Oct 2004 14:50:03 -0400 (EDT) Received: from allozyme116.gprs.suomen2g.fi ([62.78.104.116] helo=rautu.tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFH10-0005z7-QC for sip@ietf.org; Wed, 06 Oct 2004 14:59:58 -0400 Received: from rautu.tutpro.com (jh@localhost [127.0.0.1]) by rautu.tutpro.com (8.12.3/8.12.3/Debian-7.1) with ESMTP id i96InNIT001821; Wed, 6 Oct 2004 21:49:23 +0300 Received: (from jh@localhost) by rautu.tutpro.com (8.12.3/8.12.3/Debian-7.1) id i96InNpQ001817; Wed, 6 Oct 2004 21:49:23 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16740.15923.52064.449429@rautu.tutpro.com> Date: Wed, 6 Oct 2004 21:49:23 +0300 From: Juha Heinanen To: "Peterson, Jon" Subject: RE: [Sip] verifying identity of sender In-Reply-To: <7927C67249E4AD43BC05B539AF0D129801AF422F@stntexch04.cis.neustar.com> References: <7927C67249E4AD43BC05B539AF0D129801AF422F@stntexch04.cis.neustar.com> X-Mailer: VM 7.17 under Emacs 21.2.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Peterson, Jon writes: > However, the > insecurity of the DNS at the moment makes these sorts of approaches > problematic. Also, I think the security community is deeply suspicious of > attempts to reinvent the certificate construct in some other way. This is > what certificates are for: if we need this property, we should use > certificates. i didn't try to propose any new certificate construct. uas would just send a verification request to the proxy of the domain and would get back a reply. > Perhaps even more fundamentally, without TLS, sip-identity-03 would not work > at all. TLS assumes that your SIP proxies have a domain certificate. People > must be able to verify this certificate. TLS is mandatory-to-implement for > SIP proxy servers according to RFC3261. In other words, I'm not requiring > anything that isn't required of proxy servers by RFC3261 already. Finally, I > don't really think certificates are prohibitively expensive, and so > on. implementation of tls in the proxy is one thing and getting a certificate for it that is verifiable to a known CA is another thing. i can imagine that large operators can do it, but not small companies and private people who use sip more or less in peer-to-peer mode. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 6 17:01:00 2004 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 RAA12366 for ; Wed, 6 Oct 2004 17:01:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFJ3n-0000va-KY for sip-web-archive@ietf.org; Wed, 06 Oct 2004 17:10:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFIei-0006e0-HW; Wed, 06 Oct 2004 16:45:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFHnS-0008Uk-Cn for sip@megatron.ietf.org; Wed, 06 Oct 2004 15:49:58 -0400 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 PAA28819 for ; Wed, 6 Oct 2004 15:49:56 -0400 (EDT) Received: from [206.176.144.210] (helo=kevlar.softarmor.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFHwp-0001iU-Q3 for sip@ietf.org; Wed, 06 Oct 2004 15:59:51 -0400 Received: from [63.110.3.195] ([63.110.3.195]) (authenticated bits=0) by kevlar.softarmor.com (8.12.11/8.12.11) with ESMTP id i96Jn2vs013175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Oct 2004 14:49:05 -0500 Message-ID: <41644C1C.9090509@softarmor.com> Date: Wed, 06 Oct 2004 14:48:44 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" Subject: Re: [Sip] verifying identity of sender References: <7927C67249E4AD43BC05B539AF0D129801AF422F@stntexch04.cis.neustar.com> In-Reply-To: <7927C67249E4AD43BC05B539AF0D129801AF422F@stntexch04.cis.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, "'Juha Heinanen'" X-BeenThere: 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: 7bit Peterson, Jon wrote: >Yes, it may mean network lookup, but doesn't necessarily. There are >certainly other ways for the UAS to acquire certificates. This system does >not require a network lookup to work because certificates are >self-verifying. Any system that relies on a network lookup is troublesome, >generally, because caching credentials because very problematic. That much >said, probably I should probably make the phrasing of that requirement more >precise. > > Checking certificate revocation lists, which is an important part of TLS, does seem to require network lookup. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 6 17:14:44 2004 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 RAA15325 for ; Wed, 6 Oct 2004 17:14:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFJH7-0002Fp-2a for sip-web-archive@ietf.org; Wed, 06 Oct 2004 17:24:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFIh1-0000Vk-RG; Wed, 06 Oct 2004 16:47:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFI8W-0003Lp-Ss for sip@megatron.ietf.org; Wed, 06 Oct 2004 16:11:44 -0400 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 QAA02735 for ; Wed, 6 Oct 2004 16:11:42 -0400 (EDT) Received: from [206.176.144.210] (helo=kevlar.softarmor.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFII5-0003rS-1R for sip@ietf.org; Wed, 06 Oct 2004 16:21:37 -0400 Received: from [63.110.3.195] ([63.110.3.195]) (authenticated bits=0) by kevlar.softarmor.com (8.12.11/8.12.11) with ESMTP id i96KB2no013266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Oct 2004 15:11:03 -0500 Message-ID: <41645144.1000304@softarmor.com> Date: Wed, 06 Oct 2004 15:10:44 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] verifying identity of sender References: <16739.44325.802638.401548@rautu.tutpro.com> <41640B27.6000101@softarmor.com> <16740.4310.12199.820636@rautu.tutpro.com> <41643684.3050407@softarmor.com> <16740.15249.191729.128450@rautu.tutpro.com> In-Reply-To: <16740.15249.191729.128450@rautu.tutpro.com> 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 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: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Juha Heinanen wrote: >i just repeat that a certificate free identity solution would prevent a >very large percent of sip requests coming from faked senders. it would >not protect against mitm attacks or dns hijacking, but those are much >more difficult things to do that simply faking the from field of the >request that is within the reach of anybody. it would thus make more >sense to me to have a imperfect deployable solution rather than a >"correct" solution that very few can deploy. > > > It seems this has a lot in common with the MARID email work, which as I recall tried two approaches: 1) Putting keying material into DNS that a domain server could use to "sign" outbound email, thereby proving it had come from that domain 2) developing a sort of "outbound" MX record for DNS that indicates authoritative sender relays for a domain, allowing receivers to verify (by address matching) that the message had at least come through a server in the indicated domain. Both approaches are transitive trust models, with DNS dependencies, that vary by the strength of the trust mechanism. If one wished to "water down" identity for deployability one could essentially use the 3GPP approach of P-Asserted-Identity combined with veryifying that the Via header contains an entry listed in DNS as an authoritative proxy for the domain asserted in the P-Asserted-Identity header field, and trusting that said proxy enforced identity. This is a little lighter than polling said proxy, but does slightly less about MITMs, as another proxy in the chain might have changed the P-Asserted -Identity header field value. It may also be interesting to note that MARID apparently gave up in disgust at the patent situation. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 6 19:13:47 2004 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 TAA28116 for ; Wed, 6 Oct 2004 19:13:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFL8K-0002Ss-Va for sip-web-archive@ietf.org; Wed, 06 Oct 2004 19:23:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFKws-0007Wd-Gw; Wed, 06 Oct 2004 19:11:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFKvD-0007Jx-Sa for sip@megatron.ietf.org; Wed, 06 Oct 2004 19:10:11 -0400 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 TAA27971 for ; Wed, 6 Oct 2004 19:10:08 -0400 (EDT) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFL4e-0002Dd-9Y for sip@ietf.org; Wed, 06 Oct 2004 19:20:06 -0400 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id i96N9SPm019116; Wed, 6 Oct 2004 23:09:28 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Wed, 6 Oct 2004 19:09:28 -0400 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF4230@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'Juha Heinanen'" Subject: RE: [Sip] verifying identity of sender Date: Wed, 6 Oct 2004 19:09:28 -0400 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: 9ed51c9d1356100bce94f1ae4ec616a9 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: 50a516d93fd399dc60588708fd9a3002 Juha, > > However, the > > insecurity of the DNS at the moment makes these sorts of approaches > > problematic. Also, I think the security community is deeply suspicious of > > attempts to reinvent the certificate construct in some other way. This is > > what certificates are for: if we need this property, we should use > > certificates. > > i didn't try to propose any new certificate construct. uas would just > send a verification request to the proxy of the domain and would get > back a reply. I didn't mean that you were proposing a new model for certificates - I meant that you were trying to propose a new way of getting the same properties that we get from certificates. I think that is unnecessary and potentially very dangerously. > implementation of tls in the proxy is one thing and getting a > certificate for it that is verifiable to a known CA is another thing. i > can imagine that large operators can do it, but not small companies and > private people who use sip more or less in peer-to-peer mode. > Anyway, implementation has nothing to do with this. If you don't -do- TLS, you can't provide an Identity header; or rather, the assertion that Identity provides is valueless. Look, this isn't something where every user of a domain needs their own certificate, or something. This is a case where you need one cert for one domain. How much do certs cost? Probably as much as $350 a year, down to as little as $40 dollars a year. I'm sorry, but compared to the cost of operating a server, bandwidth, etc etc, I don't think this is such a tremendous impediment. Jon Peterson NeuStar, Inc. > -- juha > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 7 01:25:30 2004 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 BAA24826 for ; Thu, 7 Oct 2004 01:25:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFQw4-0008Bf-FV for sip-web-archive@ietf.org; Thu, 07 Oct 2004 01:35:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFQkY-0001Ak-Qj; Thu, 07 Oct 2004 01:23:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFQji-0000db-4a for sip@megatron.ietf.org; Thu, 07 Oct 2004 01:22:42 -0400 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 BAA24722 for ; Thu, 7 Oct 2004 01:22:40 -0400 (EDT) Received: from eukaryote161.gprs.suomen2g.fi ([62.78.106.161] helo=rautu.tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFQtI-00080s-8G for sip@ietf.org; Thu, 07 Oct 2004 01:32:40 -0400 Received: from rautu.tutpro.com (jh@localhost [127.0.0.1]) by rautu.tutpro.com (8.12.3/8.12.3/Debian-7.1) with ESMTP id i975M0wV001108; Thu, 7 Oct 2004 08:22:00 +0300 Received: (from jh@localhost) by rautu.tutpro.com (8.12.3/8.12.3/Debian-7.1) id i975Lxmm001104; Thu, 7 Oct 2004 08:22:00 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16740.53879.810148.870970@rautu.tutpro.com> Date: Thu, 7 Oct 2004 08:21:59 +0300 From: Juha Heinanen To: Dean Willis Subject: Re: [Sip] verifying identity of sender In-Reply-To: <41645144.1000304@softarmor.com> References: <16739.44325.802638.401548@rautu.tutpro.com> <41640B27.6000101@softarmor.com> <16740.4310.12199.820636@rautu.tutpro.com> <41643684.3050407@softarmor.com> <16740.15249.191729.128450@rautu.tutpro.com> <41645144.1000304@softarmor.com> X-Mailer: VM 7.17 under Emacs 21.2.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Dean Willis writes: > 1) Putting keying material into DNS that a domain server could use to > "sign" outbound email, thereby proving it had come from that domain > 2) developing a sort of "outbound" MX record for DNS that indicates > authoritative sender relays for a domain, allowing receivers to verify > (by address matching) that the message had at least come through a > server in the indicated domain. here nothing new needs to be put in dns. when uas receives invite, it gives back a provisional response, constructs the verify request including a hash of invite's from uri, call id and from tag, and then sends it out like any out-of-dialog request using the from uri as request uri. when the uac of the invite receives the verify request, it checks if it has any pending invite that matches the hash and responds either with 200 ok or some failure code. when uas receives the verify response it gives final response to the invite and that is it. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 7 09:01:54 2004 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 JAA13155 for ; Thu, 7 Oct 2004 09:01:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFY3q-0002cA-7i for sip-web-archive@ietf.org; Thu, 07 Oct 2004 09:11:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFXoZ-0004AA-9D; Thu, 07 Oct 2004 08:56:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFXlE-0003IO-FD for sip@megatron.ietf.org; Thu, 07 Oct 2004 08:52:44 -0400 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 IAA12349 for ; Thu, 7 Oct 2004 08:52:42 -0400 (EDT) Received: from [203.129.224.106] (helo=kr.aftek.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFXuu-00028S-GD for sip@ietf.org; Thu, 07 Oct 2004 09:02:46 -0400 Received: from [10.0.0.145] ([10.0.0.145]) by kr.aftek.com (8.11.6/8.11.6) with ESMTP id i97CqdL28250; Thu, 7 Oct 2004 18:22:39 +0530 Message-ID: <41653DE9.7090804@aftek.com> Date: Thu, 07 Oct 2004 18:30:25 +0530 From: vikram User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip-ietf , sip-implementors@cs.columbia.edu 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 Subject: [Sip] Nat traversal ! X-BeenThere: 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 Hello all , For symmetric NAT traversal , I tried my VoIP client with some free SBCs (termed as Out bound proxies also ) I could register with them and even call is established but there was no voice behind Symmetric NAT. 1. In the source code I am sending all my packets (sip as well as rtp) to SBCs's IP & port We are using same socket to send/recv rtp packet. It this enough ? 2. Do I have to do anything additionally ? 3. With the same set up X-lite(xten) worked , but our s/w could not . 4. we have compared x-lite packets with ours, they are very same. When we sniff packets at our ISP we could see packets coming in but our Symmetric NAT -router might be dropping them . If router blocks some traffic because of its symmetric Nature dose it respond with ICMP error messages ? how do i know that my router is dropping (specially when my router is a old and low end ) This is happening even if we are using a SBC. Our logic : 1.Check NAT type 2. If it is Symmetric NAT Send local IP & media port in SDP. Use SBC IP & port while sending anything (sip/rtp) any guess what is going wrong ? Please HELP !!!!! regards vikram _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 7 10:49:17 2004 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 KAA23484 for ; Thu, 7 Oct 2004 10:49:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFZjm-0001Ux-Dl for sip-web-archive@ietf.org; Thu, 07 Oct 2004 10:59:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFZSY-00078b-5A; Thu, 07 Oct 2004 10:41:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFZDl-000411-5v for sip@megatron.ietf.org; Thu, 07 Oct 2004 10:26:19 -0400 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 KAA19930 for ; Thu, 7 Oct 2004 10:26:14 -0400 (EDT) Received: from web53605.mail.yahoo.com ([206.190.37.38]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CFZNR-00088C-L9 for sip@ietf.org; Thu, 07 Oct 2004 10:36:20 -0400 Message-ID: <20041007142543.23384.qmail@web53605.mail.yahoo.com> Received: from [203.126.136.220] by web53605.mail.yahoo.com via HTTP; Thu, 07 Oct 2004 07:25:43 PDT Date: Thu, 7 Oct 2004 07:25:43 -0700 (PDT) From: Ranjit Avasarala Subject: Re: [Sip] Far End Camera Control in SIP To: rajeewsingh@tataelxsi.co.in In-Reply-To: <001501c4ab9d$7e0860f0$2f01080a@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Hi rajeev SIP is not the protocol of choice for far end camera control or for video conferencing. More ideal protocol would be H.324 and H.324M for 3GPP. Ranjit --- Rajeew Kumar Singh wrote: > > Hi, > Can anybody provide some info on Far End Camera > Control in SIP. > > Regards > Rajeew > > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip > ===== Regards Ranjit _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.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 Oct 7 11:50:55 2004 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 LAA28541 for ; Thu, 7 Oct 2004 11:50:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFahP-0005E5-4U for sip-web-archive@ietf.org; Thu, 07 Oct 2004 12:01:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFaN3-00042s-GC; Thu, 07 Oct 2004 11:39:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFaAo-0002bM-GK for sip@megatron.ietf.org; Thu, 07 Oct 2004 11:27:18 -0400 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 LAA26597 for ; Thu, 7 Oct 2004 11:27:15 -0400 (EDT) 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 1CFaKV-00042d-NW for sip@ietf.org; Thu, 07 Oct 2004 11:37:22 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 07 Oct 2004 08:41:51 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i97FQbwp016569; Thu, 7 Oct 2004 08:26:38 -0700 (PDT) Received: from [192.168.2.226] (rtp-vpn1-65.cisco.com [10.82.224.65]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id ASW97736; Thu, 7 Oct 2004 08:26:41 -0700 (PDT) User-Agent: Microsoft-Entourage/11.0.0.040405 Date: Thu, 07 Oct 2004 08:26:48 -0700 Subject: Re: [Sip] verifying identity of sender From: Cullen Jennings To: Juha Heinanen , "sip@ietf.org" Message-ID: In-Reply-To: <16739.44325.802638.401548@rautu.tutpro.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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 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 If you want a free certificate, have a look at http://cacert.org It sounds like the sort of scheme you discuss below would end up relying on the security of DNS which, short of DNSSec, is not very good. Certificates are not that hard to get but yes I agree they do take some effort. The problem is, no one has proposed an alternative solutions that does not use them and looks deployable. The current identity scheme adds a little extra work for the domain administrator and a close to zero cost. It does not add any additional per end user cost or effort. This seems pretty good compared to any alternatives that have been proposed. Cullen On 10/6/04 1:30 AM, "Juha Heinanen" wrote: > i read draft-ietf-sip-identity-03 and noticed that in order to use it, > the domains must still have private/public certificates that are "valid > back to a trusted CA". > > my domain tutpro.com has not purchased such certificate and i would bet > that the same holds true for a VERY large percent of all internet > domains. as long as this is true, the proposed identity verification > solution may work in theory but not is practice. > > when thinking about this, i started to wonder if it would be possible > for the UAS to verify the identity of the UAC from the domain via a few > sip requests, i.e., by breaking this requirement: > > User agents that receive identity assurances must be able to > validate these assurances without performing any network lookup. > > by the way, i don't think that this requirement holds true in the > proposed solution either, since the uas must acquire the certificate of > the signing domain, which may mean network lookup. > > so how about a certificate free system where the UAS authenticates the > request with the domain by sending to the proxy of the domain a > verification request? when the proxy receives the verification request > it challenges the UAC and then replies to the UAS. comments? > > -- juha > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 7 12:24:25 2004 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 MAA01646 for ; Thu, 7 Oct 2004 12:24:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFbDh-0007Sn-Rk for sip-web-archive@ietf.org; Thu, 07 Oct 2004 12:34:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFasL-0004JU-Hs; Thu, 07 Oct 2004 12:12:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFafc-0000L5-Eo for sip@megatron.ietf.org; Thu, 07 Oct 2004 11:59:08 -0400 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 LAA29262 for ; Thu, 7 Oct 2004 11:59:05 -0400 (EDT) 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 1CFapL-0005gT-VH for sip@ietf.org; Thu, 07 Oct 2004 12:09:12 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 07 Oct 2004 09:03:48 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i97FwVwp009126; Thu, 7 Oct 2004 08:58:31 -0700 (PDT) Received: from [192.168.2.226] (rtp-vpn1-65.cisco.com [10.82.224.65]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id ASX00394; Thu, 7 Oct 2004 08:58:32 -0700 (PDT) User-Agent: Microsoft-Entourage/11.0.0.040405 Date: Thu, 07 Oct 2004 08:58:37 -0700 Subject: Re: [Sip] verifying identity of sender From: Cullen Jennings To: Juha Heinanen , Dean Willis Message-ID: In-Reply-To: <16740.53879.810148.870970@rautu.tutpro.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit On 10/6/04 10:21 PM, "Juha Heinanen" wrote: > Dean Willis writes: > >> 1) Putting keying material into DNS that a domain server could use to >> "sign" outbound email, thereby proving it had come from that domain >> 2) developing a sort of "outbound" MX record for DNS that indicates >> authoritative sender relays for a domain, allowing receivers to verify >> (by address matching) that the message had at least come through a >> server in the indicated domain. > > here nothing new needs to be put in dns. when uas receives invite, it > gives back a provisional response, constructs the verify request > including a hash of invite's from uri, call id and from tag, and then > sends it out like any out-of-dialog request using the from uri as > request uri. when the uac of the invite receives the verify request, it > checks if it has any pending invite that matches the hash and responds > either with 200 ok or some failure code. when uas receives the verify > response it gives final response to the invite and that is it. > ok so my from says if X send you a message, then X can receive your reply. How does this help know who X is? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 7 17:55:05 2004 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 RAA02039 for ; Thu, 7 Oct 2004 17:55:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFgNs-0007Hb-7Z for sip-web-archive@ietf.org; Thu, 07 Oct 2004 18:05:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFg7m-00071S-IM; Thu, 07 Oct 2004 17:48:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFflu-0007Lm-V8 for sip@megatron.ietf.org; Thu, 07 Oct 2004 17:25:59 -0400 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 RAA28959 for ; Thu, 7 Oct 2004 17:25:56 -0400 (EDT) Received: from [206.176.144.210] (helo=kevlar.softarmor.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFfvM-0005d0-2l for sip@ietf.org; Thu, 07 Oct 2004 17:36:05 -0400 Received: from [63.110.3.195] ([63.110.3.195]) (authenticated bits=0) by kevlar.softarmor.com (8.12.11/8.12.11) with ESMTP id i97LNgfa010359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Oct 2004 16:23:43 -0500 Message-ID: <4165B3CF.8020707@softarmor.com> Date: Thu, 07 Oct 2004 16:23:27 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] verifying identity of sender 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: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Juha Heinanen X-BeenThere: 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 Cullen Jennings wrote: >>here nothing new needs to be put in dns. when uas receives invite, it >>gives back a provisional response, constructs the verify request >>including a hash of invite's from uri, call id and from tag, and then >>sends it out like any out-of-dialog request using the from uri as >>request uri. when the uac of the invite receives the verify request, it >>checks if it has any pending invite that matches the hash and responds >>either with 200 ok or some failure code. when uas receives the verify >>response it gives final response to the invite and that is it. >> >> >> > >ok so my from says if X send you a message, then X can receive your reply. >How does this help know who X is? > > Not quite. I INVITE you to a call. Upon sending the INVITE, my UA sends a PUBLISH to the softarmor.com server saying I really did send an INVITE to you, and including a hash of that INVITE. Hopefully, softarmor.com authenticates that PUBLISH message. You get the invite, wonder if it really came from someone who could authenticate as me to softarmor.com, poll that server (including the hash) and softarmor.com tells you "Yes, that INVITE came from somebody who could authenticate as Dean. Trust me." So, the strength of the assertion of softarmor.com as to my identity is contingent on two things: 1) The strength of your belief that the server you think is softarmor.com really is (and isn't somebody else just faking) 2) The strength of your belief in the functional integrity and authentication provided by softarmor.com In the simplest case, all that this technique proves is that whoever sent you the message is either 1) authenticated to the asserting server, or 2) capable of munging DNS or IP routing to intercept your request to the asserting server, making them sufficiently interesting to talk to anyhow. In the typical "dumb ISP" case, this is a weak assertion, but it's still much stronger than we get for email and would block the majority of source-fraud spam. But in a confederated environment, where servers might have IPSEC SAs or be linked by private, protected network, the assertion could be a bit stronger. Questions: 1) Is this imperfect solution so useful as to be worth specifying, even though we know it's not complete? 2) Is the benefit of the solution worth the additional 4 message overhead on every transaction? 3) Are there obvious optimizations, such as having the asserting server "learn" about the request by observation rather than explicit notification? 4) Could we just use a MARID approach, and configure "edge" proxies to discard inbound requests where the source IP address doesn't show in DNS as authoritative for the domain component of the From: address, thereby getting most of the benefit with less overhead? -- 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 Oct 8 02:10:16 2004 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 CAA21546 for ; Fri, 8 Oct 2004 02:10:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFo7A-00075u-6o for sip-web-archive@ietf.org; Fri, 08 Oct 2004 02:20:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFnuh-0006n2-Ji; Fri, 08 Oct 2004 02:07:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFnnQ-0003rB-MU for sip@megatron.ietf.org; Fri, 08 Oct 2004 02:00:04 -0400 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 CAA11262 for ; Fri, 8 Oct 2004 02:00:04 -0400 (EDT) Received: from vmail.vsnl.com ([203.199.113.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFnx7-0006vm-Ii for sip@ietf.org; Fri, 08 Oct 2004 02:10:16 -0400 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 <0I59001H34MXZY@vmail.vsnl.com> for sip@ietf.org; Fri, 08 Oct 2004 11:29:22 +0530 (IST) Received: from ([tataelxsi.co.in (203.197.168.145)]) by vmail.vsnl.com (InterScan E-Mail VirusWall Unix); Fri, 08 Oct 2004 11:29:21 +0530 (IST) Date: Fri, 08 Oct 2004 11:29:35 +0530 From: Rajeew Kumar Singh Subject: RE: [Sip] Far End Camera Control in SIP In-reply-to: <20041007142543.23384.qmail@web53605.mail.yahoo.com> To: "'Ranjit Avasarala'" Message-id: <000201c4acfb$fd7ea240$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=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7BIT Hi Ranjit, Now people have started working on SIP based video conferencing. What till now I came to know that the "support for Far End Camera Control by SIP User Agent" can be signalled by SDP using the "m" field giving support for H.224 like m:data 9000 RTP/AVP 100 Media Attribute(a):rtpmap:100 H224 This shows that the User Agent has support for Far End Camera Control. Now the Far End Camera Control messages can be carried in RTP during the conferencing. The User agent should be intelligent enough to know the RTP streams related to Far End Camera Control..and accordingly the Camera is controlled. Let me know if there is any misunderstanding on this part.. Thanks Rajeew -----Original Message----- From: Ranjit Avasarala [mailto:ranjsadh@yahoo.com] Sent: Thursday, October 07, 2004 7:56 PM To: rajeewsingh@tataelxsi.co.in Cc: sip@ietf.org Subject: Re: [Sip] Far End Camera Control in SIP Hi rajeev SIP is not the protocol of choice for far end camera control or for video conferencing. More ideal protocol would be H.324 and H.324M for 3GPP. Ranjit --- Rajeew Kumar Singh wrote: > > Hi, > Can anybody provide some info on Far End Camera > Control in SIP. > > Regards > Rajeew > > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip > ===== Regards Ranjit _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.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 Fri Oct 8 02:46:26 2004 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 CAA28221 for ; Fri, 8 Oct 2004 02:46:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFogA-0007kL-V0 for sip-web-archive@ietf.org; Fri, 08 Oct 2004 02:56:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFoRI-0001PP-0A; Fri, 08 Oct 2004 02:41:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFoOo-00012K-RD for sip@megatron.ietf.org; Fri, 08 Oct 2004 02:38:42 -0400 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 CAA27765 for ; Fri, 8 Oct 2004 02:38:41 -0400 (EDT) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFoYf-0007cM-Ga for sip@ietf.org; Fri, 08 Oct 2004 02:48:54 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id i986do7I009305 for ; Thu, 7 Oct 2004 23:39:50 -0700 (MST) Received: from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i986aINK017583 for ; Fri, 8 Oct 2004 01:36:19 -0500 Received: from motorola.com (ibis.miel.mot.com [217.1.84.158]) by hpux4.miel.mot.com (8.12.10/8.12.10) with ESMTP id i986eQI6019868; Fri, 8 Oct 2004 12:10:27 +0530 (IST) Message-ID: <416635E7.4040803@motorola.com> Date: Fri, 08 Oct 2004 12:08:31 +0530 From: Ranjit Avasarala Organization: motorola User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rajeewsingh@tataelxsi.co.in Subject: Re: [Sip] Far End Camera Control in SIP References: <000201c4acfb$fd7ea240$2a46010a@telxsi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.1 (++++) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ranjit@motorola.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: 4.1 (++++) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Hi Rajeev what u say is ok. I mean u can indicate support for 224 in SDP. But IP network is not capable of carrying delay sensitive information. Ranjit Rajeew Kumar Singh wrote: > Hi Ranjit, > Now people have started working on SIP based video conferencing. > What till now I came to know that the > "support for Far End Camera Control by SIP User Agent" > can be signalled by SDP using the "m" field giving support for H.224 > like > > m:data 9000 RTP/AVP 100 > Media Attribute(a):rtpmap:100 H224 > > This shows that the User Agent has support for Far End Camera Control. > Now the Far End Camera Control messages can be carried in RTP during the > conferencing. > The User agent should be intelligent enough to know the RTP streams related > to > Far End Camera Control..and accordingly the Camera is controlled. > > Let me know if there is any misunderstanding on this part.. > > Thanks > Rajeew > > > -----Original Message----- > From: Ranjit Avasarala [mailto:ranjsadh@yahoo.com] > Sent: Thursday, October 07, 2004 7:56 PM > To: rajeewsingh@tataelxsi.co.in > Cc: sip@ietf.org > Subject: Re: [Sip] Far End Camera Control in SIP > > > Hi rajeev > > SIP is not the protocol of choice for far end camera > control or for video conferencing. More ideal protocol > would be H.324 and H.324M for 3GPP. > > Ranjit > > --- Rajeew Kumar Singh > wrote: > > >>Hi, >> Can anybody provide some info on Far End Camera >>Control in SIP. >> >>Regards >>Rajeew >> >> >>_______________________________________________ >>Sip mailing list >>https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP >>Protocol >>Use sip-implementors@cs.columbia.edu for questions >>on current sip >>Use sipping@ietf.org for new developments on the >>application of sip >> > > > > ===== > Regards > Ranjit > > > > _______________________________ > Do you Yahoo!? > Declare Yourself - Register online to vote today! > http://vote.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 > -- Regards Ranjit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 8 07:53:43 2004 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 HAA16942 for ; Fri, 8 Oct 2004 07:53:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFtTa-0004rs-RA for sip-web-archive@ietf.org; Fri, 08 Oct 2004 08:03:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFtEB-0002mF-NK; Fri, 08 Oct 2004 07:48:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFt8v-00022a-Vh for sip@megatron.ietf.org; Fri, 08 Oct 2004 07:42:38 -0400 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 HAA16264 for ; Fri, 8 Oct 2004 07:42:37 -0400 (EDT) Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFtIm-0004XM-Rg for sip@ietf.org; Fri, 08 Oct 2004 07:52:52 -0400 Received: from dfnjgl21 (c-24-1-99-5.client.comcast.net[24.1.99.5]) by comcast.net (rwcrmhc11) with SMTP id <2004100811420001300c5uf8e> (Authid: sdawkins@comcast.net); Fri, 8 Oct 2004 11:42:00 +0000 Message-ID: <152b01c4ad2b$e310e230$0400a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <4165B3CF.8020707@softarmor.com> Subject: Re: [Sip] verifying identity of sender Date: Fri, 8 Oct 2004 06:42:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Spencer Dawkins 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 Content-Transfer-Encoding: 7bit > Questions: > > 2) Is the benefit of the solution worth the additional 4 message > overhead on every transaction? Dean/all - 2.a) is there anything that can be overlapped with this four-message exchange? The calling party UA can immediately publish its hashed INVITE, and isn't waiting for the softarmor server's response to do anything - no delay there. But I'm thinking the called party UA couldn't advance to Alerting without getting the hashed response - am I missing anything? I'm also thinking that an additional RTT from called party UA to calling party proxy would be more noticeable in wireless environments... Spencer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 8 10:12:47 2004 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 KAA26489 for ; Fri, 8 Oct 2004 10:12:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFveC-0007QU-OF for sip-web-archive@ietf.org; Fri, 08 Oct 2004 10:23:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFvLn-0000gY-3N; Fri, 08 Oct 2004 10:04:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFvFh-0005eS-FJ for sip@megatron.ietf.org; Fri, 08 Oct 2004 09:57:45 -0400 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 JAA24465 for ; Fri, 8 Oct 2004 09:57:44 -0400 (EDT) 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 1CFvPc-00072u-De for sip@ietf.org; Fri, 08 Oct 2004 10:08:01 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 08 Oct 2004 07:05:15 -0700 X-BrightmailFiltered: true Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i98Dv9IC020076; Fri, 8 Oct 2004 06:57:09 -0700 (PDT) Received: from [10.32.245.151] (stealth-10-32-245-151.cisco.com [10.32.245.151]) by imail.cisco.com (8.12.5/8.12.10) with SMTP id i98EC2ZH010684; Fri, 8 Oct 2004 07:12:03 -0700 In-Reply-To: <416635E7.4040803@motorola.com> References: <000201c4acfb$fd7ea240$2a46010a@telxsi.com> <416635E7.4040803@motorola.com> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: From: David R Oran Subject: Re: [Sip] Far End Camera Control in SIP Date: Fri, 8 Oct 2004 09:57:03 -0400 To: ranjit@motorola.com X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1097244725.132307"; x:"432000"; a:"rsa-sha1"; b:"nofws:3753"; e:"Iw=="; n:"zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBVeaRZ4yWEPclZ/2Mda" "s5Bs9RPWH0BGd3fx6j+txdOXarv4Y8kpMqTexCOMFlDmatpXDXfFj3VI9o4G7" "674gFTasaoPcvEfZCwcBgZD7T6sLZa3RTBUGzZqOshAMRpVek="; s:"camGcb3EO1COUIFMBo5Bs+GnYLmGWOsA3/sc47purgm/faI7ff5vBcPWyArzO" "mzkp6UEnpn9Z/Tafx/PlcXvL9zlPLSIZUlTRXwc1MM8e65UAc0muq1lZzGW7b" "ny54VwyrZ3sJBV3k+BSx/vo4aVvkIMXbKscYXLwXllPNTVzO8="; c:"From: David R Oran "; c:"Subject: Re: [Sip] Far End Camera Control in SIP"; c:"Date: Fri, 8 Oct 2004 09:57:03 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"19"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 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="===============0584901612==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 --===============0584901612== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-10-825023051" --Apple-Mail-10-825023051 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Oct 8, 2004, at 2:38 AM, Ranjit Avasarala wrote: > Hi Rajeev > > what u say is ok. I mean u can indicate support for 224 in SDP. But IP > network is not capable of carrying delay sensitive information. > Ah, I didn't know that! Thanks, that'll save me a lot of work. We can shut down SIP, SIPPING, MMUSIC, AVT, and DIFFSERV and move on to other things. dave. > Ranjit > > > > Rajeew Kumar Singh wrote: >> Hi Ranjit, >> Now people have started working on SIP based video conferencing. >> What till now I came to know that the >> "support for Far End Camera Control by SIP User Agent" >> can be signalled by SDP using the "m" field giving support for >> H.224 >> like >> m:data 9000 RTP/AVP 100 >> Media Attribute(a):rtpmap:100 H224 >> This shows that the User Agent has support for Far End Camera Control. >> Now the Far End Camera Control messages can be carried in RTP during >> the >> conferencing. >> The User agent should be intelligent enough to know the RTP streams >> related >> to >> Far End Camera Control..and accordingly the Camera is controlled. >> Let me know if there is any misunderstanding on this part.. >> Thanks >> Rajeew >> -----Original Message----- >> From: Ranjit Avasarala [mailto:ranjsadh@yahoo.com] >> Sent: Thursday, October 07, 2004 7:56 PM >> To: rajeewsingh@tataelxsi.co.in >> Cc: sip@ietf.org >> Subject: Re: [Sip] Far End Camera Control in SIP >> Hi rajeev >> SIP is not the protocol of choice for far end camera >> control or for video conferencing. More ideal protocol >> would be H.324 and H.324M for 3GPP. >> Ranjit >> --- Rajeew Kumar Singh >> wrote: >>> Hi, >>> Can anybody provide some info on Far End Camera >>> Control in SIP. >>> >>> Regards >>> Rajeew >>> >>> >>> _______________________________________________ >>> Sip mailing list >>> https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP >>> Protocol >>> Use sip-implementors@cs.columbia.edu for questions >>> on current sip >>> Use sipping@ietf.org for new developments on the >>> application of sip >>> >> ===== >> Regards >> Ranjit >> _______________________________ >> Do you Yahoo!? >> Declare Yourself - Register online to vote today! >> http://vote.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 > > > -- > Regards > Ranjit > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 --Apple-Mail-10-825023051 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFBZpyvjWaEtlTdKuYRAvK6AJ9fjVvpG9Q6q9SDYK2SyLB3ro0mBwCfWbLk T+MmBQPxFg9Gcj95tDdqvME= =7sjr -----END PGP SIGNATURE----- --Apple-Mail-10-825023051-- --===============0584901612== 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 --===============0584901612==-- From sip-bounces@ietf.org Fri Oct 8 10:40:28 2004 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 KAA00203 for ; Fri, 8 Oct 2004 10:40:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFw4z-0008EV-1w for sip-web-archive@ietf.org; Fri, 08 Oct 2004 10:50:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFvhi-0002Zt-1B; Fri, 08 Oct 2004 10:26:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFvSM-0003Mj-GW for sip@megatron.ietf.org; Fri, 08 Oct 2004 10:10:50 -0400 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 KAA26194 for ; Fri, 8 Oct 2004 10:10:49 -0400 (EDT) Received: from airwolf.sentito.com ([65.202.222.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CFvcI-0007Mx-Gp for sip@ietf.org; Fri, 08 Oct 2004 10:21:07 -0400 Received: (qmail 50634 invoked by uid 1014); 8 Oct 2004 14:10:09 -0000 Received: from shanlu@sentito.com by airwolf.sentito.com by uid 1002 with qmail-scanner-1.22 (clamdscan: 0.75. spamassassin: 2.63. Clear:RC:1(65.202.222.2):. Processed in 0.10917 secs); 08 Oct 2004 14:10:09 -0000 Received: from unknown (HELO SAJAK) (65.202.222.2) by airwolf.sentito.com with SMTP; 8 Oct 2004 14:10:09 -0000 From: "Shan Lu" To: "'IETF SIP Mailing List'" Subject: FW: [Sip] Question on RFC3261 Merged Requests - please respond Date: Fri, 8 Oct 2004 10:11:28 -0400 Message-ID: <001901c4ad40$b431c7d0$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 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: 25eb6223a37c19d53ede858176b14339 Content-Transfer-Encoding: quoted-printable Can someone - RFC3261 authors or otherwise - comment on this, please?=20 Regards, Shan Lu -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Shan Lu Sent: Friday, October 01, 2004 12:02 PM To: 'Christer Holmberg (JO/LMF)'; 'IETF SIP Mailing List' Subject: RE: [Sip] Question on RFC3261 Merged Requests Christer, I appreciate your comments. After thinking over the point you raised = (why old transaction mapping rules have to be used in 3261-compliant environment), I came to the conclusion that 8.2.2.2 is completely = broken.=20 My gateway example showed that at least when R-URI is different, second INVITE should not be automatically rejected on the basis that it shares = same call-id, cseq, and the from tag with an INVITE in a different = transaction. Even when the two INVITEs have identical R-URI, the fact that they may = have visited different proxies after being forked could make one of them more desirable than the other. The order they arrive at the UAS should not determine which one gets presented to user and which one gets discarded. = The protocol can not make that distinction. The forking proxy and calling UA both have built-in mechanisms to avoid = one single INVITE leading to two established dialogs. When it works, Section 8.2.2.2 is an optimization on top of that. And there are plenty of cases = it simply does not work. I propose two options moving forward: 1. strike out 8.2.2.2 completely, or 2. replace it with a note to say that UAS may receive INVITEs in = different transactions but with identical call-id, cseq, from tag, and possibly = same R-URI. UAS should be prepared to handle this situation as it would with = any other incoming INVITEs. I like to hear the list's opinion on this and whether it is a bug that should be logged. Regards, Shan Lu sentitO Networks =20 >-----Original Message----- >From: Christer Holmberg (JO/LMF)=20 >[mailto:christer.holmberg@ericsson.com]=20 >Sent: Thursday, September 30, 2004 1:41 AM >To: 'Shan Lu'; 'IETF SIP Mailing List' >Subject: RE: [Sip] Question on RFC3261 Merged Requests > > > >Hi, > >Interesting point. > >One could argue that the existing text is ok for a normal SIP=20 >phone, because there is really no idea in receiving multiple=20 >"calls" (multiple "instances" of the same forked INVITE) from=20 >the same caller (in most cases the SIP phone can handle only=20 >one call at a time anyway, no matter if the incoming INVITEs=20 >origin from the same user or different users). > >However, for a gateway that may not be a valid case. Even if=20 >the gateway from a SIP perspective is a single SIP endpoint=20 >there are multiple end-users behind it, so IF we want to allow=20 >"forking" into the PSTN network (or whatever is on the other=20 >side) you are correct, I think. > >The problem I have with merged requests is that it takes away=20 >the advantages of only using the RFC3261 Via branch cookie=20 >from transaction identification. A node compliant with RFC3261=20 >will basically still have to use the "old" transaction mapping=20 >mechanism, in order the to the merge check... > >Regards, > >Christer Holmberg >Ericsson Finland > > > > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of >> Shan Lu >> Sent: 30. syyskuuta 2004 1:22 >> To: 'IETF SIP Mailing List' >> Subject: [Sip] Question on RFC3261 Merged Requests >>=20 >>=20 >> Hi, >>=20 >> RFC3261 has following text: >>=20 >> 8.2.2.2 Merged Requests >>=20 >> If the request has no tag in the To header field, the UAS=20 >core MUST >> check the request against ongoing transactions. If the From tag, >> Call-ID, and CSeq exactly match those associated with an ongoing >> transaction, but the request does not match that=20 >transaction (based >> on the matching rules in Section 17.2.3), the UAS core SHOULD >> generate a 482 (Loop Detected) response and pass it to the server >> transaction. >>=20 >> Assume that calls to support@example.com is forked to two=20 >> phone numbers on >> PSTN, say, 555-1111 and 555-2222. Further assume that there=20 >> is only one >> SIP-PSTN gateway. The two INVITEs arriving at the gw are=20 >> identical except >> for R-URI userinfo and top VIA branch (assuming forking proxy=20 >> is the only >> proxy).=20 >>=20 >> My question is: why should GW 482 second INVITE? Isn't that=20 >> the purpose of >> forking? Should 8.2.2.2 be modified as: >>=20 >> ... If request URI, the From tag, Call-ID, and CSeq exactly match ... >> ^^^^^^^^^^^^=20 >>=20 >> Regards,=20 >>=20 >> Shan Lu >> sentitO Networks >>=20 >>=20 >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >>=20 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 8 10:56:55 2004 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 KAA01709 for ; Fri, 8 Oct 2004 10:56:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFwKv-0000Gp-0L for sip-web-archive@ietf.org; Fri, 08 Oct 2004 11:07:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFw68-0000R2-Ce; Fri, 08 Oct 2004 10:51:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFvsa-0005Bd-UK for sip@megatron.ietf.org; Fri, 08 Oct 2004 10:37:56 -0400 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 KAA00072 for ; Fri, 8 Oct 2004 10:37:55 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFw2X-0008BI-7Y for sip@ietf.org; Fri, 08 Oct 2004 10:48:13 -0400 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i98Eblpl000848; Fri, 8 Oct 2004 10:37:48 -0400 (EDT) Message-ID: <41668F0D.6040301@dynamicsoft.com> Date: Fri, 08 Oct 2004 08:58:53 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ragunath Devarasu Subject: Re: [Sip] Session timer issue resolutions 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: a1f9797ba297220533cb8c3f4bc709a8 Content-Transfer-Encoding: 7bit Cc: "'sip@ietf.org'" , Shriram Natarajan X-BeenThere: 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: dd7e0c3fd18d19cffdd4de99a114001d Content-Transfer-Encoding: 7bit OK, I think its fair to characterize this as a typo, and I will change it to >= during auth48. Thanks, Jonathan R. Ragunath Devarasu wrote: > One reason could be backward compatibility with older drafts which said: > > " If a Min-SE header is included > in the initial session refresh request, the value of the > Session-Expires MUST be equal to the value in Min-SE." > > I understand that we needed to relax this requirement and that is the reason > we have changed it to GREATER THAN. > > Assume that Session-Expires of already existing session is 300 seconds. > During session timer refresh, uac wants to put Min-SE along with > Session-Expires, it needs to put Min-SE: 299 and Session-Expires: 300 just > to satisfy GREATER THAN. If it would have been GREATER THAN or EQUAL TO, uac > could as well put Min-SE: 300 and Session-Expires: 300 > > Thanks > Ragunath > > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, September 15, 2004 8:43 PM > To: Shriram Natarajan > Cc: sip@ietf.org > Subject: Re: [Sip] Session timer issue resolutions > > I don't think there is really any difference between > and >= in this > case. Is there a specific reason you need equality? > > Also, do note that session timer has been approved by IESG. As such, any > changes to this specification need to be done during authors 48 hours. > Such changes are meant to address editorial/typo problems, and bugs in > the spec. New features, improvements, etc. are not permitted. > > Thanks, > Jonathan R. > > Shriram Natarajan wrote: > > >>Good day Jonathan, >> >>Why must the initial session refresh request have SE > MinSE (if present)? >> >>draft-15 section 7.1 says: >> >> >> If a Min-SE header is included >> in the initial session refresh request, the value of the >> Session-Expires MUST be greater than the value in Min-SE. >><< >> >>What is the problem in modifying this to say: >> >> >> >> If a Min-SE header is included >> in the initial session refresh request, the value of the >> Session-Expires MUST be greater than or equal to the value >> in Min-SE. >><< >> >> >>With best regards >>Shriram >> >> >> >> >>On 7/18/2004 2:03 PM, Jonathan Rosenberg wrote: >> >> >>>Folks, >>> >>>Over the past few months, there were a bunch of comments on the list >>>regarding the previous revision of session timer. That previous >>>revision, -13, was made to address IESG comments, as the document >>>completed working group last call and was making its way towards >>>approval. >>> >>>I'll summarize what was said and the conclusions that were reached. >>> >>>Comment: I never saw -13, what happened? >>> >>>Conclusion: There was some kind of secretariat problem, I don't know >>>why. It was resubmitted and a -14 appeared, with no content change >>>from -13. >>> >>>Comment: Making Min-SE a minimum of 90s is too low for applications >>>that want to know quickly when there is a failure, including billing. >>> >>>Conclusions: Usage of the session timer for such fine grained liveness >>>tests is simply out of scope. Session timer is explicitly designed to >>>deal with cleanup of old, stale state. >>> >>>There were some comments along the lines of, "don't impose this 90s >>>minimum because of philosophical objections to this usage". However, >>>the reason that the 90s minimum was introduces is not philosophical at >>>all. There was a REAL practical problem of sessions being >>>inappropriately timed out. Here is the example. We set up a call with >>>the minimum session timer. Half way through it, the client tries to >>>refresh. A few packets get lost, so the refresh takes a bit. However, >>>since the session timer was so small, the session gets torn down by >>>the peer UA and/or intermediaries. This is bad. The session should >>>continue as long as the refresh transaction can complete successfully, >>>if initiated halfway through the interval. Do a bit of math, and this >>>tells you that you need around a 90s minimum. >>> >>>A final point on this topic - I agree it would be useful for third >>>parties to get VERY fine grained notifications of session liveness and >>>failure. However, the session timer mechanism is just flat out >>>inappropriate for that. I think that, if this was the driving >>>requirement, you would define a totally different solution; something >>>that did very frequent, low-overhead messages (like a stun request for >>>example) directly between interested entitites. As such, if people >>>want a good way to solve this problem, please write some requirements >>>down, bring them forward, and we can work on it. But, session timer is >>>not going to EVER be good enough for 6s failure detections (6s was >>>explicitly mentioned in the thread as a goal). >>> >>>As such, I have not changed the 90s requirement. >>> >>>Comment: Paul made a comment, preferring the usage of "infinite" for a >>>UA and "indefinite" for a proxy, as a description of the default value >>>of the session timer (i.e., whats in place when nothing is >>>negotiated). Dean commented that IESG felt that this would not be >>>good, and that the document would have trouble passing with this change. >>> >>>Conclusion: The current wording stays. >>> >>> >>>Comment: the document defines "initial session refresh" as a >>>mid-dialog request, but it can happen in the middle of a dialog. >>> >>>Conclusion: this is a good point. I have fixed the terminology. >>> >>> >>>Comment: can session timer be used in SUBSCRIBE dialogs? >>> >>>Answer: I don't think its needed, since subscriptions have their own >>>way of refreshing. I see adding the session timer to that as >>>confusing. Granted, subscription durations aren't negotiated with >>>input from proxies, but I dont see why they'll care for the most part. >>>Invite sessions are different because of the heavy involvement from >>>intermediaries. >>> >>>Comment/Question: If UAC includes both Session-Expires and Min-SE in >>>an initial request, it is required to make the values the same >>>(section 7.1). Why??? >>> >>>Answer: >>> >>>Good question. Turns out this is a bug, and there is a historical >>>reason for it. >>> >>>First, you must pay attention to this bit in the security >>>considerations section: >>> >>> Next, consider the case of a rogue UAS that wishes to force a UAC to >>> generate refreshes at a rapid rate. In that case, the UAC has to >>> support session timer. The initial INVITE arrives at the rogue UAS, >>> which returns a 2xx with a very small session interval. The UAC uses >>> this timer, and quickly sends a refresh. Section 7.1 requires the UAC >>> to copy the current session interval into the Session-Expires header >>> field in the request. This enables the proxies to see the current >>> value. The proxies will reject this request, and provide a Min-SE >>> with a higher minimum. The UAC will then use this higher minimum. >>> Note, that if the proxies did not reject the request, but rather >>> proxied the request with a Min-SE header field, an attack would still >>> be possible. The UAS could discard this header field in a 2xx >>> response, and force the UAC to continue to generate rapid requests. >>> >>> From this, it is clear that for subsequent refreshes (rather than >>>initial ones), the session-expires should be placed into the request >>>as it was, allowing the chance for proxies to reject it. Note, >>>however, that the text above references section 7.1 which talks about >>>*initial* session refresh requests. Now, in an earlier version of the >>>document, the description of initial and subsequent behavior was >>>combined, and the section reference was valid. After it was split >>>apart, the functionality was inappropriately left in the section on >>>initial requests, and the reference also stayed in tact. >>> >>>The requirement is there in a slightly different form for subsequent >>>session refreshes: >>> >>> In a session refresh request sent within a dialog with an active >>> session timer, the Sesssion-Expires header field SHOULD be present. >>> When present, it MUST be equal to the maximum of the Min-SE header >>> field (recall that its default value when not present is 90 seconds) >>> and the current session interval. >>> >>>As such, I believe the constraint can be removed for initial requests. >>>I've fixed that (SE just has to be larger than Min-SE), and adjusted >>>the reference from the security considerations section. >>> >>>Now, the behavior for subsequent requests needs some further >>>consideration. Both strengths ought to be the same; there is no point >>>in making the Session Expires max(min,current) if its not going to be >>>present in the request. So, I changed the second MUST to a SHOULD, and >>>explained that you normally want this to avoid dos attacks, but can >>>remove it or set it larger if you want to "reset" the process and >>>compute a new Session expires. >>> >>> >>> >>>Comment: what if a proxy (such as that in an ALG) has a MAXIMUM timer >>>it can support? Can we reject a refresh request and include some kind >>>of max-se header field? >>> >>>Answer: >>> >>>You can't have it both ways. If you allow for rejection of requests >>>because an interval is above someones maximum, you can get a situation >>>where someones maximum is below someones minimum. This is unsolveable >>>by any protocol means - the constraint cannot be jointly met. So, >>>which is worse - having an interval thats longer than someone wants, >>>or shorter? I say, its worse to have one that is longer than someone >>>wants, because having one that is too short can generate a lot of >>>traffic and processing for everyone. Thus, for the purposes of being a >>>good sip citizen, it is better to have an interval be longer than you >>>might want. >>> >>>So, I have made no change to the spec. >>> >>>I'll post a separate note with the specific changes. >>> >>>-Jonathan R. >>> >> > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 8 11:17:11 2004 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 LAA03171 for ; Fri, 8 Oct 2004 11:17:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFweV-0000lJ-7a for sip-web-archive@ietf.org; Fri, 08 Oct 2004 11:27:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFwQj-0005AB-Aa; Fri, 08 Oct 2004 11:13:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFw7w-00011x-1A for sip@megatron.ietf.org; Fri, 08 Oct 2004 10:53:48 -0400 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 KAA01465 for ; Fri, 8 Oct 2004 10:53:47 -0400 (EDT) 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 1CFwHr-0000Bi-Oe for sip@ietf.org; Fri, 08 Oct 2004 11:04:05 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 08 Oct 2004 08:01:18 -0700 X-BrightmailFiltered: true Received: from whoami.cisco.com (IDENT:mirapoint@whoami.cisco.com [64.101.128.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i98ErBIC020371; Fri, 8 Oct 2004 07:53:12 -0700 (PDT) Received: from arunvenkw2k (arunvenk-w2k.cisco.com [64.101.150.172]) by whoami.cisco.com (MOS 3.4.5-GR) with ESMTP id AGE89940; Fri, 8 Oct 2004 09:53:12 -0500 (CDT) From: "Arunachalam Venkatraman \(arunvenk\)" To: "'Shan Lu'" , "'IETF SIP Mailing List'" Subject: RE: [Sip] Question on RFC3261 Merged Requests Date: Fri, 8 Oct 2004 09:53:12 -0500 Message-ID: <001201c4ad46$88befb30$ac966540@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal In-Reply-To: <001601c4a672$ac45bab0$eb00000a@SAJAK> X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: arunvenk@cisco.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: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Shan You are correct about this, In a gateway implementation I am familiar = with, the user part of the ReqUri are compared and if this also matches, a 482 response is sent to the second request. Otherwise, the second call is = set up to the distinctly different number. Venkat -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Shan Lu Sent: Wednesday, September 29, 2004 5:22 PM To: 'IETF SIP Mailing List' Subject: [Sip] Question on RFC3261 Merged Requests Hi, RFC3261 has following text: 8.2.2.2 Merged Requests If the request has no tag in the To header field, the UAS core MUST check the request against ongoing transactions. If the From tag, Call-ID, and CSeq exactly match those associated with an ongoing transaction, but the request does not match that transaction (based on the matching rules in Section 17.2.3), the UAS core SHOULD generate a 482 (Loop Detected) response and pass it to the server transaction. Assume that calls to support@example.com is forked to two phone numbers = on PSTN, say, 555-1111 and 555-2222. Further assume that there is only one SIP-PSTN gateway. The two INVITEs arriving at the gw are identical = except for R-URI userinfo and top VIA branch (assuming forking proxy is the = only proxy).=20 My question is: why should GW 482 second INVITE? Isn't that the purpose = of forking? Should 8.2.2.2 be modified as: ... If request URI, the From tag, Call-ID, and CSeq exactly match ... ^^^^^^^^^^^^=20 Regards,=20 Shan Lu sentitO Networks _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 8 13:23:34 2004 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 NAA12675 for ; Fri, 8 Oct 2004 13:23:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFycr-0003bb-AW for sip-web-archive@ietf.org; Fri, 08 Oct 2004 13:33:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFyQi-0002pd-Dh; Fri, 08 Oct 2004 13:21:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFyL5-0001ex-VF for sip@megatron.ietf.org; Fri, 08 Oct 2004 13:15:32 -0400 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 NAA12008 for ; Fri, 8 Oct 2004 13:15:30 -0400 (EDT) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFyV4-0003Ov-Kw for sip@ietf.org; Fri, 08 Oct 2004 13:25:51 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i98HDcW02546; Fri, 8 Oct 2004 20:13:39 +0300 (EET DST) X-Scanned: Fri, 8 Oct 2004 20:10:06 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i98HA61g016163; Fri, 8 Oct 2004 20:10:06 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00E935B6; Fri, 08 Oct 2004 20:10:06 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i98H9xY06362; Fri, 8 Oct 2004 20:09:59 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 8 Oct 2004 20:09:57 +0300 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 8 Oct 2004 20:09:58 +0300 Received: ESEBE054.NOE.Nokia.com 172.21.143.44 from 172.21.34.184 172.21.34.184 via HTTP with MS-WebStorage 6.0.6249 Received: from localhost by ESEBE054.NOE.Nokia.com; 08 Oct 2004 20:09:57 +0300 Subject: Re: [Sip] verifying identity of sender From: Aki Niemi To: ext Dean Willis In-Reply-To: <4165B3CF.8020707@softarmor.com> References: <4165B3CF.8020707@softarmor.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1097255397.14266.60.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 08 Oct 2004 20:09:57 +0300 X-OriginalArrivalTime: 08 Oct 2004 17:09:58.0021 (UTC) FILETIME=[A3836B50:01C4AD59] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , SIP WG , Juha Heinanen X-BeenThere: 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 On Fri, 2004-10-08 at 00:23, ext Dean Willis wrote: ...snip... > I INVITE you to a call. Upon sending the INVITE, my UA sends a PUBLISH > to the softarmor.com server saying I really did send an INVITE to you, > and including a hash of that INVITE. Hopefully, softarmor.com > authenticates that PUBLISH message. Uhh... I don't really want to nit-pick on this proposal, but this isn't the intended use of the PUBLISH method [1]. I guess if your UA sent the INVITE first to softarmor.com's outbound proxy, who in turn Digest-challenged for your proxy-authentication, then no PUBLISH would be needed. Cheers, Aki [1] From Abstract: ... The mechanism described in this document can be extended to support publication of any event state for which there exists an appropriate event package. It is not intended to be a general-purpose mechanism for transport of arbitrary data, as there are better-suited mechanisms for this purpose. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 8 14:45:49 2004 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 OAA21606 for ; Fri, 8 Oct 2004 14:45:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFzuR-0005ka-Vt for sip-web-archive@ietf.org; Fri, 08 Oct 2004 14:56:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFzcO-0006zm-KZ; Fri, 08 Oct 2004 14:37:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFzUP-0004Ud-Jt for sip@megatron.ietf.org; Fri, 08 Oct 2004 14:29:13 -0400 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 OAA18870 for ; Fri, 8 Oct 2004 14:29:14 -0400 (EDT) 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 1CFzeP-0005EG-Dj for sip@ietf.org; Fri, 08 Oct 2004 14:39:33 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 08 Oct 2004 11:34:08 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i98ISddX009628; Fri, 8 Oct 2004 11:28:41 -0700 (PDT) Received: from [10.32.131.15] ([10.32.131.15]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id ASY09483; Fri, 8 Oct 2004 11:28:40 -0700 (PDT) User-Agent: Microsoft-Entourage/11.0.0.040405 Date: Fri, 08 Oct 2004 11:28:48 -0700 Subject: Re: [Sip] verifying identity of sender From: Cullen Jennings To: Dean Willis Message-ID: In-Reply-To: <4165B3CF.8020707@softarmor.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Juha Heinanen X-BeenThere: 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 ok, ignoring the syntax of the message, what you have is A and B are proxies and A sends message to B with a token in it then B contacts A and verifies this. This works as well as B can believe that it reached A and not the attacker. Now consider the current identity proposal when A uses a self signed cert. A adds hash and sends message to B. B contacts A to get the certificate. If B decided to accept this certificate from someone that provides a self signed cert it can. This is just policy about how well it wants to believe it really is talking to B. I think that in this case, the identity scheme reduces to exactly the same basic message flow and security properties as your proposal below. On 10/7/04 2:23 PM, "Dean Willis" wrote: > Cullen Jennings wrote: > >>> here nothing new needs to be put in dns. when uas receives invite, it >>> gives back a provisional response, constructs the verify request >>> including a hash of invite's from uri, call id and from tag, and then >>> sends it out like any out-of-dialog request using the from uri as >>> request uri. when the uac of the invite receives the verify request, it >>> checks if it has any pending invite that matches the hash and responds >>> either with 200 ok or some failure code. when uas receives the verify >>> response it gives final response to the invite and that is it. >>> >>> >>> >> >> ok so my from says if X send you a message, then X can receive your reply. >> How does this help know who X is? >> >> > Not quite. > > I INVITE you to a call. Upon sending the INVITE, my UA sends a PUBLISH > to the softarmor.com server saying I really did send an INVITE to you, > and including a hash of that INVITE. Hopefully, softarmor.com > authenticates that PUBLISH message. > > You get the invite, wonder if it really came from someone who could > authenticate as me to softarmor.com, poll that server (including the > hash) and softarmor.com tells you "Yes, that INVITE came from somebody > who could authenticate as Dean. Trust me." > > So, the strength of the assertion of softarmor.com as to my identity is > contingent on two things: > > 1) The strength of your belief that the server you think is > softarmor.com really is (and isn't somebody else just faking) > 2) The strength of your belief in the functional integrity and > authentication provided by softarmor.com > > In the simplest case, all that this technique proves is that whoever > sent you the message is either 1) authenticated to the asserting > server, or 2) capable of munging DNS or IP routing to intercept your > request to the asserting server, making them sufficiently interesting to > talk to anyhow. > > In the typical "dumb ISP" case, this is a weak assertion, but it's still > much stronger than we get for email and would block the majority of > source-fraud spam. > > But in a confederated environment, where servers might have IPSEC SAs or > be linked by private, protected network, the assertion could be a bit > stronger. > > > Questions: > > 1) Is this imperfect solution so useful as to be worth specifying, even > though we know it's not complete? > > 2) Is the benefit of the solution worth the additional 4 message > overhead on every transaction? > > 3) Are there obvious optimizations, such as having the asserting server > "learn" about the request by observation rather than explicit notification? > > 4) Could we just use a MARID approach, and configure "edge" proxies to > discard inbound requests where the source IP address doesn't show in DNS > as authoritative for the domain component of the From: address, thereby > getting most of the benefit with less overhead? > > -- > Dean > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 8 15:07:38 2004 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 PAA24908 for ; Fri, 8 Oct 2004 15:07:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG0FZ-0006Sa-T8 for sip-web-archive@ietf.org; Fri, 08 Oct 2004 15:17:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFzut-0003DS-97; Fri, 08 Oct 2004 14:56:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFzqR-0001cD-Dm; Fri, 08 Oct 2004 14:51:59 -0400 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 OAA22241; Fri, 8 Oct 2004 14:52:00 -0400 (EDT) Received: from bzq-179-16-107.cust.bezeqint.net ([212.179.16.107] helo=accord-mail.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG00Q-0005vL-4p; Fri, 08 Oct 2004 15:02:19 -0400 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id <4H4TKGYB>; Fri, 8 Oct 2004 20:51:13 +0200 Message-ID: <8F669A5302C2264DBF6B856B4CBA68A0FEA3A3@accord-mail.israel.polycom.com> From: "Even, Roni" To: rajeewsingh@tataelxsi.co.in, sip@ietf.org Subject: RE: [Sip] Far End Camera Control in SIP Date: Fri, 8 Oct 2004 20:51:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C4AD67.C78362EF" X-Spam-Score: 0.0 (/) X-Scan-Signature: 92788d1b003e07b99aff407d30cf4598 Cc: avt@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: 08aa56e70047071f9a3037af5750d40e 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_01C4AD67.C78362EF Content-Type: text/plain Hi I just submitted a personal draft to the AVT about FECC. We try to see which working group item it should be Roni Even -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Rajeew Kumar Singh Sent: Wednesday, October 06, 2004 2:11 PM To: sip@ietf.org Subject: [Sip] Far End Camera Control in SIP Hi, Can anybody provide some info on Far End Camera Control in SIP. Regards Rajeew _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_01C4AD67.C78362EF Content-Type: text/plain; name="draft-even-avt-h224-00.txt" Content-Disposition: attachment; filename="draft-even-avt-h224-00.txt" Content-Transfer-Encoding: quoted-printable AVT R. = Even Internet-Draft = Polycom Expires: March 2, 2005 September = 2004 Far End Camera Control Payload Type draft-even-avt-h224-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 2, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document defines the syntax and the semantics of SDP parameters needed to support far end camera control protocol. In conversional video applications far end camera control protocol is used by participants to control the remote camera. The common used protocol is ITU H.281 over H.224. Even Expires March 2, 2005 [Page = 1] =0C Internet-Draft FECC September = 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . = 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . = 4 3. Far-end camera control protocol . . . . . . . . . . . . . . . = 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . = 6 4.1 Registration of MIME media type application/h224 . . . . . = 6 5. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . . = 7 5.1 Usage with the SDP Offer Answer Model . . . . . . . . . . = 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . = 8 7. Normative References . . . . . . . . . . . . . . . . . . . . . = 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . = 9 Intellectual Property and Copyright Statements . . . . . . . . = 10 Even Expires March 2, 2005 [Page = 2] =0C Internet-Draft FECC September = 2004 1. Introduction The ITU-T recommendation H.281 [ITU.281] specifies a protocol for = far end camera control. This protocol is carried in H.320 systems using H.224 [ITU.H224] H.323 annex Q specifies how to carry H.281/H.224 frames using RTP packets. The document will define the SDP[RFC2327]parameters needed to = support the above far end camera control protocol in systems that use SDP Even Expires March 2, 2005 [Page = 3] =0C Internet-Draft FECC September = 2004 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119[RFC2119] and indicate requirement levels for compliant RTP implementations. Even Expires March 2, 2005 [Page = 4] =0C Internet-Draft FECC September = 2004 3. Far-end camera control protocol This protocol is based on ITU-T H.281 running over ITU-T H.224 in an RTP/UDP channel. H.323 annex Q specifies how to build the RTP packets from the H.224 packets. Using far end camera control protocol in point to point calls and multipoint calls is described in H.281 and H.323 annex Q Even Expires March 2, 2005 [Page = 5] =0C Internet-Draft FECC September = 2004 4. IANA Considerations This section describes the MIME types and names associated with this payload format. The section registers the MIME types, as per RFC2048[RFC2048] 4.1 Registration of MIME media type application/h224 MIME media type name: application MIME subtype name: H224 Required parameters: None Optional parameters: None Encoding considerations: This type is only defined for transfer via RTP [RFC3550] Security considerations: See Section 6 Interoperability considerations: Terminals that will like to send = far end camera control command should use this MIME type, receivers who can not support the protocol will reject the channel. Published specification: RFC yyy Applications which use this media type: Video conferencing applications. Additional information: none Person and email address to contact for further information : Roni Even: roni.even@polycom.co.il Intended usage: COMMON Author/Change controller: Roni Even Even Expires March 2, 2005 [Page = 6] =0C Internet-Draft FECC September = 2004 5. SDP Parameters The MIME media type application/h224 string is mapped to fields in the Session Description Protocol (SDP) as follows: o The media name in the "m=3D" line of SDP MUST be application. The transport SHOULD be RTP and the payload type is dynamic. o The encoding name in the "a=3Drtpmap" line of SDP MUST be h224 = (the MIME subtype). o The clock rate in the "a=3Drtpmap" line MUST be 0. The recommended maximum bandwidth for this protocol is 6.4 kbit/sec. 5.1 Usage with the SDP Offer Answer Model When offering FECC using SDP in an Offer/Answer model[RFC3264] the following considerations are necessary. H.281 Far end camera control communication are uni-directional. H.224 is bi-directional and can be used to learn the capabilities of the remote video end point e.g how many cameras it has. The offer answer exchange will be dependent on the functionality of both side. The offerer will offer a sendonly channel if its camera can not be remotely controlled and if the offerer does not intend to use H.224 to learn the capabilities of the remote video endpoints. In all other cases, when the offerer camera can be remotely controlled and/or it intends to use H.224 capabilities negotiation, the offerer will offer a sendrecv channel. The answerer behavior will be as follows: If it receives an offer with sendonly it will answer with a recvonly if it supports far end camera control, otherwise it will ignore reject the offer. If it receives an offer with sendrecv and its camera can be remotely controlled it will answer with a sendrecv option. If its camera cannot be remotely control it will reject the offer but may later = try to remotely control the offerer's camera using this procedure. Even Expires March 2, 2005 [Page = 7] =0C Internet-Draft FECC September = 2004 6. Security Considerations RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550]. This implies that confidentiality of the media streams is achieved by encryption. A potential denial-of-service threat exists. The attacker can = inject pathological datagrams into the stream which may cause the receiver to move the camera randomly. The usage of authentication of at = least the RTP packet is RECOMMENDED As with any IP-based protocol, in some circumstances a receiver may be overloaded simply by the receipt of too many packets, either desired or undesired. Network-layer authentication may be used to discard packets from undesired sources, but the processing cost of the authentication itself may be too high. 7 Normative References [ITU.281] International Telecommunications Union, "A far end camera control protocol for videoconferences using H.224", ITU-T Recommendation H.281, November 1994. [ITU.H224] International Telecommunications Union, "A real time control protocol for simplex applications using the H.221 LSD/HSD/HLP channels.", ITU-T Recommendation H.224, February 2000. [ITU.H323] International Telecommunications Union, "Visual telephone systems and equipment for local area networks which provide a non-guaranteed quality of service", ITU-T Recommendation H.323, July 2003. [RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June Even Expires March 2, 2005 [Page = 8] =0C Internet-Draft FECC September = 2004 2002. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. Author's Address Roni Even Polycom 94 Derech Em Hamoshavot Petach Tikva 49130 Israel EMail: roni.even@polycom.co.il Even Expires March 2, 2005 [Page = 9] =0C Internet-Draft FECC September = 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed = to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. = Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use = of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository = at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on = an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE = REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Even Expires March 2, 2005 [Page = 10] =0C ------_=_NextPart_000_01C4AD67.C78362EF 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 ------_=_NextPart_000_01C4AD67.C78362EF-- From sip-bounces@ietf.org Mon Oct 11 00:21:45 2004 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 AAA11796 for ; Mon, 11 Oct 2004 00:21:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGrrQ-0006JN-9G for sip-web-archive@ietf.org; Mon, 11 Oct 2004 00:32:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGrdS-00067k-Ln; Mon, 11 Oct 2004 00:18:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGraX-00050P-Tc for sip@megatron.ietf.org; Mon, 11 Oct 2004 00:15:10 -0400 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 AAA11337 for ; Mon, 11 Oct 2004 00:15:06 -0400 (EDT) Received: from [206.176.144.210] (helo=kevlar.softarmor.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGrkq-0006Cj-Hy for sip@ietf.org; Mon, 11 Oct 2004 00:25:59 -0400 Received: from [127.0.0.1] (kevlar.softarmor.com [127.0.0.1]) by kevlar.softarmor.com (8.12.11/8.12.11) with ESMTP id i9B4E88p007316; Sun, 10 Oct 2004 23:14:08 -0500 Message-ID: <416A088F.4010608@softarmor.com> Date: Sun, 10 Oct 2004 23:14:07 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Sip] verifying identity of sender References: <4165B3CF.8020707@softarmor.com> <1097255397.14266.60.camel@localhost.localdomain> In-Reply-To: <1097255397.14266.60.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , SIP WG , Juha Heinanen X-BeenThere: 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: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Aki Niemi wrote: > On Fri, 2004-10-08 at 00:23, ext Dean Willis wrote: > ...snip... > >>I INVITE you to a call. Upon sending the INVITE, my UA sends a PUBLISH >>to the softarmor.com server saying I really did send an INVITE to you, >>and including a hash of that INVITE. Hopefully, softarmor.com >>authenticates that PUBLISH message. > > > Uhh... I don't really want to nit-pick on this proposal, but this isn't > the intended use of the PUBLISH method [1]. Absolutely true. > I guess if your UA sent the INVITE first to softarmor.com's outbound > proxy, who in turn Digest-challenged for your proxy-authentication, then > no PUBLISH would be needed. yes, that's true. > [1] From Abstract: > > ... > The mechanism described in this document can be extended to support > publication of any event state for which there exists an appropriate > event package. It is not intended to be a general-purpose mechanism > for transport of arbitrary data, as there are better-suited > mechanisms for this purpose. of course, one could certainly define an event package for "Pending Requests for Which I Might Need a Half-Assed Identity Voucher". Perhaps a modification of the UA State event package? This does give rise to the question of "How do we evaluate the appropriateness of new event packages?" which I suspect we'll be asked to do over the next year or so. Something to think about, as many of the proposals I've heard for new event packages had even less merit than the strawman above. -- 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 Oct 11 00:27:34 2004 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 AAA12449 for ; Mon, 11 Oct 2004 00:27:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGrx4-0006Rt-78 for sip-web-archive@ietf.org; Mon, 11 Oct 2004 00:38:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGrlJ-0007dI-S9; Mon, 11 Oct 2004 00:26:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGrj4-0007Ed-PX for sip@megatron.ietf.org; Mon, 11 Oct 2004 00:23:58 -0400 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 AAA12002 for ; Mon, 11 Oct 2004 00:23:55 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGrtX-0006M7-Nw for sip@ietf.org; Mon, 11 Oct 2004 00:34:48 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i9B4PFh2029223 for ; Sun, 10 Oct 2004 21:25:15 -0700 (MST) Received: from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i9B4Nps8029857 for ; Sun, 10 Oct 2004 23:23:55 -0500 Received: from motorola.com (ibis.miel.mot.com [217.1.84.158]) by hpux4.miel.mot.com (8.12.10/8.12.10) with ESMTP id i9B4PiI6027894; Mon, 11 Oct 2004 09:55:45 +0530 (IST) Message-ID: <416A0AD4.8020703@motorola.com> Date: Mon, 11 Oct 2004 09:53:48 +0530 From: Ranjit Avasarala Organization: motorola User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David R Oran , sip@ietf.org Subject: Re: [Sip] Far End Camera Control in SIP References: <000201c4acfb$fd7ea240$2a46010a@telxsi.com> <416635E7.4040803@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.1 (++++) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ranjit@motorola.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: 4.1 (++++) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: 7bit Hi What I meant by "IP network is not capable" is still IP network has to evolve and lot of work needs to be done to make it robustto carry delay sensitive data ..Thats why SIP, SIPPING, SIMPLE , etc groups are there.. Dave, Hope u have got what I meant. Ranjit David R Oran wrote: > > On Oct 8, 2004, at 2:38 AM, Ranjit Avasarala wrote: > >> Hi Rajeev >> >> what u say is ok. I mean u can indicate support for 224 in SDP. But IP >> network is not capable of carrying delay sensitive information. >> > Ah, I didn't know that! Thanks, that'll save me a lot of work. We can > shut down SIP, SIPPING, MMUSIC, AVT, and DIFFSERV and move on to other > things. > > dave. > >> Ranjit >> >> >> >> Rajeew Kumar Singh wrote: >> >>> Hi Ranjit, >>> Now people have started working on SIP based video conferencing. >>> What till now I came to know that the >>> "support for Far End Camera Control by SIP User Agent" >>> can be signalled by SDP using the "m" field giving support for H.224 >>> like >>> m:data 9000 RTP/AVP 100 >>> Media Attribute(a):rtpmap:100 H224 >>> This shows that the User Agent has support for Far End Camera Control. >>> Now the Far End Camera Control messages can be carried in RTP during the >>> conferencing. >>> The User agent should be intelligent enough to know the RTP streams >>> related >>> to >>> Far End Camera Control..and accordingly the Camera is controlled. >>> Let me know if there is any misunderstanding on this part.. >>> Thanks >>> Rajeew >>> -----Original Message----- >>> From: Ranjit Avasarala [mailto:ranjsadh@yahoo.com] >>> Sent: Thursday, October 07, 2004 7:56 PM >>> To: rajeewsingh@tataelxsi.co.in >>> Cc: sip@ietf.org >>> Subject: Re: [Sip] Far End Camera Control in SIP >>> Hi rajeev >>> SIP is not the protocol of choice for far end camera >>> control or for video conferencing. More ideal protocol >>> would be H.324 and H.324M for 3GPP. >>> Ranjit >>> --- Rajeew Kumar Singh >>> wrote: >>> >>>> Hi, >>>> Can anybody provide some info on Far End Camera >>>> Control in SIP. >>>> >>>> Regards >>>> Rajeew >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list >>>> https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP >>>> Protocol >>>> Use sip-implementors@cs.columbia.edu for questions >>>> on current sip >>>> Use sipping@ietf.org for new developments on the >>>> application of sip >>>> >>> ===== >>> Regards >>> Ranjit >>> _______________________________ >>> Do you Yahoo!? >>> Declare Yourself - Register online to vote today! >>> http://vote.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 >> >> >> >> -- >> Regards >> Ranjit >> >> >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP 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 -- Regards Ranjit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 11 00:31:18 2004 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 AAA12783 for ; Mon, 11 Oct 2004 00:31:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGs0f-0006YS-FG for sip-web-archive@ietf.org; Mon, 11 Oct 2004 00:42:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGrlL-0007dR-49; Mon, 11 Oct 2004 00:26:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGrkQ-0007MQ-SI for sip@megatron.ietf.org; Mon, 11 Oct 2004 00:25:22 -0400 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 AAA12136 for ; Mon, 11 Oct 2004 00:25:19 -0400 (EDT) Received: from [206.176.144.210] (helo=kevlar.softarmor.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGrut-0006NW-Uo for sip@ietf.org; Mon, 11 Oct 2004 00:36:12 -0400 Received: from [127.0.0.1] (kevlar.softarmor.com [127.0.0.1]) by kevlar.softarmor.com (8.12.11/8.12.11) with ESMTP id i9B4Oc4D007389; Sun, 10 Oct 2004 23:24:39 -0500 Message-ID: <416A0B06.5020604@softarmor.com> Date: Sun, 10 Oct 2004 23:24:38 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] verifying identity of sender 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: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Juha Heinanen X-BeenThere: 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 Cullen Jennings wrote: > ok, ignoring the syntax of the message, what you have is A and B are proxies > and A sends message to B with a token in it then B contacts A and verifies > this. This works as well as B can believe that it reached A and not the > attacker. A simple two-party reverse validity check can be handled more readily with a null-poassword digest authentication request, as proposed on the list a few years back. Actually, you need 3 parties to demonstrate the utility of Juha's proposal. Assume A, B, and C where A and C are UAs, and B is a proxy normally used by neither, but authoritative for the domain of A. A sends a message to C with a token in it, which C can then ask B to validate -- "Hey Dude, do you believe one of your people called A said this to me?" > Now consider the current identity proposal when A uses a self signed cert. > A adds hash and sends message to B. B contacts A to get the certificate. If > B decided to accept this certificate from someone that provides a self > signed cert it can. This is just policy about how well it wants to believe > it really is talking to B. I think that in this case, the identity scheme > reduces to exactly the same basic message flow and security properties as > your proposal below. err, not exactly sure I follow the above, as you seem to have B using A's cert to decide whether it is talking to itself. But the (relatively) important thing about this approach is that it does block attacks where somebody pretends to be A, but doesn't really have the wherewithal to either authenticate to B, or to subvert the mostly unprotected the B-C link. This is excatly the weakness that the majority of source-forged spammers use to deliver spam in today's world. -- Dean -- 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 Oct 11 01:45:52 2004 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 BAA17609 for ; Mon, 11 Oct 2004 01:45:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGtAp-0007m5-0f for sip-web-archive@ietf.org; Mon, 11 Oct 2004 01:56:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGsxu-0001vW-I4; Mon, 11 Oct 2004 01:43:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGsuD-0001T1-Tm for sip@megatron.ietf.org; Mon, 11 Oct 2004 01:39:33 -0400 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 BAA17190 for ; Mon, 11 Oct 2004 01:39:33 -0400 (EDT) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGt4h-0007fX-L0 for sip@ietf.org; Mon, 11 Oct 2004 01:50:24 -0400 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id i9B5d2Pm010042; Mon, 11 Oct 2004 05:39:02 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Mon, 11 Oct 2004 01:39:01 -0400 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF4238@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'Dean Willis'" , Cullen Jennings Subject: RE: [Sip] verifying identity of sender Date: Mon, 11 Oct 2004 01:38:59 -0400 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: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: sip@ietf.org, Juha Heinanen X-BeenThere: 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 Dean, Help me to understand your position here. Is it your position as WG chair that we need to scrap the existing identity work, and begin anew along the lines you describe below? Or would you like to pursue this work as a separate work item? Anyway, hypothetically exploring this line of thought, it seems that using PUBLISH to inform your local server of the hash of the INVTE you've sent is probably superfluous - why not just send the INVITE through the local server, and have it act as a proxy (along the lines of Question 3 in your original mail describing the scheme)? It can acquire whatever state it needs to as the request passes (including generating or copying the hash). If you don't do that, anyway, you prevent the domain from enforcing any identity policies on requests before they are sent. While this isn't strictly necessary for an identity system to operate, it does provide a number of beneficial properties. If you do just sent the INVITE through the local server, the only real difference between sip-identity-03 and your approach is whether the local server signs the hash with a cert or forces any verifier to do a dial-back. In fact, this variety of dial-back is remarkably similar to the authentication mechanism employed by Jabber. That much said, sip-identity-03 can also requires a dial-back, after a fashion, if the verifier does not already have the cert of the proxy server. So, once again, this is a question about how to provide a construct that links a domain name to some sort of credentials: cryptographically with certificates, or using the network with the DNS. A couple of things to note, beyond the general weaknesses of using the DNS already highlighted in this thread: - There can be more than one consumer of the identity information in a request; i.e., one or more intermediaries and/or the UAS might want to verify the hash. If a dial-back is required, we pay the network cost on a per-verifier basis. Of course, in sip-identity-03, if verifiers don't have the cert of the domain, they'll pay the network cost anyway. However, each verifier needs to pay that network cost only once per unique domain, not once per unique message. This can quickly become meaningful, even in the course of a single dialog. - In order to dial-back (not to mention PUBLISH) securely, one should use TLS. TLS entails the use of certs anyway, and requires the verifier to download a cert. So, it's not clear to me that the cert costs won't be paid anyway. Without TLS, anyway, you have to worry about more than just someone who is capable of munging DNS or IP routing - passive attackers could quite possibly confuse the verifier with forged responses to a poll to verify the hash. - This requires per-message state (i.e. the hash) to be maintained at the local server (as your proposed use of PUBLISH exemplifies). Managing an event database that changes for each message in your domain becomes intensive pretty quick. Of course, sip-identity-03 requires state to be kept at verifiers, in the form of certificates, but this is not per-message state, nor even per-sender state - it's per-sending-domain state. Moreover, for the most part this state is being kept where state belongs - in the UAs, not in intermediaries. Finally, let me add that the dial-back constraint in sip-identity-03 (deferencing the URI in the Identity-Info header to acquire the cert) is artificial - it's not necessary for this mechanism use the network. The originating UAC could of course include his domain's certificate in a request with a "cid:" URI in the Identity-Info header indicating the MIME body contain the cert. The UAC will know this cert, after all, because at the very least it will learn it when it forges a TLS connection to the authentication service. If we did this every time, there would never be any need for the verifier to poll the network. Of course, it would also make requests larger, and this is why the draft currently doesn't recommend the practice. But the fact that you can do things this way without impacting the strength of the solution shows, I think, the versatility of this approach. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Sunday, October 10, 2004 9:25 PM > To: Cullen Jennings > Cc: sip@ietf.org; Juha Heinanen > Subject: Re: [Sip] verifying identity of sender > > > Cullen Jennings wrote: > > ok, ignoring the syntax of the message, what you have is A > and B are proxies > > and A sends message to B with a token in it then B contacts > A and verifies > > this. This works as well as B can believe that it reached A > and not the > > attacker. > > > A simple two-party reverse validity check can be handled more readily > with a null-poassword digest authentication request, as > proposed on the > list a few years back. > > Actually, you need 3 parties to demonstrate the utility of > Juha's proposal. > > Assume A, B, and C where A and C are UAs, and B is a proxy > normally used > by neither, but authoritative for the domain of A. > > A sends a message to C with a token in it, which C can then ask B to > validate -- "Hey Dude, do you believe one of your people > called A said > this to me?" > > > > Now consider the current identity proposal when A uses a > self signed cert. > > A adds hash and sends message to B. B contacts A to get the > certificate. If > > B decided to accept this certificate from someone that > provides a self > > signed cert it can. This is just policy about how well it > wants to believe > > it really is talking to B. I think that in this case, the > identity scheme > > reduces to exactly the same basic message flow and security > properties as > > your proposal below. > > err, not exactly sure I follow the above, as you seem to have B using > A's cert to decide whether it is talking to itself. > > But the (relatively) important thing about this approach is > that it does > block attacks where somebody pretends to be A, but doesn't > really have > the wherewithal to either authenticate to B, or to subvert the mostly > unprotected the B-C link. This is excatly the weakness that > the majority > of source-forged spammers use to deliver spam in today's world. > > > -- > Dean > > -- > dean > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 11 12:35:11 2004 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 MAA20199 for ; Mon, 11 Oct 2004 12:35:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH3JJ-0002p1-DK for sip-web-archive@ietf.org; Mon, 11 Oct 2004 12:46:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH31z-0006iS-3L; Mon, 11 Oct 2004 12:28:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH2rj-0004eH-Dk for sip@megatron.ietf.org; Mon, 11 Oct 2004 12:17:39 -0400 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 MAA19126 for ; Mon, 11 Oct 2004 12:17:36 -0400 (EDT) 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 1CH328-0002Ts-4m for sip@ietf.org; Mon, 11 Oct 2004 12:28:34 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 11 Oct 2004 09:22:54 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9BGGlYJ019494; Mon, 11 Oct 2004 09:16:48 -0700 (PDT) Received: from [192.158.121.252] (ams-clip-vpn-dhcp4399.cisco.com [10.61.81.46]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id ASZ79305; Mon, 11 Oct 2004 09:16:50 -0700 (PDT) User-Agent: Microsoft-Entourage/11.0.0.040405 Date: Mon, 11 Oct 2004 16:08:08 +0200 Subject: Re: [Sip] verifying identity of sender From: Cullen Jennings To: Dean Willis Message-ID: In-Reply-To: <416A0B06.5020604@softarmor.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Juha Heinanen X-BeenThere: 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: 7bit inline ... On 10/11/04 6:24 AM, "Dean Willis" wrote: > Cullen Jennings wrote: >> ok, ignoring the syntax of the message, what you have is A and B are proxies >> and A sends message to B with a token in it then B contacts A and verifies >> this. This works as well as B can believe that it reached A and not the >> attacker. > > > A simple two-party reverse validity check can be handled more readily > with a null-poassword digest authentication request, as proposed on the > list a few years back. Hmm, I don't by the "handled more readily" part. I have looked at dial back and I believe it is harder to implement, results in weaker security in all cases, is not easier to deploy, and results in significantly higher load on proxies. I know that at first glance it seems like anything that does not involve PKI must be easier than anything that does but I don't think it is in this case. I will try and explain why later on in this email. > > Actually, you need 3 parties to demonstrate the utility of Juha's proposal. > > Assume A, B, and C where A and C are UAs, and B is a proxy normally used > by neither, but authoritative for the domain of A. > > A sends a message to C with a token in it, which C can then ask B to > validate -- "Hey Dude, do you believe one of your people called A said > this to me?" > Hmm suspect you often need another proxy that is authoritative for B to form the dialog but never mind. So the dial back proposal works something like A first gets this token, on a per call basis from B (it has to be per call to include enough in the token to stop cut and paste attacks). So B gets token, and hands to C. C does connection with B and verifies the token. Is that connection TLS protected? Alternative call flow using the Identity mechanism falls into two cases, one where B trusts A with B's private key. This would be the case for voice mail systems, large gateways, conference servers, and such but not typically the case for phones other than in domains with a very small number of phones. Keep in mind this thread started around domains that were too cheap to get a certificate from a well known CA. If B trusts A, then A can insert the identity header, send the call to C. If the cert is from a well known CA then CA then C can verify the identity of the sender. Note number of messages involved was 1. If B does not trust A, then A can send call to B using previous digest credential and B can insert identity header and send call to C and C can verify it. Message count 2. If B does not have a cert from a well known CA, it can still do the same things as before but C will need to fetch the cert from B. The *first* time this happens we add a +2 to the message count but it can be cached for later messages. > >> Now consider the current identity proposal when A uses a self signed cert. >> A adds hash and sends message to B. B contacts A to get the certificate. If >> B decided to accept this certificate from someone that provides a self >> signed cert it can. This is just policy about how well it wants to believe >> it really is talking to B. I think that in this case, the identity scheme >> reduces to exactly the same basic message flow and security properties as >> your proposal below. > > err, not exactly sure I follow the above, as you seem to have B using > A's cert to decide whether it is talking to itself. > Hopefully I cleared this up somewhat in the example of above. If this is not clear, then is is probably not clear to many people and we should spend some time at the next IETF meeting discussing why it is unclear and how to get it clear. > But the (relatively) important thing about this approach is that it does > block attacks where somebody pretends to be A, but doesn't really have > the wherewithal to either authenticate to B, or to subvert the mostly > unprotected the B-C link. This is excatly the weakness that the majority > of source-forged spammers use to deliver spam in today's world. > You are correct that the proxy to proxy link is were most SPAM gets inserted today but DNS dialback is not going to help this all that much (unless you assume DNSSec). That is why the email folks are so interested in the MASS working group which ends up with solutions very similar to SIP Identity. As a side note on DNS Sec - some people feel that PKI with delegated signing keys for every company failed because the big CAs were greedy. Perhaps they were not greed and that's just what it costs to run a CA - either way my argument stays the same. DNS Sec requires the people that run the top level domains to delegate to the sub domains and not be too greedy. Unfortunately, the companies that ran the CAs and the companies that will with run the DNS Sec TLDs are, surprise, surprise, the same companies. They may change their pricing but I believe they are just as likely to change their pricing on delegated CA certs as they are on sub domain signing) Dialback provides better security than nothing and does not require money to be sent to any CAs. The Identity draft as written provides a way to implement one thing and be able to simultaneously get a much better solution that does use CAs and also be able to get a solution that is better than Dialback and also does not require certificates from well known CA's. The level of security offered by Dialback is ok for some. Mostly for people that are willing to use no security but would like better as long as it cost them nothing. Identity can provide this (including the no extra cost part) People that need security better than none, usually need security well beyond what dialback can provide. Identity can provide that too. There is a large contingent of people that want real security available. This includes encrypted integrity protect communications to the person you think you are talking to. It's useless to have encrypted communications but not know who it is encrypted to. Identity meets the needs of knowing who you are talking to for this group of people and is much more deployable than a S/MIME cert for every UA. It's not clear to me what problem dialback solves that many deployments would care about. Today the B-C links are very well protected as they mostly run in IPSec tunnels between preconfigured links. The ones that are not all preconfigured can use mutual TLS. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 11 17:00:34 2004 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 RAA26863 for ; Mon, 11 Oct 2004 17:00:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH7SA-0004ST-8k for sip-web-archive@ietf.org; Mon, 11 Oct 2004 17:11:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH67L-0007gA-CN; Mon, 11 Oct 2004 15:45:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH65r-0006qg-9g; Mon, 11 Oct 2004 15:44:27 -0400 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 PAA09440; Mon, 11 Oct 2004 15:44:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH6GS-0007Va-CG; Mon, 11 Oct 2004 15:55:24 -0400 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CH5yy-0003kz-2x; Mon, 11 Oct 2004 15:37:20 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 11 Oct 2004 15:37:20 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: sip@ietf.org Subject: [Sip] Last Call: 'Update to the Session Initiation Protocol (SIP) Preconditions Framework' to Proposed Standard X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 The IESG has received a request from the Session Initiation Protocol WG to consider the following document: - 'Update to the Session Initiation Protocol (SIP) Preconditions Framework ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-10-25. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-rfc3312-update-03.txt _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 11 17:21:59 2004 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 RAA29808 for ; Mon, 11 Oct 2004 17:21:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH7mq-0005LI-AC for sip-web-archive@ietf.org; Mon, 11 Oct 2004 17:32:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH7Kn-00036W-Cz; Mon, 11 Oct 2004 17:03:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH6Oh-0000QJ-Dw for sip@megatron.ietf.org; Mon, 11 Oct 2004 16:03:55 -0400 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 QAA11785 for ; Mon, 11 Oct 2004 16:03:53 -0400 (EDT) Received: from [206.176.144.210] (helo=kevlar.softarmor.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH6Yx-0008FH-JE for sip@ietf.org; Mon, 11 Oct 2004 16:14:52 -0400 Received: from [63.110.3.195] ([63.110.3.195]) (authenticated bits=0) by kevlar.softarmor.com (8.12.11/8.12.11) with ESMTP id i9BK2f13014151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Oct 2004 15:02:43 -0500 Message-ID: <416AE6ED.2070009@softarmor.com> Date: Mon, 11 Oct 2004 15:02:53 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" Subject: Re: [Sip] verifying identity of sender References: <7927C67249E4AD43BC05B539AF0D129801AF4238@stntexch04.cis.neustar.com> In-Reply-To: <7927C67249E4AD43BC05B539AF0D129801AF4238@stntexch04.cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , sip@ietf.org, Juha Heinanen X-BeenThere: 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: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: 7bit Peterson, Jon wrote: >Dean, > >Help me to understand your position here. Is it your position as WG chair >that we need to scrap the existing identity work, and begin anew along the >lines you describe below? Or would you like to pursue this work as a >separate work item? > > > My position is that exploring Juha's suggested approach through list dicussion may provide enlightenment. I have not taken a position as chair on the appropriateness of this work. >Anyway, hypothetically exploring this line of thought, it seems that using >PUBLISH to inform your local server of the hash of the INVTE you've sent is >probably superfluous - why not just send the INVITE through the local >server, and have it act as a proxy (along the lines of Question 3 in your >original mail describing the scheme)? It can acquire whatever state it needs >to as the request passes (including generating or copying the hash). > > > This was previously suggested by Aki, and is inarguably true. It does, however, predicate sending the request through the proxy, which is not absolutely required to get the properties under discussion. In short, it's a useful optimization, but is no more revealing (and may, in fact obfuscate) the security properties being discussed in Juha's proposal, as I understand them. This approach is roughly analogous to the lightweight alternative I proposed earlier, which is "accept no requests from an external domain unless they came directly from the IP address of a proxy that is authoritative for that domain according to DNS". Again, this is not perfect security, but if combined with TCP (or self-signed TLS) at least blocks the vast majority of source-addres forgeries as seen in the world of email. >If you don't do that, anyway, you prevent the domain from enforcing any >identity policies on requests before they are sent. While this isn't >strictly necessary for an identity system to operate, it does provide a >number of beneficial properties. > > > Right. These properties were explicitly not part of Juha's proposal, so I constructed a discussion framework that did not exhibit them. >If you do just sent the INVITE through the local server, the only real >difference between sip-identity-03 and your approach is whether the local >server signs the hash with a cert or forces any verifier to do a dial-back. >In fact, this variety of dial-back is remarkably similar to the >authentication mechanism employed by Jabber. That much said, sip-identity-03 >can also requires a dial-back, after a fashion, if the verifier does not >already have the cert of the proxy server. > > > I believe that is correct. >So, once again, this is a question about how to provide a construct that >links a domain name to some sort of credentials: cryptographically with >certificates, or using the network with the DNS. > >A couple of things to note, beyond the general weaknesses of using the DNS >already highlighted in this thread: > >- There can be more than one consumer of the identity information in a >request; i.e., one or more intermediaries and/or the UAS might want to >verify the hash. If a dial-back is required, we pay the network cost on a >per-verifier basis. Of course, in sip-identity-03, if verifiers don't have >the cert of the domain, they'll pay the network cost anyway. However, each >verifier needs to pay that network cost only once per unique domain, not >once per unique message. This can quickly become meaningful, even in the >course of a single dialog. > > > Quite true, and a strong argument indeed. >- In order to dial-back (not to mention PUBLISH) securely, one should use >TLS. TLS entails the use of certs anyway, and requires the verifier to >download a cert. So, it's not clear to me that the cert costs won't be paid >anyway. Without TLS, anyway, you have to worry about more than just someone >who is capable of munging DNS or IP routing - passive attackers could quite >possibly confuse the verifier with forged responses to a poll to verify the >hash. > > > That depends to a great extent on your definition of "secure". There is, in a practical sense, a significant difference between state-of-the-art (or state of the imagination, in some cases) security and "things that can be done very esaily and help prevent real problems." Since someone with paractical experience running a consumer network raised the question along with the argument that the identity approach might be difficult for them to deploy, it seems like it might be worth discussing the issues. Or in short, "Security doesn't have to be perfect to be useful". So, does Juha's approach offer any security benefits over simpler hacks, like my source-to-authority matching requirement? If it does, then let's understand those properties and see if any sort of standardization is needed. If not, then let's see what properties really are useful, and see if we need to document practices that exploit those properties for the operator community. >- This requires per-message state (i.e. the hash) to be maintained at the >local server (as your proposed use of PUBLISH exemplifies). Managing an >event database that changes for each message in your domain becomes >intensive pretty quick. Of course, sip-identity-03 requires state to be kept >at verifiers, in the form of certificates, but this is not per-message >state, nor even per-sender state - it's per-sending-domain state. Moreover, >for the most part this state is being kept where state belongs - in the UAs, >not in intermediaries. > > Absolutely true, and again a very strong argument. >Finally, let me add that the dial-back constraint in sip-identity-03 >(deferencing the URI in the Identity-Info header to acquire the cert) is >artificial - it's not necessary for this mechanism use the network. The >originating UAC could of course include his domain's certificate in a >request with a "cid:" URI in the Identity-Info header indicating the MIME >body contain the cert. The UAC will know this cert, after all, because at >the very least it will learn it when it forges a TLS connection to the >authentication service. If we did this every time, there would never be any >need for the verifier to poll the network. Of course, it would also make >requests larger, and this is why the draft currently doesn't recommend the >practice. But the fact that you can do things this way without impacting the >strength of the solution shows, I think, the versatility of this approach. > > All true. But as Juha said, this approach requires gettting a valid, signed, checkable cert, which is non-trivial. I've been running my own fake CA for years, and I don't have any "real" certs to use. Do you? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 11 17:30:22 2004 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 RAA00643 for ; Mon, 11 Oct 2004 17:30:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH7v0-0005ax-NQ for sip-web-archive@ietf.org; Mon, 11 Oct 2004 17:41:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH7YA-0001BQ-Sq; Mon, 11 Oct 2004 17:17:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH6kC-00085Y-RA for sip@megatron.ietf.org; Mon, 11 Oct 2004 16:26:08 -0400 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 QAA17988 for ; Mon, 11 Oct 2004 16:26:06 -0400 (EDT) Received: from [206.176.144.210] (helo=kevlar.softarmor.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH6um-0001YF-AI for sip@ietf.org; Mon, 11 Oct 2004 16:37:06 -0400 Received: from [63.110.3.195] ([63.110.3.195]) (authenticated bits=0) by kevlar.softarmor.com (8.12.11/8.12.11) with ESMTP id i9BKPFlZ014293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Oct 2004 15:25:17 -0500 Message-ID: <416AEC37.8050406@softarmor.com> Date: Mon, 11 Oct 2004 15:25:27 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] verifying identity of sender 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: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Juha Heinanen X-BeenThere: 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: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > >>Actually, you need 3 parties to demonstrate the utility of Juha's proposal. >> >>Assume A, B, and C where A and C are UAs, and B is a proxy normally used >>by neither, but authoritative for the domain of A. >> >>A sends a message to C with a token in it, which C can then ask B to >>validate -- "Hey Dude, do you believe one of your people called A said >>this to me?" >> >> >> > >Hmm suspect you often need another proxy that is authoritative for B to form >the dialog but never mind. > >So the dial back proposal works something like A first gets this token, on >a per call basis from B (it has to be per call to include enough in the >token to stop cut and paste attacks). So B gets token, and hands to C. C >does connection with B and verifies the token. Is that connection TLS >protected? > > > Doesn't have to be. Remember, the scenario we're working from is someone faking a sender address in their otherwise normal endpoint, without the ability (or requirement) of intervening in normal network operations or altering DNS for the domain in question. >Alternative call flow using the Identity mechanism falls into two cases, one >where B trusts A with B's private key. This would be the case for voice mail >systems, large gateways, conference servers, and such but not typically the >case for phones other than in domains with a very small number of phones. >Keep in mind this thread started around domains that were too cheap to get a >certificate from a well known CA. > > > Huh? I doubt Cisco is going to hand you the private key to their proxy so that you can use it to sign requests. Consequently we fall into the second case for all real deployments. >If B trusts A, then A can insert the identity header, send the call to C. If >the cert is from a well known CA then CA then C can verify the identity of >the sender. Note number of messages involved was 1. > >If B does not trust A, then A can send call to B using previous digest >credential and B can insert identity header and send call to C and C can >verify it. Message count 2. > >If B does not have a cert from a well known CA, it can still do the same >things as before but C will need to fetch the cert from B. The *first* time >this happens we add a +2 to the message count but it can be cached for later >messages. > > > Excellent point. If C trusts that B is authoritative for the domain of A, then C has as much reason to trust a cert delivered by B as it does to trust an assertion on A's behalf made by B. This obviates the need for dial backs (except, of course, for certificate revocation issues) for the life of the cert, if we use an identity-assertion-by-signing approach. Now, what does this get us that just having C verify 1) That B is authoritative for the domain of A according to DNS, and that 2) that the request came from the IP address of B, according to DNS, to the extent that a TCP socket could from. You're doing the same exact thing, when you have C trust DNS and the routing path to B in order to fetch the cert from B. As far, as I know, all the crypto you've outlined falls back to assumptions that are just as supportable in the non-crypto solution I counter-proposed to Juha, with a lot less CPU effort and network traffic required. One different property is that both assertion-by-signing and assertion-by-dialback can be "checked" multiple hops down the router-chain, whereas assertion-by-source-address cannot. Is this critical for real-world deployments? ... section elided ... > > >>But the (relatively) important thing about this approach is that it does >>block attacks where somebody pretends to be A, but doesn't really have >>the wherewithal to either authenticate to B, or to subvert the mostly >>unprotected the B-C link. This is excatly the weakness that the majority >>of source-forged spammers use to deliver spam in today's world. >> >> >> > > >It's not clear to me what problem dialback solves that many deployments >would care about. Today the B-C links are very well protected as they mostly >run in IPSec tunnels between preconfigured links. The ones that are not all >preconfigured can use mutual TLS. > > > Well, last week I tried to send an email to somebody at RoadRunner, who bounced the email because the netblock (PTR) delegation for the address of my mail server du jour wasn't right. It turns out it's REALLY difficult for ISPs to get this right. Certainly the B-C link between my email server and their email server isn't going to be IPSec protected anytime soon. But if they'd been able to just look at DNS and say "Whaddya know. That email DID come through the MX for softarmor.com", things would have been ok. We don't do that for mail, because many companies run diassgregated inbound and outbound mail servers, and MX records only describe inbound servers. And once again, remember that this thread was started by somebody (NOT ME ;-) ) who runs a REAL SIP NETWORK, is impacted by this problem in the real world, is looking for an adequate, deployable solution, and hasn't been able to make registered certs appear to be financially attractive. -- 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 Oct 11 19:33:56 2004 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 TAA10340 for ; Mon, 11 Oct 2004 19:33:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH9qc-0007z1-KW for sip-web-archive@ietf.org; Mon, 11 Oct 2004 19:44:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH9be-00039j-Tj; Mon, 11 Oct 2004 19:29:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH9Tv-0001KP-Uv for sip@megatron.ietf.org; Mon, 11 Oct 2004 19:21:32 -0400 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 TAA09764 for ; Mon, 11 Oct 2004 19:21:28 -0400 (EDT) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH9eY-0007n5-Qf for sip@ietf.org; Mon, 11 Oct 2004 19:32:31 -0400 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id i9BNKxPm012630; Mon, 11 Oct 2004 23:20:59 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Mon, 11 Oct 2004 19:20:59 -0400 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF4246@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'Dean Willis'" Subject: RE: [Sip] verifying identity of sender Date: Mon, 11 Oct 2004 19:20:58 -0400 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: c1c65599517f9ac32519d043c37c5336 Cc: Cullen Jennings , sip@ietf.org, Juha Heinanen X-BeenThere: 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 Again, Dean, my immediate concern here is whether or not this discussion about a hypothetical, partially-formulated alternative is material to the progression of sip-identity-03. While it is interesting to discuss alternatives that provide a weaker assurance, I see no reason why the exploration of those alternatives should impede the standardization of a system that seems to satisfy the broader requirement. Ultimately, this thread was kicked off with the contention that acquiring certificates is infeasible. Both Cullen and I provided some data about certificate acquisition that seemed to argue that the problem isn't nearly so bad. If you can get a publicly-verifiable certificate for under $100 a year, then the expenditure is on the same order of magnitude as acquiring a domain name. I haven't yet heard the parallel argument that domain names are so expensive and administratively cumbersome that we should invent a new alternative system for locating SIP servers, but in my opinion, this contention would carry roughly the same weight as the arguments I've heard against certificates so far. If there is in fact no problem with making certificates a component of the identity architecture, then I'm not sure why we want to explore the specification of alternatives. Alternatives are bad, when it comes to security. I continue to believe that we should set a long-term goal of arriving a single mandatory-to-use identity mechanism for SIP. Partial solutions will not get us where we need to be. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Monday, October 11, 2004 1:03 PM > To: Peterson, Jon > Cc: Cullen Jennings; sip@ietf.org; Juha Heinanen > Subject: Re: [Sip] verifying identity of sender > [snip] > > So, does Juha's approach offer any security benefits over simpler hacks, > like my source-to-authority matching requirement? If it does, then let's > understand those properties and see if any sort of standardization is > needed. If not, then let's see what properties really are useful, and > see if we need to document practices that exploit those properties for > the operator community. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 11 20:24:23 2004 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 UAA13442 for ; Mon, 11 Oct 2004 20:24:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHAdG-0000Mk-8I for sip-web-archive@ietf.org; Mon, 11 Oct 2004 20:35:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHAK4-0000yt-WD; Mon, 11 Oct 2004 20:15:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHACU-0007Yl-HM for sip@megatron.ietf.org; Mon, 11 Oct 2004 20:07:34 -0400 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 UAA12324 for ; Mon, 11 Oct 2004 20:07:32 -0400 (EDT) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHAMx-0008WD-P8 for sip@ietf.org; Mon, 11 Oct 2004 20:18:33 -0400 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id i9C06rPm013654 for ; Tue, 12 Oct 2004 00:06:53 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Mon, 11 Oct 2004 20:06:53 -0400 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF4247@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'sip@ietf.org'" Date: Mon, 11 Oct 2004 20:06:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 1.5 (+) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [Sip] jon's rodeo of certificate savings! X-BeenThere: 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.5 (+) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Let's see if this survives anyone's spam filters. Here's a round-up of the certificate business as seen through Google this afternoon. This is far from an exhaustive list - basically, it's as many as I was able to go through before I got bored. Enrollment price for a certificate (contracting lasting a single year) is given - multi-year contracts generally provide a lower cost per annum. Only the lowest-cost applicable certificates offered by a particular provider are listed. I've tried to limit this to CAs whose root cert is currently distributed with IE, but in some cases I couldn't be exactly sure (all promise compatibility with over 95% of existing web browsers). Only certificates that cost less than US$100 per year are listed. About half of the CAs provide free 30-day trial certificates. This mail does not constitute an endorsement of any of these services. RegisterFly - $25 (special offer: $9!) http://registerfly.com/ssl/ ("instant signup process (as little as 5 minutes)") FreeSSL - $39 (special offer: $19 - act now, supplies are limited (by the DNS namespace size)!) http://www.freessl.com/ ("issued in minutes, installed in seconds!") Uses the StarterSSL root. Another reseller: http://www.ev1servers.net/english/starterssldetails.asp ... is apparently selling StarterSSL certs for only $4.95! GoDaddy SSL - $49 (special offer: $29) http://www.godaddy.com/gdshop/ssl/turbo.asp?isc=sslgol003t (certificate issued "within minutes") InstantSSL - $49 http://www.instantssl.com/ ("certificates can be issued instantly" thanks to some proprietary thingy they run) DigiCertSSL - $99 http://www.digicert.com/SSL-Server-certificatee.html GeoTrust - $149 - but if you're currently a Thawte/Verisign customer, only $69 to enroll! http://www.geotrust.com/jump/upgrade-ssl-certificate.html (promises to issue a certificate in 10 minutes or less, sort of like pizza I guess) Jon Peterson NeuStar, Inc. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 12 06:59:16 2004 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 GAA07760 for ; Tue, 12 Oct 2004 06:59:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHKXv-0002CB-VG for sip-web-archive@ietf.org; Tue, 12 Oct 2004 07:10:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHKGu-0002gZ-W1; Tue, 12 Oct 2004 06:52:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHKAL-0000xd-71 for sip@megatron.ietf.org; Tue, 12 Oct 2004 06:46:01 -0400 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 GAA07401 for ; Tue, 12 Oct 2004 06:45:58 -0400 (EDT) Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CHKL2-00022B-N8 for sip@ietf.org; Tue, 12 Oct 2004 06:57:06 -0400 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 12 Oct 2004 11:45:20 +0100 X-Mailer: exmh version 2.6.3 04/04/2003 with version: MH 6.8.3 #25[UCI] To: sip@ietf.org Date: Tue, 12 Oct 2004 11:45:18 +0100 Message-ID: <21736.1097577918@cs.ucl.ac.uk> From: "Piers O'Hanlon" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: P.OHanlon@cs.ucl.ac.uk Subject: [Sip] Queries/Comments on Resource Priority-04 X-BeenThere: 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 Hi, I've taken a look at the draft and have the following comments: General comments: - The fact that it isn't mandatory to mark all responses with RP headers means that one should at least make it a SHOULD(MUST?) to provide "resource prioritization" based on a dialog or session initiated with the RP header (possibly requiring Stateful proxy?). Otherwise it seems that being able to know if a node "supports Resource priority" (using OPTIONS or a Require hdr) may not be of use if you can't be assured the whole dialog/session will be assured of the "resource prioritization"? If it's not specified in this document then I guess it will need to be specified in some external policy document...(out of scope) Section 3.3 - minor comment: It might be useful to label table something like 'Table 1'. - In the second the paragraph the 420 response is incorrectly defined as "(Not Supported)" - when it should be "(Bad Extension)". - In the same paragraph the explanation following the handling of the 420 response seems at odds with the description in section 4.2.2 and that of RFC3261. Firstly this is because it indicates that a 420 is generated when it encounters a unknown RP value (on an RP capable node) - shouldn't that be covered in section 4.2.2 - Shouldn't a 420 be generated only by non RP capable node in response to Require? Secondly it seems to reccomend adding an 'Accept-Resource-Priority' header when RFC3261 specifies adding an "Unsupported" header for a 420 response? Or maybe it was intended to talk about the 417 handling here? Example 7.2 - In this example - according to section 4.2.2 a 417 response should only generated when in strict mode, in which case the shouldn't the INVITE contain the Require header? Piers O'Hanlon --------------_____________ Computer Science Department University College London _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 12 14:22:13 2004 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 OAA16573 for ; Tue, 12 Oct 2004 14:22:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHRSc-00046x-LP for sip-web-archive@ietf.org; Tue, 12 Oct 2004 14:33:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHRFM-0003cV-JO; Tue, 12 Oct 2004 14:19:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHR6a-0001O9-7g for sip@megatron.ietf.org; Tue, 12 Oct 2004 14:10:36 -0400 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 OAA15497 for ; Tue, 12 Oct 2004 14:10:35 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHRHL-0003oV-7t for sip@ietf.org; Tue, 12 Oct 2004 14:21:45 -0400 Received: from wink.ho.lucent.com (h135-112-126-3.lucent.com [135.112.126.3]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i9CI9fCu009364 for ; Tue, 12 Oct 2004 13:09:46 -0500 (CDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id OAA15880; Tue, 12 Oct 2004 14:09:37 -0400 (EDT) Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id OAA15876; Tue, 12 Oct 2004 14:09:37 -0400 (EDT) Message-ID: <416C1DD0.7030804@bell-labs.com> Date: Tue, 12 Oct 2004 14:09:20 -0400 From: Troy Cauble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Subject: [Sip] precisely when is a dialog terminated X-BeenThere: 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: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Sorry to bother this list, but I couldn't find a clear statement in the RFC or a consensus on the sip-implementors list. For the UA that sends a BYE, is the dialog terminated when the BYE is sent or when the 200 response is received? Can you point to a quote in the RFC? Related questions: Should crossed BYEs generate 481s or 200s? (I think the answer is obvious based on the answer to the first question.) If the dialog is not terminated until the BYE's response is received, how are re-INVITES handled during the period from when the BYE is sent until the response is received? Specifically the RFC refers to the session/media being stopped when the BYE is sent. Could a re-INVITE restart the session/media? Thanks -troy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 12 15:23:22 2004 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 PAA22002 for ; Tue, 12 Oct 2004 15:23:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHSPo-0005HB-Qd for sip-web-archive@ietf.org; Tue, 12 Oct 2004 15:34:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHS9s-0000PY-RQ; Tue, 12 Oct 2004 15:18:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHS8x-0008Kz-1m for sip@megatron.ietf.org; Tue, 12 Oct 2004 15:17:07 -0400 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 PAA21324 for ; Tue, 12 Oct 2004 15:17:06 -0400 (EDT) From: suheelh@nc.rr.com Received: from ms-smtp-02-lbl.southeast.rr.com ([24.25.9.101] helo=ms-smtp-02-eri0.southeast.rr.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHSJk-00059y-Pj for sip@ietf.org; Tue, 12 Oct 2004 15:28:17 -0400 Received: from ms-mss-04-ce0-1 ([10.10.5.90]) by ms-smtp-02-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id i9CJH34R023545 for ; Tue, 12 Oct 2004 15:17:03 -0400 (EDT) Received: from southeast.rr.com (localhost [127.0.0.1]) by ms-mss-04.southeast.rr.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5H00BK0K8FP9@ms-mss-04.southeast.rr.com> for sip@ietf.org; Tue, 12 Oct 2004 15:17:03 -0400 (EDT) Received: from [10.10.1.23] (Forwarded-For: [192.76.54.20]) by ms-mss-04.southeast.rr.com (mshttpd); Tue, 12 Oct 2004 14:17:03 -0500 Date: Tue, 12 Oct 2004 14:17:03 -0500 Subject: Re: [Sip] precisely when is a dialog terminated To: Troy Cauble Message-id: <69bdbb69a5f0.69a5f069bdbb@southeast.rr.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.21 (built Sep 8 2003) Content-type: multipart/mixed; boundary="Boundary_(ID_L1Q6QvIewC4OjioR/uo93Q)" Content-language: en X-Accept-Language: en Priority: normal X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.3 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: suheelh@nc.rr.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.3 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 This is a multi-part message in MIME format. --Boundary_(ID_L1Q6QvIewC4OjioR/uo93Q) Content-type: text/plain; charset=us-ascii Content-disposition: inline Content-Transfer-Encoding: 7BIT Troy, This topic has been hashed out a number of times. Refer to archives for discussion on this topic. -suheel ----------------- Suheel Hussain ----- Original Message ----- From: Troy Cauble Date: Tuesday, October 12, 2004 1:09 pm Subject: [Sip] precisely when is a dialog terminated > > Sorry to bother this list, but I couldn't find a clear statement > in the RFC or a consensus on the sip-implementors list. > > For the UA that sends a BYE, is the dialog terminated when the > BYE is sent or when the 200 response is received? Can you point > to a quote in the RFC? > > Related questions: > > Should crossed BYEs generate 481s or 200s? (I think the answer is > obvious based on the answer to the first question.) > > If the dialog is not terminated until the BYE's response is received, > how are re-INVITES handled during the period from when the BYE is sent > until the response is received? Specifically the RFC refers to the > session/media being stopped when the BYE is sent. Could a re-INVITE > restart the session/media? > > Thanks > -troy > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > --Boundary_(ID_L1Q6QvIewC4OjioR/uo93Q) Content-type: text/x-vcard; name="suheelh@nc.rr.com.vcf"; charset=windows-1252 Content-disposition: attachment; filename="suheelh@nc.rr.com.vcf" Content-description: Card for Content-Transfer-Encoding: 7BIT begin:vcard n:Hussain;Suheel fn:Suheel Hussain version:2.1 email;internet:suheelh@nc.rr.com end:vcard --Boundary_(ID_L1Q6QvIewC4OjioR/uo93Q) 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 --Boundary_(ID_L1Q6QvIewC4OjioR/uo93Q)-- From sip-bounces@ietf.org Tue Oct 12 19:35:19 2004 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 TAA27791 for ; Tue, 12 Oct 2004 19:35:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHWLi-0006aY-B3 for sip-web-archive@ietf.org; Tue, 12 Oct 2004 19:46:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHW9M-000875-Ea; Tue, 12 Oct 2004 19:33:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHVvh-0005Nq-Ra for sip@megatron.ietf.org; Tue, 12 Oct 2004 19:19:42 -0400 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 TAA27107 for ; Tue, 12 Oct 2004 19:19:39 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHW6X-0006Mo-3l for sip@ietf.org; Tue, 12 Oct 2004 19:30:53 -0400 Received: from wink.ho.lucent.com (h135-112-126-3.lucent.com [135.112.126.3]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i9CNJ763012651 for ; Tue, 12 Oct 2004 18:19:07 -0500 (CDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id TAA22518; Tue, 12 Oct 2004 19:19:05 -0400 (EDT) Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id TAA22509; Tue, 12 Oct 2004 19:19:04 -0400 (EDT) Message-ID: <416C6656.7080200@bell-labs.com> Date: Tue, 12 Oct 2004 19:18:46 -0400 From: Troy Cauble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: suheelh@nc.rr.com Original-CC: sip@ietf.org Subject: Re: [Sip] precisely when is a dialog terminated References: <69bdbb69a5f0.69a5f069bdbb@southeast.rr.com> In-Reply-To: <69bdbb69a5f0.69a5f069bdbb@southeast.rr.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit I'd love to. Got a searchable archive? I couldn't find one off the links below. http://www1.ietf.org/mail-archive/web/sip/current/index.html https://www1.ietf.org/mailman//listinfo/sip I also tried this google search with no relevant results: site: ietf.org BYE dialog sip-mailing-list -troy suheelh@nc.rr.com wrote: > Troy, > This topic has been hashed out a number of times. Refer to archives for discussion on this topic. > > -suheel > > ----------------- > Suheel Hussain > > ----- Original Message ----- > From: Troy Cauble > Date: Tuesday, October 12, 2004 1:09 pm > Subject: [Sip] precisely when is a dialog terminated > > >>Sorry to bother this list, but I couldn't find a clear statement >>in the RFC or a consensus on the sip-implementors list. >> >>For the UA that sends a BYE, is the dialog terminated when the >>BYE is sent or when the 200 response is received? Can you point >>to a quote in the RFC? >> >>Related questions: >> >>Should crossed BYEs generate 481s or 200s? (I think the answer is >>obvious based on the answer to the first question.) >> >>If the dialog is not terminated until the BYE's response is received, >>how are re-INVITES handled during the period from when the BYE is sent >>until the response is received? Specifically the RFC refers to the >>session/media being stopped when the BYE is sent. Could a re-INVITE >>restart the session/media? >> >>Thanks >>-troy >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 12 20:21:34 2004 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 UAA01397 for ; Tue, 12 Oct 2004 20:21:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHX4R-0007SO-HM for sip-web-archive@ietf.org; Tue, 12 Oct 2004 20:32:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHWoe-0004Zi-Qh; Tue, 12 Oct 2004 20:16:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHWh6-0001YH-3x for sip@megatron.ietf.org; Tue, 12 Oct 2004 20:08:40 -0400 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 UAA00223 for ; Tue, 12 Oct 2004 20:08:39 -0400 (EDT) Received: from mail.lumenvox.com ([206.169.193.45] helo=lv-svr.lumenvox.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHWrw-0007CB-1a for sip@ietf.org; Tue, 12 Oct 2004 20:19:52 -0400 Received: from PROGTHOMAS ([10.0.0.141]) by lv-svr.lumenvox.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 12 Oct 2004 16:59:55 -0700 From: "Thomas Gal" To: "'Troy Cauble'" , Subject: RE: [Sip] precisely when is a dialog terminated Date: Tue, 12 Oct 2004 17:08:00 -0700 Organization: LumenVox LLC MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <2D0CA64CDC33E14DA7AB043B8CC4D2BB0263A707@svr-exc.domain.com> Thread-Index: AcSwsywt4An+GN7rRauu7tErDhSkbAABIg2w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-ID: X-OriginalArrivalTime: 12 Oct 2004 23:59:55.0031 (UTC) FILETIME=[92204A70:01C4B0B7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ThomasGal@LumenVox.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: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit https://www1.ietf.org/mailman/listinfo/sip guides you to: http://www1.ietf.org/pipermail/sip/ Which you can plug into google (I think the trick is site:www1.ietf.org) http://tinyurl.com/3ltlo More or less works I think -Tom > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Troy Cauble > Sent: Tuesday, October 12, 2004 4:19 PM > To: suheelh@nc.rr.com > Cc: sip@ietf.org > Subject: Re: [Sip] precisely when is a dialog terminated > > > I'd love to. Got a searchable archive? > I couldn't find one off the links below. > > http://www1.ietf.org/mail-archive/web/sip/current/index.html > https://www1.ietf.org/mailman//listinfo/sip > > I also tried this google search with no relevant results: > site: ietf.org BYE dialog sip-mailing-list > > -troy > > > > > suheelh@nc.rr.com wrote: > > > Troy, > > This topic has been hashed out a number of times. Refer to > archives for discussion on this topic. > > > > -suheel > > > > ----------------- > > Suheel Hussain > > > > ----- Original Message ----- > > From: Troy Cauble > > Date: Tuesday, October 12, 2004 1:09 pm > > Subject: [Sip] precisely when is a dialog terminated > > > > > >>Sorry to bother this list, but I couldn't find a clear statement in > >>the RFC or a consensus on the sip-implementors list. > >> > >>For the UA that sends a BYE, is the dialog terminated when > the BYE is > >>sent or when the 200 response is received? Can you point > to a quote > >>in the RFC? > >> > >>Related questions: > >> > >>Should crossed BYEs generate 481s or 200s? (I think the answer is > >>obvious based on the answer to the first question.) > >> > >>If the dialog is not terminated until the BYE's response is > received, > >>how are re-INVITES handled during the period from when the > BYE is sent > >>until the response is received? Specifically the RFC refers to the > >>session/media being stopped when the BYE is sent. Could a > re-INVITE > >>restart the session/media? > >> > >>Thanks > >>-troy > >> > >>_______________________________________________ > >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>This list is for NEW development of the core SIP Protocol Use > >>sip-implementors@cs.columbia.edu for questions on current sip Use > >>sipping@ietf.org for new developments on the application of sip > >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 13 15:12:24 2004 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 PAA26282 for ; Wed, 13 Oct 2004 15:12:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHoiu-0003I2-Lj for sip-web-archive@ietf.org; Wed, 13 Oct 2004 15:23:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHoK1-0001fT-14; Wed, 13 Oct 2004 14:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHoG8-0000jY-I4 for sip@megatron.ietf.org; Wed, 13 Oct 2004 14:54:00 -0400 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 OAA23821 for ; Wed, 13 Oct 2004 14:54:01 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHoR8-0002oL-8y for sip@ietf.org; Wed, 13 Oct 2004 15:05:23 -0400 Received: from wink.ho.lucent.com (h135-112-126-3.lucent.com [135.112.126.3]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i9DIru0j028060 for ; Wed, 13 Oct 2004 13:53:57 -0500 (CDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id OAA17438; Wed, 13 Oct 2004 14:53:55 -0400 (EDT) Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id OAA17434; Wed, 13 Oct 2004 14:53:54 -0400 (EDT) Message-ID: <416D79AF.2040100@bell-labs.com> Date: Wed, 13 Oct 2004 14:53:35 -0400 From: Troy Cauble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Subject: Re: [Sip] precisely when is a dialog terminated References: <416C1DD0.7030804@bell-labs.com> In-Reply-To: <416C1DD0.7030804@bell-labs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Tom's google tip returned a lot more results but I didn't find any that addressed my questions. I've read the RFC and the archives. Anyone want to help out? The primary question was: > For the UA that sends a BYE, is the dialog terminated when the > BYE is sent or when the 200 response is received? Can you point > to a quote in the RFC? The following quote from 15.1.1 says that the Session is terminated when the BYE transaction is started, but doesn't clearly say when the dialog is terminated. The last sentence may imply that it's terminated when a final response is received, but that's inferring a lot, IMO. > The UAC MUST > consider the session terminated (and therefore stop sending or > listening for media) as soon as the BYE request is passed to the > client transaction. If the response for the BYE is a 481 > (Call/Transaction Does Not Exist) or a 408 (Request Timeout) or no > response at all is received for the BYE (that is, a timeout is > returned by the client transaction), the UAC MUST consider the > session and the dialog terminated. "Terminating a dialog" by "sending a BYE" is referred to more than once, but I take that as specifying the mechanism, not the precise timing. Thanks, -troy Troy Cauble wrote: > > Sorry to bother this list, but I couldn't find a clear statement > in the RFC or a consensus on the sip-implementors list. > > For the UA that sends a BYE, is the dialog terminated when the > BYE is sent or when the 200 response is received? Can you point > to a quote in the RFC? > > Related questions: > > Should crossed BYEs generate 481s or 200s? (I think the answer is > obvious based on the answer to the first question.) > > If the dialog is not terminated until the BYE's response is received, > how are re-INVITES handled during the period from when the BYE is sent > until the response is received? Specifically the RFC refers to the > session/media being stopped when the BYE is sent. Could a re-INVITE > restart the session/media? > > Thanks > -troy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 13 15:45:00 2004 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 PAA28746 for ; Wed, 13 Oct 2004 15:45:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHpER-0004TO-UJ for sip-web-archive@ietf.org; Wed, 13 Oct 2004 15:56:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHoxZ-0007S3-SI; Wed, 13 Oct 2004 15:38:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHonn-000649-Aq for sip@megatron.ietf.org; Wed, 13 Oct 2004 15:28:47 -0400 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 PAA27478 for ; Wed, 13 Oct 2004 15:28:46 -0400 (EDT) Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHow4-0003pk-Br for sip@ietf.org; Wed, 13 Oct 2004 15:37:23 -0400 Received: from unknown (HELO beta.jnpr.net) (172.24.18.109) by borg.juniper.net with ESMTP; 13 Oct 2004 12:25:23 -0700 X-BrightmailFiltered: true X-Ironport-AV: i="3.85,140,1094454000"; d="scan'208"; a="32188140:sNHT18051816" Received: from hadron.jnpr.net ([172.24.15.25]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 13 Oct 2004 12:25:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Oct 2004 12:25:23 -0700 Message-ID: Thread-Topic: [Sip-implementors] Question on OPTIONS method Thread-Index: AcSxWf8J42opnRgST0SUrFn9npQ1eQAAF1Gw From: "Anil Bollineni" To: X-OriginalArrivalTime: 13 Oct 2004 19:25:23.0695 (UTC) FILETIME=[62DB9FF0:01C4B15A] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Subject: [Sip] [Sip-implementors] Question on OPTIONS method X-BeenThere: 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 Content-Transfer-Encoding: quoted-printable Hi All,=20 =20 Is OPTIONS method should be part of the dialog, or can be before initiation of dialog. From RFC, I understand that OPTIONS can be sent in two scenarios. Please tell that it is correct. =20 Thanks in Advance, Anil _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 13 16:09:30 2004 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 QAA01571 for ; Wed, 13 Oct 2004 16:09:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHpcC-0005C4-VT for sip-web-archive@ietf.org; Wed, 13 Oct 2004 16:20:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHpFr-0000BX-6s; Wed, 13 Oct 2004 15:57:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHp8M-0004J2-LB for sip@megatron.ietf.org; Wed, 13 Oct 2004 15:50:02 -0400 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 PAA29276 for ; Wed, 13 Oct 2004 15:50:02 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHpJM-0004jY-FC for sip@ietf.org; Wed, 13 Oct 2004 16:01:25 -0400 Received: from oh0012exch001p.wins.lucent.com (h135-7-157-6.lucent.com [135.7.157.6]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i9DJnw0Z010342 for ; Wed, 13 Oct 2004 14:49:58 -0500 (CDT) Received: by OH0012EXCH001P with Internet Mail Service (5.5.2657.72) id <4M3H7YD1>; Wed, 13 Oct 2004 15:49:58 -0400 Message-ID: <4C37CF2D8DF07E4CA6357BAD5EB9A5D713E297F5@oh0012exch004u.cb.lucent.com> From: "Shekar, Nagesh Soma (Shekar)** CTR **" To: "'Anil Bollineni'" , sip@ietf.org Subject: RE: [Sip] [Sip-implementors] Question on OPTIONS method Date: Wed, 13 Oct 2004 15:49:55 -0400 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: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: 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: c1c65599517f9ac32519d043c37c5336 Anil, OPTIONS transaction can be part of a exisiting Dialog or can create a new Dialog. Nagesh Shekar > -----Original Message----- > From: Anil Bollineni [mailto:ABollineni@juniper.net] > Sent: Wednesday, October 13, 2004 3:25 PM > To: sip@ietf.org > Subject: [Sip] [Sip-implementors] Question on OPTIONS method > > > > Hi All, > > > > Is OPTIONS method should be part of the dialog, or can be before > initiation of dialog. From RFC, I understand that OPTIONS can > be sent in > two scenarios. Please tell that it is correct. > > > > Thanks in Advance, > > Anil > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 13 16:12:54 2004 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 QAA01932 for ; Wed, 13 Oct 2004 16:12:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHpfU-0005Gp-MH for sip-web-archive@ietf.org; Wed, 13 Oct 2004 16:24:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHpFw-0000GK-E2; Wed, 13 Oct 2004 15:57:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHp9h-0004vb-Bw for sip@megatron.ietf.org; Wed, 13 Oct 2004 15:51:25 -0400 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 PAA29483 for ; Wed, 13 Oct 2004 15:51:25 -0400 (EDT) Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHpKh-0004kL-BH for sip@ietf.org; Wed, 13 Oct 2004 16:02:48 -0400 Received: from unknown (HELO alpha.jnpr.net) (172.24.18.126) by kremlin.juniper.net with ESMTP; 13 Oct 2004 12:50:53 -0700 X-BrightmailFiltered: true X-Ironport-AV: i="3.85,140,1094454000"; d="scan'208"; a="14061463:sNHT21659628" Received: from hadron.jnpr.net ([172.24.15.25]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 13 Oct 2004 12:50:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] [Sip-implementors] Question on OPTIONS method Date: Wed, 13 Oct 2004 12:50:52 -0700 Message-ID: Thread-Topic: [Sip] [Sip-implementors] Question on OPTIONS method Thread-Index: AcSxXdPaGhd0y+OpQpeQwVpAzH6PZgAAA0Sg From: "Anil Bollineni" To: "Shekar, Nagesh Soma \(Shekar\)** CTR **" , X-OriginalArrivalTime: 13 Oct 2004 19:50:52.0796 (UTC) FILETIME=[F245EBC0:01C4B15D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Thanks, I got the same opinion form RFC. Anil -----Original Message----- From: Shekar, Nagesh Soma (Shekar)** CTR ** [mailto:shek@lucent.com]=20 Sent: Wednesday, October 13, 2004 12:50 PM To: Anil Bollineni; sip@ietf.org Subject: RE: [Sip] [Sip-implementors] Question on OPTIONS method Anil, OPTIONS transaction can be part of a exisiting Dialog or can=20 create a new Dialog. Nagesh Shekar > -----Original Message----- > From: Anil Bollineni [mailto:ABollineni@juniper.net] > Sent: Wednesday, October 13, 2004 3:25 PM > To: sip@ietf.org > Subject: [Sip] [Sip-implementors] Question on OPTIONS method >=20 >=20 >=20 > Hi All,=20 >=20 > =20 >=20 > Is OPTIONS method should be part of the dialog, or can be before > initiation of dialog. From RFC, I understand that OPTIONS can=20 > be sent in > two scenarios. Please tell that it is correct. >=20 > =20 >=20 > Thanks in Advance, >=20 > Anil >=20 > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >=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 Wed Oct 13 18:23:36 2004 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 SAA20241 for ; Wed, 13 Oct 2004 18:23:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHrhy-0001q3-AS for sip-web-archive@ietf.org; Wed, 13 Oct 2004 18:35:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHrLp-0005Yw-AQ; Wed, 13 Oct 2004 18:12:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHqwl-0008LH-S8 for sip@megatron.ietf.org; Wed, 13 Oct 2004 17:46:11 -0400 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 RAA14067 for ; Wed, 13 Oct 2004 17:46:10 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHr7m-0000AT-2V for sip@ietf.org; Wed, 13 Oct 2004 17:57:35 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i9DLjapD016230 for ; Wed, 13 Oct 2004 16:45:37 -0500 (CDT) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i9DLjZJ03388; Wed, 13 Oct 2004 16:45:35 -0500 (CDT) Message-ID: <416DA1E0.90807@lucent.com> Date: Wed, 13 Oct 2004 16:45:04 -0500 From: "Vijay K. Gurbani" Organization: Wireless Research and Development/Internet Software and Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Troy Cauble Subject: Re: [Sip] precisely when is a dialog terminated References: <416C1DD0.7030804@bell-labs.com> <416D79AF.2040100@bell-labs.com> In-Reply-To: <416D79AF.2040100@bell-labs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Troy Cauble wrote: > The following quote from 15.1.1 says that the Session is terminated > when the BYE transaction is started, but doesn't clearly say when the > dialog is terminated. The last sentence may imply that it's terminated > when a final response is received, but that's inferring a lot, IMO. Troy: Given that the SIP community believes that dialog sharing may be undesirable, you can probably rest assured that the dialog is terminated when a final response is received. - 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 Oct 14 10:23:47 2004 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 KAA22996 for ; Thu, 14 Oct 2004 10:23:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI6hO-0003KO-EP for sip-web-archive@ietf.org; Thu, 14 Oct 2004 10:35:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI6Uq-0002q4-He; Thu, 14 Oct 2004 10:22:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI6St-0001eH-L7 for sip@megatron.ietf.org; Thu, 14 Oct 2004 10:20:23 -0400 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 KAA22375 for ; Thu, 14 Oct 2004 10:20:21 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI6e3-0003Ep-UB for sip@ietf.org; Thu, 14 Oct 2004 10:31:56 -0400 Received: from [192.168.0.100] (router.legacysuites.com [216.201.172.33] (may be forged)) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i9EEK1V9083080 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 14 Oct 2004 09:20:03 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <416DA1E0.90807@lucent.com> References: <416C1DD0.7030804@bell-labs.com> <416D79AF.2040100@bell-labs.com> <416DA1E0.90807@lucent.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1281A476-1DEC-11D9-A3AA-000D93326732@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] precisely when is a dialog terminated Date: Thu, 14 Oct 2004 09:19:34 -0500 To: "Vijay K. Gurbani" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit What is the practical impact of the answer to this question on your application? For BYE, the dialog is going to terminate (for a given endpoint) when a 200 is sent or received. Why? You could get a recoverable error (a 407 or a 503 for example) response from an intervening proxy, and you need the dialog state to generate your next request. You can use similar reasoning to determine when you can lose state for other dialog terminating events. RjS On Oct 13, 2004, at 4:45 PM, Vijay K. Gurbani wrote: > Troy Cauble wrote: > >> The following quote from 15.1.1 says that the Session is terminated >> when the BYE transaction is started, but doesn't clearly say when the >> dialog is terminated. The last sentence may imply that it's >> terminated >> when a final response is received, but that's inferring a lot, IMO. > > Troy: > > Given that the SIP community believes that dialog sharing > may be undesirable, you can probably rest assured that the > dialog is terminated when a final response is received. > > - 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 15 06:33:19 2004 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 GAA14649 for ; Fri, 15 Oct 2004 06:33:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIPa3-0003NJ-SW for sip-web-archive@ietf.org; Fri, 15 Oct 2004 06:45:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIPJW-0008In-4H; Fri, 15 Oct 2004 06:27:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBxlz-0003Ox-QG for sip@megatron.ietf.org; Mon, 27 Sep 2004 11:50:48 -0400 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 LAA09109 for ; Mon, 27 Sep 2004 11:50:40 -0400 (EDT) Received: from pcp09495338pcs.nrockv01.md.comcast.net ([69.140.95.157] helo=mail.atelo.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CBxtd-00006T-Fy for sip@ietf.org; Mon, 27 Sep 2004 11:58:38 -0400 SUBJECT: Re: Re: [Sip] Problem with an intial SIP INVITE server transa ction. DATE: 27 Sep 2004 15:50:40 GMT RECEIVED: from WebBizLogic4 by Dispatcher; 27 Sep 2004 15:50:40 GMT Message-ID: X-Mailer: mail.atelo.com POP3 Server v.1c MIME-Version: 1.0 X-Priority: Normal X-MSMail-Priority: 3 From: Roman Shpount To: Content-type: TEXT/PLAIN Content-Transfer-Encoding: quoted-printable X-Spam-Score: 3.9 (+++) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 15 Oct 2004 06:27:55 -0400 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: 3.9 (+++) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Content-Transfer-Encoding: quoted-printable I do not belive this will work. In case of proxy it can route this INVIT= E message to a completely different endpoint, then it did for the first = INVITE. This means that a new dialog will be established, which is clear= ly not intended=0D=0A=0D=0AAs far as SIP UA is concerned, this will also= not work, for one very simple reason -- SIP INVITE does not match the S= IP dialog. If we want to create a mechanism to match this INVITE to an e= xisting dialog, this mechanism should be part of the standard. Furthermo= re, it would be a very bad thing to create a new transaction for the re-= transmitted INVITE. Imagine, what would the SIP UA, that originated the = call do if it receives two responses, one successful and one failure in = unspecified order. If SIP UA will receive the failure or out of order re= sponse first, it will ignore all the success responses afterwards. I am = not even sure what SIP UA will do if it receives a failure response afte= r the success. I do not belive this is even allowed.=0D=0A=0D=0AAs I men= tioned before, the most consistent way of dealing with this scenario is = to put a timer, which will keep the transaction going after 2XX response= is sent. If transaction receives a message during this time, this messa= ge is ignored. =0D=0A=0D=0AAs I mentioned before, I am not looking as mu= ch for the way to deal with this problem, as for the way to fix the RFC.= =0D=0A___________________________________=0D=0ARoman Shpount, VP of Tech= nology=0D=0AaTelo, Inc. -- www.atelo.com=0D=0A=0D=0A------ Original mess= age ------=0D=0A=0D=0A>From: Gautham =0D=0A= >Subject: Re: [Sip] Problem with an intial SIP INVITE server transa ctio= n.=0D=0A>Date: 27 Sep 04, 02:18 PM=0D=0A>To: Paul D.Smith =0D=0A>Cc: 'Roman Shpount' , SIP WG = =0D=0A=0D=0AHi,=0D=0A=0D=0AThe scenario given by Roman cou= ld happen at either a proxy or a endpoint.=0D=0A=0D=0AAt a proxy, the ap= propriate thing would be to create a new transaction.=0D=0ALike Roman ha= s mentioned in his mail, this retransmission may be because =0D=0Athe=0D= =0A1xx responses and the 2xx responses were lost. In such a case, I bel= ieve,=0D=0Ait would be correct for the proxy to create a new transaction= and=0D=0Aforward the INVITE downstream, as if it were a new transaction= .=0D=0AIn anycase, a proxy would not know better.=0D=0A=0D=0AAt an endp= oint too, it should not be a problem if a new server =0D=0Atransaction g= ets created=0D=0Afor the retransmitted INVITE. The UA core can look at t= he From tag, =0D=0ACall-Id and possibly CSeq=0D=0Ato determine that it = is not a new dialog request i.e., that it matches =0D=0Aan ongoing dialo= g.=0D=0AIf the UA core is still retransmitting the 2xx, it would send th= e 2xx to =0D=0Athe=0D=0Atransaction which would terminate it. If the UA = core has finished =0D=0Aretransmitting=0D=0Athe 2xx (and has received th= e ACK) it could treat the INVITE as an=0D=0Aout-of-sequence request.=0D= =0A=0D=0AHope this helps.=0D=0A=0D=0ARegards,=0D=0AA. N. Gautham=0D=0A= =0D=0APaul D.Smith wrote:=0D=0A=0D=0A>Roman,=0D=0A>=0D=0A>I believe you = have strayed into a poorly specified area of SIP here. I have=0D=0A>als= o found nothing in the specs. that directly answers your question howeve= r=0D=0A>I can tell you what is observed: the duplication INVITEs are si= mply=0D=0A>ignored. One option is to keep track of the INVITE transacti= on until the=0D=0A>ACK arrives. Although logically there is no transact= ion layer interaction=0D=0A>(as per section 17, RFC 3261), you can then = identify the INVITE as a=0D=0A>duplicate and discard it.=0D=0A>=0D=0A>Pa= ul D Smith=0D=0A>Network Protocols Group =0D=0A>Data Connection Ltd (DCL= )=0D=0A>Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com = =0D=0A>Fax: +44 20 8363 1039 Web: http://www.dataconnection.com=0D=0A= >=0D=0A>=0D=0A>-----Original Message-----=0D=0A>From: Roman Shpount [mai= lto:roman@atelo.com]=0D=0A>Sent: 19 September 2004 08:15=0D=0A>To: SIP P= ublic Folder (E-mail)=0D=0A>Subject: Re: RE: RE: [Sip] Problem with an i= ntial SIP INVITE server=0D=0A>transaction.=0D=0A>=0D=0A>=0D=0A>Thomas,= =0D=0A>=0D=0A>The problem is that retransmitted INVITE message does not = have the To-tag.=0D=0A>Thus it does not match the dialog and UAC is not = even informed about this=0D=0A>message. The only way I could think to de= al with this, as I described in my=0D=0A>original email, was to add a ti= mer which keeps the server INVITE transaction=0D=0A>open for T4 after 2X= X response is sent. If retransmitted INVITE message=0D=0A>arrives within= this time, it matches the transaction and is ignored. By the=0D=0A>way,= this discussion is not academic, this is the real problem that we=0D=0A= >encountered while dealing with large volumes of SIP transactions over W= i-Fi.=0D=0A>___________________________________=0D=0A>Roman Shpount, VP = of Technology=0D=0A>aTelo, Inc. -- www.atelo.com=0D=0A>=0D=0A>------ Ori= ginal message ------=0D=0A>=0D=0A> =0D=0A>=0D=0A>>From: Thomas Gal =0D=0A>>Subject: RE: RE: [Sip] Problem with an intia= l SIP INVITE server=0D=0A>> =0D=0A>>=0D=0A>transaction.=0D=0A> =0D= =0A>=0D=0A>>Date: 31 Aug 04, 04:44 PM=0D=0A>>To: 'Roman Shpount' , ,=0D=0A>> =0D=0A>>=0D=0A>=0D=0A>=0D=0A>Maybe some people were just trying to help without sco= uring the spec for all=0D=0A>the details. I have read the spec quite a f= ew times, thanks, but here, maybe=0D=0A>this will help(17):=0D=0A>=0D=0A= > In the case of a transaction where the=0D=0A> request was an INVITE = (known as an INVITE transaction), the=0D=0A> transaction also includes= the ACK only if the final response was not=0D=0A> a 2xx response. If= the response was a 2xx, the ACK is not considered=0D=0A> part of the = transaction.=0D=0A>=0D=0A> The reason for this separation is rooted= in the importance of=0D=0A> delivering all 200 (OK) responses to a= n INVITE to the UAC. To=0D=0A> deliver them all to the UAC, the UA= S alone takes responsibility=0D=0A> for retransmitting them (see Se= ction 13.3.1.4), and the UAC alone=0D=0A> takes responsibility for = acknowledging them with ACK (see Section=0D=0A> 13.2.2.4). Since t= his ACK is retransmitted only by the UAC, it is=0D=0A> effectively = considered its own transaction.=0D=0A>=0D=0A>You gotta wait til you get = the ACK.=0D=0A>=0D=0A>-Tom=0D=0A>=0D=0A>=0D=0A>-----Original Message----= -=0D=0A>From: Roman Shpount [mailto:roman@atelo.com] =0D=0A>Sent: Tuesda= y, August 31, 2004 8:38 AM=0D=0A>To: gledgard@iperia.com; ThomasGal@Lume= nVox.com; sip@ietf.org=0D=0A>Subject: Re: RE: [Sip] Problem with an inti= al SIP INVITE server transaction.=0D=0A>=0D=0A>Hi All, =0D=0A>=0D=0A>I g= ot quite a few answers like: "there is a magic key which prevents this"= =0D=0A>or "there is a timer that prevents this", or "you cannot get an I= NVITE once=0D=0A>you sent the 1XX or 2XX response". I would suggest that= you would read the=0D=0A>RFC (Section 17.2.1) before rushing to answer = my question. RFC clearly=0D=0A>spells out that INVITE server transaction= is terminated when 2XX response is=0D=0A>sent. There is even a picture = (Figure 7) that shows just that. There are no=0D=0A>timers. There are no= special transaction IDs. Transaction is ended, clear=0D=0A>and simple. = Once transaction is ended, re-transmitted INVITE message should=0D=0A>st= art the new transaction. =0D=0A>___________________________________=0D= =0A>Roman Shpount, VP of Technology=0D=0A>aTelo, Inc. -- www.atelo.com= =0D=0A>=0D=0A>------ Original message ------=0D=0A>=0D=0A> =0D=0A>=0D= =0A>>From: Gordon Ledgard =0D=0A>>Subject: RE: [Sip= ] Problem with an intial SIP INVITE server transaction.=0D=0A>>Date: 31 = Aug 04, 12:40 PM=0D=0A>>To: , Roman Shpount , =0D=0A>>=0D=0A>> =0D=0A>>=0D=0A>=0D=0A= >=0D=0A>Read the stuff about timers in the transaction layer. It spells = out how you=0D=0A>need to hold on to transactions for messages over unre= liable transports for=0D=0A>just this sort of reason.=0D=0A>=0D=0A>=0D= =0A>Gordon=0D=0A>=0D=0A>=0D=0A>=0D=0A>-----Original Message-----=0D=0A>F= rom: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Thom= as=0D=0A>Gal=0D=0A>Sent: Monday, August 30, 2004 7:54 PM=0D=0A>To: 'Roma= n Shpount'; sip@ietf.org=0D=0A>Subject: RE: [Sip] Problem with an intial= SIP INVITE server transaction.=0D=0A>=0D=0A>=0D=0A>I'm not an expert on= this protocol (only read through the spec a few times=0D=0A>so it blurs= together with some of the other ones) but even without looking=0D=0A>I'= m SURE there's supposed to be a unique request-ID generated by the clien= t=0D=0A>to avoid just such a confusion. Of course in this case any state= ful UA would=0D=0A>ignore the already processed invite request. Also (su= re about this one) if=0D=0A>the client received the provisional(100) res= ponse it wouldn't re-transmit=0D=0A>the INVITE either as that's the whol= e point.=0D=0A>=0D=0A>-Tom=0D=0A>=0D=0A>-----Original Message-----=0D=0A= >From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of R= oman=0D=0A>Shpount=0D=0A>Sent: Tuesday, August 17, 2004 7:05 PM=0D=0A>To= : sip@ietf.org=0D=0A>Subject: [Sip] Problem with an intial SIP INVITE se= rver transaction.=0D=0A>=0D=0A>I run into the problem with handling of r= etransmitted SIP INVITE message=0D=0A>based on the RFC 3621. =0D=0A>=0D= =0A>Imagine the following situation=0D=0A>=0D=0A>INVITE 1=0D=0A>--------= --------------->=0D=0A>100=0D=0A><-----------------------=0D=0A>2XX=0D= =0A><-----------------------=0D=0A>re-transmitted INVITE 1=0D=0A>-------= ---------------->=0D=0A>=0D=0A>Based on RFC 3261, server INVITE transact= ion terminates as soon as 2XX=0D=0A>response is sent. This means that re= -transmitted INVITE will be treated as a=0D=0A>new transaction. This INV= ITE message will not match the existing dialog,=0D=0A>since its To tag i= s empty. This means it will be treated as new dialog=0D=0A>creating mess= age and phone will treat this message as a new call, which is=0D=0A>clea= rly not intended.=0D=0A>=0D=0A>This situation can occur if both 100 and = 2XX responses were lost by the=0D=0A>unreliable transport, and INVITE co= ntinues to be re-transmitted. The fact=0D=0A>that, 100 and 2XX responses= were lost is unknown to the server transaction=0D=0A>and INVITE re-tran= smit can arrive before the 2XX re-transmit is sent. =0D=0A>=0D=0A>Majori= ty of the transaction state machines in SIP are designed to handle=0D=0A= >messages, that are received after the response is sent. It seems that= =0D=0A>something simular is required in this case as well. =0D=0A>=0D=0A= >In our implementation of SIP stack, server transaction is not terminate= d=0D=0A>when the 2XX response is sent. Instead, transaction is moved int= o the=0D=0A>"ConfirmedBis" state and timer, which is set to fire in T4, = is started. If=0D=0A>the stack receives an INVITE message which matches = the server transaction in=0D=0A>this state, it ignores it. If stack rece= ives a 2XX response, which matches=0D=0A>the server transaction, it pass= es it to TU. Once the T4 timer is fired, the=0D=0A>transaction is termin= ated.=0D=0A>=0D=0A>There is also an additional issue related to this pro= blem. It looks like,=0D=0A>for the sake of consistency, some type of res= ponse should be sent=0D=0A>immediately to the transport layer when INVIT= E re-transmit is received. If=0D=0A>multiple 2XX responses has been sent= , it is unclear what the behavior should=0D=0A>be: should all the 2XX me= ssages be sent, should the last 2XX message be=0D=0A>resent or should th= e INVITE be plainly ignored. =0D=0A>=0D=0A>_____________________________= ______=0D=0A>Roman Shpount, VP of Technology=0D=0A>aTelo, Inc. -- www.at= elo.com=0D=0A>=0D=0A>=0D=0A>=0D=0A>=0D=0A>=0D=0A>=0D=0A>________________= _______________________________=0D=0A>Sip mailing list https://www1.iet= f.org/mailman/listinfo/sip=0D=0A>This list is for NEW development of the= core SIP Protocol Use=0D=0A>sip-implementors@cs.columbia.edu for questi= ons on current sip Use=0D=0A>sipping@ietf.org for new developments on th= e application of sip=0D=0A>=0D=0A>=0D=0A>_______________________________= ________________=0D=0A>Sip mailing list https://www1.ietf.org/mailman/l= istinfo/sip=0D=0A>This list is for NEW development of the core SIP Proto= col Use=0D=0A>sip-implementors@cs.columbia.edu for questions on current = sip Use=0D=0A>sipping@ietf.org for new developments on the application o= f sip=0D=0A>=0D=0A>=0D=0A>=0D=0A>=0D=0A>=0D=0A>=0D=0A>=0D=0A>=0D=0A>=0D= =0A>=0D=0A>=0D=0A>=0D=0A>=0D=0A>________________________________________= _______=0D=0A>Sip mailing list https://www1.ietf.org/mailman/listinfo/s= ip=0D=0A>This list is for NEW development of the core SIP Protocol=0D=0A= >Use sip-implementors@cs.columbia.edu for questions on current sip=0D=0A= >Use sipping@ietf.org for new developments on the application of sip=0D= =0A>=0D=0A>_______________________________________________=0D=0A>Sip mai= ling list https://www1.ietf.org/mailman/listinfo/sip=0D=0A>This list is= for NEW development of the core SIP Protocol=0D=0A>Use sip-implementors= @cs.columbia.edu for questions on current sip=0D=0A>Use sipping@ietf.org= for new developments on the application of sip=0D=0A>=0D=0A> =0D=0A>= =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 15 06:34:35 2004 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 GAA14757 for ; Fri, 15 Oct 2004 06:34:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIPbK-0003P9-5m for sip-web-archive@ietf.org; Fri, 15 Oct 2004 06:46:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIPJX-0008J8-5y; Fri, 15 Oct 2004 06:27:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDHJ1-0002FF-9w for sip@megatron.ietf.org; Fri, 01 Oct 2004 02:54:15 -0400 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 CAA28644 for ; Fri, 1 Oct 2004 02:54:12 -0400 (EDT) Received: from natsmtp00.rzone.de ([81.169.145.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDHRO-0007MI-HH for sip@ietf.org; Fri, 01 Oct 2004 03:02:56 -0400 Received: from snom.de (pD95162F8.dip.t-dialin.net [217.81.98.248]) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id i916rnrc012097; Fri, 1 Oct 2004 08:53:49 +0200 (MEST) Content-class: urn:content-classes:message Subject: RE: [Sip] Symmetric NAT issue MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Oct 2004 08:53:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: Thread-Topic: [Sip] Symmetric NAT issue thread-index: AcSnbWzg4kYiaxdgQkahlkF5HEkMigAE0YcQ From: "Christian Stredicke" To: "Jonathan Rosenberg" X-Spam-Score: 0.2 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 15 Oct 2004 06:27:55 -0400 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.2 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: quoted-printable > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]=20 >=20 > Christian Stredicke wrote: >=20 > > IMVHO SBC that use ICE are a smart alternative to using TURN.=20 >=20 > I don't really understand what this means. I would not expect=20 > an SBC to=20 > implement ICE, in the sense that it would do the p2p STUN pings,=20 > connectivity checks, etc., or are you proposing that it does? In ICE we are talking about possible communication addresses, right? One possible address is the private address, another adress that has been allocated via a STUN packet sent out to a STUN server. The trick is that AFTER the UA has created the SDP with these possible addresses and sent them to the SBC, the SBC ADDS another communication address: UA sends SDP: v=3D0 o=3D17187614121 8000 8000 IN IP4 =20 s=3DSIP Call=20 c=3DIN IP4 =20 t=3D0 0=20 m=3Daudio 49242 RTP/AVP 0=20 a=3Drtpmap:0 PCMU/8000 a=3Dalt: a=3Dalt: The SBC allocates RTP relay ports and MODIFIES the SDP: v=3D0 o=3D17187614121 8000 8000 IN IP4 =20 s=3DSIP Call=20 c=3DIN IP4 =20 t=3D0 0=20 m=3Daudio 49242 RTP/AVP 0=20 a=3Drtpmap:0 PCMU/8000 a=3Dalt: a=3Dalt: a=3Dalt: The STUN packets and everything else is just forwarded, the SBC does not implemenent any logic for that. That means when ICE tries the connections, it will give a realistic picture of the delay. If the RTP has not started yet and the SBC could not get the IP/port of the symmetrical NAT, it will not relay that packet. But thats no problem as the primary contact is the SBC allocated port (c-line). >=20 > Also, ICE makes use of TURN, to deal with the symmetric NAT=20 > case. SO I=20 > don't understand what you mean when you say ICE is an alternative to=20 > TURN. Can you explain? >=20 Tried to explain above. >=20 > UA that > > are not aware of ICE, STUN, TURN or NAT will run media=20 > through the B2BUA > > while ICE-aware devices can bypass them. >=20 > That I agree with. >=20 > > IMEHO ist much easier to > > implement STUN/ICE than TURN (well, we did/tried it) and it=20 > solves the > > problem with the "dumb" devices. >=20 > ICE without TURN will not help in the symmetric NAT case. See above. >=20 >=20 > > Paired with DNS SRV and STUN its > > possible to automatically detect the nearest SBC, in case the SBC is > > necessary to relay media for symmetrical NAT. >=20 > Detect an SBC? I don't follow. Assume that you are a global operator with customers in USA, Australia, Europe and China. Customers in China expect that the delay when talking in China is reasonable (no relaying via USA). That means the UA must use the China SBC for communication. You can detect that by probing the possible SBC with STUN packets, the addresses are listed in DNS SRV. You just send a packet to all of them and pick the one with the shortest delay. This is necessary because you cannot for the INVITE to all DNS SRV listed SBC. Here TURN would be better, cause you can allocate ports on all TURN servers and ICE will then find the shortest delay. Take a look at http://snom.com/download/natf_205.pdf. Henry forbid me to use the three bad letters S-B-C...=20 Keep smiling, CS >=20 > Thanks, > Jonathan R. >=20 >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 15 11:06:35 2004 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 LAA11359 for ; Fri, 15 Oct 2004 11:06:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CITqa-0001Ze-Ks for sip-web-archive@ietf.org; Fri, 15 Oct 2004 11:18:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CITaY-0008Rh-5v; Fri, 15 Oct 2004 11:01:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CITS9-0006FF-Ri for sip@megatron.ietf.org; Fri, 15 Oct 2004 10:53:09 -0400 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 KAA10171 for ; Fri, 15 Oct 2004 10:53:07 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CITdV-0001Fa-Q4 for sip@ietf.org; Fri, 15 Oct 2004 11:04:56 -0400 Received: from wink.ho.lucent.com (h135-112-126-3.lucent.com [135.112.126.3]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i9FEr4Wp004092 for ; Fri, 15 Oct 2004 09:53:04 -0500 (CDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id KAA13443; Fri, 15 Oct 2004 10:53:00 -0400 (EDT) Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id KAA13434; Fri, 15 Oct 2004 10:52:59 -0400 (EDT) Message-ID: <416FE437.7090804@bell-labs.com> Date: Fri, 15 Oct 2004 10:52:39 -0400 From: Troy Cauble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks Original-CC: sip@ietf.org Subject: Re: [Sip] precisely when is a dialog terminated References: <416C1DD0.7030804@bell-labs.com> <416D79AF.2040100@bell-labs.com> <416DA1E0.90807@lucent.com> <1281A476-1DEC-11D9-A3AA-000D93326732@nostrum.com> In-Reply-To: <1281A476-1DEC-11D9-A3AA-000D93326732@nostrum.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 X-BeenThere: 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 Thank you! The possibility of a 407 clarifies things nicely. -troy Robert Sparks wrote: > What is the practical impact of the answer to this question on your > application? > > For BYE, the dialog is going to terminate (for a given endpoint) when a > 200 is > sent or received. Why? You could get a recoverable error (a 407 or a 503 > for > example) response from an intervening proxy, and you need the dialog state > to generate your next request. > > You can use similar reasoning to determine when you can lose state for > other > dialog terminating events. > > RjS > > On Oct 13, 2004, at 4:45 PM, Vijay K. Gurbani wrote: > >> Troy Cauble wrote: >> >>> The following quote from 15.1.1 says that the Session is terminated >>> when the BYE transaction is started, but doesn't clearly say when the >>> dialog is terminated. The last sentence may imply that it's terminated >>> when a final response is received, but that's inferring a lot, IMO. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 15 17:35:31 2004 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 RAA24860 for ; Fri, 15 Oct 2004 17:35:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIZv0-00066c-OP for sip-web-archive@ietf.org; Fri, 15 Oct 2004 17:47:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIZW6-0001Di-Rd; Fri, 15 Oct 2004 17:21:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIYuM-0003c3-UG for sip@megatron.ietf.org; Fri, 15 Oct 2004 16:42:39 -0400 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 QAA14393 for ; Fri, 15 Oct 2004 16:42:36 -0400 (EDT) Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIZ5m-0002wI-RK for sip@ietf.org; Fri, 15 Oct 2004 16:54:28 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i9FKg1lS023240; Fri, 15 Oct 2004 15:42:02 -0500 (CDT) Message-ID: <41703618.8040403@alcatel.com> Date: Fri, 15 Oct 2004 15:42:00 -0500 From: Alex Audu 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: Troy Cauble Subject: Re: [Sip] precisely when is a dialog terminated References: <416C1DD0.7030804@bell-labs.com> <416D79AF.2040100@bell-labs.com> <416DA1E0.90807@lucent.com> <1281A476-1DEC-11D9-A3AA-000D93326732@nostrum.com> <416FE437.7090804@bell-labs.com> In-Reply-To: <416FE437.7090804@bell-labs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alex.audu@alcatel.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: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Isn't it also necessary to to ensure that there are no outstanding subscriptions that have application states associated with the dialog? See the following from rfc 3265, section 3.3.4. Dialog creation and termination : If a subscription's destruction leaves no other application state associated with the dialog, the dialog terminates. The destruction of other application state (such as that created by an INVITE) will not terminate the dialog if a subscription is still associated with that dialog. Note that the above behavior means that a dialog created with an INVITE does not necessarily terminate upon receipt of a BYE. Similarly, in the case that several subscriptions are associated with a single dialog, the dialog does not terminate until all the subscriptions in it are destroyed. Cheers, Alex. Troy Cauble wrote: > Thank you! The possibility of a 407 clarifies things nicely. > -troy > > Robert Sparks wrote: > >> What is the practical impact of the answer to this question on your >> application? >> >> For BYE, the dialog is going to terminate (for a given endpoint) when >> a 200 is >> sent or received. Why? You could get a recoverable error (a 407 or a >> 503 for >> example) response from an intervening proxy, and you need the dialog >> state >> to generate your next request. >> >> You can use similar reasoning to determine when you can lose state >> for other >> dialog terminating events. >> >> RjS >> >> On Oct 13, 2004, at 4:45 PM, Vijay K. Gurbani wrote: >> >>> Troy Cauble wrote: >>> >>>> The following quote from 15.1.1 says that the Session is terminated >>>> when the BYE transaction is started, but doesn't clearly say when the >>>> dialog is terminated. The last sentence may imply that it's >>>> terminated >>>> when a final response is received, but that's inferring a lot, IMO. >>> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 16 18:02:59 2004 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 SAA16579 for ; Sat, 16 Oct 2004 18:02:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIwpN-00066E-KB for sip-web-archive@ietf.org; Sat, 16 Oct 2004 18:15:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIwbt-0003N9-BD; Sat, 16 Oct 2004 18:01:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIwbT-0002wX-Ii for sip@megatron.ietf.org; Sat, 16 Oct 2004 18:00:43 -0400 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 SAA16522 for ; Sat, 16 Oct 2004 18:00:40 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIwn7-00064c-7a for sip@ietf.org; Sat, 16 Oct 2004 18:12:46 -0400 Received: from [192.168.1.216] (c-24-1-66-77.client.comcast.net [24.1.66.77]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i9GM008s034536 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 16 Oct 2004 17:00:01 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <41703618.8040403@alcatel.com> References: <416C1DD0.7030804@bell-labs.com> <416D79AF.2040100@bell-labs.com> <416DA1E0.90807@lucent.com> <1281A476-1DEC-11D9-A3AA-000D93326732@nostrum.com> <416FE437.7090804@bell-labs.com> <41703618.8040403@alcatel.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] precisely when is a dialog terminated Date: Sat, 16 Oct 2004 16:59:34 -0500 To: alex.audu@alcatel.com X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit So, the original question was about a dialog with one usage. In general, a dialog goes away when its last usage goes away. Each type of usage gets terminated in different ways, but the same logic can be used for determining when that is. See the -nit- drafts for a more detailed discussion. RjS On Oct 15, 2004, at 3:42 PM, Alex Audu wrote: > Isn't it also necessary to to ensure that there are no outstanding > subscriptions > that have application states associated with the dialog? > > See the following from rfc 3265, section 3.3.4. Dialog creation and > termination : > > If a subscription's destruction leaves no other application state > associated with the dialog, the dialog terminates. The destruction > of other application state (such as that created by an INVITE) will > not terminate the dialog if a subscription is still associated with > that dialog. > > Note that the above behavior means that a dialog created with an > INVITE does not necessarily terminate upon receipt of a BYE. > Similarly, in the case that several subscriptions are associated > with a single dialog, the dialog does not terminate until all the > subscriptions in it are destroyed. > > > Cheers, > Alex. > > > Troy Cauble wrote: > >> Thank you! The possibility of a 407 clarifies things nicely. >> -troy >> >> Robert Sparks wrote: >> >>> What is the practical impact of the answer to this question on your >>> application? >>> >>> For BYE, the dialog is going to terminate (for a given endpoint) >>> when a 200 is >>> sent or received. Why? You could get a recoverable error (a 407 or a >>> 503 for >>> example) response from an intervening proxy, and you need the dialog >>> state >>> to generate your next request. >>> >>> You can use similar reasoning to determine when you can lose state >>> for other >>> dialog terminating events. >>> >>> RjS >>> >>> On Oct 13, 2004, at 4:45 PM, Vijay K. Gurbani wrote: >>> >>>> Troy Cauble wrote: >>>> >>>>> The following quote from 15.1.1 says that the Session is terminated >>>>> when the BYE transaction is started, but doesn't clearly say when >>>>> the >>>>> dialog is terminated. The last sentence may imply that it's >>>>> terminated >>>>> when a final response is received, but that's inferring a lot, IMO. >>>> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 18 09:52:25 2004 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 JAA17772 for ; Mon, 18 Oct 2004 09:52:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJY82-0000hO-AO for sip-web-archive@ietf.org; Mon, 18 Oct 2004 10:04:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJXpZ-0002o4-C1; Mon, 18 Oct 2004 09:45:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJXn3-00026F-FV for sip@megatron.ietf.org; Mon, 18 Oct 2004 09:43:09 -0400 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 JAA16952 for ; Mon, 18 Oct 2004 09:43:07 -0400 (EDT) Received: from premium.exocore.com ([203.197.173.224]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJXz3-0000U0-1Y for sip@ietf.org; Mon, 18 Oct 2004 09:55:33 -0400 Received: from mail.ncoretech.com (dsl.ncoretech.com [61.95.205.91]) by premium.exocore.com (8.12.8/8.12.8) with ESMTP id i9IDh5Vq015053 for ; Mon, 18 Oct 2004 19:13:05 +0530 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.ncoretech.com (Postfix) with ESMTP id 00136D42A for ; Mon, 18 Oct 2004 19:13:04 +0530 (IST) Received: from mail.ncoretech.com ([127.0.0.1]) by localhost (mail.ncoretech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14704-05 for ; Mon, 18 Oct 2004 19:13:04 +0530 (IST) Received: from [192.168.1.209] (ws209.ncoretech.com [192.168.1.209]) by mail.ncoretech.com (Postfix) with ESMTP id 62621D40C for ; Mon, 18 Oct 2004 19:13:04 +0530 (IST) Message-ID: <4173C777.7040007@ncoretech.com> Date: Mon, 18 Oct 2004 19:09:03 +0530 From: Ramalakshmi M User-Agent: Mozilla Thunderbird 0.8 (Windows/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-Virus-Scanned: by amavisd-new at ncoretech.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Subject: [Sip] DNS support for Sip 3261 stack X-BeenThere: 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 Content-Transfer-Encoding: 7bit Hi All, I want to implement DNS support for SIP 3261stack. Can you please provide me some details regarding this. Which RFCs i should refer ? Any open source implementations will support DNS in SIP 3261 Stack? Any application available on the net will support DNS so that i can i see the log of those packets ? Right now i am referring, RFC 2782 - A DNS RR for specifying the location of services (DNS SRV) RFC 3263 - Session Initiation Protocol (SIP): Locating SIP Servers RFC 2168 - Resolution of Uniform Resource Identifiers using the Domain Name System Thanks in Advance. Regards, Ramalakshmi. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 19 02:49:44 2004 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 CAA24157 for ; Tue, 19 Oct 2004 02:49:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJo0g-0005QU-CI for sip-web-archive@ietf.org; Tue, 19 Oct 2004 03:02:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJnBr-0006rz-E4; Tue, 19 Oct 2004 02:09:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJmr7-0001SA-Lj for sip@megatron.ietf.org; Tue, 19 Oct 2004 01:48:21 -0400 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 BAA05736 for ; Tue, 19 Oct 2004 01:48:15 -0400 (EDT) From: nabeel.2.cocker@verizon.com Received: from irvmail2.bdi.gte.com ([192.76.80.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJn3A-0004GN-A7 for sip@ietf.org; Tue, 19 Oct 2004 02:00:49 -0400 Received: from smtpirv.interwan.gte.com ([138.83.34.67]) by irvmail2.bdi.gte.com (8.12.10/8.12.10) with ESMTP id i9J5lfqG007245 for ; Tue, 19 Oct 2004 00:47:43 -0500 (EST) Received: from ustxirvhqwmms01.ent.verizon.com (IRVMMS01B.interwan.gte.com [138.83.34.107]) by smtpirv.interwan.gte.com (8.12.10/8.12.10) with ESMTP id i9J54GUH008801 for ; Tue, 19 Oct 2004 00:04:22 -0500 (CDT) Received: from 138.83.34.22 by ustxirvhqwmms01.ent.verizon.com with ESMTP (SMTP Relay); Tue, 19 Oct 2004 01:04:12 -0400 X-Server-Uuid: E1A60121-6F68-4E45-9692-B480AF34C963 Received: from dwsmtp01.core.verizon.com (dwmail21.interwan.gte.com [138.83.36.17]) by coregate1.interwan.gte.com (8.12.10/8.12.10) with ESMTP id i9J50f42026030 for ; Tue, 19 Oct 2004 00:04:12 -0500 (CDT) To: sip@ietf.org Message-ID: Date: Tue, 19 Oct 2004 01:02:42 -0400 X-MIMETrack: Serialize by Router on DWSMTP01/HSVR/Verizon(Release 6.0.2CF2|July 23, 2003) at 10/19/2004 00:04:11 MIME-Version: 1.0 X-WSS-ID: 6D6A7FC61OK4083499-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [Sip] Nabeel 2. Cocker/EMPL/NY/Bell-Atl is out of the office. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit I will be out of the office starting 10/18/2004 and will not return until 10/25/2004. I will respond to your message when I return. Regards, Nabeel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 19 22:32:39 2004 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 WAA17819 for ; Tue, 19 Oct 2004 22:32:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK6Tc-0003qv-EU for sip-web-archive@ietf.org; Tue, 19 Oct 2004 22:45:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4cE-0001um-9W; Tue, 19 Oct 2004 20:46:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJwbJ-0008FP-SY for sip@megatron.ietf.org; Tue, 19 Oct 2004 12:12:41 -0400 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 MAA11237 for ; Tue, 19 Oct 2004 12:12:39 -0400 (EDT) Received: from [203.129.224.106] (helo=kr.aftek.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJwnW-0001xx-BH for sip@ietf.org; Tue, 19 Oct 2004 12:25:20 -0400 Received: from Amit ([10.0.0.169]) by kr.aftek.com (8.11.6/8.11.6) with ESMTP id i9JGCZF25534 for ; Tue, 19 Oct 2004 21:42:35 +0530 Content-Type: text/plain; charset="iso-8859-1" From: Anurag Kabra Organization: Aftek Infosys Ltd. To: sip@ietf.org Date: Tue, 19 Oct 2004 21:47:42 +0530 User-Agent: KMail/1.4.3 References: <4173C777.7040007@ncoretech.com> In-Reply-To: <4173C777.7040007@ncoretech.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200410192147.42802.anuragk@aftek.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Subject: [Sip] Call Transfer Scenario X-BeenThere: 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: quoted-printable Hi I need to clear few of my doubts regarding call transfer,=20 In a scenario of A, B and C - Unattended Transfer (Blind Transfer) A =3D transferor B =3D transferee C =3D transfer target 1. There is a call set up between A and B 2. A need to transfer to C - A puts the RTP session on Hold with Re-INVI= TE=20 and sends REFER with refer-to C,=20 3. B on getting refer needs to put audio streaming on hold and so sends =20 Re-INVITE!! -- (DOUBT - is this step right) 4. B sends NOTIFY with subscription-state =3D active and expires to A 5. B now INVITES C=20 6. On getting response its sends a NOTIFY to A with subscription-state =3D= =20 terminated (Need to know if the REFER expires because of expires in NOTIFY what can = be=20 done ie if we get a time out on A side) 7. Now A sends a BYE to B (What to do if B wants to terminate the dialog with CANCEL or BYE) How can we differentiate Attended Transfer and Blind Transfer in the=20 application?? Can anyone tell me free sip UA implementing Call Transfer? Please do let me know any of your views. Please correct me if i am wrong=20 anywhere.=20 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 Wed Oct 20 00:19:02 2004 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 AAA25021 for ; Wed, 20 Oct 2004 00:19:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK88b-0005z0-0l for sip-web-archive@ietf.org; Wed, 20 Oct 2004 00:31:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4j4-0004Z9-Ii; Tue, 19 Oct 2004 20:53:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK0Tb-0008BM-Lp for sip@megatron.ietf.org; Tue, 19 Oct 2004 16:20:59 -0400 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 QAA09249 for ; Tue, 19 Oct 2004 16:20:52 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK0fk-0001J0-0j for sip@ietf.org; Tue, 19 Oct 2004 16:33:35 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61991 helo=[192.168.0.5]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CK0Sw-0003CX-PD; Tue, 19 Oct 2004 21:20:18 +0100 Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <47A87ADB-220C-11D9-AB8E-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Tue, 19 Oct 2004 21:20:12 +0100 To: sip@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Joerg Ott , Gonzalo Camarillo Subject: [Sip] Review request: draft-ietf-mmusic-connection-precon-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Folks, The MMUSIC working group is considering a draft on Connection-Establishment Preconditions in SIP . As there are obvious implications for SIP, this note is to solicit review by the SIP working group before we advance this draft in MMUSIC. We'd be grateful to receive any comments - both for or against this draft - in reply to this message. Thanks, Colin _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 20 00:41:19 2004 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 AAA26813 for ; Wed, 20 Oct 2004 00:41:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK8UB-0006a4-2R for sip-web-archive@ietf.org; Wed, 20 Oct 2004 00:54:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4kw-0007sh-0E; Tue, 19 Oct 2004 20:55:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK1oK-00004q-9R for sip@megatron.ietf.org; Tue, 19 Oct 2004 17:46:28 -0400 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 RAA17746 for ; Tue, 19 Oct 2004 17:46:19 -0400 (EDT) Received: from [206.176.144.210] (helo=kevlar.softarmor.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK20T-0003nA-SX for sip@ietf.org; Tue, 19 Oct 2004 17:59:03 -0400 Received: from [63.110.3.195] ([63.110.3.195]) (authenticated bits=0) by kevlar.softarmor.com (8.12.11/8.12.11) with ESMTP id i9JLi84s029625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Oct 2004 16:44:10 -0500 Message-ID: <41758AC4.2090506@softarmor.com> Date: Tue, 19 Oct 2004 16:44:36 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" Subject: Re: [Sip] verifying identity of sender References: <7927C67249E4AD43BC05B539AF0D129801AF4246@stntexch04.cis.neustar.com> In-Reply-To: <7927C67249E4AD43BC05B539AF0D129801AF4246@stntexch04.cis.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , sip@ietf.org, Juha Heinanen X-BeenThere: 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: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Peterson, Jon wrote: >Again, Dean, my immediate concern here is whether or not this discussion >about a hypothetical, partially-formulated alternative is material to the >progression of sip-identity-03. > > > Ahah! No, this has NOTHING to do with impeding the Identity draft, as far as I know. But it is a suggestion of another mechanism that MIGHT be useful to talk about. As far as I know, it NEVER had anything to do with the identity draft, but was a suggestion of another technique that might also be useful, and deployable in the nearer term. I think we've roughly concluded that the specific idea suggested has little or no benefit over a simpler operatioal procedure, but the exercise of that analysis is probably something useful for the larger community. >While it is interesting to discuss alternatives that provide a weaker >assurance, I see no reason why the exploration of those alternatives should >impede the standardization of a system that seems to satisfy the broader >requirement. > > Me neither. >Ultimately, this thread was kicked off with the contention that acquiring >certificates is infeasible. Both Cullen and I provided some data about >certificate acquisition that seemed to argue that the problem isn't nearly >so bad. If you can get a publicly-verifiable certificate for under $100 a >year, then the expenditure is on the same order of magnitude as acquiring a >domain name. I haven't yet heard the parallel argument that domain names are >so expensive and administratively cumbersome that we should invent a new >alternative system for locating SIP servers, but in my opinion, this >contention would carry roughly the same weight as the arguments I've heard >against certificates so far. > > > Yes, but this thread SUGGESTED operational policies that, in the absence of universal certificate deployment, might cut down on sip-spam. >If there is in fact no problem with making certificates a component of the >identity architecture, then I'm not sure why we want to explore the >specification of alternatives. Alternatives are bad, when it comes to >security. I continue to believe that we should set a long-term goal of >arriving a single mandatory-to-use identity mechanism for SIP. Partial >solutions will not get us where we need to be. > > > Operational procedures can be put in place in the "near end", (the domain individual operators are operating and protecting), and certificates gain little utility until they happen to be widely deployed at the FAR end, over which said operator has little control. That being said, there -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 20 01:01:19 2004 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 BAA28452 for ; Wed, 20 Oct 2004 01:01:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK8nU-00076x-Mj for sip-web-archive@ietf.org; Wed, 20 Oct 2004 01:14:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4o3-0004x4-4O; Tue, 19 Oct 2004 20:58:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK3XH-0004BF-Fe for sip@megatron.ietf.org; Tue, 19 Oct 2004 19:36:59 -0400 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 TAA02188 for ; Tue, 19 Oct 2004 19:36:55 -0400 (EDT) Received: from [206.176.144.210] (helo=kevlar.softarmor.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK3jN-0007ej-Va for sip@ietf.org; Tue, 19 Oct 2004 19:49:41 -0400 Received: from [63.110.3.195] ([63.110.3.195]) (authenticated bits=0) by kevlar.softarmor.com (8.12.11/8.12.11) with ESMTP id i9JNZW9a030460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Oct 2004 18:35:33 -0500 Message-ID: <4175A4E0.2000208@softarmor.com> Date: Tue, 19 Oct 2004 18:36:00 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) 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: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: rohan Mahy , Allison Mankin Subject: [Sip] Discussion on draft-ietf-sip-identity-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.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Wearing my chair hat and thinking about draft-ietf-sip-identity-03, which IS an approved working-group effort that WAS scheduled to be finished last April . . . From the minutes at IETF 60: "It was observed that few participants in the room displayed confidence in their understanding of the problem or the proposal, and that further study would be a Good Thing." Since then, we have talked a lot about identity-related issues on the list. We've hashed through some of the less-understood issues, including the tremendous similarity between the SIP spam problem and the SMTP spam problem, and Michael Thomas pointed us at the MASS work, which is astoundingly similar to sip-identity. Juha contributed some ideas on techniques related to jabber-style dial-back auth that could be applied to get partial identity in the absence of a certificate deployment, which led to discussion of additional operational hacks that could be applied to help with the problem, but neither gave us a complete solution. Jon and Cullen proved that real CS-signed certificates are readily available at a cost not significantly different than that of a domain registration, or slightly less than the price of a decent bottle of Scotch, for some definition of the word "decent". So, where do we go now? Are we ready to take this document to a working group last call? If you think not, please explain what we need to know, understand, or discuss in order to make forward progress here. Thanks, -- Dean Willis Co-Chair, SIP Working Group _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 20 01:20:25 2004 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 BAA29964 for ; Wed, 20 Oct 2004 01:20:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK95z-0007S2-HY for sip-web-archive@ietf.org; Wed, 20 Oct 2004 01:33:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK5LS-0002aY-R6; Tue, 19 Oct 2004 21:32:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK3pJ-0002Ny-01 for sip@megatron.ietf.org; Tue, 19 Oct 2004 19:55:47 -0400 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 TAA03918 for ; Tue, 19 Oct 2004 19:55:28 -0400 (EDT) Received: from [206.176.144.210] (helo=kevlar.softarmor.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK41V-0008HZ-CB for sip@ietf.org; Tue, 19 Oct 2004 20:08:14 -0400 Received: from [63.110.3.195] ([63.110.3.195]) (authenticated bits=0) by kevlar.softarmor.com (8.12.11/8.12.11) with ESMTP id i9JNsHot030568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Oct 2004 18:54:18 -0500 Message-ID: <4175A945.5020705@softarmor.com> Date: Tue, 19 Oct 2004 18:54:45 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) 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: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: rohan@ekabal.com, rjs@xten.com, Allison Mankin Subject: [Sip] WGLC for draft-sparks-sip-nit-problems-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: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit "chair hat on" At San Diego, we had consensus that we're ready to discuss finalization of the non-invite trasnactions problem statement and corrective actions drafts. Consequently, I'd like to request a Working Group Last Call (WGLC) on draft-sparks-sip-nit-problems-01.txt, which as I understand we intend to publish eventually as an informational RFC which will set up the near-term (as in NOW) work of the "actions" draft as well as establish problem definitions for other work we hope to undertake in the future, or at least think people should know about. WGLC for ths draft will commence immediately, and I expect to be able to complete this review by November 3. As always, please send your comments to the author (rjs@xten.com) and copy the list if you don't mind. Thanks, -- Dean Willis SIP WG 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 Oct 20 01:33:14 2004 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 BAA00697 for ; Wed, 20 Oct 2004 01:33:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK9IO-0007hN-QF for sip-web-archive@ietf.org; Wed, 20 Oct 2004 01:46:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK5Lv-0002gg-Oc; Tue, 19 Oct 2004 21:33:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK3s5-0003Cm-Pc for sip@megatron.ietf.org; Tue, 19 Oct 2004 19:58:29 -0400 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 TAA04063 for ; Tue, 19 Oct 2004 19:58:21 -0400 (EDT) Received: from [206.176.144.210] (helo=kevlar.softarmor.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK44I-0008Kr-4P for sip@ietf.org; Tue, 19 Oct 2004 20:11:07 -0400 Received: from [63.110.3.195] ([63.110.3.195]) (authenticated bits=0) by kevlar.softarmor.com (8.12.11/8.12.11) with ESMTP id i9JNv9u4030590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Oct 2004 18:57:10 -0500 Message-ID: <4175A9F1.3020201@softarmor.com> Date: Tue, 19 Oct 2004 18:57:37 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) 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: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: rohan@ekabal.com, Allison Mankin Subject: [Sip] WGLC for draft-sparks-sip-nit-actions-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: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit "chair hat on still" At San Diego, we had consensus that we're ready to discuss finalization of the non-invite transactions problem statement and corrective actions drafts. Consequently, I'd like to request a Working Group Last Call (WGLC) on draft-sparks-sip-nit-actions-02, which as I understand we intend to publish eventually as an proposed standard RFC that will change a few aspects of RFC 3261 and related NIT request types to prevent some of the problems outlined in the problem statement draft. WGLC for ths draft will commence immediately, and I expect to be able to complete this review by November 3. As always, please send your comments to the author (rjs@xten.com) and copy the list if you don't mind. Thanks, -- Dean Willis SIP WG 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 Oct 20 11:42:21 2004 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 LAA15633 for ; Wed, 20 Oct 2004 11:42:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKIny-0003J9-Bq for sip-web-archive@ietf.org; Wed, 20 Oct 2004 11:55:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKHna-0002DG-Fr; Wed, 20 Oct 2004 10:50:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKHCx-0006uX-Oe for sip@megatron.ietf.org; Wed, 20 Oct 2004 10:12:55 -0400 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 KAA05224 for ; Wed, 20 Oct 2004 10:12:47 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKHPH-0001M1-DG for sip@ietf.org; Wed, 20 Oct 2004 10:25:40 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 20 Oct 2004 10:33:27 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9KECExT026160; Wed, 20 Oct 2004 10:12:15 -0400 (EDT) Received: from cisco.com (dhcp-64-102-209-210.cisco.com [64.102.209.210]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BCU63457; Wed, 20 Oct 2004 07:12:14 -0700 (PDT) Message-ID: <4176723F.9060707@cisco.com> Date: Wed, 20 Oct 2004 10:12:15 -0400 From: Kevin Lingle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Penfield Subject: Re: [Sip] SIP MIB method based status code monitoring References: <009401c4860c$4099d750$800101df@BPenfield> 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 bob, i've defined the following object to incorporate your suggestion for monitoring rsp status code statistics on a per method basis. + sipStatusCodeMethod OBJECT-TYPE + SYNTAX SipMethodIdentifier + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "This object uniquely identifies a conceptual row + in the table and reflects an assigned number used + to identifier a specific SIP method." + ::= { sipStatusCodeEntry 1 } this new (additional) indexing object will be added to the sipStatusCodesTable. that able will now be indexed by applIndex, sipStatusCodeMethod, and sipStatusCodeValue. kevin Bob Penfield wrote: > The SIP MIB currently supports monitoring of response status codes, but not > on a per method basis. I find response status code information much more > useful when it is correlated to the method. Would it be possible to add > this? > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 20 13:32:24 2004 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 NAA29948 for ; Wed, 20 Oct 2004 13:32:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKKWU-0006dQ-Tt for sip-web-archive@ietf.org; Wed, 20 Oct 2004 13:45:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKIAq-0000Wz-Bn; Wed, 20 Oct 2004 11:14:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKHS7-0006Rp-C5 for sip@megatron.ietf.org; Wed, 20 Oct 2004 10:28:35 -0400 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 KAA08470 for ; Wed, 20 Oct 2004 10:28:28 -0400 (EDT) Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKHeR-0001mE-Tv for sip@ietf.org; Wed, 20 Oct 2004 10:41:21 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id i9KESSNt022762 for ; Wed, 20 Oct 2004 07:28:28 -0700 (MST) Received: from il02exm15.corp.mot.com (il02exm15.corp.mot.com [10.0.111.27]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i9KEPIXO005789 for ; Wed, 20 Oct 2004 09:25:18 -0500 Received: by il02exm15.corp.mot.com with Internet Mail Service (5.5.2657.72) id <4KC6K4J6>; Wed, 20 Oct 2004 09:25:17 -0500 Message-ID: <53F44AF77A9F9B458DCE1910C2E6263802B66DF1@il02exm15.corp.mot.com> From: Goulet Walter-CWG009 To: "'sip@ietf.org'" Date: Wed, 20 Oct 2004 09:25:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.3 (++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Sip] Status of draft for SIP connection reuse X-BeenThere: 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="===============1214764002==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 2.3 (++) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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. --===============1214764002== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B6B0.9DF5A0DA" 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_01C4B6B0.9DF5A0DA Content-Type: text/plain Hi: The draft 'draft-ietf-sip-connect-reuse-02' describes sharing a single SIP connection at the transport layer between two SIP endpoints. I've been trying to determine if this draft is going to be moved further along in the RFC process; currently it's in the initial ID-Exists state. I haven't been able to contact the author, hopefully he'll see this message. Thanks, Walter ------_=_NextPart_001_01C4B6B0.9DF5A0DA Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXVzLWFzY2lpIj4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0i TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI2NTguMiI+DQo8VElUTEU+U3RhdHVzIG9m IGRyYWZ0IGZvciBTSVAgY29ubmVjdGlvbiByZXVzZTwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4N Cg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5IaTo8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxG T05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+VGhlIGRyYWZ0ICdkcmFmdC1pZXRmLXNpcC1jb25uZWN0 LXJldXNlLTAyJyBkZXNjcmliZXMgc2hhcmluZyBhIHNpbmdsZSBTSVAgY29ubmVjdGlvbiBhdCB0 aGUgdHJhbnNwb3J0IGxheWVyIGJldHdlZW4gdHdvIFNJUCBlbmRwb2ludHMuIEkndmUgYmVlbiB0 cnlpbmcgdG8gZGV0ZXJtaW5lIGlmIHRoaXMgZHJhZnQgaXMgZ29pbmcgdG8gYmUgbW92ZWQgZnVy dGhlciBhbG9uZyBpbiB0aGUgUkZDIHByb2Nlc3M7IGN1cnJlbnRseSBpdCdzIGluIHRoZSBpbml0 aWFsIElELUV4aXN0cyBzdGF0ZS4gSSBoYXZlbid0IGJlZW4gYWJsZSB0byBjb250YWN0IHRoZSBh dXRob3IsIGhvcGVmdWxseSBoZSdsbCBzZWUgdGhpcyBtZXNzYWdlLjwvRk9OVD48L1A+DQoNCjxQ PjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+VGhhbmtzLDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF PTIgRkFDRT0iQXJpYWwiPldhbHRlcjwvRk9OVD4NCjwvUD4NCg0KPC9CT0RZPg0KPC9IVE1MPg== ------_=_NextPart_001_01C4B6B0.9DF5A0DA-- --===============1214764002== 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 --===============1214764002==-- From sip-bounces@ietf.org Thu Oct 21 08:28:54 2004 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 IAA15249 for ; Thu, 21 Oct 2004 08:28:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKcGR-0007x4-9q for sip-web-archive@ietf.org; Thu, 21 Oct 2004 08:41:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKb6N-0005TZ-RF; Thu, 21 Oct 2004 07:27:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKST6-00088y-Uw for sip@megatron.ietf.org; Wed, 20 Oct 2004 22:14:21 -0400 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 WAA10734 for ; Wed, 20 Oct 2004 22:14:13 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKSfY-0001nu-Bq for sip@ietf.org; Wed, 20 Oct 2004 22:27:12 -0400 Received: from phys-fll03-2 ([129.154.149.12]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9L2EDNJ010614 for ; Wed, 20 Oct 2004 20:14:14 -0600 (MDT) Received: from conversion-daemon.fll03-mail1.east.sun.com by fll03-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0I5W00E01WL5U6@fll03-mail1.east.sun.com> (original mail from Mauricio.Arango@Sun.COM) for sip@ietf.org; Wed, 20 Oct 2004 22:14:13 -0400 (EDT) Received: from sun.com (vpn-129-150-65-1.East.Sun.COM [129.150.65.1]) by fll03-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0I5W00KDMWVNMB@fll03-mail1.east.sun.com>; Wed, 20 Oct 2004 22:14:13 -0400 (EDT) Date: Wed, 20 Oct 2004 22:18:09 -0400 From: Mauricio Arango Subject: Re: [Sip] verifying identity of sender To: Dean Willis Message-id: <41771C61.978236FE@sun.com> MIME-version: 1.0 X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en,pdf References: <7927C67249E4AD43BC05B539AF0D129801AF4246@stntexch04.cis.neustar.com> <41758AC4.2090506@softarmor.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: 7BIT Cc: Cullen Jennings , sip@ietf.org, Juha Heinanen , "Peterson, Jon" X-BeenThere: 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: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 7BIT Folks, I believe the approach described in draft-ietf-sip-identity-03, based on secure exchange of authentication assurances, is the right way to achieve end-to-end authentication among SIP entities that don't belong to the same administrative domain. However, I'd like to ask of why not use an already standardized structure, specifically SAML, for the proposed Identity header? Something similar has been already put forward in draft-tschofenig-sip-saml, where the 'Network Asserted Identities' case in Figure 3 is the closest to the approach in draft-ietf-sip-identity-03 (where the SAML Asserting party role is handled by the SIP Autentication proxy). Benefits of using SAML include: - Standardized and widely adopted structure for security (authentication, authorization, attribute) assertions. - Simplifies integration with other identity management systems. - Extensible, XML-based format - SIP-specific message information including headers (eg. Contact, Call-ID, CSeq) and the SDP body can be specified as new SAML attributes. - Transfer of attributes associated with the asserted identity, which enables trait-based authorization as described in draft-ietf-sipping-trait-authz-00. Regards, Mauricio Arango Dean Willis wrote: > Peterson, Jon wrote: > > >Again, Dean, my immediate concern here is whether or not this discussion > >about a hypothetical, partially-formulated alternative is material to the > >progression of sip-identity-03. > > > > > > > Ahah! No, this has NOTHING to do with impeding the Identity draft, as > far as I know. But it is a suggestion of another mechanism that MIGHT be > useful to talk about. As far as I know, it NEVER had anything to do with > the identity draft, but was a suggestion of another technique that might > also be useful, and deployable in the nearer term. I think we've roughly > concluded that the specific idea suggested has little or no benefit over > a simpler operatioal procedure, but the exercise of that analysis is > probably something useful for the larger community. > > >While it is interesting to discuss alternatives that provide a weaker > >assurance, I see no reason why the exploration of those alternatives should > >impede the standardization of a system that seems to satisfy the broader > >requirement. > > > > > > Me neither. > > >Ultimately, this thread was kicked off with the contention that acquiring > >certificates is infeasible. Both Cullen and I provided some data about > >certificate acquisition that seemed to argue that the problem isn't nearly > >so bad. If you can get a publicly-verifiable certificate for under $100 a > >year, then the expenditure is on the same order of magnitude as acquiring a > >domain name. I haven't yet heard the parallel argument that domain names are > >so expensive and administratively cumbersome that we should invent a new > >alternative system for locating SIP servers, but in my opinion, this > >contention would carry roughly the same weight as the arguments I've heard > >against certificates so far. > > > > > > > Yes, but this thread SUGGESTED operational policies that, in the absence > of universal certificate deployment, might cut down on sip-spam. > > >If there is in fact no problem with making certificates a component of the > >identity architecture, then I'm not sure why we want to explore the > >specification of alternatives. Alternatives are bad, when it comes to > >security. I continue to believe that we should set a long-term goal of > >arriving a single mandatory-to-use identity mechanism for SIP. Partial > >solutions will not get us where we need to be. > > > > > > > Operational procedures can be put in place in the "near end", (the > domain individual operators are operating and protecting), and > certificates gain little utility until they happen to be widely deployed > at the FAR end, over which said operator has little control. That being > said, there > > -- > Dean > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 21 08:39:42 2004 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 IAA18060 for ; Thu, 21 Oct 2004 08:39:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKcQl-0000Cp-TW for sip-web-archive@ietf.org; Thu, 21 Oct 2004 08:52:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKbLU-0000kg-4M; Thu, 21 Oct 2004 07:43:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKUbi-0001n8-60 for sip@megatron.ietf.org; Thu, 21 Oct 2004 00:31:22 -0400 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 AAA23882 for ; Thu, 21 Oct 2004 00:31:13 -0400 (EDT) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKUoA-0005lw-7v for sip@ietf.org; Thu, 21 Oct 2004 00:44:15 -0400 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id i9L4UePm009470 for ; Thu, 21 Oct 2004 04:30:40 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Thu, 21 Oct 2004 00:30:40 -0400 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF42BB@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'sip@ietf.org'" Date: Thu, 21 Oct 2004 00:30:39 -0400 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: 7d33c50f3756db14428398e2bdedd581 Subject: [Sip] draft on messaging, impersonation and identity X-BeenThere: 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: 2409bba43e9c8d580670fda8b695204a I've written a new draft on the design space of providing identity services to meet the threat of impersonation in messaging systems: http://www.ietf.org/internet-drafts/draft-peterson-message-identity-00.txt It's a very long draft, since it tries to be a relatively complete analysis of the problem space (though that much said, I am already aware of several important omissions). Moreover, it tries to look at messaging at a high level, rather than being specific to SIP. I created this draft for two reasons, really. First, to show what the trade-offs are in the many possible core designs of identity services that we've uncovered in our work here in SIP. Second, I hope that it might be useful to others exploring designs for identity mechanisms for other messaging systems. I won't be seeking working group status for this draft here in the SIP WG, but I thought it might be of interest. Jon Peterson NeuStar, Inc. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 21 08:59:56 2004 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 IAA21886 for ; Thu, 21 Oct 2004 08:59:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKckU-0001AS-KE for sip-web-archive@ietf.org; Thu, 21 Oct 2004 09:13:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKbOP-00050n-J2; Thu, 21 Oct 2004 07:46:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKaeM-0000jP-UJ for sip@megatron.ietf.org; Thu, 21 Oct 2004 06:58:31 -0400 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 GAA27942 for ; Thu, 21 Oct 2004 06:58:27 -0400 (EDT) Received: from lohi.tutpro.com ([192.98.100.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKaqx-00039d-0V for sip@ietf.org; Thu, 21 Oct 2004 07:11:31 -0400 Received: from www-data by lohi.tutpro.com with local (Exim 4.34) id 1CKaeC-0002Pc-EI; Thu, 21 Oct 2004 13:58:20 +0300 Received: from 218.111.55.235 (SquirrelMail authenticated user jh) by lohi.tutpro.com with HTTP; Thu, 21 Oct 2004 13:58:20 +0300 (EEST) Message-ID: <50998.218.111.55.235.1098356300.squirrel@lohi.tutpro.com> In-Reply-To: <41758AC4.2090506@softarmor.com> References: <7927C67249E4AD43BC05B539AF0D129801AF4246@stntexch04.cis.neustar.com> <41758AC4.2090506@softarmor.com> Date: Thu, 21 Oct 2004 13:58:20 +0300 (EEST) Subject: Re: [Sip] verifying identity of sender From: "Juha Heinanen" To: "Dean Willis" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 3.7 (+++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 8bit Cc: Cullen Jennings , sip@ietf.org, Juha Heinanen , "Peterson, Jon" X-BeenThere: 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: 3.7 (+++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 8bit Dean Willis said: > Ahah! No, this has NOTHING to do with impeding the Identity draft, as > far as I know. But it is a suggestion of another mechanism that MIGHT be > useful to talk about. As far as I know, it NEVER had anything to do with > the identity draft, but was a suggestion of another technique that might > also be useful, and deployable in the nearer term. that is correct, but if it is so that the identity draft requires presence of a proxy, then it needs to be fixed so that it also works in a pure peer-to-peer environment like the mechanism that i proposed for spam control. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 21 10:25:13 2004 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 KAA05037 for ; Thu, 21 Oct 2004 10:25:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKe55-0004HN-8m for sip-web-archive@ietf.org; Thu, 21 Oct 2004 10:38:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKdkF-0005cj-NC; Thu, 21 Oct 2004 10:16:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKdZg-0002Dx-Jl for sip@megatron.ietf.org; Thu, 21 Oct 2004 10:05:52 -0400 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 KAA01430 for ; Thu, 21 Oct 2004 10:05:50 -0400 (EDT) Received: from [62.119.82.41] (helo=mailserver.hotsip.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKdm8-0003bQ-Qf for sip@ietf.org; Thu, 21 Oct 2004 10:18:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Oct 2004 16:05:07 +0200 Message-ID: Thread-Topic: Join header (draft-ietf-sip-join-03.txt) unnecessary? Thread-Index: AcS3dqfKJkX6MDJCQd6VWtE6hauJPw== From: "Christian Jansson" To: X-Spam-Score: 0.2 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Subject: [Sip] Join header (draft-ietf-sip-join-03.txt) unnecessary? X-BeenThere: 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="===============2030059498==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 This is a multi-part message in MIME format. --===============2030059498== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B776.F8792790" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B776.F8792790 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Why do we need a Join header to be able to indicate that we want to join an ongoing session? Wouldn't it be enough to, for the party that wants to join, actually use the call-id for the session when sending the join-INVITE? Suppose A and B are in a session with the dialog identified by call-id=3D12345;tag=3DA;tag=3DB. If C now wants to join the session = he sends an INVITE to A or B with call-id=3D12345, from-tag=3DC, and an = empty to-tag. Wouldn't it make more sense that the 2 dialog-ids had some parts in common, that is the call-id, and something that distinguished them, that is the to and from tags? It would be much easier to find the session related messages as they would share the same call-id. =20 Have I missed some essential part of the Join header, or are we just adding something that we could already express easily with what we already have? =20 =20 / Christian Jansson, Hotsip ------_=_NextPart_001_01C4B776.F8792790 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Why do we need a Join header to be able to indicate = that we want to join an ongoing session? Wouldn’t it be enough to, for the = party that wants to join, actually use the call-id for the session when = sending the join-INVITE? Suppose A and B are in a session with the dialog identified = by call-id=3D12345;tag=3DA;tag=3DB. If C now wants to join the session he sends an INVITE to A or B with call-id=3D12345, from-tag=3DC, and an empty to-tag. Wouldn’t it = make more sense that the 2 dialog-ids had some parts in common, that is the = call-id, and something that distinguished them, that is the to and from tags? It = would be much easier to find the session related messages as they would share the = same call-id.

 

Have I missed some essential part of the Join header, = or are we just adding something that we could already express easily with what = we already have?

 

 

/ Christian = Jansson, Hotsip

------_=_NextPart_001_01C4B776.F8792790-- --===============2030059498== 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 --===============2030059498==-- From sip-bounces@ietf.org Thu Oct 21 13:51:38 2004 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 NAA28829 for ; Thu, 21 Oct 2004 13:51:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhIr-0001Nu-88 for sip-web-archive@ietf.org; Thu, 21 Oct 2004 14:04:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKgzl-0005gJ-O7; Thu, 21 Oct 2004 13:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKgkJ-0004wd-VA for sip@megatron.ietf.org; Thu, 21 Oct 2004 13:29:04 -0400 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 NAA25923 for ; Thu, 21 Oct 2004 13:29:00 -0400 (EDT) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKgwy-0000Yf-Rd for sip@ietf.org; Thu, 21 Oct 2004 13:42:09 -0400 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id i9LHSUPm009898; Thu, 21 Oct 2004 17:28:30 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Thu, 21 Oct 2004 13:28:29 -0400 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF42C2@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'Mauricio Arango'" , Dean Willis Subject: RE: [Sip] verifying identity of sender Date: Thu, 21 Oct 2004 13:28:28 -0400 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: 0cff8c3ec906d056784362c06f5f88c1 Cc: Cullen Jennings , sip@ietf.org, Juha Heinanen X-BeenThere: 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: 9af087f15dbdd4c64ae6bbcdbc5b1d44 We're working towards a mid-term goal of unifying the existing sip-identity work with the SIP-SAML draft. I suspect that the vehicle for this unification while actually be the Identity-Info header rather than the Identity header (i.e., Identity-Info could provide a means of accessing a SAML assertion by reference). However, I also believe it is critical that we aim towards a universally-deployable, thinner identity assertion than SAML. SAML is heavy, and requires a great deal of pre-association between the creator and consumer of assertions. We need something that addresses the impersonation problem but doesn't entail the sorts of smarts required to make SAML work. So in any regime, I believe sip-identity will have a place; SAML would provide supplemental information commensurate with its intrinsic versatility. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Mauricio Arango [mailto:Mauricio.Arango@Sun.COM] > Sent: Wednesday, October 20, 2004 10:18 PM > To: Dean Willis > Cc: Cullen Jennings; sip@ietf.org; Juha Heinanen; Peterson, Jon > Subject: Re: [Sip] verifying identity of sender > > > Folks, > > I believe the approach described in draft-ietf-sip-identity-03, > based on secure exchange of authentication assurances, is the right > way to achieve end-to-end authentication among SIP entities that > don't belong to the same administrative domain. > > However, I'd like to ask of why not use an already > standardized structure, specifically SAML, for the > proposed Identity header? Something similar has been > already put forward in draft-tschofenig-sip-saml, where the > 'Network Asserted Identities' case in Figure 3 is > the closest to the approach in draft-ietf-sip-identity-03 > (where the SAML Asserting party role is handled by > the SIP Autentication proxy). > > Benefits of using SAML include: > > - Standardized and widely adopted structure for > security (authentication, authorization, attribute) assertions. > > - Simplifies integration with other identity management systems. > > - Extensible, XML-based format - SIP-specific message information > including headers (eg. Contact, Call-ID, CSeq) > and the SDP body can be specified as new SAML > attributes. > > - Transfer of attributes associated with the asserted > identity, which enables trait-based authorization as > described in draft-ietf-sipping-trait-authz-00. > > Regards, > > Mauricio Arango > > > > > > > > > > Dean Willis wrote: > > > Peterson, Jon wrote: > > > > >Again, Dean, my immediate concern here is whether or not > this discussion > > >about a hypothetical, partially-formulated alternative is > material to the > > >progression of sip-identity-03. > > > > > > > > > > > Ahah! No, this has NOTHING to do with impeding the Identity > draft, as > > far as I know. But it is a suggestion of another mechanism > that MIGHT be > > useful to talk about. As far as I know, it NEVER had > anything to do with > > the identity draft, but was a suggestion of another > technique that might > > also be useful, and deployable in the nearer term. I think > we've roughly > > concluded that the specific idea suggested has little or no > benefit over > > a simpler operatioal procedure, but the exercise of that analysis is > > probably something useful for the larger community. > > > > >While it is interesting to discuss alternatives that > provide a weaker > > >assurance, I see no reason why the exploration of those > alternatives should > > >impede the standardization of a system that seems to > satisfy the broader > > >requirement. > > > > > > > > > > Me neither. > > > > >Ultimately, this thread was kicked off with the contention > that acquiring > > >certificates is infeasible. Both Cullen and I provided > some data about > > >certificate acquisition that seemed to argue that the > problem isn't nearly > > >so bad. If you can get a publicly-verifiable certificate > for under $100 a > > >year, then the expenditure is on the same order of > magnitude as acquiring a > > >domain name. I haven't yet heard the parallel argument > that domain names are > > >so expensive and administratively cumbersome that we > should invent a new > > >alternative system for locating SIP servers, but in my > opinion, this > > >contention would carry roughly the same weight as the > arguments I've heard > > >against certificates so far. > > > > > > > > > > > Yes, but this thread SUGGESTED operational policies that, > in the absence > > of universal certificate deployment, might cut down on sip-spam. > > > > >If there is in fact no problem with making certificates a > component of the > > >identity architecture, then I'm not sure why we want to explore the > > >specification of alternatives. Alternatives are bad, when > it comes to > > >security. I continue to believe that we should set a > long-term goal of > > >arriving a single mandatory-to-use identity mechanism for > SIP. Partial > > >solutions will not get us where we need to be. > > > > > > > > > > > Operational procedures can be put in place in the "near end", (the > > domain individual operators are operating and protecting), and > > certificates gain little utility until they happen to be > widely deployed > > at the FAR end, over which said operator has little > control. That being > > said, there > > > > -- > > Dean > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 21 14:00:51 2004 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 OAA29629 for ; Thu, 21 Oct 2004 14:00:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhRl-0001ca-Me for sip-web-archive@ietf.org; Thu, 21 Oct 2004 14:13:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKgzu-0005sW-4y; Thu, 21 Oct 2004 13:45:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKgmv-00067m-BS for sip@megatron.ietf.org; Thu, 21 Oct 2004 13:31:45 -0400 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 NAA26146 for ; Thu, 21 Oct 2004 13:31:41 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKgzZ-0000cf-Vd for sip@ietf.org; Thu, 21 Oct 2004 13:44:50 -0400 Received: from phys-fll03-2 ([129.154.149.12]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9LHVguo014001 for ; Thu, 21 Oct 2004 11:31:43 -0600 (MDT) Received: from conversion-daemon.fll03-mail1.east.sun.com by fll03-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0I5Y00M011ZCXO@fll03-mail1.east.sun.com> (original mail from Mauricio.Arango@Sun.COM) for sip@ietf.org; Thu, 21 Oct 2004 13:31:42 -0400 (EDT) Received: from sun.com (vpn-129-150-64-49.East.Sun.COM [129.150.64.49]) by fll03-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0I5Y001TK3CSEG@fll03-mail1.east.sun.com>; Thu, 21 Oct 2004 13:31:42 -0400 (EDT) Date: Thu, 21 Oct 2004 13:35:39 -0400 From: Mauricio Arango To: CORVOYSIER David RD-MAPS-REN Message-id: <4177F36B.D297C250@sun.com> MIME-version: 1.0 X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=iso-8859-1 X-Accept-Language: en,pdf References: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by brmea-mail-3.sun.com id i9LHVguo014001 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: "sip@ietf.org" , Jonathan Rosenberg , simple@ietf.org Subject: [Sip] Re: [Simple] Usage of Contact header in PUBLISH for applicationauthentication ? X-BeenThere: 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: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Use of TLS between the app server and the presence server seems to assume that the PUBLISH request isn't routed through multiple intermediate SIP proxies, which shouldn't be a valid assumption even when both the app server and the presence server are in the same administrative domain. I believe the problem of a presence server authenticating the source of a PUBLISH request (application server) is provided in in draft-ietf-sip-identity-03. The other question you pose is how does the application server can authenticate the source of presence the information it collects. If the app server is in turn a SIMPLE presence server, then the approach in draft-ietf-sip-identity-03 can also be applied to its presence sources. If it isn't then a similar approach should be proposed via the use of authentication assertions granted by an authentication provider with which the presence sources authenticate. Mauricio Arango CORVOYSIER David RD-MAPS-REN wrote: > I'm jumping into that thread because the use case described by bernhard= is one of those I am also struggling with (presence published on behalf = of a presentity) ... > > So, from your answer I understand that TLS will authenticate the applic= ation server towards the presence server, but does this also mean that th= e presence server delegates user authentication to the application server= ? > In that case how can the application server be sure that the user is al= lowed to publish presence for the presentity ? I am probably missing some= thing but it seems to me that without some kind of control a user authent= icated by the app server could possibly publish presence for anyone ... > > -------------------------------- > David Corvoysier > France Telecom R&D > http://www.rd.francetelecom.com/ > -------------------------------- > > > -----Message d'origine----- > > De : simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] > > De la part de Jonathan Rosenberg > > Envoy=E9 : jeudi 21 octobre 2004 05:24 > > =C0 : Boehmer Bernhard ICM Berlin > > Cc : 'Aki Niemi'; SIMPLE WG > > Objet : Re: AW: [Simple] Usage of Contact header in PUBLISH > > for applicationa uthentication ? > > > > For cases where an application server is publishing, the > > right thing is to use mutual TLS between the application > > server and the presence server. The TLS certificates indicate > > the identity of the element generating the publish. There is > > no need for p-a-id here; the presence document would contain > > the identity of the presentity. Authorization policies in the > > presence server would typically make sure that the given > > application server can publish state for that presentity. > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 21 15:40:57 2004 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 PAA11713 for ; Thu, 21 Oct 2004 15:40:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKj0e-0004Tp-FU for sip-web-archive@ietf.org; Thu, 21 Oct 2004 15:54:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKidi-0004yO-6M; Thu, 21 Oct 2004 15:30:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKiYd-0000go-5y for sip@megatron.ietf.org; Thu, 21 Oct 2004 15:25:07 -0400 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 PAA10108 for ; Thu, 21 Oct 2004 15:25:05 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKilI-00048Z-PD for sip@ietf.org; Thu, 21 Oct 2004 15:38:13 -0400 Received: from [192.168.0.111] (adsl-209-30-28-252.dsl.rcsntx.swbell.net [209.30.28.252]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i9LJOw6E081014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Oct 2004 14:25:00 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <41780D08.3090007@nostrum.com> Date: Thu, 21 Oct 2004 14:24:56 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.6 (++++) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Subject: [Sip] Event Lists: Back-End Credentials X-BeenThere: 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: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit During IESG review of draft-ietf-simple-event-list-05, the IESG raised a concern that section 7.1 does not specify a mandatory-to-implement mechanism for transfer of a secret to the RLS. This secret transfer is necessary under some circumstances for the purposes of authenticating on the users behalf for back-end subscriptions. There is no clear-cut solution to this problem. The options that I've been able to think of -- and there are almost certainly more -- are as follows: * Make HTML forms mandatory The current example in the draft is to send the credentials in an HTML form over HTTP. Making this mandatory has the obvious drawback that it requires HTML browsers in all devices that make use of event lists. This is probably not an acceptable requirement. * Disallow back-end subscriptions altogether For this solution, the list server would pass back the resource list in notifications, along with state for any locally managed states. The client would be responsible for sending subscriptions for the state for any resources in the list that are not managed by the RLS. This defeats some of the purpose of event lists, since the client is left with maintaining several subscriptions for resources -- so it's really rather suboptimal. * Add new SIP header field (or maybe method) for credential upload One very simple solution would be to add a new header which contains a triple of [realm,userid,password]. We would specify that this header is disallowed except over SIPS connections. The client would include one or more such headers in its SUBSCRIBE request, and the RLS would use them to obtain information on the user's behalf. To make this work, we would also add a status field to the element that indicates something like "authorization failed" and the realm for which credentials are needed. The user, upon seeing this in the RLMI, could re-subscribe with the missing credentials. * Try to leverage ongoing work in draft-ietf-sip-identity and/or draft-jennings-sipping certs This feels like the class of problem that the ongoing identity work is trying to solve, but I can't figure out how to apply the existing drafts to it. The problem is that the RLS needs to change almost everything that would be protected by the identity draft. Of these, I prefer the simplicity of adding a new SIP header-- but I'm a bit scared of it because the obvious, most simple solution in security typically ends up being the wrong solution. However, I'll point out that the concern that was raised by the IESG was *not* that we are passing the user's secret to a third party; it was the fact that we're not defining *how* to do so. Unless I'm missing something, the RLS simply needs to be trusted to act on the user's behalf to make more-or-less arbitrary SUBSCRIBE requests, since the user doesn't know the contents of the list before subscribing. There might be some really clever way to do this without passing the user's secret over wholesale, but I don't see it. Thoughts? Ideas? Brilliant solutions? /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 21 20:41:36 2004 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 UAA14936 for ; Thu, 21 Oct 2004 20:41:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKnhf-00072m-4b for sip-web-archive@ietf.org; Thu, 21 Oct 2004 20:54:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKl8T-0007CY-Do; Thu, 21 Oct 2004 18:10:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKj8s-0003tk-Ly for sip@megatron.ietf.org; Thu, 21 Oct 2004 16:02:34 -0400 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 QAA14428 for ; Thu, 21 Oct 2004 16:02:32 -0400 (EDT) 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 1CKjLY-000565-T7 for sip@ietf.org; Thu, 21 Oct 2004 16:15:41 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 21 Oct 2004 13:19:26 +0000 X-BrightmailFiltered: true Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9LK0tYJ023242; Thu, 21 Oct 2004 13:00:56 -0700 (PDT) Received: from [10.32.245.154] (stealth-10-32-245-154.cisco.com [10.32.245.154]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id i9LK35bI029143; Thu, 21 Oct 2004 13:03:08 -0700 In-Reply-To: <41780D08.3090007@nostrum.com> References: <41780D08.3090007@nostrum.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Sip] Event Lists: Back-End Credentials Date: Thu, 21 Oct 2004 16:00:55 -0400 To: Adam Roach X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1098388990.91026"; x:"432200"; a:"rsa-sha1"; b:"nofws:4628"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"icJRJHoRqfBxaENFrRIx4fG2HtdPnlAPAXvj77b6NxduVOJf1r3UPj2LHtKPu" "sOliwvvLCpmUw1u8Ucv1dnopdLzK2JzSuuHXHD0MU4GcHEKXj35GBbO3MXUGU" "FRVtU1Pq6XBMR+oT84CeRZg3BarEYxZ1Es/NtOo4SFU+/QUak="; c:"From: David R Oran "; c:"Subject: Re: [Sip] Event Lists: Back-End Credentials"; c:"Date: Thu, 21 Oct 2004 16:00:55 -0400" 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: 5011df3e2a27abcc044eaa15befcaa87 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: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Sigh. Delegation is hard. I frankly don't like any of these solutions because they allow full user impersonation by the RLS, which is a lot more trust that I think ought to be given it. If we want to really tackle delegation, I'd suggest that we extend SIP generally to allow SIP-specific delegation capability. One way to do this is for the user to construct a certificate for the RLS giving it specific rights (e.g. Subscribe on my behalf), and then signing it based on a credential that would be accepted by the ultimate target of the request. SAML might be our friend here. It might be worth going back and seeing what applies to REFER as well while we're at it since REFER has some pretty brittle security properties due to our needing to to get done quickly. Dave. On Oct 21, 2004, at 3:24 PM, Adam Roach wrote: > During IESG review of draft-ietf-simple-event-list-05, the IESG raised > a concern that section 7.1 does not specify a mandatory-to-implement > mechanism for transfer of a secret to the RLS. This secret transfer is > necessary under some circumstances for the purposes of authenticating > on the users behalf for back-end subscriptions. > > There is no clear-cut solution to this problem. The options that I've > been able to think of -- and there are almost certainly more -- are as > follows: > > * Make HTML forms mandatory > > The current example in the draft is to send the credentials in an > HTML form over HTTP. Making this mandatory has the obvious drawback > that it requires HTML browsers in all devices that make use of event > lists. This is probably not an acceptable requirement. > > * Disallow back-end subscriptions altogether > > For this solution, the list server would pass back the resource list > in notifications, along with state for any locally managed states. > The client would be responsible for sending subscriptions for the > state for any resources in the list that are not managed by the RLS. > This defeats some of the purpose of event lists, since the client is > left with maintaining several subscriptions for resources -- so it's > really rather suboptimal. > > * Add new SIP header field (or maybe method) for credential upload > > One very simple solution would be to add a new header which contains > a triple of [realm,userid,password]. We would specify that this > header is disallowed except over SIPS connections. The client would > include one or more such headers in its SUBSCRIBE request, and the > RLS would use them to obtain information on the user's behalf. > > To make this work, we would also add a status field to the > element that indicates something like "authorization > failed" and the realm for which credentials are needed. The user, > upon seeing this in the RLMI, could re-subscribe with the missing > credentials. > > * Try to leverage ongoing work in draft-ietf-sip-identity and/or > draft-jennings-sipping certs > > This feels like the class of problem that the ongoing identity work > is trying to solve, but I can't figure out how to apply the existing > drafts to it. The problem is that the RLS needs to change almost > everything that would be protected by the identity draft. > > Of these, I prefer the simplicity of adding a new SIP header-- but I'm > a bit scared of it because the obvious, most simple solution in > security typically ends up being the wrong solution. However, I'll > point out that the concern that was raised by the IESG was *not* that > we are passing the user's secret to a third party; it was the fact > that we're not defining *how* to do so. > > Unless I'm missing something, the RLS simply needs to be trusted to > act on the user's behalf to make more-or-less arbitrary SUBSCRIBE > requests, since the user doesn't know the contents of the list before > subscribing. There might be some really clever way to do this without > passing the user's secret over wholesale, but I don't see it. > > Thoughts? Ideas? Brilliant solutions? > > /a > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > 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 Oct 21 21:50:46 2004 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 VAA27625 for ; Thu, 21 Oct 2004 21:50:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKomb-0001sL-KS for sip-web-archive@ietf.org; Thu, 21 Oct 2004 22:03:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKoFX-000635-13; Thu, 21 Oct 2004 21:29:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKmfg-0001kK-6p for sip@megatron.ietf.org; Thu, 21 Oct 2004 19:48:40 -0400 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 TAA03568 for ; Thu, 21 Oct 2004 19:48:36 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKmsN-0003BF-8m for sip@ietf.org; Thu, 21 Oct 2004 20:01:48 -0400 Received: from phys-fll03-2 ([129.154.149.12]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i9LNmb7s014717 for ; Thu, 21 Oct 2004 16:48:37 -0700 (PDT) Received: from conversion-daemon.fll03-mail1.east.sun.com by fll03-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0I5Y00D01K5UG1@fll03-mail1.east.sun.com> (original mail from Mauricio.Arango@Sun.COM) for sip@ietf.org; Thu, 21 Oct 2004 19:48:36 -0400 (EDT) Received: from sun.com (vpn-129-150-64-49.East.Sun.COM [129.150.64.49]) by fll03-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0I5Y0016OKSYEG@fll03-mail1.east.sun.com>; Thu, 21 Oct 2004 19:48:36 -0400 (EDT) Date: Thu, 21 Oct 2004 19:52:32 -0400 From: Mauricio Arango Subject: Re: [Sip] verifying identity of sender To: "Peterson, Jon" Message-id: <41784BC0.8E628594@sun.com> MIME-version: 1.0 X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en,pdf References: <7927C67249E4AD43BC05B539AF0D129801AF42C2@stntexch04.cis.neustar.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Content-Transfer-Encoding: 7BIT Cc: Cullen Jennings , sip@ietf.org, Juha Heinanen , 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: 612a16ba5c5f570bfc42b3ac5606ac53 Content-Transfer-Encoding: 7BIT Thanks for the update on unifications of the sip-identity and sip-saml drafts. Additional commments inline: "Peterson, Jon" wrote: > We're working towards a mid-term goal of unifying the existing sip-identity > work with the SIP-SAML draft. I suspect that the vehicle for this > unification while actually be the Identity-Info header rather than the > Identity header (i.e., Identity-Info could provide a means of accessing a > SAML assertion by reference). This scheme would work, it's actually the SAML IdP (Identity Provider) artifact binding approach. > > > However, I also believe it is critical that we aim towards a > universally-deployable, thinner identity assertion than SAML. SAML is heavy, > and requires a great deal of pre-association between the creator and For clarification, is the comment of "SAML heavy" because of the pre-associations only? > > consumer of assertions. We need something that addresses the impersonation > problem but doesn't entail the sorts of smarts required to make SAML work. > So in any regime, I believe sip-identity will have a place; SAML would > provide supplemental information commensurate with its intrinsic > versatility. Sounds like a good initial approach. Mauricio Arango > > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Mauricio Arango [mailto:Mauricio.Arango@Sun.COM] > > Sent: Wednesday, October 20, 2004 10:18 PM > > To: Dean Willis > > Cc: Cullen Jennings; sip@ietf.org; Juha Heinanen; Peterson, Jon > > Subject: Re: [Sip] verifying identity of sender > > > > > > Folks, > > > > I believe the approach described in draft-ietf-sip-identity-03, > > based on secure exchange of authentication assurances, is the right > > way to achieve end-to-end authentication among SIP entities that > > don't belong to the same administrative domain. > > > > However, I'd like to ask of why not use an already > > standardized structure, specifically SAML, for the > > proposed Identity header? Something similar has been > > already put forward in draft-tschofenig-sip-saml, where the > > 'Network Asserted Identities' case in Figure 3 is > > the closest to the approach in draft-ietf-sip-identity-03 > > (where the SAML Asserting party role is handled by > > the SIP Autentication proxy). > > > > Benefits of using SAML include: > > > > - Standardized and widely adopted structure for > > security (authentication, authorization, attribute) assertions. > > > > - Simplifies integration with other identity management systems. > > > > - Extensible, XML-based format - SIP-specific message information > > including headers (eg. Contact, Call-ID, CSeq) > > and the SDP body can be specified as new SAML > > attributes. > > > > - Transfer of attributes associated with the asserted > > identity, which enables trait-based authorization as > > described in draft-ietf-sipping-trait-authz-00. > > > > Regards, > > > > Mauricio Arango > > > > > > > > > > > > > > > > > > > > Dean Willis wrote: > > > > > Peterson, Jon wrote: > > > > > > >Again, Dean, my immediate concern here is whether or not > > this discussion > > > >about a hypothetical, partially-formulated alternative is > > material to the > > > >progression of sip-identity-03. > > > > > > > > > > > > > > > Ahah! No, this has NOTHING to do with impeding the Identity > > draft, as > > > far as I know. But it is a suggestion of another mechanism > > that MIGHT be > > > useful to talk about. As far as I know, it NEVER had > > anything to do with > > > the identity draft, but was a suggestion of another > > technique that might > > > also be useful, and deployable in the nearer term. I think > > we've roughly > > > concluded that the specific idea suggested has little or no > > benefit over > > > a simpler operatioal procedure, but the exercise of that analysis is > > > probably something useful for the larger community. > > > > > > >While it is interesting to discuss alternatives that > > provide a weaker > > > >assurance, I see no reason why the exploration of those > > alternatives should > > > >impede the standardization of a system that seems to > > satisfy the broader > > > >requirement. > > > > > > > > > > > > > > Me neither. > > > > > > >Ultimately, this thread was kicked off with the contention > > that acquiring > > > >certificates is infeasible. Both Cullen and I provided > > some data about > > > >certificate acquisition that seemed to argue that the > > problem isn't nearly > > > >so bad. If you can get a publicly-verifiable certificate > > for under $100 a > > > >year, then the expenditure is on the same order of > > magnitude as acquiring a > > > >domain name. I haven't yet heard the parallel argument > > that domain names are > > > >so expensive and administratively cumbersome that we > > should invent a new > > > >alternative system for locating SIP servers, but in my > > opinion, this > > > >contention would carry roughly the same weight as the > > arguments I've heard > > > >against certificates so far. > > > > > > > > > > > > > > > Yes, but this thread SUGGESTED operational policies that, > > in the absence > > > of universal certificate deployment, might cut down on sip-spam. > > > > > > >If there is in fact no problem with making certificates a > > component of the > > > >identity architecture, then I'm not sure why we want to explore the > > > >specification of alternatives. Alternatives are bad, when > > it comes to > > > >security. I continue to believe that we should set a > > long-term goal of > > > >arriving a single mandatory-to-use identity mechanism for > > SIP. Partial > > > >solutions will not get us where we need to be. > > > > > > > > > > > > > > > Operational procedures can be put in place in the "near end", (the > > > domain individual operators are operating and protecting), and > > > certificates gain little utility until they happen to be > > widely deployed > > > at the FAR end, over which said operator has little > > control. That being > > > said, there > > > > > > -- > > > Dean > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 21 21:51:04 2004 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 VAA27683 for ; Thu, 21 Oct 2004 21:51:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKomt-0001sz-WC for sip-web-archive@ietf.org; Thu, 21 Oct 2004 22:04:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKoFw-0006yY-27; Thu, 21 Oct 2004 21:30:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKmkP-0003kr-GO for sip@megatron.ietf.org; Thu, 21 Oct 2004 19:53:34 -0400 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 TAA04598 for ; Thu, 21 Oct 2004 19:53:20 -0400 (EDT) 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 1CKmwx-0003VE-1J for sip@ietf.org; Thu, 21 Oct 2004 20:06:32 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 21 Oct 2004 17:01:21 -0700 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 i9LNrJ6s015013; Thu, 21 Oct 2004 16:53:20 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.96.48]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id i9LNtFmg029752; Thu, 21 Oct 2004 16:55:15 -0700 From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16760.19438.367703.86167@thomasm-u1.cisco.com> Date: Thu, 21 Oct 2004 16:53:18 -0700 (PDT) To: Dean Willis Subject: [Sip] Discussion on draft-ietf-sip-identity-03.txt In-Reply-To: <4175A4E0.2000208@softarmor.com> References: <4175A4E0.2000208@softarmor.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &, heK/V66p?[2!i|tVn, 9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a), -7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d, g">$%B!0w{W)qIhmwhye104zd bUcI'1! IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1098402915.383157"; x:"432200"; a:"rsa-sha1"; b:"nofws:1999"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"pEfQCkniYOC6/L1eRabzbDmtYCfFjcpzSp904SNvQc3x6xjP6jeDFNofJJRbE" "K1uR0kdu+lOQu8QL4nordxupNjTE9YM7b+zYMCPzg0CLNsxX+XacuTLyNyJfA" "hfqiR4rjW2Inqzb/1wf5oUiT3BtB40D+JE3vb8zU5UKnrgt2g="; c:"From: Michael Thomas "; c:"Date: Thu, 21 Oct 2004 16:53:18 -0700 (PDT)"; c:"Subject: [Sip] Discussion on draft-ietf-sip-identity-03.txt" 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: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, rohan Mahy , Allison Mankin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Dean Willis writes: > > Wearing my chair hat and thinking about draft-ietf-sip-identity-03, > which IS an approved working-group effort that WAS scheduled to be > finished last April . . . > > From the minutes at IETF 60: "It was observed that few participants in > the room displayed confidence in their understanding of the problem or > the proposal, and that further study would be a Good Thing." > > Since then, we have talked a lot about identity-related issues on the list. > > We've hashed through some of the less-understood issues, including the > tremendous similarity between the SIP spam problem and the SMTP spam > problem, and Michael Thomas pointed us at the MASS work, which is > astoundingly similar to sip-identity. >From my poor understanding, the principle difference is what the trust anchor is. That has a tendency to either make or break these things, especially in the large... which is what led us to our use of DNS as a somewhat more "conservative" compromise of deployability over security. But! The question that I really have is whether anybody is implementing and especially deploying this, and if so, obviously how it's going. We're getting a lot of interest on the MASS front due to the dire situation with email which may in fact move some of these immovable objects, so unless people are actually making use of this, waiting to see what happens may not be a terrible option. > Jon and Cullen proved that real CS-signed certificates are readily > available at a cost not significantly different than that of a domain > registration, or slightly less than the price of a decent bottle of > Scotch, for some definition of the word "decent". There's more to it than money, of course; there's institutional, um, considerations too. And PKI's don't have a very encouraging track record beyond web stuff; whether it's reasonable being a different question than whether it is. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 21 21:58:09 2004 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 VAA28866 for ; Thu, 21 Oct 2004 21:58:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKotk-0002Dz-TQ for sip-web-archive@ietf.org; Thu, 21 Oct 2004 22:11:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKoJN-0007Tz-1E; Thu, 21 Oct 2004 21:33:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKnTt-0004Bj-1e for sip@megatron.ietf.org; Thu, 21 Oct 2004 20:40:33 -0400 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 UAA14687 for ; Thu, 21 Oct 2004 20:40:30 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKngb-0006xD-1k for sip@ietf.org; Thu, 21 Oct 2004 20:53:41 -0400 Received: from [192.168.0.111] (adsl-209-30-28-252.dsl.rcsntx.swbell.net [209.30.28.252]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i9M0eMAj010592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Oct 2004 19:40:23 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <417856F4.9070303@nostrum.com> Date: Thu, 21 Oct 2004 19:40:20 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David R Oran Subject: Re: [Sip] Event Lists: Back-End Credentials References: <41780D08.3090007@nostrum.com> In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.6 (++++) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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: 4.6 (++++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit David R Oran wrote: > Sigh. Delegation is hard. I frankly don't like any of these solutions > because they allow full user impersonation by the RLS, which is a lot > more trust that I think ought to be given it. I'm not too crazy about them either (I'll note that suggestion #2 doesn't have that property, but at the cost of making the protocol far less useful). > > If we want to really tackle delegation, I'd suggest that we extend SIP > generally to allow SIP-specific delegation capability. One way to do > this is for the user to construct a certificate for the RLS giving it > specific rights (e.g. Subscribe on my behalf), and then signing it > based on a credential that would be accepted by the ultimate target of > the request. SAML might be our friend here. That feels a lot like what I was trying to get at with my suggestion #4, albeit with a slightly different mechanism. The problem is that pursuing this kind of work will be very time consuming... and the event list document has been in limbo for over a year already. I'm not necessarily advocating expediency over security -- it's been so long since I started this work that I'm half inclined to cripple it (by removing back-end subscriptions) rather than wait several years for a general purpose solution to the delegation problem. Not that I *want* to do this -- it would remove most of the utility of the extension for the 3G guys -- but I do want to put this work to bed. I'm not sure if it represents a reasonable compromise, but I'm not averse to putting in the "use this header to transfer your secret" with a strongly worded note indicating the implications if you do, and an indication that future mechanisms may define more constrained ways to delegate limited subsets of authority to another node (possibly for a constrained time period). /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 22 02:51:50 2004 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 CAA04923 for ; Fri, 22 Oct 2004 02:51:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKtTx-0007Va-O0 for sip-web-archive@ietf.org; Fri, 22 Oct 2004 03:05:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKtDs-0003Ff-1y; Fri, 22 Oct 2004 02:48:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKtAF-000178-4K for sip@megatron.ietf.org; Fri, 22 Oct 2004 02:44:39 -0400 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 CAA04585 for ; Fri, 22 Oct 2004 02:44:37 -0400 (EDT) From: hongchuan.yuan@263.net Received: from mx04.263.net ([211.150.96.24] helo=smtp.263.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKtMy-0007O9-VQ for sip@ietf.org; Fri, 22 Oct 2004 02:57:49 -0400 Received: by smtp.263.net (Postfix, from userid 500) id 05940435AE; Fri, 22 Oct 2004 14:44:23 +0800 (CST) To: sip@ietf.org Date: Fri, 22 Oct 2004 14:56:50 +0800 X-Priority: 3 X-MSMail-Priority: Normal MIME-Version: 1.0 X-Mailer: XMail-3.0 Message-Id: <20041022064423.05940435AE@smtp.263.net> X-Spam-Score: 3.2 (+++) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [Sip] Location 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: , Content-Type: multipart/mixed; boundary="===============0405311527==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 --===============0405311527== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+PHByZT48UFJFPmhlbGxvLGV2ZXJ5b25lPC9QUkU+PFBSRT5jYW4geW91IGdpdmUg c29tZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgY3VycmVudCBzdGF0dXMgb2YgImxvY2F0aW9u IiBoZWFkZXIgaW4gU0lQLjwvUFJFPjxQUkU+dGhhbnMuPC9QUkU+PFBSRT4mbmJzcDs8L1BS RT48L3ByZT48L2h0bWw+DQoNCg0KDQoNCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT0N CjI2M7Xn19PTyrz+o63QxcC108rX1Neo0rUNCg== --===============0405311527== 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 --===============0405311527==-- From sip-bounces@ietf.org Fri Oct 22 06:14:51 2004 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 GAA17969 for ; Fri, 22 Oct 2004 06:14:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKweU-0002e4-7F for sip-web-archive@ietf.org; Fri, 22 Oct 2004 06:28:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKwMY-0000xo-39; Fri, 22 Oct 2004 06:09:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKwL3-0000aj-SO for sip@megatron.ietf.org; Fri, 22 Oct 2004 06:08:01 -0400 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 GAA17524 for ; Fri, 22 Oct 2004 06:07:58 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKwXp-0002WW-18 for sip@ietf.org; Fri, 22 Oct 2004 06:21:14 -0400 Received: from send.forptr.21cn.com ([202.105.45.50] helo=21cn.com) by mx2.foretec.com with smtp (Exim 4.24) id 1CKwKz-0002Ag-Jn for sip@ietf.org; Fri, 22 Oct 2004 06:07:58 -0400 Received: from avcongao([127.0.0.1]) by 21cn.com(AIMC 2.9.5.6) with SMTP id jm041793159; Fri, 22 Oct 2004 18:06:29 +0800 Received: from avcongao([211.160.163.36]) by 21cn.com(AIMC 2.9.5.4) with SMTP id AISP action; Fri, 22 Oct 2004 18:06:26 +0800 Message-ID: <001901c4b81e$f10fca10$f700a8c0@avcongao> From: "gao" To: References: Date: Fri, 22 Oct 2004 18:07:28 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-AIMC-AUTH: gao1028 X-AIMC-MAILFROM: gao1028@21cn.com X-Spam-Score: 4.7 (++++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Subject: [Sip] gao1028@21cn.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1126044184==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 4.7 (++++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab --===============1126044184== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 bWU= --===============1126044184== 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 --===============1126044184==-- From sip-bounces@ietf.org Fri Oct 22 08:50:16 2004 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 IAA29465 for ; Fri, 22 Oct 2004 08:50:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKz4t-0005Qt-Vn for sip-web-archive@ietf.org; Fri, 22 Oct 2004 09:03:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKynS-0002Bj-Tz; Fri, 22 Oct 2004 08:45:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKyeT-0007Zb-NK; Fri, 22 Oct 2004 08:36:13 -0400 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 IAA28558; Fri, 22 Oct 2004 08:36:11 -0400 (EDT) Received: from ns2.bln1.siemens.de ([194.138.127.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKyrG-00058V-FQ; Fri, 22 Oct 2004 08:49:27 -0400 Received: from ns-srv-2.bln1.siemens.de (stbf7654 [194.138.127.67]) by ns2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id i9MCZMaP021925; Fri, 22 Oct 2004 14:35:22 +0200 (MEST) Received: from blnss10a.bln1.siemens.de (blnss10a.bln1.siemens.de [194.138.127.102]) by ns-srv-2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id i9MCZHDm022894; Fri, 22 Oct 2004 14:35:17 +0200 (MEST) Received: by blnss10a.bln1.siemens.de with Internet Mail Service (5.5.2657.72) id ; Fri, 22 Oct 2004 14:35:17 +0200 Message-ID: <445C57B81208C24EAD99F2944DBB9D2908FE3979@blnss10a.bln1.siemens.de> From: Boehmer Bernhard ICM Berlin To: "'David R Oran'" , Adam Roach Subject: AW: [Sip] Event Lists: Back-End Credentials Date: Fri, 22 Oct 2004 14:35:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, "'Mauricio.Arango@Sun.COM'" , Simple 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: 995b2e24d23b953c94bac5288c432399 Content-Transfer-Encoding: quoted-printable Hi, I think controlling whether an RLS (or in a general any service)=20 can perform certain subscriptions or publications (in case of=20 presence) should be controlled by the notifier/PUBLISH-recipient. Thus, additionally to the control whether a certain *user* is allowed = to subscribe/publish the notifier/PUBLISH recipient should be also able to control whether an *application* is allowed to act on behalf of the user. Currently, the needed application authentication is under = discussion (see the SIMPLE thread=20 "[Simple] Usage of Contact header in PUBLISH for application = authentication?"). Mauricio also mentioned the identity draft in this thread but I haven't = yet=20 discovered how this drafts solves this issue. Bernhard > -----Urspr=FCngliche Nachricht----- > Von: David R Oran [mailto:oran@cisco.com]=20 > Gesendet: Donnerstag, 21. Oktober 2004 22:01 > An: Adam Roach > Cc: sip@ietf.org > Betreff: Re: [Sip] Event Lists: Back-End Credentials >=20 >=20 > Sigh. Delegation is hard. I frankly don't like any of these solutions = > because they allow full user impersonation by the RLS, which is a lot = > more trust that I think ought to be given it. >=20 > If we want to really tackle delegation, I'd suggest that we=20 > extend SIP=20 > generally to allow SIP-specific delegation capability. One way to do=20 > this is for the user to construct a certificate for the RLS giving it = > specific rights (e.g. Subscribe on my behalf), and then signing it=20 > based on a credential that would be accepted by the ultimate=20 > target of=20 > the request. SAML might be our friend here. >=20 > It might be worth going back and seeing what applies to REFER as well = > while we're at it since REFER has some pretty brittle security=20 > properties due to our needing to to get done quickly. >=20 > Dave. >=20 > On Oct 21, 2004, at 3:24 PM, Adam Roach wrote: >=20 > > During IESG review of draft-ietf-simple-event-list-05, the=20 > IESG raised=20 > > a concern that section 7.1 does not specify a=20 > mandatory-to-implement=20 > > mechanism for transfer of a secret to the RLS. This secret=20 > transfer is=20 > > necessary under some circumstances for the purposes of=20 > authenticating=20 > > on the users behalf for back-end subscriptions. > > > > There is no clear-cut solution to this problem. The options=20 > that I've=20 > > been able to think of -- and there are almost certainly=20 > more -- are as=20 > > follows: > > > > * Make HTML forms mandatory > > > > The current example in the draft is to send the credentials in = an > > HTML form over HTTP. Making this mandatory has the=20 > obvious drawback > > that it requires HTML browsers in all devices that make=20 > use of event > > lists. This is probably not an acceptable requirement. > > > > * Disallow back-end subscriptions altogether > > > > For this solution, the list server would pass back the=20 > resource list > > in notifications, along with state for any locally=20 > managed states. > > The client would be responsible for sending subscriptions for = the > > state for any resources in the list that are not managed=20 > by the RLS. > > This defeats some of the purpose of event lists, since=20 > the client is > > left with maintaining several subscriptions for=20 > resources -- so it's > > really rather suboptimal. > > > > * Add new SIP header field (or maybe method) for=20 > credential upload > > > > One very simple solution would be to add a new header=20 > which contains > > a triple of [realm,userid,password]. We would specify that this > > header is disallowed except over SIPS connections. The=20 > client would > > include one or more such headers in its SUBSCRIBE=20 > request, and the > > RLS would use them to obtain information on the user's behalf. > > > > To make this work, we would also add a status field to the > > element that indicates something like "authorization > > failed" and the realm for which credentials are needed. The = user, > > upon seeing this in the RLMI, could re-subscribe with the = missing > > credentials. > > > > * Try to leverage ongoing work in draft-ietf-sip-identity and/or > > draft-jennings-sipping certs > > > > This feels like the class of problem that the ongoing=20 > identity work > > is trying to solve, but I can't figure out how to apply=20 > the existing > > drafts to it. The problem is that the RLS needs to change almost > > everything that would be protected by the identity draft. > > > > Of these, I prefer the simplicity of adding a new SIP=20 > header-- but I'm=20 > > a bit scared of it because the obvious, most simple solution in=20 > > security typically ends up being the wrong solution. However, I'll=20 > > point out that the concern that was raised by the IESG was=20 > *not* that=20 > > we are passing the user's secret to a third party; it was the fact=20 > > that we're not defining *how* to do so. > > > > Unless I'm missing something, the RLS simply needs to be trusted to = > > act on the user's behalf to make more-or-less arbitrary SUBSCRIBE=20 > > requests, since the user doesn't know the contents of the=20 > list before=20 > > subscribing. There might be some really clever way to do=20 > this without=20 > > passing the user's secret over wholesale, but I don't see it. > > > > Thoughts? Ideas? Brilliant solutions? > > > > /a > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > 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 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 22 15:46:54 2004 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 PAA03790 for ; Fri, 22 Oct 2004 15:46:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL5aA-0005EA-FV for sip-web-archive@ietf.org; Fri, 22 Oct 2004 16:00:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL5Kn-0000id-ET; Fri, 22 Oct 2004 15:44:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL5Eu-0005TK-Ec for sip@megatron.ietf.org; Fri, 22 Oct 2004 15:38:16 -0400 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 PAA03107 for ; Fri, 22 Oct 2004 15:38:12 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL5Rj-00052t-CE for sip@ietf.org; Fri, 22 Oct 2004 15:51:32 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 22 Oct 2004 12:38:31 -0700 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i9MJZKBX016278; Fri, 22 Oct 2004 12:37:38 -0700 (PDT) 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 MAA18698; Fri, 22 Oct 2004 12:26:27 -0700 (PDT) Message-Id: <4.3.2.7.2.20041022141842.02749ce8@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Oct 2004 14:26:26 -0500 To: hongchuan.yuan@263.net, sip@ietf.org From: "James M. Polk" Subject: Re: [Sip] Location Header In-Reply-To: <20041022064423.05940435AE@smtp.263.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.1 (+) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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: 1.1 (+) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable At 02:56 PM 10/22/2004 +0800, hongchuan.yuan@263.net wrote: >hello,everyone >can you give some information about the current status of "location"=20 >header in SIP. There is no location "header" in SIP, but a location MIME body part effort= =20 in the SIPPING WG - which is based on the PIDF-LO that was defined in the=20 Geopriv WG. The SIPPING effort is being defined in the ID: http://www.ietf.org/internet-drafts/draft-ietf-sipping-location-requirements= -01.txt The above effort will be updated in the next few days to version -02 and=20 announced on the SIPPING list. BTW - the PIDF-LO ID from Geopriv is at: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pidf-lo-03.txt and is in the RFC-Editor now. >thans. > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D 263=B5=E7=D7=D3=D3=CA=BC=FE=A3=AD=D0=C5=C0=B5=D3=CA=D7=D4=D7=A8=D2=B5 >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 22 18:38:24 2004 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 SAA05004 for ; Fri, 22 Oct 2004 18:38:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL8GB-0006OD-0z for sip-web-archive@ietf.org; Fri, 22 Oct 2004 18:51:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL7ou-0004Zp-G1; Fri, 22 Oct 2004 18:23:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL775-0000PB-Jz; Fri, 22 Oct 2004 17:38:19 -0400 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 RAA22691; Fri, 22 Oct 2004 17:38:15 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL7Jw-0002g9-4L; Fri, 22 Oct 2004 17:51:36 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i9MLani28481; Fri, 22 Oct 2004 14:36:49 -0700 (PDT) Message-Id: <200410222136.i9MLani28481@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 22 Oct 2004 14:36:49 -0700 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: sip@ietf.org, rfc-editor@rfc-editor.org Subject: [Sip] RFC 3911 on The Session Initiation Protocol (SIP) "Join" 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: -14.6 (--------------) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3911 Title: The Session Initiation Protocol (SIP) "Join" Header Author(s): R. Mahy, D. Petrie Status: Standards Track Date: October 2004 Mailbox: rohan@airespace.com, dpetrie@pingtel.com Pages: 17 Characters: 35373 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sip-join-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3911.txt This document defines a new header for use with SIP multi-party applications and call control. The Join header is used to logically join an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: "Barge-In", answering-machine-style "Message Screening" and "Call Center Monitoring". Note that definition of these example features is non-normative. This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <041022143515.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3911 --OtherAccess Content-Type: Message/External-body; name="rfc3911.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <041022143515.RFC@RFC-EDITOR.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 Fri Oct 22 18:39:17 2004 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 SAA05196 for ; Fri, 22 Oct 2004 18:39:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL8H0-0006S5-Ic for sip-web-archive@ietf.org; Fri, 22 Oct 2004 18:52:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL7ow-0004dB-PB; Fri, 22 Oct 2004 18:23:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL77Z-0000n4-6N for sip@megatron.ietf.org; Fri, 22 Oct 2004 17:38:49 -0400 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 RAA22801 for ; Fri, 22 Oct 2004 17:38:43 -0400 (EDT) Received: from pmesmtp02.wcom.com ([199.249.20.2] helo=pmesmtp02.mci.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL7KN-0002hJ-1L for sip@ietf.org; Fri, 22 Oct 2004 17:52:04 -0400 Received: from pmismtp05.wcomnet.com ([166.38.62.53]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0I6000HHX99M43@firewall.wcom.com> for sip@ietf.org; Fri, 22 Oct 2004 21:34:34 +0000 (GMT) Received: from pmismtp05.wcomnet.com by pmismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0I600010199MHL@pmismtp05.mcilink.com>; Fri, 22 Oct 2004 21:34:34 +0000 (GMT) Received: from ThinkpadT40 ([131.146.1.104]) by pmismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0I6000M4I99KZR@pmismtp05.mcilink.com>; Fri, 22 Oct 2004 21:34:34 +0000 (GMT) Date: Fri, 22 Oct 2004 16:34:31 -0500 From: Henry Sinnreich To: sip@ietf.org Message-id: <0I6000M4J99LZR@pmismtp05.mcilink.com> Organization: MCI MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AcS4ftACDEcZYrggR3mpSOCnIf8/fw== X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: "'Rohan Mahy'" , "'Dean Willis'" , "'Peterson, Jon'" , mankin@psg.com Subject: [Sip] draft-ietf-sip-identity-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.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit The I-D on "Certificate Management Service for SIP" ( http://www.ietf.org/internet-drafts/draft-ietf-sipping-certs-00.txt ) addresses a problem we have been struggling with for some time. It is the very approach that makes sense IMHO. I propose we put it on the agenda to discuss and make it a WG item. Thanks, Henry Henry Sinnreich MCI 1201 E. Arapaho Rd./Office 1020 Richardson, Texas 75081 USA _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 22 18:54:07 2004 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 SAA07854 for ; Fri, 22 Oct 2004 18:54:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL8VO-0007Nd-1o for sip-web-archive@ietf.org; Fri, 22 Oct 2004 19:07:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL7pe-0005uU-Og; Fri, 22 Oct 2004 18:24:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL7D6-0005CE-SY for sip@megatron.ietf.org; Fri, 22 Oct 2004 17:44:32 -0400 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 RAA24246 for ; Fri, 22 Oct 2004 17:44:28 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL7Px-0003Eh-BR for sip@ietf.org; Fri, 22 Oct 2004 17:57:49 -0400 Received: from [10.1.11.198] (inetgate.teknekron.com [192.138.162.245] (may be forged)) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i9MLiQ76011124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 22 Oct 2004 16:44:27 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <41797F3A.8040705@nostrum.com> Date: Fri, 22 Oct 2004 16:44:26 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Subject: [Sip] New version event lists 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.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit I have just submitted a new version of the event list draft for publication. Until it appears in the archives, you can retrieve a copy from: http://www.nostrum.com/~adam/ids/draft-ietf-simple-event-list-06.txt /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Oct 22 19:00:27 2004 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 TAA09586 for ; Fri, 22 Oct 2004 19:00:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL8bV-0007wx-3H for sip-web-archive@ietf.org; Fri, 22 Oct 2004 19:13:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL7q3-0006nK-Jb; Fri, 22 Oct 2004 18:24:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL7GC-0006lC-UG for sip@megatron.ietf.org; Fri, 22 Oct 2004 17:47:45 -0400 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 RAA25193 for ; Fri, 22 Oct 2004 17:47:39 -0400 (EDT) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL7Sz-0003Us-Hy for sip@ietf.org; Fri, 22 Oct 2004 18:01:00 -0400 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id i9MLl0Pm009653; Fri, 22 Oct 2004 21:47:00 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Fri, 22 Oct 2004 17:47:00 -0400 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF42D2@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'Mauricio Arango'" Subject: RE: [Sip] verifying identity of sender Date: Fri, 22 Oct 2004 17:46:59 -0400 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: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Cullen Jennings , sip@ietf.org, Juha Heinanen , 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f > -----Original Message----- > From: Mauricio Arango [mailto:Mauricio.Arango@Sun.COM] > > For clarification, is the comment of "SAML heavy" because of the > pre-associations only? Pre-association and federation, agreement on various SAML attribute and so on is one aspect of it. I also think the support for XML, web services, and so on cannot be universally assumed in a SIP environment - a widespread mandate for SAML support would entail a lot of additional development, beyond SIP's current implementation challenge. Our emphasis in identity design has been on providing a very light solution, something that doesn't require us to diverge significantly from the operational models and implementation already described in the core standard. We also want to provide something for identity that is universal, and useful in essentially all contexts that SIP is used. I don't think we can position SAML to play that part in SIP's architecture, though it can certainly provide valuable supplemental security assertions for some deployments. Jon Peterson NeuStar, Inc. > > Sounds like a good initial approach. > > Mauricio Arango > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 22 19:04:29 2004 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 TAA10556 for ; Fri, 22 Oct 2004 19:04:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL8fF-0008CA-Co for sip-web-archive@ietf.org; Fri, 22 Oct 2004 19:17:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL7ra-0000Xu-LC; Fri, 22 Oct 2004 18:26:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL7YA-0007Na-Dp for sip@megatron.ietf.org; Fri, 22 Oct 2004 18:06:18 -0400 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 SAA28560 for ; Fri, 22 Oct 2004 18:06:13 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL7l0-0004el-BI for sip@ietf.org; Fri, 22 Oct 2004 18:19:35 -0400 Received: from [63.110.3.195] ([63.110.3.195]) (authenticated bits=0) by nylon.softarmor.com (8.12.11/8.12.11) with ESMTP id i9MM6KKO007557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Oct 2004 17:06:20 -0500 Message-ID: <41798441.30501@softarmor.com> Date: Fri, 22 Oct 2004 17:05:53 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henry Sinnreich References: <0I6000M4J99LZR@pmismtp05.mcilink.com> In-Reply-To: <0I6000M4J99LZR@pmismtp05.mcilink.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, "'Rohan Mahy'" , "'Peterson, Jon'" , mankin@psg.com Subject: [Sip] Re: draft-ietf-sip-identity-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.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Henry Sinnreich wrote: >The I-D on "Certificate Management Service for SIP" ( >http://www.ietf.org/internet-drafts/draft-ietf-sipping-certs-00.txt ) >addresses a problem we have been struggling with for some time. It is the >very approach that makes sense IMHO. > >I propose we put it on the agenda to discuss and make it a WG item. > > > It is now a working group item, and I expect we'll be talking about it. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Oct 25 12:03:09 2004 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 MAA09011 for ; Mon, 25 Oct 2004 12:03:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM7Wu-0001aX-AZ for sip-web-archive@ietf.org; Mon, 25 Oct 2004 12:17:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM78s-00067I-Oz; Mon, 25 Oct 2004 11:52:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM6w8-0003j2-IZ for sip@megatron.ietf.org; Mon, 25 Oct 2004 11:39:08 -0400 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 LAA05304 for ; Mon, 25 Oct 2004 11:39:05 -0400 (EDT) Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM79b-0000ZK-Lj for sip@ietf.org; Mon, 25 Oct 2004 11:53:04 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0I6500J01CP7T4@siemenscomms.co.uk> for sip@ietf.org; Mon, 25 Oct 2004 16:36:44 +0100 (BST) Received: from ntht206e.siemenscomms.co.uk ([137.223.247.52]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0I6500IAPCP6SG@siemenscomms.co.uk> for sip@ietf.org; Mon, 25 Oct 2004 16:36:42 +0100 (BST) Received: by ntht206e.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 25 Oct 2004 16:38:30 +0100 Content-return: allowed Date: Mon, 25 Oct 2004 16:38:29 +0100 From: "Elwell, John" Subject: FW: [Sip] Proposed bug fix to RFC3261 arising from draft-elwell-s ip-state-u pdate-02 To: "'sip@ietf.org'" Message-id: <50B1CBA96870A34799A506B2313F26670252D4D2@ntht201e> 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: d9238570526f12788af3d33c67f37625 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: ff0adf256e4dd459cc25215cfa732ac1 Content-Transfer-Encoding: 7BIT I received no responses to the following mail, asking for opinions on which direction to take. The default is, of course, option 1 (do nothing - no clarifications to state update will be made). Therefore in the absence of any proposals to the contrary by the Washington meeting, I will drop this work. John Elwell (john.elwell@siemens.com) > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: 01 October 2004 09:10 > To: 'Paul Kyzivat' > Cc: 'sip@ietf.org' > Subject: RE: [Sip] Proposed bug fix to RFC3261 arising from > draft-elwell-s ip-state-u pdate-02 > > Paul, > > Thanks for your comment. You have made it clear before that there is a > distinction between call state and dialog state, and that there is not > always a 1:1 relationship between them. > > However, there are moves to deprecate dialog re-use. So > although there are > examples of dialog re-use today (the REFER case being the > prime example), I > don't anticipate new applications of this technique to be > endorsed and there > is likely to be a move to phase out existing forms of re-use. > > Moreover there cannot be more than one call per dialog. Therefore if a > dialog supports a call, there is not a lot of difference in principle > between dialog state and call state, although if the dialog > also supports a > subscription, call state information will not survive after a > BYE, even > though dialog state will survive if the subscription survives. > > With these considerations in mind, perhaps we don't need to > put an excessive > amount of effort into distinguishing between call state and > dialog state. > Call state just becomes a part of dialog state, existing on > dialogs that > support calls but not on dialogs that support subscriptions. > > I eliminated some of the elements such as Call-Info, the > updating of which > did not appear to be of great interest to anyone and which, > as you say, are > call state. Yes, session information I guess is also call state. > > I forgot to add Required/Supported/Allowed headers, which I > guess are in > fact part of the dialog state. From other specifications, PAI > is an example > of data that is part of dialog state. > > I guess the main question we need to answer is whether this proposed > clarification to RFC3261 (and eventually RFC3311) should > embrace dialog > state change, call state change or both. One difficulty is > that the term > "call" is not well-defined in RFC3261 (the Call-Id header > unfortunately is > dialog state, not call state). Then the question arises > whether we should > embark on trying to define the term call and hence call state. > > So I see the following options, and I would like some > feedback from the > list: > > 1. Do nothing. > > 2. Do not attempt to distinguish between call state and > dialog state, on the > basis that the desire is to phase out dialog re-use (some > dialogs will of > course also be calls, but a dialog should not serve two purposes: > subscription and call). In other words, continue as proposed > in my previous > email (possibly restoring things like Call-Info if there is interest). > > 3. Stick rigidly to dialog state (so session information > would be removed > from my proposal). > > 4. Define "call" and "call state" and distinguish them from > "dialog" and > "dialog state". Handle both call state update and dialog state update. > > Opinions please. > > John Elwell (john.elwell@siemens.com) > > Paul Kyzivat wrote: > I agree with what you are trying to do. But one rather significant > detail with what you propose is that I don't believe the session > description (SDP) is dialog state. It is call state. (A dialog that > exists for the purpose of a SUBSCRIBE would not have this.) > > That in some sense guts this proposal, since now there are no > examples > in this document of additional dialog state. However I still > think the > clarification is needed. > > In addition, 3261 sweeps the distinction between dialog state > and call > state under the rug. Once alternative uses of dialogs are in > play it is > important to make this distinction clear, and to identify those items > that are part of call state. This includes the session > description info > (the negotiated offer and answer as well as potentially > another proposed > change to offer and answer). It also includes the data > associated with > session timer, and possibly Call-Info, Alert-Info, Subject. (Which if > any of these is truly call state remains to be discussed.) > > Paul > > Elwell, John wrote: > > At the SIP meeting in San Diego, I was asked to raise on > the mailing list > > the individual bug fixes proposed in the state-update > draft, so that each > > can be given due scrutiny. I decided to start with RFC3261. > Here only a > few > > changes are proposed and it does not seem sensible to consider these > > separately, so I propose them here as a single bug fix. If > we can gain > > consensus on those, I will follow it up with messages > proposing bug fixes > to > > the other documents (mainly RFC3311). > > > > As a result of comments by Paul Kyzivat raised on the list > recently, I > have > > modified the proposed changes slightly. In particular, I > have dropped any > > headers that are not obviously dialog state changes, > including those that > > might not be considered state at all (e.g., Alert-Info) and > those that > might > > be considered call state rather than dialog state (e.g., Call-Info, > > Subject). If anyone wants these re-instating, please say so. > > > > Proposed bug fix to RFC3261: > > > > Add the following paragraph to the end of 12 (prior to 12.1): > > > > "A dialog can also have certain other state information > that can change > > during the lifetime of the dialog. This includes the > session description > (as > > negotiated by SDP offer/answer), information from certain > other headers > and > > information from certain other bodies. There are no > examples from this > RFC. > > However, extensions may define other headers or bodies containing > > information that contributes to the state of a dialog and can change > during > > the lifetime of the dialog." > > > > Add two new paragraphs to the end of 12.2 (prior to 12.2.1): > > > > "A request, whether or not it is a target refresh request, > MAY update > > certain other information transmitted at the time of dialog > establishment. > > Although there are no examples in this RFC, other > extensions may define > > headers or bodies that are appropriate for updating during a dialog. > > > > "In this RFC, the only request defined that is suitable for updating > > information during a dialog is re-INVITE (see section 14). Other > extensions > > may define different requests suitable for updating > information during a > > dialog." > > > > Add to the end of the first paragraph of 14.1: > > > > "A UAC MAY send a session description that is unchanged, if > the purpose of > > the re-INVITE is solely for updating dialog-related information." > > > > John Elwell (john.elwell@siemens.com) > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 25 12:21:19 2004 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 MAA11143 for ; Mon, 25 Oct 2004 12:21:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM7oU-00025s-4J for sip-web-archive@ietf.org; Mon, 25 Oct 2004 12:35:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM7P5-0001zS-Mk; Mon, 25 Oct 2004 12:09:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM7Ln-0000u6-NM for sip@megatron.ietf.org; Mon, 25 Oct 2004 12:05:40 -0400 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 MAA09270 for ; Mon, 25 Oct 2004 12:05:35 -0400 (EDT) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM7ZF-0001eA-2I for sip@ietf.org; Mon, 25 Oct 2004 12:19:34 -0400 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id i9PG4wPm003287; Mon, 25 Oct 2004 16:04:58 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Mon, 25 Oct 2004 12:04:58 -0400 Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF42DA@stntexch04.cis.neustar.com> From: "Peterson, Jon" To: "'Michael Thomas'" , Dean Willis Subject: RE: [Sip] Discussion on draft-ietf-sip-identity-03.txt Date: Mon, 25 Oct 2004 12:04:44 -0400 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: 32b73d73e8047ed17386f9799119ce43 Cc: sip@ietf.org, rohan Mahy , Allison Mankin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Michael, > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > > problem, and Michael Thomas pointed us at the MASS work, which is > > astoundingly similar to sip-identity. > > >From my poor understanding, the principle > difference is what the trust anchor is. That has a > tendency to either make or break these things, > especially in the large... which is what led us to > our use of DNS as a somewhat more "conservative" > compromise of deployability over security. > Right. Just to articulate to the group what that distinction is, IIM (Michael's proposal in MASS) uses the records in the DNS to point to a key store where you can find (uncertified) public keys for a particular user. Certainly, I personally wouldn't recommend that you use CA-issued certificates for IIM, precisely because your mechanism manages keys on a per-user basis. Getting PKI to end users (in terms of enrollment and credential distribution) is very tricky. Hence, using uncertified or self-signed keys for your architecture makes more sense. We do that for end-users in SIP, too (in the jennings-certs draft). That much said, it is much harder to prove that you are a user than to prove that you are a domain. In your architecture, the DNS is used to bind credentials to the issuing domain rather than a certificate. If, say, you required people to access your key store via HTTPS, then there would be little difference between the trust anchors of our approach. I'm surprised that this doesn't even merit a MAY in your proposal; while one could argue that the DNS is sufficiently secure, it is certainly not unrealistic or operationally challenging to use HTTPS. > But! The question that I really have is whether > anybody is implementing and especially deploying > this, and if so, obviously how it's going. We're > getting a lot of interest on the MASS front due to > the dire situation with email which may in fact > move some of these immovable objects, so unless > people are actually making use of this, waiting to > see what happens may not be a terrible option. > I understand that there are some implementations underway, but I don't know about deployments. While my high-level message-identity draft shows the higher layer commonality between the identity needs of SIP and email, it also throws a lot of the differences into relief. After going through that exercise, I'm not sure I would make the same recommendations for SIP and email identity. But of course, it wasn't the point of the draft to show that MASS should use sip-identity or that SIP should use DomainKeys or IIM or what have you - it was to show a common design space in which the trade-offs are clear. > > Jon and Cullen proved that real CS-signed certificates are readily > > available at a cost not significantly different than that of a domain > > registration, or slightly less than the price of a decent bottle of > > Scotch, for some definition of the word "decent". > > There's more to it than money, of course; there's > institutional, um, considerations too. And PKI's > don't have a very encouraging track record beyond > web stuff; whether it's reasonable being a > different question than whether it is. > You and I are in perfect agreement that the traditional manner of leveraging PKI to support messaging has proved inadequate. Of course, I take exception to the idea that sip-identity relies on certificates in that manner - it is not predicated on enrolling individual users of the system and distributing certified credentials to these users. In fact, it uses certificates the same way that "web stuff" does - servers have 'em, users and other servers validate 'em. This is a tried and tested approach to enrollment into PKI, and tons of commercial services make these certificates available. I'm not sure what limiting institutional considerations you have mind. Jon Peterson NeuStar, Inc. > Mike > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 25 19:13:56 2004 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 TAA11807 for ; Mon, 25 Oct 2004 19:13:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMEFr-00026g-9C for sip-web-archive@ietf.org; Mon, 25 Oct 2004 19:27:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMBUo-00056v-38; Mon, 25 Oct 2004 16:31:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMB7m-0007pS-HP; Mon, 25 Oct 2004 16:07:26 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00130; Mon, 25 Oct 2004 16:07:24 -0400 (EDT) Message-Id: <200410252007.QAA00130@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, 25 Oct 2004 16:07:24 -0400 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-history-info-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: a8a20a483a84f747e56475e290ee868e --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : An Extension to the Session Initiation Protocol for Request History Information Author(s) : M. Barnes Filename : draft-ietf-sip-history-info-04.txt Pages : 47 Date : 2004-10-25 This draft defines a standard mechanism for capturing the history information associated with a SIP request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This draft defines a new optional SIP header, History-Info, for capturing the history information in requests. A new option tag, Histinfo, to be included in the Supported header, is defined to allow UAs to indicate whether the History-Info should be returned in responses to a request which has captured the history information. A new priv-value, history, is added to the Privacy header to allow for privacy handling of the History-Info header. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-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-history-info-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-history-info-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-25162234.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-history-info-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-history-info-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-25162234.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 Mon Oct 25 19:19:38 2004 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 TAA12682 for ; Mon, 25 Oct 2004 19:19:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMELN-0002PR-VF for sip-web-archive@ietf.org; Mon, 25 Oct 2004 19:33:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMBUs-0005Bq-Ql; Mon, 25 Oct 2004 16:31:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMB7v-0007vp-Hp; Mon, 25 Oct 2004 16:07:35 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00170; Mon, 25 Oct 2004 16:07:33 -0400 (EDT) Message-Id: <200410252007.QAA00170@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, 25 Oct 2004 16:07:32 -0400 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-connect-reuse-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: 1a1bf7677bfe77d8af1ebe0e91045c5b --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Connection Reuse in the Session Initiation Protocol (SIP) Author(s) : R. Mahy Filename : draft-ietf-sip-connect-reuse-03.txt Pages : 14 Date : 2004-10-25 When SIP entities use a connection oriented protocol to send a request, they typically originate their connections from an ephemeral port. The SIP protocol includes mechanisms which insure that responses to a request, and new requests sent in the original direction reuse an existing connection. However, new requests sent in the opposite direction are unlikely to reuse the existing connection. This frequently causes a pair of SIP entities to use one connection for requests sent in each direction, and can result in potential scaling and performance problems. This document proposes requirements and a mechanism which address this deficiency. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-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-connect-reuse-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-connect-reuse-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-25162239.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-connect-reuse-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-connect-reuse-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-25162239.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 Mon Oct 25 23:18:15 2004 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 XAA04690 for ; Mon, 25 Oct 2004 23:18:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMI4K-0008RY-7J for sip-web-archive@ietf.org; Mon, 25 Oct 2004 23:32:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMHnS-0003v0-Jp; Mon, 25 Oct 2004 23:14:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMHli-0003YU-Mf for sip@megatron.ietf.org; Mon, 25 Oct 2004 23:13:06 -0400 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 XAA04438 for ; Mon, 25 Oct 2004 23:13:02 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMHzE-0008MP-Nm for sip@ietf.org; Mon, 25 Oct 2004 23:27:07 -0400 Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i9Q3CeA4029535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Oct 2004 23:12:40 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by bart.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i9Q3CdMp001879; Mon, 25 Oct 2004 23:12:39 -0400 (EDT) Message-ID: <417DC0A6.4030801@cs.columbia.edu> Date: Mon, 25 Oct 2004 23:12:38 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Piers O'Hanlon" Subject: Re: [Sip] Queries/Comments on Resource Priority-04 References: <21736.1097577918@cs.ucl.ac.uk> In-Reply-To: <21736.1097577918@cs.ucl.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.9.21.8 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CHILD_PORN_NOT_1 0, __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: 31247fb3be228bb596db9127becad0bc 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: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Piers O'Hanlon wrote: > Hi, > > I've taken a look at the draft and have the following comments: Thanks for your comments. > > General comments: - The fact that it isn't mandatory to mark all > responses with RP headers means that one should at least make it a > SHOULD(MUST?) to provide "resource prioritization" based on a dialog > or session initiated with the RP header (possibly requiring Stateful > proxy?). Otherwise it seems that being able to know if a node > "supports Resource priority" (using OPTIONS or a Require hdr) may not > be of use if you can't be assured the whole dialog/session will be > assured of the "resource prioritization"? If it's not specified in > this document then I guess it will need to be specified in some > external policy document...(out of scope) There are two types of resource prioritization, as alluded to in the document (Introduction), namely to prioritize the signaling handling itself and, more importantly, the resources such signaling controls, e.g., trunk circuits. Resources such as trunk circuits are inherently stateful, as they are at UAs, and thus don't require the response to carry the R-P indication. The only time the response would need to carry the R-P header is for prioritizing the handling of the SIP request itself. Since a response is part of a transaction, transaction-stateful proxies (i.e., most of them) would already know that the transaction has high priority and can handle this without additional indication. Thus, only the rare case of a stateless proxy is relevant. However, since that proxy can't readily ascertain that the response is authorized (ignoring S/MIME for now), this isn't likely to be useful. I'll add a sentence that summarizes this. > > > Section 3.3 - minor comment: It might be useful to label table > something like 'Table 1'. Done. - In the second the paragraph the 420 > response is incorrectly defined as "(Not Supported)" - when it should > be "(Bad Extension)". Fixed. - In the same paragraph the explanation > following the handling of the 420 response seems at odds with the > description in section 4.2.2 and that of RFC3261. Firstly this is > because it indicates that a 420 is generated when it encounters a > unknown RP value (on an RP capable node) - shouldn't that be covered > in section 4.2.2 That part of the paragraph below the table is an orphaned remnant of some earlier behavioral description. The error behavior is now described in Section 4.2. I ditched the confusing set of sentences. - Shouldn't a 420 be generated only by non RP > capable node in response to Require? Secondly it seems to reccomend > adding an 'Accept-Resource-Priority' header when RFC3261 specifies > adding an "Unsupported" header for a 420 response? Or maybe it was > intended to talk about the 417 handling here? See above. > > Example 7.2 - In this example - according to section 4.2.2 a 417 > response should only generated when in strict mode, in which case the > shouldn't the INVITE contain the Require header? Indeed. > > > Piers O'Hanlon --------------_____________ Computer Science > Department University College London _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 26 02:08:57 2004 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 CAA25366 for ; Tue, 26 Oct 2004 02:08:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMKjV-0003B2-TF for sip-web-archive@ietf.org; Tue, 26 Oct 2004 02:23:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMKTq-0007Ct-VX; Tue, 26 Oct 2004 02:06:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMKSk-0006Z6-Kq for sip@megatron.ietf.org; Tue, 26 Oct 2004 02:05:42 -0400 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 CAA22276 for ; Tue, 26 Oct 2004 02:05:41 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMKgL-00037n-Dn for sip@ietf.org; Tue, 26 Oct 2004 02:19:45 -0400 Received: from [192.168.0.102] (adsl-209-30-28-252.dsl.rcsntx.swbell.net [209.30.28.252]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i9Q65VDw060359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Oct 2004 01:05:32 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <417DE95C.8040805@nostrum.com> Date: Tue, 26 Oct 2004 01:06:20 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) 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: 4.6 (++++) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: Jonathan Rosenberg Subject: [Sip] Event Lists: Back-End Credentials X-BeenThere: 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: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit After a discussion with Dean about some of the issues surrounding the back-end credential issue that I raised earlier on the list, I struck upon a solution that might get us past this logjam. The lynch pin to this solution is that the RLS does not ever pretend to be the user. Instead, it always subscribes as its own identity. It can present credentials as necessary to authenticate itself, but only as itself, not as its subscribers. A consequence of this is that, lacking any other mechanism, the resources in a resource list for which the RLS is not authoritative will contain only the information that their notifier is willing to reveal to the RLS -- which is generally the same information they would render to unauthenticated users. In some cases, this might result in no useful information being transferred. Of course, the resource would still be present in the RLMI document; this gives the subscriber the *option* to directly subscribe to any resources for which the RLS is not authoritative. To facilitate the client's ability to perform such subscriptions, the RLMI documents would be enhanced with a flag which indicates whether the RLS is authoritative for the resource. Finally, we would mention in the document that future work may define a mechanism by which the subscriber can pass the RLS an authorization token; the RLS could include this token in requests to show that it has been authorized by the user to send SUBSCRIBE messages for arbitrary resources on the user's behalf (mostly likely for a limited time period). Of the solutions we've seen so far, I think this one is the cleanest from a security perspective. Further, it will almost certainly allow us to progress the draft now, and separate the delegation problem so that it can be solved in a way that works well with the other identity and authentication work currently underway (and might even be reusable in other applications, such as dial-out conference bridges). Thoughts? /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Oct 26 06:12:58 2004 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 GAA18765 for ; Tue, 26 Oct 2004 06:12:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMOXj-0007ht-59 for sip-web-archive@ietf.org; Tue, 26 Oct 2004 06:27:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMOE0-0007YO-01; Tue, 26 Oct 2004 06:06:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMOB5-00074M-8j; Tue, 26 Oct 2004 06:03:43 -0400 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 GAA18331; Tue, 26 Oct 2004 06:03:40 -0400 (EDT) Received: from email10.etsi.org ([212.234.161.112] helo=email10.etsihq.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMOOi-0007ZD-Hh; Tue, 26 Oct 2004 06:17:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Oct 2004 12:03:03 +0200 Message-ID: <4091553999CBE4409CC2B562152B5A330406FAAD@email10.etsihq.org> Thread-Topic: ETSI Plugtests ENUM Call for Expert and extension of Task Force Thread-Index: AcS7N2IBNd9mcsB5S+S+uQBko/V5Mg== From: =?Windows-1252?Q?Patrick_Ren=E9_Guillemin?= To: "Plugtests" X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, sip@ietf.org, TISPAN_WG4 , PLUGETSTS-ENUM@LIST.ETSI.ORG Subject: [Sip] ETSI Plugtests ENUM Call for Expert and extension of Task Force X-BeenThere: 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: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Dear All, CALL FOR ONE ENUM INDEPENDENT EXPERT AND VOLUNTEERS TO CONTRIBUTE TO THE = TASK FORCE TO SUPPORT THE 1ST ENUM INTEROPERABILITY EVENT (Spring 2005) The ETSI Plugtests Interoperability service, hosted the first ENUM = Workshop event in February 2004 to serve the whole global market in = cooperation with the ETSI TC TISPAN committee. The ETSI Plugtests = service is independent and has, over the last 4 years, gained a unique = experience in organising 50 events for a broad range of domains. Further = information on the service is available at www.etsi.org/plugtests. =20 While being part of the ETSI structure, this service is self-financed = and fully independent. Half of the organized events are related to non = ETSI Standards (e.g. IPv6, SIP, Bluetooth, etc). The ETSI Plugtests service is now preparing a 1st ENUM interoperability = event to be held spring 2005 with the objective of having a broad = technical scope to address ENUM technologies. Preliminary ENUM tests could be conducted during the 1st NGN Plugtests = from 29-Nov to 3-Dec: http://www.etsi.org/plugtests/NGN_VoIP.htm = =20 To serve all the global ENUM solutions and all involved companies in an = open, independent and transparent process, ETSI is looking for further = assistance and support in two directions: 1) CALL FOR AN INDEPENDENT EXPERT ETSI Plugtests Service is looking for appointing an independent expert = mainly to assist in the definition of the ENUM interoperability event, = its architecture, its test bed and on the test cases to be performed. = This expert will be under contractual arrangement with ETSI and under = the financial rules of the EU eEurope programme. He will coordinate the = work under the supervision of both the ETSI TC TISPAN committee and an = independent task force to be set-up for providing main input to the = programme. The expert effort can be estimated in a range of 40 to 80 = days. Should you like to be candidate for such expertise, please send your = application and references to philippe.cousin@etsi.org (CC = patrick.guillemin@etsi.org and plugtests@etsi.org) before 15 November = 2004. 2) CALL FOR ADDITIONNAL VOLUNTEERS TO CONTRIBUTE TO A FIRST ENUM = INTEROPERABILITY EVENT TASK FORCE ETSI Interoperability Service is looking for volunteers to extend the = task force (EPTF, ENUM Plugtests Task Force) for providing inputs and = guidance to the 1st Interoperability event in a more open, transparent = and independent manner as possible . The main objective of this task = force assisted by dedicated resources of an independent expert is to = provide guidance of the architecture, the test beds, and the test cases. = This 1st interoperability event should address all the interoperability = concerns for the ENUM solutions. Should you like to be candidate to participate to this Task force, = please send your application and references to = Patrick.guillemin@etsi.org CC plugtests@etsi.org before 15 November = 2004. Any expert is welcome, even non-ETSI members as long as the = expert is committed to actively and constructively contribute to the = work. It is expected that most of the work could be done by email and = audio-conference but meeting(s) can also be convened when necessary. I am looking forward to getting a lot of applications and support Best regards Patrick GUILLEMIN, Coordinator of EPTF ETSI - Plugtests Technical Coordinator http://www.etsi.org/plugtests tel +33 (0)4 92 94 43 31 and Philippe COUSIN Interoperability Service Manager + 33 (0)4 92 94 43 06 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 26 19:57:01 2004 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 TAA04054 for ; Tue, 26 Oct 2004 19:57:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMbPH-0004Lr-UI for sip-web-archive@ietf.org; Tue, 26 Oct 2004 20:11:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMZ2I-0006PO-NL; Tue, 26 Oct 2004 17:39:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMYUN-0001O1-Ml; Tue, 26 Oct 2004 17:04:19 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21457; Tue, 26 Oct 2004 17:04:17 -0400 (EDT) Message-Id: <200410262104.RAA21457@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, 26 Oct 2004 17:04:17 -0400 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-resource-priority-05.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 : Communications Resource Priority for the Session Initiation Protocol (SIP) Author(s) : H. Schulzrinne, J. Polk Filename : draft-ietf-sip-resource-priority-05.txt Pages : 33 Date : 2004-10-26 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-05.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-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-resource-priority-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-26161213.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-resource-priority-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-resource-priority-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-26161213.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 Oct 26 20:22:21 2004 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 UAA11178 for ; Tue, 26 Oct 2004 20:22:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMbnl-0006fw-Cs for sip-web-archive@ietf.org; Tue, 26 Oct 2004 20:36:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMaDe-0007PH-1b; Tue, 26 Oct 2004 18:55:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMYqp-00011D-1w for sip@megatron.ietf.org; Tue, 26 Oct 2004 17:27:31 -0400 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 RAA26945 for ; Tue, 26 Oct 2004 17:27:28 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMZ4X-0000hl-7V for sip@ietf.org; Tue, 26 Oct 2004 17:41:43 -0400 Received: from phys-fll03-2 ([129.154.149.12]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9QLRRNJ010033 for ; Tue, 26 Oct 2004 15:27:27 -0600 (MDT) Received: from conversion-daemon.fll03-mail1.east.sun.com by fll03-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0I6700N01MCV05@fll03-mail1.east.sun.com> (original mail from Mauricio.Arango@Sun.COM) for sip@ietf.org; Tue, 26 Oct 2004 17:27:26 -0400 (EDT) Received: from sun.com (vpn-129-150-65-230.East.Sun.COM [129.150.65.230]) by fll03-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0I6700EODNLPQW@fll03-mail1.east.sun.com>; Tue, 26 Oct 2004 17:27:26 -0400 (EDT) Date: Tue, 26 Oct 2004 17:31:27 -0400 From: Mauricio Arango Subject: Re: [Sip] verifying identity of sender To: "Peterson, Jon" Message-id: <417EC22F.C42EC973@sun.com> MIME-version: 1.0 X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en,pdf References: <7927C67249E4AD43BC05B539AF0D129801AF42D2@stntexch04.cis.neustar.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7BIT Cc: Cullen Jennings , sip@ietf.org, Juha Heinanen , 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: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7BIT Use of SAML in SIP doesn't require federation, nor does it require Web Services, and pre-associations are minimal. Additional explanations as follows: - A Web Services stack isn't required when SIP is used to transport SAML assertions (or references to it). SAML comprises assertions and protocols. Use of SAML for the scenarios we are discusing would not involve use of SAML protocols. - Use of SAML to verify the 'From' identity in SIP doesn't require federation. Federation is the linking of one identity in one administrative domain with another identity in another administrative domain. Verification of the 'From' identity doesn't demand its linking with another identity at the destination of the SIP request. Federation isn't a mandatory step for any use of SAML assertions. - Pre-associations for the scenarios under consideration are minimal. A SAML assertion would refer to its governing schema in the usual XML/namespaces fashion, which would either require pre-configuration of the schema or on-the-fly loading. Another aspect that requires pre-association is agreement of the method to handle a signed assertion received from the authentication proxy. This part would have to be handled independently of whether SAML is used or not. - With respect to support for XML. XML parsers could be an issue in limited-capability user devices, though there is a increasing number of XML parsers for small devices. Nevertheless, XML processing for SIP identity would only be required by the authentication proxy at the requesting side and by the receiving side domain proxy, which are usually servers. Also, there is precendent of using XML in SIP as in event list notifications. Regards, Mauricio Arango "Peterson, Jon" wrote: > > -----Original Message----- > > From: Mauricio Arango [mailto:Mauricio.Arango@Sun.COM] > > > > For clarification, is the comment of "SAML heavy" because of the > > pre-associations only? > > Pre-association and federation, agreement on various SAML attribute and so > on is one aspect of it. I also think the support for XML, web services, and > so on cannot be universally assumed in a SIP environment - a widespread > mandate for SAML support would entail a lot of additional development, > beyond SIP's current implementation challenge. > > Our emphasis in identity design has been on providing a very light solution, > something that doesn't require us to diverge significantly from the > operational models and implementation already described in the core > standard. We also want to provide something for identity that is universal, > and useful in essentially all contexts that SIP is used. I don't think we > can position SAML to play that part in SIP's architecture, though it can > certainly provide valuable supplemental security assertions for some > deployments. > > Jon Peterson > NeuStar, Inc. > > > > > Sounds like a good initial approach. > > > > Mauricio Arango > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 26 20:35:17 2004 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 UAA14269 for ; Tue, 26 Oct 2004 20:35:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMc0J-0007ak-Pd for sip-web-archive@ietf.org; Tue, 26 Oct 2004 20:49:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMbYV-0004rK-VC; Tue, 26 Oct 2004 20:20:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMa5l-0003Hg-JN for sip@megatron.ietf.org; Tue, 26 Oct 2004 18:47:01 -0400 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 SAA16740 for ; Tue, 26 Oct 2004 18:46:58 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMaJT-0006zZ-GJ for sip@ietf.org; Tue, 26 Oct 2004 19:01:14 -0400 Received: from [10.21.112.138] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.12.11/8.12.11) with ESMTP id i9QMl8kA020590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 26 Oct 2004 17:47:09 -0500 Message-ID: <417ED3BF.4030703@softarmor.com> Date: Tue, 26 Oct 2004 17:46:23 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) 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: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Subject: [Sip] Agenda information and topics poll X-BeenThere: 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 As usual, we've requested two sessions at IEF 61 for SIP, and will be trying to focus on the high-urgency active topics and limiting discussion on the lower-urgency (by rough consensus and impinging liaison statement) topics. As usual, I expect to be downright mean about saying "no" and getting enough time to actually make SOME progress on key topics. I'll be drafting out an agenda and posting it on the softarmor web site over the next couple of days. I've already receieved some suggestions from folks, using Gonzalo's nifty template format: Gonzalo Camarillo Exploders
5
draft-camarillo-sipping-exploders-02.txt If you have additional topics that you feel need discussion, please send in suggestions, using Gonzalo's format if you can figure it out, or just: Who: Topic: Time needed: Draft: if you can't. I'll try and get those posted onto softarmor in an Agenda Request section as usual, and will confirm receipt of requests as I get them. URL: http://www.softarmor.com/sipwg Thanks, y'all. -- 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 Oct 26 23:34:38 2004 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 XAA27701 for ; Tue, 26 Oct 2004 23:34:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMenw-00033P-64 for sip-web-archive@ietf.org; Tue, 26 Oct 2004 23:48:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMeYQ-0005aV-68; Tue, 26 Oct 2004 23:32:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMeY8-0005M0-7U for sip@megatron.ietf.org; Tue, 26 Oct 2004 23:32:36 -0400 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 XAA27470 for ; Tue, 26 Oct 2004 23:32:33 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMelu-0002zc-Oq for sip@ietf.org; Tue, 26 Oct 2004 23:46:51 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9R3VxG24493 for ; Tue, 26 Oct 2004 23:31:59 -0400 (EDT) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Oct 2004 23:31:58 -0400 Message-ID: From: "Mary Barnes" To: "'sip@ietf.org'" Subject: FW: [Sip] I-D ACTION:draft-ietf-sip-history-info-04.txt Date: Tue, 26 Oct 2004 23:31:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C4BBD5.7BCE4CC0" X-Spam-Score: 0.5 (/) X-Scan-Signature: 2c12be3f3a8d57895fb9c003e1517c01 X-BeenThere: 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.5 (/) X-Scan-Signature: c119f9923e40f08a1d7f390ce651ea92 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_01C4BBD5.7BCE4CC0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4BBD5.7BCE4CC0" ------_=_NextPart_001_01C4BBD5.7BCE4CC0 Content-Type: text/plain Hi all, Since this version should be ready for WGLC, a very detailed list of the changes is provided in the document, annotated as to the source, so I won't repeat those details here. The majority of the changes were the issues discussed at IETF-60, along with the agreements there to change the text to non-normative in section 4 (Protocol structure) and to add some detail per Rohan's comment on the necessary processing should TLS not be available. In addition, I received some proposed changes on a marked up hardcopy at IETF-61 from Eric Burger. The only items not discussed at IETF-60 were 2 items that came up on the list (one posted by John Elwell on August 18th on handling of privacy in responses) the other on Oct. 15th around the appropriate character format for the escaped headers in the URI. And, as always, there are various minor editorial changes here and there while I was "in the area". So, there should be no surprises with any of the changes, although, it is possible that there are still errors and nits that can be identified during WGLC. Thanks, Mary -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, October 25, 2004 3:07 PM To: i-d-announce@ietf.org Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-history-info-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : An Extension to the Session Initiation Protocol for Request History Information Author(s) : M. Barnes Filename : draft-ietf-sip-history-info-04.txt Pages : 47 Date : 2004-10-25 This draft defines a standard mechanism for capturing the history information associated with a SIP request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This draft defines a new optional SIP header, History-Info, for capturing the history information in requests. A new option tag, Histinfo, to be included in the Supported header, is defined to allow UAs to indicate whether the History-Info should be returned in responses to a request which has captured the history information. A new priv-value, history, is added to the Privacy header to allow for privacy handling of the History-Info header. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-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-history-info-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-history-info-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_001_01C4BBD5.7BCE4CC0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable FW: [Sip] I-D ACTION:draft-ietf-sip-history-info-04.txt

Hi all,

Since this version should be ready for WGLC, a very = detailed list of the changes is provided in the document, annotated as = to the source, so I won't repeat those details here.   The = majority of the changes were the issues discussed at IETF-60, along = with the agreements there to change the text to non-normative in = section 4 (Protocol structure) and to add some detail per Rohan's = comment on the necessary processing should TLS not be available.  = In addition, I received some proposed changes on a marked up hardcopy = at IETF-61 from Eric Burger. 

The only items not discussed at IETF-60 were 2 items = that came up on the list (one posted by John Elwell on August 18th on = handling of privacy in responses) the other on Oct. 15th around the = appropriate character format for the escaped headers in the URI. And, = as always, there are various minor editorial changes here and there = while I was "in the area".  So, there should be no = surprises with any of the changes, although, it is possible that there = are still errors and nits that can be identified during = WGLC.  

Thanks,
Mary


-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] = On Behalf Of Internet-Drafts@ietf.org
Sent: Monday, October 25, 2004 3:07 PM
To: i-d-announce@ietf.org
Cc: sip@ietf.org
Subject: [Sip] I-D = ACTION:draft-ietf-sip-history-info-04.txt


A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of the Session Initiation = Protocol Working Group of the IETF.

        Title           : = An Extension to the Session Initiation Protocol for Request History = Information
        Author(s)       : M. = Barnes
        Filename        : = draft-ietf-sip-history-info-04.txt
        Pages           : = 47
        Date    =         : 2004-10-25
       =20
This draft defines a standard mechanism for = capturing the history
   information associated with a SIP = request.  This capability enables
   many enhanced services by providing the = information as to how and why
   a call arrives at a specific = application or user.  This draft defines
   a new optional SIP header, = History-Info, for capturing the history
   information in requests. A new option = tag, Histinfo, to be included
   in the Supported header, is defined to = allow UAs to indicate whether
   the History-Info should be returned in = responses to a request which
   has captured the history information. A = new priv-value, history, is
   added to the Privacy header to allow = for privacy handling of the
   History-Info header.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-his= tory-info-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-history-info-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-history-info-04.txt".
       =20
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.
        =        =20
        =        =20
Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of the
Internet-Draft.

  ------_=_NextPart_001_01C4BBD5.7BCE4CC0-- ------_=_NextPart_000_01C4BBD5.7BCE4CC0 Content-Type: application/octet-stream; name="ATT904312.TXT" Content-Disposition: attachment; filename="ATT904312.TXT" Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-25162234.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-history-info-04.txt ------_=_NextPart_000_01C4BBD5.7BCE4CC0 Content-Type: message/external-body; site="internet-drafts"; dir="draft-ietf-sip-history-info-04.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_000_01C4BBD5.7BCE4CC0 Content-Type: text/plain; name="ATT904313.txt" Content-Disposition: attachment; filename="ATT904313.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 ------_=_NextPart_000_01C4BBD5.7BCE4CC0 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_01C4BBD5.7BCE4CC0-- From sip-bounces@ietf.org Wed Oct 27 08:51:37 2004 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 IAA00736 for ; Wed, 27 Oct 2004 08:51:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMnV1-0004Zr-8Z for sip-web-archive@ietf.org; Wed, 27 Oct 2004 09:05:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMnFI-0001Gy-Jr; Wed, 27 Oct 2004 08:49:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMnET-00017y-VP for sip@megatron.ietf.org; Wed, 27 Oct 2004 08:48:54 -0400 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 IAA00473 for ; Wed, 27 Oct 2004 08:48:52 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMnSL-0004VZ-Fk for sip@ietf.org; Wed, 27 Oct 2004 09:03:14 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 27 Oct 2004 05:50:03 -0700 X-BrightmailFiltered: true Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i9RCmJ9b013547; Wed, 27 Oct 2004 05:48:20 -0700 (PDT) Received: from [10.32.245.154] (stealth-10-32-245-154.cisco.com [10.32.245.154]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id i9RCnoD1030670; Wed, 27 Oct 2004 05:49:53 -0700 In-Reply-To: <417DE95C.8040805@nostrum.com> References: <417DE95C.8040805@nostrum.com> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <7342A8D3-2816-11D9-BDDE-000A95C73842@cisco.com> From: David R Oran Subject: Re: [Sip] Event Lists: Back-End Credentials Date: Wed, 27 Oct 2004 08:48:07 -0400 To: Adam Roach X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1098881396.177059"; x:"432200"; a:"rsa-sha1"; b:"nofws:4951"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"dSo4phGQoQ4nKLclMXE3kVf4wOQYBlVSbb/fif8TatiV2PYLb/AMrn1pTxD59" "hLeyJqgt0sIi5Xy/r9dOfg9oUVhndZv5U2s+8+LgVMDO/KyyXWiemTcseG5PZ" "S65axYgdHpYTuQU2ypL6D243DhsL9BQ+Qce5zmnUFaz9ivbVI="; c:"From: David R Oran "; c:"Subject: Re: [Sip] Event Lists: Back-End Credentials"; c:"Date: Wed, 27 Oct 2004 08:48:07 -0400" 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: 67c1ea29f88502ef6a32ccec927970f0 Cc: sip@ietf.org, Jonathan Rosenberg X-BeenThere: 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="===============0942101743==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 --===============0942101743== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-315003006" --Apple-Mail-1-315003006 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Oct 26, 2004, at 2:06 AM, Adam Roach wrote: > After a discussion with Dean about some of the issues surrounding the > back-end credential issue that I raised earlier on the list, I struck > upon a solution that might get us past this logjam. > > The lynch pin to this solution is that the RLS does not ever pretend > to be the user. Instead, it always subscribes as its own identity. It > can present credentials as necessary to authenticate itself, but only > as itself, not as its subscribers. > This factors the security issues, but introduces an inconvenience in that any authorization policies have to know about the RLS in addition to the user on behalf of whom the RLS is doing the list management. Whether this constitutes a major or minor inconvenience is worth pondering. > A consequence of this is that, lacking any other mechanism, the > resources in a resource list for which the RLS is not authoritative > will contain only the information that their notifier is willing to > reveal to the RLS -- which is generally the same information they > would render to unauthenticated users. In some cases, this might > result in no useful information being transferred. > This strikes me as closer to "major" than "minor" if an important use case is buddy lists - which I suppose it is. If the RLS is in fact some kind of "shared resource" and doesn't have an identity controllable by the user it is acting on behalf of there would be little motivation for anyone to trust it and hence policy devolves to the anonymous subscription case in most instances. That would seem to do substantial damage to the utility for buddy lists. > Of course, the resource would still be present in the RLMI document; > this gives the subscriber the *option* to directly subscribe to any > resources for which the RLS is not authoritative. To facilitate the > client's ability to perform such subscriptions, the RLMI documents > would be enhanced with a flag which indicates whether the RLS is > authoritative for the resource. > Sure, but that's just saying that the RLS optimizations are of less value, and the subscriber's job of sorting through the policy versus overhead tradeoffs is made harder. > Finally, we would mention in the document that future work may define > a mechanism by which the subscriber can pass the RLS an authorization > token; the RLS could include this token in requests to show that it > has been authorized by the user to send SUBSCRIBE messages for > arbitrary resources on the user's behalf (mostly likely for a limited > time period). > That's a form of delegation which seems like it would work well for this purpose. > Of the solutions we've seen so far, I think this one is the cleanest > from a security perspective. Further, it will almost certainly allow > us to progress the draft now, and separate the delegation problem so > that it can be solved in a way that works well with the other identity > and authentication work currently underway (and might even be reusable > in other applications, such as dial-out conference bridges). > True, but are the tradeoffs with other aspects of utility and complexity right? I'm not sure but on the small amount of thought I've given this it strikes me as questionable. > Thoughts? > One option is to delay RLS until we have delegation (at least in the limited context of RLS) solved, since as you point out above subscribers may have to fall back to separate subscriptions to all the resources anyway. I'll observe that once a spec gets through to RFC, the enthusiasm to enhance it to do its full job wanes, and the complexities of multiple variants in the the wild reduces the practical utility of the "correct" solution. I don't feel strongly about this one way or the other. Dave. > /a > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com --Apple-Mail-1-315003006 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFBf5kHjWaEtlTdKuYRAt7CAJ4yT/bA74RCvNH+C/RYopKU1H4OPgCfYB17 s1Yg6WoJAwM/UmyPIubaiDM= =4yJt -----END PGP SIGNATURE----- --Apple-Mail-1-315003006-- --===============0942101743== 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 --===============0942101743==-- From sip-bounces@ietf.org Wed Oct 27 09:22:55 2004 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 JAA02743 for ; Wed, 27 Oct 2004 09:22:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMnzJ-00057z-Sq for sip-web-archive@ietf.org; Wed, 27 Oct 2004 09:37:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMnhT-0007Oa-Sa; Wed, 27 Oct 2004 09:18:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMne5-00066h-6K for sip@megatron.ietf.org; Wed, 27 Oct 2004 09:15:21 -0400 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 JAA02355 for ; Wed, 27 Oct 2004 09:15:19 -0400 (EDT) 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 1CMnrw-0004zp-4S for sip@ietf.org; Wed, 27 Oct 2004 09:29:41 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 27 Oct 2004 06:23:52 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9RDEcYL004855; Wed, 27 Oct 2004 06:14:40 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMP06853; Wed, 27 Oct 2004 09:14:44 -0400 (EDT) Message-ID: <417F9F43.1040704@cisco.com> Date: Wed, 27 Oct 2004 09:14:43 -0400 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: Adam Roach Subject: Re: [Sip] Event Lists: Back-End Credentials References: <41780D08.3090007@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Adam Roach wrote: > * Add new SIP header field (or maybe method) for credential upload > > One very simple solution would be to add a new header which contains > a triple of [realm,userid,password]. We would specify that this > header is disallowed except over SIPS connections. The client would > include one or more such headers in its SUBSCRIBE request, and the > RLS would use them to obtain information on the user's behalf. Dave then espressed reservations over this because it grants too much capability to the RLS. I agree with Dave's concern over this, and think his suggestion to tackle the problem of delegation head on is the right solution in the long term. OTOH, it doesn't seem like we can wait that long to get something going for RLS. To pursue Adam's suggestion without giving away the ranch, maybe presence servers could have one set of credentials that grant only limited access (subscription by buddies), and another for full permissions. This is really just an implementation technique and so we couldn't standardize it, but it might be a way to allow this crippled mechanism to be useful. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Oct 27 19:58:20 2004 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 TAA29275 for ; Wed, 27 Oct 2004 19:58:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMxuK-0002kd-AT for sip-web-archive@ietf.org; Wed, 27 Oct 2004 20:12:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMxdo-0001L4-SW; Wed, 27 Oct 2004 19:55:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMxdR-00018w-JT for sip@megatron.ietf.org; Wed, 27 Oct 2004 19:55:21 -0400 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 TAA29183 for ; Wed, 27 Oct 2004 19:55:19 -0400 (EDT) Received: from [204.17.219.16] (helo=exmail.lboard.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMxrF-0002hL-Ag for sip@ietf.org; Wed, 27 Oct 2004 20:09:47 -0400 Received: by exmail.lboard.com with Internet Mail Service (5.5.2653.19) id <401VGWPP>; Wed, 27 Oct 2004 16:53:02 -0700 Message-ID: From: Ragunath Devarasu To: "'sip@ietf.org'" Date: Wed, 27 Oct 2004 16:53:02 -0700 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: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Sip] Simultaneous SIP Transactions from one UA in the same dialog X-BeenThere: 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 Greetings: I am trying to find what SIP spec. has to say for the following cases: Say, UserA called UserB via P1, a Record Routing Proxy; UserA and UserB are connected. 1) UserA sends ReINVITE, and BYE to UserB before receiving response to ReINVITE. I understand the UAS behavior is specified in the spec. What about the Proxy behavior? 2) UserA sends REINVITE and OPTIONS at the same time to UserB. Is it allowed? Thanks Ragunath --- Snippet from sip spec --- 15.1 Terminating a Session with a BYE Request 15.1.2 UAS Behavior The UAS MUST still respond to any pending requests received for that dialog. It is RECOMMENDED that a 487 (Request Terminated) response be generated to those pending requests. --- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 28 09:58:35 2004 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 JAA13786 for ; Thu, 28 Oct 2004 09:58:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNB1Z-0001jy-SO for sip-web-archive@ietf.org; Thu, 28 Oct 2004 10:13:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNAhk-0000HX-5j; Thu, 28 Oct 2004 09:52:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNAZJ-0006zb-8U for sip@megatron.ietf.org; Thu, 28 Oct 2004 09:43:57 -0400 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 JAA12740 for ; Thu, 28 Oct 2004 09:43:56 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNAnO-0001MB-Ev for sip@ietf.org; Thu, 28 Oct 2004 09:58:31 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9SDhi321680; Thu, 28 Oct 2004 16:43:44 +0300 (EET DST) X-Scanned: Thu, 28 Oct 2004 16:43:30 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i9SDhUv7014444; Thu, 28 Oct 2004 16:43:30 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 008y0q6G; Thu, 28 Oct 2004 16:43:29 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9SDhMa21617; Thu, 28 Oct 2004 16:43:22 +0300 (EET DST) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 28 Oct 2004 16:43:22 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 28 Oct 2004 16:43:22 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Event Lists: Back-End Credentials Date: Thu, 28 Oct 2004 16:43:22 +0300 Message-ID: <5816828233DEFA41807A6CFDFDF2343C3A8BD7@esebe056.ntc.nokia.com> Thread-Topic: [Sip] Event Lists: Back-End Credentials Thread-Index: AcS7I29JvLC9ZPmKRH2sPvyYNLVNSQBz8ndg To: , X-OriginalArrivalTime: 28 Oct 2004 13:43:22.0212 (UTC) FILETIME=[174C1240:01C4BCF4] X-Spam-Score: 0.3 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Cc: jdrosen@dynamicsoft.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On=20 > Behalf Of ext > Adam Roach > Sent: 26.October.2004 09:06 > To: sip@ietf.org > Cc: Jonathan Rosenberg > Subject: [Sip] Event Lists: Back-End Credentials >=20 >=20 > After a discussion with Dean about some of the issues surrounding the=20 > back-end credential issue that I raised earlier on the list, I struck=20 > upon a solution that might get us past this logjam. >=20 > The lynch pin to this solution is that the RLS does not ever=20 > pretend to=20 > be the user. Instead, it always subscribes as its own=20 > identity. It can=20 > present credentials as necessary to authenticate itself, but only as=20 > itself, not as its subscribers. >=20 > A consequence of this is that, lacking any other mechanism, the=20 > resources in a resource list for which the RLS is not=20 > authoritative will=20 > contain only the information that their notifier is willing=20 > to reveal to=20 > the RLS -- which is generally the same information they would=20 > render to=20 > unauthenticated users. In some cases, this might result in no useful=20 > information being transferred. This limitation by itself kills the idea, IMO. Most presence lists will = rely on the event list, and if its gonna mean that no useful information = will come to the watcher, then the whole mecahnism is useless. Why isn't it enough to say that the way an watcher passes the key to the = RLS is outside the scope of this document? We have certainly made such = assumptions in the past. We can suggest HTML. We can suggest an email being sent to the = administrator. We can even suggest an XCAP usage document, but I don't = understand why the draft needs to define that explicitly. /Hisham >=20 > Of course, the resource would still be present in the RLMI document;=20 > this gives the subscriber the *option* to directly subscribe to any=20 > resources for which the RLS is not authoritative. To facilitate the=20 > client's ability to perform such subscriptions, the RLMI=20 > documents would=20 > be enhanced with a flag which indicates whether the RLS is=20 > authoritative=20 > for the resource. >=20 > Finally, we would mention in the document that future work=20 > may define a=20 > mechanism by which the subscriber can pass the RLS an authorization=20 > token; the RLS could include this token in requests to show=20 > that it has=20 > been authorized by the user to send SUBSCRIBE messages for arbitrary=20 > resources on the user's behalf (mostly likely for a limited=20 > time period). >=20 > Of the solutions we've seen so far, I think this one is the cleanest=20 > from a security perspective. Further, it will almost=20 > certainly allow us=20 > to progress the draft now, and separate the delegation=20 > problem so that=20 > it can be solved in a way that works well with the other identity and=20 > authentication work currently underway (and might even be reusable in=20 > other applications, such as dial-out conference bridges). >=20 > Thoughts? >=20 > /a >=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 Oct 28 10:25:01 2004 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 KAA16716 for ; Thu, 28 Oct 2004 10:25:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNBR9-0002Ld-Tl for sip-web-archive@ietf.org; Thu, 28 Oct 2004 10:39:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNB61-00012N-BW; Thu, 28 Oct 2004 10:17:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNB4J-0000Wa-Sy for sip@megatron.ietf.org; Thu, 28 Oct 2004 10:15:59 -0400 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 KAA15985 for ; Thu, 28 Oct 2004 10:15:58 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNBIK-0002CC-Cr for sip@ietf.org; Thu, 28 Oct 2004 10:30:33 -0400 Received: from [192.168.0.111] (adsl-209-30-28-252.dsl.rcsntx.swbell.net [209.30.28.252]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i9SEFgHU021421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Oct 2004 09:15:44 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4180FF0D.70409@nostrum.com> Date: Thu, 28 Oct 2004 09:15:41 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Sip] Event Lists: Back-End Credentials References: <5816828233DEFA41807A6CFDFDF2343C3A8BD7@esebe056.ntc.nokia.com> In-Reply-To: <5816828233DEFA41807A6CFDFDF2343C3A8BD7@esebe056.ntc.nokia.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.4 (+++) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 4.6 (++++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > Why isn't it enough to say that the way an watcher passes the key to > the RLS is outside the scope of this document? Because that's exactly what the document says right now, and the IESG won't let it pass as a result. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 28 10:31:03 2004 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 KAA17479 for ; Thu, 28 Oct 2004 10:31:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNBWz-0002VR-VT for sip-web-archive@ietf.org; Thu, 28 Oct 2004 10:45:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNBHh-0004ty-Oc; Thu, 28 Oct 2004 10:29:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNBGH-0004LB-HT for sip@megatron.ietf.org; Thu, 28 Oct 2004 10:28:21 -0400 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 KAA17216 for ; Thu, 28 Oct 2004 10:28:20 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNBUN-0002Sg-Fm for sip@ietf.org; Thu, 28 Oct 2004 10:42:55 -0400 Received: from [192.168.0.111] (adsl-209-30-28-252.dsl.rcsntx.swbell.net [209.30.28.252]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i9SESGbZ022268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Oct 2004 09:28:18 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <418101FF.9030506@nostrum.com> Date: Thu, 28 Oct 2004 09:28:15 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Sip] Event Lists: Back-End Credentials References: <5816828233DEFA41807A6CFDFDF2343C3A8BD7@esebe056.ntc.nokia.com> In-Reply-To: <5816828233DEFA41807A6CFDFDF2343C3A8BD7@esebe056.ntc.nokia.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.6 (++++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, jdrosen@dynamicsoft.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 4.6 (++++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>A consequence of this is that, lacking any other mechanism, the resources in a resource list for which the RLS is not authoritative will contain only the information that their notifier is willing to reveal to the RLS -- which is generally the same information they would render to unauthenticated users. In some cases, this might result in no useful information being transferred. >> >> > >This limitation by itself kills the idea, IMO. Most presence lists will rely on the event list, and if its gonna mean that no useful information will come to the watcher, then the whole mecahnism is useless. > > That's a bit of a strong characterization, and it seems to ignore the remainder of the mail that I sent out; specifically: 1. Users have the ability to subscribe to any resources that the RLS marks itself as non-authoritative, and 2. (More Importantly) Provisions for delegation of authority are included -- they're just not in-scope for this document. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Oct 28 10:45:14 2004 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 KAA19121 for ; Thu, 28 Oct 2004 10:45:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNBkj-0002nK-Px for sip-web-archive@ietf.org; Thu, 28 Oct 2004 10:59:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNBPi-000837-An; Thu, 28 Oct 2004 10:38:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNBNw-0007bT-Re for sip@megatron.ietf.org; Thu, 28 Oct 2004 10:36:16 -0400 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 KAA18231 for ; Thu, 28 Oct 2004 10:36:16 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNBc1-0002dw-S7 for sip@ietf.org; Thu, 28 Oct 2004 10:50:51 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9SEa5l00453; Thu, 28 Oct 2004 17:36:05 +0300 (EET DST) X-Scanned: Thu, 28 Oct 2004 17:35:39 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i9SEZd2T012921; Thu, 28 Oct 2004 17:35:39 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00hfCufk; Thu, 28 Oct 2004 17:35:39 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9SEZcS04901; Thu, 28 Oct 2004 17:35:38 +0300 (EET DST) Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 28 Oct 2004 17:35:25 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 28 Oct 2004 17:35:25 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Event Lists: Back-End Credentials Date: Thu, 28 Oct 2004 17:35:25 +0300 Message-ID: <5816828233DEFA41807A6CFDFDF2343C3A8BDA@esebe056.ntc.nokia.com> Thread-Topic: [Sip] Event Lists: Back-End Credentials Thread-Index: AcS8+O0GycK9VoX5R9Gt5yp3HvYTjAAAGJYA To: X-OriginalArrivalTime: 28 Oct 2004 14:35:25.0121 (UTC) FILETIME=[5CB22B10:01C4BCFB] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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.3 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable I didn't know that communication with IESG is one way only. Can the IESG = member who is blocking this explain why this cannot be outside the scope = of this document? Anyway, so how about an XCAP usage document that is carried signed and = encrypted to the server using HTTP. That xcap usage document can include = realm, username and password for realms that the user knows will be = needed by the RLS. Note that this is useful not just for backend subscriptions, but also = for any list usage we can think for that will result in backend requests = being sent on behalf of a client. A server needing a secret key to use on behave of a user can look in the = XCAP document of that user. Regards, Hisham > -----Original Message----- > From: ext Adam Roach [mailto:adam@nostrum.com] > Sent: 28.October.2004 17:16 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: sip@ietf.org > Subject: Re: [Sip] Event Lists: Back-End Credentials >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 > > Why isn't it enough to say that the way an watcher passes=20 > the key to=20 > > the RLS is outside the scope of this document? >=20 >=20 > Because that's exactly what the document says right now, and the IESG=20 > won't let it pass as a result. >=20 >=20 > /a >=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 Oct 28 15:17:39 2004 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 PAA20449 for ; Thu, 28 Oct 2004 15:17:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNG0O-0005dK-MI for sip-web-archive@ietf.org; Thu, 28 Oct 2004 15:32:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNCmn-0005t7-0u; Thu, 28 Oct 2004 12:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNBx4-0001St-OV; Thu, 28 Oct 2004 11:12:35 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23683; Thu, 28 Oct 2004 11:12:33 -0400 (EDT) Message-Id: <200410281512.LAA23683@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, 28 Oct 2004 11:12:33 -0400 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-content-indirect-mech-05.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: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --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 : A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages Author(s) : M. Dolly Filename : draft-ietf-sip-content-indirect-mech-05.txt Pages : 19 Date : 2004-10-27 This document proposes an extension to the URL MIME External- Body Access-Type to satisfy the content indirection requirements for SIP. These extensions are aimed at allowing any MIME part in a SIP message to be referred to indirectly via a URI. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-content-indirect-mech-05.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-content-indirect-mech-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-content-indirect-mech-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-28110342.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-content-indirect-mech-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-content-indirect-mech-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28110342.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 Oct 28 15:46:03 2004 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 PAA26669 for ; Thu, 28 Oct 2004 15:46:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNGRt-0007T5-Be for sip-web-archive@ietf.org; Thu, 28 Oct 2004 16:00:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNCn8-0005zW-0A; Thu, 28 Oct 2004 12:06:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNC1i-0004J2-45 for sip@megatron.ietf.org; Thu, 28 Oct 2004 11:17:22 -0400 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 LAA24832 for ; Thu, 28 Oct 2004 11:17:20 -0400 (EDT) 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 1CNCFm-0004PJ-TI for sip@ietf.org; Thu, 28 Oct 2004 11:31:56 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 28 Oct 2004 08:26:07 -0700 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 i9SFGek2013915; Thu, 28 Oct 2004 08:16:41 -0700 (PDT) Received: from [10.32.245.154] (stealth-10-32-245-154.cisco.com [10.32.245.154]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id i9SFIJVu006790; Thu, 28 Oct 2004 08:18:19 -0700 In-Reply-To: <5816828233DEFA41807A6CFDFDF2343C3A8BDA@esebe056.ntc.nokia.com> References: <5816828233DEFA41807A6CFDFDF2343C3A8BDA@esebe056.ntc.nokia.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <618AA730-28F4-11D9-8FCC-000A95C73842@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Sip] Event Lists: Back-End Credentials Date: Thu, 28 Oct 2004 11:16:45 -0400 To: hisham.khartabil@nokia.com X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1098976700.405748"; x:"432200"; a:"rsa-sha1"; b:"nofws:2001"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"omTq0k0IgcgDF0SWEKfrd4zpTUSEe2nz4Mt7XDMCrZmZvF5pr+zo1PHd/PJuh" "ptPvC7ZBWP6DC0LdUgr6Bt8KrKrRmwUuyUCYUkPjE4ohTcaAL7OfRsiPRsClj" "apI94ag6meUHBmGq4oM7VuHuF8En3EzAQjjPa3jVXtyokIu6M="; c:"From: David R Oran "; c:"Subject: Re: [Sip] Event Lists: Back-End Credentials"; c:"Date: Thu, 28 Oct 2004 11:16:45 -0400" 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: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, adam@nostrum.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit On Oct 28, 2004, at 10:35 AM, hisham.khartabil@nokia.com wrote: > I didn't know that communication with IESG is one way only. Can the > IESG member who is blocking this explain why this cannot be outside > the scope of this document? > > Anyway, so how about an XCAP usage document that is carried signed and > encrypted to the server using HTTP. That xcap usage document can > include realm, username and password for realms that the user knows > will be needed by the RLS. > That's precisely the problem. Now the RLS can impersonate the user and do anything the user could. > Note that this is useful not just for backend subscriptions, but also > for any list usage we can think for that will result in backend > requests being sent on behalf of a client. > > A server needing a secret key to use on behave of a user can look in > the XCAP document of that user. > Can I be your RLS server? Please? Pretty please? Dave. > Regards, > Hisham > >> -----Original Message----- >> From: ext Adam Roach [mailto:adam@nostrum.com] >> Sent: 28.October.2004 17:16 >> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) >> Cc: sip@ietf.org >> Subject: Re: [Sip] Event Lists: Back-End Credentials >> >> >> hisham.khartabil@nokia.com wrote: >> >>> Why isn't it enough to say that the way an watcher passes >> the key to >>> the RLS is outside the scope of this document? >> >> >> Because that's exactly what the document says right now, and the IESG >> won't let it pass as a result. >> >> >> /a >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > 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 Oct 28 19:07:32 2004 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 TAA05970 for ; Thu, 28 Oct 2004 19:07:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNJat-000231-IM for sip-web-archive@ietf.org; Thu, 28 Oct 2004 19:22:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNGVJ-0007w0-BH; Thu, 28 Oct 2004 16:04:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNEKq-00085J-So for sip@megatron.ietf.org; Thu, 28 Oct 2004 13:45:16 -0400 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 NAA00007 for ; Thu, 28 Oct 2004 13:45:16 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNEYx-0007Pd-25 for sip@ietf.org; Thu, 28 Oct 2004 13:59:52 -0400 Received: from [63.110.3.195] ([63.110.3.195]) (authenticated bits=0) by nylon.softarmor.com (8.12.11/8.12.11) with ESMTP id i9SHjPoe001404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Oct 2004 12:45:26 -0500 Message-ID: <41813002.8060608@softarmor.com> Date: Thu, 28 Oct 2004 12:44:34 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) 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: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: Mary Barnes Subject: [Sip] Working Group Last Call for History Info X-BeenThere: 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 Content-Transfer-Encoding: 7bit I believe History Info is pretty much ready for last call. See draft-ietf-sip-history-info-04.txt I believe it need news IPR boilerplate before moving to the IESG, but that shouldn't stop us from making a last effort at reviewing the text here. Mary has provided a detailed report of changes under separate cover. WGLC therefore starts immediately. Given the upcoming meeting, I would like to conclude WGLC on November 29, 2004. We should expect to TALK about this in DC, so do your homework, kids! -- Dean co-chair, SIP _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 28 19:14:48 2004 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 TAA07672 for ; Thu, 28 Oct 2004 19:14:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNJhv-0002Zp-Me for sip-web-archive@ietf.org; Thu, 28 Oct 2004 19:29:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNGVu-0000tK-DK; Thu, 28 Oct 2004 16:04:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNEQC-0001m4-0O for sip@megatron.ietf.org; Thu, 28 Oct 2004 13:50:48 -0400 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 NAA01391 for ; Thu, 28 Oct 2004 13:50:47 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNEeH-0007tW-QQ for sip@ietf.org; Thu, 28 Oct 2004 14:05:23 -0400 Received: from [63.110.3.195] ([63.110.3.195]) (authenticated bits=0) by nylon.softarmor.com (8.12.11/8.12.11) with ESMTP id i9SHoxoq001430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 28 Oct 2004 12:51:00 -0500 Message-ID: <41813150.7080707@softarmor.com> Date: Thu, 28 Oct 2004 12:50:08 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) 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: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Subject: [Sip] Some Advice about IPR bolierplate. USE THE NEW STUFF! X-BeenThere: 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: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit I've noticed that several of the drafts submitted in "the rush" before IETF 61 haven't had their IPR boilerplate updated. RFC 3667 and 3668 revised the requirements for IETF publication. Please read them. We should (ok, MUST) all start using the new format. If you use xml2rfc (and you should!) the newer versions will mostly take care of this for you. Here's an example from a draft that used xml2rfc (Thanks, Eric!). Note the critical pieces under "Status of this Memo": --------------------------------------- A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages draft-ietf-sip-content-indirect-mech-05 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 25, 2005. Copyright Notice Copyright (C) The Internet Society (2004). ------------------------------ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 28 22:35:56 2004 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 WAA24554 for ; Thu, 28 Oct 2004 22:35:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNMqc-0000K9-DN for sip-web-archive@ietf.org; Thu, 28 Oct 2004 22:50:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNKHE-0007X2-Qh; Thu, 28 Oct 2004 20:05:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNJ97-0000vY-3Y for sip@megatron.ietf.org; Thu, 28 Oct 2004 18:53:29 -0400 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 SAA03487 for ; Thu, 28 Oct 2004 18:53:26 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNJNF-0001Nj-AY for sip@ietf.org; Thu, 28 Oct 2004 19:08:06 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9SMrFl28648; Fri, 29 Oct 2004 01:53:15 +0300 (EET DST) X-Scanned: Fri, 29 Oct 2004 01:53:03 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i9SMr3Xs009560; Fri, 29 Oct 2004 01:53:03 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00QkQKLx; Fri, 29 Oct 2004 01:53:02 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9SMr0a11933; Fri, 29 Oct 2004 01:53:00 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 29 Oct 2004 01:53:00 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 29 Oct 2004 01:53:00 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Event Lists: Back-End Credentials Date: Fri, 29 Oct 2004 01:52:59 +0300 Message-ID: <5816828233DEFA41807A6CFDFDF2343C3A8BDD@esebe056.ntc.nokia.com> Thread-Topic: [Sip] Event Lists: Back-End Credentials Thread-Index: AcS9AWNebNNDBqcbRu2df1b0hePN4gAPtgpg To: X-OriginalArrivalTime: 28 Oct 2004 22:53:00.0307 (UTC) FILETIME=[DFC60630:01C4BD40] X-Spam-Score: 0.3 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, adam@nostrum.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext David R Oran [mailto:oran@cisco.com] > Sent: 28.October.2004 18:17 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: adam@nostrum.com; sip@ietf.org > Subject: Re: [Sip] Event Lists: Back-End Credentials >=20 >=20 >=20 > On Oct 28, 2004, at 10:35 AM, hisham.khartabil@nokia.com wrote: >=20 > > I didn't know that communication with IESG is one way only. Can the=20 > > IESG member who is blocking this explain why this cannot be outside=20 > > the scope of this document? > > > > Anyway, so how about an XCAP usage document that is carried=20 > signed and=20 > > encrypted to the server using HTTP. That xcap usage document can=20 > > include realm, username and password for realms that the user knows=20 > > will be needed by the RLS. > > > That's precisely the problem. Now the RLS can impersonate the=20 > user and=20 > do anything the user could. I thought the problem was how to transport the secret to the RLS. = Irrespective of how that is done (using XCAP or carrying it in the = SUBSCRIBE request itself), you will face the same problem you describe = above. So am I right in assuming that you're advocating Adam's latest = suggestion on RLS doing backend subscription using its own address? >=20 > > Note that this is useful not just for backend=20 > subscriptions, but also=20 > > for any list usage we can think for that will result in backend=20 > > requests being sent on behalf of a client. > > > > A server needing a secret key to use on behave of a user=20 > can look in=20 > > the XCAP document of that user. > > > Can I be your RLS server? Please? Pretty please? Ok, but if you behave :) You would expect a trust relationship between = the client and the RLS. /Hisham >=20 > Dave. >=20 >=20 > > Regards, > > Hisham > > > >> -----Original Message----- > >> From: ext Adam Roach [mailto:adam@nostrum.com] > >> Sent: 28.October.2004 17:16 > >> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > >> Cc: sip@ietf.org > >> Subject: Re: [Sip] Event Lists: Back-End Credentials > >> > >> > >> hisham.khartabil@nokia.com wrote: > >> > >>> Why isn't it enough to say that the way an watcher passes > >> the key to > >>> the RLS is outside the scope of this document? > >> > >> > >> Because that's exactly what the document says right now,=20 > and the IESG > >> won't let it pass as a result. > >> > >> > >> /a > >> > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 28 22:53:14 2004 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 WAA27838 for ; Thu, 28 Oct 2004 22:53:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNN7L-0001QT-IQ for sip-web-archive@ietf.org; Thu, 28 Oct 2004 23:07:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNM5K-0001sE-8b; Thu, 28 Oct 2004 22:01:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNJEN-0007M9-8b for sip@megatron.ietf.org; Thu, 28 Oct 2004 18:58:55 -0400 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 SAA04889 for ; Thu, 28 Oct 2004 18:58:52 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNJSN-0001kE-46 for sip@ietf.org; Thu, 28 Oct 2004 19:13:33 -0400 Received: from [63.110.3.195] ([63.110.3.195]) (authenticated bits=0) by nylon.softarmor.com (8.12.11/8.12.11) with ESMTP id i9SMwxhC003178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 28 Oct 2004 17:58:59 -0500 Message-ID: <4181797E.90408@softarmor.com> Date: Thu, 28 Oct 2004 17:58:06 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) 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: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Subject: [Sip] Are we ready to WGLC identity-03? X-BeenThere: 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 I polled for comments on draft-ietf-sip-identity-03 a while back, and I think the only direct comment I saw back was from MAT and basically asked "How are the implementations going?" Is anybody implementing this? I'll admit personally I need something like this in products I work with, but I know nothing about implementation plans. I'd also be intersted in hearing any details about variants that people do have implementation experience with, such as MASS-like approaches, if any. Its a bit hard to judge consensus in a vacuum. I'll admit the material here is a bit esoteric, but it does have some serious real-world implications. Somebody out there has an opinion, I'm sure of it . . . If you think STRONGLY that we either are, or are not, ready for a working group last call on this document, please speak up. Thanks, -- Dean as 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 Thu Oct 28 22:56:20 2004 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 WAA28398 for ; Thu, 28 Oct 2004 22:56:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNNAM-0001aE-Mh for sip-web-archive@ietf.org; Thu, 28 Oct 2004 23:11:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNMB7-0007pV-9y; Thu, 28 Oct 2004 22:07:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNJgq-0004v4-IT for sip@megatron.ietf.org; Thu, 28 Oct 2004 19:28:20 -0400 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 TAA10642 for ; Thu, 28 Oct 2004 19:28:18 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNJv0-0003Vy-Lz for sip@ietf.org; Thu, 28 Oct 2004 19:42:59 -0400 Received: from [63.110.3.195] ([63.110.3.195]) (authenticated bits=0) by nylon.softarmor.com (8.12.11/8.12.11) with ESMTP id i9SNSY2Q003808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Oct 2004 18:28:34 -0500 Message-ID: <4181806E.6020905@softarmor.com> Date: Thu, 28 Oct 2004 18:27:42 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Subject: Re: [Sip] Working Group Last Call for History Info References: <41813002.8060608@softarmor.com> In-Reply-To: <41813002.8060608@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: Mary Barnes X-BeenThere: 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: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Dean Willis wrote: > > I believe History Info is pretty much ready for last call. > > See draft-ietf-sip-history-info-04.txt > > I believe it need news IPR boilerplate before moving to the IESG, but > that shouldn't stop us from making a last effort at reviewing the > text here. Mary has provided a detailed report of changes under > separate cover. > I believe I was wrong about that -- apparently, I made the "fix the boilerplate" mark on the wrong row of my checklist. Sorry about that! Mary, as usual, did it right, and I, as happens far too often, did not. -- 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 Oct 28 23:02:16 2004 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 XAA29823 for ; Thu, 28 Oct 2004 23:02:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNNG5-0001tR-1e for sip-web-archive@ietf.org; Thu, 28 Oct 2004 23:16:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNMT1-00028d-Qi; Thu, 28 Oct 2004 22:26:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNK4z-0001A5-AE for sip@megatron.ietf.org; Thu, 28 Oct 2004 19:53:17 -0400 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 TAA18091 for ; Thu, 28 Oct 2004 19:53:14 -0400 (EDT) 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 1CNKJ9-0005uL-Kv for sip@ietf.org; Thu, 28 Oct 2004 20:07:56 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 28 Oct 2004 17:02:07 -0700 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 i9SNqcQ0014099; Thu, 28 Oct 2004 16:52:38 -0700 (PDT) Received: from [10.32.245.154] (stealth-10-32-245-154.cisco.com [10.32.245.154]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id i9SNsDjc011377; Thu, 28 Oct 2004 16:54:13 -0700 In-Reply-To: <5816828233DEFA41807A6CFDFDF2343C3A8BDD@esebe056.ntc.nokia.com> References: <5816828233DEFA41807A6CFDFDF2343C3A8BDD@esebe056.ntc.nokia.com> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <74053166-293C-11D9-8FCC-000A95C73842@cisco.com> From: David R Oran Subject: Re: [Sip] Event Lists: Back-End Credentials Date: Thu, 28 Oct 2004 19:52:40 -0400 To: X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1099007654.302156"; x:"432200"; a:"rsa-sha1"; b:"nofws:4580"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"OwlNS+p3Mp3bzo3NHAcSLeRt0ZLUSOttA1Zd0jD75N57vzWmv5i2ehM1/c/3S" "RuvMTFBdeswABinE8HT6YmqOTJGnP/gSPdpwceIxcQAtNzoOLhFO0QBMDtXmv" "aujquQNAkzssv+wb2mofv2M2TnvMHnDsIYFTKKz3k9yiXuoPE="; c:"From: David R Oran "; c:"Subject: Re: [Sip] Event Lists: Back-End Credentials"; c:"Date: Thu, 28 Oct 2004 19:52:40 -0400" 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: 87a3f533bb300b99e2a18357f3c1563d Cc: sip@ietf.org, adam@nostrum.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1654330079==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 --===============1654330079== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2-441276325" --Apple-Mail-2-441276325 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Oct 28, 2004, at 6:52 PM, wrote: > > >> -----Original Message----- >> From: ext David R Oran [mailto:oran@cisco.com] >> Sent: 28.October.2004 18:17 >> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) >> Cc: adam@nostrum.com; sip@ietf.org >> Subject: Re: [Sip] Event Lists: Back-End Credentials >> >> >> >> On Oct 28, 2004, at 10:35 AM, hisham.khartabil@nokia.com wrote: >> >>> I didn't know that communication with IESG is one way only. Can the >>> IESG member who is blocking this explain why this cannot be outside >>> the scope of this document? >>> >>> Anyway, so how about an XCAP usage document that is carried >> signed and >>> encrypted to the server using HTTP. That xcap usage document can >>> include realm, username and password for realms that the user knows >>> will be needed by the RLS. >>> >> That's precisely the problem. Now the RLS can impersonate the >> user and >> do anything the user could. > > I thought the problem was how to transport the secret to the RLS. > Irrespective of how that is done (using XCAP or carrying it in the > SUBSCRIBE request itself), you will face the same problem you describe > above. So am I right in assuming that you're advocating Adam's latest > suggestion on RLS doing backend subscription using its own address? > I'm not sure what I'm "advocating", since I said in my original post that I don't feel strongly about the subject. Since I'm not in the middle of the fray amongst the folks who think we need RLS urgently, I can comfortably sit back and "advocate" not progressing RLS until we have at least a resticted subset of the delegation problem solved. If the only alternatives on the table are whether to progress RLS with a security scheme that opens the user up to impersonation by a server he has very limited trust in, and progressing an solution that uses deprate credentials and hence either has limited utility or high user complexity (users have to directly subscribe or be limited to information available to the whole world), I guess I would vote for the latter. >> >>> Note that this is useful not just for backend >> subscriptions, but also >>> for any list usage we can think for that will result in backend >>> requests being sent on behalf of a client. >>> >>> A server needing a secret key to use on behave of a user >> can look in >>> the XCAP document of that user. >>> >> Can I be your RLS server? Please? Pretty please? > > Ok, but if you behave :) You would expect a trust relationship between > the client and the RLS. > Yes, but a very limited one, not one that permits identity theft. > /Hisham > >> >> Dave. >> >> >>> Regards, >>> Hisham >>> >>>> -----Original Message----- >>>> From: ext Adam Roach [mailto:adam@nostrum.com] >>>> Sent: 28.October.2004 17:16 >>>> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) >>>> Cc: sip@ietf.org >>>> Subject: Re: [Sip] Event Lists: Back-End Credentials >>>> >>>> >>>> hisham.khartabil@nokia.com wrote: >>>> >>>>> Why isn't it enough to say that the way an watcher passes >>>> the key to >>>>> the RLS is outside the scope of this document? >>>> >>>> >>>> Because that's exactly what the document says right now, >> and the IESG >>>> won't let it pass as a result. >>>> >>>> >>>> /a >>>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >> David R. Oran >> Cisco Fellow >> Cisco Systems >> 7 Ladyslipper Lane >> Acton, MA 01720 USA >> Tel: +1 978 264 2048 >> Email: oran@cisco.com >> >> >> David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com --Apple-Mail-2-441276325 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFBgYZIjWaEtlTdKuYRAn3/AKC1+KuRiZ/QN81DC93x+l4Pz+NFEgCfe+YF cEVRI9/dV6sJp/HTvXpqH4w= =35Bq -----END PGP SIGNATURE----- --Apple-Mail-2-441276325-- --===============1654330079== 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 --===============1654330079==-- From sip-bounces@ietf.org Fri Oct 29 03:11:54 2004 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 DAA00934 for ; Fri, 29 Oct 2004 03:11:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNR9i-00075u-9v for sip-web-archive@ietf.org; Fri, 29 Oct 2004 03:26:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNQcA-000103-P0; Fri, 29 Oct 2004 02:51:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKGvF-0000k6-5l for sip@megatron.ietf.org; Wed, 20 Oct 2004 09:54:37 -0400 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 JAA03862 for ; Wed, 20 Oct 2004 09:54:29 -0400 (EDT) Received: from go4.ext.ti.com ([192.91.75.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKH7W-00011A-P4 for sip@ietf.org; Wed, 20 Oct 2004 10:07:22 -0400 Received: from dlep91.itg.ti.com ([157.170.152.55]) by go4.ext.ti.com (8.12.11/8.12.11) with ESMTP id i9KDrtc0024783; Wed, 20 Oct 2004 08:53:55 -0500 (CDT) Received: from dmye2k02.ent.ti.com (localhost [127.0.0.1]) by dlep91.itg.ti.com (8.12.11/8.12.11) with ESMTP id i9KDrjZT004324; Wed, 20 Oct 2004 08:53:54 -0500 (CDT) Received: from dlee2k71.ent.ti.com ([157.170.152.85]) by dmye2k02.ent.ti.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 20 Oct 2004 09:53:54 -0400 Received: from dlee2k03.ent.ti.com ([157.170.152.86]) by dlee2k71.ent.ti.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 20 Oct 2004 08:53:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.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] Call Transfer Scenario Date: Wed, 20 Oct 2004 08:53:50 -0500 Message-ID: Thread-Topic: [Sip] Call Transfer Scenario Thread-Index: AcS2U0LLPjelRpKUQpKSgpQNs2MK4AAVeyhQ From: "Bai, Gali" To: "Anurag Kabra" , X-OriginalArrivalTime: 20 Oct 2004 13:53:50.0746 (UTC) FILETIME=[3AA0BFA0:01C4B6AC] X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 29 Oct 2004 02:51:55 -0400 X-BeenThere: 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: quoted-printable Anurag, In the attended call transfer scenario, A-transferor needs to call C-transfer target first and if C agrees to accept call from B, A will send REFER with Replaces in its Refer-to header to B-transferee; And the Invite from B to C also contains Replaces header to C. So the differences are: 1. In attended call transfer, A calls C first and sends REFER with Replaces in the Refer-to header; Unattended call transfer, A does not need to call C, just sends REFER to B; 2. B Invite C, in attended call transfer, the Invite contains Replaces header to replace the dialog between A and C; in unattended call transfer, B Invite to C does not have Replaces header 3. If C receives Invite with Replaces header, it will be answered as an attended call transfer, C needs to replace the existing dialog based on Replaces header.=20 Gali Bai -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Anurag Kabra Sent: Tuesday, October 19, 2004 12:18 PM To: sip@ietf.org Subject: [Sip] Call Transfer Scenario Hi I need to clear few of my doubts regarding call transfer,=20 In a scenario of A, B and C - Unattended Transfer (Blind Transfer) A =3D transferor B =3D transferee C =3D transfer target 1. There is a call set up between A and B 2. A need to transfer to C - A puts the RTP session on Hold with Re-INVITE=20 and sends REFER with refer-to C,=20 3. B on getting refer needs to put audio streaming on hold and so sends Re-INVITE!! -- (DOUBT - is this step right) 4. B sends NOTIFY with subscription-state =3D active and expires to A 5. B now INVITES C=20 6. On getting response its sends a NOTIFY to A with subscription-state = =3D terminated (Need to know if the REFER expires because of expires in NOTIFY what can be=20 done ie if we get a time out on A side) 7. Now A sends a BYE to B (What to do if B wants to terminate the dialog with CANCEL or BYE) How can we differentiate Attended Transfer and Blind Transfer in the=20 application?? Can anyone tell me free sip UA implementing Call Transfer? Please do let me know any of your views. Please correct me if i am wrong anywhere.=20 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 Fri Oct 29 08:21:55 2004 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 IAA23415 for ; Fri, 29 Oct 2004 08:21:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNVzk-0005Yr-HY for sip-web-archive@ietf.org; Fri, 29 Oct 2004 08:36:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNVao-0001j8-KF; Fri, 29 Oct 2004 08:10:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNVTg-0003fJ-13 for sip@megatron.ietf.org; Fri, 29 Oct 2004 08:03:32 -0400 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 IAA21623 for ; Fri, 29 Oct 2004 08:03:30 -0400 (EDT) Received: from mpd-821.tvcom.ru ([80.246.74.222] helo=intserv.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CNVhu-00052z-NC for sip@ietf.org; Fri, 29 Oct 2004 08:18:17 -0400 Date: Fri, 29 Oct 2004 16:03:26 +0300 To: "Sip" From: "Dromasca" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------tnhljmsuzxutycwonqbd" X-Spam-Score: 1.0 (+) X-Scan-Signature: 27f32072baa9c4fb41949212e86ea6d2 Subject: [Sip] Re: X-BeenThere: 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: 6fd498969019220b4f904725504c12a0 ----------tnhljmsuzxutycwonqbd Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :)
----------tnhljmsuzxutycwonqbd Content-Type: application/octet-stream; name="price.cpl" Content-Disposition: attachment; filename="price.cpl" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAABQRQAATAEDAO8AgkEAAAAAAAAAAOAADiELAQUMAAwAAAAC AAAAAAAAMBUAAAAQAAAAIAAAAAAAEAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAJeLAAAAAgAA AAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAADAUAAA8AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACAAACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACMFAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50 ZXh0AAAAEAoAAAAQAAAACAAAAAIAAAAAAAAAAAAAAAAAACAAAOAucmVsb2MAACoAAAAAIAAA AAIAAAAKAAAAAAAAAAAAAAAAAABAAABCAAAAAAAAAACXWwAAADAAAJdbAAAADAAAAAAAAAAA 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 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAk1sAAE1a AAABAAAAAgAAAP//AABAAAAAAAAAAEAAAAAAAAAAtEzNIQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAEAAAABQRQAATAEFAAAAAAAAAAAAAAAAAOAADwELAQAAADoAAABKAAAAAAAAAKAAAAAQ AAAAUAAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAI4DAQAAAgAAAAAAAAIAAAAAABAA ABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAJqiAADRAAAAAPAAAI4TAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAUAAAsAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAA6AAAAAAAAujkAAAAQ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAMAADAAAAAAAAPIKAAAAUAAAAAAAAAAAAAAAAAAA AAAAAAAAAABAAADAADAAAAAAAAB1PAAAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAwAAA AAAAAAAAAFAAAACgAAAAQgAAAAIAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAAI4TAAAA8AAA jhMAAABEAAAAAAAAAAAAAAAAAAAgAADgYOgBAAAA6IPEBOgBAAAA6V2B7dkhQADobQIAAOjr COsCzSD/JCSaZr5ycugBAAAAmlmNlUQiQADoAQAAAGlYZr9zZ+goAgAAjVL56AEAAADoW2jM /+KaZGZkZ2ZoZnl5Z2d2am1qa2poZ3V1Zm5oZ//kaf+lsCRAAOnooP///+sCzSCLxOsCzSCB ABYAAAAPhfQBAABp6AAAAABYmWoVWo0EAlDowAEAAGY9hvN0A+mNleYiQADotQEAAOgBAAAA aYPEBI29NSVAALm7PQAAurS4fOaKB9LIMsH20DLFMsIyxtLAAsECxQLCAsbSyCrBKsX20CrC KsbSwNPCiAdHSXXS6AEAAADog8QEDwvoK9JkiwKLIGSPAlhdw5qLlbAkQADoSQEAAOgBAAAA x4PEBLskegAAagRoADAAAFNqAP+VtCRAAOgBAAAA6IPEBGgAQAAAU1DoAQAAAOmDxARQjZU1 JUAAUugOAAAA6AEAAABpg8QEWl4OVstgi3QkJIt8JCj8soCk6GwAAABz+CvJ6GMAAABzGivA 6FoAAABzIEGwEOhQAAAAEsBz93VAquvW6HUAAABJ4hToawAAAOssrNHoD4SXAAAAE8nrHJFI weAIrOhRAAAAPQB9AABzCoD8BXMGg/h/dwJBQZWLxVaL9yvw86Re648C0nUFihZGEtLD6yU2 VTk2VTk6VTk2VUM2VTk2VQ85NlU5OlU5NlVDNlU5NlUPVUM5K8lB6Mf///8TyejA////cvLD 6yM2VTk2VTk6VTk2VUM2VTk2VQ85NlU5OlU5NlVDNlU5NlUPOSt8JCiJfCQcYcPrAWlYWP/g WVJVjYXYIkAAUCvAZP8wZIkg6wPHhOhRw+sDx4SaWUHr8AAAAAAAAAAA3qIAAAAAAAAAAAAA 9qIAAN6iAADWogAAAAAAAAAAAAADowAA1qIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWaMAAAAA AAAOowAAH6MAAC6jAAA8owAAS6MAAAAAAABLRVJORUwzMi5ETEwAVVNFUjMyLkRMTAAAAEdl dFByb2NBZGRyZXNzAAAATG9hZExpYnJhcnlBAAAARXhpdFByb2Nlc3MAAABWaXJ0dWFsQWxs b2MAAABWaXJ0dWFsRnJlZQAAAE1lc3NhZ2VCb3hBAAAAAADBNpySPNJdz4yflLf7D+pj2XEM gijNQ5ShiUoIdD9Xs3ANfg2SFOwnzInxt0SDS2TGpGqlaqyNyL93MOYH6sDaSjDCMVfhapA7 WcaHRY5S4ciMaSVxcRZH9L/oarXpNqPs3q88sQedbKythK5ttNNhn8jiNE3LbM4HbMJv2k2t G1gEB/U9O0wE4gkqCfXBqwNE2pVG3TbWFTmOeQZ2ka8nL7cYdqkURObIq3bCp0THZRSq8T1B p3A8WKq20/IzxkvCGRMXV21sYOqkR8pz2SQs1kZ7sVYWBQv0LBt6eg4C4+ibw8AKtzfAAnv6 TwhSVKqKvT8Ni2lwBU+Fm15o9fKuIfM7T+XRQqA/pARd03zCtgI/XIbeiv6ye5hmdlz7o0KZ mQixWLHBfo9D5AiTmB02501x9qml+IdBsclvLneU9wshvRHXFfiyfcqju9fACrgdeOKhoxHw g+k54vWkGDJLJvDNlIERi+nn17CR3W7hS/t6zK/wZvqkD87gkGaR/86Fi7ufJnV8nW5whkFa T0HR7T5qDxV6NcIPrDHJSrJbhy+cnEoec8S5QElpd9YrHpOYOl/+bKTRX/O/Je44pUWOPCj0 0vin0+ZPUuKhLL+VeXCxHB9eYh9LUOj4xehOkU+xkCzs75dQolR4FOYM11gd2u2vIwhqkohM WDPpH2E0fCT8LP9Xu9sZT2CBH9z1qWKUT8XYF9rD0DtiO6jng9LcHJDnbtxMCexYCjdU82bX GbU/Sukuqjwp/WFXVPVAwsC2x1PUw7Y2C2GauhqOwURyojvcWR/P8Hw7oXtK0VS2zqJO67rO XmaCNqKZo3WcDUhP3QPK95dLj27X2/jPNfHy0bPViEQG3tmF9Cc5fs0AeQ/t7PUnrvDlBiL3 k2Ck4oHvG/3kTF/uE4oGUJ0qnBex9AwDDr9MJLkHjwXpbgLxB8y9NNdWEIQfB/ezrYxgq3t6 8kjM8/wF7rsw7HohqyKEMV+Hkvannlw21YO3mrfvEg9io8pQHVB/HHWjwoNnTeb/dIhTZo+M 6+mNutSbxyxjN9b2eCdWpTE2sXoGDq5Cb0Hyn1eep/M5cJTAtF9NgzRQDeIq0sW9aZN/AN+C Idj+FLWwSMwufhBrZ1mPTJYgf7nY0G9qg7BBJI3D/BkZ9yD0mesi8MUZJH4SUCtDH8ARaimW kFqMv2qjUNvCo4krUXt8S3TP34lXgQXbrt4ELuuWIkBO/0hBmkuebmXBKZgiTIREqUwUgYgr hDJ5wKdu0JMbG4HpqI/oHrqWha6WKVJzPG+sj0PxmvLm9LvupjSCQNgiysOaGz+LB9Qcc9Xp 0npoKZUv3nPmhwh1XFHDGW6mA0m33FTGb8WbhRNy5v22vXRKV5ABgA2bZqptorrg3V3pji/j Ue7hhR/ynGy9rW7iFS9gkjRmZ5erpIJoioMDuBo4YaewBqnZFVzT/EJrxPjQcIQW2AZrCIZe OFJh1q4Lzl7yxlC5pwsxT+a0uSC5/OBLEZd4mjUOnframDL2jUWF4PiXpq7ER3L6N2L8D/PN vuzS0QX2qCHuv51gmwr+8OTmiwifDsvRbNfXmblU/23A3dxuVkuekkvah0FmLrs3+PimROok UMpHqhvaG+1j/I7I05FcPug2FpTr02DKbnjzbadUqcNDz01jG+tOETghFvttlWtbjqGeS6RV m75R/1i3sKV/4VUGpDXwtd5amKUByiEN2xQIK/lcwFygLUNbUkI1d9K6wN7hmA0uBskwpYST bJyHvnZAtom9aBriTxgajJm/qytfvfASfzPTC/ueuWu5hxC5CyugnwNDoP9FSuvzSiAbCgu7 PD8FS7ayGqUzIaHStDH3yJtodsysYZw8fSE8glqt9HVKhRN+iqSbuFkDPTarmTdE4rYxjMZt q2e+rZHLSPFabmLVy88vGtFYvA0fYeBYqGlwc9Fyk3mCwByC1LEnneNGT0qscFNycNb3pU6C GSu8NWZp6H03ATBljFJ7yNF1b8U7AVaPotuzkiV9POiPEz0BWQlGsmuV0mq9+G1kNCiTVhJ3 tuGRudpBeqvq4IMoeWacmfITmUfOpPRWtqKCqOihVvWM8uZZWeRaB/9dpknm3Y+mBt2Qp64M fBNh89hOo0+1O+9ytbyRw+RkN6xaEQa/IFbaid/sKb1yDSQLiY7ZC46yZjGeJcGfu8msiCZ1 w5fcLSQhi2/R2a1KsyFBZP3j2EXHWMUQOVA9Bh3rEUS0QLKHaZEBqJXN8C4e4ojT/u/fyuSh /b1sL3QorYz/1WbCwChftKzyqduYfwLKYu+8zwEFQ19aaE6TTu8YBV1crKHvpsgvzm5PqGfA KqAudfD3t5JQnptRwAertgtRzPiafePVKUdzLnRYqvCL3i6TQIKY1ViVjTt2TWx9TmF/qptF geKussYLbYwDcdAsS9FNe5518bQVaQQKYz/ztr/zVLhSJgOeelT+77LLzyeOP1cv1XbeLOph MGfF2iBAnGym/YmTkp8RF+lISDYyEt8fcm1sREQoMBGcNaL1Cb47MLMwUlVXMy1S5seofebx WacKxYQs1pZgXVrO+RmrjDJZzhUO43nM92vn9thAiiParkE5TVjkrb+I+PlwBZVR0+EGiyTm Rpq3F5LQUKnihjxj6U+kEWp1YcCX7noy8QSZm0iqPLl+mZGlAYmP1Ld4EeA+sj+bCSm0wBJf Ga8GMd60Dr1FO/ktmhzF43vptTuecglIZQjA9yUzFtBWAYCkidbB4YIXSOZnkvwgn5KvMBkD qDF8ErMp/S1aILE3nqIiWrJS1AcQrxTXX3hqk3BoD7+cIQ12EqZv6YU+yZWeVCmSlhK+Dhme KDLMIbxIRvTME1MMLIpv4bN7SFXbO1HPet2Z6x6vRYHOzw5qmaeRxETlY2z5tFa8yq871v90 boRK17JQjF229hHQYrmwOZHvvtI2x8puMrH/lNPiQut0uMD1b0QiHm7lqJ/OViUqb9aCCh8W 1R+dp4+u5V1PrGn7rx0pejeQnx4CnlFEKfQ3QiANATkAKYZB45rkHKpsUl1IsNVHdcJmSsMa 3m3Zeo063bkeXFF8jI85Ry5YOisXel7xRP2yM8yW/i2LqJ4Hv1jOaXllDRHEG04RgQuHQW/g 8syC2tYUviwWymVI9AZdI8aDUPapv/jGyR7yV0LRRP2a/IDZh8Qf8EtuFVd61UPeNXJRHrIC U4yXEJNWHDahnHIJyjgxPfurHJ6Q5L8gWMXqKSPahhiRkF0Zt7ra1TRxExBexBo25ibDYcCs ub+/rpVLbLx0oI4Eq9j9G0SMFUygCDrovsk8Qxt/upP2Bzj0Pio5mqQzCkjzKBq/inEOLlVK 19fjWp9ToGVs+lYR8FASvkfIw46vLi3KPYZO475mcHEEHtFeUNZ0yvl7/bFsItQ7hwHJxCBv QvzEi73KHB+/AsYjuma1Mx7dgN0WHRVsGnMwrQvNPozGMEyVyltVq1BY+lM6cmFkZjy2N14e 9T82fU0qK5mHdYW5Ua1ezSq9QZ3C88E5MpJwrRv8tC8XLqLDlKe/GNotzZBWg9pTIbw0y3WJ Ck3fIJ79ZkpkK1jW3HBowl3P/8rRhaQ5yB1PIsvCSuovXXvzObpP7NfwNZOZ1v/bCj2GPLWk hoFgzIy3zcWuH93LAdR/CroueBljyvQY78wRWeowWzksayKskgG5/ICirQYiFIcVSdO9ec26 xVIG1AAA4ixN6vJfP2oPe3DeoOlqtSCE5wjzDLHGC9VoFAalwYWwL3C6q0rLNYYaAV6Ogu/Y evoTcO94tP0L6KIjoQFQGCnv70Xurk4irNn6bAXO6LQ+hljLtXMtApIOaCPnKnesbYR1wPn4 X5aVXCGmOr5nWXk3Bq5Sp50ZK92tR874xeQtO1JnGcWtntaU3W3rywOrZpE1SRiv81LF3P61 LAaF/AmSZ1KjAQU1VpfsHL+so4uI/J9APoxoajL7hs/b9PSEMmdnGKLD1S8POPaQPeVkNYez SCvayc90PONQGgnTwxiuKyA/DHr7s3DaGek8FuoogGH7AjofsXO2vQZICLEGxxdIA+cVr6OK gCleASvLXSMiYbF4f8qUQWaI4TeWiDdhvP3ad3YSnTAkyQtVR7SqQ4/cDskbOxwovWX1IXrO BKfaE+fV6hIDEOF8uGlFUCzlJZOb2t6Hyahk49G2h1Lp+GmpV+nHy5Vgde7OydvFakgldvKQ b6QF7S8ZL9Y5VBfrrOBHnobiMHX1wfriMQmOAEUyRUNa2iQlEawVTfAWpZYdkTcjO+ReW9EB whe3qa9e2cgEZ/2K1dD8UJ2Lb8hVT7d/iZgP6mbKM5Lg1rqEQnzgq/Z46/B3r+r3+2SSWRgt vKBHvHbmR0IWlfnKG4FdKxoE+P4vbtDZwdb+pSf/rUEtPn7SP7uw9ixQSHJDhBSh3hU7xtuS EMLk3KARfPR99eoBTH7MG7Jn+6o+ndABlgFYeMLdmJcaVQzfiRtJ+m6IMlPTbGuQuCAVksNE feKdc850DQyOMNpDnZSD9ePhxbcG6tMUybPaOkL6Dfdib1kfz83ixOWWQZ0J+WLl7Q2YS7g9 yN2zm6DlBgRIxF6OGG3Tsbevgn0C+Y5Srqk/F58l3yW/QZRQ4damsZRjQw8JM/AILsI9Cc8i B5OFEUoN9/yG/pNdauT6nQcTsTVvOdKWZDHoxVGyQgjbmht/1o2fCSv83SCT55+ShTzYWUK6 Qcn6AP7uSVASmMsgBuLK72Vlamkw298PKHaOXZawswrRpsjSXre1LJKU/sG6QB/yuLHpXHFs vk5ZNFrukB+5AKlYelK5YINm3UflQKWHV5pfv010IP5J2KTZkfRxBtMWlmQF3nimTDkY54oE BwQeUbt/u22Cl1vWqykHfPNmxDoGlXNoA8AkTsT1Y1Njg04qIOxUnwBrKzRyrqZaMBSf8SDN oOvGGa2Xr/a91fm1WHIWHfEwhdo85O2LRf518Eb3AjFRIbfYbLAP1GTRxX3R/pdUo3sWPRwU LlaaPABG2+se+dvayWsI2HZz1+OizAj1GZ7FWogqCCoxJXXvmqCsyfcRnzHwABGapq+CAJ3w sRpD67VtuE1fp382vfzdNebYwXSZ5+1jZk4S8ElVF2VjUrLyp3b0cX19P7PLLiSpleRBXUT7 bIgAmDNISXB+GoJPiDynnR2OIMDkvROM/a6GZIHq31srtQu7lfi6IIaZm6MFwhQqZDR3vkgF zLyCsiEKUc7h27mqn2FrlCWztdwldtRfZS8thfw0VHOoCKthbSw9iI8U6DPJ3gDDZV416XxZ bsyyDtRVPJraMy87AJpNUREfFYMwnFklmoYE1sOt7JMw6haPMBEEiBJrC8hYzVKW+RdznWNJ c77LN2otggboV873M3EhFJhM+RhmMYv46bh29PIIJ0yB/S8Zcf85nVzWXkJYna4nguB+193T igYcg0Qcogs76L9ESgAu739gfqvNFiQdXc+mWrw4dj7v2gMEkeGKYHYNJ3t6AaD/p8GkaHDr G4xGNjd8+XS738vBlu+DRD/fgcOK/RHbAsZ+1TMJLDGxQsvS5o7pYQ9fBX1i8/sMFuprYF0I +hEL6gC4fPLm+PE4s8Bfp+buWuVm0o4w8QZFBmXEUlpsQz0YX5lXtMnr++H/wbe81RLD0HiJ Ro3SyVqaAlNQGXynhfbxl5CE4WrZfpgHgkXhXkZM1PRrVuRRSa2x3XNPbs8eWRFpYUhDcFiZ /Mjc7MdkXZQa1l9I6O2AUhjvOKoRBYJ6oq+OQobftNAa1Fo7bWVBx2UbqSQHwE+KueGztgZw xoU9CjdzpRVQdeZi2LZh1TshXsSnKJRy6uu+Ixt9jw8meA95T8RuYRTIo1ymAXtopatmt2Wo WKzZygAR21Dto3Ab+ULJGL7Kdq0n9cT3CnIGHpoFSa/MRzlS1kz68kMCQyn1L/CCnw8G3bdi QPJ51eLv1nR3XA90cXEwtL0cc+vKSpnOA2gpNLKRWMXL+Njlz7FCtzn3ThDFM27gaYZkULK3 k95NYmDRex8SY6xuJSQZUclLxkVz+qdwtvogLhqn2Opb87bepGhwibyq9kMOnvuu+4BZcBnb OgXvviN+0BgE82WMBu7b6u7rjZVNQ+FJVpdAEp/+2EnwjqEqoApFK8lZjSkQIXXqp6wFXcB/ YLOV9bL5VJ1PtgzkFlvoxfeAqImCBVDS0W/87J2ZS8RYm0lDZrq8wie1EE6ZSQHgY9hbN+yV eoH4us2H+sRVHmeb8m10fl2p3dImBZKv75ixlw9260JoymrNNKzbbM4msKyF3wZTEWdhvFhH u4KDu3zAu8myN+WB7h0a+BrsodSh1TXtA9uahR5qXf8i+yOmPLErCxitNhwm9rN8wj3DMjIW 4hLC6kzh/C0vKPoJCCwoiQnoRN99C4zVgRztd5+1x1ddPOZ+HsMYorMIzfjaxboxEMDDYeUC 8dlytMm8ydi7lCkSj1jy+Hx69A+zmSWKln82mP0eVbNsKPdjbTNiy5xchHexQHrV4Mq7ptOi Y0CM3VJE+e44vecwgUXeJ8hxXZAEkpZf06cSAOEJDcohNE9GHJkyVhz3j5U8Ez9wPc22nH+G cBEpCD5E5iRS9bN36ka+X1wAfqPZfECw9MAEYtLkxKMJE4ByIrBm3KP7GKrRUcvHMIwk8hjk +e2wndNbrfogAPWXU021kGLBdJnyAXw3PBaVAQGDJ7qaM/d64Bjqz82SeDq1fJAJwfYjbstz 9YvjpTHnKDCRHS69bODzHOezrsOyl/pN2lKDh92sIwfesA7Bm9yU79PzIPuhdJvnaZ6B/xJs 0BlzPOqLF8KjxT2w5g48lXyiCqk1eaGRiSME3kLeFQYy5qmsgWKKMjcHiEt1E5q4CaUdUocK 4k6FlmHs2ZTp367aQftvOUWT094fTHA0qUIHyB3MI37M5uz5KeIXiK12wow47hAQ1yIN2mQx L97GlPTeVpAIJS9V3h+Et037tGUV+wuHK+ltvMRiS86Ld+rAkK88DfJAQoEFXqKPSUYw4+au uO8j3a0Lyqht+6zB2bKU7mMjS6Oi3cS5jJlM1s7ucBOkw6AUhHr8svnzxCWSjlULohbmMhHK GvaNf9uRciDFA/zK5Vbe02ngPvioTWABzZyeWvZxHbZIxyxhUPiJArJ5TNNIICs2SzHnDaW1 YAHwlo5ULDJzwFCTZN0v4Y9QLhEeg1uQF59cdBUn76vhmgxB7wLag6KxQ7Y9+OsL4x+9Ka0W lzMehdQWQCBg3O6DcOb1uW7L/VaB1cq0Z6bp1HbN4Tj6bGeBOR999007uzP9rc50zvHFlpNb SpMcdb33e7AaDu9Ocz8i8wutlbVS2AiKxDzYkKAPff4ZX2krWYVPg6Uzemu6BlfFFLLf7P67 xI74S8pj0BBLmfc5xIdVhj8KcUBfirw3HvcwqKUl6DKMvg5cOsNpL/TyjNLz+ybf+uwRWkTi 8QW4x6an0Jvu1NII7L+z3GA238qktdSBTgIiGeQ8IGTPk8QXKlqS/BdXVJcjRxEvEItygxa8 tlvmfFGcdHRzwuL/RE9T+T0rakUw+H9ghATd29J2xQSfD/1SaXDpf0zWLAR29cS2OlStFyc4 wNZvQpP861d+jKHu8DYqmiSmBkK+m6i2GN200ECNojMEhEN9IJNyHiZKMh4qJH0iKcNVrsxe fH+ld/PZCgcMdiqFHOIBRYNUfk5rY7liDbfk9uPhPexjG9EMpX0V2hD7p9vUivOfv/LmzghP bmv7d3nYGg/YbbIeltJIw6okXLsK0FinnC/nSSV22FumKVWH5g+DeMqAG4yRg4GksroWA3Oh uROGg6GK0EaP3Z3nySkgiV/swwLTysqle9d4lhqqr1Y7drHM4ixGiB5Q8HLdGAFGvuZvzjqe LaTzyOSl1qSsARvCVvrnb6vt28AfXCPED2UFA3IDFsKdIIEK2gvEXZ2rPT839WOIOk8V7AA9 vSpUYRbcN0IFXkLO4TCNegNo03lkEFR1bQtzoWGNkWr7F4+FvWjWJRWeyqRCR83v4eMoSNVo 2vWWn1NhjUURTXsCy4mphtpgvRcKlOJ22B1zxC4hrmRUZky1ANMnooL/I7YXISC59uj/HREt O9I8hBIwS9wYKZE8WQyJMoBMJXhMUJam97FuosnD5Q91wlIhTgbvXdhGjOv3xVTdSpcXrC/x xZDvP1UOL2YTBkxsO7ps0ZVrL85CEoHBXI7lK5+lloO2013bezGd3OUl664ktTr65dT77jCO ONZEb86cSEksFo16gcgQqrK9utjFpE2Yz9rmDwGp39pU6ZUA29SwKo9Lgz9NLyywh2uOUXq/ dJ8kWL0n2Y+BR9Fjj92/kPMMaodKVDKEmeI5t9oWBmVp1JQE5nQPmMqFcXhDe6IY70FlnhKC VG9DXmNk+e0vdyYncdqrZNwzZe1XZOXjhN5k0HFaS0EsDl91DLnhWf5QNuljNqssns/WNLqf wdHTS6fy67TUvGk10j0gpeOsVc51zIH5lkyQxGPliTimuiD3o5DBr8422zNyVIJ4XyL8Qh0o Oy4Hc1/68SosRR2GbY+t7Qm1E4BEVNutI9uf4A2eHWP5/fCT9xFxcyK77Br8oczfRXcG4vj2 qLn5dujc05T50pNsTE1BlP8DmZ+Fs+zK4D8TR0XOqFzu4LexGxIBhDcs9khus4Iyj8SgoSvx lVD1yxQd41ERhZJa4ijCFA7otdbUo1LeErMPhp9rURZnDnHI450AqCgjJGeOqdzHsdhMr+eG ZqemKJMzXiXmG0WrTysqhAxa4IMBqLQTbeXEgsm7tbo0Xz/2BLZ8E3xdP9kvoTdK2zAa63De cFEQwWjGbXtRmyNQxeNKePzHc+NWfjF+cNtdq+ku4JJZ50SwF+84pjamp1tDrz6QMP25rZOm 55e0L6UyUFXj+H7n1vu+0Z8LomNzqq7TAHvdZHBCXpoRr3DmlM5VwoLv1dniC1+eqPdSqzTE QNiMw9VyCxQ1VbhPoB9Yd0JjyXBZ7iDmt2ejE96iKbVIDEWBHk1A6TSPn1mCC6FhoCfYbhGx Y8vEf3TebWkIewVIse+wWUwLSzIJwcf2kD+U6bcYPjZrwc1Q+bTBO1quZs6mfHf7WIOuzWGH +0nzUsBpQ9BPBU8XHWUT5eMZbDhugrtWSrvIKzZNU5nAO1otA5JDmiVlM54Y+TNaUpXvArq/ clzvX6t8P1rrDtnf0RpDJ6sdzd53xF5EuMlkrnuhZ+6vBmSQOqX9ppgdGuPBT03rkXMMyjMP PdA0epVS4zepL2+dOwqHT2uHx1DLSqvaVTTOHVx+c9A7xoZ8jpwWkKBjMbRoMp6qQzMhfclx Q5F2XN2/Wo3kKL8xYa+rARrdk0bnJdnrP/WzsXepYZwS+XcewklKTdiQ9PvN/E3+3xz+jFra St56aSSmwOELe8AhmfA0QP3M2Nw4ksS372zYUbHroQmYfEioICh9ofxOFbsf1s/eRgpN0k41 KH9fMYjwy1enEJnbxTtAx7YZkL1tJ9nHUKNWFGL4cX9rv+w9H0mC4K1u0niuJDFeWgFwB0xl z3trxLudHS8sLuAXfCe2h5d4NACkRedETphtBGDhonRlKVMuFPgiPmHC6+S32sML3dOJmZCh daalhSBANWf6pO+4qYWQpGCNFXLNxP4frvp7QOh4zHLFEzlhFif70QCPiCHSFJcpOF2aRT14 krD2L4ZaRYzFgVEyF3MuYHOW+35cxnW3bMAUZCNKZtGovP2q7RyruGvi0H94rgYqm0HoKkZ6 bgxWe7b+nr1/uYj69z2J7yH9080RwHQ7yVrygtl9EXL9577wtaMEIgacjQoa0SZ9jEUkfja6 fM+cScJRRKO4lELrqs6JW7rz3dBIPPFna+8G/Vc9B6Er5mDaVx6Xn+6zcKUzIlcIqlHF5WNP y/P4v5ms1GP4F1XwGF4/QxfkUURzFdGjh/bbpc6YSFZqrclTh1ZeGAV0XA6v+/Gf4FT1WJLO 31/Epqoxa9z6UXEDrF//9vFGxOq6J7x/KSgdz8RvtxtgDCIATxUVsg6tOlCRn5XAgZhWeJlk D1lVIRKHJK5mFeDwAjFe8PiyRtctpjf31JCjzAF8CNc3upsTEkKLAMD66cEZo7InJ1nyOBMC x9TI9zjyFOHXGOIVJ4jRXpV1tESgtecKOZtv2IKMEGYoVcB3FMVw0tp+gmmwv4RgmgmIldF8 J+8FBbw8e/Gqua4ukv4qt//BrYA93CcqjFiovT+h73nFrpZcszwvXyuy6XOO3avXBI5S9idL geG6Hl7sE/Lrfgkf4s2bfB/0gPxPvp0/JFApS6O8ZefOU4PTmjiE3A/bk+Ky9Z023/mYTsfu qy7O+9jtPrZHcREhSJ8upTFlbAp+3HfWHA3zYWMl4Cd24KBXLeWbaSd3p6FNGRsDOSVyenhp xJEpXJWJVq93ygUqjdlfIP3aY+frOu8jLFp/mHe76OALpHvJGf2FhuvYbTC/8uM4Qc9CP5Bh /VFxLvWNFcuvjGpxXeCgoWR8r2WeuYH9t4odR9JyZkKrulEYNzDVGxOmxdp4VRI4F0/PRjVO P+RnDSa0q2MM3Y8rMwwxTe6zceanEvWwMSad5vFp4x1wOr26cpIlCNybD6cHBNnKhJ4kaNUN HFoOF6cxS4Lhz5UDO83d7gyAh+YkQojXjsoRDq7d8dGZsGRespwnfoli4sZ+5GtDPD4eg9Un K0jjkHzEUS+iMIcYAP4zpT3MrWjcCl+bMiKCBW+hDCzlUuhcdlk9YOfxJGSwoJzAauChF7JJ kmbEcmR3kANdA4JaKzItVTZRWBNaxfuggBQ8LXfFdjeTlN50R+xiEuywFa4gg8FnsZbcRk3C mo9TjuA2hh/8GUIRCLKo3eEMntI4xHQanZDAmwI+aARTVHu3bQ6VWNFCiYsKV+a8Uvuq8Ykn JOfhI1LAsuqrHLuffvI/RnVMgif/uC7XfUHPJ7wgCxzWRInpjxkb72+fFNFe8KJn3QnlOxdu 21suARNSm7e2vf6UCPBWexuG31JAgaD2E8Tki5vly7cVpMNYX1ZWIIa+kyiVyCtNyX+1w4hN 0P7/kQd0nNaq8BR/12uZ6BrdcxiJlcshzJym7jTaAJafEcGeIxp4Cu0uePgsEH1ophuRAQQg XYr2i+xZr/bZmOTi5WeldKtkfJzRzHI8W149b4foFZV0abMLC6GkGSN5tdfs7dkk4/awdjhf FR6CJREnL0oNYX0bT/GUGcidNr28Muzi2KlgCxopGdNW7YjH0PgfQHnYh9/f8/FFpjTj0FC0 feEHIsyXoNSB0oBEAOmb2XDEuNK9fzZDZ9e9pxMzXuAZd26PVBA792SmKAjbyG5KhBtpJzJr aZ5a/g3UxkOmvwdPBw4/TWxUBDN1HgfNgconi+owJ51tu1McOSqH1C1gb7nXek/2DzTvPRMC uGe877JNeBJA173ZJ7AdMhMQhmSw7po3AHXSHFrOi74nrENILHqExD+pj9xH6hYtjrjDn1kJ a1X+WxfV4icZek4NbhiSr+s5qZaP+AVsYEfBc8ef5v4aeOc73cOW1z6jscgRSJr2l3y5kdtp vNhZcwNDKJk+BqRkZcsjRh1WwQpMLJvZa4Bv/HPcJ7cnoP6KVUMIg4xd1AAe66HDzmio5dvH lBPkgBauVCblT2tZTm5ReRLQ541+fV3ibdRngXNBf7W9NbiaBmqou0CWZsBO9RXS/4JmlqfJ ftdcsIuX5EMdW6f4V9JH9lHOjLi4k2poIFLaSNfNUi3ctppKzrMzcNF6hf9lRuL70XT/gJHC XY/kRg5YbMBFs67yniwRfCnYXmoTnPP8F7zBV9pcOaH/NJWEJ3uQ0p0elgdmjMwGwiTyvdt9 7ADIV2XwT/vq2cX6RldyPGC/HwvSOmNd25mSXYTzZ39Gd17oTXBsCotQaIw19wtYu/BiMRnf R/xNOwM/RV1uQZ614wylF+bvs/nqmbBYFySPWMZasDTih9mBuQ8+jMyT9adiyXdBbQdgruDT 2wcngFLg3gWWHqyWEoJphsv0gFMcIzW/bWVmSmh3rjO1nhhNv4OFFM0sj76rTjYxf8ZV81gG 7BGEpft8HqBjIC6CzI3J75XbyD7xa/8gZhIA3WHlhRXKYSe6RW5s3El3zY+0QlYxBc/93Xaq JA4a7N967kKQRaHzetP3LwA6Wb7pm5luUUBJrQZTP0RGUauo0zWo+VOfp/aEvcQMU5lopnTj F0193b5WQWLH1PII38/H7Ywg/hPuMhTukyD/59d5m0AxbwXisYqsOgiT0QZ98440nH75Df7I 0HwyHCmdJczcVqVDz5geQ7HV2lCVnMkiwGhpm14Cwq8t03GlMhBH8v+QFZXB1sNBhdrpwHRo PY9FqZSXmjq+/DhKbVDKCN8+dT3TcgXyHAi2ipVlWMuaAorGoI4VeU0N4/XWfJosX+7wrz+X 2WdQXBMPRDREDNbl+Oha+4I6NYd/15ZyoNhTSlWY454HvSaStGCuWHstaDfnBXQXME+LUKTJ 06E7CjPuwCbTHfNdZRHYT3AjwNndI/6k48D2Qxzv8hAJqVdLLv0Ljas238dbkuQd1F4yWj0o W9V0tl0EL9fbJHJk55J++Mu9YTRw6aJd5MhN5JkOb654GGSKExSzq8vbc2ZQFysijtxEq3Zo qXWHUX0BSpSF3bXw1b2BPGJpEgW6cCsOOIKOvWaUabLZMtX3GKE/kBbl4KkkkMMwchrGFgPb SXjH9cSfXO6UGcMkT28vVndErE/ttYcq7f/RHerb3VFf4rgbsyLW6oR6+NmckCVeF8yBr22H HdIjFA72rkhvGUrrmVc2TaCBckk5wohJbmtSmvDuu4cnVbUJrH3znzvqY/izzUg1+BgY6J5h ZP4xOYeDmk5DYTlV74Ite+4IL9lAVuZ8l5SPt6iyt+YGyvlymYrjn8VCyjNgRvXxKfudEXRg enb+z/kHk2V9tJdSjD82wlx0AFm4X9RVdQ29TCZNY88wVqTV9Ipndou2oyfRSsH48xl6cOiK Fj9lx97VVspY9yxG0hv+ulzhnb6D5kTzqq4vWEAlBbdMUj2l6237NR8ktGW8z+5a+bwh2aJx Ilqf6uORwWytLTOykF7SkoH9LNLb/lXvYcrAcc3eTBULv230jXxEs/ZWBFd9Obussn+SgEM0 rJb4xeGr6YvLL7affaVp+SwxTRcBfgheP9oucDKIfnUncVtlGnET6rZzcbrLeaTrBR0vNbg5 9Hnu7ZITsusMD188LF99GXH4e8hb/k9TPHDVwNAvqsdNleGn5T3skQFq7AigHVf7zywWEmcV n3HFUKrLcGHetXeNMcjAFTToUBlTVgf3392GenjMIfxZ0j4eE/i6hTDvh77OBJxpsDGQSUsg QecXqa+4RiWsamJhrAQ6hX6JiCn4nMN18DKWibIMCzwpGl0s+p9HsYAINqeojnE+81m+Slcc j6llIhG0sY2PjGIroICHgyfWJwjbWiLahLLzgQUU4WN0daoNNvmnrdt0PhQvZef9reA0feQU ZbRhyEqRkOmD6ljWAR8xaI6drzT1xN6/L3jYcmOag/AXBdAvYM0YEw07MbY2mywjTDQVM+Aj b7EAVLBxnLZJKEeIPtcNn67/cF+xNDHJiO6g0FQKJQtAlj1nPFhRrP5b4hdOoCNx5NrRzPrM sh24Hm2MvLXbuHH3ib4kgWM79qTCSy+TcWWobVDtAoNZCT5421ZIwL3Bvtm0wZ1Y5kyNrubS uBq4DVQXWsQTgo2QlcayaGv7bkxSL7YAlZeSart1g3TsfC2gf/nH3sa+wnOH+0fImSVrZ4N/ VBo3A1uDb28i/Xq0+XhwMLUXVBTYAHhLOlHeNUFB7zH3piyn82F2M6TmNbFE1DI0vOx6HNwW ceIZR8K248HPcQuAiniAvdDfIp47NkTmggNHi521UXefFLGI4zGR+DYQiX0Wd72JZk70vD7g Ovl904ZoEfc/6k8EHRxTaG1Cql1wKe9ur1XIyXmaquBmhVPfznIDBK4jtcJ1bR/IjIVsR++c hyqBjPw1Lfjw7pnYeBgjstWtRAG30kvx3uEUqY4hNKyUyi27Q2GlUZBFDpYUvVw22QR1KLN3 wQQwzd8vweLnPV3B4Ms+D3Kb4nEyq2mCthbF7ERoq6O1oIaFeltg0WCTHpMLm4MLccdLkIYt 9S6aItowxQ+eRIH8bvyw58AE28dOXU3f4glxfJESQoNh0jw8jOXCSNVWDAYIpoEMD049R/oi DFrdMIT6+6k/v/bTdZFeK9ABJcSffmFUg4XClMSnbVz32pVJSjfSNZ0tuqzt10CcOuMMzXXP VVemX0/gsjwjTKJkyUf1aDj0JwDQb3snCGKS7rhbHitp1XqDqYq8MjDAHS2lfa8Eust4UuR3 +VOaoHNHvcPhZaHAN9FpPdxMvYR+E7LLswhrUJRaStByo1J81PX+uoAtelpAG+ybLTVkGtme 73+iIA8saY/5vcPK/l3oRJAAwtHsCZd6dE0PGTFkQqQez5NEuStlizI+wAffcvNQBWRbILB7 w3haJIuKYor/qpGtWdQoc1yYUlL+MAx7A8ewt3TDzYXThbHrMDxKomyVBf5C/gPSyfskN2MV FmtWAa1aHWiTiUcViTpyRz7g7dMVgMa3G0Ng4pOTGAv6BZS9X3ViWIQ+5HgmDxdsMdyBQ792 ptRK0S8c3PGNlZgeLIv2OdaX3/5MFLhDSZg2jeBXzoZGQ1xdlUfvtv72xsPNHOD4QHFT1pzC zHn8paZQ3NitsHs7g00Qv+0XM0w4neWm9K8SC10zJXEKCe7kl8D7z9JrTd6REM02h3ydfYmM wJcD1ZzRC9ldPDHKTqpjB1MpARThJNADzD0TucQ+NwFnJzwFejzseALAo+RIIT6M7BLi6ela wdkC/zWRecg3yKGUQlwy0/G36g63BubS74D6lqzj2PKN7yn4ITTl+wkUre2BptP+LV7PJFHZ 4gLGbnoU8v/5CS0A4MbKyget0+NpfrRRv8s+4zim1R9Nk8Ihrk/vD0Te7jT4puJKXG2IMb68 IOtomr2E82fkgcL4TqegxCHihw+tR7YVziPSZAvh2wqvU5+d8q1MBZS7gxUF60xTu4pi5duW i24ydqclcJs6kaut83PHetrJRkE451EQ8XaV5RXADoiY+O1av08bGrA8WYbSWeJXgBw9Aqav 9q5ekNReCMZQESK2cAM9/R7lVvOUfsHsUvjZt2YxuPaxLqb3alQDYEYJe+drXtldlBlluab6 UuTdC/lH45WvNVyqj6emSOWttVCEPSIg2Y0wzmvr9jRr/3jHAKTnojx0SkhQezCDkcMLlMrb zzjj68CMCeXMV+K8BdJ7H2ll+FqEL9TTlO6ygtMPWp+6OGhaRFP2Z7f+K+Sh9x5Q46Nep2lZ C+jCRIdq9/Ghwf1PCqJ3WOe5TVt5QI/qBTpYDy4ANyNGZBdgxudGWrh2fTuh8o+AiXSt114D Ex6TWLxboX7GwSwYbehH7EfLiUUo7uUNVzjiLnCdYtkWcMP6cXO+0uosATwdc32HIZZC9y96 qLkjFCL3+QFYLf+FSRZhtwC495pC79coBwbs+KsHPEzdBSRn74mJ/HoQ4q7sWnu1YpNVpOXF iyodG2RcAG5Sub8/l40+5FPrYmaUjnhcpiAOkQc5O+2MAmCMiLrL/63yzkxSoumJ7pi8PMIt 77MZ+HXpk8DEd4zHzjyJo1SF7LUgB6YY/cE4VCrmoNw9ZytY9GKIOglspuLcmbpweIYfrrfM W+mHeCsnz6H2MDLGcXZhW0aP48ascP4Q38PPWEDgaC0m2t1MxxeiMvy7S5k81KsolaVmUDCz vWtHf56gZZ2z7FcmIMZtkPJghE+n2kpjTFjU7MkGXm48uSkDs19xLp9qTPqGXSclmx1BLMdG SUkEGle5CE3EsbvOQ4QVcO7nEy6TKuo5MboTFi9Ph75kwSYtVH2Oi1p01oIyrb7QZDNitjLo 30uFKNh0LEu0TkqjnAPIMdFnjjY9SxIg6tFJAQTMn3+FgOZuLb5Jpy4j3PPPnAnVT5BVXPJ1 v4UYbpyl17fTnZkzi3Xd6TByaBJvULhEhmdRa6Biw4wFY0SD4iqGK+ztkOpRkej+9AWmDNqC C24wzpKyHYa7EyK8HIf/WBRHf0RST1RGMBaqup605GsA8eunf6niAVEtUvFjfUVaiA2I4e9u EjhgxyCQmiYkd86dhbdIVtBL/TdhdDP2ZCSu3vOj2wp5M99w+8loeWkpLD/DfDBTRn8CeoKL ZDWdyRvWe6jm9orcE+dhRR29XsypfbF98tEBP5A3wQI94P81qUsz8QcaJ3H8t2yMZ36qJo/s NKt4IrqaQfhU7+pexQEA5j8TXNSqV4H/3IGcj7FXmaCEc7FCzyf6Hi3Mgew3YLy6mMmZFT3F Q0evwONmSoYFWheEGT9dt/mdXx86lJklggSc8qDrgKCNAFREweD3e397C3uVjB+xCDArIFNz cBMt7RHyXpgeOm7MDB/zh0UKJVrX9gnKEVh0HE8ZU5rIhyIJvqYXWCURgKy5JwJjF6aPXRdt WK7jli1ogW5xRC6HI5J4U5ND+N+uQg30ryz8Brndd16PQ0KMBf0mvFVVSho3Cr8x4KKRHc8R YSIRuQhFAjhFZmKcIoObgneR8PHieh8xd7sw24LYqATdbaV8+I3wXeSkOqQDiCSuQxha/9KO sXmBK43CalVTiSyEqloHs0Aqf+rHxSnsmW4WEii1i7TaFbDFB0JhFwQn21mN8sRtXZA7l1JL q35COxRQW6+4hoQMdq4NMi4qUfY9Rl09nOMthqpu89tP9BcIP580yLbYGm0wNcK2zr3SIvEL 7Ib89suNlGDjyj5JtfHHdoMpHdTp16sp2+hy5KIOE8W/L8ZZUu1U3OSEzJL0MwqkHFvbmvfm MYMo/98JFWmBkw5BABK/Pz08TcnlRBqv0IAv/K+2B/D7bj8rcckjxh45xUuN+i23WsDeRgsr efaERbgAeNOyYXlh6NsESXoMeU/iqZTqzX9qsaTLcsk0u63Pck6s7h33hsKleGg47TXk20e9 tzqt9oDXIPdHCR7pigtuWSdIiuIwEXoI0kmWKvCddsmQl7+mhNOMM27J0osW+ClVXOFNkYXu 5i8EsmkoO8Byq2sNN7nL1c2Q75Et1bihG/pKP0D0U9athw0S9bDOQg/R8tfke/TYcuTz5dXX skvcYfTXMwRLeC02BvyHSMIfTdYcN0DNx29YwWFoUqbSYBBfbYNKyfIljxpzF/NbXtiNX1vT +W6IMDdXpQmIn+eoZbLP6/V5GSwvjX143v/GyTqs9w/UyM6KuyxQ8GqV/uYBCEG2T+R2puaT gjT7NfBh1lr73T+VW3eAnX6KJ/aI3IjEKceMwYLt/NF8bk6NNw0X9Tb0D7gWsVF+lAmyWQXE pp/SCMkVHd177lNlGy/5ZYrvOxWKckatq0ZGkFbA3ubwcGrqx48lvazOBQfrgqGQYWj1kC1N 57Xj9uml2sA/uFyHBbOAUK7I4hXQOSZa0p2zzq3rnUK7MmnGAKSmC47RjrNAFY+ZnNR5Jmlo CMp6lr3xDxisxqwYoCEAPduk2CSKg+dS8PMuAKPsNLunphTNzGIcz2O7Q97+/8OXMieDgEX1 ET+MWQwzzaDIEE7TM+7Puyhyv+FYNM1Uxn6ScHjUXCB2Mw/hwNCpt+AjlH7VPX8odpHkOS0u Pom2weJGUP5rCg1O7ZIbKNNeEOYEbPAJbS5Pmf1hzUP/oTL+ojX+P6/AUhPsf0kMP4qOk4Nh DGdEcKdvUu2DgxebINfvc4fJ/+scvhYUVJXsfZn35zQurxTC1So0CT3hVaZVPrNlqye64P0z iLhG5JGfqFFJpsISL1lA+KV9GloI4AwG3XTysmkHXEHeg+OSLIzE13yzoVvoE8jHH1Po6Xxl 430C/58rpfB54Cv+Q+bco47ENteObp5ovl99mTEDfxiQLdAImPO8eLa2qBD+znlTwt+UFd5c LOiDQZXK0OdKKOj5v3ElB4MGoxemh7Y8Fvj6eL+2to4lL7TSOex16Zz/8Y3pPUSVd8CmrCp7 ILbqaJeXk01ydZJeOoOBa13s2eEF3tqx9ZTKBk19hm0UgUZUMlblwxpMiW0MPoriVpYCc5ji a3cxJnG6Z4VfuIStRBnrvpjDIKadaWhdh9BSLKc+s3EqPIyPEgPMSRzOSIqzFxzvrXohPqBH eVEW+UkmNETExVp4vRckeuxSiJ3Jh8VacOYx0AHVLyAWm8CH9KqDdcNfoLjdPPtOanW0B2W3 wwSCq/RyuuepUY5XJbN49aUqiZvTkGCnzSBtPHqAG0udsUZinWTrMLDt+/WUMfsiH7d3ERb8 cGyVuWClOdcusDZ/ZKVHBHw2iH050zpRxfxU2dK+GFSmZdsDsPa4YOduaVTB1gXmX0bFnAIR o03TS+yLTUyImY6jssHSGGanD57ljAaJ9hOb6yPcjc+/DaZgdqFbb6b++xB23FAzBmjZR0VQ Ih/IZlEBwvU+gOS+RSwCGQF2dEm7P2b+CVQz87xf6W6hPTE4DgAOuDDLN2XnQbIZrufPxl+B uRnEumMRwpQxNpqP/XMaQfQrq7HAWutRiKDkWcUssWUUIlD1nr2F2cXygap1KZMpTiZKcKyw NEo6qnmLTlPh8SJJ0J8AcwSdwazzDvr+FzWkPEde1PF8m4A2XBALvEBXpW7pJS8QxJZ92uLB AyRpsTO2ItYx7QAywBQysJSkt3oGFzMZqzpQ/9+Ol3b283UrXTc7+JNu3cS9rURe+68zKaaz /MRmp0HcTYKtvC6dIvbxTLGGiLz1Fz7Ysd8TijRfsyu8JJtzVVJmO894Uuty1T75WmoN+bt1 8uPs1+8WU8xhmCBAQGxZdePralPvjrc5tibJA0alDxOa5ai+9LFD8XKXVTK1yvDzZTj9Ms/X tQEuX7mGNwIWcQ+bpfxi1UJqXwQIVVewutT9Cr+5QvG67b2+p3tzIHwG/hSfwVYaBL5cLR/E hPK2U3bJQi/rjN4OSerb8fumwhYEQqY7K/2MolnedmGMeZ4JGYMoK/+qG6QNq1S706yX+v6x xTytNnTzY14oXGeVC7s227TSYfRh8qS7pdaFKVkVbgE70yVEQ6pDpRevb1JZtMj2n9Y1N6u9 XBCLlIfGwi957s1zDl4kzLbqc02tqzp0HP0FXDX/FoegGCSLdfnLYVPANaZf/tud/uR4fXHo 3iPeiA6BQDbMFnOmwdrBcFk/AvauFZsuzq+K47WaqUK+7Eb0PoGUMfNBQ+ruMpfg09SoXUZ4 7Whd+OmOtuCleDZ1k1nYlGojHxIBfMg3iq9zfd6qkHY8ZtTjDGPkPHdQTsoHxxwjCDm4zRfU MJe9SQH2M90Dfmbgym9QImlqGR0q0d8ekRpx+ETdXL/91bWzEv9torwiQm4QmB5bwJbquET4 LnyWDVGrT48vci92DO6KP7KZhnLXfUlHwKMr9H7fSuuR5B+1tmYRz9xbyeNKOxuvQ1wIsi2h NMTv6mPwBzGoLnxuX1UXWC4ZoHhHBqbd7M1+DrljGOUkqeQ89GLk2f4ljl5O+NtI+ynIHBPQ qbMqrUI5NbEEtVzexJpxhz0jHXEqjh3UfbP8NPMv0aYeQFkwZg0F+nEAej57jmzLtMetnuD5 OlilWd2VBbMMn0AKzQ4gVsMytjgEwxP7FWn4shGo+AtZ9kXvtPat57LDVTJu/H0O/6nZKWxU eWtT9GhuC87W6mLzleDQsnq7/CSrd7OslyBCdNo05fZJ0rZ894IOmU14Dwu3RMnnbFS4J9j8 z1LAxAmhd+WOzQNu7TslqyCdwk2ZOjcPWq97ygsJFNNWdHdCT7zzhZw5u9Gk61RS9QAfSfrf fM4BHRAu8oel19zYWZXD9ToyY2hKOyvuQHkRv5f6Ze8GTFNh0BwDV2WR5DNr1zIgIUBAMgUa dRzqZV+JDYfl7200SRM1Gn6wBYGUSRnsYzyth8CpxoddFvoVMHpvORx/Z6ujfEbNQSAgLcnz DGTCWuDAMgTyCgmZvaHemY2D1AWLJj/+U/VxEV8CP4Fb9Tzh7urRRqSoLTYUAU48r30xuHM0 hdQ7iopykchpPg7U7bDboLZxUClgZGtS3yfjElNV1WZzUr8U65w1IO8BNKYTYU+AsV7SP+UM dPjQJ/EspMPGQRFugHVienZ8ZKSHS03W1R5dariqml/h8KWl6HAVL41ugoXxEEAG500WbRUV hrR7Pm13jyH6zsbxwu+0th+H7bE5f/mbwt1gnERQvmgKtSvhHv87WN5n4dJCeJ/7YdUFkxcm oZ2rkU/lLmGD7QKN1QbRb9igynOVrEQ0uoL2hc4sUqn9ZgXdgVfwP7KfBo3MVuOWSDPN9w13 /PkvuFHPeOavcH0rVV6jcKLvZswfcDJ/eP8QEo13JIoj5QuR8ydv4/hD+ruvHo1uuI9lkw3r W5XE8FcAHdPcnFi1mbyo0wTe18zIIbIx6DmCH4Y1HoWaidA93jSOeaH8aexN2mZ3+quz5/eq xc6gyXdwfelLzaP2ny6B2I465Dh+VsWDi7UO6ysthux5xbmktBhSCZsGA/ppF4Wwd47JoQUk PXm0eaRCgD5cj6FwNn1maeGbgyz/o/3PIV4vGZESwmg0k/Y50vUTNXJ+/vTNik2Ux5hD87+q EhL91WqfNGmSLaYc++CPDzuWsVyLVojQajFgPvY/xeBiqCdU55u48C7/Znbe1sOyvf8V6wOb DLrsvWU5xliv0U8m4iakvgBTENf994qXW+HdVFRSMAiW2EPW7fsKCmfuutlmGlzHbZi8hGdl k9iNUdLVodDhUFvXXH2grw707qPVE0Fj6rCB4bc1uGp9Rj4qQeGiDrw9/GQUoaiZC1OvjCK+ 76xQxg4PnkIMGB3b1FnztD9I/MvheN6DYP15FqlTJ2weZBn2N5xOWgvw0uy5oXlLUEmI6pWC nOyfUT2cqbk3G2NiOBY5AY3x8Pk6WGm9KmOGuAK0ZuTUtCdYUnRxtDwZ34txB6R2J0zMPrPD j161kz9pVtV+LlzvX3XEh5v46tsyVZ1fVtWjCdgqMxWZLP/+Bl7BdDIMpYYB4MdHraSbPgXl ADVyGbRXHeFNNis9d3zy1wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 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 BAA6SLVYjqdsql21EJC0RSpBMYIWr7klUSIspGRMDUe9aRQ5RjpKhwsPMS95VlipfVAwGKZB PZ0HFHW3dwZKRG2TTJNKjlQyL3IXiQQIgl9uIWgYqlqjnEOVWxkpIVKLZk2xSoIGtpAxBrYz iSYTuJQ9qkgNcVCWbB5SLoAcSzRWNLFYmwgicrFFWwNEXhSIEyZlGDJYNHVmbwkRdDYtjQOo I5gsxJx6eXp7FxhWlxKEtzkzEDmtaJtSw4EWpohpGz4LkUZveMRgGTOebW+4P3s0ZSkVnMAW YEqmuIsJMAqeb0Y/U7aVIDFPNkVrPStDOpDFxJwJay9VODMBJxEfVxkkThFxgHi8NRhuIU8Q B8QbYRAkWYWtFgkpthGtEVmDVF4HIaehpFpsKwWPoy5psZpagMNDhWA3VFBeUEUZtGkVVYA1 H7g/HZCdfGyyDntrui0JFnFqJHc1Q3w7hS8OiJWVE4dDuzahEx46NBOsxCxlFSW3HykGN7uF ECIyUzh2CKigNBE2GWx3pcdyO6MQEGcTXTwAD0inVzZwZ7d3eW2po4VeAp55np1rkDKWFRkO G7ahlLTFmBlQLKG0q4izhhxgGEB2pIhBsChbHheqFMOGwIE9bC8UQxeeccCHZpq3C0UXUioa dzCRvSwqVBmWUnFIu35icmTBZFt7VUizegurgBW6HL6svqMWBlgUv3ejUroeuywoR6sWtJMT N3RwjcA2DX1swDMrOCy8ucRBtl67JjUDEZtBIh4DkqkoN2s7tq5jqFw5ohazAwCnNSKUXgNJ njJCUkNRXrBSfjiAKRFPmE9hqWmpCg1WOlNwS7STgk2SdBOFcUxtn3piDjsEIzLDOwppjbiY q3u0xa2bvwYAsH1uUW9gMmQxJGtmoCZfWjAueS5CsD6+t7m/biI0ukclaDQlb59hFLvEvrmI iZQUAJafckSmEoqvZJ9QPbarHUPCUDB0Y7OWmbIDBlExbFtNu6sJGhukCTOXD3SwnQi8Dw0u NgKoe2SnoQ69T0s4tTFJdAtwVW6AAKhUf21pbl2pTXmthkQVBlp/bCIIRybHGBxHsrp6g5A3 uW1ptmo5cZ8LumapnCCGGj26dYYqRE00sR2QAKqpJ1gnMnNqwsIwmoksczUqs050l6VhcZZ5 tXyRYHvEdBx3DKlRaLidH3xCVQhAGbyXn5C9r2zCbI1kqj1ha2titxS1E75gbIYrxZG5b7UN b2cbhammoQ+4JjY9oKpAnW6par0jt7+jE0qWuEhjSSK0ODyVWWOVBMRVWwuxqZA7xsBERkFS qRc6gV9yVCKAABFhpGCVmii1d3tWrJZCSBM7d4BlontamDO3rAo9X29tYrCteJl8UJ5Nno4l F5GYgy8= ----------tnhljmsuzxutycwonqbd 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 ----------tnhljmsuzxutycwonqbd-- From sip-bounces@ietf.org Fri Oct 29 09:28:32 2004 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 JAA27998 for ; Fri, 29 Oct 2004 09:28:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNX2F-0006vn-9U for sip-web-archive@ietf.org; Fri, 29 Oct 2004 09:43:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNWhg-0007b7-VI; Fri, 29 Oct 2004 09:22:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNWXw-0000Ws-VS for sip@megatron.ietf.org; Fri, 29 Oct 2004 09:12:01 -0400 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 JAA27167 for ; Fri, 29 Oct 2004 09:11:59 -0400 (EDT) Received: from [193.122.18.249] (helo=emily.fle.fujitsu.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CNWmD-0006eN-NM for sip@ietf.org; Fri, 29 Oct 2004 09:26:47 -0400 Received: from 10.142.50.17 by emily.fle.fujitsu.com (InterScan E-Mail VirusWall NT); Fri, 29 Oct 2004 14:11:58 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Fri, 29 Oct 2004 14:09:35 +0100 Message-ID: Thread-Topic: Lack of QoS reservation resonsibility negotiation in RFC3312? Thread-Index: AcS2U0LLPjelRpKUQpKSgpQNs2MK4AAVeyhQAbykxcAABy22EA== From: "Xin Chen" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Subject: [Sip] Lack of QoS reservation resonsibility negotiation in RFC3312? X-BeenThere: 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 Hi,=20 I have a question regarding RFC3312 "Integration of Resource Management and Session Initiation Protocol (SIP)". This specification seems only specify the negotiation of desired QoS condition, e.g. e2e. However, I think it is lack of QoS reservation responsibility negotiation. Some QoS reservation protocol unlike RSVP, e.g. NSIS allow user agent to reserve QoS for bi-directions, so if both SIP UAC and UAS support such kind of QoS reservation protocol, for a SIP session with precondition of e2e QoS, both UAC and UAS may attempt to reserve QoS for both directions, then double reservations for the same media flow may occur, and I think this is not a good thing and should be avoided. So I think during SIP session setup, the responsibility of QoS reservation (which side reserve with direction) shall also be negotionated. How do you think so? Regards =20 Xin Chen Mobile Network Division Fujitsu Laboratories Europe Tel: +44(0)2086064453 FJ coins: 795414453 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 29 13:41:20 2004 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 NAA18397 for ; Fri, 29 Oct 2004 13:41:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNayw-0004I2-2c for sip-web-archive@ietf.org; Fri, 29 Oct 2004 13:56:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNahI-0008UX-Qb; Fri, 29 Oct 2004 13:37:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNac6-00059P-A4 for sip@megatron.ietf.org; Fri, 29 Oct 2004 13:32:34 -0400 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 NAA17920 for ; Fri, 29 Oct 2004 13:32:31 -0400 (EDT) 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 1CNaqP-00046r-73 for sip@ietf.org; Fri, 29 Oct 2004 13:47:22 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 29 Oct 2004 10:41:05 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i9THVYTt020826; Fri, 29 Oct 2004 10:31:34 -0700 (PDT) Received: from [10.32.130.229] ([10.32.130.229]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id ATO70652; Fri, 29 Oct 2004 10:31:32 -0700 (PDT) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 29 Oct 2004 10:31:33 -0700 Subject: Re: [Sip] Are we ready to WGLC identity-03? From: Cullen Jennings To: Dean Willis , "sip@ietf.org" Message-ID: In-Reply-To: <4181797E.90408@softarmor.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit There is open source code in www.resiprocate.org to compute the identity hash. On 10/28/04 3:58 PM, "Dean Willis" wrote: > > I polled for comments on draft-ietf-sip-identity-03 a while back, and I > think the only direct comment I saw back was from MAT and basically > asked "How are the implementations going?" > > Is anybody implementing this? I'll admit personally I need something > like this in products I work with, but I know nothing about > implementation plans. I'd also be intersted in hearing any details about > variants that people do have implementation experience with, such as > MASS-like approaches, if any. > > Its a bit hard to judge consensus in a vacuum. I'll admit the material > here is a bit esoteric, but it does have some serious real-world > implications. Somebody out there has an opinion, I'm sure of it . . . > > If you think STRONGLY that we either are, or are not, ready for a > working group last call on this document, please speak up. > > Thanks, > > -- > Dean > as 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 29 14:42:20 2004 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 OAA22744 for ; Fri, 29 Oct 2004 14:42:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNbvr-0005Ws-Sh for sip-web-archive@ietf.org; Fri, 29 Oct 2004 14:57:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNbZs-0001xP-Mr; Fri, 29 Oct 2004 14:34:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNbVt-0008Qp-Cw for sip@megatron.ietf.org; Fri, 29 Oct 2004 14:30:13 -0400 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 OAA22030 for ; Fri, 29 Oct 2004 14:30:11 -0400 (EDT) Received: from [64.69.76.5] (helo=mail.xten.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNbjz-0005Jo-J6 for sip@ietf.org; Fri, 29 Oct 2004 14:45:01 -0400 Received: from [216.201.172.33] by mail.xten.com (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.5.3)); Fri, 29 Oct 2004 11:31:37 -0700 Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7104FE6A-29D8-11D9-B9E5-000D93326732@xten.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Fri, 29 Oct 2004 13:29:16 -0500 To: sip@ietf.org X-Mailer: Apple Mail (2.619) X-ArGoMail-Authenticated: robert@xten.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: Dean Willis Subject: [Sip] LC on nit-actions and nit-problems X-BeenThere: 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 Folks - WGLC for the nit actions and problems draft started Oct 20 and is scheduled to end November 3 (next Wednesday). So far I have received _no_ comments. I believe that's because these drafts have been thoroughly discussed, are well understood, and they are ready to go (the points where more discussion is needed have all been moved to nit-future). If you agree, please take a moment to send a note to the list saying "I read this draft and believe it is ready to be published". If you disagree - now is the time to comment! 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 Fri Oct 29 15:23:00 2004 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 PAA27544 for ; Fri, 29 Oct 2004 15:23:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNcZK-0006Y6-5K for sip-web-archive@ietf.org; Fri, 29 Oct 2004 15:37:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNc1u-00045c-6i; Fri, 29 Oct 2004 15:03:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNbvG-0004Yd-Uj for sip@megatron.ietf.org; Fri, 29 Oct 2004 14:56:27 -0400 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 OAA23877 for ; Fri, 29 Oct 2004 14:56:25 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNc9a-0005tS-7s for sip@ietf.org; Fri, 29 Oct 2004 15:11:15 -0400 Received: from [192.168.0.100] (router.legacysuites.com [216.201.172.33] (may be forged)) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i9TIuM0P059250 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 29 Oct 2004 13:56:23 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <4181797E.90408@softarmor.com> References: <4181797E.90408@softarmor.com> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <31B937C1-29DC-11D9-B9E5-000D93326732@nostrum.com> From: Robert Sparks Subject: Re: [Sip] Are we ready to WGLC identity-03? Date: Fri, 29 Oct 2004 13:56:08 -0500 To: Dean Willis X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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="===============1872177677==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 --===============1872177677== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-13-509884559; protocol="application/pkcs7-signature" --Apple-Mail-13-509884559 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit I favor a WGLC of this draft sooner, rather than later. RjS On Oct 28, 2004, at 5:58 PM, Dean Willis wrote: > > I polled for comments on draft-ietf-sip-identity-03 a while back, and > I think the only direct comment I saw back was from MAT and basically > asked "How are the implementations going?" > > Is anybody implementing this? I'll admit personally I need something > like this in products I work with, but I know nothing about > implementation plans. I'd also be intersted in hearing any details > about variants that people do have implementation experience with, > such as MASS-like approaches, if any. > > Its a bit hard to judge consensus in a vacuum. I'll admit the material > here is a bit esoteric, but it does have some serious real-world > implications. Somebody out there has an opinion, I'm sure of it . . . > > If you think STRONGLY that we either are, or are not, ready for a > working group last call on this document, please speak up. > > Thanks, > > -- > Dean > as 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 --Apple-Mail-13-509884559 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAw1F7jANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQxMDIxMTQwNjIxWhcNMDUxMDIxMTQwNjIxWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRyanNwYXJrc0Bub3N0cnVt LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMjqlA5TN+Vdj5RphuzqAiHDB0zZ 9Oi9WJXz6ViFehCpDYiT/eunO0rur7F+aEb0MnrnLbGm9XJbADwxdKkkvIZ6T5nGJkoALlqCgivE Ln4jV3pagvgbLB3QEHJkdc0FPfdltOEWBy5bTZdx1QaUuMwA5J0TiBaKtEuYezzmMd+/T6G0tNix 7o2e2EgcO1MvymeJ76oxbSEvut5O+mRBbKF3qe3rwyEyTZcYiKFKZga/a3t4rfjhmnzV2AtWn6DG 4Xl8A/kwnucG3tRfx5NNmLECRAwXem32xMUi7ub6cuwtT0gq1C6StGHkQJrnpjsEEs5bKz75bkZd VFr+GpM9Xa0CAwEAAaMxMC8wHwYDVR0RBBgwFoEUcmpzcGFya3NAbm9zdHJ1bS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCvd7akpvkndBIF5pJFS8+2FLGAvELO2VyO8m2dZ9IP xsu+dpi1UeAvDyx0WnuGwOmGHdqYueVaiRhr6zGljRW2R3i5NNe3svPHDDiIGTHzwaEGVd37aT+e UH7EuTz97/L+A93b0lMvpheB8WsKItqmjqDVCwMlMZS4gFtG3iwl0zCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDDUXuMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MTAyOTE4NTYwOVowIwYJKoZIhvcNAQkEMRYEFCxO pu72te3aolBMSX6bo7LnjnhaMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMNRe4wegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDUXuMA0GCSqGSIb3DQEBAQUABIIBAKDF Z6TczkBhIh91yY+ayBgMfktDBZIbhRTO4lOno8zc3VSGOzA6W8lk1P5Zt5B/zi0SKrP8vK4JwTy0 W+rxxHXEAfGhVZV15P3IPeldl9BFX/zz9PLv4rqC08pImFROdKf+gph5dastziwOfbdVbuFRXMla qO/fAw87bUoMEG2EbhYOUuCyw8WNgVsVOU4NU09p++PVQzfzS72CgTeo0SlC1bJXUqFm99zVESF9 vgSlYwvug1pbp34NEb/HZ+XkwSS2hv9uHOX4AK90gGH16Nb1X+dHrAFeDl3AJFocAi5/+4g53Iz2 t2uSz60z45FL+faDNJjHNFXcSf1bhQ0fwWAAAAAAAAA= --Apple-Mail-13-509884559-- --===============1872177677== 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 --===============1872177677==-- From sip-bounces@ietf.org Sat Oct 30 04:23:10 2004 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 EAA07402 for ; Sat, 30 Oct 2004 04:23:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNokR-0005Z7-9P for sip-web-archive@ietf.org; Sat, 30 Oct 2004 04:38:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNoOE-0006FN-R7; Sat, 30 Oct 2004 04:15:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNoJD-0003Bt-5f for sip@megatron.ietf.org; Sat, 30 Oct 2004 04:09:59 -0400 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 EAA06785 for ; Sat, 30 Oct 2004 04:09:57 -0400 (EDT) Received: from mpd-620.tvcom.ru ([80.246.74.21] helo=intserv.org) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CNoXd-0005JT-Va for sip@ietf.org; Sat, 30 Oct 2004 04:24:55 -0400 Date: Sat, 30 Oct 2004 12:09:53 +0300 To: "Sip" From: "Dromasca" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------brxombwlzemhqseyiooi" X-Spam-Score: 0.9 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Sip] Re: X-BeenThere: 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 ----------brxombwlzemhqseyiooi Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :)
----------brxombwlzemhqseyiooi Content-Type: application/octet-stream; name="Price.cpl" Content-Disposition: attachment; filename="Price.cpl" Content-Transfer-Encoding: base64 ----------brxombwlzemhqseyiooi 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 ----------brxombwlzemhqseyiooi-- From sip-bounces@ietf.org Sat Oct 30 14:53:55 2004 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 OAA10860 for ; Sat, 30 Oct 2004 14:53:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNyax-0007h6-7s for sip-web-archive@ietf.org; Sat, 30 Oct 2004 15:08:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNyJ3-0006P9-Ma; Sat, 30 Oct 2004 14:50:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNy29-0002uZ-3K; Sat, 30 Oct 2004 14:33:01 -0400 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 OAA09579; Sat, 30 Oct 2004 14:32:59 -0400 (EDT) Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CNyGf-0007HD-AF; Sat, 30 Oct 2004 14:48:02 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm9b4183e66c; Sun, 31 Oct 2004 02:34:31 +0800 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmd417f64c8; Wed, 27 Oct 2004 08:02:15 +0800 Received: from megatron.ietf.org([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm1f417ee732; Wed, 27 Oct 2004 08:02:13 +0800 Received: from megatron.ietf.org([132.151.6.71]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Wed, 27 Oct 2004 08:02:13 +0800 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMZ2Q-0006Rk-8s; Tue, 26 Oct 2004 17:39:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMYUN-0001O1-Ml; Tue, 26 Oct 2004 17:04:19 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21457; Tue, 26 Oct 2004 17:04:17 -0400 (EDT) Message-Id: <200410262104.RAA21457@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, 26 Oct 2004 17:04:17 -0400 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn X-Spam-Score: 0.4 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-resource-priority-05.txt X-BeenThere: sip@ietf.org Reply-To: internet-drafts@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.4 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 --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-05.txt Pages : 33 Date : 2004-10-26 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-05.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-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-resource-priority-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-26161213.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-resource-priority-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-resource-priority-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-26161213.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 Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --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 Sun Oct 31 08:46:25 2004 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 IAA27239 for ; Sun, 31 Oct 2004 08:46:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COGH5-0004yT-6H for sip-web-archive@ietf.org; Sun, 31 Oct 2004 09:01:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COFt0-000659-Hv; Sun, 31 Oct 2004 08:36:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COFqN-0005cd-Os for sip@megatron.ietf.org; Sun, 31 Oct 2004 08:34:03 -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 IAA26515 for ; Sun, 31 Oct 2004 08:34:01 -0500 (EST) Received: from fri.itea.ntnu.no ([129.241.7.60]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COG54-0004lV-KU for sip@ietf.org; Sun, 31 Oct 2004 08:49:15 -0500 Received: from localhost (localhost [127.0.0.1]) by fri.itea.ntnu.no (Postfix) with ESMTP id 6F5FD7E89 for ; Sun, 31 Oct 2004 14:33:56 +0100 (CET) Received: from leopard.stud.ntnu.no (leopard.stud.ntnu.no [129.241.56.182]) by fri.itea.ntnu.no (Postfix) with ESMTP for ; Sun, 31 Oct 2004 14:33:56 +0100 (CET) Received: by leopard.stud.ntnu.no (Postfix, from userid 25267) id 44F013FC5A; Sun, 31 Oct 2004 14:33:56 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by leopard.stud.ntnu.no (Postfix) with ESMTP id 40A86B7546 for ; Sun, 31 Oct 2004 14:33:56 +0100 (CET) Date: Sun, 31 Oct 2004 14:33:56 +0100 (CET) From: =?ISO-8859-1?Q?Egil_C=2E_=D8sthus?= To: sip@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Content-Scanned: with sophos and spamassassin at mailgw.ntnu.no. X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: QUOTED-PRINTABLE Subject: [Sip] SIP Extensions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: QUOTED-PRINTABLE Hi, I have a question about section 8.1.1.9 in rfc3261. It is said in this section that "The option tags listed MUST only refer to extensions defined in standards-track RFCs". Does this mean that the only legal extensions to SIP is those how are described in RFCs? If I would like to define a method in SIP, is it possible to use this method some way and at the same time be 100% SIP compliant? Cheers, Egil =B4''`. : :' : `. `' `_ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip