From sip-bounces@ietf.org Thu Jun 01 00:59:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlfFl-0002C2-FA; Thu, 01 Jun 2006 00:57:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlfFj-0002Bx-Rp for sip@ietf.org; Thu, 01 Jun 2006 00:57:47 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlfFi-00076f-I3 for sip@ietf.org; Thu, 01 Jun 2006 00:57:47 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 31 May 2006 21:57:46 -0700 X-IronPort-AV: i="4.05,195,1146466800"; d="scan'208"; a="1816826007:sNHT32679512" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k514vjSq020326; Wed, 31 May 2006 21:57:45 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k514vjIs014920; Wed, 31 May 2006 21:57:45 -0700 (PDT) Received: from [192.168.1.2] ([10.21.82.39]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 21:57:45 -0700 In-Reply-To: <447C45F6.60907@cisco.com> References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <447911C5.7050805@softarmor.com> <17529.15626.334110.853151@rautu.tutpro.com> <200605290322.40468.dean.willis@softarmor.com> <1148929672.17999.5.camel@niagra.pingtel.com> <758F0645-1076-44CB-8121-05C921B9B335@cisco.com> <447C45F6.60907@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <66C72342-79D2-4D0E-879C-FA1BE4EEA506@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: Wacky thead of the month award goes to ... Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Date: Wed, 31 May 2006 21:57:43 -0700 To: Michael Thomas X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 01 Jun 2006 04:57:45.0668 (UTC) FILETIME=[EC0E1840:01C68537] DKIM-Signature: a=rsa-sha1; q=dns; l=2269; t=1149137865; x=1150001865; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20Wacky=20thead=20of=20the=20month=20award=20goes=20to=20...=20Re= 3A=20[Sip]=09draft-audet-sip-sips-guidelines=3A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3Dd8aUGDr85fleDPPciN1KWeI/Bqk=3D; b=JrvVLPL7LBrtOaHiSHpuEX/CP2tlVvg/K9Hup1ezRmvh/UehsGg07wrKVZK0Yw49lIfhonrU 3kAW6gJGDOU/3WIrbK3ca86Ne5jdy/jtPu4brBC1U5dh0F0+0372otKq; Authentication-Results: sj-dkim-7.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Excellent question (definitely falls in my not wacky category) On May 30, 2006, at 6:17 AM, Michael Thomas wrote: > Cullen Jennings wrote: > >> sips is not the answer to every problem. > > My question is whether it's answer to _any_ problem. My last > attempt at > getting and answer was fruitless. What attacks do SIPS thwart in > real life > that honest operators and transport=tls doesn't? Real life good > guy, bad guy > situations would be helpful. > > Mike I agree with your comment that as long as people can't say what they are trying to accomplish, saying sips does or does not meet that is pretty meaningless. The problem with transport=tls is that it only applies to one hop and has no semantics that it get applied to the retarget. If it did, then it would mean about the same as sips. I think it is fairly clear there are cases where you want to make sure each hop is confidential protected and it is reasonable to trust the proxies. Let me provide a simple example. In several cases we end up using the to and from tags as cryptographic tokens that can be used for authorization. For example, the typical way an INVITE with replaces is authorized to replace an existing call is that the new INVITE knows the to and from tag of the old call. sips can provide a way to stop some attacker on the network form leaning these. (or just learning what 1-900 numbers I was calling ). It's pretty easy for the UAC to control the protection on the first hop. However, it needs a way to signal that the future hops are also protected. SIPS is used to signal that. Now you could argue that there could have been several other ways to signal this and I would agree. But I think there are plenty of practical threats where you can show that being able to signal this, and assuming proxies did the right thing, you can stop the attacks with this. An alternative design would be just say all connection MUST be protected. (Forgive my use of protected here, I understand how imprecise I am being but I think you follow what I mean). Then you would not need to signal that future hops needed protection but people were not willing to accept that for all case. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 01 01:02:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlfIZ-0003qu-Vk; Thu, 01 Jun 2006 01:00:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlfIX-0003kF-SO for sip@ietf.org; Thu, 01 Jun 2006 01:00:41 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlfIX-0007iM-A8 for sip@ietf.org; Thu, 01 Jun 2006 01:00:41 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 31 May 2006 22:00:40 -0700 X-IronPort-AV: i="4.05,195,1146466800"; d="scan'208"; a="286617765:sNHT109871438" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k5150erC012847; Wed, 31 May 2006 22:00:40 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5150ecL022870; Wed, 31 May 2006 22:00:40 -0700 (PDT) Received: from [192.168.1.2] ([10.21.82.39]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 22:00:39 -0700 In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F0FBD@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB594017F0FBD@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: Wacky thead of the month award goes to ... Re: [Sip]draft-audet-sip-sips-guidelines: Meaning of sips Date: Wed, 31 May 2006 22:00:37 -0700 To: Christer Holmberg ((JO/LMF)) X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 01 Jun 2006 05:00:40.0029 (UTC) FILETIME=[53FB78D0:01C68538] DKIM-Signature: a=rsa-sha1; q=dns; l=5487; t=1149138040; x=1150002040; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20Wacky=20thead=20of=20the=20month=20award=20goes=20to=20...=20Re= 3A=20[Sip]draft-audet-sip-sips-guidelines=3A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3D8h2wwaVc9nz9a5STVtxlDPmH4os=3D; b=Jq7spA7vq2ac2vrNtdfRDRJTtYyCdsMBBSYXakIoxJXLdUwb0lKNexfP7pCedcNltk90muQb 2c1nL593JJDUyJv89VFQYxTfD3jbvMmujZqst+C+pWQotEEiF+2Tv9m+; Authentication-Results: sj-dkim-6.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This suggestion is certainly not in the wacky category so my apologies for the subject line :-) What you are suggesting here may have possibly been a much better design than what we have. There would be several advantages (like being able to specify more about the level of protection). The issues with it were that we were passing URI around between things. Take a REFER for example - now I suppose that you could embed the requires into the URI but in practice theses don't get processed. A contact getting copied out of one dialog and into some new dialog. A subscribe that sets up a notify. There are many examples. There was also the questions of what level of granularity we needed to be able to describe the level of protection. I think the feeling at the time was that one very rough cut (reduced to a single bit) could work for many things given the transitive trust assumptions that were intrinsic in any security based on hop by hop. The questions we are at now is, given the choices we made, would it be possible to even change this. The backwards compatibility issues are not so much the places were we did something specific for a URL but all the places that we allowed URL to be copied we would need to think about how the protection parameters associated with them got copied. I'm not saying that this path is not worth thinking about it - perhaps we can figure something out along these lines. On May 30, 2006, at 4:04 AM, Christer Holmberg ((JO/LMF)) wrote: > > So, what you are saying: > > sips:brian@neustar.com > > = > > sip:brian@neustar.com > Require: integrity-and-confidentiality-protection > Proxy-Require: integrity-and-confidentiality-protection > > ? > > If so, and if people have problems with sips, and what it really > means, > why not then simply define an option tag to be used in a > Require/Proxy-Require header? > > Regards, > > Christer > > > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: 30. toukokuuta 2006 8:03 > To: Sip > Subject: Wacky thead of the month award goes to ... Re: > [Sip]draft-audet-sip-sips-guidelines: Meaning of sips > > I plan to very seldom sends emails with my AD hat on but I think I > will > make an exception for this one. This may be a learning experience > for me > in trying to provide some of that "Steering" part of the IESG role. > > sips is not analogous to https or the lock icon on a browser. When > firefox puts up the lock icon, some of the things it tries to mean is > that you are connected to the website you think you are connected and > your data in encrypted. > > sips was never meant to imply that you were talking to the person in > your To header field value or that your RTP is somehow encrypted. It > does not solve either of those problems. We have several working > groups > in the RAI and Security area that are working to provide solutions to > these two security issues and others. That sips does not provide these > does not in any way mean that sips should be deprecated. In many > situations, sips provides a very powerful security primitive that > protects against several things. Many of these were brought up on this > thread. > > I would like to point at one in particular. Imagine the hypothetical > case where Brian has a phone at Neustar and trusts Neustar, and I > have a > phone at Cisco and trust Cisco. Using sips for a call that goes from > Brains phone to the Neustar proxy to the Cisco proxy and to my phone > provides a surprisingly strong system for many attacks. Note that > Brian's proxy found no need to route the call through an AT&T proxy in > the middle. Now Brian and I might not want to use this signaling > channel > for things that we did not want Cisco or Neustar to know about but > this > channel could help secure many things that were reasonable business > items between Cisco and Neustar. In this case, sips can help be a tool > that can be used to achieve the desired security. For communications > where I would not trust Cisco or Nuestar, we will might use AOR at > domains we trust for that purpose - like our own domains. > > I think that at the high level, the semantics of sips are simple. We > want it to mean that every hop from the UAC to the UAS was > integrity and > confidentiality protected at a reasonable level assuming transitive > trust. This can be very useful. At the more fine details level, we > have > some parts that are unclear in how to implement it, we probably have > some bugs in the spec, and perhaps we even one place where we made > a bad > choice that we may correct. I'm very keen on this draft - I want it to > try and sort out the details that are missing or wrong. > > sips is not the answer to every problem. Note even 3261 had S/MIME and > we have done Identity, SRTP, and many more. However SIPS is a useful > tool for creating security solutions and we should sort out any > missing > details. > > Cullen > > Now bring on the rotten vegetables. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 01 01:02:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlfIu-0004LZ-0Y; Thu, 01 Jun 2006 01:01:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlfIr-0004LU-R6 for sip@ietf.org; Thu, 01 Jun 2006 01:01:01 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlfIq-0007l4-HR for sip@ietf.org; Thu, 01 Jun 2006 01:01:01 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 31 May 2006 22:01:00 -0700 X-IronPort-AV: i="4.05,195,1146466800"; d="scan'208"; a="1816827761:sNHT37693324" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k51510HA012964; Wed, 31 May 2006 22:01:00 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5150xcL022936; Wed, 31 May 2006 22:00:59 -0700 (PDT) Received: from [192.168.1.2] ([10.21.82.39]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 22:00:59 -0700 In-Reply-To: References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <447911C5.7050805@softarmor.com> <17529.15626.334110.853151@rautu.tutpro.com> <200605290322.40468.dean.willis@softarmor.com> <1148929672.17999.5.camel@niagra.pingtel.com> <758F0645-1076-44CB-8121-05C921B9B335@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: Wacky thead of the month award goes to ... Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Date: Wed, 31 May 2006 22:00:57 -0700 To: Dean Willis X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 01 Jun 2006 05:00:59.0639 (UTC) FILETIME=[5FABB870:01C68538] DKIM-Signature: a=rsa-sha1; q=dns; l=1965; t=1149138060; x=1150002060; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20Wacky=20thead=20of=20the=20month=20award=20goes=20to=20...=20Re= 3A=20[Sip]=20draft-audet-sip-sips-guidelines=3A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3Dd8aUGDr85fleDPPciN1KWeI/Bqk=3D; b=Yjb40HAXH45wlTaKjSiGJeFADgcKDmxw+PexMNadPoCKG0M77R8BAS1vaeIBKY+wbGCcnMhM mCs3SCCRWzIoQOwjn5/4ukR4fe6ZHYRhh49BueXfvJPTEQCMIfZGepDn; Authentication-Results: sj-dkim-6.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On May 30, 2006, at 2:35 PM, Dean Willis wrote: > On May 30, 2006, at 12:02 AM, Cullen Jennings wrote: >> >> I think that at the high level, the semantics of sips are simple. >> We want it to mean that every hop from the UAC to the UAS was >> integrity and confidentiality protected at a reasonable level >> assuming transitive trust. This can be very useful. At the more >> fine details level, we have some parts that are unclear in how to >> implement it, we probably have some bugs in the spec, and perhaps >> we even one place where we made a bad choice that we may correct. >> I'm very keen on this draft - I want it to try and sort out the >> details that are missing or wrong. >> > > > "Correcting" the "bad choice" in the proposed way would be counter > to the semantics you give above. > > It's been proposed that we should change RFC 3261 to require that, > if sips: is used, then TLS MUST be used on all hops. This runs > afoul of architectures where some other mechanism, notably IPSEC, > is used on some hops. > > If we make this proposal a requirement, we end up in in a situation > where we frequently cannot use sips: on the UAC to serving-proxy > hops because some other security mechanism is used on the back side > of the serving proxy. And since sips: is the only "please secure > me" indicator we have, this means that we have no way to request > any security treatment at all in this situation -- in short, that > we're requiring people to NOT secure some links. > > This doesn't sound particularly rational. Yes, the key thing we might want to change would be what happens on the link from the callees "home proxy" to to the UAS. We could decide that on this link sips means a) some unspecified secure things b) tls c) tls or ipsec Right now we have a - I suspect that we might want b or c. I think this is one of the key issues we need to sort out. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 01 01:03:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlfJI-0004jC-MR; Thu, 01 Jun 2006 01:01:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlfJG-0004ix-NT for sip@ietf.org; Thu, 01 Jun 2006 01:01:26 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlfJF-0007n9-Cy for sip@ietf.org; Thu, 01 Jun 2006 01:01:26 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 31 May 2006 22:01:25 -0700 X-IronPort-AV: i="4.05,195,1146466800"; d="scan'208"; a="286618367:sNHT32232220" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k5151Ohn021869; Wed, 31 May 2006 22:01:24 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5151OcL023135; Wed, 31 May 2006 22:01:24 -0700 (PDT) Received: from [192.168.1.2] ([10.21.82.39]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 22:01:24 -0700 In-Reply-To: <200605301424.k4UEOsx19165@smapp01.siteprotect.com> References: <200605301424.k4UEOsx19165@smapp01.siteprotect.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: Wacky thead of the month award goes to ... Re: [Sip] Date: Wed, 31 May 2006 22:01:22 -0700 To: fwmiller@cornfed.com X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 01 Jun 2006 05:01:24.0499 (UTC) FILETIME=[6E7D0E30:01C68538] DKIM-Signature: a=rsa-sha1; q=dns; l=1461; t=1149138084; x=1150002084; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20Wacky=20thead=20of=20the=20month=20award=20goes=20to=20...=20Re= 3A=20[Sip]; X=v=3Dcisco.com=3B=20h=3DDsd3VkNwyreufX5qwkOBOWvXhnE=3D; b=HgHL3T/oWckyTzYumqAvKq9+Re/op8trAcuA1mQTaOW+SgSOvlfIvcf0MgNkaq/uRkvIGm9V xZPE0MfEOsY3VvAC7LGLjRl5ECMa0HhcQFWZiJMSuOQlRQsyCjUVOXR2; Authentication-Results: sj-dkim-7.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I certainly agree we need to deal with some end to end problem - the raisec mailing list and several other WGs are trying to figure out ways to make the keying of SRTP media work. I will point out that in 3261, the solution for end to end is not sips but is S/MIME. We have been trying to deal with issues around S/MIME for a long time. Part of this has focused on making certificate management easier and cheaper. The Identity work has provided close to end end type integrity without S/MIME. We have been looking at SAML for certain types of assertions. We defined AIB for certain types of end to end assertions. On May 30, 2006, at 7:24 AM, fwmiller@cornfed.com wrote: > > > This is a nice encapsulation of the capabilities that are there. > While I agree that depracating sips is probably not useful, its > also clear IMHO that something needs to be put in place to allow > for end-to-end secure signaling. If sips can be morphed simply to > do that then lets do it. If it can't, lets forget about sips and > figure out a way to solve the end-to-end problem. > > The end-to-end problem is hard given the basic architecture of SIP > but is also the problem that once solved will really boost the > usefulness of SIP in general, again, IMHO. > > FM > > > ------------------------------------------------ > On Mon, 29 May 2006 22:02:51 -0700, Cullen Jennings > wrote: _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 01 01:03:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlfJN-0004nL-MQ; Thu, 01 Jun 2006 01:01:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlfJM-0004nD-9F for sip@ietf.org; Thu, 01 Jun 2006 01:01:32 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlfJK-0007nZ-W4 for sip@ietf.org; Thu, 01 Jun 2006 01:01:32 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 31 May 2006 22:01:30 -0700 X-IronPort-AV: i="4.05,195,1146466800"; d="scan'208"; a="286618420:sNHT32245968" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k5151UDk018384; Wed, 31 May 2006 22:01:30 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5151UIs016146; Wed, 31 May 2006 22:01:30 -0700 (PDT) Received: from [192.168.1.2] ([10.21.82.39]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 22:01:30 -0700 In-Reply-To: References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <447911C5.7050805@softarmor.com> <17529.15626.334110.853151@rautu.tutpro.com> <200605290322.40468.dean.willis@softarmor.com> <1148929672.17999.5.camel@niagra.pingtel.com> <758F0645-1076-44CB-8121-05C921B9B335@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: Wacky thead of the month award goes to ... Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Date: Wed, 31 May 2006 22:01:28 -0700 To: Dean Willis X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 01 Jun 2006 05:01:30.0296 (UTC) FILETIME=[71F19B80:01C68538] DKIM-Signature: a=rsa-sha1; q=dns; l=1637; t=1149138090; x=1150002090; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20Wacky=20thead=20of=20the=20month=20award=20goes=20to=20...=20Re= 3A=20[Sip]=20draft-audet-sip-sips-guidelines=3A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3Dd8aUGDr85fleDPPciN1KWeI/Bqk=3D; b=Z7a+uT+3uFqyVyaAxxaIm5xHuIhf1H2Ssi7Jw28ayG1m9Fjj0tR8zUfrHAbEzes9maAihvE0 rUSg3APki3PhsdeRudbuSR6W1YJ5aZJ5w7cGx1PrG22kt8D8TAbDK2xm; Authentication-Results: sj-dkim-8.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org this reply is not really all that relevant, I don't know why I am sending it but I will :-) On May 30, 2006, at 2:35 PM, Dean Willis wrote: > But in any case, sips: remains only a marginal indicator of > security. It's kind of like a note by the door of the office that > says "Last one out, please lock the door". If somebody forgets, or > choses not to, the door isn't locked, and nobody else knows. Most security is only as strong as the weakest link and often no one knows when the weakest link has failed. I don't know why you use the word "indicator", if we think that sips is somehow a indicator to end users that they get something like an end users might think of as "secure", then clearly sips does not provide that. > It's not the lack of security that gets me -- it's the lack of > KNOWING that there is no security. Our current usage of sips: is no > more secure and generally applicable to the Internet than the trust- > domain protections around the privacy of P-Asserted-Identity are, > and we made that a P-header. I think there are some significant differences here. RFC 3325 requires that you have contracts between two parties that are using this (the SPEC(T)) or you can be in violation of privacy laws in several countries. There is no case where you need a contract between two domains doing sips. It true that you can only trust things in so much you trust the person you contact. That is the nature of communications - just because you can perfectly encrypt your email to me does not mean I don't print it out and pin it the bathroom wall. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 01 01:21:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlfbE-00073I-3M; Thu, 01 Jun 2006 01:20:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlfbB-0006no-EA for sip@ietf.org; Thu, 01 Jun 2006 01:19:57 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlfYO-0000S8-H2 for sip@ietf.org; Thu, 01 Jun 2006 01:17:07 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 31 May 2006 22:17:04 -0700 X-IronPort-AV: i="4.05,195,1146466800"; d="scan'208"; a="286623927:sNHT32411712" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k515H4iP026508; Wed, 31 May 2006 22:17:04 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k515H3Is019682; Wed, 31 May 2006 22:17:03 -0700 (PDT) Received: from [192.168.1.2] ([10.21.82.39]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 22:17:03 -0700 In-Reply-To: <447E28E8.7000304@cisco.com> References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <447911C5.7050805@softarmor.com> <17529.15626.334110.853151@rautu.tutpro.com> <200605290322.40468.dean.willis@softarmor.com> <1148929672.17999.5.camel@niagra.pingtel.com> <758F0645-1076-44CB-8121-05C921B9B335@cisco.com> <447C45F6.60907@cisco.com> <447C5294.9010107@lucent.com> <447CCACA.10501@cisco.com> <953beacc0605311614g40618ac8n6ca6ab25069fd419@mail.gmail.com> <447E28E8.7000304@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: Wacky thead of the month award goes to ... Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Date: Wed, 31 May 2006 22:17:01 -0700 To: Michael Thomas X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 01 Jun 2006 05:17:03.0808 (UTC) FILETIME=[9E5C3C00:01C6853A] DKIM-Signature: a=rsa-sha1; q=dns; l=1323; t=1149139024; x=1150003024; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20Wacky=20thead=20of=20the=20month=20award=20goes=20to=20...=20Re= 3A=20[Sip]=20draft-audet-sip-sips-guidelines=3A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3Dd8aUGDr85fleDPPciN1KWeI/Bqk=3D; b=tFKYKEv07KBzEe0TpnwT7SneT3xM/qeyXU2PN5gUPrcmg6ldq8NKgwag5DuDv/Ncvwon/EbB Bj9O7OOhOgkX3ncwDKulU0WUjW/u/ARYySpdjMeEVN5AtANmen+bYlfw; Authentication-Results: sj-dkim-7.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Sip , "Vijay K. Gurbani" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Agreeing with Mike here.... Hypothetically, if we were going to write a BCP that said described when a phone should display a "lock icon" to the end user, well that would be a useful document to have and clearly it would not be the same as you display this when you have a sips URI. My personal opinion is that we don't quite have all the building blocks in place yet to be able to do this yet. We have tls, sips, srtp, and Identity, but I think we need a little more on the SRTP key negotiation. On May 31, 2006, at 4:38 PM, Michael Thomas wrote: > You're undoubtably right -- I've been wondering about this -- so > let me say that > my problem is with anything that supposedly dictates security > beyond what the > next hop is but cannot be verified by the would be dictator. > > Barring end to end security of some form, anything that purports to > elevate the > authenticity and/or confidentiality of the signaling is bound to be > misinterpretred, > and that's what sips real sin is. If this is really a BCP -- which > I'm becoming > convinced is the only way to reasonably sell -- not oversell -- > this desire, then > we should work in that direction. Signaling for security that one > has no means > of verifying is just plain dumb. > > 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 Jun 01 01:30:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlfjM-0001ib-DN; Thu, 01 Jun 2006 01:28:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlfjK-0001ga-BM for sip@ietf.org; Thu, 01 Jun 2006 01:28:22 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlfjI-0000xI-SP for sip@ietf.org; Thu, 01 Jun 2006 01:28:22 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Thu, 1 Jun 2006 07:28:19 +0200 Received: by S4DE8PSAANQ.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Jun 2006 07:28:19 +0200 Message-Id: <85108216918A984C8C60172D7C84770A08A518@S4DE8PSAAGO.mitte.t-com.de> From: "Jesske, R" To: pkyzivat@cisco.com Subject: AW: AW: [Sip] Connected-identity and changing the To header field ina response Date: Thu, 1 Jun 2006 07:28:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: fluffy@cisco.com, sip@ietf.org, john.elwell@siemens.com, roland.jesske@web.de, christer.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul, in the past we lookes also on the Reply-to header. But per definition = it is the address where the user want to be connected. So it is not in = each case the real conected identity. But the COLP (TIP) service could = be used in the same way. So if it would be possible to use Reply-to header in Responses, if = people are willing and we as TISPAN can narrow it then only to the real = connected identity (within our walled garden service definition) I = would be happy. Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Gesendet: Mittwoch, 31. Mai 2006 17:04 > An: Jesske, Roland > Cc: fluffy@cisco.com; sip@ietf.org; john.elwell@siemens.com;=20 > roland.jesske@web.de; christer.holmberg@ericsson.com > Betreff: Re: AW: [Sip] Connected-identity and changing the To=20 > header field ina response >=20 >=20 >=20 >=20 > Jesske, R wrote: > > These are the requirements we already expressed in our=20 > draft draft-jesske-sipping-tispan-requirements-02: > >=20 > > REQ-TIP-1: In addition to any network asserted identity,=20 > it must be > > possible for the callee to indicate in a SIP=20 > response an > > additional identity where the user is=20 > reachable for future > > direct communications. Note that the=20 > requirement refers > > to the user, not to the same instance of the=20 > User Agent. > > REQ-TIP-2: The identity mentioned in REQ-TIP-1 must be=20 > formatted as a > > SIP URI [2] or TEL URL [3]. A translation=20 > between SIP URI > > and TEL URL by the network is not requested. > > REQ-TIP-3: The identity mentioned in REQ-TIP-1 is=20 > considered an end > > user supplied information that is not asserted by the > > network. > >=20 > >=20 > > As you can see we do not need any authenticated identity in=20 > the response. For the authenticated identity we are using the=20 > P-Asserted-Identity. So we have two identities in a Response. > > For our purposes the user provided identity in a final 200=20 > OK response is sufficient. So that avoids confusion within=20 > forking cases. >=20 > I haven't been paying close attention to this. What header are you=20 > planning to use to carry this callee provided identity? >=20 > The Reply-To header would seem to be appropriate for this=20 > purpose, but=20 > unfortunately, according to table 2 of 3261, it is only=20 > allowed in INVITE. >=20 > Paul >=20 > > Roland > >=20 > >=20 > >=20 > >=20 > >> -----Urspr=FCngliche Nachricht----- > >> Von: Cullen Jennings [mailto:fluffy@cisco.com]=20 > >> Gesendet: Montag, 22. Mai 2006 17:32 > >> An: Jesske, Roland > >> Cc: John Elwell; sip@ietf.org; Roland Jesske; Christer=20 > >> Holmberg (JO/LMF) > >> Betreff: Re: [Sip] Connected-identity and changing the To=20 > >> header field ina response > >> > >> > >> > >> On May 16, 2006, at 7:07 AM, Jesske, R wrote: > >> > >>> John, > >>> it is that we don't can get an connected identity within=20 > the final =20 > >>> response of the initial INVITE. > >>> Your draft proposes a mid dialog request for getting this=20 > >> information. > >>> That is not usable for the TIP service. > >> I think this is part of what I am not understanding. What is the =20 > >> requirement here? > >> > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 01 01:49:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flg1o-0005Dg-TD; Thu, 01 Jun 2006 01:47:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flg1m-0005D9-PM for sip@ietf.org; Thu, 01 Jun 2006 01:47:26 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlfwU-0003vD-Nm for sip@ietf.org; Thu, 01 Jun 2006 01:42:00 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 31 May 2006 22:41:58 -0700 X-IronPort-AV: i="4.05,195,1146466800"; d="scan'208"; a="286634378:sNHT32644640" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k515fvot030665; Wed, 31 May 2006 22:41:57 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k515fvcL004496; Wed, 31 May 2006 22:41:57 -0700 (PDT) Received: from [192.168.1.2] ([10.21.82.39]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 22:41:56 -0700 In-Reply-To: <6E74F7E2-57E7-4A72-B4EC-383686B2E4DC@nostrum.com> References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <447911C5.7050805@softarmor.com> <17529.15626.334110.853151@rautu.tutpro.com> <200605290322.40468.dean.willis@softarmor.com> <1148929672.17999.5.camel@niagra.pingtel.com> <758F0645-1076-44CB-8121-05C921B9B335@cisco.com> <447C45F6.60907@cisco.com> <447C5294.9010107@lucent.com> <17532.42511.131915.278909@rautu.tutpro.com> <6E74F7E2-57E7-4A72-B4EC-383686B2E4DC@nostrum.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <42B83C30-4B78-486C-BEA7-DBB16A819703@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: transport=tls vs 3263 (was Re: Wacky thead of the month award goes to ... Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips) Date: Wed, 31 May 2006 22:41:54 -0700 To: Robert Sparks X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 01 Jun 2006 05:41:56.0983 (UTC) FILETIME=[185CA870:01C6853E] DKIM-Signature: a=rsa-sha1; q=dns; l=887; t=1149140518; x=1150004518; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20transport=3Dtls=20vs=203263=20(was=20Re=3A=20Wacky=20thead=20of= 20the=20month=20award=20goes=20to=20...=20Re=3A=20[Sip]=20draft-audet-sip-s ips-guidelines=3A=20Meaning=20of=20sips); X=v=3Dcisco.com=3B=20h=3DTQHEBoJDvvVSh/sj37s2GPexA8I=3D; b=gMWyZTX/O+53XQRFZWEDz6p4tEyZMJOgdOTBQk1e7dtjFvNyuir5pdPMLWFW+tOhAn7nmshm 78D3QEAL5nippk+EtVyhSXdktW86FOTtSqPdy8XhfSVil2Vwtw505xvd; Authentication-Results: sj-dkim-8.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Sip , Juha Heinanen , Michael Thomas , "Vijay K. Gurbani" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On May 31, 2006, at 7:35 AM, Robert Sparks wrote: > There _is_ a way to tell the next hop to use TLS (or whatever > protocol) > using 3263, so "next hop" probably isn't the real motivation for > the continued > existence of transport=tls in the wild. Agree with what you are saying but want to point out there are two sides of the connection. Hop A is forming a connection to Hop B. Hop A might prefer no TLS, prefer TLS, or require TLS. Similarly with B. B could express what it wanted with DNS. However, A can not express it's reference using DNS. A could have a some field that the application passed down to the stack that told the stack what A wanted set up but I think some people found transport=tls a convenient way to pass this "tls required" flag along with the URI and let the stack figure it out at the bottom of the application. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 01 01:49:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flg22-0005JN-Ay; Thu, 01 Jun 2006 01:47:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flg1z-0005GG-Jn for sip@ietf.org; Thu, 01 Jun 2006 01:47:39 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlfpK-00028f-DK for sip@ietf.org; Thu, 01 Jun 2006 01:34:36 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 31 May 2006 22:34:34 -0700 X-IronPort-AV: i="4.05,195,1146466800"; d="scan'208"; a="1816843222:sNHT33567380" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k515YXUO022921; Wed, 31 May 2006 22:34:33 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k515YXcL001884; Wed, 31 May 2006 22:34:33 -0700 (PDT) Received: from [192.168.1.2] ([10.21.82.39]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 22:34:33 -0700 In-Reply-To: <200605311938.k4VJcox30249@smapp01.siteprotect.com> References: <200605311938.k4VJcox30249@smapp01.siteprotect.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <86855B33-B51F-44D9-A496-3552EB05872C@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: End-to-end security (was RE: [Sip] Re: Wacky thead... Date: Wed, 31 May 2006 22:34:31 -0700 To: fwmiller@cornfed.com X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 01 Jun 2006 05:34:33.0587 (UTC) FILETIME=[1013CC30:01C6853D] DKIM-Signature: a=rsa-sha1; q=dns; l=3295; t=1149140073; x=1150004073; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20End-to-end=20security=20(was=20RE=3A=20[Sip]=20Re=3A=20Wacky=20t head...; X=v=3Dcisco.com=3B=20h=3DIIs4Yt+z1UwhpDveyC2B4WgU/U0=3D; b=okfhBId/aWC5+5v0NfJIHvK+cFGq60+Bvz602HtoP6zX0yOkvlXDOzb5NDjw/FW+3AzY7Y91 UHNrhj2bGd6IDU0RzxzieeWtwYeYt6CIJRBhQD8hrNiE/QAxNxY0qfPX; Authentication-Results: sj-dkim-6.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Sip , Paul Kyzivat , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org First some bad news - It's rough to figure out how to protect from evil proxies. If you start as an assumption that a proxy is needed at all because it is going to make a routing decisions that the UAC can't make itself, then if the proxy lies about this you will get misrouted. There is not that much you can do about that - perhaps query multiple independent sources for the routing decisions and compare answers. Theoretically interesting but not sure how practical that would be - might be more practical in the p2p work. But now the good news - when you consider the possible attacks, you are unlike to use an evil proxy and it might turn out that the harm caused by misrouting was not all that bad as long as you knew you had been misrouted. What you would like to make sure is that if you did happen to end up connected to the right person a) you could tell you were connected to the right person b) you could have encrypted media to them that the evil proxy was not able to decrypt c) you would know if anyone along the path could decrypt your media. I think this is achievable and though we still end up trusting the proxies in certain ways such as routing, we don't have to trust them with everything. There are probably several ways we could achieve this but many of them tend to end up looking like SRTP with some sort of DH mode for keying and some secure verification of DH fingerprints that end up binding the fingerprint with the identity of the users. On May 31, 2006, at 12:38 PM, fwmiller@cornfed.com wrote: > > > Thinking a bit more about this end-to-end thing, I thought I would > float an idea that has probably been proposed before... > > First, it seems like the interposition of proxies as a basic > architectural element is a non-starter. What I mean is, if there > are proxies in there somewhere, you can probably make an argument > that the proxy could be compromised. If the signaling has to pass > through the proxy, you cannot guarantee end-to-end security. > > If you grant that, then an INVITE must go from the UAC to the UAS > directly. The question is, how do you make that happen? How do > you guarantee to the caller that the INVITE is not traversing any > proxies along the way? > > I'm wondering if there can't be some kind of end-to-end mode for > signaling? Let's say that a UAC wants to make an end-to-end secure > call to an UAS. Perhaps the UAC could query a presence service for > the actual endpoint address of the UAS. Perhaps we could add some > presence bits that tell the presence server that a UAS is at this > address for direct access and then when the UAC queries for the > UAS, it gets that address. > > If this were done, the trust would be changed to trusting the UAS > and the presence server. Is that better than trusting the proxies > during hop-by-hop signaling? > > FM > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 01 01:52:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flg4m-00069e-5F; Thu, 01 Jun 2006 01:50:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flg1r-0005DY-72 for sip@ietf.org; Thu, 01 Jun 2006 01:47:31 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flfv6-0003jx-6v for sip@ietf.org; Thu, 01 Jun 2006 01:40:33 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 2FEE513FFE9; Thu, 1 Jun 2006 08:40:31 +0300 (EEST) Received: from rautu (polymer8.gprs.dnafinland.fi [62.78.110.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id F1CBE13F917; Thu, 1 Jun 2006 08:40:24 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id AF7A1F03C1; Thu, 1 Jun 2006 08:40:25 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17534.32201.383240.611714@rautu.tutpro.com> Date: Thu, 1 Jun 2006 08:40:25 +0300 From: Juha Heinanen To: "Rohan Mahy" Subject: Re: Wacky thead of the month award goes to ... Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips In-Reply-To: <953beacc0605311616j241bcdacy22ffca7ae712636d@mail.gmail.com> References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <447911C5.7050805@softarmor.com> <17529.15626.334110.853151@rautu.tutpro.com> <200605290322.40468.dean.willis@softarmor.com> <1148929672.17999.5.camel@niagra.pingtel.com> <758F0645-1076-44CB-8121-05C921B9B335@cisco.com> <447C45F6.60907@cisco.com> <447C5294.9010107@lucent.com> <17532.42511.131915.278909@rautu.tutpro.com> <953beacc0605311616j241bcdacy22ffca7ae712636d@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Sip , Michael Thomas , "Vijay K. Gurbani" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Rohan Mahy writes: > On the contrary Juha, the SIP server role can indicate it wants to the > client to use TLS by including the appropriate NATPR and/or SRV > records. for clients, proxy usually supports all common transport modes has NAPTR/SRV records for them all. now if another proxy (e.g. trusted peer) talks to this proxy, it may want to FORCE transport to be tcp+tls, and thus adds transport=tls uri parameter to the request-uri before it gives the request to the transaction layer for processing. -- 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 Jun 01 01:52:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flg5O-0006PJ-JL; Thu, 01 Jun 2006 01:51:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flg5N-0006OO-28 for sip@ietf.org; Thu, 01 Jun 2006 01:51:09 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flg5J-0005ic-ON for sip@ietf.org; Thu, 01 Jun 2006 01:51:09 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 31 May 2006 22:51:05 -0700 X-IronPort-AV: i="4.05,195,1146466800"; d="scan'208"; a="286638521:sNHT31276800" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k515p52j027985; Wed, 31 May 2006 22:51:05 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k515p5cL006814; Wed, 31 May 2006 22:51:05 -0700 (PDT) Received: from [192.168.1.2] ([10.21.82.39]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 22:51:04 -0700 In-Reply-To: <1149083614.458.3.camel@niagra.pingtel.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F02600951@esebe103.NOE.Nokia.com> <1149083614.458.3.camel@niagra.pingtel.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0EAB4C3B-8ECD-4D59-A08A-B43A13D77691@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] "backup" outbound flows Date: Wed, 31 May 2006 22:51:03 -0700 To: "Dale R. Worley" X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 01 Jun 2006 05:51:04.0927 (UTC) FILETIME=[5EF646F0:01C6853F] DKIM-Signature: a=rsa-sha1; q=dns; l=1263; t=1149141065; x=1150005065; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20=22backup=22=20outbound=20flows; X=v=3Dcisco.com=3B=20h=3D06m5Q4sco+Btrp7jeR3i5iM36Yo=3D; b=PfzVWgaoU3RxsSa3+Cni1rSrqSkoXdcvq0BPbCV/FS8xCmmZernDdIr/BvXLc/uDRADtQNOO NO5rBDwrJzo2so9rtdAxiFhCJI5YkK6zqrgSfHUL332LJmFhdywi6cbP; Authentication-Results: sj-dkim-6.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On May 31, 2006, at 6:53 AM, Dale R. Worley wrote: > > Well, that's a different problem than the one I was asking about -- > namely, is it worth the effort to *maintain* two flows? One could > establish a backup flow at the time that one discovers that the > primary > flow has failed. (Which has the advantage that one can with certainly > choose a proxy that is working at the moment of need.) The only > disadvantage is that it takes time to establish the second flow. The > only reason that one would want to have the backup flow pre- > established > is that the setup time is longer than can be tolerated. > > But I've never seen anyone say that they've determined that the setup > time is too long to be tolerated. I've never even seen anyone > *assert* > (with or without evidence) that the setup time is too long. We just > seem to be progressing with the design, taking that for granted. As well as the avalanche restart issues ... the problem is not so much the time to set up a flow as it is the time to detect flow failure. Say I do a some sort of keep alive to the registrar every 15 minutes. Now if the registrar dies somehow, it might be 15 minutes before I detected it and set up a new connection. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 01 01:54:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flg6d-0007W5-7n; Thu, 01 Jun 2006 01:52:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flg6c-0007W0-Ef for sip@ietf.org; Thu, 01 Jun 2006 01:52:26 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flg6a-0005s9-LL for sip@ietf.org; Thu, 01 Jun 2006 01:52:26 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 18DAC13FFE9; Thu, 1 Jun 2006 08:52:24 +0300 (EEST) Received: from rautu (polymer8.gprs.dnafinland.fi [62.78.110.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 5E14713F917; Thu, 1 Jun 2006 08:52:17 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 229B7F03C1; Thu, 1 Jun 2006 08:52:26 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17534.32922.74282.205800@rautu.tutpro.com> Date: Thu, 1 Jun 2006 08:52:26 +0300 From: Juha Heinanen To: Cullen Jennings Subject: Re: transport=tls vs 3263 (was Re: Wacky thead of the month award goes to ... Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips) In-Reply-To: <42B83C30-4B78-486C-BEA7-DBB16A819703@cisco.com> References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <447911C5.7050805@softarmor.com> <17529.15626.334110.853151@rautu.tutpro.com> <200605290322.40468.dean.willis@softarmor.com> <1148929672.17999.5.camel@niagra.pingtel.com> <758F0645-1076-44CB-8121-05C921B9B335@cisco.com> <447C45F6.60907@cisco.com> <447C5294.9010107@lucent.com> <17532.42511.131915.278909@rautu.tutpro.com> <6E74F7E2-57E7-4A72-B4EC-383686B2E4DC@nostrum.com> <42B83C30-4B78-486C-BEA7-DBB16A819703@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Sip , Michael Thomas , "Vijay K. Gurbani" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen Jennings writes: > Hop A is forming a connection to Hop B. Hop A might prefer no TLS, > prefer TLS, or require TLS. Similarly with B. B could express what it > wanted with DNS. However, A can not express it's reference using DNS. > A could have a some field that the application passed down to the > stack that told the stack what A wanted set up but I think some > people found transport=tls a convenient way to pass this "tls > required" flag along with the URI and let the stack figure it out at > the bottom of the application. thanks cullen, it is this A preference thing that i have trying to explain in my messages too. today transport=tls is the only way known me on how to indicate it. if no other means exists and since there is a clear need, we need de-deprecate transport=tls officially or make it less ambiguous as transport=tcp+tls. -- 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 Jun 01 02:12:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlgOL-0005Te-HO; Thu, 01 Jun 2006 02:10:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlgNS-0004wJ-J1 for sip@ietf.org; Thu, 01 Jun 2006 02:09:50 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlgDR-0006SN-TY for sip@ietf.org; Thu, 01 Jun 2006 01:59:32 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 31 May 2006 22:59:29 -0700 X-IronPort-AV: i="4.05,195,1146466800"; d="scan'208"; a="286641963:sNHT74091234" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k515xTHL021866; Wed, 31 May 2006 22:59:29 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k515xScL009464; Wed, 31 May 2006 22:59:29 -0700 (PDT) Received: from [192.168.1.2] ([10.21.82.39]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 22:59:28 -0700 In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F0260098C@esebe103.NOE.Nokia.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F0260098C@esebe103.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <89B76691-B8FE-4E31-A8C0-D31C2D0A77F6@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Usage of flows in draft-ietf-sip-outbound-03 Date: Wed, 31 May 2006 22:59:26 -0700 To: "" X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 01 Jun 2006 05:59:28.0653 (UTC) FILETIME=[8B34C3D0:01C68540] DKIM-Signature: a=rsa-sha1; q=dns; l=4625; t=1149141569; x=1150005569; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Usage=20of=20flows=20in=20draft-ietf-sip-outbound-03; X=v=3Dcisco.com=3B=20h=3D0YYiX3neypTSH/MgOCYs7w8eddk=3D; b=0I2Zj+5K6ocH7fF+hAMvvUxxB3ITua2CVlAHtohOz5cyRFynQ7h/si5+VPiG6r5APazSUeMg hT2VuHm2yDT0QfYxezHcJAcmPK0jZpAxj7z00oEWSDGLOpWNmVO28N/O; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On May 31, 2006, at 7:16 AM, wrote: > > Hi, > > While reading draft-ietf-sip-outbound earlier I got (a wrong) > idea that the UA would use those flows it has set up towards > the outbound-proxy-set during registration, for sending any > other requests thereafter. However this is not the case. > When thinking this a bit more I found two use cases and > different problem with each of them and I would like to get > some answers how the next version of the draft should deal > with those: > > 1. Sending request to first hop other than outbound proxy > > Sections 4.3.1 and 4.3.2 tell that the "The UA performs normal > DNS resolution on the next hop URI (as described in RFC 3263) > to find a protocol, IP address, and port." and "If the UA > cannot use one of the existing flows, then it SHOULD form a new flow > by sending a datagram or opening a new connection to the next hop, as > appropriate for the transport protocol." > > Is the UA expected to keep this new flow alive ? No - if it is important for this flow to stay alive, it will use a GRUU in the contact which will end up with routing over one of the flows that is alive. This is out of the scope of outbound. > If yes, how long ? > I do not think it is a valid requirement for the UA to keep a flow > alive forever towards any proxy the UA has communicated with. But > the draft does not suggest any rules about when the flow should > be closed. For the flow related to registration I believe the flow > can be cleared after removing the registration binding, but what > about a flow the UA has opened when initiating a call through > some other proxy than the outbound proxy e.g. due to 305 response ? > > 2. Sending registration refreshes > > I believe that draft-ietf-sip-outbound is written with the > assumption that when the UA refreshes a registration binding > the REGISTER message would be sent over the same flow over which > the binding was created, right ? Or at least that the refreshed > REGISTER would reach the same target host (outbound proxy) that > received the very first REGISTER request, now to be refreshed ? > > However this is not guranteed. When sending the REGISTER refresh, > the UA is supposed to use DNS procedures of RFC 3263 for resolving > the URI of the outbound proxy. While doing that the UA may find a > number of SRV records for that URI, having equal priorities and > equal or different weights. Basically according to RFC 2782 the UA > would select the used SRV record by random, possibly a different > target host than the one used previously. I think Robert has or working on a draft with fixes this. It's not clear this is what 3263 says should happen. Let me take TCP - if you have an TCP connection to example.com, clearly you want to reuse that not open a new one for every transaction. > Is this a problem for > SIP Outbound (while it is not a problem in RFC 3261 point of view)? > > What happens in this case: > > - Should the UA keep the flows now alive to those two proxies > for the same refreshed registration or should it silently drop > the first one ? I believe keeping all those flows open would > be an unnecessary burden, especially for mobile devices with > a battery. > Yes - clearly we want to send things in the same dialog on an existing connection if we have one. > - Is there any risk that a proxy or registrar would try to use > such a flow towards the UA that is no more existing ? > > I would hope the next version of the draft would explicitely specify > either that the UA is supposed to use the existing flow instead of > performing RFC 3263 processing for the refreshed REGISTER or that > the UA should drop the flow it had with the target host it used > earlier, when receiving the 200 OK for the REGISTER. > One of the things we got wrong in much earlier version of outbound was trying to fix every routing problem in sip in one document including high availability and stateless server design. We are definitely trying to push things that are orthogonal to be solved separately. > Feel free to tell me if I got it wrong at some point. > > Regards, > > Erkki Koivusalo > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 01 03:07:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlhFn-00057W-Ts; Thu, 01 Jun 2006 03:05:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlhFm-00057R-Bf for sip@ietf.org; Thu, 01 Jun 2006 03:05:58 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlhFk-0002kS-GF for sip@ietf.org; Thu, 01 Jun 2006 03:05:58 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A2CEE4F0094; Thu, 1 Jun 2006 09:05:55 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 09:05:54 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 09:05:53 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [Sip] Connected-identity and changing the To header fieldina response Date: Thu, 1 Jun 2006 09:05:52 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F0FCD@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Sip] Connected-identity and changing the To header fieldina response Thread-Index: AcaFP3EilrdI82B9T82F0nl4tYnF2wACleag From: "Christer Holmberg \(JO/LMF\)" To: "Jesske, R" , X-OriginalArrivalTime: 01 Jun 2006 07:05:53.0012 (UTC) FILETIME=[D211B340:01C68549] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: fluffy@cisco.com, sip@ietf.org, john.elwell@siemens.com, roland.jesske@web.de X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org What happened to the modified To header? Regards, Christer=20 -----Original Message----- From: Jesske, R [mailto:R.Jesske@t-com.net]=20 Sent: 1. kes=E4kuuta 2006 8:28 To: pkyzivat@cisco.com Cc: fluffy@cisco.com; sip@ietf.org; john.elwell@siemens.com; = roland.jesske@web.de; Christer Holmberg (JO/LMF) Subject: AW: AW: [Sip] Connected-identity and changing the To header = fieldina response Paul, in the past we lookes also on the Reply-to header. But per definition it = is the address where the user want to be connected. So it is not in each = case the real conected identity. But the COLP (TIP) service could be = used in the same way. So if it would be possible to use Reply-to header in Responses, if = people are willing and we as TISPAN can narrow it then only to the real = connected identity (within our walled garden service definition) I would = be happy. Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Gesendet: Mittwoch, 31. Mai 2006 17:04 > An: Jesske, Roland > Cc: fluffy@cisco.com; sip@ietf.org; john.elwell@siemens.com;=20 > roland.jesske@web.de; christer.holmberg@ericsson.com > Betreff: Re: AW: [Sip] Connected-identity and changing the To header=20 > field ina response >=20 >=20 >=20 >=20 > Jesske, R wrote: > > These are the requirements we already expressed in our > draft draft-jesske-sipping-tispan-requirements-02: > >=20 > > REQ-TIP-1: In addition to any network asserted identity, > it must be > > possible for the callee to indicate in a SIP > response an > > additional identity where the user is > reachable for future > > direct communications. Note that the > requirement refers > > to the user, not to the same instance of the > User Agent. > > REQ-TIP-2: The identity mentioned in REQ-TIP-1 must be > formatted as a > > SIP URI [2] or TEL URL [3]. A translation > between SIP URI > > and TEL URL by the network is not requested. > > REQ-TIP-3: The identity mentioned in REQ-TIP-1 is > considered an end > > user supplied information that is not asserted by the > > network. > >=20 > >=20 > > As you can see we do not need any authenticated identity in > the response. For the authenticated identity we are using the=20 > P-Asserted-Identity. So we have two identities in a Response. > > For our purposes the user provided identity in a final 200 > OK response is sufficient. So that avoids confusion within forking=20 > cases. >=20 > I haven't been paying close attention to this. What header are you=20 > planning to use to carry this callee provided identity? >=20 > The Reply-To header would seem to be appropriate for this purpose, but = > unfortunately, according to table 2 of 3261, it is only allowed in=20 > INVITE. >=20 > Paul >=20 > > Roland > >=20 > >=20 > >=20 > >=20 > >> -----Urspr=FCngliche Nachricht----- > >> Von: Cullen Jennings [mailto:fluffy@cisco.com] > >> Gesendet: Montag, 22. Mai 2006 17:32 > >> An: Jesske, Roland > >> Cc: John Elwell; sip@ietf.org; Roland Jesske; Christer Holmberg=20 > >> (JO/LMF) > >> Betreff: Re: [Sip] Connected-identity and changing the To header=20 > >> field ina response > >> > >> > >> > >> On May 16, 2006, at 7:07 AM, Jesske, R wrote: > >> > >>> John, > >>> it is that we don't can get an connected identity within > the final > >>> response of the initial INVITE. > >>> Your draft proposes a mid dialog request for getting this > >> information. > >>> That is not usable for the TIP service. > >> I think this is part of what I am not understanding. What is the=20 > >> requirement here? > >> > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use = sip-implementors@cs.columbia.edu for questions on current sip Use = sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 01 03:12:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlhKd-0000K7-Nc; Thu, 01 Jun 2006 03:10:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlhKc-0000K1-5q for sip@ietf.org; Thu, 01 Jun 2006 03:10:58 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlhKa-00033A-NG for sip@ietf.org; Thu, 01 Jun 2006 03:10:58 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 01 Jun 2006 00:10:56 -0700 X-IronPort-AV: i="4.05,195,1146466800"; d="scan'208"; a="1816883151:sNHT298547660" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k517AtkH030476; Thu, 1 Jun 2006 00:10:55 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k517AtcL000756; Thu, 1 Jun 2006 00:10:55 -0700 (PDT) Received: from [192.168.1.2] ([10.21.89.137]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 00:10:55 -0700 In-Reply-To: <85108216918A984C8C60172D7C84770A08A518@S4DE8PSAAGO.mitte.t-com.de> References: <85108216918A984C8C60172D7C84770A08A518@S4DE8PSAAGO.mitte.t-com.de> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Cullen Jennings Subject: Re: AW: AW: [Sip] Connected-identity and changing the To header field ina response Date: Thu, 1 Jun 2006 00:10:53 -0700 To: "Jesske, R" X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 01 Jun 2006 07:10:55.0348 (UTC) FILETIME=[86468340:01C6854A] DKIM-Signature: a=rsa-sha1; q=dns; l=4302; t=1149145855; x=1150009855; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20AW=3A=20AW=3A=20[Sip]=20Connected-identity=20and=20changing=20th e=20To=20header=20field=20ina=09response; X=v=3Dcisco.com=3B=20h=3Dg1dmDpuhpXMnOuTxMq2l65UE3+8=3D; b=Yc8Lia887tCw0mvOoGqxvDMmhZOwe4C9S/6zMqsRZGbdTBCVLDolchjkgReqjkoUl+BLi5EN uu+NpnAvx0gqcr/Y4gaFBht8feQzqn3VMvCjFgny6RjGG+aA0XQUuObR; Authentication-Results: sj-dkim-7.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: sip@ietf.org, pkyzivat@cisco.com, john.elwell@siemens.com, roland.jesske@web.de, christer.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org What things use these two identities, what do they get used for, and =20 what security assumptions come around them. That type of information =20 would help people on this list understand the problem. On May 31, 2006, at 10:28 PM, Jesske, R wrote: > Paul, > in the past we lookes also on the Reply-to header. But per =20 > definition it is the address where the user want to be connected. =20 > So it is not in each case the real conected identity. But the COLP =20 > (TIP) service could be used in the same way. > So if it would be possible to use Reply-to header in Responses, if =20 > people are willing and we as TISPAN can narrow it then only to the =20 > real connected identity (within our walled garden service =20 > definition) I would be happy. > > Best Regards > > Roland > >> -----Urspr=FCngliche Nachricht----- >> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Gesendet: Mittwoch, 31. Mai 2006 17:04 >> An: Jesske, Roland >> Cc: fluffy@cisco.com; sip@ietf.org; john.elwell@siemens.com; >> roland.jesske@web.de; christer.holmberg@ericsson.com >> Betreff: Re: AW: [Sip] Connected-identity and changing the To >> header field ina response >> >> >> >> >> Jesske, R wrote: >>> These are the requirements we already expressed in our >> draft draft-jesske-sipping-tispan-requirements-02: >>> >>> REQ-TIP-1: In addition to any network asserted identity, >> it must be >>> possible for the callee to indicate in a SIP >> response an >>> additional identity where the user is >> reachable for future >>> direct communications. Note that the >> requirement refers >>> to the user, not to the same instance of the >> User Agent. >>> REQ-TIP-2: The identity mentioned in REQ-TIP-1 must be >> formatted as a >>> SIP URI [2] or TEL URL [3]. A translation >> between SIP URI >>> and TEL URL by the network is not requested. >>> REQ-TIP-3: The identity mentioned in REQ-TIP-1 is >> considered an end >>> user supplied information that is not asserted by the >>> network. >>> >>> >>> As you can see we do not need any authenticated identity in >> the response. For the authenticated identity we are using the >> P-Asserted-Identity. So we have two identities in a Response. >>> For our purposes the user provided identity in a final 200 >> OK response is sufficient. So that avoids confusion within >> forking cases. >> >> I haven't been paying close attention to this. What header are you >> planning to use to carry this callee provided identity? >> >> The Reply-To header would seem to be appropriate for this >> purpose, but >> unfortunately, according to table 2 of 3261, it is only >> allowed in INVITE. >> >> Paul >> >>> Roland >>> >>> >>> >>> >>>> -----Urspr=FCngliche Nachricht----- >>>> Von: Cullen Jennings [mailto:fluffy@cisco.com] >>>> Gesendet: Montag, 22. Mai 2006 17:32 >>>> An: Jesske, Roland >>>> Cc: John Elwell; sip@ietf.org; Roland Jesske; Christer >>>> Holmberg (JO/LMF) >>>> Betreff: Re: [Sip] Connected-identity and changing the To >>>> header field ina response >>>> >>>> >>>> >>>> On May 16, 2006, at 7:07 AM, Jesske, R wrote: >>>> >>>>> John, >>>>> it is that we don't can get an connected identity within >> the final >>>>> response of the initial INVITE. >>>>> Your draft proposes a mid dialog request for getting this >>>> information. >>>>> That is not usable for the TIP service. >>>> I think this is part of what I am not understanding. What is the >>>> requirement here? >>>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 01 03:32:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlhdU-0003Xx-5f; Thu, 01 Jun 2006 03:30:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlhdT-0003Xs-6B for sip@ietf.org; Thu, 01 Jun 2006 03:30:27 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlhdS-0005ds-MK for sip@ietf.org; Thu, 01 Jun 2006 03:30:27 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Thu, 1 Jun 2006 09:30:25 +0200 Received: by S4DE8PSAANQ.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Jun 2006 09:30:24 +0200 Message-Id: <85108216918A984C8C60172D7C84770A08A51B@S4DE8PSAAGO.mitte.t-com.de> From: "Jesske, R" To: christer.holmberg@ericsson.com, pkyzivat@cisco.com Subject: AW: AW: [Sip] Connected-identity and changing the To header field ina response Date: Thu, 1 Jun 2006 09:30:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: fluffy@cisco.com, sip@ietf.org, john.elwell@siemens.com, roland.jesske@web.de X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer, I'm looking which ways are possible. The discussion with the urichange = is at the moment is not very satisfying. So I'm happy if people come = with other possibilies that could solve the issue. The reply-to header could be an other solution that fits and do not use = a P-header.=20 The question which solution will be available faster. The to header change has the advantage that we do not need a additional = header and the draft is on the way and stable.=20 I could life with both possibilities.=20 Which way do you prefer? Best Regards Roland=20 > -----Urspr=FCngliche Nachricht----- > Von: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Gesendet: Donnerstag, 1. Juni 2006 09:06 > An: Jesske, Roland; pkyzivat@cisco.com > Cc: fluffy@cisco.com; sip@ietf.org; john.elwell@siemens.com;=20 > roland.jesske@web.de > Betreff: RE: AW: [Sip] Connected-identity and changing the To=20 > header fieldina response >=20 >=20 >=20 > What happened to the modified To header? >=20 > Regards, >=20 > Christer=20 >=20 > -----Original Message----- > From: Jesske, R [mailto:R.Jesske@t-com.net]=20 > Sent: 1. kes=E4kuuta 2006 8:28 > To: pkyzivat@cisco.com > Cc: fluffy@cisco.com; sip@ietf.org; john.elwell@siemens.com;=20 > roland.jesske@web.de; Christer Holmberg (JO/LMF) > Subject: AW: AW: [Sip] Connected-identity and changing the To=20 > header fieldina response >=20 > Paul, > in the past we lookes also on the Reply-to header. But per=20 > definition it is the address where the user want to be=20 > connected. So it is not in each case the real conected=20 > identity. But the COLP (TIP) service could be used in the same way. > So if it would be possible to use Reply-to header in=20 > Responses, if people are willing and we as TISPAN can narrow=20 > it then only to the real connected identity (within our=20 > walled garden service definition) I would be happy. >=20 > Best Regards >=20 > Roland >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Gesendet: Mittwoch, 31. Mai 2006 17:04 > > An: Jesske, Roland > > Cc: fluffy@cisco.com; sip@ietf.org; john.elwell@siemens.com;=20 > > roland.jesske@web.de; christer.holmberg@ericsson.com > > Betreff: Re: AW: [Sip] Connected-identity and changing the=20 > To header=20 > > field ina response > >=20 > >=20 > >=20 > >=20 > > Jesske, R wrote: > > > These are the requirements we already expressed in our > > draft draft-jesske-sipping-tispan-requirements-02: > > >=20 > > > REQ-TIP-1: In addition to any network asserted identity, > > it must be > > > possible for the callee to indicate in a SIP > > response an > > > additional identity where the user is > > reachable for future > > > direct communications. Note that the > > requirement refers > > > to the user, not to the same instance of the > > User Agent. > > > REQ-TIP-2: The identity mentioned in REQ-TIP-1 must be > > formatted as a > > > SIP URI [2] or TEL URL [3]. A translation > > between SIP URI > > > and TEL URL by the network is not requested. > > > REQ-TIP-3: The identity mentioned in REQ-TIP-1 is > > considered an end > > > user supplied information that is not=20 > asserted by the > > > network. > > >=20 > > >=20 > > > As you can see we do not need any authenticated identity in > > the response. For the authenticated identity we are using the=20 > > P-Asserted-Identity. So we have two identities in a Response. > > > For our purposes the user provided identity in a final 200 > > OK response is sufficient. So that avoids confusion within forking=20 > > cases. > >=20 > > I haven't been paying close attention to this. What header are you=20 > > planning to use to carry this callee provided identity? > >=20 > > The Reply-To header would seem to be appropriate for this=20 > purpose, but=20 > > unfortunately, according to table 2 of 3261, it is only allowed in=20 > > INVITE. > >=20 > > Paul > >=20 > > > Roland > > >=20 > > >=20 > > >=20 > > >=20 > > >> -----Urspr=FCngliche Nachricht----- > > >> Von: Cullen Jennings [mailto:fluffy@cisco.com] > > >> Gesendet: Montag, 22. Mai 2006 17:32 > > >> An: Jesske, Roland > > >> Cc: John Elwell; sip@ietf.org; Roland Jesske; Christer Holmberg=20 > > >> (JO/LMF) > > >> Betreff: Re: [Sip] Connected-identity and changing the To header = > > >> field ina response > > >> > > >> > > >> > > >> On May 16, 2006, at 7:07 AM, Jesske, R wrote: > > >> > > >>> John, > > >>> it is that we don't can get an connected identity within > > the final > > >>> response of the initial INVITE. > > >>> Your draft proposes a mid dialog request for getting this > > >> information. > > >>> That is not usable for the TIP service. > > >> I think this is part of what I am not understanding. What is the = > > >> requirement here? > > >> > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use = > > > sipping@ietf.org for new developments on the application of sip > > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 01 04:05:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fli9M-000613-BF; Thu, 01 Jun 2006 04:03:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fli9K-00060y-Tp for sip@ietf.org; Thu, 01 Jun 2006 04:03:22 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fli9K-0000RI-Aj for sip@ietf.org; Thu, 01 Jun 2006 04:03:22 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5183GYI005864; Thu, 1 Jun 2006 11:03:19 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 11:03:18 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 11:03:18 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Usage of flows in draft-ietf-sip-outbound-03 Date: Thu, 1 Jun 2006 11:03:17 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F02600CF0@esebe103.NOE.Nokia.com> In-Reply-To: <89B76691-B8FE-4E31-A8C0-D31C2D0A77F6@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Usage of flows in draft-ietf-sip-outbound-03 Thread-Index: AcaFQJ7BsQqjD2i1TdSZfLzVtMLQKgAEEiIw From: To: X-OriginalArrivalTime: 01 Jun 2006 08:03:18.0581 (UTC) FILETIME=[D7C9CE50:01C68551] X-Spam-Score: 0.2 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Hi, >> 1. Sending request to first hop other than outbound proxy >> >> Sections 4.3.1 and 4.3.2 tell that the "The UA performs normal >> DNS resolution on the next hop URI (as described in RFC 3263) >> to find a protocol, IP address, and port." and "If the UA >> cannot use one of the existing flows, then it SHOULD form a new flow >> by sending a datagram or opening a new connection to the next hop, as >> appropriate for the transport protocol." >> >> Is the UA expected to keep this new flow alive ? > >No - if it is important for this flow to stay alive, it will use a =20 >GRUU in the contact which will end up with routing over one of the =20 >flows that is alive. This is out of the scope of outbound. Hmmm, I was just thinking about a situation where the UA, for some reason or another, would send an INVITE towards any other proxy than the outbound proxy. If that proxy record-routes and the flow would not be kept alive, then the remote end could no more get the BYE back to the UA. Are you saying that there should be no reason whatsoever for the UA=20 to use other proxy than the outbound one ? (Preloaded route from a=20 game application, 305 response from the network etc. ) >One of the things we got wrong in much earlier version of outbound =20 >was trying to fix every routing problem in sip in one document =20 >including high availability and stateless server design. We are =20 >definitely trying to push things that are orthogonal to be solved =20 >separately. Or are you rather suggesting that if anything like that happens,=20 it is not in scope of draft-ietf-sip-outbound to try to fix the=20 resulting problems ? In other words: to traverse the NAT, the UA has better to always use its persistent flows towards the outbound proxy, no matter what. Regards, Erkki >-----Original Message----- >From: ext Cullen Jennings [mailto:fluffy@cisco.com]=20 >Sent: 01.June.2006 08:59 >To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki) >Cc: sip@ietf.org >Subject: Re: [Sip] Usage of flows in draft-ietf-sip-outbound-03 > > >On May 31, 2006, at 7:16 AM, =20 > wrote: > >> >> Hi, >> >> While reading draft-ietf-sip-outbound earlier I got (a wrong) >> idea that the UA would use those flows it has set up towards >> the outbound-proxy-set during registration, for sending any >> other requests thereafter. However this is not the case. >> When thinking this a bit more I found two use cases and >> different problem with each of them and I would like to get >> some answers how the next version of the draft should deal >> with those: >> >> 1. Sending request to first hop other than outbound proxy >> >> Sections 4.3.1 and 4.3.2 tell that the "The UA performs normal >> DNS resolution on the next hop URI (as described in RFC 3263) >> to find a protocol, IP address, and port." and "If the UA >> cannot use one of the existing flows, then it SHOULD form a new flow >> by sending a datagram or opening a new connection to the next hop, as >> appropriate for the transport protocol." >> >> Is the UA expected to keep this new flow alive ? > >No - if it is important for this flow to stay alive, it will use a =20 >GRUU in the contact which will end up with routing over one of the =20 >flows that is alive. This is out of the scope of outbound. > > >> If yes, how long ? >> I do not think it is a valid requirement for the UA to keep a flow >> alive forever towards any proxy the UA has communicated with. But >> the draft does not suggest any rules about when the flow should >> be closed. For the flow related to registration I believe the flow >> can be cleared after removing the registration binding, but what >> about a flow the UA has opened when initiating a call through >> some other proxy than the outbound proxy e.g. due to 305 response ? >> >> 2. Sending registration refreshes >> >> I believe that draft-ietf-sip-outbound is written with the >> assumption that when the UA refreshes a registration binding >> the REGISTER message would be sent over the same flow over which >> the binding was created, right ? Or at least that the refreshed >> REGISTER would reach the same target host (outbound proxy) that >> received the very first REGISTER request, now to be refreshed ? >> >> However this is not guranteed. When sending the REGISTER refresh, >> the UA is supposed to use DNS procedures of RFC 3263 for resolving >> the URI of the outbound proxy. While doing that the UA may find a >> number of SRV records for that URI, having equal priorities and >> equal or different weights. Basically according to RFC 2782 the UA >> would select the used SRV record by random, possibly a different >> target host than the one used previously. > >I think Robert has or working on a draft with fixes this. It's not =20 >clear this is what 3263 says should happen. Let me take TCP - if you =20 >have an TCP connection to example.com, clearly you want to reuse that =20 >not open a new one for every transaction. > >> Is this a problem for >> SIP Outbound (while it is not a problem in RFC 3261 point of view)? >> >> What happens in this case: >> >> - Should the UA keep the flows now alive to those two proxies >> for the same refreshed registration or should it silently drop >> the first one ? I believe keeping all those flows open would >> be an unnecessary burden, especially for mobile devices with >> a battery. >> > >Yes - clearly we want to send things in the same dialog on an =20 >existing connection if we have one. > >> - Is there any risk that a proxy or registrar would try to use >> such a flow towards the UA that is no more existing ? >> >> I would hope the next version of the draft would explicitely specify >> either that the UA is supposed to use the existing flow instead of >> performing RFC 3263 processing for the refreshed REGISTER or that >> the UA should drop the flow it had with the target host it used >> earlier, when receiving the 200 OK for the REGISTER. >> > >One of the things we got wrong in much earlier version of outbound =20 >was trying to fix every routing problem in sip in one document =20 >including high availability and stateless server design. We are =20 >definitely trying to push things that are orthogonal to be solved =20 >separately. > >> Feel free to tell me if I got it wrong at some point. >> >> Regards, >> >> Erkki Koivusalo >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 01 04:30:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FliXh-00055w-6X; Thu, 01 Jun 2006 04:28:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FliXf-00055r-U0 for sip@ietf.org; Thu, 01 Jun 2006 04:28:31 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FliXf-0002iw-62 for sip@ietf.org; Thu, 01 Jun 2006 04:28:31 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k518SP4K008120; Thu, 1 Jun 2006 11:28:26 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 11:28:09 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 11:28:10 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Usage of flows in draft-ietf-sip-outbound-03 Date: Thu, 1 Jun 2006 11:28:08 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F02600D35@esebe103.NOE.Nokia.com> In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F02600CF0@esebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Usage of flows in draft-ietf-sip-outbound-03 Thread-Index: AcaFQJ7BsQqjD2i1TdSZfLzVtMLQKgAEEiIwAADtqiA= From: To: , X-OriginalArrivalTime: 01 Jun 2006 08:28:10.0090 (UTC) FILETIME=[50CC04A0:01C68555] X-Spam-Score: 0.2 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Hi, Excuse me for my previous questions in this thread, I was just too quick for pressing the send button before applying enough thinking :-) >>No - if it is important for this flow to stay alive, it will use a =20 >>GRUU in the contact which will end up with routing over one of the =20 >>flows that is alive. >Hmmm, I was just thinking about a situation where the UA, for some >reason or another, would send an INVITE towards any other proxy than >the outbound proxy. If that proxy record-routes and the flow would not >be kept alive, then the remote end could no more get the BYE back to >the UA. I have been looking things recently too much from the UA perspective and were not very familiar with GRUU either. But I assume what Cullen meant is that even if the first hop proxy that the UA uses would record-route, the fact that the Contact header of such an INVITE contains the GRUU would make sure that the proxy would eventually=20 route any mid-dialog requests from the other end towards the outbound proxy that has the flow with the UA. So this would be the way to solve the problem with GRUU and Outbound together ? Regards, Erkki >-----Original Message----- >From: ext sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]=20 >Sent: 01.June.2006 11:03 >To: fluffy@cisco.com >Cc: sip@ietf.org >Subject: RE: [Sip] Usage of flows in draft-ietf-sip-outbound-03 > >=20 >Hi, > >>> 1. Sending request to first hop other than outbound proxy >>> >>> Sections 4.3.1 and 4.3.2 tell that the "The UA performs normal >>> DNS resolution on the next hop URI (as described in RFC 3263) >>> to find a protocol, IP address, and port." and "If the UA >>> cannot use one of the existing flows, then it SHOULD form a new flow >>> by sending a datagram or opening a new connection to the=20 >next hop, as >>> appropriate for the transport protocol." >>> >>> Is the UA expected to keep this new flow alive ? >> >>No - if it is important for this flow to stay alive, it will use a =20 >>GRUU in the contact which will end up with routing over one of the =20 >>flows that is alive. This is out of the scope of outbound. > >Hmmm, I was just thinking about a situation where the UA, for some >reason or another, would send an INVITE towards any other proxy than >the outbound proxy. If that proxy record-routes and the flow would not >be kept alive, then the remote end could no more get the BYE back to >the UA. > >Are you saying that there should be no reason whatsoever for the UA=20 >to use other proxy than the outbound one ? (Preloaded route from a=20 >game application, 305 response from the network etc. ) > >>One of the things we got wrong in much earlier version of outbound =20 >>was trying to fix every routing problem in sip in one document =20 >>including high availability and stateless server design. We are =20 >>definitely trying to push things that are orthogonal to be solved =20 >>separately. > >Or are you rather suggesting that if anything like that happens,=20 >it is not in scope of draft-ietf-sip-outbound to try to fix the=20 >resulting problems ? In other words: to traverse the NAT, the UA >has better to always use its persistent flows towards the outbound >proxy, no matter what. > >Regards, > >Erkki > >>-----Original Message----- >>From: ext Cullen Jennings [mailto:fluffy@cisco.com]=20 >>Sent: 01.June.2006 08:59 >>To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki) >>Cc: sip@ietf.org >>Subject: Re: [Sip] Usage of flows in draft-ietf-sip-outbound-03 >> >> >>On May 31, 2006, at 7:16 AM, =20 >> wrote: >> >>> >>> Hi, >>> >>> While reading draft-ietf-sip-outbound earlier I got (a wrong) >>> idea that the UA would use those flows it has set up towards >>> the outbound-proxy-set during registration, for sending any >>> other requests thereafter. However this is not the case. >>> When thinking this a bit more I found two use cases and >>> different problem with each of them and I would like to get >>> some answers how the next version of the draft should deal >>> with those: >>> >>> 1. Sending request to first hop other than outbound proxy >>> >>> Sections 4.3.1 and 4.3.2 tell that the "The UA performs normal >>> DNS resolution on the next hop URI (as described in RFC 3263) >>> to find a protocol, IP address, and port." and "If the UA >>> cannot use one of the existing flows, then it SHOULD form a new flow >>> by sending a datagram or opening a new connection to the=20 >next hop, as >>> appropriate for the transport protocol." >>> >>> Is the UA expected to keep this new flow alive ? >> >>No - if it is important for this flow to stay alive, it will use a =20 >>GRUU in the contact which will end up with routing over one of the =20 >>flows that is alive. This is out of the scope of outbound. >> >> >>> If yes, how long ? >>> I do not think it is a valid requirement for the UA to keep a flow >>> alive forever towards any proxy the UA has communicated with. But >>> the draft does not suggest any rules about when the flow should >>> be closed. For the flow related to registration I believe the flow >>> can be cleared after removing the registration binding, but what >>> about a flow the UA has opened when initiating a call through >>> some other proxy than the outbound proxy e.g. due to 305 response ? >>> >>> 2. Sending registration refreshes >>> >>> I believe that draft-ietf-sip-outbound is written with the >>> assumption that when the UA refreshes a registration binding >>> the REGISTER message would be sent over the same flow over which >>> the binding was created, right ? Or at least that the refreshed >>> REGISTER would reach the same target host (outbound proxy) that >>> received the very first REGISTER request, now to be refreshed ? >>> >>> However this is not guranteed. When sending the REGISTER refresh, >>> the UA is supposed to use DNS procedures of RFC 3263 for resolving >>> the URI of the outbound proxy. While doing that the UA may find a >>> number of SRV records for that URI, having equal priorities and >>> equal or different weights. Basically according to RFC 2782 the UA >>> would select the used SRV record by random, possibly a different >>> target host than the one used previously. >> >>I think Robert has or working on a draft with fixes this. It's not =20 >>clear this is what 3263 says should happen. Let me take TCP - if you =20 >>have an TCP connection to example.com, clearly you want to=20 >reuse that =20 >>not open a new one for every transaction. >> >>> Is this a problem for >>> SIP Outbound (while it is not a problem in RFC 3261 point of view)? >>> >>> What happens in this case: >>> >>> - Should the UA keep the flows now alive to those two proxies >>> for the same refreshed registration or should it silently drop >>> the first one ? I believe keeping all those flows open would >>> be an unnecessary burden, especially for mobile devices with >>> a battery. >>> >> >>Yes - clearly we want to send things in the same dialog on an =20 >>existing connection if we have one. >> >>> - Is there any risk that a proxy or registrar would try to use >>> such a flow towards the UA that is no more existing ? >>> >>> I would hope the next version of the draft would explicitely specify >>> either that the UA is supposed to use the existing flow instead of >>> performing RFC 3263 processing for the refreshed REGISTER or that >>> the UA should drop the flow it had with the target host it used >>> earlier, when receiving the 200 OK for the REGISTER. >>> >> >>One of the things we got wrong in much earlier version of outbound =20 >>was trying to fix every routing problem in sip in one document =20 >>including high availability and stateless server design. We are =20 >>definitely trying to push things that are orthogonal to be solved =20 >>separately. >> >>> Feel free to tell me if I got it wrong at some point. >>> >>> Regards, >>> >>> Erkki Koivusalo >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >> > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 01 04:44:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flil4-0006GJ-Sg; Thu, 01 Jun 2006 04:42:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flil3-0006GE-Ni for sip@ietf.org; Thu, 01 Jun 2006 04:42:21 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flil3-0004m3-7k for sip@ietf.org; Thu, 01 Jun 2006 04:42:21 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Thu, 1 Jun 2006 10:42:20 +0200 Received: by S4DE8PSAANQ.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Jun 2006 10:42:19 +0200 Message-Id: <85108216918A984C8C60172D7C84770A08A521@S4DE8PSAAGO.mitte.t-com.de> From: "Jesske, R" To: fluffy@cisco.com Subject: AW: AW: AW: [Sip] Connected-identity and changing the To header f ield ina response Date: Thu, 1 Jun 2006 10:42:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: sip@ietf.org, pkyzivat@cisco.com, john.elwell@siemens.com, roland.jesske@web.de, christer.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The two identities are used for PBX services. Example If a user calls a special hotline for e.G. Computer Services. = +496151830. This is the main number of a PBX with several extensions. The user will = be at least connected to an Service Expert (Extension No: = +496151831111). So now there is a Public Id (+496151830) that is trusted and the all = billing is bind to. (TISPAN uses the P-Asserted-Identity) and a private not secure id of the Expert. Advantage is that the Caller = has now the ability to see the real connected number where the expert = can now called directly. This service is widely used within the PSTN/ISDN world and is known as = COLP (Connected Line Identification Presentation) Specifies in ITU-T = Q.731.5 and in ETSI ETSI EN 300 094 (free downloadable at = portal.etsi.org). We have described the Requirements in = draft-jesske-sipping-tispan-requirements-01 and did some analysis in = the past in draft-jesske-sipping-tispan-analysis-00.txt Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Gesendet: Donnerstag, 1. Juni 2006 09:11 > An: Jesske, Roland > Cc: pkyzivat@cisco.com; sip@ietf.org;=20 > john.elwell@siemens.com; roland.jesske@web.de;=20 > christer.holmberg@ericsson.com > Betreff: Re: AW: AW: [Sip] Connected-identity and changing=20 > the To header field ina response >=20 >=20 >=20 > What things use these two identities, what do they get used for, and = > what security assumptions come around them. That type of information = > would help people on this list understand the problem. >=20 > On May 31, 2006, at 10:28 PM, Jesske, R wrote: >=20 > > Paul, > > in the past we lookes also on the Reply-to header. But per =20 > > definition it is the address where the user want to be connected. =20 > > So it is not in each case the real conected identity. But the COLP = > > (TIP) service could be used in the same way. > > So if it would be possible to use Reply-to header in Responses, if = > > people are willing and we as TISPAN can narrow it then only to the = > > real connected identity (within our walled garden service =20 > > definition) I would be happy. > > > > Best Regards > > > > Roland > > > >> -----Urspr=FCngliche Nachricht----- > >> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Gesendet: Mittwoch, 31. Mai 2006 17:04 > >> An: Jesske, Roland > >> Cc: fluffy@cisco.com; sip@ietf.org; john.elwell@siemens.com; > >> roland.jesske@web.de; christer.holmberg@ericsson.com > >> Betreff: Re: AW: [Sip] Connected-identity and changing the To > >> header field ina response > >> > >> > >> > >> > >> Jesske, R wrote: > >>> These are the requirements we already expressed in our > >> draft draft-jesske-sipping-tispan-requirements-02: > >>> > >>> REQ-TIP-1: In addition to any network asserted identity, > >> it must be > >>> possible for the callee to indicate in a SIP > >> response an > >>> additional identity where the user is > >> reachable for future > >>> direct communications. Note that the > >> requirement refers > >>> to the user, not to the same instance of the > >> User Agent. > >>> REQ-TIP-2: The identity mentioned in REQ-TIP-1 must be > >> formatted as a > >>> SIP URI [2] or TEL URL [3]. A translation > >> between SIP URI > >>> and TEL URL by the network is not requested. > >>> REQ-TIP-3: The identity mentioned in REQ-TIP-1 is > >> considered an end > >>> user supplied information that is not=20 > asserted by the > >>> network. > >>> > >>> > >>> As you can see we do not need any authenticated identity in > >> the response. For the authenticated identity we are using the > >> P-Asserted-Identity. So we have two identities in a Response. > >>> For our purposes the user provided identity in a final 200 > >> OK response is sufficient. So that avoids confusion within > >> forking cases. > >> > >> I haven't been paying close attention to this. What header are you > >> planning to use to carry this callee provided identity? > >> > >> The Reply-To header would seem to be appropriate for this > >> purpose, but > >> unfortunately, according to table 2 of 3261, it is only > >> allowed in INVITE. > >> > >> Paul > >> > >>> Roland > >>> > >>> > >>> > >>> > >>>> -----Urspr=FCngliche Nachricht----- > >>>> Von: Cullen Jennings [mailto:fluffy@cisco.com] > >>>> Gesendet: Montag, 22. Mai 2006 17:32 > >>>> An: Jesske, Roland > >>>> Cc: John Elwell; sip@ietf.org; Roland Jesske; Christer > >>>> Holmberg (JO/LMF) > >>>> Betreff: Re: [Sip] Connected-identity and changing the To > >>>> header field ina response > >>>> > >>>> > >>>> > >>>> On May 16, 2006, at 7:07 AM, Jesske, R wrote: > >>>> > >>>>> John, > >>>>> it is that we don't can get an connected identity within > >> the final > >>>>> response of the initial INVITE. > >>>>> Your draft proposes a mid dialog request for getting this > >>>> information. > >>>>> That is not usable for the TIP service. > >>>> I think this is part of what I am not understanding. What is the > >>>> requirement here? > >>>> > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol > >>> Use sip-implementors@cs.columbia.edu for questions on current sip > >>> Use sipping@ietf.org for new developments on the=20 > application of sip > >>> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP 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 Jun 01 06:07:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flk47-0005Et-28; Thu, 01 Jun 2006 06:06:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flk45-0005El-TJ for sip@ietf.org; Thu, 01 Jun 2006 06:06:05 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flk44-0006Z7-JM for sip@ietf.org; Thu, 01 Jun 2006 06:06:05 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k51A63dh000706; Thu, 1 Jun 2006 05:06:03 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 1 Jun 2006 11:06:02 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0130F6998@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Jesske, R'" Subject: RE: [Sip] Connected-identity and changing the To header field ina response Date: Thu, 1 Jun 2006 11:06:01 +0100 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: 9a2be21919e71dc6faef12b370c4ecf5 Cc: "'sip@ietf.org'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I don't entirely agree with this answer. Using the term "authenticated" is too general to be meaningful. As far as I understand the requirements for this, they are to enable = the ISDN service to be mimicked. This additional identifier required = here merely has a different assertion. The P-Asserted-Identity is = asserted by the network. The additional identifier is asserted by = whichever entity the "special arrangement" has been granted to. These = entities are outside the trust domain of the P-Asserted-Identity, but = that does not necessarily mean there is not some level of trust. For = the ISDN, in some countries, e.g. USA, this may be any customer = premises equipment, in other countries it may be more controlled and be = the specific operator of an enterprise network interconnected to the = public network. It was not possible to gain international agreement on = this because (way back somewhere around 1983) they wrote the codepoints = before they defined what they meant (which did not really happen until = around 1989). And to answer Cullen's request later in the thread, the seond = identifier is needed because in certain enterprise network scenarios, = it stands more chance of being a real dial-back number than the = P-Asserted-Identity. regards Keith > -----Original Message----- > From: Jesske, R [mailto:R.Jesske@t-com.net] > Sent: 31 May 2006 06:38 > To: fluffy@cisco.com > Cc: sip@ietf.org; john.elwell@siemens.com; roland.jesske@web.de; > christer.holmberg@ericsson.com > Subject: AW: [Sip] Connected-identity and changing the To header = field > ina response >=20 >=20 > These are the requirements we already expressed in our draft=20 > draft-jesske-sipping-tispan-requirements-02: >=20 > REQ-TIP-1: In addition to any network asserted identity, it must = be > possible for the callee to indicate in a SIP response = an > additional identity where the user is reachable=20 > for future > direct communications. Note that the requirement = refers > to the user, not to the same instance of the User = Agent. > REQ-TIP-2: The identity mentioned in REQ-TIP-1 must be=20 > formatted as a > SIP URI [2] or TEL URL [3]. A translation=20 > between SIP URI > and TEL URL by the network is not requested. > REQ-TIP-3: The identity mentioned in REQ-TIP-1 is considered an = end > user supplied information that is not asserted by the > network. >=20 >=20 > As you can see we do not need any authenticated identity in=20 > the response. For the authenticated identity we are using the=20 > P-Asserted-Identity. So we have two identities in a Response. > For our purposes the user provided identity in a final 200 OK=20 > response is sufficient. So that avoids confusion within forking = cases. >=20 > Roland >=20 >=20 >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Cullen Jennings [mailto:fluffy@cisco.com]=20 > > Gesendet: Montag, 22. Mai 2006 17:32 > > An: Jesske, Roland > > Cc: John Elwell; sip@ietf.org; Roland Jesske; Christer=20 > > Holmberg (JO/LMF) > > Betreff: Re: [Sip] Connected-identity and changing the To=20 > > header field ina response > >=20 > >=20 > >=20 > > On May 16, 2006, at 7:07 AM, Jesske, R wrote: > >=20 > > > John, > > > it is that we don't can get an connected identity within=20 > the final =20 > > > response of the initial INVITE. > > > Your draft proposes a mid dialog request for getting this=20 > > information. > > > That is not usable for the TIP service. > >=20 > > I think this is part of what I am not understanding. What is the =20 > > requirement here? > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 01 09:06:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flmqf-0000q0-NX; Thu, 01 Jun 2006 09:04:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flmqe-0000pX-Aw for sip@ietf.org; Thu, 01 Jun 2006 09:04:24 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlmqO-0007aR-Ds for sip@ietf.org; Thu, 01 Jun 2006 09:04:09 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 01 Jun 2006 06:04:07 -0700 X-IronPort-AV: i="4.05,197,1146466800"; d="scan'208"; a="1817129471:sNHT40156558" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k51D47Q3030237; Thu, 1 Jun 2006 06:04:07 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k51D47KP027542; Thu, 1 Jun 2006 06:04:07 -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 k51D0f3G012201; Thu, 1 Jun 2006 06:00:42 -0700 In-Reply-To: <85108216918A984C8C60172D7C84770A08A510@S4DE8PSAAGO.mitte.t-com.de> References: <85108216918A984C8C60172D7C84770A08A510@S4DE8PSAAGO.mitte.t-com.de> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <2D9C78DD-235C-4805-86CC-98065A2B469D@cisco.com> Content-Transfer-Encoding: quoted-printable From: David R Oran Subject: Re: AW: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt Date: Thu, 1 Jun 2006 09:03:57 -0400 To: "Jesske, R" X-Mailer: Apple Mail (2.750) Authentication-Results: sj-dkim-4.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=3704; t=1149167047; x=1150031047; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20AW=3A=20[Sip]=20Issue=201=20in=20draft-ietf-sip-connected-identi ty-00.txt; X=v=3Dcisco.com=3B=20h=3DE4UpyAccqsUtmGI9vXrK7RwqaAU=3D; b=f66latNX7Te2PWtAZJFURJ19vo33/rIZMQT6PJ5rnnY6CmBbKivbeH3RT/BzN+Wguez30S3K X3bAZ3nGvYyxkiG1PtXjk/yqrUzbSJtAxLAQ92SuSI/R6FFPHINx7sOR; X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: fluffy@cisco.com, chister.holmberg@ericsson.com, sip@ietf.org, esasaki@NTT-AT.COM, john.elwell@siemens.com, christer.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On May 31, 2006, at 2:03 AM, Jesske, R wrote: > The problem is that we try to solve two different approaches. > 1. The identity approach to get back an authenticated identity of =20 > the connected user > 2. To get back an "additional connected identity" that is =20 > unauthenticated and provided by the user. > Doesn't (2) sound like the job for a body, not a header? You could =20 send a picture, your C.V., a voiceprint - anything you want. > Due to Jon's comments these are valid for the first case but does =20 > not harm the 2nd case. > So we need the "unanticipated respondent" problem does not exist, =20 > because we need only the "additional connected identity" in a final =20= > 200OK Response. > > Looking on the second concern from Jon. That does not exist for our =20= > used cases, because we have also included a P-Asserted-Identity in =20 > our responses that identifies the Callee with a public identity so =20 > that the called user cannot cheat with the "additional connected =20 > identity". > > The last problem of appearing the "additional connected identity" =20 > in Final responses like the 403 does not appear if we are using the =20= > "additional connected identity" only in 200 OK. > > So at least we need only an "additional connected identity" when =20 > the called UA sends back a 200OK. Perhaps that was misleading in =20 > the past discussion that I didn't express this requirement well. > > But nevertheless question for me is now how to go forward. Could we =20= > use the "dialogUriChange" for this narrowed scope or not. > > Best Regards > > Roland > >> -----Urspr=FCngliche Nachricht----- >> Von: Cullen Jennings [mailto:fluffy@cisco.com] >> Gesendet: Dienstag, 23. Mai 2006 04:22 >> An: Jesske, Roland >> Cc: chister.holmberg@ericsson.com; sip@ietf.org; >> christer.holmberg@ericsson.com; esasaki@NTT-AT.COM; >> john.elwell@siemens.com >> Betreff: Re: [Sip] Issue 1 in draft-ietf-sip-connected-=20 >> identity-00.txt >> >> >> >> On May 8, 2006, at 3:52 AM, Jesske, R wrote: >> >>> The discussion showed it that there is no harm in changing the to >>> header field in a response. >> >> I think there has been several emails that point out the >> implications >> of this do cause harm (check out pretty much any post on the subject >> from Jon Peterson). >> >> This has been a very long running debate and was discussed for >> several years with agenda time at many meetings. The change the To >> and put Identity in response solution has been considered and >> I think >> people have tried to explain the issues with it - I'm glad to spend >> some more time explaining that. However, much more productive would >> be trying to move off of this solution a little and look at the >> requirements. What do we need to do - I think there are some straw- >> man proposal that meet many of the requirements and do work. >> Understanding what requirements they have issues would would be good >> and help make them so they could be used. >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 01 09:37:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlnLN-0004P8-VL; Thu, 01 Jun 2006 09:36:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlnLM-0004P2-4V for sip@ietf.org; Thu, 01 Jun 2006 09:36:08 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlnLK-0002Yo-GZ for sip@ietf.org; Thu, 01 Jun 2006 09:36:08 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 01 Jun 2006 06:35:51 -0700 X-IronPort-AV: i="4.05,197,1146466800"; d="scan'208"; a="286924889:sNHT3378748968" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k51DZokT009364; Thu, 1 Jun 2006 06:35:50 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k51DZoku029081; Thu, 1 Jun 2006 09:35:50 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Jun 2006 09:35:50 -0400 Received: from [161.44.79.149] ([161.44.79.149]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Jun 2006 09:35:49 -0400 Message-ID: <447EED35.1000701@cisco.com> Date: Thu, 01 Jun 2006 09:35:49 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Drage, Keith (Keith)" Subject: Re: [Sip] Connected-identity and changing the To header field ina response References: <475FF955A05DD411980D00508B6D5FB0130F6998@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB0130F6998@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 01 Jun 2006 13:35:49.0683 (UTC) FILETIME=[4B926030:01C68580] DKIM-Signature: a=rsa-sha1; q=dns; l=4607; t=1149168951; x=1150032951; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20Connected-identity=20and=20changing=20the=20To=20header= 20field=20ina=0A=20response; X=v=3Dcisco.com=3B=20h=3DZwZrlMEzzCRzFS1U93OIVpiHWh0=3D; b=LcgTR7SYjmUt2pIiSd751O/G/qlphC79mwBzplyJHrB2sSXvpzsG/gj08Zj/hmdTBkowo6OS eE9wo0P3oMA4mQaDPbxuQxfmCkHJ6zdO34Wow+8FsrYP+kq/fA/yL20X; Authentication-Results: sj-dkim-2.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: "'Jesske, R'" , "'sip@ietf.org'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Reading this, I get the feeling that this identity is *similar in intent* (but not identical) to the Contact address in a sip message. Unfortunately it seems that we have more and more "twisty little addresses, all slightly different". Paul Drage, Keith (Keith) wrote: > I don't entirely agree with this answer. > > Using the term "authenticated" is too general to be meaningful. > > As far as I understand the requirements for this, they are to enable the ISDN service to be mimicked. This additional identifier required here merely has a different assertion. The P-Asserted-Identity is asserted by the network. The additional identifier is asserted by whichever entity the "special arrangement" has been granted to. These entities are outside the trust domain of the P-Asserted-Identity, but that does not necessarily mean there is not some level of trust. For the ISDN, in some countries, e.g. USA, this may be any customer premises equipment, in other countries it may be more controlled and be the specific operator of an enterprise network interconnected to the public network. It was not possible to gain international agreement on this because (way back somewhere around 1983) they wrote the codepoints before they defined what they meant (which did not really happen until around 1989). > > And to answer Cullen's request later in the thread, the seond identifier is needed because in certain enterprise network scenarios, it stands more chance of being a real dial-back number than the P-Asserted-Identity. > > regards > > Keith > >> -----Original Message----- >> From: Jesske, R [mailto:R.Jesske@t-com.net] >> Sent: 31 May 2006 06:38 >> To: fluffy@cisco.com >> Cc: sip@ietf.org; john.elwell@siemens.com; roland.jesske@web.de; >> christer.holmberg@ericsson.com >> Subject: AW: [Sip] Connected-identity and changing the To header field >> ina response >> >> >> These are the requirements we already expressed in our draft >> draft-jesske-sipping-tispan-requirements-02: >> >> REQ-TIP-1: In addition to any network asserted identity, it must be >> possible for the callee to indicate in a SIP response an >> additional identity where the user is reachable >> for future >> direct communications. Note that the requirement refers >> to the user, not to the same instance of the User Agent. >> REQ-TIP-2: The identity mentioned in REQ-TIP-1 must be >> formatted as a >> SIP URI [2] or TEL URL [3]. A translation >> between SIP URI >> and TEL URL by the network is not requested. >> REQ-TIP-3: The identity mentioned in REQ-TIP-1 is considered an end >> user supplied information that is not asserted by the >> network. >> >> >> As you can see we do not need any authenticated identity in >> the response. For the authenticated identity we are using the >> P-Asserted-Identity. So we have two identities in a Response. >> For our purposes the user provided identity in a final 200 OK >> response is sufficient. So that avoids confusion within forking cases. >> >> Roland >> >> >> >> >>> -----Ursprüngliche Nachricht----- >>> Von: Cullen Jennings [mailto:fluffy@cisco.com] >>> Gesendet: Montag, 22. Mai 2006 17:32 >>> An: Jesske, Roland >>> Cc: John Elwell; sip@ietf.org; Roland Jesske; Christer >>> Holmberg (JO/LMF) >>> Betreff: Re: [Sip] Connected-identity and changing the To >>> header field ina response >>> >>> >>> >>> On May 16, 2006, at 7:07 AM, Jesske, R wrote: >>> >>>> John, >>>> it is that we don't can get an connected identity within >> the final >>>> response of the initial INVITE. >>>> Your draft proposes a mid dialog request for getting this >>> information. >>>> That is not usable for the TIP service. >>> I think this is part of what I am not understanding. What is the >>> requirement here? >>> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 01 09:45:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlnSN-0001Gu-Tr; Thu, 01 Jun 2006 09:43:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlnSL-00013T-Vv for sip@ietf.org; Thu, 01 Jun 2006 09:43:21 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlnSK-0003Q3-D7 for sip@ietf.org; Thu, 01 Jun 2006 09:43:21 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 01 Jun 2006 06:43:20 -0700 X-IronPort-AV: i="4.05,197,1146466800"; d="scan'208"; a="429533588:sNHT36803484" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k51DhJh2017329; Thu, 1 Jun 2006 06:43:19 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k51DhJIs018779; Thu, 1 Jun 2006 09:43:19 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Jun 2006 09:43:18 -0400 Received: from [161.44.79.149] ([161.44.79.149]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Jun 2006 09:43:18 -0400 Message-ID: <447EEEF6.5070500@cisco.com> Date: Thu, 01 Jun 2006 09:43:18 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Jesske, R" Subject: Re: AW: AW: [Sip] Connected-identity and changing the To header field ina response References: <85108216918A984C8C60172D7C84770A08A518@S4DE8PSAAGO.mitte.t-com.de> In-Reply-To: <85108216918A984C8C60172D7C84770A08A518@S4DE8PSAAGO.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 01 Jun 2006 13:43:18.0544 (UTC) FILETIME=[571D2100:01C68581] DKIM-Signature: a=rsa-sha1; q=dns; l=4515; t=1149169399; x=1150033399; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20AW=3A=20AW=3A=20[Sip]=20Connected-identity=20and=20changing=20th e=20To=20header=20field=0A=20=20ina=09response; X=v=3Dcisco.com=3B=20h=3Dnb1qk1nmsuuCHsCabsuj8lBYVGU=3D; b=rbNWCYhXvZJIxbc9NHhSjO98UNFLlNv42BThDAVYxEPlJl9S5AVBxap0EhFuROHWRVhEKORl LwsSfwwBimTlk31zu9IVsbFE3D+tjC3z9vyTLPwFuiWKUEa29hVNKywd; Authentication-Results: sj-dkim-3.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: fluffy@cisco.com, sip@ietf.org, john.elwell@siemens.com, roland.jesske@web.de, christer.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I don't know if Reply-To would be any better for your schedule than a new header. It will still require an RFC to make it legal to use in responses. But it would avoid bringing yet another new header into the world. IMO, if the semantics are right, then it is better to reuse it than to invent something new. If the semantics are wrong, then it shouldn't be used. Based on my limited understanding of the usage, the semantics seem about right to me. Paul Jesske, R wrote: > Paul, > in the past we lookes also on the Reply-to header. But per definition it is the address where the user want to be connected. So it is not in each case the real conected identity. But the COLP (TIP) service could be used in the same way. > So if it would be possible to use Reply-to header in Responses, if people are willing and we as TISPAN can narrow it then only to the real connected identity (within our walled garden service definition) I would be happy. > > Best Regards > > Roland > >> -----Ursprüngliche Nachricht----- >> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Gesendet: Mittwoch, 31. Mai 2006 17:04 >> An: Jesske, Roland >> Cc: fluffy@cisco.com; sip@ietf.org; john.elwell@siemens.com; >> roland.jesske@web.de; christer.holmberg@ericsson.com >> Betreff: Re: AW: [Sip] Connected-identity and changing the To >> header field ina response >> >> >> >> >> Jesske, R wrote: >>> These are the requirements we already expressed in our >> draft draft-jesske-sipping-tispan-requirements-02: >>> REQ-TIP-1: In addition to any network asserted identity, >> it must be >>> possible for the callee to indicate in a SIP >> response an >>> additional identity where the user is >> reachable for future >>> direct communications. Note that the >> requirement refers >>> to the user, not to the same instance of the >> User Agent. >>> REQ-TIP-2: The identity mentioned in REQ-TIP-1 must be >> formatted as a >>> SIP URI [2] or TEL URL [3]. A translation >> between SIP URI >>> and TEL URL by the network is not requested. >>> REQ-TIP-3: The identity mentioned in REQ-TIP-1 is >> considered an end >>> user supplied information that is not asserted by the >>> network. >>> >>> >>> As you can see we do not need any authenticated identity in >> the response. For the authenticated identity we are using the >> P-Asserted-Identity. So we have two identities in a Response. >>> For our purposes the user provided identity in a final 200 >> OK response is sufficient. So that avoids confusion within >> forking cases. >> >> I haven't been paying close attention to this. What header are you >> planning to use to carry this callee provided identity? >> >> The Reply-To header would seem to be appropriate for this >> purpose, but >> unfortunately, according to table 2 of 3261, it is only >> allowed in INVITE. >> >> Paul >> >>> Roland >>> >>> >>> >>> >>>> -----Ursprüngliche Nachricht----- >>>> Von: Cullen Jennings [mailto:fluffy@cisco.com] >>>> Gesendet: Montag, 22. Mai 2006 17:32 >>>> An: Jesske, Roland >>>> Cc: John Elwell; sip@ietf.org; Roland Jesske; Christer >>>> Holmberg (JO/LMF) >>>> Betreff: Re: [Sip] Connected-identity and changing the To >>>> header field ina response >>>> >>>> >>>> >>>> On May 16, 2006, at 7:07 AM, Jesske, R wrote: >>>> >>>>> John, >>>>> it is that we don't can get an connected identity within >> the final >>>>> response of the initial INVITE. >>>>> Your draft proposes a mid dialog request for getting this >>>> information. >>>>> That is not usable for the TIP service. >>>> I think this is part of what I am not understanding. What is the >>>> requirement here? >>>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 01 10:19:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlnzW-0005KM-BD; Thu, 01 Jun 2006 10:17:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlnzU-0005J2-7Q for sip@ietf.org; Thu, 01 Jun 2006 10:17:36 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlnzT-00076E-SL for sip@ietf.org; Thu, 01 Jun 2006 10:17:36 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k51EHVlj025479; Thu, 1 Jun 2006 09:17:32 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 1 Jun 2006 15:17:31 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0130F6A27@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Paul Kyzivat , "Jesske, R" Subject: RE: AW: AW: [Sip] Connected-identity and changing the To header f ield ina response Date: Thu, 1 Jun 2006 15:17:27 +0100 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: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: fluffy@cisco.com, sip@ietf.org, john.elwell@siemens.com, roland.jesske@web.de, christer.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org So how would you deal with the interworking scenario with something = like the Reply-To header. For calling identity. An enterprise network at the calling side has an asserted identity for = the calling user (be it in Identity or P-Asserted-Identity). It wishes = to to send the call to the called user via the public network, and = ensure that the called user receives the asserted identity. The public = network uses P-Asserted-Identity but the enterprise network is not part = of the trust domain for P-Asserted-Identity. For connected identity. The enterprise network receives a call from the public network and = sends it to one of its users. The enterprise network has an asserted = identity for the called user (be it in Identity or = P-Asserted-Identity). It wishes to to ensure that the calling user = receives the asserted identity. The public network uses = P-Asserted-Identity but the enterprise network is not part of the trust = domain for P-Asserted-Identity. regards Keith > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 01 June 2006 14:43 > To: Jesske, R > Cc: fluffy@cisco.com; sip@ietf.org; john.elwell@siemens.com; > roland.jesske@web.de; christer.holmberg@ericsson.com > Subject: Re: AW: AW: [Sip] Connected-identity and changing=20 > the To header > field ina response >=20 >=20 > I don't know if Reply-To would be any better for your schedule than a = > new header. It will still require an RFC to make it legal to use in=20 > responses. But it would avoid bringing yet another new header=20 > into the=20 > world. >=20 > IMO, if the semantics are right, then it is better to reuse=20 > it than to=20 > invent something new. If the semantics are wrong, then it=20 > shouldn't be=20 > used. Based on my limited understanding of the usage, the=20 > semantics seem=20 > about right to me. >=20 > Paul >=20 > Jesske, R wrote: > > Paul, > > in the past we lookes also on the Reply-to header. But per=20 > definition it is the address where the user want to be=20 > connected. So it is not in each case the real conected=20 > identity. But the COLP (TIP) service could be used in the same way. > > So if it would be possible to use Reply-to header in=20 > Responses, if people are willing and we as TISPAN can narrow=20 > it then only to the real connected identity (within our=20 > walled garden service definition) I would be happy. > >=20 > > Best Regards > >=20 > > Roland > >=20 > >> -----Urspr=FCngliche Nachricht----- > >> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > >> Gesendet: Mittwoch, 31. Mai 2006 17:04 > >> An: Jesske, Roland > >> Cc: fluffy@cisco.com; sip@ietf.org; john.elwell@siemens.com;=20 > >> roland.jesske@web.de; christer.holmberg@ericsson.com > >> Betreff: Re: AW: [Sip] Connected-identity and changing the To=20 > >> header field ina response > >> > >> > >> > >> > >> Jesske, R wrote: > >>> These are the requirements we already expressed in our=20 > >> draft draft-jesske-sipping-tispan-requirements-02: > >>> REQ-TIP-1: In addition to any network asserted identity,=20 > >> it must be > >>> possible for the callee to indicate in a SIP=20 > >> response an > >>> additional identity where the user is=20 > >> reachable for future > >>> direct communications. Note that the=20 > >> requirement refers > >>> to the user, not to the same instance of the=20 > >> User Agent. > >>> REQ-TIP-2: The identity mentioned in REQ-TIP-1 must be=20 > >> formatted as a > >>> SIP URI [2] or TEL URL [3]. A translation=20 > >> between SIP URI > >>> and TEL URL by the network is not requested. > >>> REQ-TIP-3: The identity mentioned in REQ-TIP-1 is=20 > >> considered an end > >>> user supplied information that is not=20 > asserted by the > >>> network. > >>> > >>> > >>> As you can see we do not need any authenticated identity in=20 > >> the response. For the authenticated identity we are using the=20 > >> P-Asserted-Identity. So we have two identities in a Response. > >>> For our purposes the user provided identity in a final 200=20 > >> OK response is sufficient. So that avoids confusion within=20 > >> forking cases. > >> > >> I haven't been paying close attention to this. What header are you = > >> planning to use to carry this callee provided identity? > >> > >> The Reply-To header would seem to be appropriate for this=20 > >> purpose, but=20 > >> unfortunately, according to table 2 of 3261, it is only=20 > >> allowed in INVITE. > >> > >> Paul > >> > >>> Roland > >>> > >>> > >>> > >>> > >>>> -----Urspr=FCngliche Nachricht----- > >>>> Von: Cullen Jennings [mailto:fluffy@cisco.com]=20 > >>>> Gesendet: Montag, 22. Mai 2006 17:32 > >>>> An: Jesske, Roland > >>>> Cc: John Elwell; sip@ietf.org; Roland Jesske; Christer=20 > >>>> Holmberg (JO/LMF) > >>>> Betreff: Re: [Sip] Connected-identity and changing the To=20 > >>>> header field ina response > >>>> > >>>> > >>>> > >>>> On May 16, 2006, at 7:07 AM, Jesske, R wrote: > >>>> > >>>>> John, > >>>>> it is that we don't can get an connected identity within=20 > >> the final =20 > >>>>> response of the initial INVITE. > >>>>> Your draft proposes a mid dialog request for getting this=20 > >>>> information. > >>>>> That is not usable for the TIP service. > >>>> I think this is part of what I am not understanding.=20 > What is the =20 > >>>> requirement here? > >>>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol > >>> Use sip-implementors@cs.columbia.edu for questions on current sip > >>> Use sipping@ietf.org for new developments on the=20 > application of sip > >>> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of = sip > >> > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 01 11:01:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Floe7-00046s-FX; Thu, 01 Jun 2006 10:59:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Floe6-00045U-A2 for sip@ietf.org; Thu, 01 Jun 2006 10:59:34 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Floe4-0003cx-TJ for sip@ietf.org; Thu, 01 Jun 2006 10:59:34 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 01 Jun 2006 07:59:29 -0700 X-IronPort-AV: i="4.05,197,1146466800"; d="scan'208"; a="1817219196:sNHT8417585520" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k51ExT2q010116; Thu, 1 Jun 2006 07:59:29 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k51ExTKP005498; Thu, 1 Jun 2006 07:59:29 -0700 (PDT) Received: from [216.102.208.11] (sjc-vpn6-510.cisco.com [10.21.121.254]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k51Eu2q3014788; Thu, 1 Jun 2006 07:56:03 -0700 Message-ID: <447F00DD.2080500@cisco.com> Date: Thu, 01 Jun 2006 07:59:41 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: Wacky thead of the month award goes to ... Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <447911C5.7050805@softarmor.com> <17529.15626.334110.853151@rautu.tutpro.com> <200605290322.40468.dean.willis@softarmor.com> <1148929672.17999.5.camel@niagra.pingtel.com> <758F0645-1076-44CB-8121-05C921B9B335@cisco.com> <447C45F6.60907@cisco.com> <66C72342-79D2-4D0E-879C-FA1BE4EEA506@cisco.com> In-Reply-To: <66C72342-79D2-4D0E-879C-FA1BE4EEA506@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-2.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=3374; t=1149173969; x=1150037969; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:Michael=20Thomas=20 |Subject:Re=3A=20Wacky=20thead=20of=20the=20month=20award=20goes=20to=20...=20Re= 3A=20[Sip]=09draft-audet-sip-sips-guidelines=3A=0A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3D5Z3eXCg7lQqehgEB9HfS2i5thd0=3D; b=gFgCXCSilcvhroB7uU1CoR9EgaOmiGsF1vZieUc2iQ7acpym0rWbh7X049RjQWtbn0GjxHtW FhQ7GYgQiyUZqX8x8qbQtdqphkMLzh3PQEq2sEgLQN/tVmHBnBY2G/Ro; X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen Jennings wrote: > > Excellent question (definitely falls in my not wacky category) > > On May 30, 2006, at 6:17 AM, Michael Thomas wrote: > >> Cullen Jennings wrote: >> >>> sips is not the answer to every problem. >> >> >> My question is whether it's answer to _any_ problem. My last attempt at >> getting and answer was fruitless. What attacks do SIPS thwart in >> real life >> that honest operators and transport=tls doesn't? Real life good guy, >> bad guy >> situations would be helpful. >> >> Mike > > > I agree with your comment that as long as people can't say what they > are trying to accomplish, saying sips does or does not meet that is > pretty meaningless. > > The problem with transport=tls is that it only applies to one hop and > has no semantics that it get applied to the retarget. If it did, then > it would mean about the same as sips. > > I think it is fairly clear there are cases where you want to make > sure each hop is confidential protected and it is reasonable to trust > the proxies. Well, SIPS is _clearly_ not up for that task. But what about lazy, indifferent or incompetent proxies? That is, IMO, the real threat. All of this division into "trusted" and "evil" proxies doesn't cover the full range of possibilities in the real world. Do I trust a service provider proxy for example? Defining "trust" as "won't turn this message over to the NSA", then clearly I don't even if I trust them to route the message correctly. > Let me provide a simple example. In several cases we end up using the > to and from tags as cryptographic tokens that can be used for > authorization. For example, the typical way an INVITE with replaces > is authorized to replace an existing call is that the new INVITE > knows the to and from tag of the old call. sips can provide a way to > stop some attacker on the network form leaning these. (or just > learning what 1-900 numbers I was calling ). This is where we have a pretty fundamental disconnect: sips is not providing that, it's the good will of that proxy. What's even worse about this is that SIPS is having the perverse effect of discouraging proxies from doing the right thing unless they are explicitly asked. It should be the Best Current Practice that proxies forward requests with equivalent or better security. It should be the _norm_ that proxies forward with TLS/etc if possible, not the exception. > It's pretty easy for the UAC to control the protection on the first > hop. However, it needs a way to signal that the future hops are also > protected. SIPS is used to signal that. Why does this need to be signaled? Especially when there's no way that I can verify that they did the right thing? You're setting the wrong expectations for the user, and that I think is quite dangerous. > Now you could argue that there could have been several other ways to > signal this and I would agree. But I think there are plenty of > practical threats where you can show that being able to signal this, > and assuming proxies did the right thing, ^^^^^^^ Then lets just write a BCP that says that proxies should do the right thing. We should be promoting secure signaling in general, not in specific unenforceable cases. 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 Jun 01 11:37:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlpCm-0006q1-5I; Thu, 01 Jun 2006 11:35:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlpCk-0006pr-41 for sip@ietf.org; Thu, 01 Jun 2006 11:35:22 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlpCj-0007Yc-CK for sip@ietf.org; Thu, 01 Jun 2006 11:35:22 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 01 Jun 2006 08:35:21 -0700 X-IronPort-AV: i="4.05,198,1146466800"; d="scan'208"; a="1817249251:sNHT275460870" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k51FZI4f012188; Thu, 1 Jun 2006 08:35:18 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k51FZHIu013280; Thu, 1 Jun 2006 11:35:17 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Jun 2006 11:35:17 -0400 Received: from [161.44.79.149] ([161.44.79.149]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Jun 2006 11:35:17 -0400 Message-ID: <447F0934.2070205@cisco.com> Date: Thu, 01 Jun 2006 11:35:16 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Drage, Keith (Keith)" Subject: Re: AW: AW: [Sip] Connected-identity and changing the To header f ield ina response References: <475FF955A05DD411980D00508B6D5FB0130F6A27@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB0130F6A27@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 01 Jun 2006 15:35:17.0169 (UTC) FILETIME=[FBB9F210:01C68590] DKIM-Signature: a=rsa-sha1; q=dns; l=10043; t=1149176118; x=1150040118; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20AW=3A=20AW=3A=20[Sip]=20Connected-identity=20and=20changing=20th e=20To=20header=20f=0A=20ield=20ina=09response; X=v=3Dcisco.com=3B=20h=3DkMCYm8MOlT+z3Q+dpd5652m4/a0=3D; b=hkPEgHMYxuzKfo+8dV3JDhDN+QnN2ZZ6X0ACSb6Q0EW4/WsKO4cPVYVJx0W7DsP/T4hyBfUL mmEel+y2ulAD3ULYrlbJJjn5FGljRObj5fy4Dn+cJOM16ZTH21uUYLR1; Authentication-Results: sj-dkim-4.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: "Jesske, R" , fluffy@cisco.com, sip@ietf.org, john.elwell@siemens.com, roland.jesske@web.de, christer.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Drage, Keith (Keith) wrote: > So how would you deal with the interworking scenario with something like the Reply-To header. Keith - I am not at all certain I fully understand all the nuances of the case or what you would like to happen. > For calling identity. > > An enterprise network at the calling side has an asserted identity for the calling user (be it in Identity or P-Asserted-Identity). It wishes to to send the call to the called user via the public network, and ensure that the called user receives the asserted identity. The public network uses P-Asserted-Identity but the enterprise network is not part of the trust domain for P-Asserted-Identity. I guess you are saying that calling enterprise network is one trust domain that uses P-Asserted-ID, and the public network is a separate trust domain that also uses P-Asserted-ID. And I suppose the enterprise network trusts the public network, but not visa versa. In this case the public network will presumably want to assert *some* identity for the request once it is received from the enterprise network. The question is: how does the public network decide what to assert? When crossing the trust domain boundary this way, according to RFC 3325, the enterprise network should use P-Preferred-ID. Then the public network should authenticate the request in some way, and insert a P-Asserted-ID, ideally with the same value as found if the P-Preferred-ID if the authentication permits that. So, one answer would be for a proxy in the enterprise network to remove the P-Asserted-ID header that is valid in its network, and replace it with a P-Preferred-Identity having the same value, and then forward to the public network. If the public network is aware of the full range of addresses valid in the enterprise network, and has authenticated the request (possibly just the previous hop), it may then go ahead and convert the P-Preferred-ID back into a P-Asserted-ID. In that case no Refer-To is needed. Alternatively, proxy in the enterprise network could remove the P-Asserted-ID and insert a P-Preferred-ID containing a single address for the entire enterprise network. The public network would then still need to authenticate to determine whether to replace that P-Preferred-ID with the corresponding P-Asserted-ID again. The difference is that then the public network doesn't have to know the full range of addresses the enterprise network is allowed to use. It only needs to know one. If the caller knows its enterprise network behaves this way, and wants to communicate its own address, it could put it into a Reply-To header. (Or some other header that isn't authenticated.) The callee then MAY use that, rather than the P-Asserted-ID it receives, to identify the caller and to send subsequent requests to the caller. But no matter how you cut it, this technique is pretty weak in the guarantees it provides. (I may just decide to put "Reply-To: sip:drage@lucent.com" in all my calls.) If I was the recipient of such a call, using a UA with a form factor like a phone, I don't know what I would expect it to do with such an incoming call. If it can only display one callerid, then I think it should display what is asserted. Only if it can display two numbers, and show confidence levels for them, would I be inclined to show the Reply-To number. And its complicates all features that are based on the identity of the caller, since those are predicated on knowing a single address when in fact there is a choice of two addresses with different confidence levels. You end up needing two variants of the feature, e.g. "safe but maybe not useful callback" vs "unsafe but probably useful callback". So this approach is of questionable utility to me. IMO it would make way more sense for the public network to have enough data to validate that the address the enterprise network wants to assert is in fact one that it is permitted to assert. > For connected identity. Much the same issues as above. Paul > The enterprise network receives a call from the public network and sends it to one of its users. The enterprise network has an asserted identity for the called user (be it in Identity or P-Asserted-Identity). It wishes to to ensure that the calling user receives the asserted identity. The public network uses P-Asserted-Identity but the enterprise network is not part of the trust domain for P-Asserted-Identity. > > regards > > Keith > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 01 June 2006 14:43 >> To: Jesske, R >> Cc: fluffy@cisco.com; sip@ietf.org; john.elwell@siemens.com; >> roland.jesske@web.de; christer.holmberg@ericsson.com >> Subject: Re: AW: AW: [Sip] Connected-identity and changing >> the To header >> field ina response >> >> >> I don't know if Reply-To would be any better for your schedule than a >> new header. It will still require an RFC to make it legal to use in >> responses. But it would avoid bringing yet another new header >> into the >> world. >> >> IMO, if the semantics are right, then it is better to reuse >> it than to >> invent something new. If the semantics are wrong, then it >> shouldn't be >> used. Based on my limited understanding of the usage, the >> semantics seem >> about right to me. >> >> Paul >> >> Jesske, R wrote: >>> Paul, >>> in the past we lookes also on the Reply-to header. But per >> definition it is the address where the user want to be >> connected. So it is not in each case the real conected >> identity. But the COLP (TIP) service could be used in the same way. >>> So if it would be possible to use Reply-to header in >> Responses, if people are willing and we as TISPAN can narrow >> it then only to the real connected identity (within our >> walled garden service definition) I would be happy. >>> Best Regards >>> >>> Roland >>> >>>> -----Ursprüngliche Nachricht----- >>>> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Gesendet: Mittwoch, 31. Mai 2006 17:04 >>>> An: Jesske, Roland >>>> Cc: fluffy@cisco.com; sip@ietf.org; john.elwell@siemens.com; >>>> roland.jesske@web.de; christer.holmberg@ericsson.com >>>> Betreff: Re: AW: [Sip] Connected-identity and changing the To >>>> header field ina response >>>> >>>> >>>> >>>> >>>> Jesske, R wrote: >>>>> These are the requirements we already expressed in our >>>> draft draft-jesske-sipping-tispan-requirements-02: >>>>> REQ-TIP-1: In addition to any network asserted identity, >>>> it must be >>>>> possible for the callee to indicate in a SIP >>>> response an >>>>> additional identity where the user is >>>> reachable for future >>>>> direct communications. Note that the >>>> requirement refers >>>>> to the user, not to the same instance of the >>>> User Agent. >>>>> REQ-TIP-2: The identity mentioned in REQ-TIP-1 must be >>>> formatted as a >>>>> SIP URI [2] or TEL URL [3]. A translation >>>> between SIP URI >>>>> and TEL URL by the network is not requested. >>>>> REQ-TIP-3: The identity mentioned in REQ-TIP-1 is >>>> considered an end >>>>> user supplied information that is not >> asserted by the >>>>> network. >>>>> >>>>> >>>>> As you can see we do not need any authenticated identity in >>>> the response. For the authenticated identity we are using the >>>> P-Asserted-Identity. So we have two identities in a Response. >>>>> For our purposes the user provided identity in a final 200 >>>> OK response is sufficient. So that avoids confusion within >>>> forking cases. >>>> >>>> I haven't been paying close attention to this. What header are you >>>> planning to use to carry this callee provided identity? >>>> >>>> The Reply-To header would seem to be appropriate for this >>>> purpose, but >>>> unfortunately, according to table 2 of 3261, it is only >>>> allowed in INVITE. >>>> >>>> Paul >>>> >>>>> Roland >>>>> >>>>> >>>>> >>>>> >>>>>> -----Ursprüngliche Nachricht----- >>>>>> Von: Cullen Jennings [mailto:fluffy@cisco.com] >>>>>> Gesendet: Montag, 22. Mai 2006 17:32 >>>>>> An: Jesske, Roland >>>>>> Cc: John Elwell; sip@ietf.org; Roland Jesske; Christer >>>>>> Holmberg (JO/LMF) >>>>>> Betreff: Re: [Sip] Connected-identity and changing the To >>>>>> header field ina response >>>>>> >>>>>> >>>>>> >>>>>> On May 16, 2006, at 7:07 AM, Jesske, R wrote: >>>>>> >>>>>>> John, >>>>>>> it is that we don't can get an connected identity within >>>> the final >>>>>>> response of the initial INVITE. >>>>>>> Your draft proposes a mid dialog request for getting this >>>>>> information. >>>>>>> That is not usable for the TIP service. >>>>>> I think this is part of what I am not understanding. >> What is the >>>>>> requirement here? >>>>>> >>>>> _______________________________________________ >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP Protocol >>>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>>> Use sipping@ietf.org for new developments on the >> application of sip >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the application of sip >>>> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 01 12:48:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlqK8-0002Rn-70; Thu, 01 Jun 2006 12:47:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlqK6-0002Ri-QW for sip@ietf.org; Thu, 01 Jun 2006 12:47:02 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlqK5-0007Kh-Ua for sip@ietf.org; Thu, 01 Jun 2006 12:47:02 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 322EBDD2; Thu, 1 Jun 2006 18:45:39 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 18:45:38 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 18:45:37 +0200 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: AW: AW: [Sip] Connected-identity and changing the To header field ina response X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 1 Jun 2006 18:45:37 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F0FF4@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: AW: [Sip] Connected-identity and changing the To header field ina response Thread-Index: AcaFgVrNaDVAQrkcQwyFWNGC6mW7kAAGSGnQ From: "Christer Holmberg \(JO/LMF\)" To: "Paul Kyzivat" , "Jesske, R" X-OriginalArrivalTime: 01 Jun 2006 16:45:37.0621 (UTC) FILETIME=[CF4FD050:01C6859A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: fluffy@cisco.com, sip@ietf.org, john.elwell@siemens.com, roland.jesske@web.de X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Paul, One suggestion has been to modify the To header in the response. It has = been agreed on the list that it should not cause any harm to 3261 = compliant nodes because the To header is not used as a transaction = identifier. As, for the dialog identifier, only the tag parameter is = used (and that would not be modified). Regards, Christer -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: 1. kes=E4kuuta 2006 16:43 To: Jesske, R Cc: fluffy@cisco.com; sip@ietf.org; john.elwell@siemens.com; = roland.jesske@web.de; Christer Holmberg (JO/LMF) Subject: Re: AW: AW: [Sip] Connected-identity and changing the To header = field ina response I don't know if Reply-To would be any better for your schedule than a = new header. It will still require an RFC to make it legal to use in = responses. But it would avoid bringing yet another new header into the = world. IMO, if the semantics are right, then it is better to reuse it than to = invent something new. If the semantics are wrong, then it shouldn't be = used. Based on my limited understanding of the usage, the semantics seem = about right to me. Paul Jesske, R wrote: > Paul, > in the past we lookes also on the Reply-to header. But per definition = it is the address where the user want to be connected. So it is not in = each case the real conected identity. But the COLP (TIP) service could = be used in the same way. > So if it would be possible to use Reply-to header in Responses, if = people are willing and we as TISPAN can narrow it then only to the real = connected identity (within our walled garden service definition) I would = be happy. >=20 > Best Regards >=20 > Roland >=20 >> -----Urspr=FCngliche Nachricht----- >> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Gesendet: Mittwoch, 31. Mai 2006 17:04 >> An: Jesske, Roland >> Cc: fluffy@cisco.com; sip@ietf.org; john.elwell@siemens.com;=20 >> roland.jesske@web.de; christer.holmberg@ericsson.com >> Betreff: Re: AW: [Sip] Connected-identity and changing the To header=20 >> field ina response >> >> >> >> >> Jesske, R wrote: >>> These are the requirements we already expressed in our >> draft draft-jesske-sipping-tispan-requirements-02: >>> REQ-TIP-1: In addition to any network asserted identity, >> it must be >>> possible for the callee to indicate in a SIP >> response an >>> additional identity where the user is >> reachable for future >>> direct communications. Note that the >> requirement refers >>> to the user, not to the same instance of the >> User Agent. >>> REQ-TIP-2: The identity mentioned in REQ-TIP-1 must be >> formatted as a >>> SIP URI [2] or TEL URL [3]. A translation >> between SIP URI >>> and TEL URL by the network is not requested. >>> REQ-TIP-3: The identity mentioned in REQ-TIP-1 is >> considered an end >>> user supplied information that is not asserted by the >>> network. >>> >>> >>> As you can see we do not need any authenticated identity in >> the response. For the authenticated identity we are using the=20 >> P-Asserted-Identity. So we have two identities in a Response. >>> For our purposes the user provided identity in a final 200 >> OK response is sufficient. So that avoids confusion within forking=20 >> cases. >> >> I haven't been paying close attention to this. What header are you=20 >> planning to use to carry this callee provided identity? >> >> The Reply-To header would seem to be appropriate for this purpose,=20 >> but unfortunately, according to table 2 of 3261, it is only allowed=20 >> in INVITE. >> >> Paul >> >>> Roland >>> >>> >>> >>> >>>> -----Urspr=FCngliche Nachricht----- >>>> Von: Cullen Jennings [mailto:fluffy@cisco.com] >>>> Gesendet: Montag, 22. Mai 2006 17:32 >>>> An: Jesske, Roland >>>> Cc: John Elwell; sip@ietf.org; Roland Jesske; Christer Holmberg=20 >>>> (JO/LMF) >>>> Betreff: Re: [Sip] Connected-identity and changing the To header=20 >>>> field ina response >>>> >>>> >>>> >>>> On May 16, 2006, at 7:07 AM, Jesske, R wrote: >>>> >>>>> John, >>>>> it is that we don't can get an connected identity within >> the final >>>>> response of the initial INVITE. >>>>> Your draft proposes a mid dialog request for getting this >>>> information. >>>>> That is not usable for the TIP service. >>>> I think this is part of what I am not understanding. What is the=20 >>>> requirement here? >>>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use=20 >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20 >>> sipping@ietf.org for new developments on the application of sip >>> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use=20 >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 >> sipping@ietf.org for new developments on the application of sip >> >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 01 15:14:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlsbU-0006Pz-18; Thu, 01 Jun 2006 15:13:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlsbT-0006PG-7a for sip@ietf.org; Thu, 01 Jun 2006 15:13:07 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlsbR-0006gf-VN for sip@ietf.org; Thu, 01 Jun 2006 15:13:07 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k51JD1L28205; Thu, 1 Jun 2006 15:13:01 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Wacky thead of the month award goes to ... Re: [Sip]draft-audet-sip-sips-guidelines: Meaning of sips Date: Thu, 1 Jun 2006 14:12:53 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0A23505C@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Wacky thead of the month award goes to ... Re: [Sip]draft-audet-sip-sips-guidelines: Meaning of sips Thread-Index: AcaFOGgYplN4MfA/S1a9Horiy++GVAAdnz6Q From: "Francois Audet" To: "Cullen Jennings" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > Yes, the key thing we might want to change would be what happens on =20 > the link from the callees "home proxy" to to the UAS. We=20 > could decide =20 > that on this link sips means >=20 > a) some unspecified secure things > b) tls > c) tls or ipsec >=20 > Right now we have a - I suspect that we might want b or c. I think =20 > this is one of the key issues we need to sort out. Exactly. I'm open on both b) or c). >From my own bias I prefer b), but I'm also OK with c), especially if it satisfies some market segment (say, 3GPP or whatever). I don't like a) at all because it is too open. I would be open to something along the lines of=20 d) Security mechanisms specified by IETF to be appropriate. At the time of this writing, it means TLS or IPsec. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 01 16:33:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fltpw-00069k-CE; Thu, 01 Jun 2006 16:32:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fltpv-00069N-Bp; Thu, 01 Jun 2006 16:32:07 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FltM6-0002Sd-Az; Thu, 01 Jun 2006 16:01:18 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=oak.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FltBC-0007Jm-AU; Thu, 01 Jun 2006 15:50:09 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k51Jo1WR003735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FltBB-0001X4-R8; Thu, 01 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 01 Jun 2006 15:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-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: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Diagnostic Responses for SIP Hop Limit Errors Author(s) : S. Lawrence, et al. Filename : draft-ietf-sip-hop-limit-diagnostics-01.txt Pages : 12 Date : 2006-6-1 The SIP protocol imposes a limit on the number of hops a request may make from a sender to the recipient. When this limit is reached, a 483 error response is returned. The present form of the 483 response does not provide enough information for the sender or proxies on the path to diagnose failures whose symptom is that the hop limit is reached. This document proposes additional diagnostic information to be returned in a 483 response. Comments are solicited, and should be directed to the SIP working group list at 'sip@ietf.org'. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-hop-limit-diagnostics-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-hop-limit-diagnostics-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-hop-limit-diagnostics-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-1142523.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-hop-limit-diagnostics-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-hop-limit-diagnostics-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-1142523.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Thu Jun 01 16:57:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FluCo-0007Ti-RE; Thu, 01 Jun 2006 16:55:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FluCQ-0005Tt-Mm for sip@ietf.org; Thu, 01 Jun 2006 16:55:22 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FltzH-0000HA-L2 for sip@ietf.org; Thu, 01 Jun 2006 16:41:48 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 01 Jun 2006 13:41:47 -0700 X-IronPort-AV: i="4.05,199,1146466800"; d="scan'208"; a="1817496074:sNHT33655604" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k51Kfkdj010806; Thu, 1 Jun 2006 13:41:46 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k51Kfkku011363; Thu, 1 Jun 2006 16:41:46 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Jun 2006 16:41:46 -0400 Received: from [161.44.79.149] ([161.44.79.149]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Jun 2006 16:41:45 -0400 Message-ID: <447F5109.3050603@cisco.com> Date: Thu, 01 Jun 2006 16:41:45 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Francois Audet Subject: Re: Wacky thead of the month award goes to ... Re: [Sip]draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF0A23505C@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0A23505C@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jun 2006 20:41:45.0880 (UTC) FILETIME=[CC409180:01C685BB] DKIM-Signature: a=rsa-sha1; q=dns; l=1716; t=1149194507; x=1150058507; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20Wacky=20thead=20of=20the=20month=20award=20goes=20to=20...=20Re= 3A=09[Sip]draft-audet-sip-sips-guidelines=3A=0A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3DEJkuLZ24/uA05EEZ4BYxUbBV7HI=3D; b=eEGZCzf3pY6ZxjSWAve59uKOuuyuEnj6f9CCQXOmsZ5/+y+Dp2QPaNuNVr/OI72ONp1PE8pV VHTGFj4p9xKr8P8gwI/K333qwt28vib4aUp3nRWOH01c+jzIw2lgapON; Authentication-Results: sj-dkim-2.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Cullen Jennings , Sip , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I would be ok with something like (d). Or perhaps just a specification of the characteristics that must be met without specifying the protocol used to achieve them. The latter would be just a tightening up of (a). Whichever of those, why is it applicable only downstream of the callee's home proxy? Why shouldn't this be valid between caller and its proxy? Or on any hop along the way? It seems like TLS is important as a protocol of last resort, when all you know about contacting the next hop is learned via 3263. Paul Francois Audet wrote: > >> Yes, the key thing we might want to change would be what happens on >> the link from the callees "home proxy" to to the UAS. We >> could decide >> that on this link sips means >> >> a) some unspecified secure things >> b) tls >> c) tls or ipsec >> >> Right now we have a - I suspect that we might want b or c. I think >> this is one of the key issues we need to sort out. > > Exactly. > > I'm open on both b) or c). > >>From my own bias I prefer b), but I'm also OK with c), especially if it > satisfies some > market segment (say, 3GPP or whatever). > > I don't like a) at all because it is too open. > > I would be open to something along the lines of > > d) Security mechanisms specified by IETF to be appropriate. At the time > of this writing, > it means TLS or IPsec. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 01 22:02:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlyxT-00006h-11; Thu, 01 Jun 2006 22:00:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlyxR-0008Sd-2c for sip@ietf.org; Thu, 01 Jun 2006 22:00:13 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlyxP-0001sh-Oi for sip@ietf.org; Thu, 01 Jun 2006 22:00:13 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k521sww02805; Thu, 1 Jun 2006 21:54:58 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Wacky thead of the month award goes to ... Re: [Sip]draft-audet-sip-sips-guidelines: Meaning of sips Date: Thu, 1 Jun 2006 21:00:05 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0A2E72C7@zrc2hxm0.corp.nortel.com> In-Reply-To: <447F5109.3050603@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Wacky thead of the month award goes to ... Re: [Sip]draft-audet-sip-sips-guidelines: Meaning of sips Thread-Index: AcaFvJPpCTQB2R46RSe5/5SeFAYSXAAK2tSA From: "Francois Audet" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Cullen Jennings , Sip , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm not sure I understand your point about "protocol of last resort". And yes, in my mind, it would be applicable end-to-end accross all hops (including upstream to the outbound proxy). I agree. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Thursday, June 01, 2006 13:42 > To: Audet, Francois [SC100:3055:EXCH] > Cc: Cullen Jennings; Dean Willis; Sip > Subject: Re: Wacky thead of the month award goes to ... Re:=20 > [Sip]draft-audet-sip-sips-guidelines: Meaning of sips >=20 >=20 > I would be ok with something like (d). Or perhaps just a=20 > specification=20 > of the characteristics that must be met without specifying=20 > the protocol=20 > used to achieve them. The latter would be just a tightening up of (a). >=20 > Whichever of those, why is it applicable only downstream of=20 > the callee's=20 > home proxy? Why shouldn't this be valid between caller and=20 > its proxy? Or=20 > on any hop along the way? >=20 > It seems like TLS is important as a protocol of last resort, when all=20 > you know about contacting the next hop is learned via 3263. >=20 > Paul >=20 > Francois Audet wrote: > >=20 > >> Yes, the key thing we might want to change would be what happens on > >> the link from the callees "home proxy" to to the UAS. We=20 > >> could decide =20 > >> that on this link sips means > >> > >> a) some unspecified secure things > >> b) tls > >> c) tls or ipsec > >> > >> Right now we have a - I suspect that we might want b or c. I think > >> this is one of the key issues we need to sort out. > >=20 > > Exactly. > >=20 > > I'm open on both b) or c). > >=20 > >>From my own bias I prefer b), but I'm also OK with c),=20 > especially if=20 > >>it > > satisfies some > > market segment (say, 3GPP or whatever). > >=20 > > I don't like a) at all because it is too open. > >=20 > > I would be open to something along the lines of > >=20 > > d) Security mechanisms specified by IETF to be appropriate. At the=20 > > time of this writing, > > it means TLS or IPsec. > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 02 02:12:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm2s5-000743-Ry; Fri, 02 Jun 2006 02:10:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm2nr-00042g-Ru for sip@ietf.org; Fri, 02 Jun 2006 02:06:35 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm2Y5-0000es-3N for sip@ietf.org; Fri, 02 Jun 2006 01:50:21 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Fri, 2 Jun 2006 07:50:12 +0200 Received: by S4DE8PSAANQ.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Jun 2006 07:50:12 +0200 Message-Id: <85108216918A984C8C60172D7C84770A08A537@S4DE8PSAAGO.mitte.t-com.de> From: "Jesske, R" To: oran@cisco.com Subject: AW: AW: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt Date: Fri, 2 Jun 2006 07:50:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: fluffy@cisco.com, chister.holmberg@ericsson.com, sip@ietf.org, esasaki@NTT-AT.COM, john.elwell@siemens.com, christer.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Urspr=FCngliche Nachricht----- > Von: David R Oran [mailto:oran@cisco.com]=20 > Gesendet: Donnerstag, 1. Juni 2006 15:04 > An: Jesske, Roland > Cc: fluffy@cisco.com; sip@ietf.org; esasaki@NTT-AT.COM;=20 > chister.holmberg@ericsson.com; john.elwell@siemens.com;=20 > christer.holmberg@ericsson.com > Betreff: Re: AW: [Sip] Issue 1 in=20 > draft-ietf-sip-connected-identity-00.txt >=20 >=20 >=20 > On May 31, 2006, at 2:03 AM, Jesske, R wrote: >=20 > > The problem is that we try to solve two different approaches. > > 1. The identity approach to get back an authenticated identity of =20 > > the connected user > > 2. To get back an "additional connected identity" that is =20 > > unauthenticated and provided by the user. > > > Doesn't (2) sound like the job for a body, not a header? You could =20 > send a picture, your C.V., a voiceprint - anything you want. In the PSTN it is a full E164 number so we need an SIP uri/ tel uri. = For us it must be interopeable. Roland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 02 07:49:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm885-0004yW-II; Fri, 02 Jun 2006 07:47:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm884-0004yR-FO for sip@ietf.org; Fri, 02 Jun 2006 07:47:48 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm882-0003Dp-58 for sip@ietf.org; Fri, 02 Jun 2006 07:47:48 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 02 Jun 2006 04:47:46 -0700 X-IronPort-AV: i="4.05,203,1146466800"; d="scan'208"; a="429636983:sNHT33289688" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k52Blj8K027491; Fri, 2 Jun 2006 04:47:45 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k52BljKP000550; Fri, 2 Jun 2006 04:47:45 -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 k52BiGEY010096; Fri, 2 Jun 2006 04:44:16 -0700 In-Reply-To: <85108216918A984C8C60172D7C84770A08A537@S4DE8PSAAGO.mitte.t-com.de> References: <85108216918A984C8C60172D7C84770A08A537@S4DE8PSAAGO.mitte.t-com.de> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <7F8FD6D5-4F02-4977-8390-D77B2A7C4C1D@cisco.com> Content-Transfer-Encoding: quoted-printable From: David R Oran Subject: Re: AW: AW: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt Date: Fri, 2 Jun 2006 07:47:40 -0400 To: "Jesske, R" X-Mailer: Apple Mail (2.750) Authentication-Results: sj-dkim-3.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1997; t=1149248865; x=1150112865; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20AW=3A=20AW=3A=20[Sip]=20Issue=201=20in=20draft-ietf-sip-connecte d-identity-00.txt; X=v=3Dcisco.com=3B=20h=3D6sJG4OlwkZuUJksAmsRdRizVjdU=3D; b=a5CBVPDMpIOxFjzav1CLoslfPegqU6KjbrT5UIHx2nEzrCgT3Rv2RJJpFgEjSw9asKFJKplv A5tXkxip8yqAyH/i3XY/V9vIlIi2IW5MiZL7R4hU3ZNOC8O3DvrZcQRQ; X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: fluffy@cisco.com, chister.holmberg@ericsson.com, sip@ietf.org, esasaki@NTT-AT.COM, john.elwell@siemens.com, christer.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 2, 2006, at 1:50 AM, Jesske, R wrote: > > >> -----Urspr=FCngliche Nachricht----- >> Von: David R Oran [mailto:oran@cisco.com] >> Gesendet: Donnerstag, 1. Juni 2006 15:04 >> An: Jesske, Roland >> Cc: fluffy@cisco.com; sip@ietf.org; esasaki@NTT-AT.COM; >> chister.holmberg@ericsson.com; john.elwell@siemens.com; >> christer.holmberg@ericsson.com >> Betreff: Re: AW: [Sip] Issue 1 in >> draft-ietf-sip-connected-identity-00.txt >> >> >> >> On May 31, 2006, at 2:03 AM, Jesske, R wrote: >> >>> The problem is that we try to solve two different approaches. >>> 1. The identity approach to get back an authenticated identity of >>> the connected user >>> 2. To get back an "additional connected identity" that is >>> unauthenticated and provided by the user. >>> >> Doesn't (2) sound like the job for a body, not a header? You could >> send a picture, your C.V., a voiceprint - anything you want. > > In the PSTN it is a full E164 number so we need an SIP uri/ tel =20 > uri. For us it must be interopeable. > So, in the case of the PSTN send a text/uri body type in the response =20= and put a Tel uri in it. The point is that if I'm NOT talking to the =20 PSTN the "connected identity" doesn't have to be an E.164 number. And =20= by the way, if this is unauthenticated and asserted by the whoever, =20 how can you tell it's an E.164 number, other than in a syntactic sense? This header-containing-identities thing could have no end. I might =20 want to send my identity, the identity of my secretary, the identity =20 of my lawyer, etc. etc. I would have less problem with header if it had different semantics =20 (in fact I'm not sure if even in the PSTN case the semantics of =20 "connected identity" are well defined). If it really was a "if you =20 want to call again in the future, use this URI" then I'd be =20 moderately OK with using a "Reply-To" header, although as Paul K. =20 points out, it's bit of a stretch. > > Roland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 02 10:26:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmAZW-00018D-GL; Fri, 02 Jun 2006 10:24:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmAZV-000187-6y for sip@ietf.org; Fri, 02 Jun 2006 10:24:17 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm9Lf-0003Wk-C9 for sip@ietf.org; Fri, 02 Jun 2006 09:05:55 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fm973-0003f7-1C for sip@ietf.org; Fri, 02 Jun 2006 08:50:51 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 02 Jun 2006 05:50:48 -0700 X-IronPort-AV: i="4.05,203,1146466800"; d="scan'208"; a="1818001483:sNHT139558690" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k52ComSR006228; Fri, 2 Jun 2006 05:50:48 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k52Cofcd001909; Fri, 2 Jun 2006 05:50:47 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Jun 2006 08:50:47 -0400 Received: from [161.44.79.149] ([161.44.79.149]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Jun 2006 08:50:46 -0400 Message-ID: <44803426.9000102@cisco.com> Date: Fri, 02 Jun 2006 08:50:46 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Francois Audet Subject: Re: Wacky thead of the month award goes to ... Re: [Sip]draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF0A2E72C7@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0A2E72C7@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jun 2006 12:50:46.0698 (UTC) FILETIME=[2AE158A0:01C68643] DKIM-Signature: a=rsa-sha1; q=dns; l=2728; t=1149252648; x=1150116648; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20Wacky=20thead=20of=20the=20month=20award=20goes=20to=20...=20Re= 3A=20[Sip]draft-audet-sip-sips-guidelines=3A=0A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3DEJkuLZ24/uA05EEZ4BYxUbBV7HI=3D; b=lAjcXlpYT1JhXKaDBvl6KasnTwTbAaPIl9DXS9s3H7pXANBhAg3AzmKlZKNoN2tA4tMCCQo+ FletpfNSW+iflewVpvtxsHj8we/GFes7jl7rvLcq1ZwQehhaLvkyk2GX; Authentication-Results: sj-dkim-8.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.2 (--) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Cullen Jennings , Sip , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois Audet wrote: > I'm not sure I understand your point about "protocol of last resort". What I mean is that TLS (over TCP) is a protocol that can be used with somebody you have no prior relationship with. The other likely candidates aren't like that - e.g. you would need some other agreement to know how to set up an IPSec relationship. > And yes, in my mind, it would be applicable end-to-end accross all hops > (including upstream to the outbound proxy). I agree. Hey, we arent' supposed to *agree*! :-) Paul >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Thursday, June 01, 2006 13:42 >> To: Audet, Francois [SC100:3055:EXCH] >> Cc: Cullen Jennings; Dean Willis; Sip >> Subject: Re: Wacky thead of the month award goes to ... Re: >> [Sip]draft-audet-sip-sips-guidelines: Meaning of sips >> >> >> I would be ok with something like (d). Or perhaps just a >> specification >> of the characteristics that must be met without specifying >> the protocol >> used to achieve them. The latter would be just a tightening up of (a). >> >> Whichever of those, why is it applicable only downstream of >> the callee's >> home proxy? Why shouldn't this be valid between caller and >> its proxy? Or >> on any hop along the way? >> >> It seems like TLS is important as a protocol of last resort, when all >> you know about contacting the next hop is learned via 3263. >> >> Paul >> >> Francois Audet wrote: >>>> Yes, the key thing we might want to change would be what happens on >>>> the link from the callees "home proxy" to to the UAS. We >>>> could decide >>>> that on this link sips means >>>> >>>> a) some unspecified secure things >>>> b) tls >>>> c) tls or ipsec >>>> >>>> Right now we have a - I suspect that we might want b or c. I think >>>> this is one of the key issues we need to sort out. >>> Exactly. >>> >>> I'm open on both b) or c). >>> >>> >From my own bias I prefer b), but I'm also OK with c), >> especially if >>>> it >>> satisfies some >>> market segment (say, 3GPP or whatever). >>> >>> I don't like a) at all because it is too open. >>> >>> I would be open to something along the lines of >>> >>> d) Security mechanisms specified by IETF to be appropriate. At the >>> time of this writing, >>> it means TLS or IPsec. >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on >> current sip Use >>> sipping@ietf.org for new developments on the application of sip >>> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 02 11:21:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmBRE-0001p3-8I; Fri, 02 Jun 2006 11:19:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmBRC-0001oy-UZ for sip@ietf.org; Fri, 02 Jun 2006 11:19:46 -0400 Received: from zeus.digiweb.ie ([83.147.147.9] helo=dlk-exchange-01.dlk-office.digiweb.ie) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FmBRB-0007Jl-J0 for sip@ietf.org; Fri, 02 Jun 2006 11:19:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Jun 2006 16:19:09 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: problems with Fritz ATA (sipx 3.1) Thread-Index: AcaGV+UqSNirrmagS2+LixpLFgx2xQ== From: "Michal Suchon" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: [Sip] problems with Fritz ATA (sipx 3.1) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi=20 I am trying to use Fritz Box fon ata with sipX version 3.1 and I am getting very strange error in sipproxy.log: "2006-06-02T14:34:49.715408Z":944:SIP:CRIT:sip.web.ie:SipClient-8:B7A7CB B0:SipAuthProxy:"SipTransaction::handleChildIncoming 180 response with parent client transaction NOT dispatched". I found a similar bug description but I am not sure if it is the same case.=20 Every other ATA that I have (Linksys,Grandstream) works fine (I can call and I can be called).=20 When I try to call I get that: 1 14.714475 89.234.130.151 -> 89.234.161.91 SIP/SDP Request: INVITE sip:0249393343@sip.web.ie, with session description 2 14.717415 89.234.161.91 -> 89.234.130.151 SIP Status: 100 Trying 3 14.742250 89.234.161.91 -> 89.234.130.151 SIP Status: 407 Proxy Authentication Required 4 14.793294 89.234.130.151 -> 89.234.161.91 SIP Request: ACK sip:0249393343@sip.web.ie 5 14.827272 89.234.130.151 -> 89.234.161.91 SIP/SDP Request: INVITE sip:0249393343@sip.web.ie, with session description 6 14.830011 89.234.161.91 -> 89.234.130.151 SIP Status: 100 Trying 7 14.851127 89.234.161.91 -> 89.234.162.132 SIP/SDP Request: INVITE sip:0249393343@89.234.162.132, with session description 8 14.859748 89.234.162.132 -> 89.234.161.91 SIP Status: 100 Trying 9 14.865244 89.234.162.132 -> 89.234.161.91 SIP/SDP Request: INVITE sip:0249393343@sip.web.ie:5060, with session description 10 14.869296 89.234.161.91 -> 89.234.162.132 SIP Status: 100 Trying 11 14.886632 89.234.161.91 -> 89.234.162.132 SIP Status: 407 Proxy Authentication Required 12 14.892349 89.234.162.132 -> 89.234.161.91 SIP Request: ACK sip:0249393343@sip.web.ie:5060 13 15.912509 89.234.162.132 -> 89.234.161.91 SIP Status: 180 Ringing 14 15.916303 89.234.161.91 -> 89.234.130.151 SIP Status: 180 Ringing 15 15.972215 89.234.130.151 -> 89.234.161.91 SIP Request: PRACK sip:0249393343@89.234.162.132:5060 16 15.975032 89.234.161.91 -> 89.234.130.151 SIP Status: 403 Not authorized for ValidUserValidUserValidUser+ValidUserValidUserValidUser 17 16.017438 89.234.130.151 -> 89.234.161.91 SIP Request: CANCEL sip:0249393343@sip.web.ie 18 16.021828 89.234.161.91 -> 89.234.162.132 SIP Request: CANCEL sip:0249393343@89.234.162.132 When I am being called it works ok: 33 285.686568 89.234.161.91 -> 89.234.130.151 SIP/SDP Request: INVITE sip:0249340098@89.234.130.151;uniq=3D60DA60530128E1331B93FDB09CBA, with session description 34 285.693808 89.234.161.91 -> 89.234.164.171 SIP/SDP Request: INVITE sip:0249340098@89.234.164.171;uniq=3D816AB8879BAC6221798AC8482C89, with session description 35 285.819887 89.234.130.151 -> 89.234.161.91 SIP Status: 180 Ringing 36 285.827221 89.234.161.91 -> 89.234.162.132 SIP Status: 180 Ringing 37 286.074335 89.234.164.171 -> 89.234.161.91 SIP Status: 180 Ringing 38 286.081634 89.234.161.91 -> 89.234.162.132 SIP Status: 180 Ringing 39 289.037627 89.234.130.151 -> 89.234.161.91 SIP/SDP Status: 200 OK, with session description 40 289.047505 89.234.161.91 -> 89.234.164.171 SIP Request: CANCEL sip:0249340098@89.234.164.171;uniq=3D816AB8879BAC6221798AC8482C89 41 289.050609 89.234.161.91 -> 89.234.162.132 SIP/SDP Status: 200 OK, with session description 42 289.055736 89.234.162.132 -> 89.234.161.91 SIP Request: ACK sip:0249340098@89.234.130.151:5060;uniq=3D60DA60530128E1331B93FDB09CBA 43 289.058975 89.234.161.91 -> 89.234.130.151 SIP Request: ACK sip:0249340098@89.234.130.151:5060;uniq=3D60DA60530128E1331B93FDB09CBA 44 289.093214 89.234.161.91 -> 89.234.164.171 SIP Request: ACK sip:0249340098@89.234.164.171;uniq=3D816AB8879BAC6221798AC8482C89 45 294.287437 89.234.162.132 -> 89.234.161.91 SIP Request: BYE sip:0249340098@89.234.130.151:5060;uniq=3D60DA60530128E1331B93FDB09CBA 46 294.291391 89.234.161.91 -> 89.234.130.151 SIP Request: BYE sip:0249340098@89.234.130.151:5060;uniq=3D60DA60530128E1331B93FDB09CBA Help. Michal _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 02 12:39:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmCeA-0003qi-Hs; Fri, 02 Jun 2006 12:37:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmCe8-0003oT-H5 for sip@ietf.org; Fri, 02 Jun 2006 12:37:12 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmC1s-0005R6-3U for sip@ietf.org; Fri, 02 Jun 2006 11:57:40 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FmBnu-0006TF-FN for sip@ietf.org; Fri, 02 Jun 2006 11:43:15 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id A20D16C017 for ; Fri, 2 Jun 2006 11:43:12 -0400 (EDT) Subject: Re: [Sip] problems with Fritz ATA (sipx 3.1) From: "Dale R. Worley" To: Sip In-Reply-To: References: Content-Type: text/plain Date: Fri, 02 Jun 2006 11:43:12 -0400 Message-Id: <1149262992.21971.12.camel@niagra.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: -2.5 (--) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Fri, 2006-06-02 at 16:19 +0100, Michal Suchon wrote: > I am trying to use Fritz Box fon ata with sipX version 3.1 and I am > getting very strange error in sipproxy.log: > > "2006-06-02T14:34:49.715408Z":944:SIP:CRIT:sip.web.ie:SipClient-8:B7A7CB > B0:SipAuthProxy:"SipTransaction::handleChildIncoming 180 response with > parent client transaction NOT dispatched". I found a similar bug > description but I am not sure if it is the same case. It's more useful to ask these questions on sipx-users@sipfoundry.org. But it turns out that these messages are not important. Later versions of sipX cure the problem, IIRC. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 02 15:52:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFfA-0001T1-GV; Fri, 02 Jun 2006 15:50:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFem-0000ul-Iz; Fri, 02 Jun 2006 15:50:04 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmFek-0004G4-Bj; Fri, 02 Jun 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k52Jo2Rx010848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FmFek-0008IV-55; Fri, 02 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 02 Jun 2006 15:50:02 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Diagnostic Responses for SIP Hop Limit Errors Author(s) : S. Lawrence, et al. Filename : draft-ietf-sip-hop-limit-diagnostics-02.txt Pages : 12 Date : 2006-6-2 The SIP protocol imposes a limit on the number of hops a request may make from a sender to the recipient. When this limit is reached, a 483 error response is returned. The present form of the 483 response does not provide enough information for the sender or proxies on the path to diagnose failures whose symptom is that the hop limit is reached. This document proposes additional diagnostic information to be returned in a 483 response. Comments are solicited, and should be directed to the SIP working group list at 'sip@ietf.org'. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-hop-limit-diagnostics-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-hop-limit-diagnostics-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-hop-limit-diagnostics-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-2141354.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-hop-limit-diagnostics-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-hop-limit-diagnostics-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-2141354.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Fri Jun 02 17:49:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmHUu-0005T3-Es; Fri, 02 Jun 2006 17:48:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmHUt-0005Sy-Fw for sip@ietf.org; Fri, 02 Jun 2006 17:47:59 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmGQX-0002cD-MZ for sip@ietf.org; Fri, 02 Jun 2006 16:39:25 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FmGNH-0003Ae-Nf for sip@ietf.org; Fri, 02 Jun 2006 16:36:05 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 36A8C6C01C for ; Fri, 2 Jun 2006 16:36:03 -0400 (EDT) From: Scott Lawrence To: sip@ietf.org In-Reply-To: References: Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Fri, 02 Jun 2006 16:36:02 -0400 Message-Id: <1149280562.29816.19.camel@sukothai.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Sip] Re:draft-ietf-sip-hop-limit-diagnostics-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > Title : Diagnostic Responses for SIP Hop Limit Errors > The SIP protocol imposes a limit on the number of hops a request may > make from a sender to the recipient. When this limit is reached, a > 483 error response is returned. The present form of the 483 response > does not provide enough information for the sender or proxies on the > path to diagnose failures whose symptom is that the hop limit is > reached. This document proposes additional diagnostic information to > be returned in a 483 response. I believe this version addresses all the comments received on the -00 draft (which was actually the second publication; the first was part of the SIPPING draft draft-lawrence-maxforward-problems-00.txt). Specifically, it: - Adds a Warning header to identify the system at which the hop limit was reached. - Provides a suggested way to trim the returned message, should that be needed for size or security reasons. (the difference between -01 and -02 was just an editorial error in the author contact information) Other than the issues addressed above (which were both good suggestions), this has, I think, been non-controversial. I believe that it is ready for a Working Group Last Call. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.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 Jun 02 18:52:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmITi-0007nz-Hk; Fri, 02 Jun 2006 18:50:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmITM-00077D-FG for sip@ietf.org; Fri, 02 Jun 2006 18:50:28 -0400 Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmITL-0000kF-6u for sip@ietf.org; Fri, 02 Jun 2006 18:50:28 -0400 Received: (qmail 31766 invoked by uid 510); 2 Jun 2006 18:31:51 -0400 Received: from henry@pulver.com by mail.pulver.com by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.72. spamassassin: 2.63. Clear:RC:1(24.1.140.191):. Processed in 1.010174 secs); 02 Jun 2006 22:31:51 -0000 X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(24.1.140.191):. Processed in 1.010174 secs Process 31761) Received: from c-24-1-140-191.hsd1.tx.comcast.net (HELO DSX400) (henry@pulver.com@24.1.140.191) by 192.246.69.184 with SMTP; Fri, 02 Jun 2006 22:31:50 +0000 From: "Henry Sinnreich" To: Date: Fri, 2 Jun 2006 17:50:25 -0500 Organization: pulver.com Message-ID: <00ba01c68696$eff6c0a0$2800a8c0@DSX400> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 thread-index: AcaGluGLq/8Ol+uDS6GqiVvEs84YtA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Sip] draft-poretsky-sip-bench-term-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: henry@pulver.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The new I-D "Terminology for Benchmarking SIP Networking Devices", see http://www.ietf.org/internet-drafts/draft-poretsky-sip-bench-term-00.txt talks about items on the Internet that are not documented in any RFC, such as the SIP Control Plane and the SIP Media Plane. - How does this fit with the Internet e2e architecture? - Are such planes defined in any SIP related RFC or elsewhere in the IETF? - What are the two dimensions for each plane? - Can there be a black box benchmark without describing its behavior (for example the behavior of a SIP proxy is well documented)? There are several other concepts that have no definition in the IETF, though they have a familiar ring from ITU-T documents. Thanks, Henry _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 03 09:11:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmVs8-0005ou-0A; Sat, 03 Jun 2006 09:08:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmVs5-0005op-Qd for sip@ietf.org; Sat, 03 Jun 2006 09:08:53 -0400 Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmVs3-00005t-J0 for sip@ietf.org; Sat, 03 Jun 2006 09:08:53 -0400 Received: by email.quarrytech.com with Internet Mail Service (5.5.2653.19) id ; Sat, 3 Jun 2006 09:01:54 -0400 Message-ID: <496A8683261CD211BF6C0008C733261A0803CB6D@email.quarrytech.com> From: sporetsky@reefpoint.com To: henry@pulver.com, sip@ietf.org Subject: RE: [Sip] draft-poretsky-sip-bench-term-00.txt Date: Sat, 3 Jun 2006 09:01:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: acmorton@att.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The BMWG Charter can be found at the following link: http://www.ietf.org/html.charters/bmwg-charter.html The companion Methodology document will also be posted before the deadline. Scott -----Original Message----- From: Henry Sinnreich [mailto:henry@pulver.com] Sent: Friday, June 02, 2006 6:50 PM To: sip@ietf.org Subject: [Sip] draft-poretsky-sip-bench-term-00.txt The new I-D "Terminology for Benchmarking SIP Networking Devices", see http://www.ietf.org/internet-drafts/draft-poretsky-sip-bench-term-00.txt talks about items on the Internet that are not documented in any RFC, such as the SIP Control Plane and the SIP Media Plane. - How does this fit with the Internet e2e architecture? - Are such planes defined in any SIP related RFC or elsewhere in the IETF? - What are the two dimensions for each plane? - Can there be a black box benchmark without describing its behavior (for example the behavior of a SIP proxy is well documented)? There are several other concepts that have no definition in the IETF, though they have a familiar ring from ITU-T documents. Thanks, Henry _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 03 18:37:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmeiG-0006qm-VB; Sat, 03 Jun 2006 18:35:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmeiF-0006oS-7D for sip@ietf.org; Sat, 03 Jun 2006 18:35:19 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmefS-0003oL-BO for sip@ietf.org; Sat, 03 Jun 2006 18:32:27 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 03 Jun 2006 15:32:26 -0700 X-IronPort-AV: i="4.05,206,1146466800"; d="scan'208"; a="288381535:sNHT34721148" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k53MWP1q031285; Sat, 3 Jun 2006 15:32:25 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k53MWPKP004417; Sat, 3 Jun 2006 15:32:25 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 3 Jun 2006 15:32:25 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.144.242]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 3 Jun 2006 15:32:24 -0700 Message-Id: <4.3.2.7.2.20060603172827.027649d0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 03 Jun 2006 17:32:23 -0500 To: "Brian Rosen" , "'Tschofenig, Hannes'" , "'Hannes Tschofenig'" , From: "James M. Polk" In-Reply-To: <07e801c67db7$c98bb020$640fa8c0@cis.neustar.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 03 Jun 2006 22:32:24.0823 (UTC) FILETIME=[96326070:01C6875D] DKIM-Signature: a=rsa-sha1; q=dns; l=3420; t=1149373945; x=1150237945; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:RE=3A=20[Geopriv]=20Explicit=20Indication=20of=20Location=20Object=20Con sumer; X=v=3Dcisco.com=3B=20h=3DI9O08AmKtkI4AWfqf2lKdRGeHno=3D; b=YkKuZy4NbXxZv7K02sKYc+HzthT2BPI/t7cXQZHIz5L9I8oc4v3Mc7Lo9HaY66uBKK90jr6O lMNr4WH2AYeO+SZYjhOvxnwe+ZzczEsTeTydQPmteyPindWII9tQC76z; Authentication-Results: sj-dkim-1.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: Subject: [Sip] RE: [Geopriv] Explicit Indication of Location Object Consumer X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org [took Geopriv alias off] Question - shouldn't we assume in this example that take-out@pizza-hut.com is a B2BUA, making it a destination - allowing it to open and read the S/MIME body? I'm asking this because this seems like it could be a logical operation of Pizza-Hut's SIP infrastructure under the conditions you've laid out. At 11:52 AM 5/22/2006 -0400, Brian Rosen wrote: >I don't see this as a problem. > >Let's take the non-emergency case. > >If I call take-out@pizza-hut.com, and I want location based routing, I put >my location header in the call, and send the call with TLS. My outbound >proxy will properly ignore it. The pizza-hut domain is the one that wants >to do location based routing, it will get the location and send it off. I >don't need to tell it to do that. I could imagine a generic location based >routing proxy, but I would not think we would want to mark the location >header as the way to get it invoked; we need something else (directly, or >indirectly, a Route header) to do that. > >If I want the endpoint to get it, then I protect it with S/MIME and no proxy >sees it. > >Brian > >-----Original Message----- >From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] >Sent: Monday, May 22, 2006 10:54 AM >To: Brian Rosen; Hannes Tschofenig; sip@ietf.org; geopriv@ietf.org >Subject: AW: [Geopriv] Explicit Indication of Location Object Consumer > >Hi Brian, > > > I would say no. If the location is not needed by proxies, > > then I would say > > you MUST protect it (S/MIME), or it will not be private. >I am less concerned about the security aspects here and more focused the >protocol operation first. >Typically, it is good to know for a device whether it has to process the >content of the message or not. > >If you want to prevent intermediaries to inspect your location object >then S/MIME might be a choice (at least on paper). > > > > > If you have to route on it (emergency or otherwise), then you > > have to send > > it with TLS, and the proxies can see it. > > > > Brian > >Ciao >Hannes > > > > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Sunday, May 21, 2006 7:40 AM > > To: sip@ietf.org; geopriv@ietf.org > > Subject: [Geopriv] Explicit Indication of Location Object Consumer > > > > Hi James > > Hi Brian, > > > > do you plan to put additional info into the SIP message to > > indicate who > > should consume the Location Object (explicity rather than > > implicit info)? > > > > Here is an example: Assume that SIP UA Alice wants to give > > Bob location > > information (via reference). Now, Alice could easily indicate that it > > wants Bob to resolve the reference and to process the > > location object. > > Stating this explicitly would prevent proxies to resolve it and to > > process the location object. > > > > Ciao > > Hannes > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 03 20:16:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmgGS-0003fE-HR; Sat, 03 Jun 2006 20:14:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmgGR-0003f9-42 for sip@ietf.org; Sat, 03 Jun 2006 20:14:43 -0400 Received: from celine.siteprotect.com ([64.41.122.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmgGN-0006FI-Ok for sip@ietf.org; Sat, 03 Jun 2006 20:14:43 -0400 Received: from dimension.cornfed.com (pool-70-16-26-40.balt.east.verizon.net [70.16.26.40]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id k540ETF32285; Sat, 3 Jun 2006 19:14:29 -0500 Subject: Re: [Sip] RE: [Geopriv] Explicit Indication of Location Object Consumer From: "Frank W. Miller" To: "James M. Polk" In-Reply-To: <4.3.2.7.2.20060603172827.027649d0@email.cisco.com> References: <4.3.2.7.2.20060603172827.027649d0@email.cisco.com> Content-Type: text/plain Organization: Cornfed Systems, LLC Date: Sat, 03 Jun 2006 20:14:26 -0400 Message-Id: <1149380066.3057.3.camel@dimension.cornfed.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fwmiller@cornfed.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The Web way would be to redirect the request to another address automatically rather than leaving the address alone and routing it transparently under the covers. Think www.whatever going to www12.whatever in a server farm, or whatever.com going to us.whatever.com. You should be doing an end-to-end secure connection to the original address and then a separate end-to-end secure connection to the redirected address. FM On Sat, 2006-06-03 at 17:32 -0500, James M. Polk wrote: > [took Geopriv alias off] > > Question - shouldn't we assume in this example that take-out@pizza-hut.com > is a B2BUA, making it a destination - allowing it to open and read the > S/MIME body? > > I'm asking this because this seems like it could be a logical operation of > Pizza-Hut's SIP infrastructure under the conditions you've laid out. > > At 11:52 AM 5/22/2006 -0400, Brian Rosen wrote: > >I don't see this as a problem. > > > >Let's take the non-emergency case. > > > >If I call take-out@pizza-hut.com, and I want location based routing, I put > >my location header in the call, and send the call with TLS. My outbound > >proxy will properly ignore it. The pizza-hut domain is the one that wants > >to do location based routing, it will get the location and send it off. I > >don't need to tell it to do that. I could imagine a generic location based > >routing proxy, but I would not think we would want to mark the location > >header as the way to get it invoked; we need something else (directly, or > >indirectly, a Route header) to do that. > > > >If I want the endpoint to get it, then I protect it with S/MIME and no proxy > >sees it. > > > >Brian > > > >-----Original Message----- > >From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > >Sent: Monday, May 22, 2006 10:54 AM > >To: Brian Rosen; Hannes Tschofenig; sip@ietf.org; geopriv@ietf.org > >Subject: AW: [Geopriv] Explicit Indication of Location Object Consumer > > > >Hi Brian, > > > > > I would say no. If the location is not needed by proxies, > > > then I would say > > > you MUST protect it (S/MIME), or it will not be private. > >I am less concerned about the security aspects here and more focused the > >protocol operation first. > >Typically, it is good to know for a device whether it has to process the > >content of the message or not. > > > >If you want to prevent intermediaries to inspect your location object > >then S/MIME might be a choice (at least on paper). > > > > > > > > If you have to route on it (emergency or otherwise), then you > > > have to send > > > it with TLS, and the proxies can see it. > > > > > > Brian > > > >Ciao > >Hannes > > > > > > > > -----Original Message----- > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > Sent: Sunday, May 21, 2006 7:40 AM > > > To: sip@ietf.org; geopriv@ietf.org > > > Subject: [Geopriv] Explicit Indication of Location Object Consumer > > > > > > Hi James > > > Hi Brian, > > > > > > do you plan to put additional info into the SIP message to > > > indicate who > > > should consume the Location Object (explicity rather than > > > implicit info)? > > > > > > Here is an example: Assume that SIP UA Alice wants to give > > > Bob location > > > information (via reference). Now, Alice could easily indicate that it > > > wants Bob to resolve the reference and to process the > > > location object. > > > Stating this explicitly would prevent proxies to resolve it and to > > > process the location object. > > > > > > Ciao > > > Hannes > > > > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > >_______________________________________________ > >Geopriv mailing list > >Geopriv@ietf.org > >https://www1.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 03 21:00:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fmgwq-0003pn-68; Sat, 03 Jun 2006 20:58:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fmgwo-0003ow-Cg for sip@ietf.org; Sat, 03 Jun 2006 20:58:30 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fmgna-0001JN-Nw for sip@ietf.org; Sat, 03 Jun 2006 20:48:59 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 03 Jun 2006 17:48:58 -0700 X-IronPort-AV: i="4.05,206,1146466800"; d="scan'208"; a="1818764905:sNHT37819032" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k540mvEC022413; Sat, 3 Jun 2006 17:48:57 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k540mvCU020370; Sat, 3 Jun 2006 17:48:57 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 3 Jun 2006 17:48:57 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.144.242]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 3 Jun 2006 17:48:56 -0700 Message-Id: <4.3.2.7.2.20060603193453.028d8c18@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 03 Jun 2006 19:48:55 -0500 To: fwmiller@cornfed.com From: "James M. Polk" Subject: Re: [Sip] RE: [Geopriv] Explicit Indication of Location Object Consumer In-Reply-To: <1149380066.3057.3.camel@dimension.cornfed.com> References: <4.3.2.7.2.20060603172827.027649d0@email.cisco.com> <4.3.2.7.2.20060603172827.027649d0@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 04 Jun 2006 00:48:56.0757 (UTC) FILETIME=[A8F84E50:01C68770] DKIM-Signature: a=rsa-sha1; q=dns; l=5300; t=1149382137; x=1150246137; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Sip]=20RE=3A=20[Geopriv]=20Explicit=20Indication=20of=20Locatio n=20Object=0A=20=20Consumer; X=v=3Dcisco.com=3B=20h=3Doa55v3j3iS2dE3ePmtnfbZZB6g4=3D; b=RqDu5vrMqNHkzK8OPzLykn+iYufBdvhTba00IDLsLrtlRO1EnXhgntBnqlvXqVtlYakcIGtG cyHnjK8oQ/eCSbsFIZGAk7UV9+A8nBBRV7aFZhDOcQSoCRM8HPDstHU3; Authentication-Results: sj-dkim-2.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org weeeeeell.... "take-out@pizza-hut.com" would be the R-URI in this case, wouldn't it? I think this has to the case since Brian has no knowledge which is the closest Pizza-Hut store to contact directly. Given this, S/MIME should still be the correct way to send location in the message (e2e). A 302 would be the response from take-out@pizza-hut.com. This would necessitate a new INVITE to the new URI given in the 302, but not necessarily including location in that INVITE at all. This is interesting... I need to think about how this can be misused/abused. At 08:14 PM 6/3/2006 -0400, Frank W. Miller wrote: >The Web way would be to redirect the request to another address >automatically rather than leaving the address alone and routing it >transparently under the covers. Think www.whatever going to >www12.whatever in a server farm, or whatever.com going to >us.whatever.com. You should be doing an end-to-end secure connection to >the original address and then a separate end-to-end secure connection to >the redirected address. > >FM > > > >On Sat, 2006-06-03 at 17:32 -0500, James M. Polk wrote: > > [took Geopriv alias off] > > > > Question - shouldn't we assume in this example that take-out@pizza-hut.com > > is a B2BUA, making it a destination - allowing it to open and read the > > S/MIME body? > > > > I'm asking this because this seems like it could be a logical operation of > > Pizza-Hut's SIP infrastructure under the conditions you've laid out. > > > > At 11:52 AM 5/22/2006 -0400, Brian Rosen wrote: > > >I don't see this as a problem. > > > > > >Let's take the non-emergency case. > > > > > >If I call take-out@pizza-hut.com, and I want location based routing, I put > > >my location header in the call, and send the call with TLS. My outbound > > >proxy will properly ignore it. The pizza-hut domain is the one that wants > > >to do location based routing, it will get the location and send it off. I > > >don't need to tell it to do that. I could imagine a generic location > based > > >routing proxy, but I would not think we would want to mark the location > > >header as the way to get it invoked; we need something else (directly, or > > >indirectly, a Route header) to do that. > > > > > >If I want the endpoint to get it, then I protect it with S/MIME and no > proxy > > >sees it. > > > > > >Brian > > > > > >-----Original Message----- > > >From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > > >Sent: Monday, May 22, 2006 10:54 AM > > >To: Brian Rosen; Hannes Tschofenig; sip@ietf.org; geopriv@ietf.org > > >Subject: AW: [Geopriv] Explicit Indication of Location Object Consumer > > > > > >Hi Brian, > > > > > > > I would say no. If the location is not needed by proxies, > > > > then I would say > > > > you MUST protect it (S/MIME), or it will not be private. > > >I am less concerned about the security aspects here and more focused the > > >protocol operation first. > > >Typically, it is good to know for a device whether it has to process the > > >content of the message or not. > > > > > >If you want to prevent intermediaries to inspect your location object > > >then S/MIME might be a choice (at least on paper). > > > > > > > > > > > If you have to route on it (emergency or otherwise), then you > > > > have to send > > > > it with TLS, and the proxies can see it. > > > > > > > > Brian > > > > > >Ciao > > >Hannes > > > > > > > > > > > -----Original Message----- > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > Sent: Sunday, May 21, 2006 7:40 AM > > > > To: sip@ietf.org; geopriv@ietf.org > > > > Subject: [Geopriv] Explicit Indication of Location Object Consumer > > > > > > > > Hi James > > > > Hi Brian, > > > > > > > > do you plan to put additional info into the SIP message to > > > > indicate who > > > > should consume the Location Object (explicity rather than > > > > implicit info)? > > > > > > > > Here is an example: Assume that SIP UA Alice wants to give > > > > Bob location > > > > information (via reference). Now, Alice could easily indicate that it > > > > wants Bob to resolve the reference and to process the > > > > location object. > > > > Stating this explicitly would prevent proxies to resolve it and to > > > > process the location object. > > > > > > > > Ciao > > > > Hannes > > > > > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > > > >_______________________________________________ > > >Geopriv mailing list > > >Geopriv@ietf.org > > >https://www1.ietf.org/mailman/listinfo/geopriv > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 04 09:36:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fmskg-0005wP-UD; Sun, 04 Jun 2006 09:34:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fmske-0005wI-2j for sip@ietf.org; Sun, 04 Jun 2006 09:34:44 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fmskb-0003r9-Pn for sip@ietf.org; Sun, 04 Jun 2006 09:34:44 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 04 Jun 2006 06:34:41 -0700 X-IronPort-AV: i="4.05,206,1146466800"; d="scan'208"; a="1818896135:sNHT32909568" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k54DYfos014609; Sun, 4 Jun 2006 06:34:41 -0700 Received: from [192.168.1.2] (sjc-vpn4-214.cisco.com [10.21.80.214]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k54DYWIw012927; Sun, 4 Jun 2006 06:34:40 -0700 (PDT) In-Reply-To: <85108216918A984C8C60172D7C84770A08A521@S4DE8PSAAGO.mitte.t-com.de> References: <85108216918A984C8C60172D7C84770A08A521@S4DE8PSAAGO.mitte.t-com.de> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: AW: AW: AW: [Sip] Connected-identity and changing the To header f ield ina response Date: Sat, 3 Jun 2006 18:53:11 -0700 To: "Jesske, R" X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=1266; t=1149428081; x=1150292081; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20AW=3A=20AW=3A=20AW=3A=20[Sip]=20Connected-identity=20and=20chang ing=20the=20To=20header=20f=20ield=20ina=09response; X=v=3Dcisco.com=3B=20h=3Df7Uv8H3uG0rTgsh3kFJQzjSBuaA=3D; b=b44Zp3v/q5aiWMedeRv9SGImdwZkhJrLnvmLlLIiGFfvq1Oscudq27wpPCRebfMGhkc1Yc6P JNahS690HrrL8NRtAcn+1w1uEFVnB94uOI5qdzA/GHUU3JXp7w9/KwpG; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: sip@ietf.org, pkyzivat@cisco.com, john.elwell@siemens.com, roland.jesske@web.de, christer.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 1, 2006, at 1:42 AM, Jesske, R wrote: > The two identities are used for PBX services. > Example > If a user calls a special hotline for e.G. Computer Services. > +496151830. > This is the main number of a PBX with several extensions. The user > will be at least connected to an Service Expert (Extension No: > +496151831111). > So now there is a Public Id (+496151830) that is trusted and the > all billing is bind to. (TISPAN uses the P-Asserted-Identity) > and a private not secure id of the Expert. Advantage is that the > Caller has now the ability to see the real connected number where > the expert can now called directly. > > This service is widely used within the PSTN/ISDN world and is known > as COLP (Connected Line Identification Presentation) Specifies in > ITU-T Q.731.5 and in ETSI ETSI EN 300 094 (free downloadable at > portal.etsi.org). > > We have described the Requirements in draft-jesske-sipping-tispan- > requirements-01 and did some analysis in the past in draft-jesske- > sipping-tispan-analysis-00.txt > > Best Regards Ok, this is a good example. Now the next questions in this scenario, what are some of the things that use these two numbers and what do they get used for? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 04 11:14:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmuHG-0007Ij-6I; Sun, 04 Jun 2006 11:12:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmuHE-0007G9-Vi for sip@ietf.org; Sun, 04 Jun 2006 11:12:28 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmuHC-0006Pm-F6 for sip@ietf.org; Sun, 04 Jun 2006 11:12:28 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FmuH0-0006Sn-T1; Sun, 04 Jun 2006 10:12:15 -0500 From: "Brian Rosen" To: "'James M. Polk'" , Subject: RE: [Sip] RE: [Geopriv] Explicit Indication of Location Object Consumer Date: Sun, 4 Jun 2006 11:12:16 -0400 Message-ID: <0cce01c687e9$464f7520$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4.3.2.7.2.20060603193453.028d8c18@email.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaHcKWJu3SZ8C39Q5aOJWN6Xk5IlQAeDc2Q X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The problem here is S/MIME. No one really uses S/MIME with SIP because the PKI is too hard to deal with. This case is just as hard as any other case. I also think PLANNING a B2BUA for this is a bad idea. B2BUAs are evil. Brian -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: Saturday, June 03, 2006 8:49 PM To: fwmiller@cornfed.com Cc: Brian Rosen; 'Tschofenig, Hannes'; 'Hannes Tschofenig'; sip@ietf.org Subject: Re: [Sip] RE: [Geopriv] Explicit Indication of Location Object Consumer weeeeeell.... "take-out@pizza-hut.com" would be the R-URI in this case, wouldn't it? I think this has to the case since Brian has no knowledge which is the closest Pizza-Hut store to contact directly. Given this, S/MIME should still be the correct way to send location in the message (e2e). A 302 would be the response from take-out@pizza-hut.com. This would necessitate a new INVITE to the new URI given in the 302, but not necessarily including location in that INVITE at all. This is interesting... I need to think about how this can be misused/abused. At 08:14 PM 6/3/2006 -0400, Frank W. Miller wrote: >The Web way would be to redirect the request to another address >automatically rather than leaving the address alone and routing it >transparently under the covers. Think www.whatever going to >www12.whatever in a server farm, or whatever.com going to >us.whatever.com. You should be doing an end-to-end secure connection to >the original address and then a separate end-to-end secure connection to >the redirected address. > >FM > > > >On Sat, 2006-06-03 at 17:32 -0500, James M. Polk wrote: > > [took Geopriv alias off] > > > > Question - shouldn't we assume in this example that take-out@pizza-hut.com > > is a B2BUA, making it a destination - allowing it to open and read the > > S/MIME body? > > > > I'm asking this because this seems like it could be a logical operation of > > Pizza-Hut's SIP infrastructure under the conditions you've laid out. > > > > At 11:52 AM 5/22/2006 -0400, Brian Rosen wrote: > > >I don't see this as a problem. > > > > > >Let's take the non-emergency case. > > > > > >If I call take-out@pizza-hut.com, and I want location based routing, I put > > >my location header in the call, and send the call with TLS. My outbound > > >proxy will properly ignore it. The pizza-hut domain is the one that wants > > >to do location based routing, it will get the location and send it off. I > > >don't need to tell it to do that. I could imagine a generic location > based > > >routing proxy, but I would not think we would want to mark the location > > >header as the way to get it invoked; we need something else (directly, or > > >indirectly, a Route header) to do that. > > > > > >If I want the endpoint to get it, then I protect it with S/MIME and no > proxy > > >sees it. > > > > > >Brian > > > > > >-----Original Message----- > > >From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > > >Sent: Monday, May 22, 2006 10:54 AM > > >To: Brian Rosen; Hannes Tschofenig; sip@ietf.org; geopriv@ietf.org > > >Subject: AW: [Geopriv] Explicit Indication of Location Object Consumer > > > > > >Hi Brian, > > > > > > > I would say no. If the location is not needed by proxies, > > > > then I would say > > > > you MUST protect it (S/MIME), or it will not be private. > > >I am less concerned about the security aspects here and more focused the > > >protocol operation first. > > >Typically, it is good to know for a device whether it has to process the > > >content of the message or not. > > > > > >If you want to prevent intermediaries to inspect your location object > > >then S/MIME might be a choice (at least on paper). > > > > > > > > > > > If you have to route on it (emergency or otherwise), then you > > > > have to send > > > > it with TLS, and the proxies can see it. > > > > > > > > Brian > > > > > >Ciao > > >Hannes > > > > > > > > > > > -----Original Message----- > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > Sent: Sunday, May 21, 2006 7:40 AM > > > > To: sip@ietf.org; geopriv@ietf.org > > > > Subject: [Geopriv] Explicit Indication of Location Object Consumer > > > > > > > > Hi James > > > > Hi Brian, > > > > > > > > do you plan to put additional info into the SIP message to > > > > indicate who > > > > should consume the Location Object (explicity rather than > > > > implicit info)? > > > > > > > > Here is an example: Assume that SIP UA Alice wants to give > > > > Bob location > > > > information (via reference). Now, Alice could easily indicate that it > > > > wants Bob to resolve the reference and to process the > > > > location object. > > > > Stating this explicitly would prevent proxies to resolve it and to > > > > process the location object. > > > > > > > > Ciao > > > > Hannes > > > > > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > > > >_______________________________________________ > > >Geopriv mailing list > > >Geopriv@ietf.org > > >https://www1.ietf.org/mailman/listinfo/geopriv > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 05 03:36:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn9bF-0004Mq-9o; Mon, 05 Jun 2006 03:34:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn9bD-0004Ml-8p for sip@ietf.org; Mon, 05 Jun 2006 03:34:07 -0400 Received: from [58.246.81.90] (helo=vlichina.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn9bB-0007t1-17 for sip@ietf.org; Mon, 05 Jun 2006 03:34:07 -0400 Received: from vli353dt by vlichina.com (MDaemon.PRO.v8.0.2.R) with ESMTP id md50000064226.msg for ; Mon, 05 Jun 2006 15:31:54 +0800 From: "raingy.JIN" To: Date: Mon, 5 Jun 2006 15:33:48 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaIcmJoYh/MdkkYQN+2+W7NfCdZRg== X-Spam-Processed: vlichina.com, Mon, 05 Jun 2006 15:31:54 +0800 (not processed: message from valid local sender) X-Return-Path: raingy.jin@vlichina.com X-MDaemon-Deliver-To: sip@ietf.org X-MDAV-Processed: vlichina.com, Mon, 05 Jun 2006 15:31:55 +0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Subject: [Sip] RFC3261 about Timer J of non-INVITE server transaction X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Message-Id: Hi~ I have a question about Timer J of non-INVITE server transaction. I think the Timer J should be set at Trying state NOT Completed state. Because TU may cost a long time to process the Request. ======================================================= // (RFC 3261; page 137-140) |Request received |pass to TU V +-----------+ | | | Trying |-------------+ | | | +-----------+ |200-699 from TU | |send response |1xx from TU | |send response | | | Request V 1xx from TU | send response+-----------+send response| +--------| |--------+ | | | Proceeding| | | +------->| |<-------+ | +<--------------| | | |Trnsprt Err +-----------+ | |Inform TU | | | | | | |200-699 from TU | | |send response | | Request V | | send response+-----------+ | | +--------| | | | | | Completed |<------------+ | +------->| | +<--------------| | |Trnsprt Err +-----------+ |Inform TU | | |Timer J fires | |- | | | V | +-----------+ | | | +-------------->| Terminated| | | +-----------+ Figure 8: non-INVITE server transaction ========================================================== // I think it should be modified to: |Request received |pass to TU V set Timer F Timer F fires +-----------+ +<--------------| | | | Trying |-------------+ | | | | | +-----------+ |200-699 from TU | | |send response | |1xx from TU | | |send response | | | | | Request V 1xx from TU | | send response+-----------+send response| | +--------| |--------+ | | | | Proceeding| | | | +------->| |<-------+ | +<--------------| | | |Timer F fires +-----------+ | |or | | |Trnsprt Err | | |Inform TU |200-699 from TU | | |send response | | Request V | | send response+-----------+ | | +--------| | | | | | Completed |<------------+ | +------->| | +<--------------| | |Timer F fires +-----------+ |or | |Trnsprt Err | |Inform TU |(Cancel Timer F for non-UDP) | | | V | +-----------+ | | | +-------------->| Terminated| | | +-----------+ ============================================== Is that right? Thanks, raingy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 05 07:48:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnDXm-0005fx-JP; Mon, 05 Jun 2006 07:46:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnDXl-0005eB-Jj for sip@ietf.org; Mon, 05 Jun 2006 07:46:49 -0400 Received: from nat1.alcatel-sbell.com.cn ([202.96.203.177] helo=mail.alcatel-sbell.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnDXh-0005iU-SG for sip@ietf.org; Mon, 05 Jun 2006 07:46:49 -0400 Received: from asbmail4.sbell.com.cn (localhost [127.0.0.1]) by mail.alcatel-sbell.com.cn (8.12.11/8.12.11/Alcanet1.0) with ESMTP id k55BgFcQ005158 for ; Mon, 5 Jun 2006 19:42:16 +0800 Received: from asbmail2.sbell.com.cn ([172.24.208.62]) by asbmail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Mon, 5 Jun 2006 19:46:41 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Mon, 5 Jun 2006 19:46:41 +0800 Message-ID: <9570C1261494D54D9D3115BC2C83429A0202C62C@asbmail2.sbell.com.cn> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: how to create a multicast session using SIP? Thread-Index: AcaIlZVRYEhZvGbHQYSUctUW23r7Nw== From: "CTO YAN Renxiang" To: X-OriginalArrivalTime: 05 Jun 2006 11:46:41.0556 (UTC) FILETIME=[B63C7D40:01C68895] X-imss-version: 2.040 X-imss-result: Passed X-imss-approveListMatch: *@alcatel-sbell.com.cn X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Sip] how to create a multicast session using SIP? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, all, How to create a multicast session using SIP? Is the following = description right? Two kinds of case: Case (1) A invites B to join a multicast session. A sends a INVITE to B, the multicast address is included in SDP part = of INVITE message.=20 B will then join the session by sending an IGMP to join the multicast = session. ... Case (2) A joins a multicast session independently. A sends INVITE to whom? when send IGMP join message? Other cases? Regards, Renxiang _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 05 10:00:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnFaz-0004P4-PW; Mon, 05 Jun 2006 09:58:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnFax-0004Oz-Rn for sip@ietf.org; Mon, 05 Jun 2006 09:58:15 -0400 Received: from ms-smtp-03.rdc-nyc.rr.com ([24.29.109.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnFaw-00023l-Ik for sip@ietf.org; Mon, 05 Jun 2006 09:58:15 -0400 Received: from tarragona (cpe-68-175-84-59.nyc.res.rr.com [68.175.84.59]) by ms-smtp-03.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id k55Dvqnl027163; Mon, 5 Jun 2006 09:58:01 -0400 (EDT) From: "Tarun Kapoor" To: "'CTO YAN Renxiang'" , Subject: RE: [Sip] how to create a multicast session using SIP? Date: Mon, 5 Jun 2006 09:57:24 -0400 Message-ID: <004901c688a7$fe5e59b0$0202fea9@tarragona> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <9570C1261494D54D9D3115BC2C83429A0202C62C@asbmail2.sbell.com.cn> Thread-Index: AcaIlZVRYEhZvGbHQYSUctUW23r7NwAETbvQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Renxiang, I believe this question is more suited for the "SIP Implementors" mailing list (sip-implementors@cs.columbia.edu). But to answer your question, you always need to embedded any media session parameters (such as multicast session) in the SDP of any INVITE. However, in the first case, you are directly inviting B to the multicast media session (who will then join the multicast session via IGMP, assuming it accepts the INVITE with a 200 response), and in the second case, A needs to determine whom to invite to the session (which is independent of SIP) and sends the INVITE to the those users, and if they accept with a 200 response, then they will also join the multicast session via IGMP. Alternatively, in the second case, you could send the INVITE itself to a multicast address (i.e., send the SIP message to a multicast address, rather than a unicast address). Anyone listening for SIP messages on that multicast address will automatically receive the INVITE and can determine whether to join independently of any specific (i.e., unicast) INVITE received. However, in practice, I don't know how many implementations use the SIP over multicast scenario. Regards, Tarun Kapoor Pangean Technologies, LLC W: +1 (877) 472-6432 F: +1 (877) 581-7616 M: +1 (917) 698-3450 www.pangeantech.com "...communications without boundaries" -----Original Message----- From: CTO YAN Renxiang [mailto:Renxiang.Yan@alcatel-sbell.com.cn] Sent: Monday, June 05, 2006 7:47 AM To: sip@ietf.org Subject: [Sip] how to create a multicast session using SIP? Hi, all, How to create a multicast session using SIP? Is the following description right? Two kinds of case: Case (1) A invites B to join a multicast session. A sends a INVITE to B, the multicast address is included in SDP part of INVITE message. B will then join the session by sending an IGMP to join the multicast session. ... Case (2) A joins a multicast session independently. A sends INVITE to whom? when send IGMP join message? Other cases? Regards, Renxiang _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 05 15:08:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnKPP-0004b0-Hs; Mon, 05 Jun 2006 15:06:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnKPO-0004au-4f for sip@ietf.org; Mon, 05 Jun 2006 15:06:38 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnKPN-0002NK-GJ for sip@ietf.org; Mon, 05 Jun 2006 15:06:38 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 05 Jun 2006 12:06:36 -0700 X-IronPort-AV: i="4.05,211,1146466800"; d="scan'208"; a="1819512702:sNHT35211152" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k55J6a6H003226; Mon, 5 Jun 2006 12:06:36 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k55J6WCa020218; Mon, 5 Jun 2006 12:06:36 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Jun 2006 12:06:34 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.96.20]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Jun 2006 12:06:33 -0700 Message-Id: <4.3.2.7.2.20060605135702.02801e70@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Jun 2006 14:06:32 -0500 To: "Brian Rosen" , From: "James M. Polk" Subject: RE: [Sip] RE: [Geopriv] Explicit Indication of Location Object Consumer In-Reply-To: <0cce01c687e9$464f7520$640fa8c0@cis.neustar.com> References: <4.3.2.7.2.20060603193453.028d8c18@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 05 Jun 2006 19:06:33.0397 (UTC) FILETIME=[28FFD650:01C688D3] DKIM-Signature: a=rsa-sha1; q=dns; l=7239; t=1149534396; x=1150398396; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:RE=3A=20[Sip]=20RE=3A=20[Geopriv]=20Explicit=20Indication=20of=20Locatio n=20Object=0A=20=20=20Consumer; X=v=3Dcisco.com=3B=20h=3D7ogYcxcUPFsWjl8LEH3ntUB8YhI=3D; b=PDQSS1VFYob4AzyJkeey8kdMLDFFdNvSdQOAYdhGPflejr/dlX2xcNcV6XWg3lvp5k6+ffen bP1qFrx5i6R53HK/zNQyE9+ByxOuF67nbisFQzcWTp0QDTKQl3OQtfRP; Authentication-Results: sj-dkim-4.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 11:12 AM 6/4/2006 -0400, Brian Rosen wrote: >The problem here is S/MIME. No one really uses S/MIME with SIP because the >PKI is too hard to deal with. This case is just as hard as any other case. > >I also think PLANNING a B2BUA for this is a bad idea. B2BUAs are evil. B2BUA's are a reality. That ship's sailed already. No one does this function yet (routing a message based on the location of the caller), so this is greenfield. Someone can write an ID intending to become a BCP that says this is the RECOMMENDED practice of any organization that wants to route based on the location of the caller, since a B2BUA can inspect S/MIME bodies because it IS the desination. At that point, I think a 3XX is a waste of BW, as the more efficient means of communicating with the exact ultimate destination of that take-out@pizza-hut.com R-URI from where you are is determined by that server. Remember, a UA may not have their location by-reference to give to take-out@pizza-hut.com to dereference. That makes the call fail due to not having a route; unless you want a less efficient default route that will never be right, and cause further delay, and possibly has to be designed with user interaction. If the B2BUA still wants to give a 302 back, it still can, once it's read the S/MIME location body. >Brian > >-----Original Message----- >From: James M. Polk [mailto:jmpolk@cisco.com] >Sent: Saturday, June 03, 2006 8:49 PM >To: fwmiller@cornfed.com >Cc: Brian Rosen; 'Tschofenig, Hannes'; 'Hannes Tschofenig'; sip@ietf.org >Subject: Re: [Sip] RE: [Geopriv] Explicit Indication of Location Object >Consumer > >weeeeeell.... "take-out@pizza-hut.com" would be the R-URI in this case, >wouldn't it? I think this has to the case since Brian has no knowledge >which is the closest Pizza-Hut store to contact directly. > >Given this, S/MIME should still be the correct way to send location in the >message (e2e). > >A 302 would be the response from take-out@pizza-hut.com. > >This would necessitate a new INVITE to the new URI given in the 302, but >not necessarily including location in that INVITE at all. This is >interesting... I need to think about how this can be misused/abused. > >At 08:14 PM 6/3/2006 -0400, Frank W. Miller wrote: > > >The Web way would be to redirect the request to another address > >automatically rather than leaving the address alone and routing it > >transparently under the covers. Think www.whatever going to > >www12.whatever in a server farm, or whatever.com going to > >us.whatever.com. You should be doing an end-to-end secure connection to > >the original address and then a separate end-to-end secure connection to > >the redirected address. > > > >FM > > > > > > > >On Sat, 2006-06-03 at 17:32 -0500, James M. Polk wrote: > > > [took Geopriv alias off] > > > > > > Question - shouldn't we assume in this example that >take-out@pizza-hut.com > > > is a B2BUA, making it a destination - allowing it to open and read the > > > S/MIME body? > > > > > > I'm asking this because this seems like it could be a logical operation >of > > > Pizza-Hut's SIP infrastructure under the conditions you've laid out. > > > > > > At 11:52 AM 5/22/2006 -0400, Brian Rosen wrote: > > > >I don't see this as a problem. > > > > > > > >Let's take the non-emergency case. > > > > > > > >If I call take-out@pizza-hut.com, and I want location based routing, I >put > > > >my location header in the call, and send the call with TLS. My >outbound > > > >proxy will properly ignore it. The pizza-hut domain is the one that >wants > > > >to do location based routing, it will get the location and send it off. >I > > > >don't need to tell it to do that. I could imagine a generic location > > based > > > >routing proxy, but I would not think we would want to mark the location > > > >header as the way to get it invoked; we need something else (directly, >or > > > >indirectly, a Route header) to do that. > > > > > > > >If I want the endpoint to get it, then I protect it with S/MIME and no > > proxy > > > >sees it. > > > > > > > >Brian > > > > > > > >-----Original Message----- > > > >From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > > > >Sent: Monday, May 22, 2006 10:54 AM > > > >To: Brian Rosen; Hannes Tschofenig; sip@ietf.org; geopriv@ietf.org > > > >Subject: AW: [Geopriv] Explicit Indication of Location Object Consumer > > > > > > > >Hi Brian, > > > > > > > > > I would say no. If the location is not needed by proxies, > > > > > then I would say > > > > > you MUST protect it (S/MIME), or it will not be private. > > > >I am less concerned about the security aspects here and more focused >the > > > >protocol operation first. > > > >Typically, it is good to know for a device whether it has to process >the > > > >content of the message or not. > > > > > > > >If you want to prevent intermediaries to inspect your location object > > > >then S/MIME might be a choice (at least on paper). > > > > > > > > > > > > > > If you have to route on it (emergency or otherwise), then you > > > > > have to send > > > > > it with TLS, and the proxies can see it. > > > > > > > > > > Brian > > > > > > > >Ciao > > > >Hannes > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > > Sent: Sunday, May 21, 2006 7:40 AM > > > > > To: sip@ietf.org; geopriv@ietf.org > > > > > Subject: [Geopriv] Explicit Indication of Location Object Consumer > > > > > > > > > > Hi James > > > > > Hi Brian, > > > > > > > > > > do you plan to put additional info into the SIP message to > > > > > indicate who > > > > > should consume the Location Object (explicity rather than > > > > > implicit info)? > > > > > > > > > > Here is an example: Assume that SIP UA Alice wants to give > > > > > Bob location > > > > > information (via reference). Now, Alice could easily indicate that >it > > > > > wants Bob to resolve the reference and to process the > > > > > location object. > > > > > Stating this explicitly would prevent proxies to resolve it and to > > > > > process the location object. > > > > > > > > > > Ciao > > > > > Hannes > > > > > > > > > > > > > > > _______________________________________________ > > > > > Geopriv mailing list > > > > > Geopriv@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > > > > > > _______________________________________________ > > > > > Geopriv mailing list > > > > > Geopriv@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > > > > > > > >_______________________________________________ > > > >Geopriv mailing list > > > >Geopriv@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 05 16:26:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLdA-0003dq-Sh; Mon, 05 Jun 2006 16:24:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLd9-0003dl-Hk for sip@ietf.org; Mon, 05 Jun 2006 16:24:55 -0400 Received: from ftwmail4.verizon.com ([192.76.86.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnLd6-000343-7n for sip@ietf.org; Mon, 05 Jun 2006 16:24:55 -0400 Received: from smtpftw3.verizon.com (smtpftw3.verizon.com [138.83.140.92]) by ftwmail4.verizon.com (8.13.3/8.13.3) with ESMTP id k55KOpVX024580 for ; Mon, 5 Jun 2006 16:24:51 -0400 (EDT) Received: from TPAP1CVMMA04.vzh.ent.verizon.com (tpap1cvmma04.verizon.com [138.83.67.59]) by smtpftw3.verizon.com (8.13.3/8.13.3) with ESMTP id k55KNsIK003132 for ; Mon, 5 Jun 2006 16:24:51 -0400 (EDT) Received: from 138.83.34.22 by TPAP1CVMMA04.vzh.ent.verizon.com with ESMTP (SMTP Relay); Mon, 05 Jun 2006 16:24:43 -0400 X-Server-Uuid: C9AEC8CA-C5F9-4186-A8C9-C5C3D4DB8A19 Received: from dwsmtp01.core.verizon.com (dwsmtp01.verizon.com [138.83.35.62]) by coregate1.verizon.com (8.13.3/8.13.3) with ESMTP id k55KOhB3011614 for ; Mon, 5 Jun 2006 15:24:43 -0500 (CDT) Date: Mon, 5 Jun 2006 16:24:38 -0400 MIME-Version: 1.0 To: sip@ietf.org cc: From: steven.d.whitehead@verizon.com X-Mailer: Microsoft Outlook v 11.00.6353, MSOC v 2.00.4007.00 Message-ID: X-MIMETrack: Serialize by Router on DWSMTP01/HSVR/Verizon(Release 6.5.4HF453 | August 4, 2005) at 06/05/2006 15:24:43, Serialize complete at 06/05/2006 15:24:43 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-WSS-ID: 689A4C811VO199076-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Sip] What error response to Naked Invite? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org If a UAS doesn't support naked INVITEs, what error response should it generate? Is there a preferred response? Is it 415 unsupported media type? Thanks in advance for your help. -Steve _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 05 16:41:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLr4-0004bf-54; Mon, 05 Jun 2006 16:39:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLr2-0004bL-JJ for sip@ietf.org; Mon, 05 Jun 2006 16:39:16 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnLr2-0005Vr-49 for sip@ietf.org; Mon, 05 Jun 2006 16:39:16 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FnLqq-0002b1-6d; Mon, 05 Jun 2006 15:39:04 -0500 From: "Brian Rosen" To: "'James M. Polk'" , Subject: RE: [Sip] RE: [Geopriv] Explicit Indication of Location Object Consumer Date: Mon, 5 Jun 2006 16:39:08 -0400 Message-ID: <024601c688e0$19d996e0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaI0ylbkmGA8mi2T42U+Dsh3roNTQADMbQA In-reply-to: <4.3.2.7.2.20060605135702.02801e70@email.cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I would strongly prefer to leave this as proxy routes with TLS security. I wouldn't want to preclude an endpoint from routing with S/MIME security, but I don't think that will be common. Brian -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: Monday, June 05, 2006 3:07 PM To: Brian Rosen; fwmiller@cornfed.com Cc: 'Tschofenig, Hannes'; 'Hannes Tschofenig'; sip@ietf.org Subject: RE: [Sip] RE: [Geopriv] Explicit Indication of Location Object Consumer At 11:12 AM 6/4/2006 -0400, Brian Rosen wrote: >The problem here is S/MIME. No one really uses S/MIME with SIP because the >PKI is too hard to deal with. This case is just as hard as any other case. > >I also think PLANNING a B2BUA for this is a bad idea. B2BUAs are evil. B2BUA's are a reality. That ship's sailed already. No one does this function yet (routing a message based on the location of the caller), so this is greenfield. Someone can write an ID intending to become a BCP that says this is the RECOMMENDED practice of any organization that wants to route based on the location of the caller, since a B2BUA can inspect S/MIME bodies because it IS the desination. At that point, I think a 3XX is a waste of BW, as the more efficient means of communicating with the exact ultimate destination of that take-out@pizza-hut.com R-URI from where you are is determined by that server. Remember, a UA may not have their location by-reference to give to take-out@pizza-hut.com to dereference. That makes the call fail due to not having a route; unless you want a less efficient default route that will never be right, and cause further delay, and possibly has to be designed with user interaction. If the B2BUA still wants to give a 302 back, it still can, once it's read the S/MIME location body. >Brian > >-----Original Message----- >From: James M. Polk [mailto:jmpolk@cisco.com] >Sent: Saturday, June 03, 2006 8:49 PM >To: fwmiller@cornfed.com >Cc: Brian Rosen; 'Tschofenig, Hannes'; 'Hannes Tschofenig'; sip@ietf.org >Subject: Re: [Sip] RE: [Geopriv] Explicit Indication of Location Object >Consumer > >weeeeeell.... "take-out@pizza-hut.com" would be the R-URI in this case, >wouldn't it? I think this has to the case since Brian has no knowledge >which is the closest Pizza-Hut store to contact directly. > >Given this, S/MIME should still be the correct way to send location in the >message (e2e). > >A 302 would be the response from take-out@pizza-hut.com. > >This would necessitate a new INVITE to the new URI given in the 302, but >not necessarily including location in that INVITE at all. This is >interesting... I need to think about how this can be misused/abused. > >At 08:14 PM 6/3/2006 -0400, Frank W. Miller wrote: > > >The Web way would be to redirect the request to another address > >automatically rather than leaving the address alone and routing it > >transparently under the covers. Think www.whatever going to > >www12.whatever in a server farm, or whatever.com going to > >us.whatever.com. You should be doing an end-to-end secure connection to > >the original address and then a separate end-to-end secure connection to > >the redirected address. > > > >FM > > > > > > > >On Sat, 2006-06-03 at 17:32 -0500, James M. Polk wrote: > > > [took Geopriv alias off] > > > > > > Question - shouldn't we assume in this example that >take-out@pizza-hut.com > > > is a B2BUA, making it a destination - allowing it to open and read the > > > S/MIME body? > > > > > > I'm asking this because this seems like it could be a logical operation >of > > > Pizza-Hut's SIP infrastructure under the conditions you've laid out. > > > > > > At 11:52 AM 5/22/2006 -0400, Brian Rosen wrote: > > > >I don't see this as a problem. > > > > > > > >Let's take the non-emergency case. > > > > > > > >If I call take-out@pizza-hut.com, and I want location based routing, I >put > > > >my location header in the call, and send the call with TLS. My >outbound > > > >proxy will properly ignore it. The pizza-hut domain is the one that >wants > > > >to do location based routing, it will get the location and send it off. >I > > > >don't need to tell it to do that. I could imagine a generic location > > based > > > >routing proxy, but I would not think we would want to mark the location > > > >header as the way to get it invoked; we need something else (directly, >or > > > >indirectly, a Route header) to do that. > > > > > > > >If I want the endpoint to get it, then I protect it with S/MIME and no > > proxy > > > >sees it. > > > > > > > >Brian > > > > > > > >-----Original Message----- > > > >From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > > > >Sent: Monday, May 22, 2006 10:54 AM > > > >To: Brian Rosen; Hannes Tschofenig; sip@ietf.org; geopriv@ietf.org > > > >Subject: AW: [Geopriv] Explicit Indication of Location Object Consumer > > > > > > > >Hi Brian, > > > > > > > > > I would say no. If the location is not needed by proxies, > > > > > then I would say > > > > > you MUST protect it (S/MIME), or it will not be private. > > > >I am less concerned about the security aspects here and more focused >the > > > >protocol operation first. > > > >Typically, it is good to know for a device whether it has to process >the > > > >content of the message or not. > > > > > > > >If you want to prevent intermediaries to inspect your location object > > > >then S/MIME might be a choice (at least on paper). > > > > > > > > > > > > > > If you have to route on it (emergency or otherwise), then you > > > > > have to send > > > > > it with TLS, and the proxies can see it. > > > > > > > > > > Brian > > > > > > > >Ciao > > > >Hannes > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > > Sent: Sunday, May 21, 2006 7:40 AM > > > > > To: sip@ietf.org; geopriv@ietf.org > > > > > Subject: [Geopriv] Explicit Indication of Location Object Consumer > > > > > > > > > > Hi James > > > > > Hi Brian, > > > > > > > > > > do you plan to put additional info into the SIP message to > > > > > indicate who > > > > > should consume the Location Object (explicity rather than > > > > > implicit info)? > > > > > > > > > > Here is an example: Assume that SIP UA Alice wants to give > > > > > Bob location > > > > > information (via reference). Now, Alice could easily indicate that >it > > > > > wants Bob to resolve the reference and to process the > > > > > location object. > > > > > Stating this explicitly would prevent proxies to resolve it and to > > > > > process the location object. > > > > > > > > > > Ciao > > > > > Hannes > > > > > > > > > > > > > > > _______________________________________________ > > > > > Geopriv mailing list > > > > > Geopriv@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > > > > > > _______________________________________________ > > > > > Geopriv mailing list > > > > > Geopriv@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > > > > > > > >_______________________________________________ > > > >Geopriv mailing list > > > >Geopriv@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 05 17:04:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMDL-0006nR-0a; Mon, 05 Jun 2006 17:02:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMDJ-0006nM-52 for sip@ietf.org; Mon, 05 Jun 2006 17:02:17 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnMDF-0002G4-UN for sip@ietf.org; Mon, 05 Jun 2006 17:02:17 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 9994D6C017 for ; Mon, 5 Jun 2006 17:02:13 -0400 (EDT) Subject: Re: [Sip] What error response to Naked Invite? From: "Dale R. Worley" To: Sip In-Reply-To: References: Content-Type: text/plain Date: Mon, 05 Jun 2006 17:02:13 -0400 Message-Id: <1149541333.5683.30.camel@niagra.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mon, 2006-06-05 at 16:24 -0400, steven.d.whitehead@verizon.com wrote: > If a UAS doesn't support naked INVITEs, what error response should it > generate? Is there a preferred response? Is it 415 unsupported media type? 488 Not Acceptable Here, unless it is a clothing-optional location ;-) Seriously -- what do you mean by "naked INVITE"? If you mean INVITE without SDP, a UAS is required to support that. See RFC 3261, section 13.2.1, page 80, 5th paragraph: "Concretely, the above rules specify two exchanges for UAs compliant to this specification alone - [...], or the offer is in the 2xx, and the answer is in the ACK. All user agents that support INVITE MUST support these two exchanges" Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 05 17:33:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMg0-0001bE-JT; Mon, 05 Jun 2006 17:31:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMfz-0001UB-3l for sip@ietf.org; Mon, 05 Jun 2006 17:31:55 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnMfx-0003J9-JL for sip@ietf.org; Mon, 05 Jun 2006 17:31:55 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 05 Jun 2006 14:31:53 -0700 X-IronPort-AV: i="4.05,211,1146466800"; d="scan'208"; a="1819626153:sNHT49694810" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k55LVpbS008019; Mon, 5 Jun 2006 14:31:51 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k55LVGcT007962; Mon, 5 Jun 2006 14:31:46 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Jun 2006 17:31:05 -0400 Received: from [161.44.79.149] ([161.44.79.149]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Jun 2006 17:31:05 -0400 Message-ID: <4484A299.8090708@cisco.com> Date: Mon, 05 Jun 2006 17:31:05 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Dale R. Worley" Subject: Re: [Sip] What error response to Naked Invite? References: <1149541333.5683.30.camel@niagra.pingtel.com> In-Reply-To: <1149541333.5683.30.camel@niagra.pingtel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jun 2006 21:31:05.0523 (UTC) FILETIME=[59FD4030:01C688E7] DKIM-Signature: a=rsa-sha1; q=dns; l=1132; t=1149543111; x=1150407111; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20What=20error=20response=20to=20Naked=20Invite?; X=v=3Dcisco.com=3B=20h=3DigetX/IAaLez8BfpzYfYdDQ1rC0=3D; b=ENfKwQoN5lgSbvfdswuHpnN0DEhRasfaGt9B3Oc4dfqs6rgrNLJ8hPScwTMvGe0CbmM5u7a9 Fqs+bESgFYwPHIiQ28uUAxPd9C2KieqLIaQCB4YAO9y9TINbC0KS97V7; Authentication-Results: sj-dkim-6.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dale R. Worley wrote: > On Mon, 2006-06-05 at 16:24 -0400, steven.d.whitehead@verizon.com wrote: >> If a UAS doesn't support naked INVITEs, what error response should it >> generate? Is there a preferred response? Is it 415 unsupported media type? > > 488 Not Acceptable Here, unless it is a clothing-optional location ;-) > > Seriously -- what do you mean by "naked INVITE"? > > If you mean INVITE without SDP, a UAS is required to support that. See > RFC 3261, section 13.2.1, page 80, 5th paragraph: "Concretely, the above > rules specify two exchanges for UAs compliant to this specification > alone - [...], or the offer is in the 2xx, and the answer is in the ACK. > All user agents that support INVITE MUST support these two exchanges" If your assumption about the meaning of "naked INVITE" is correct, then I guess it would be appropriate for this server to respond with a 500, because the server clearly has experienced an internal error by not being able to process this. Just include a Retry-After that is large enough to give time for the implementation to be corrected. :-) 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 Mon Jun 05 21:54:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnQkG-0003ZV-1w; Mon, 05 Jun 2006 21:52:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnQkE-0003ZN-Gb for sip@ietf.org; Mon, 05 Jun 2006 21:52:34 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnQkD-00014c-0G for sip@ietf.org; Mon, 05 Jun 2006 21:52:34 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0F006FF18854@szxga01-in.huawei.com> for sip@ietf.org; Tue, 06 Jun 2006 09:52:56 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0F00JGW188DF@szxga01-in.huawei.com> for sip@ietf.org; Tue, 06 Jun 2006 09:52:56 +0800 (CST) Received: from z53160 ([10.164.5.15]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0F00DWQ17KNG@szxml03-in.huawei.com> for sip@ietf.org; Tue, 06 Jun 2006 09:52:40 +0800 (CST) Date: Tue, 06 Jun 2006 09:51:29 +0800 From: zhou hong To: sip@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.2627 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: 08170828343bcf1325e4a0fb4584481c Subject: [Sip] outbound-keepalive question X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, In draft-ietf-sip-outbound-03 says " This document defines a new STUN usage for inband connectivity checks. The only STUN messages required by this usage are Binding Requests, Binding Responses, and Error Responses. The UAC sends Binding Requests over the same UDP flow, TCP connection, or TLS channel used for sending SIP messages, once a SIP registration has been successfully processed on that flow". But in draft-ietf-behave-rfc3489bis-03 says " There are two types of requests defined in this specification - Binding Requests, sent over UDP, and Shared Secret Requests, sent over TLS [6] over TCP ". So who can tell me which one is right or both right? Regards, Hong _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 06 00:51:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnTVe-0005uq-7E; Tue, 06 Jun 2006 00:49:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnTVc-0005uk-Sc for sip@ietf.org; Tue, 06 Jun 2006 00:49:40 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnTVb-0001Vs-Gp for sip@ietf.org; Tue, 06 Jun 2006 00:49:40 -0400 Received: from [192.168.2.103] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k564p05V028437 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 5 Jun 2006 23:51:01 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] What error response to Naked Invite? Date: Mon, 5 Jun 2006 23:49:39 -0500 To: steven.d.whitehead@verizon.com X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 5, 2006, at 3:24 PM, steven.d.whitehead@verizon.com wrote: > If a UAS doesn't support naked INVITEs, what error response should it > generate? Is there a preferred response? Is it 415 unsupported > media type? > The "Naked INVITE" is a phenomenon wlosely related to the East African "Naked Mole Rat", Heterocephalus Glaber, and if you can't figure out the relationship, I suggest using Google. Oh, heck, I'll spell it out -- they're both nominally ugly, occur primarily in eusocial structures, and are believed to be coprophagic, but only one is a rodent. See: http://www.bbc.co.uk/nature/wildfacts/factfiles/614.shtml But let's assume we're talking about an INVITE request without an SDP body carrying the "offer" of the offer/answer model documented in RFC 3264. One might argue that an improperly socialized UAS that rejected an INVITE request on the basis of the media (or lack thereof) specified therein might do so with a 415, which RFC 3261 describes as: If a 415 (Unsupported Media Type) response is received (Section 21.4.13), the request contained media types not supported by the UAS. The UAC SHOULD retry sending the request, this time only using content with types listed in the Accept header field in the response, with encodings listed in the Accept-Encoding header field in the response, and with languages listed in the Accept-Language in the response. and 8.2.3 Content Processing goes on to say: Assuming the UAS understands any extensions required by the client, the UAS examines the body of the message, and the header fields that describe it. If there are any bodies whose type (indicated by the Content-Type), language (indicated by the Content-Language) or encoding (indicated by the Content-Encoding) are not understood, and that body part is not optional (as indicated by the Content- Disposition header field), the UAS MUST reject the request with a 415 (Unsupported Media Type) response. The response MUST contain an Accept header field listing the types of all bodies it understands, in the event the request contained bodies of types not supported by the UAS. If the request contained content encodings not understood by the UAS, the response MUST contain an Accept-Encoding header field listing the encodings understood by the UAS. If the request contained content with languages not understood by the UAS, the response MUST contain an Accept-Language header field indicating the languages understood by the UAS. Beyond these checks, body handling depends on the method and type. For further information on the processing of content-specific header fields, see Section 7.4 as well as Section 20.11 through 20.15. However, we have, in RFC 3261 13.2.1 o The initial offer MUST be in either an INVITE or, if not there, in the first reliable non-failure message from the UAS back to the UAC. In this specification, that is the final 2xx response. and, a few paragraphs later: Concretely, the above rules specify two exchanges for UAs compliant to this specification alone - the offer is in the INVITE, and the answer in the 2xx (and possibly in a 1xx as well, with the same value), or the offer is in the 2xx, and the answer is in the ACK. All user agents that support INVITE MUST support these two exchanges. So it would seem that our UAS here is behaving in a fashion somewhat inconsistent with RFC 3261 by rejecting the INVITE-without-SDP. The correct response to such a request is to respond with an offer in the 200 OK. Now, let's say this just doesn't work, because we're using preconditions as per RFC 3312, which would be indicated by a "Require: precondition" in the request, probably along with a "Supported: 100-rel". This lets us extend the offer/answer model of RGC 3261 by placing the offer into a PRACK, which is now a reliable message and therefore capable of meeting the requirements of RFC 3261 13.2.1. So, since we've already established it's non-compliant with RFC 3261, the UAS might as well come back with a 418 "I'm a teapot" message, because it's broken. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 06 07:46:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnZyv-0007Hn-G6; Tue, 06 Jun 2006 07:44:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnZyu-0007Hh-7L for sip@ietf.org; Tue, 06 Jun 2006 07:44:20 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnYyJ-0006av-Up for sip@ietf.org; Tue, 06 Jun 2006 06:39:39 -0400 Received: from ausmtp06.au.ibm.com ([202.81.18.155]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FnYpQ-00009K-Oo for sip@ietf.org; Tue, 06 Jun 2006 06:30:30 -0400 Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp06.au.ibm.com (8.13.6/8.13.6) with ESMTP id k56AWTr05546024 for ; Tue, 6 Jun 2006 20:32:33 +1000 Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.250.244]) by sd0208e0.au.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k56AXb2q205228 for ; Tue, 6 Jun 2006 20:33:43 +1000 Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k56AUGHd019169 for ; Tue, 6 Jun 2006 20:30:16 +1000 Received: from d23m0037.cn.ibm.com (d23m0037.cn.ibm.com [9.181.2.105]) by d23av03.au.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k56AUFrV018978 for ; Tue, 6 Jun 2006 20:30:15 +1000 From: Xin Sheng Mao To: sip@ietf.org Message-ID: Date: Tue, 6 Jun 2006 18:32:54 +0800 X-MIMETrack: Serialize by Router on D23M0037/23/M/IBM(Release 7.0HF124 | January 12, 2006) at 06/06/2006 18:33:01 MIME-Version: 1.0 X-Spam-Score: -0.3 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Sip] Xin Sheng Mao/China/IBM 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: , Content-Type: multipart/mixed; boundary="===============0008670385==" Errors-To: sip-bounces@ietf.org --===============0008670385== Content-type: multipart/alternative; Boundary="0__=C7BBFB16DFAA775A8f9e8a93df938690918cC7BBFB16DFAA775A" Content-Disposition: inline --0__=C7BBFB16DFAA775A8f9e8a93df938690918cC7BBFB16DFAA775A Content-type: text/plain; charset=US-ASCII I will be out of the office starting 06/06/2006 and will not return until 06/10/2006. I am out of office for Spring Festival, ie., Chinese New Year, till Feb. 5th. Pls access me at my cell phone if you have any urgency. --0__=C7BBFB16DFAA775A8f9e8a93df938690918cC7BBFB16DFAA775A Content-type: text/html; charset=US-ASCII Content-Disposition: inline

I will be out of the office starting 06/06/2006 and will not return until 06/10/2006.

I am out of office for Spring Festival, ie., Chinese New Year, till Feb. 5th. Pls access me at my cell phone if you have any urgency. --0__=C7BBFB16DFAA775A8f9e8a93df938690918cC7BBFB16DFAA775A-- --===============0008670385== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0008670385==-- From sip-bounces@ietf.org Tue Jun 06 11:20:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FndK1-0003kz-CF; Tue, 06 Jun 2006 11:18:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FndJz-0003ku-LY for sip@ietf.org; Tue, 06 Jun 2006 11:18:19 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FndJy-0005GS-Bw for sip@ietf.org; Tue, 06 Jun 2006 11:18:19 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k56FIEmT029823 for ; Tue, 6 Jun 2006 10:18:17 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 6 Jun 2006 16:18:14 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C2908F0@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt Date: Tue, 6 Jun 2006 16:18:12 +0100 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: 3002fc2e661cd7f114cb6bae92fe88f1 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (as WG chair) The author thinks this document is complete. If this is true we should be putting it into working group last call, and after that pushing it up to the IESG. Do you (the SIP WG) agree with author, such that this document is ready, or are there issues you would still like addressed with this document. Secondly, in parallel with the WGLC, we would like to see some detailed reviewers. If you would like to do this, particularly if you are attempting to use this draft in some application, please send your names to Dean and myself. regards Keith > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: 02 June 2006 20:50 > To: i-d-announce@ietf.org > Cc: sip@ietf.org > Subject: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.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 : Diagnostic Responses for SIP Hop Limit Errors > Author(s) : S. Lawrence, et al. > Filename : draft-ietf-sip-hop-limit-diagnostics-02.txt > Pages : 12 > Date : 2006-6-2 > > The SIP protocol imposes a limit on the number of hops a request may > make from a sender to the recipient. When this limit is reached, a > 483 error response is returned. The present form of the 483 response > does not provide enough information for the sender or proxies on the > path to diagnose failures whose symptom is that the hop limit is > reached. This document proposes additional diagnostic information to > be returned in a 483 response. > > Comments are solicited, and should be directed to the SIP working > group list at 'sip@ietf.org'. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-hop-limit-d iagnostics-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-hop-limit-diagnostics-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-hop-limit-diagnostics-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 06 13:58:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnfmo-0007yf-HQ; Tue, 06 Jun 2006 13:56:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnfmn-0007ya-A6 for sip@ietf.org; Tue, 06 Jun 2006 13:56:13 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnfml-0008FH-R4 for sip@ietf.org; Tue, 06 Jun 2006 13:56:13 -0400 Received: from [192.168.2.103] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k56HvXXG031559 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Tue, 6 Jun 2006 12:57:34 -0500 Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: <2B137721-9B8A-4EB1-94A8-6039C06D8F09@softarmor.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Sip IETF From: Dean Willis Date: Tue, 6 Jun 2006 12:56:13 -0500 X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Sip] What to do with SIP SAML 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: , Errors-To: sip-bounces@ietf.org Our current charter and slightly-stale milestones include a deliverable for SAML: Jul 2006 -- Using SAML for SIP (PS) At the IETF 65, we discussed the Tschofenig draft, currently available as: http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-05.txt We didn't have a firm consensus in the room for what to do with this, so It'd like to discuss it now. Our options include: 1) Adopt this draft as a WG document and keep working on it. 2) Decide we don't need to solve the problem just yet and abandon the milestone. 3) Let Hannes and team keep working on it until we decide it has reached critical mass, and keep slipping the milestone along. 4) Do something entirely different. So, what do you people think? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 06 14:27:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FngFV-0005M6-MT; Tue, 06 Jun 2006 14:25:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnL2K-0004di-7m for sip@ietf.org; Mon, 05 Jun 2006 15:46:52 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnL2I-0005pV-UC for sip@ietf.org; Mon, 05 Jun 2006 15:46:52 -0400 Received: from montag.eng.l3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k55JkmaK014585; Mon, 5 Jun 2006 19:46:48 GMT Subject: Re: [Sip] draft-poretsky-sip-bench-term-00.txt From: Daryl Malas To: henry@pulver.com In-Reply-To: <00ba01c68696$eff6c0a0$2800a8c0@DSX400> References: <00ba01c68696$eff6c0a0$2800a8c0@DSX400> Content-Type: text/plain Organization: Message-Id: <1149536788.4648.13.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 05 Jun 2006 13:46:29 -0600 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-Mailman-Approved-At: Tue, 06 Jun 2006 14:25:48 -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: , Errors-To: sip-bounces@ietf.org On a similar topic, I just posted an updated version of a draft called "SIP Performance Metrics", see http://www.ietf.org/internet-drafts/draft-malas-performance-metrics.02.txt This draft does not focus on the testing aspects, but rather on the ability for vendors, subscribers, and providers to measure the performance of their SIP elements in a production environment. It defines the metrics and the methods for calculating them. It can be used as a guideline for the development of KPI's or SLA's directly related to SIP environments. Thanks, Daryl On Fri, 2006-06-02 at 16:50, Henry Sinnreich wrote: > The new I-D "Terminology for Benchmarking SIP Networking Devices", see > http://www.ietf.org/internet-drafts/draft-poretsky-sip-bench-term-00.txt > > talks about items on the Internet that are not documented in any RFC, such > as the SIP Control Plane and the SIP Media Plane. > > - How does this fit with the Internet e2e architecture? > - Are such planes defined in any SIP related RFC or elsewhere in the IETF? > - What are the two dimensions for each plane? > - Can there be a black box benchmark without describing its behavior (for > example the behavior of a SIP proxy is well documented)? > > There are several other concepts that have no definition in the IETF, though > they have a familiar ring from ITU-T documents. > > Thanks, Henry > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 06 14:36:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FngNf-0000xW-Pj; Tue, 06 Jun 2006 14:34:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FizGa-0002a4-9a for sip@ietf.org; Wed, 24 May 2006 15:43:36 -0400 Received: from nwkea-mail-5.sun.com ([192.18.42.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FizGV-0002nG-TR for sip@ietf.org; Wed, 24 May 2006 15:43:36 -0400 Received: from jurassic.eng.sun.com ([129.146.226.130]) by nwkea-mail-5.sun.com (8.12.10/8.12.9) with ESMTP id k4OJhS4P016558 for ; Wed, 24 May 2006 12:43:28 -0700 (PDT) Received: from ishana (ishana.SFBay.Sun.COM [129.146.108.217]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4OJhSlO982334 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 24 May 2006 12:43:28 -0700 (PDT) Date: Wed, 24 May 2006 12:49:37 -0700 (PDT) From: venugopal iyer X-X-Sender: vi117747@ishana To: sip@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-Mailman-Approved-At: Tue, 06 Jun 2006 14:34:18 -0400 Subject: [Sip] privacy header format - RFC 3323 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Am looking for some clarification about the definition of Privacy-hdr (from RFC 3323): Privacy-hdr = "Privacy" HCOLON priv-value *(";" priv-value) priv-value = "header" / "session" / "user" / "none" / "critical" / token I am not clear about ";" above given the header defns in RFC 3261. I would have thought it should be a COMMA. I maybe missing something. I did come across a mail that specifically talks about this: (http://www.atm.tut.fi/list-archive/sip/msg05124.html) " > Privacy-hdr = "Privacy" HCOLON priv-value *(COMMA priv-value) > priv-value = "header" | "session" | "user" | "none" | "critical" | token I would strongly advise that you also allow for semi-colon separated parameters for the purposes of future extensibility. Also, you need to use slashes "/" to separate or-values, not vertical bars "|". " but am not sure the comment actually resulted in the change from COMMA to SEMI. thanks, -venu _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 06 14:55:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnggY-0005FG-UM; Tue, 06 Jun 2006 14:53:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnggX-0005FB-9T for sip@ietf.org; Tue, 06 Jun 2006 14:53:49 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnggW-0006sy-P9 for sip@ietf.org; Tue, 06 Jun 2006 14:53:49 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0J0G00H01CICPM@siemenscomms.co.uk> for sip@ietf.org; Tue, 06 Jun 2006 19:54:12 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J0G00G5PCICIX@siemenscomms.co.uk>; Tue, 06 Jun 2006 19:54:12 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 06 Jun 2006 19:53:47 +0100 Content-return: allowed Date: Tue, 06 Jun 2006 19:53:46 +0100 From: "Elwell, John" Subject: RE: AW: AW: [Sip] Connected-identity and changing the To header f ield ina response To: "Christer Holmberg (JO/LMF)" , Paul Kyzivat , "Jesske, R" Message-id: <50B1CBA96870A34799A506B2313F266709182406@ntht201e.siemenscomms.co.uk> 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: 48472a944c87678fcfe8db15ffecdfff Cc: fluffy@cisco.com, sip@ietf.org, roland.jesske@web.de X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer, You wrote: "It has been agreed on the list that it should not cause any = harm to 3261 compliant nodes because the To header is not used as a = transaction identifier." I don't think this is agreed. I think there may have been acceptance that the transaction model does not appear to be broken, but there are other concerns, especially those expressed in the past by Jon Peterson. Regards, John =20 > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Sent: 01 June 2006 17:46 > To: Paul Kyzivat; Jesske, R > Cc: fluffy@cisco.com; sip@ietf.org; Elwell, John; = roland.jesske@web.de > Subject: RE: AW: AW: [Sip] Connected-identity and changing=20 > the To header field ina response >=20 >=20 > Hi Paul, >=20 > One suggestion has been to modify the To header in the=20 > response. It has been agreed on the list that it should not=20 > cause any harm to 3261 compliant nodes because the To header=20 > is not used as a transaction identifier. As, for the dialog=20 > identifier, only the tag parameter is used (and that would=20 > not be modified). >=20 > Regards, >=20 > Christer >=20 >=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 1. kes=E4kuuta 2006 16:43 > To: Jesske, R > Cc: fluffy@cisco.com; sip@ietf.org; john.elwell@siemens.com;=20 > roland.jesske@web.de; Christer Holmberg (JO/LMF) > Subject: Re: AW: AW: [Sip] Connected-identity and changing=20 > the To header field ina response >=20 > I don't know if Reply-To would be any better for your=20 > schedule than a new header. It will still require an RFC to=20 > make it legal to use in responses. But it would avoid=20 > bringing yet another new header into the world. >=20 > IMO, if the semantics are right, then it is better to reuse=20 > it than to invent something new. If the semantics are wrong,=20 > then it shouldn't be used. Based on my limited understanding=20 > of the usage, the semantics seem about right to me. >=20 > Paul >=20 > Jesske, R wrote: > > Paul, > > in the past we lookes also on the Reply-to header. But per=20 > definition it is the address where the user want to be=20 > connected. So it is not in each case the real conected=20 > identity. But the COLP (TIP) service could be used in the same way. > > So if it would be possible to use Reply-to header in=20 > Responses, if people are willing and we as TISPAN can narrow=20 > it then only to the real connected identity (within our=20 > walled garden service definition) I would be happy. > >=20 > > Best Regards > >=20 > > Roland > >=20 > >> -----Urspr=FCngliche Nachricht----- > >> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Gesendet: Mittwoch, 31. Mai 2006 17:04 > >> An: Jesske, Roland > >> Cc: fluffy@cisco.com; sip@ietf.org; john.elwell@siemens.com;=20 > >> roland.jesske@web.de; christer.holmberg@ericsson.com > >> Betreff: Re: AW: [Sip] Connected-identity and changing the=20 > To header=20 > >> field ina response > >> > >> > >> > >> > >> Jesske, R wrote: > >>> These are the requirements we already expressed in our > >> draft draft-jesske-sipping-tispan-requirements-02: > >>> REQ-TIP-1: In addition to any network asserted identity, > >> it must be > >>> possible for the callee to indicate in a SIP > >> response an > >>> additional identity where the user is > >> reachable for future > >>> direct communications. Note that the > >> requirement refers > >>> to the user, not to the same instance of the > >> User Agent. > >>> REQ-TIP-2: The identity mentioned in REQ-TIP-1 must be > >> formatted as a > >>> SIP URI [2] or TEL URL [3]. A translation > >> between SIP URI > >>> and TEL URL by the network is not requested. > >>> REQ-TIP-3: The identity mentioned in REQ-TIP-1 is > >> considered an end > >>> user supplied information that is not=20 > asserted by the > >>> network. > >>> > >>> > >>> As you can see we do not need any authenticated identity in > >> the response. For the authenticated identity we are using the=20 > >> P-Asserted-Identity. So we have two identities in a Response. > >>> For our purposes the user provided identity in a final 200 > >> OK response is sufficient. So that avoids confusion within forking = > >> cases. > >> > >> I haven't been paying close attention to this. What header are you = > >> planning to use to carry this callee provided identity? > >> > >> The Reply-To header would seem to be appropriate for this purpose, = > >> but unfortunately, according to table 2 of 3261, it is=20 > only allowed=20 > >> in INVITE. > >> > >> Paul > >> > >>> Roland > >>> > >>> > >>> > >>> > >>>> -----Urspr=FCngliche Nachricht----- > >>>> Von: Cullen Jennings [mailto:fluffy@cisco.com] > >>>> Gesendet: Montag, 22. Mai 2006 17:32 > >>>> An: Jesske, Roland > >>>> Cc: John Elwell; sip@ietf.org; Roland Jesske; Christer Holmberg=20 > >>>> (JO/LMF) > >>>> Betreff: Re: [Sip] Connected-identity and changing the To header = > >>>> field ina response > >>>> > >>>> > >>>> > >>>> On May 16, 2006, at 7:07 AM, Jesske, R wrote: > >>>> > >>>>> John, > >>>>> it is that we don't can get an connected identity within > >> the final > >>>>> response of the initial INVITE. > >>>>> Your draft proposes a mid dialog request for getting this > >>>> information. > >>>>> That is not usable for the TIP service. > >>>> I think this is part of what I am not understanding. What is the = > >>>> requirement here? > >>>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol Use=20 > >>> sip-implementors@cs.columbia.edu for questions on current sip Use = > >>> sipping@ietf.org for new developments on the application of sip > >>> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >> > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 06 15:19:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnh3p-0000ee-ER; Tue, 06 Jun 2006 15:17:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnh3n-0000eZ-Dt for sip@ietf.org; Tue, 06 Jun 2006 15:17:51 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnh3m-00015C-Qm for sip@ietf.org; Tue, 06 Jun 2006 15:17:51 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0J0G00001DMETZ@siemenscomms.co.uk> for sip@ietf.org; Tue, 06 Jun 2006 20:18:15 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J0G00M2TDMDDA@siemenscomms.co.uk>; Tue, 06 Jun 2006 20:18:13 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 06 Jun 2006 20:17:48 +0100 Content-return: allowed Date: Tue, 06 Jun 2006 20:17:47 +0100 From: "Elwell, John" Subject: RE: AW: AW: [Sip] Connected-identity and changing the To header f ield ina response To: "Jesske, R" , fluffy@cisco.com Message-id: <50B1CBA96870A34799A506B2313F26670918240F@ntht201e.siemenscomms.co.uk> 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: 83e9494d829b08cc3f644ef6ac1b9bd4 Cc: sip@ietf.org, pkyzivat@cisco.com, roland.jesske@web.de, christer.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The requirements have indeed been described in the tispan-requirement= s draft, but clearly there is still some misunderstanding. Let me try t= o shed some light, although my background is enterprise rather than carrier = and I don't pretend to understand all practices of PSTN or NGN. A PSTN carries two identities in each direction - one that has been "authenticated" or "screened" by the PSTN and one that has been recei= ved =66rom outside the PSTN and has not been screened. The first type of = identity is used for billing, authorisation etc. within the PSTN, and may also= be delivered to the customer premises equipment. The second type of iden= tity is used only for delivery to the customer premises equipment. What the c= ustomer premises equipment does with the two types of identities is not reall= y specified, but I think enterprise networks (e.g., based on QSIG) woul= d normally use only the first type of identity for passing through the enterprise network to the end user. I believe TISPAN has ambitions to support these two types of identity= in NGN, so this leads to the question how to carry the two identities in= SIP. For the INVITE request, the first caller identity is carried in the P-Asserted-Identity header, the first node in the NGN having authenti= cated the source of the request by some means (e.g., through the certificat= e supplied during TLS handshake). The second caller identity is carried= in the =46rom header. Obviously the latter is open to falsification unless s= upported by an Identity header. With the Identity header, the second caller id= entity would be far more useful to the destination customer premises equipme= nt. For the reverse direction, the first callee identity is carried in th= e P-Asserted-Identity header, I believe. There are fewer authentication options, but I guess TLS-based authentication is still a possibility.= So the question is how to supply the second callee identity. Option 1. Modify the To header in the INVITE response. There have bee= n objections to this. Also it would not be authenticated, so it would n= ot be nearly as useful as the second identity in the request, which can be authenticated by the Identity header. Option 2. Use the Reply-To header or some new header in the INVITE re= sponse. The objections concerning modifying the To header go away, but again = it would not be authenticated, so it would not be nearly as useful as th= e second identity in the request. Option 3. Use the From header in conjunction with the Identity header= in a request in the reverse direction, as specified in the Connected-Ident= ity draft. This seems to solve the problem, except that it may make inter= working with PSTN signalling more difficult since PSTN expects the second ide= ntity in the "answer" message. If a solution to this signalling interworkin= g can be found, I think option 3 would clearly be the best solution. John > -----Original Message----- > From: Jesske, R [mailto:R.Jesske@t-com.net]=20 > Sent: 01 June 2006 09:42 > To: fluffy@cisco.com > Cc: sip@ietf.org; pkyzivat@cisco.com; Elwell, John;=20 > roland.jesske@web.de; christer.holmberg@ericsson.com > Subject: AW: AW: AW: [Sip] Connected-identity and changing=20 > the To header f ield ina response >=20 > The two identities are used for PBX services. > Example > If a user calls a special hotline for e.G. Computer Services.=20 > +496151830. > This is the main number of a PBX with several extensions. The=20 > user will be at least connected to an Service Expert=20 > (Extension No: +496151831111). > So now there is a Public Id (+496151830) that is trusted and=20 > the all billing is bind to. (TISPAN uses the P-Asserted-Identity) > and a private not secure id of the Expert. Advantage is that=20 > the Caller has now the ability to see the real connected=20 > number where the expert can now called directly. >=20 > This service is widely used within the PSTN/ISDN world and is=20 > known as COLP (Connected Line Identification Presentation)=20 > Specifies in ITU-T Q.731.5 and in ETSI ETSI EN 300 094 (free=20 > downloadable at portal.etsi.org). >=20 > We have described the Requirements in=20 > draft-jesske-sipping-tispan-requirements-01 and did some=20 > analysis in the past in draft-jesske-sipping-tispan-analysis-00.txt >=20 > Best Regards >=20 > Roland >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Cullen Jennings [mailto:fluffy@cisco.com]=20 > > Gesendet: Donnerstag, 1. Juni 2006 09:11 > > An: Jesske, Roland > > Cc: pkyzivat@cisco.com; sip@ietf.org;=20 > > john.elwell@siemens.com; roland.jesske@web.de;=20 > > christer.holmberg@ericsson.com > > Betreff: Re: AW: AW: [Sip] Connected-identity and changing=20 > > the To header field ina response > >=20 > >=20 > >=20 > > What things use these two identities, what do they get used=20 > for, and =20 > > what security assumptions come around them. That type of=20 > information =20 > > would help people on this list understand the problem. > >=20 > > On May 31, 2006, at 10:28 PM, Jesske, R wrote: > >=20 > > > Paul, > > > in the past we lookes also on the Reply-to header. But per = =20 > > > definition it is the address where the user want to be=20 > connected. =20 > > > So it is not in each case the real conected identity. But=20 > the COLP =20 > > > (TIP) service could be used in the same way. > > > So if it would be possible to use Reply-to header in=20 > Responses, if =20 > > > people are willing and we as TISPAN can narrow it then=20 > only to the =20 > > > real connected identity (within our walled garden service =20 > > > definition) I would be happy. > > > > > > Best Regards > > > > > > Roland > > > > > >> -----Urspr=FCngliche Nachricht----- > > >> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > >> Gesendet: Mittwoch, 31. Mai 2006 17:04 > > >> An: Jesske, Roland > > >> Cc: fluffy@cisco.com; sip@ietf.org; john.elwell@siemens.com; > > >> roland.jesske@web.de; christer.holmberg@ericsson.com > > >> Betreff: Re: AW: [Sip] Connected-identity and changing the To > > >> header field ina response > > >> > > >> > > >> > > >> > > >> Jesske, R wrote: > > >>> These are the requirements we already expressed in our > > >> draft draft-jesske-sipping-tispan-requirements-02: > > >>> > > >>> REQ-TIP-1: In addition to any network asserted identity, > > >> it must be > > >>> possible for the callee to indicate in a SIP > > >> response an > > >>> additional identity where the user is > > >> reachable for future > > >>> direct communications. Note that the > > >> requirement refers > > >>> to the user, not to the same instance of the > > >> User Agent. > > >>> REQ-TIP-2: The identity mentioned in REQ-TIP-1 must be > > >> formatted as a > > >>> SIP URI [2] or TEL URL [3]. A translation > > >> between SIP URI > > >>> and TEL URL by the network is not requested. > > >>> REQ-TIP-3: The identity mentioned in REQ-TIP-1 is > > >> considered an end > > >>> user supplied information that is not=20 > > asserted by the > > >>> network. > > >>> > > >>> > > >>> As you can see we do not need any authenticated identity in > > >> the response. For the authenticated identity we are using the > > >> P-Asserted-Identity. So we have two identities in a Response. > > >>> For our purposes the user provided identity in a final 200 > > >> OK response is sufficient. So that avoids confusion within > > >> forking cases. > > >> > > >> I haven't been paying close attention to this. What=20 > header are you > > >> planning to use to carry this callee provided identity? > > >> > > >> The Reply-To header would seem to be appropriate for this > > >> purpose, but > > >> unfortunately, according to table 2 of 3261, it is only > > >> allowed in INVITE. > > >> > > >> =09Paul > > >> > > >>> Roland > > >>> > > >>> > > >>> > > >>> > > >>>> -----Urspr=FCngliche Nachricht----- > > >>>> Von: Cullen Jennings [mailto:fluffy@cisco.com] > > >>>> Gesendet: Montag, 22. Mai 2006 17:32 > > >>>> An: Jesske, Roland > > >>>> Cc: John Elwell; sip@ietf.org; Roland Jesske; Christer > > >>>> Holmberg (JO/LMF) > > >>>> Betreff: Re: [Sip] Connected-identity and changing the To > > >>>> header field ina response > > >>>> > > >>>> > > >>>> > > >>>> On May 16, 2006, at 7:07 AM, Jesske, R wrote: > > >>>> > > >>>>> John, > > >>>>> it is that we don't can get an connected identity within > > >> the final > > >>>>> response of the initial INVITE. > > >>>>> Your draft proposes a mid dialog request for getting this > > >>>> information. > > >>>>> That is not usable for the TIP service. > > >>>> I think this is part of what I am not understanding.=20 > What is the > > >>>> requirement here? > > >>>> > > >>> > > >>> _______________________________________________ > > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >>> This list is for NEW development of the core SIP Protocol > > >>> Use sip-implementors@cs.columbia.edu for questions on=20 > current sip > > >>> Use sipping@ietf.org for new developments on the=20 > > application of sip > > >>> > > >> > > >> _______________________________________________ > > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >> This list is for NEW development of the core SIP Protocol > > >> Use sip-implementors@cs.columbia.edu for questions on current = sip > > >> Use sipping@ietf.org for new developments on the=20 > application of sip > > >> > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 06 15:51:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnhZ3-0001iJ-Ti; Tue, 06 Jun 2006 15:50:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnhYy-0001g3-2D; Tue, 06 Jun 2006 15:50:04 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnhYv-0005hO-Px; Tue, 06 Jun 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k56Jo1WR015764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FnhYv-0007M4-Jt; Tue, 06 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 06 Jun 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-mib-11.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Management Information Base for the Session Initiation Protocol (SIP) Author(s) : D. Walker, et al. Filename : draft-ietf-sip-mib-11.txt Pages : 93 Date : 2006-6-6 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Session Initiation Protocol (SIP) entities, which include User Agents, Proxy, Redirect and Registrar servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-11.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-mib-11.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-mib-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-6130724.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-mib-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-mib-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-6130724.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Tue Jun 06 16:29:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fni9Z-00062C-Hw; Tue, 06 Jun 2006 16:27:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fni9Y-000622-Fp for sip@ietf.org; Tue, 06 Jun 2006 16:27:52 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fni9X-0002nk-Nx for sip@ietf.org; Tue, 06 Jun 2006 16:27:52 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 06 Jun 2006 13:27:50 -0700 X-IronPort-AV: i="4.05,214,1146466800"; d="scan'208"; a="1820492846:sNHT38732496" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k56KRnvS013034; Tue, 6 Jun 2006 13:27:50 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k56KRmIs010803; Tue, 6 Jun 2006 16:27:48 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Jun 2006 16:27:48 -0400 Received: from [161.44.79.149] ([161.44.79.149]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Jun 2006 16:27:48 -0400 Message-ID: <4485E543.8020705@cisco.com> Date: Tue, 06 Jun 2006 16:27:47 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Elwell, John" Subject: Re: AW: AW: [Sip] Connected-identity and changing the To header f ield ina response References: <50B1CBA96870A34799A506B2313F26670918240F@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F26670918240F@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 06 Jun 2006 20:27:48.0146 (UTC) FILETIME=[ACFD4120:01C689A7] DKIM-Signature: a=rsa-sha1; q=dns; l=12267; t=1149625670; x=1150489670; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20AW=3A=20AW=3A=20[Sip]=20Connected-identity=20and=20changing=20th e=20To=20header=20f=0A=20ield=20ina=09response; X=v=3Dcisco.com=3B=20h=3DkMCYm8MOlT+z3Q+dpd5652m4/a0=3D; b=AKmEz/xDAb8wvzhXC3wVuSVhPjNlVdV1r4omfcbDh7IPWJK1byJW5DoaGxXrZ5XOqQZ3qn8N e7agDMtAcwCmEiWWz/kKsEh8+fSThIU9LbaxjbCtC/IzLjYqnfY2q1Y6; Authentication-Results: sj-dkim-4.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 Cc: "Jesske, R" , fluffy@cisco.com, sip@ietf.org, roland.jesske@web.de, christer.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Elwell, John wrote: > The requirements have indeed been described in the tispan-requirements > draft, but clearly there is still some misunderstanding. Yup. > Let me try to shed > some light, although my background is enterprise rather than carrier and I > don't pretend to understand all practices of PSTN or NGN. Thanks for trying. > A PSTN carries two identities in each direction - one that has been > "authenticated" or "screened" by the PSTN and one that has been received > from outside the PSTN and has not been screened. The first type of identity > is used for billing, authorisation etc. within the PSTN, and may also be > delivered to the customer premises equipment. The second type of identity is > used only for delivery to the customer premises equipment. What the customer > premises equipment does with the two types of identities is not really > specified, but I think enterprise networks (e.g., based on QSIG) would > normally use only the first type of identity for passing through the > enterprise network to the end user. So what you are saying is that some trouble is taken to carry both of these identities, but at least in the case you cite the 2nd isn't ued for anything. Do I have that right? Is there a use case where it *is* used? If it isn't used, then why should a lot of effort be expended to replicate it? Even if both are delivered to the peer user equipment, what plausible actions are there for the equipment to take, when presented with one address that is trusted, and one that is advertised as not to be trusted? And I think there are variants when one or the other is not available. 1) if only one is available, display that one. if both are available, display the trusted one. a) indicate whether the number is trusted or not b) provide no indication of trustedness. 2) if only one is available, display it. If both are available, display the untrusted one. a) and b) as in 1. 3) if both are available, display both. indicate which is the trusted one. Of those, 3) might be good, if the device is capable of this. But few devices have such capability. It is hard to choose between 1 and 2, because the number of interest may vary with context. The example Roland gives only works for 2 (or 3). But it will be very hard for a service provider to decide to display an untrusted number in preference to a trusted number. So I doubt that service would work in practice. There is some benefit in displaying the untrusted number if the trusted number is unavailable (blocked). But I suspect in practice that won't happen - the untrusted number will also be blocked. Another possibility is that both numbers are trusted, but to different degrees. For instance, within my own company I trust the numbers provided by other callers from the same company (pbx). But those self declared numbers might not be trusted by a peer outside the company pbx. However I don't think that requires this feature. It can be handled by one P-Asserted-ID used inside the company, that is replaced when going outside the company. So, I'm still looking for the use case that makes this feature worth bothering with. > I believe TISPAN has ambitions to support these two types of identity in > NGN, so this leads to the question how to carry the two identities in SIP. > > For the INVITE request, the first caller identity is carried in the > P-Asserted-Identity header, the first node in the NGN having authenticated > the source of the request by some means (e.g., through the certificate > supplied during TLS handshake). The second caller identity is carried in the >>From header. Obviously the latter is open to falsification unless supported > by an Identity header. With the Identity header, the second caller identity > would be far more useful to the destination customer premises equipment. With the Identity header, there need be no other identity. What is the value of having both Identity, and a P-Asserted-ID with a different value? Paul > For the reverse direction, the first callee identity is carried in the > P-Asserted-Identity header, I believe. There are fewer authentication > options, but I guess TLS-based authentication is still a possibility. So the > question is how to supply the second callee identity. > > Option 1. Modify the To header in the INVITE response. There have been > objections to this. Also it would not be authenticated, so it would not be > nearly as useful as the second identity in the request, which can be > authenticated by the Identity header. > > Option 2. Use the Reply-To header or some new header in the INVITE response. > The objections concerning modifying the To header go away, but again it > would not be authenticated, so it would not be nearly as useful as the > second identity in the request. > > Option 3. Use the From header in conjunction with the Identity header in a > request in the reverse direction, as specified in the Connected-Identity > draft. This seems to solve the problem, except that it may make interworking > with PSTN signalling more difficult since PSTN expects the second identity > in the "answer" message. If a solution to this signalling interworking can > be found, I think option 3 would clearly be the best solution. > > John > >> -----Original Message----- >> From: Jesske, R [mailto:R.Jesske@t-com.net] >> Sent: 01 June 2006 09:42 >> To: fluffy@cisco.com >> Cc: sip@ietf.org; pkyzivat@cisco.com; Elwell, John; >> roland.jesske@web.de; christer.holmberg@ericsson.com >> Subject: AW: AW: AW: [Sip] Connected-identity and changing >> the To header f ield ina response >> >> The two identities are used for PBX services. >> Example >> If a user calls a special hotline for e.G. Computer Services. >> +496151830. >> This is the main number of a PBX with several extensions. The >> user will be at least connected to an Service Expert >> (Extension No: +496151831111). >> So now there is a Public Id (+496151830) that is trusted and >> the all billing is bind to. (TISPAN uses the P-Asserted-Identity) >> and a private not secure id of the Expert. Advantage is that >> the Caller has now the ability to see the real connected >> number where the expert can now called directly. >> >> This service is widely used within the PSTN/ISDN world and is >> known as COLP (Connected Line Identification Presentation) >> Specifies in ITU-T Q.731.5 and in ETSI ETSI EN 300 094 (free >> downloadable at portal.etsi.org). >> >> We have described the Requirements in >> draft-jesske-sipping-tispan-requirements-01 and did some >> analysis in the past in draft-jesske-sipping-tispan-analysis-00.txt >> >> Best Regards >> >> Roland >> >> >>> -----Ursprüngliche Nachricht----- >>> Von: Cullen Jennings [mailto:fluffy@cisco.com] >>> Gesendet: Donnerstag, 1. Juni 2006 09:11 >>> An: Jesske, Roland >>> Cc: pkyzivat@cisco.com; sip@ietf.org; >>> john.elwell@siemens.com; roland.jesske@web.de; >>> christer.holmberg@ericsson.com >>> Betreff: Re: AW: AW: [Sip] Connected-identity and changing >>> the To header field ina response >>> >>> >>> >>> What things use these two identities, what do they get used >> for, and >>> what security assumptions come around them. That type of >> information >>> would help people on this list understand the problem. >>> >>> On May 31, 2006, at 10:28 PM, Jesske, R wrote: >>> >>>> Paul, >>>> in the past we lookes also on the Reply-to header. But per >>>> definition it is the address where the user want to be >> connected. >>>> So it is not in each case the real conected identity. But >> the COLP >>>> (TIP) service could be used in the same way. >>>> So if it would be possible to use Reply-to header in >> Responses, if >>>> people are willing and we as TISPAN can narrow it then >> only to the >>>> real connected identity (within our walled garden service >>>> definition) I would be happy. >>>> >>>> Best Regards >>>> >>>> Roland >>>> >>>>> -----Ursprüngliche Nachricht----- >>>>> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>> Gesendet: Mittwoch, 31. Mai 2006 17:04 >>>>> An: Jesske, Roland >>>>> Cc: fluffy@cisco.com; sip@ietf.org; john.elwell@siemens.com; >>>>> roland.jesske@web.de; christer.holmberg@ericsson.com >>>>> Betreff: Re: AW: [Sip] Connected-identity and changing the To >>>>> header field ina response >>>>> >>>>> >>>>> >>>>> >>>>> Jesske, R wrote: >>>>>> These are the requirements we already expressed in our >>>>> draft draft-jesske-sipping-tispan-requirements-02: >>>>>> REQ-TIP-1: In addition to any network asserted identity, >>>>> it must be >>>>>> possible for the callee to indicate in a SIP >>>>> response an >>>>>> additional identity where the user is >>>>> reachable for future >>>>>> direct communications. Note that the >>>>> requirement refers >>>>>> to the user, not to the same instance of the >>>>> User Agent. >>>>>> REQ-TIP-2: The identity mentioned in REQ-TIP-1 must be >>>>> formatted as a >>>>>> SIP URI [2] or TEL URL [3]. A translation >>>>> between SIP URI >>>>>> and TEL URL by the network is not requested. >>>>>> REQ-TIP-3: The identity mentioned in REQ-TIP-1 is >>>>> considered an end >>>>>> user supplied information that is not >>> asserted by the >>>>>> network. >>>>>> >>>>>> >>>>>> As you can see we do not need any authenticated identity in >>>>> the response. For the authenticated identity we are using the >>>>> P-Asserted-Identity. So we have two identities in a Response. >>>>>> For our purposes the user provided identity in a final 200 >>>>> OK response is sufficient. So that avoids confusion within >>>>> forking cases. >>>>> >>>>> I haven't been paying close attention to this. What >> header are you >>>>> planning to use to carry this callee provided identity? >>>>> >>>>> The Reply-To header would seem to be appropriate for this >>>>> purpose, but >>>>> unfortunately, according to table 2 of 3261, it is only >>>>> allowed in INVITE. >>>>> >>>>> Paul >>>>> >>>>>> Roland >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Ursprüngliche Nachricht----- >>>>>>> Von: Cullen Jennings [mailto:fluffy@cisco.com] >>>>>>> Gesendet: Montag, 22. Mai 2006 17:32 >>>>>>> An: Jesske, Roland >>>>>>> Cc: John Elwell; sip@ietf.org; Roland Jesske; Christer >>>>>>> Holmberg (JO/LMF) >>>>>>> Betreff: Re: [Sip] Connected-identity and changing the To >>>>>>> header field ina response >>>>>>> >>>>>>> >>>>>>> >>>>>>> On May 16, 2006, at 7:07 AM, Jesske, R wrote: >>>>>>> >>>>>>>> John, >>>>>>>> it is that we don't can get an connected identity within >>>>> the final >>>>>>>> response of the initial INVITE. >>>>>>>> Your draft proposes a mid dialog request for getting this >>>>>>> information. >>>>>>>> That is not usable for the TIP service. >>>>>>> I think this is part of what I am not understanding. >> What is the >>>>>>> requirement here? >>>>>>> >>>>>> _______________________________________________ >>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>> This list is for NEW development of the core SIP Protocol >>>>>> Use sip-implementors@cs.columbia.edu for questions on >> current sip >>>>>> Use sipping@ietf.org for new developments on the >>> application of sip >>>>> _______________________________________________ >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP Protocol >>>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>>> Use sipping@ietf.org for new developments on the >> application of sip >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 06 16:35:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FniFa-0002y5-LQ; Tue, 06 Jun 2006 16:34:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FniFY-0002y0-NO for sip@ietf.org; Tue, 06 Jun 2006 16:34:04 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FniFV-0003Ea-Va for sip@ietf.org; Tue, 06 Jun 2006 16:34:04 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 06 Jun 2006 13:34:01 -0700 X-IronPort-AV: i="4.05,214,1146466800"; d="scan'208"; a="289979552:sNHT324657882" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k56KY1ew030331; Tue, 6 Jun 2006 13:34:01 -0700 Received: from billybong.cisco.com (billybong.cisco.com [171.71.163.234]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k56KY0cM017408; Tue, 6 Jun 2006 13:34:00 -0700 (PDT) Date: Tue, 6 Jun 2006 13:34:00 -0700 (PDT) From: Feng Cao To: "Elwell, John" Subject: RE: AW: AW: [Sip] Connected-identity and changing the To header f ield ina response In-Reply-To: <50B1CBA96870A34799A506B2313F26670918240F@ntht201e.siemenscomms.co.uk> Message-ID: References: <50B1CBA96870A34799A506B2313F26670918240F@ntht201e.siemenscomms.co.uk> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1254324197-1149626040=:20986" DKIM-Signature: a=rsa-sha1; q=dns; l=11404; t=1149626041; x=1150490041; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fcao@cisco.com; z=From:Feng=20Cao=20 |Subject:RE=3A=20AW=3A=20AW=3A=20[Sip]=20Connected-identity=20and=20changing=20th e=20To=20header=20f=0A=20ield=20ina=09response; X=v=3Dcisco.com=3B=20h=3DNPH0zh/CuVwQV2ZPS2epyqk3nAo=3D; b=ajoA8V9WW7nPqXqn02z1lKqi++oMDS98PduhO7lFFTiMz/SoWcupiy0egbimOsn2HFur0ixG Oe7PuIJBIUm3EAOH0aG0+m3eg7TO96hmnf/9++SFo65LD+oVRkiSjO5z; Authentication-Results: sj-dkim-7.cisco.com; header.From=fcao@cisco.com; dkim=pass ( 43 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 Cc: "Jesske, R" , fluffy@cisco.com, sip@ietf.org, pkyzivat@cisco.com, roland.jesske@web.de, christer.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1254324197-1149626040=:20986 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Please see comments inline: On Tue, 6 Jun 2006, Elwell, John wrote: > The requirements have indeed been described in the tispan-requirements > draft, but clearly there is still some misunderstanding. Let me try to sh= ed > some light, although my background is enterprise rather than carrier and = I > don't pretend to understand all practices of PSTN or NGN. > > A PSTN carries two identities in each direction - one that has been > "authenticated" or "screened" by the PSTN and one that has been received > from outside the PSTN and has not been screened. The first type of identi= ty > is used for billing, authorisation etc. within the PSTN, and may also be > delivered to the customer premises equipment. The second type of identity= is > used only for delivery to the customer premises equipment. What the custo= mer > premises equipment does with the two types of identities is not really > specified, but I think enterprise networks (e.g., based on QSIG) would > normally use only the first type of identity for passing through the > enterprise network to the end user. > > I believe TISPAN has ambitions to support these two types of identity in > NGN, so this leads to the question how to carry the two identities in SIP= =2E > > For the INVITE request, the first caller identity is carried in the > P-Asserted-Identity header, the first node in the NGN having authenticate= d > the source of the request by some means (e.g., through the certificate > supplied during TLS handshake). The second caller identity is carried in = the > From header. Obviously the latter is open to falsification unless support= ed > by an Identity header. With the Identity header, the second caller identi= ty > would be far more useful to the destination customer premises equipment. > > For the reverse direction, the first callee identity is carried in the > P-Asserted-Identity header, I believe. There are fewer authentication > options, but I guess TLS-based authentication is still a possibility. So = the > question is how to supply the second callee identity. > > Option 1. Modify the To header in the INVITE response. There have been > objections to this. Also it would not be authenticated, so it would not b= e > nearly as useful as the second identity in the request, which can be > authenticated by the Identity header. > Agreed. > Option 2. Use the Reply-To header or some new header in the INVITE respon= se. > The objections concerning modifying the To header go away, but again it > would not be authenticated, so it would not be nearly as useful as the > second identity in the request. It'd better to divide this option into two. One is to use Reply-To, the other is to use one new header. For "Reply-To", you had pointed out the drawbacks. To use one new header, it is straightforward to add authentication as well as the identity into this new header. Please see our draft http://www.ietf.org/internet-drafts/draft-cao-sip-response-identity-00.txt the new header can also indicate if the authentication is needed and which authentication method is used. It is worth noting that either of these two approaches is more generic, because the response directly carries the identity. > > Option 3. Use the From header in conjunction with the Identity header in = a > request in the reverse direction, as specified in the Connected-Identity > draft. This seems to solve the problem, except that it may make interwork= ing > with PSTN signalling more difficult since PSTN expects the second identit= y > in the "answer" message. If a solution to this signalling interworking ca= n > be found, I think option 3 would clearly be the best solution. > It is worth noting that connected-id can only happen in the mid-call scenarios, which is just a subset compared with the solution in the above option. --Feng > John > >> -----Original Message----- >> From: Jesske, R [mailto:R.Jesske@t-com.net] >> Sent: 01 June 2006 09:42 >> To: fluffy@cisco.com >> Cc: sip@ietf.org; pkyzivat@cisco.com; Elwell, John; >> roland.jesske@web.de; christer.holmberg@ericsson.com >> Subject: AW: AW: AW: [Sip] Connected-identity and changing >> the To header f ield ina response >> >> The two identities are used for PBX services. >> Example >> If a user calls a special hotline for e.G. Computer Services. >> +496151830. >> This is the main number of a PBX with several extensions. The >> user will be at least connected to an Service Expert >> (Extension No: +496151831111). >> So now there is a Public Id (+496151830) that is trusted and >> the all billing is bind to. (TISPAN uses the P-Asserted-Identity) >> and a private not secure id of the Expert. Advantage is that >> the Caller has now the ability to see the real connected >> number where the expert can now called directly. >> >> This service is widely used within the PSTN/ISDN world and is >> known as COLP (Connected Line Identification Presentation) >> Specifies in ITU-T Q.731.5 and in ETSI ETSI EN 300 094 (free >> downloadable at portal.etsi.org). >> >> We have described the Requirements in >> draft-jesske-sipping-tispan-requirements-01 and did some >> analysis in the past in draft-jesske-sipping-tispan-analysis-00.txt >> >> Best Regards >> >> Roland >> >> >>> -----Urspr=FCngliche Nachricht----- >>> Von: Cullen Jennings [mailto:fluffy@cisco.com] >>> Gesendet: Donnerstag, 1. Juni 2006 09:11 >>> An: Jesske, Roland >>> Cc: pkyzivat@cisco.com; sip@ietf.org; >>> john.elwell@siemens.com; roland.jesske@web.de; >>> christer.holmberg@ericsson.com >>> Betreff: Re: AW: AW: [Sip] Connected-identity and changing >>> the To header field ina response >>> >>> >>> >>> What things use these two identities, what do they get used >> for, and >>> what security assumptions come around them. That type of >> information >>> would help people on this list understand the problem. >>> >>> On May 31, 2006, at 10:28 PM, Jesske, R wrote: >>> >>>> Paul, >>>> in the past we lookes also on the Reply-to header. But per >>>> definition it is the address where the user want to be >> connected. >>>> So it is not in each case the real conected identity. But >> the COLP >>>> (TIP) service could be used in the same way. >>>> So if it would be possible to use Reply-to header in >> Responses, if >>>> people are willing and we as TISPAN can narrow it then >> only to the >>>> real connected identity (within our walled garden service >>>> definition) I would be happy. >>>> >>>> Best Regards >>>> >>>> Roland >>>> >>>>> -----Urspr=FCngliche Nachricht----- >>>>> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>> Gesendet: Mittwoch, 31. Mai 2006 17:04 >>>>> An: Jesske, Roland >>>>> Cc: fluffy@cisco.com; sip@ietf.org; john.elwell@siemens.com; >>>>> roland.jesske@web.de; christer.holmberg@ericsson.com >>>>> Betreff: Re: AW: [Sip] Connected-identity and changing the To >>>>> header field ina response >>>>> >>>>> >>>>> >>>>> >>>>> Jesske, R wrote: >>>>>> These are the requirements we already expressed in our >>>>> draft draft-jesske-sipping-tispan-requirements-02: >>>>>> >>>>>> REQ-TIP-1: In addition to any network asserted identity, >>>>> it must be >>>>>> possible for the callee to indicate in a SIP >>>>> response an >>>>>> additional identity where the user is >>>>> reachable for future >>>>>> direct communications. Note that the >>>>> requirement refers >>>>>> to the user, not to the same instance of the >>>>> User Agent. >>>>>> REQ-TIP-2: The identity mentioned in REQ-TIP-1 must be >>>>> formatted as a >>>>>> SIP URI [2] or TEL URL [3]. A translation >>>>> between SIP URI >>>>>> and TEL URL by the network is not requested. >>>>>> REQ-TIP-3: The identity mentioned in REQ-TIP-1 is >>>>> considered an end >>>>>> user supplied information that is not >>> asserted by the >>>>>> network. >>>>>> >>>>>> >>>>>> As you can see we do not need any authenticated identity in >>>>> the response. For the authenticated identity we are using the >>>>> P-Asserted-Identity. So we have two identities in a Response. >>>>>> For our purposes the user provided identity in a final 200 >>>>> OK response is sufficient. So that avoids confusion within >>>>> forking cases. >>>>> >>>>> I haven't been paying close attention to this. What >> header are you >>>>> planning to use to carry this callee provided identity? >>>>> >>>>> The Reply-To header would seem to be appropriate for this >>>>> purpose, but >>>>> unfortunately, according to table 2 of 3261, it is only >>>>> allowed in INVITE. >>>>> >>>>> =09Paul >>>>> >>>>>> Roland >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Urspr=FCngliche Nachricht----- >>>>>>> Von: Cullen Jennings [mailto:fluffy@cisco.com] >>>>>>> Gesendet: Montag, 22. Mai 2006 17:32 >>>>>>> An: Jesske, Roland >>>>>>> Cc: John Elwell; sip@ietf.org; Roland Jesske; Christer >>>>>>> Holmberg (JO/LMF) >>>>>>> Betreff: Re: [Sip] Connected-identity and changing the To >>>>>>> header field ina response >>>>>>> >>>>>>> >>>>>>> >>>>>>> On May 16, 2006, at 7:07 AM, Jesske, R wrote: >>>>>>> >>>>>>>> John, >>>>>>>> it is that we don't can get an connected identity within >>>>> the final >>>>>>>> response of the initial INVITE. >>>>>>>> Your draft proposes a mid dialog request for getting this >>>>>>> information. >>>>>>>> That is not usable for the TIP service. >>>>>>> I think this is part of what I am not understanding. >> What is the >>>>>>> requirement here? >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>> This list is for NEW development of the core SIP Protocol >>>>>> Use sip-implementors@cs.columbia.edu for questions on >> current sip >>>>>> Use sipping@ietf.org for new developments on the >>> application of sip >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP Protocol >>>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>>> Use sipping@ietf.org for new developments on the >> application of sip >>>>> >>> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ---559023410-1254324197-1149626040=:20986 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ---559023410-1254324197-1149626040=:20986-- From sip-bounces@ietf.org Tue Jun 06 17:07:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnikY-00072s-Ck; Tue, 06 Jun 2006 17:06:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnikW-000714-J0 for sip@ietf.org; Tue, 06 Jun 2006 17:06:04 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnikV-0008GR-Ab for sip@ietf.org; Tue, 06 Jun 2006 17:06:04 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0J0G00301IMRMK@siemenscomms.co.uk> for sip@ietf.org; Tue, 06 Jun 2006 22:06:27 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J0G0030HIMRG8@siemenscomms.co.uk>; Tue, 06 Jun 2006 22:06:27 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 06 Jun 2006 22:06:01 +0100 Content-return: allowed Date: Tue, 06 Jun 2006 22:06:00 +0100 From: "Elwell, John" Subject: RE: AW: AW: [Sip] Connected-identity and changing the To header f ield ina response To: Feng Cao Message-id: <50B1CBA96870A34799A506B2313F26670918241E@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: "Jesske, R" , fluffy@cisco.com, sip@ietf.org, pkyzivat@cisco.com, roland.jesske@web.de, christer.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Feng, You wrote: > It is worth noting that connected-id can only happen in the mid-call > scenarios, which is just a subset compared with the solution in the > above option. Mid call can be immediately after the 2xx response to the INVITE, so I don't see your point. John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 06 17:34:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnj9i-0002mK-Ru; Tue, 06 Jun 2006 17:32:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnj9g-0002jP-S6 for sip@ietf.org; Tue, 06 Jun 2006 17:32:04 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnj9e-0003s6-Io for sip@ietf.org; Tue, 06 Jun 2006 17:32:04 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.6/IER-o) with ESMTP id k56LVv61024122; Tue, 6 Jun 2006 16:31:58 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k56LVrn22053; Tue, 6 Jun 2006 16:31:57 -0500 (CDT) Message-ID: <4485F449.4030704@lucent.com> Date: Tue, 06 Jun 2006 16:31:53 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] What to do with SIP SAML draft References: <2B137721-9B8A-4EB1-94A8-6039C06D8F09@softarmor.com> In-Reply-To: <2B137721-9B8A-4EB1-94A8-6039C06D8F09@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Sip IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (1) or (3); in either of the cases, we will have to come up with a new milestone date. I have already posted some feedback on it a couple (three?) weeks ago. Thanks, - vijay Dean Willis wrote: > > Our current charter and slightly-stale milestones include a > deliverable for SAML: > > Jul 2006 -- Using SAML for SIP (PS) > > At the IETF 65, we discussed the Tschofenig draft, currently > available as: > > http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-05.txt > > We didn't have a firm consensus in the room for what to do with this, > so It'd like to discuss it now. > > Our options include: > > 1) Adopt this draft as a WG document and keep working on it. > > 2) Decide we don't need to solve the problem just yet and abandon the > milestone. > > 3) Let Hannes and team keep working on it until we decide it has > reached critical mass, and keep slipping the milestone along. > > 4) Do something entirely different. -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 06 18:07:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnjfz-0005HO-Uj; Tue, 06 Jun 2006 18:05:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnjfy-0005HA-C1 for sip@ietf.org; Tue, 06 Jun 2006 18:05:26 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnjfx-0000B4-1f for sip@ietf.org; Tue, 06 Jun 2006 18:05:26 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 06 Jun 2006 15:00:15 -0700 X-IronPort-AV: i="4.05,215,1146466800"; d="scan'208"; a="290033133:sNHT4810337180" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k56M0FrV020807; Tue, 6 Jun 2006 15:00:15 -0700 Received: from billybong.cisco.com (billybong.cisco.com [171.71.163.234]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k56M0FcM022093; Tue, 6 Jun 2006 15:00:15 -0700 (PDT) Date: Tue, 6 Jun 2006 15:00:15 -0700 (PDT) From: Feng Cao To: "Elwell, John" Subject: RE: AW: AW: [Sip] Connected-identity and changing the To header f ield ina response In-Reply-To: <50B1CBA96870A34799A506B2313F26670918241E@ntht201e.siemenscomms.co.uk> Message-ID: References: <50B1CBA96870A34799A506B2313F26670918241E@ntht201e.siemenscomms.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=651; t=1149631215; x=1150495215; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fcao@cisco.com; z=From:Feng=20Cao=20 |Subject:RE=3A=20AW=3A=20AW=3A=20[Sip]=20Connected-identity=20and=20changing=20th e=20To=20header=20f=0A=20ield=20ina=20response; X=v=3Dcisco.com=3B=20h=3Dwc5CgBrVHsWn+gbLHwIMUEUkRL0=3D; b=xiGNNu25+dbFbCgMh21fuaYgummqGQMWY4wUjEnfeqvlWY3ahrPzfxEDCQd9TF9rVztsOKBH GLkZ1LJHjP0p7sXCE25j9Y0Q+MJr3IoPSsOP8s6VNQIO6RtY6UQ8eO2D; Authentication-Results: sj-dkim-5.cisco.com; header.From=fcao@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: "Jesske, R" , fluffy@cisco.com, sip@ietf.org, pkyzivat@cisco.com, roland.jesske@web.de, christer.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org John, Assume the response be able to directly carry the identity through a new header in the above option, it leaves room for providing identity beyond response code 2xx, when it is needed. For example, the response with 301 might need to provide additional identity for security reasons. --Feng On Tue, 6 Jun 2006, Elwell, John wrote: > Feng, > > You wrote: >> It is worth noting that connected-id can only happen in the mid-call >> scenarios, which is just a subset compared with the solution in the >> above option. > Mid call can be immediately after the 2xx response to the INVITE, so I don't > see your point. > > John > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 07 01:34:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnqeD-0003uP-Me; Wed, 07 Jun 2006 01:32:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnqeB-0003uK-QB for sip@ietf.org; Wed, 07 Jun 2006 01:32:03 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnqeA-0002OG-HB for sip@ietf.org; Wed, 07 Jun 2006 01:32:03 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 06 Jun 2006 22:32:01 -0700 X-IronPort-AV: i="4.05,215,1146466800"; d="scan'208"; a="290264524:sNHT31619544" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k575W1wi007929; Tue, 6 Jun 2006 22:32:01 -0700 Received: from [192.168.1.109] (sjc-vpn-hwcore-955.cisco.com [10.21.155.187]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k575VicM004346; Tue, 6 Jun 2006 22:31:57 -0700 (PDT) In-Reply-To: <475FF955A05DD411980D00508B6D5FB0130F6998@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB0130F6998@en0033exch001u.uk.lucent.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Connected-identity and changing the To header field ina response Date: Tue, 6 Jun 2006 22:31:56 -0700 To: "Drage, Keith (Keith)" X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=735; t=1149658322; x=1150522322; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Connected-identity=20and=20changing=20the=20To=20header= 20field=20ina=20response; X=v=3Dcisco.com=3B=20h=3Df84KHgZGNz0QggvC4EBI34LfHus=3D; b=WnD3fgPQXJmV2+w5a6AZ2h0wodwmMcpIvjPufgZOESoEJdRpfyezeyb40BYmnGPLVzCjvtQM z7Nc4kiuq2VMZz5dCy1ZZwaSxFfUOd42SRmBz62TCsjaXG+BmUkRgsvU; Authentication-Results: sj-dkim-8.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: "'Jesske, R'" , "'sip@ietf.org'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 1, 2006, at 3:06 AM, Drage, Keith (Keith) wrote: > And to answer Cullen's request later in the thread, the seond > identifier is needed because in certain enterprise network > scenarios, it stands more chance of being a real dial-back number > than the P-Asserted-Identity. Ok, I am a little lost on the benefit of the network asserting that the correct id is one that is clearly wrong. And I still don't feel like I understand the problem well enough to tell why the contact or the Reply-To could not be used. I'm perfectly willing to believe there is a good reason they can't but I don't feel that we have enough information about the requirements to figure out how this might map to SIP. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 07 06:41:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnvRY-0006y2-SX; Wed, 07 Jun 2006 06:39:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnvRX-0006xv-E1 for sip@ietf.org; Wed, 07 Jun 2006 06:39:19 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnvRX-0005FQ-3t for sip@ietf.org; Wed, 07 Jun 2006 06:39:19 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k57AdBcq017475; Wed, 7 Jun 2006 05:39:14 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 7 Jun 2006 11:39:11 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0130F705F@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt Date: Wed, 7 Jun 2006 11:39:08 +0100 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: 9a2be21919e71dc6faef12b370c4ecf5 Cc: ahawrylyshen@ditechnetworks.com, RjS@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: , Errors-To: sip-bounces@ietf.org I worked through this document and identified the following points for consideration. Technical --------- 1) Section 2.2, final indented paragraph. Firstly, can we emphasise that this applies to any method, e.g. by inserting the words: "Any 483 response, to any method, SHOULD..." Secondly, if we are going to use SHOULD here, can we insert some informative text relating to why it is only a SHOULD and not a MUST, and therefore giving the reader the understanding of why it does not always apply. 2) Section 2.2 and elsewhere, I am not convinced that the use of the Warning header is consistent with RFC 3261. The clear implication of RFC 3261 is that Warning headers relate only to the session description contained in the request. 3) Section 2.4. The 3rd (final) paragraph clearly indicates this as a normative requirement, with SHOULD strength. The second paragraph contains a similar requirement, but no keyword. Either rephrase to include a "SHOULD", or change the "It is suggested..." to It is RECOMMENDED...". NITS ---- a) Wherever we indicate "483 error response" in the text, can we follow the style of RFC 3261 and change it to "483 (Too Many Hops) response code"? b) Instead of "sender" and "receiver" (relating to a request) can we use RFC 3261 terminology "UAC" and "UAS". Occurences at least in the abstract (where they will need expansion) and in the introduction"? c) In the Abstract delete the paragraph relating to "Comments are solicited..." It's an I-D after all. d) In the examples, I note they all use "pingtel.com". Should these be changed to a more usual example URI. regards e) In section 2.2, Can we make the two sets of bullets more apparent? f) In section 2.2, 1st bullet of 1st bullet list, the reference to RFC 3261 needs to have the reference identifier. g) When referring to the "Max Forwards value" use "Max Forwards header field value", i.e. consistent with RFC 3261 usage. regards Keith > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: 02 June 2006 20:50 > To: i-d-announce@ietf.org > Cc: sip@ietf.org > Subject: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.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 : Diagnostic Responses for SIP Hop Limit Errors > Author(s) : S. Lawrence, et al. > Filename : draft-ietf-sip-hop-limit-diagnostics-02.txt > Pages : 12 > Date : 2006-6-2 > > The SIP protocol imposes a limit on the number of hops a request may > make from a sender to the recipient. When this limit is reached, a > 483 error response is returned. The present form of the 483 response > does not provide enough information for the sender or proxies on the > path to diagnose failures whose symptom is that the hop limit is > reached. This document proposes additional diagnostic information to > be returned in a 483 response. > > Comments are solicited, and should be directed to the SIP working > group list at 'sip@ietf.org'. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-hop-limit-d > iagnostics-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in > the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-hop-limit-diagnostics-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-hop-limit-diagnostics-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 07 09:11:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnxn7-000620-19; Wed, 07 Jun 2006 09:09:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnxn5-00061u-KU for sip@ietf.org; Wed, 07 Jun 2006 09:09:43 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnxn1-0007qM-CH for sip@ietf.org; Wed, 07 Jun 2006 09:09:43 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k57D9aC0003440; Wed, 7 Jun 2006 08:09:37 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 7 Jun 2006 14:09:36 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0130F70C3@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Cullen Jennings Subject: RE: [Sip] Connected-identity and changing the To header field ina response Date: Wed, 7 Jun 2006 14:09:33 +0100 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: b19722fc8d3865b147c75ae2495625f2 Cc: "'Jesske, R'" , "'sip@ietf.org'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Neither identity is clearly wrong. This issue is that the assertion of each identity may be right for some purposes, but not the best for others. The public network asserted identity works fine for charging purposes, and allocation of public network services in accordance with the subscriber's wishes, but is useless as a dial back number. For the enterprise network asserted identity, the opposite applies. In regard to the appropriate solutions, I leave that to others. regards Keith > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: 07 June 2006 06:32 > To: Drage, Keith (Keith) > Cc: 'Jesske, R'; 'sip@ietf.org' > Subject: Re: [Sip] Connected-identity and changing the To header field > ina response > > > > On Jun 1, 2006, at 3:06 AM, Drage, Keith (Keith) wrote: > > > And to answer Cullen's request later in the thread, the seond > > identifier is needed because in certain enterprise network > > scenarios, it stands more chance of being a real dial-back number > > than the P-Asserted-Identity. > > Ok, I am a little lost on the benefit of the network asserting that > the correct id is one that is clearly wrong. And I still don't feel > like I understand the problem well enough to tell why the contact or > the Reply-To could not be used. I'm perfectly willing to believe > there is a good reason they can't but I don't feel that we have > enough information about the requirements to figure out how this > might map to SIP. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 07 09:36:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnyBR-0001hd-A3; Wed, 07 Jun 2006 09:34:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnyBP-0001hU-VU for sip@ietf.org; Wed, 07 Jun 2006 09:34:51 -0400 Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnyBO-00027L-Mo for sip@ietf.org; Wed, 07 Jun 2006 09:34:51 -0400 Received: (qmail 11860 invoked by uid 510); 7 Jun 2006 09:17:45 -0400 Received: from henry@pulver.com by mail.pulver.com by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.72. spamassassin: 2.63. Clear:RC:1(24.1.140.191):. Processed in 0.993481 secs); 07 Jun 2006 13:17:45 -0000 X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(24.1.140.191):. Processed in 0.993481 secs Process 11855) Received: from c-24-1-140-191.hsd1.tx.comcast.net (HELO DSX400) (henry@pulver.com@24.1.140.191) by 192.246.69.184 with SMTP; Wed, 07 Jun 2006 13:17:44 +0000 From: "Henry Sinnreich" To: "'Drage, Keith \(Keith\)'" , "'Cullen Jennings'" Subject: RE: [Sip] Connected-identity and changing the To header field inaresponse Date: Wed, 7 Jun 2006 08:34:48 -0500 Organization: pulver.com Message-ID: <000801c68a37$25f93040$2800a8c0@DSX400> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaKMVy0heO9N38PTs62PAEN1/w6zQAA207Q In-Reply-To: <475FF955A05DD411980D00508B6D5FB0130F70C3@en0033exch001u.uk.lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: "'Jesske, R'" , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: henry@pulver.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is an excellent definition of the various types and application areas for identity. Maybe Keith has time for a short I-D :-) Thanks, Henry -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com] Sent: Wednesday, June 07, 2006 8:10 AM To: Cullen Jennings Cc: 'Jesske, R'; 'sip@ietf.org' Subject: RE: [Sip] Connected-identity and changing the To header field inaresponse Neither identity is clearly wrong. This issue is that the assertion of each identity may be right for some purposes, but not the best for others. The public network asserted identity works fine for charging purposes, and allocation of public network services in accordance with the subscriber's wishes, but is useless as a dial back number. For the enterprise network asserted identity, the opposite applies. In regard to the appropriate solutions, I leave that to others. regards Keith > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: 07 June 2006 06:32 > To: Drage, Keith (Keith) > Cc: 'Jesske, R'; 'sip@ietf.org' > Subject: Re: [Sip] Connected-identity and changing the To header field > ina response > > > > On Jun 1, 2006, at 3:06 AM, Drage, Keith (Keith) wrote: > > > And to answer Cullen's request later in the thread, the seond > > identifier is needed because in certain enterprise network > > scenarios, it stands more chance of being a real dial-back number > > than the P-Asserted-Identity. > > Ok, I am a little lost on the benefit of the network asserting that > the correct id is one that is clearly wrong. And I still don't feel > like I understand the problem well enough to tell why the contact or > the Reply-To could not be used. I'm perfectly willing to believe > there is a good reason they can't but I don't feel that we have > enough information about the requirements to figure out how this > might map to SIP. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 07 10:24:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnyw5-0003CU-N0; Wed, 07 Jun 2006 10:23:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnyw4-0003CP-CB for sip@ietf.org; Wed, 07 Jun 2006 10:23:04 -0400 Received: from [217.205.209.100] (helo=vegastream.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnyw1-0007sQ-Vp for sip@ietf.org; Wed, 07 Jun 2006 10:23:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] privacy header format - RFC 3323 Date: Wed, 7 Jun 2006 15:23:00 +0100 Message-ID: <8F1F2062CA7D754A838F0E66097D23A0C23C98@veg-brk-svr-pri.vegastream> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] privacy header format - RFC 3323 thread-index: AcaJl9oSq8OD5SxxSMqfJ7FRjYfhIgApb1oA From: "Attila Sipos" To: "venugopal iyer" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Venu, Your mentioned mail is referring to the draft version (draft-ietf-sip-privacy-general) of something that became RFC3323. Since it is only a draft and RFC3323 is newer and it's an approved RFC, then you should ditch the draft and use the RFC (which uses ";"). Regards, Attila Attila Sipos http://www.vegastream.com >> -----Original Message----- >> From: venugopal iyer [mailto:venu@sun.com] >> Sent: 24 May 2006 20:50 >> To: sip@ietf.org >> Subject: [Sip] privacy header format - RFC 3323 >>=20 >>=20 >>=20 >>=20 >> Am looking for some clarification about the definition of=20 >> Privacy-hdr >> (from RFC 3323): >>=20 >> Privacy-hdr =3D "Privacy" HCOLON priv-value *(";" priv-value) >> priv-value =3D "header" / "session" / "user" / "none"=20 >> / "critical" >> / token >>=20 >> I am not clear about ";" above given the header defns in RFC=20 >> 3261. I would >> have thought it should be a COMMA. I maybe missing something. >>=20 >> I did come across a mail that specifically talks about this: >> (http://www.atm.tut.fi/list-archive/sip/msg05124.html) >>=20 >> " >> > Privacy-hdr =3D "Privacy" HCOLON priv-value *(COMMA priv-value) >> > priv-value =3D "header" | "session" | "user" | "none"=20 >> | "critical" | token >>=20 >> I would strongly advise that you also allow for semi-colon separated >> parameters for the purposes of future extensibility. >>=20 >> Also, you need to use slashes "/" to separate or-values, not vertical >> bars "|". >> " >>=20 >> but am not sure the comment actually resulted in the change=20 >> from COMMA to >> SEMI. >>=20 >> thanks, >>=20 >> -venu >>=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 Jun 07 11:04:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnzY1-00071j-KA; Wed, 07 Jun 2006 11:02:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnzY0-0006wE-2F for sip@ietf.org; Wed, 07 Jun 2006 11:02:16 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnzXx-00062e-Mv for sip@ietf.org; Wed, 07 Jun 2006 11:02:16 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 07 Jun 2006 08:02:13 -0700 X-IronPort-AV: i="4.05,217,1146466800"; d="scan'208"; a="1821181962:sNHT42042956" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k57F2Dcd026791; Wed, 7 Jun 2006 08:02:13 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k57F2D9s008122; Wed, 7 Jun 2006 08:02:13 -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 ESMTP id k57EwPU3014776; Wed, 7 Jun 2006 07:58:25 -0700 In-Reply-To: <50B1CBA96870A34799A506B2313F26670918240F@ntht201e.siemenscomms.co.uk> References: <50B1CBA96870A34799A506B2313F26670918240F@ntht201e.siemenscomms.co.uk> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: AW: AW: [Sip] Connected-identity and changing the To header f ield ina response Date: Wed, 7 Jun 2006 11:02:07 -0400 To: "Elwell, John" X-Mailer: Apple Mail (2.750) Authentication-Results: sj-dkim-4.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=3290; t=1149692533; x=1150556533; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20AW=3A=20AW=3A=20[Sip]=20Connected-identity=20and=20changing=20th e=20To=20header=20f=09ield=20ina=09response; X=v=3Dcisco.com=3B=20h=3DoW3T1cGWCyTOr8KudNAJu9Pcp5U=3D; b=uubivC9XHVkTGnojBvVljeYUgUEYuTAzOkF5LdQdSdkmiQa06bWfRqvVlkJ8JR0RBEJZczPz EzrlOOLjskMLVTfubd3VjzcFL0GmQJ+4zeBPchz4fnQvkgZLzEW5OenR; X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: "Jesske, R" , fluffy@cisco.com, sip@ietf.org, pkyzivat@cisco.com, roland.jesske@web.de, christer.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 6, 2006, at 3:17 PM, Elwell, John wrote: > The requirements have indeed been described in the tispan-requirements > draft, but clearly there is still some misunderstanding. Let me try > to shed > some light, although my background is enterprise rather than > carrier and I > don't pretend to understand all practices of PSTN or NGN. > > A PSTN carries two identities in each direction - one that has been > "authenticated" or "screened" by the PSTN and one that has been > received > from outside the PSTN and has not been screened. The first type of > identity > is used for billing, authorisation etc. within the PSTN, and may > also be > delivered to the customer premises equipment. The second type of > identity is > used only for delivery to the customer premises equipment. What the > customer > premises equipment does with the two types of identities is not really > specified, but I think enterprise networks (e.g., based on QSIG) would > normally use only the first type of identity for passing through the > enterprise network to the end user. > > I believe TISPAN has ambitions to support these two types of > identity in > NGN, so this leads to the question how to carry the two identities > in SIP. > > For the INVITE request, the first caller identity is carried in the > P-Asserted-Identity header, the first node in the NGN having > authenticated > the source of the request by some means (e.g., through the certificate > supplied during TLS handshake). The second caller identity is > carried in the > From header. Obviously the latter is open to falsification unless > supported > by an Identity header. With the Identity header, the second caller > identity > would be far more useful to the destination customer premises > equipment. > > For the reverse direction, the first callee identity is carried in the > P-Asserted-Identity header, I believe. There are fewer authentication > options, but I guess TLS-based authentication is still a > possibility. So the > question is how to supply the second callee identity. > > Option 1. Modify the To header in the INVITE response. There have been > objections to this. Also it would not be authenticated, so it would > not be > nearly as useful as the second identity in the request, which can be > authenticated by the Identity header. > > Option 2. Use the Reply-To header or some new header in the INVITE > response. > The objections concerning modifying the To header go away, but > again it > would not be authenticated, so it would not be nearly as useful as the > second identity in the request. > > Option 3. Use the From header in conjunction with the Identity > header in a > request in the reverse direction, as specified in the Connected- > Identity > draft. This seems to solve the problem, except that it may make > interworking > with PSTN signalling more difficult since PSTN expects the second > identity > in the "answer" message. If a solution to this signalling > interworking can > be found, I think option 3 would clearly be the best solution. > Option 4: Use a Body, since this is strictly end-to-end and various forms of connected identity may be useful. > John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 07 11:43:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo09f-00038R-Hl; Wed, 07 Jun 2006 11:41:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo09d-00038M-SP for sip@ietf.org; Wed, 07 Jun 2006 11:41:09 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo09c-0008UU-ES for sip@ietf.org; Wed, 07 Jun 2006 11:41:09 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 07 Jun 2006 08:41:08 -0700 X-IronPort-AV: i="4.05,217,1146466800"; d="scan'208"; a="1821221009:sNHT37663732" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k57Ff6mO006431; Wed, 7 Jun 2006 08:41:07 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k57Ff6ku009046; Wed, 7 Jun 2006 11:41:06 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Jun 2006 11:41:06 -0400 Received: from [161.44.79.149] ([161.44.79.149]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Jun 2006 11:41:05 -0400 Message-ID: <4486F391.9090409@cisco.com> Date: Wed, 07 Jun 2006 11:41:05 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: David R Oran Subject: Re: AW: AW: [Sip] Connected-identity and changing the To header f ield ina response References: <50B1CBA96870A34799A506B2313F26670918240F@ntht201e.siemenscomms.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2006 15:41:05.0737 (UTC) FILETIME=[C9F7B390:01C68A48] DKIM-Signature: a=rsa-sha1; q=dns; l=4100; t=1149694867; x=1150558867; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20AW=3A=20AW=3A=20[Sip]=20Connected-identity=20and=20changing=20th e=20To=20header=20f=0A=20ield=20ina=09response; X=v=3Dcisco.com=3B=20h=3DAru7e00TZGWSwjYz86Qev9e3OrE=3D; b=iAw3HvWLBzGxSmS7auKGSPaYs5J4oF5IAcBpcd6cZDKxJXgTN11p2RlVARvg+6iIbG9mwjoS gycmSvwAc2AKC66DLBG+UsyXBdRJMeBUlNv/9FTfNmaEfXaemDwx0Iu0; Authentication-Results: sj-dkim-1.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: "Jesske, R" , fluffy@cisco.com, sip@ietf.org, "Elwell, John" , roland.jesske@web.de, christer.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org What I am starting to discern here is a desire for multiple identities in the same message that are asserted by different authorities. P-Asserted-Identity clearly can't do that. I guess there potentially could be multiple instances of sip identity, though the logistics of getting that asserted could be difficult. It has been suggested here that P-Asserted-ID and sip identity could be used together to provide two identities. In any case, the value proposition is different if the multiple identities are all authenticated to the satisfaction of the recipient, rather than one of them being untrustworthy. So, am I right in thinking the goal is for multiple identities, authenticated by different parties? Thanks, Paul David R Oran wrote: > > On Jun 6, 2006, at 3:17 PM, Elwell, John wrote: > >> The requirements have indeed been described in the tispan-requirements >> draft, but clearly there is still some misunderstanding. Let me try to >> shed >> some light, although my background is enterprise rather than carrier >> and I >> don't pretend to understand all practices of PSTN or NGN. >> >> A PSTN carries two identities in each direction - one that has been >> "authenticated" or "screened" by the PSTN and one that has been received >> from outside the PSTN and has not been screened. The first type of >> identity >> is used for billing, authorisation etc. within the PSTN, and may also be >> delivered to the customer premises equipment. The second type of >> identity is >> used only for delivery to the customer premises equipment. What the >> customer >> premises equipment does with the two types of identities is not really >> specified, but I think enterprise networks (e.g., based on QSIG) would >> normally use only the first type of identity for passing through the >> enterprise network to the end user. >> >> I believe TISPAN has ambitions to support these two types of identity in >> NGN, so this leads to the question how to carry the two identities in >> SIP. >> >> For the INVITE request, the first caller identity is carried in the >> P-Asserted-Identity header, the first node in the NGN having >> authenticated >> the source of the request by some means (e.g., through the certificate >> supplied during TLS handshake). The second caller identity is carried >> in the >> From header. Obviously the latter is open to falsification unless >> supported >> by an Identity header. With the Identity header, the second caller >> identity >> would be far more useful to the destination customer premises equipment. >> >> For the reverse direction, the first callee identity is carried in the >> P-Asserted-Identity header, I believe. There are fewer authentication >> options, but I guess TLS-based authentication is still a possibility. >> So the >> question is how to supply the second callee identity. >> >> Option 1. Modify the To header in the INVITE response. There have been >> objections to this. Also it would not be authenticated, so it would >> not be >> nearly as useful as the second identity in the request, which can be >> authenticated by the Identity header. >> >> Option 2. Use the Reply-To header or some new header in the INVITE >> response. >> The objections concerning modifying the To header go away, but again it >> would not be authenticated, so it would not be nearly as useful as the >> second identity in the request. >> >> Option 3. Use the From header in conjunction with the Identity header >> in a >> request in the reverse direction, as specified in the Connected-Identity >> draft. This seems to solve the problem, except that it may make >> interworking >> with PSTN signalling more difficult since PSTN expects the second >> identity >> in the "answer" message. If a solution to this signalling interworking >> can >> be found, I think option 3 would clearly be the best solution. >> > Option 4: Use a Body, since this is strictly end-to-end and various > forms of connected identity may be useful. > >> John > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 07 12:15:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo0fS-0006r5-K5; Wed, 07 Jun 2006 12:14:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo0fQ-0006qp-J8 for sip@ietf.org; Wed, 07 Jun 2006 12:14:00 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo0fP-0004J1-WA for sip@ietf.org; Wed, 07 Jun 2006 12:14:00 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 07 Jun 2006 09:13:54 -0700 X-IronPort-AV: i="4.05,217,1146466800"; d="scan'208"; a="1821249917:sNHT9209058786" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k57GDrOI006088; Wed, 7 Jun 2006 09:13:53 -0700 Received: from [128.107.138.237] (dhcp-128-107-138-237.cisco.com [128.107.138.237]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k57GDckn017043; Wed, 7 Jun 2006 09:13:53 -0700 (PDT) In-Reply-To: <50B1CBA96870A34799A506B2313F26670918240F@ntht201e.siemenscomms.co.uk> References: <50B1CBA96870A34799A506B2313F26670918240F@ntht201e.siemenscomms.co.uk> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Cullen Jennings Subject: Re: AW: AW: [Sip] Connected-identity and changing the To header f ield ina response Date: Wed, 7 Jun 2006 06:59:45 -0700 To: "Elwell, John" X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=10451; t=1149696833; x=1150560833; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20AW=3A=20AW=3A=20[Sip]=20Connected-identity=20and=20changing=20th e=20To=20header=20f=09ield=20ina=09response; X=v=3Dcisco.com=3B=20h=3DfHBnZA0cyfQppYUWvW4U7VrA7Ko=3D; b=XfbJwsB4BUX5GeaVjZ8+NBOEks4xnRhh9Gdxi/BGALqyFH9mWyUBe6Moz8eNLp2zqYKTml1Z GDet1jD2aMNKOGxXDAzHz4aFc4yxnc889U7SlSVz21pWVVouYO9E9n8x; Authentication-Results: sj-dkim-2.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 Cc: "Jesske, R" , sip@ietf.org, pkyzivat@cisco.com, roland.jesske@web.de, christer.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org In the reverse direction, why not use UPDATE? On Jun 6, 2006, at 12:17 PM, Elwell, John wrote: > The requirements have indeed been described in the tispan-requirements > draft, but clearly there is still some misunderstanding. Let me try =20= > to shed > some light, although my background is enterprise rather than =20 > carrier and I > don't pretend to understand all practices of PSTN or NGN. > > A PSTN carries two identities in each direction - one that has been > "authenticated" or "screened" by the PSTN and one that has been =20 > received > from outside the PSTN and has not been screened. The first type of =20 > identity > is used for billing, authorisation etc. within the PSTN, and may =20 > also be > delivered to the customer premises equipment. The second type of =20 > identity is > used only for delivery to the customer premises equipment. What the =20= > customer > premises equipment does with the two types of identities is not really > specified, but I think enterprise networks (e.g., based on QSIG) would > normally use only the first type of identity for passing through the > enterprise network to the end user. > > I believe TISPAN has ambitions to support these two types of =20 > identity in > NGN, so this leads to the question how to carry the two identities =20 > in SIP. > > For the INVITE request, the first caller identity is carried in the > P-Asserted-Identity header, the first node in the NGN having =20 > authenticated > the source of the request by some means (e.g., through the certificate > supplied during TLS handshake). The second caller identity is =20 > carried in the > =46rom header. Obviously the latter is open to falsification unless =20= > supported > by an Identity header. With the Identity header, the second caller =20 > identity > would be far more useful to the destination customer premises =20 > equipment. > > For the reverse direction, the first callee identity is carried in the > P-Asserted-Identity header, I believe. There are fewer authentication > options, but I guess TLS-based authentication is still a =20 > possibility. So the > question is how to supply the second callee identity. > > Option 1. Modify the To header in the INVITE response. There have been > objections to this. Also it would not be authenticated, so it would =20= > not be > nearly as useful as the second identity in the request, which can be > authenticated by the Identity header. > > Option 2. Use the Reply-To header or some new header in the INVITE =20 > response. > The objections concerning modifying the To header go away, but =20 > again it > would not be authenticated, so it would not be nearly as useful as the > second identity in the request. > > Option 3. Use the =46rom header in conjunction with the Identity =20 > header in a > request in the reverse direction, as specified in the Connected-=20 > Identity > draft. This seems to solve the problem, except that it may make =20 > interworking > with PSTN signalling more difficult since PSTN expects the second =20 > identity > in the "answer" message. If a solution to this signalling =20 > interworking can > be found, I think option 3 would clearly be the best solution. > > John > >> -----Original Message----- >> From: Jesske, R [mailto:R.Jesske@t-com.net] >> Sent: 01 June 2006 09:42 >> To: fluffy@cisco.com >> Cc: sip@ietf.org; pkyzivat@cisco.com; Elwell, John; >> roland.jesske@web.de; christer.holmberg@ericsson.com >> Subject: AW: AW: AW: [Sip] Connected-identity and changing >> the To header f ield ina response >> >> The two identities are used for PBX services. >> Example >> If a user calls a special hotline for e.G. Computer Services. >> +496151830. >> This is the main number of a PBX with several extensions. The >> user will be at least connected to an Service Expert >> (Extension No: +496151831111). >> So now there is a Public Id (+496151830) that is trusted and >> the all billing is bind to. (TISPAN uses the P-Asserted-Identity) >> and a private not secure id of the Expert. Advantage is that >> the Caller has now the ability to see the real connected >> number where the expert can now called directly. >> >> This service is widely used within the PSTN/ISDN world and is >> known as COLP (Connected Line Identification Presentation) >> Specifies in ITU-T Q.731.5 and in ETSI ETSI EN 300 094 (free >> downloadable at portal.etsi.org). >> >> We have described the Requirements in >> draft-jesske-sipping-tispan-requirements-01 and did some >> analysis in the past in draft-jesske-sipping-tispan-analysis-00.txt >> >> Best Regards >> >> Roland >> >> >>> -----Urspr=FCngliche Nachricht----- >>> Von: Cullen Jennings [mailto:fluffy@cisco.com] >>> Gesendet: Donnerstag, 1. Juni 2006 09:11 >>> An: Jesske, Roland >>> Cc: pkyzivat@cisco.com; sip@ietf.org; >>> john.elwell@siemens.com; roland.jesske@web.de; >>> christer.holmberg@ericsson.com >>> Betreff: Re: AW: AW: [Sip] Connected-identity and changing >>> the To header field ina response >>> >>> >>> >>> What things use these two identities, what do they get used >> for, and >>> what security assumptions come around them. That type of >> information >>> would help people on this list understand the problem. >>> >>> On May 31, 2006, at 10:28 PM, Jesske, R wrote: >>> >>>> Paul, >>>> in the past we lookes also on the Reply-to header. But per >>>> definition it is the address where the user want to be >> connected. >>>> So it is not in each case the real conected identity. But >> the COLP >>>> (TIP) service could be used in the same way. >>>> So if it would be possible to use Reply-to header in >> Responses, if >>>> people are willing and we as TISPAN can narrow it then >> only to the >>>> real connected identity (within our walled garden service >>>> definition) I would be happy. >>>> >>>> Best Regards >>>> >>>> Roland >>>> >>>>> -----Urspr=FCngliche Nachricht----- >>>>> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>> Gesendet: Mittwoch, 31. Mai 2006 17:04 >>>>> An: Jesske, Roland >>>>> Cc: fluffy@cisco.com; sip@ietf.org; john.elwell@siemens.com; >>>>> roland.jesske@web.de; christer.holmberg@ericsson.com >>>>> Betreff: Re: AW: [Sip] Connected-identity and changing the To >>>>> header field ina response >>>>> >>>>> >>>>> >>>>> >>>>> Jesske, R wrote: >>>>>> These are the requirements we already expressed in our >>>>> draft draft-jesske-sipping-tispan-requirements-02: >>>>>> >>>>>> REQ-TIP-1: In addition to any network asserted identity, >>>>> it must be >>>>>> possible for the callee to indicate in a SIP >>>>> response an >>>>>> additional identity where the user is >>>>> reachable for future >>>>>> direct communications. Note that the >>>>> requirement refers >>>>>> to the user, not to the same instance of the >>>>> User Agent. >>>>>> REQ-TIP-2: The identity mentioned in REQ-TIP-1 must be >>>>> formatted as a >>>>>> SIP URI [2] or TEL URL [3]. A translation >>>>> between SIP URI >>>>>> and TEL URL by the network is not requested. >>>>>> REQ-TIP-3: The identity mentioned in REQ-TIP-1 is >>>>> considered an end >>>>>> user supplied information that is not >>> asserted by the >>>>>> network. >>>>>> >>>>>> >>>>>> As you can see we do not need any authenticated identity in >>>>> the response. For the authenticated identity we are using the >>>>> P-Asserted-Identity. So we have two identities in a Response. >>>>>> For our purposes the user provided identity in a final 200 >>>>> OK response is sufficient. So that avoids confusion within >>>>> forking cases. >>>>> >>>>> I haven't been paying close attention to this. What >> header are you >>>>> planning to use to carry this callee provided identity? >>>>> >>>>> The Reply-To header would seem to be appropriate for this >>>>> purpose, but >>>>> unfortunately, according to table 2 of 3261, it is only >>>>> allowed in INVITE. >>>>> >>>>> Paul >>>>> >>>>>> Roland >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Urspr=FCngliche Nachricht----- >>>>>>> Von: Cullen Jennings [mailto:fluffy@cisco.com] >>>>>>> Gesendet: Montag, 22. Mai 2006 17:32 >>>>>>> An: Jesske, Roland >>>>>>> Cc: John Elwell; sip@ietf.org; Roland Jesske; Christer >>>>>>> Holmberg (JO/LMF) >>>>>>> Betreff: Re: [Sip] Connected-identity and changing the To >>>>>>> header field ina response >>>>>>> >>>>>>> >>>>>>> >>>>>>> On May 16, 2006, at 7:07 AM, Jesske, R wrote: >>>>>>> >>>>>>>> John, >>>>>>>> it is that we don't can get an connected identity within >>>>> the final >>>>>>>> response of the initial INVITE. >>>>>>>> Your draft proposes a mid dialog request for getting this >>>>>>> information. >>>>>>>> That is not usable for the TIP service. >>>>>>> I think this is part of what I am not understanding. >> What is the >>>>>>> requirement here? >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>> This list is for NEW development of the core SIP Protocol >>>>>> Use sip-implementors@cs.columbia.edu for questions on >> current sip >>>>>> Use sipping@ietf.org for new developments on the >>> application of sip >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP Protocol >>>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>>> Use sipping@ietf.org for new developments on the >> application of sip >>>>> >>> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 07 12:15:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo0fT-0006rC-IY; Wed, 07 Jun 2006 12:14:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo0fQ-0006qu-Py for sip@ietf.org; Wed, 07 Jun 2006 12:14:00 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo0fQ-0004JW-Az for sip@ietf.org; Wed, 07 Jun 2006 12:14:00 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 07 Jun 2006 09:14:01 -0700 X-IronPort-AV: i="4.05,217,1146466800"; d="scan'208"; a="430077001:sNHT33990412" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k57GDxXL027541; Wed, 7 Jun 2006 09:13:59 -0700 Received: from [128.107.138.237] (dhcp-128-107-138-237.cisco.com [128.107.138.237]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k57GDcks017043; Wed, 7 Jun 2006 09:13:59 -0700 (PDT) In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C2908F0@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB00C2908F0@en0033exch001u.uk.lucent.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <19B7EC33-5163-48FB-A22F-7776BFCCB52F@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt Date: Wed, 7 Jun 2006 07:34:58 -0700 To: "Drage, Keith (Keith)" X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=4578; t=1149696839; x=1150560839; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20I-D=20ACTION=3Adraft-ietf-sip-hop-limit-diagnostics-02.t xt=20; X=v=3Dcisco.com=3B=20h=3DuuoBsEgzdw6+9X+Y6yGlgJ8d2Es=3D; b=p16PtCCAnyAz66hsTtpak/67nxEIDD9sdRS/WGNDyZtHYH0BJeeXYmpGDC/xL38QSbcflPx6 mlKl2LBH5LnIYbi1fl0gCfcZQBxMun2nKslFhZ73ao/OeZNoEXKtmDYS; Authentication-Results: sj-dkim-4.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think it still has at least one serious question open - that being does it help or harm? The example in the draft, each via is about 87 octets and imagine it had 70 hops or so. This would be a real big response - too big for a UDP packet most likely. To follow the congestion safety, I don't know how to deal with this. If seems that in many systems, the resource would simply be dropped because it is too large. It seems like not getting any response would be far worse than getting getting a response that did not have the debugging information. On Jun 6, 2006, at 8:18 AM, Drage, Keith (Keith) wrote: > (as WG chair) > > The author thinks this document is complete. > > If this is true we should be putting it into working group last > call, and after that pushing it up to the IESG. > > Do you (the SIP WG) agree with author, such that this document is > ready, or are there issues you would still like addressed with this > document. > > Secondly, in parallel with the WGLC, we would like to see some > detailed reviewers. If you would like to do this, particularly if > you are atteFrom sip-bounces@ietf.org Wed Jun 07 12:15:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo0fT-0006rC-IY; Wed, 07 Jun 2006 12:14:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo0fQ-0006qu-Py for sip@ietf.org; Wed, 07 Jun 2006 12:14:00 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo0fQ-0004JW-Az for sip@ietf.org; Wed, 07 Jun 2006 12:14:00 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 07 Jun 2006 09:14:01 -0700 X-IronPort-AV: i="4.05,217,1146466800"; d="scan'208"; a="430077001:sNHT33990412" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k57GDxXL027541; Wed, 7 Jun 2006 09:13:59 -0700 Received: from [128.107.138.237] (dhcp-128-107-138-237.cisco.com [128.107.138.237]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k57GDcks017043; Wed, 7 Jun 2006 09:13:59 -0700 (PDT) In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C2908F0@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB00C2908F0@en0033exch001u.uk.lucent.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <19B7EC33-5163-48FB-A22F-7776BFCCB52F@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt Date: Wed, 7 Jun 2006 07:34:58 -0700 To: "Drage, Keith (Keith)" X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=4578; t=1149696839; x=1150560839; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20I-D=20ACTION=3Adraft-ietf-sip-hop-limit-diagnostics-02.t xt=20; X=v=3Dcisco.com=3B=20h=3DuuoBsEgzdw6+9X+Y6yGlgJ8d2Es=3D; b=p16PtCCAnyAz66hsTtpak/67nxEIDD9sdRS/WGNDyZtHYH0BJeeXYmpGDC/xL38QSbcflPx6 mlKl2LBH5LnIYbi1fl0gCfcZQBxMun2nKslFhZ73ao/OeZNoEXKtmDYS; Authentication-Results: sj-dkim-4.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think it still has at least one serious question open - that being does it help or harm? The example in the draft, each via is about 87 octets and imagine it had 70 hops or so. This would be a real big response - too big for a UDP packet most likely. To follow the congestion safety, I don't know how to deal with this. If seems that in many systems, the resource would simply be dropped because it is too large. It seems like not getting any response would be far worse than getting getting a response that did not have the debugging information. On Jun 6, 2006, at 8:18 AM, Drage, Keith (Keith) wrote: > (as WG chair) > > The author thinks this document is complete. > > If this is true we should be putting it into working group last > call, and after that pushing it up to the IESG. > > Do you (the SIP WG) agree with author, such that this document is > ready, or are there issues you would still like addressed with this > document. > > Secondly, in parallel with the WGLC, we would like to see some > detailed reviewers. If you would like to do this, particularly if > you are attempting to use this draft in some application, please > send your names to Dean and myself. > > regards > > Keith > >> -----Original Message----- >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >> Sent: 02 June 2006 20:50 >> To: i-d-announce@ietf.org >> Cc: sip@ietf.org >> Subject: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.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 : Diagnostic Responses for SIP Hop Limit Errors >> Author(s) : S. Lawrence, et al. >> Filename : draft-ietf-sip-hop-limit-diagnostics-02.txt >> Pages : 12 >> Date : 2006-6-2 >> >> The SIP protocol imposes a limit on the number of hops a request may >> make from a sender to the recipient. When this limit is reached, a >> 483 error response is returned. The present form of the 483 response >> does not provide enough information for the sender or proxies on the >> path to diagnose failures whose symptom is that the hop limit is >> reached. This document proposes additional diagnostic information to >> be returned in a 483 response. >> >> Comments are solicited, and should be directed to the SIP working >> group list at 'sip@ietf.org'. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-sip-hop-limit-d > iagnostics-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body > of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sip-hop-limit-diagnostics-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sip-hop-limit-diagnostics-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 07 12:15:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo0fU-0006sO-M5; Wed, 07 Jun 2006 12:14:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo0fS-0006qz-2V for sip@ietf.org; Wed, 07 Jun 2006 12:14:02 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iportmpting to use this draft in some application, please > send your names to Dean and myself. > > regards > > Keith > >> -----Original Message----- >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >> Sent: 02 June 2006 20:50 >> To: i-d-announce@ietf.org >> Cc: sip@ietf.org >> Subject: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.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 : Diagnostic Responses for SIP Hop Limit Errors >> Author(s) : S. Lawrence, et al. >> Filename : draft-ietf-sip-hop-limit-diagnostics-02.txt >> Pages : 12 >> Date : 2006-6-2 >> >> The SIP protocol imposes a limit on the number of hops a request may >> make from a sender to the recipient. When this limit is reached, a >> 483 error response is returned. The present form of the 483 response >> does not provide enough information for the sender or proxies on the >> path to diagnose failures whose symptom is that the hop limit is >> reached. This document proposes additional diagnostic information to >> be returned in a 483 response. >> >> Comments are solicited, and should be directed to the SIP working >> group list at 'sip@ietf.org'. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-sip-hop-limit-d > iagnostics-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body > of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sip-hop-limit-diagnostics-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sip-hop-limit-diagnostics-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 07 12:15:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo0fU-0006sO-M5; Wed, 07 Jun 2006 12:14:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo0fS-0006qz-2V for sip@ietf.org; Wed, 07 Jun 2006 12:14:02 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo0fQ-0004JX-QX for sip@ietf.org; Wed, 07 Jun 2006 12:14:02 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 07 Jun 2006 09:14:00 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k57GE08r006604; Wed, 7 Jun 2006 09:14:00 -0700 Received: from [128.107.138.237] (dhcp-128-107-138-237.cisco.com [128.107.138.237]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k57GDckt017043; Wed, 7 Jun 2006 09:14:00 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8A0592DF-8999-441C-BE99-4A9335A8E4C6@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] outbound-keepalive question Date: Wed, 7 Jun 2006 07:37:07 -0700 To: zhou hong X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=354; t=1149696840; x=1150560840; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20outbound-keepalive=20question; X=v=3Dcisco.com=3B=20h=3D5qO2qPn42EA+vTIlaMJ3LbXC5uM=3D; b=MQJr20DuorWmJFMzXR2YChFVPi3cgCfgppCi88cuGKiSd4Iz3yY1RqAc1A3EdnuZOg6JuO+2 xD/i5oUIx/xFUpW0EFIqszmyhMkrIjeyJzPv5Ltr1yf37GM3vfRynzeV; Authentication-Results: sj-dkim-3.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 5, 2006, at 6:51 PM, zhou hong wrote: > But in draft-ietf-behave-rfc3489bis-03 says " There are two types of > requests defined in this specification - Binding Requests, sent over > UDP, and Shared Secret Requests, sent over TLS [6] over TCP ". I think that outbound would not us the shared secret requests. Other STUN usages might. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip -1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo0fQ-0004JX-QX for sip@ietf.org; Wed, 07 Jun 2006 12:14:02 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 07 Jun 2006 09:14:00 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k57GE08r006604; Wed, 7 Jun 2006 09:14:00 -0700 Received: from [128.107.138.237] (dhcp-128-107-138-237.cisco.com [128.107.138.237]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k57GDckt017043; Wed, 7 Jun 2006 09:14:00 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8A0592DF-8999-441C-BE99-4A9335A8E4C6@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] outbound-keepalive question Date: Wed, 7 Jun 2006 07:37:07 -0700 To: zhou hong X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=354; t=1149696840; x=1150560840; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20outbound-keepalive=20question; X=v=3Dcisco.com=3B=20h=3D5qO2qPn42EA+vTIlaMJ3LbXC5uM=3D; b=MQJr20DuorWmJFMzXR2YChFVPi3cgCfgppCi88cuGKiSd4Iz3yY1RqAc1A3EdnuZOg6JuO+2 xD/i5oUIx/xFUpW0EFIqszmyhMkrIjeyJzPv5Ltr1yf37GM3vfRynzeV; Authentication-Results: sj-dkim-3.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 5, 2006, at 6:51 PM, zhou hong wrote: > But in draft-ietf-behave-rfc3489bis-03 says " There are two types of > requests defined in this specification - Binding Requests, sent over > UDP, and Shared Secret Requests, sent over TLS [6] over TCP ". I think that outbound would not us the shared secret requests. Other STUN usages might. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 07 12:39:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo12L-0005FG-TP; Wed, 07 Jun 2006 12:37:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo12K-0005F9-6P for sip@ietf.org; Wed, 07 Jun 2006 12:37:40 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo0kQ-0004zY-FX for sip@ietf.org; Wed, 07 Jun 2006 12:19:10 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fo0fO-0001Vb-3V for sip@ietf.org; Wed, 07 Jun 2006 12:13:59 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 07 Jun 2006 09:13:54 -0700 X-IronPort-AV: i="4.05,217,1146466800"; d="scan'208"; a="1821249929:sNHT7946494904" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k57GDsIS018705; Wed, 7 Jun 2006 09:13:54 -0700 Received: from [128.107.138.237] (dhcp-128-107-138-237.cisco.com [128.107.138.237]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k57GDcko017043; Wed, 7 Jun 2006 09:13:54 -0700 (PDT) In-Reply-To: References: <50B1CBA96870A34799A506B2313F26670918240F@ntht201e.siemenscomms.co.uk> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <57B62710-CC9D-4FDE-9D76-EFD4A49D5087@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: AW: AW: [Sip] Connected-identity and changing the To header f ield ina response Date: Wed, 7 Jun 2006 07:00:56 -0700 To: Feng Cao X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=442; t=1149696834; x=1150560834; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20AW=3A=20AW=3A=20[Sip]=20Connected-identity=20and=20changing=20th e=20To=20header=20f=20ield=20ina=09response; X=v=3Dcisco.com=3B=20h=3DCdwckvEbs480gsOs/PbPlmpNoKk=3D; b=Xu1QH2gA1E/YE4jXVD6EY6HY3TC91ByXvMcNBOd/pc1QcxVkt9+RjMIgRuyfB9F/ueFP5zpW XqJQmiP+xYo020DIFrq9zQuAAy3dfpJLxJvGUUbtmb3RweX3kXM9cFUX; Authentication-Results: sj-dkim-1.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: "Jesske, R" , sip@ietf.org, pkyzivat@cisco.com, "Elwell, John" , roland.jesske@web.de, christer.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 6, 2006, at 1:34 PM, Feng Cao wrote: > To use one new header, it is straightforward to add authentication > as well as the identity into this new header. Please see our draft > http://www.ietf.org/internet-drafts/draft-cao-sip-response- > identity-00.txt > the new header can also indicate if the authentication is needed and > which authentication method is used. I don't think this draft would help solve the problem. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 07 13:03:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo1Pb-0003SF-1Z; Wed, 07 Jun 2006 13:01:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo1PZ-0003SA-Br for sip@ietf.org; Wed, 07 Jun 2006 13:01:41 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo1PY-0003OB-5E for sip@ietf.org; Wed, 07 Jun 2006 13:01:41 -0400 Received: from [127.0.0.1] (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k57H1WWS031660; Wed, 7 Jun 2006 17:01:39 GMT Message-ID: <44870663.5080406@neustar.biz> Date: Wed, 07 Jun 2006 10:01:23 -0700 From: Jeff Hodges User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: IETF SIP WG Subject: Re: [Sip] What to do with SIP SAML draft References: <2B137721-9B8A-4EB1-94A8-6039C06D8F09@softarmor.com> In-Reply-To: <2B137721-9B8A-4EB1-94A8-6039C06D8F09@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > Our options include: > > 1) Adopt this draft as a WG document and keep working on it. > > 2) Decide we don't need to solve the problem just yet and abandon the > milestone. > > 3) Let Hannes and team keep working on it until we decide it has reached > critical mass, and keep slipping the milestone along. > > 4) Do something entirely different. I'd certainly vote for (1), tho (3) would be fine I suppose. We will have a revised rev (-06) incorporating Vijay's feedback (thanks!) before the I-D cutoff date. thanks, JeffH _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 07 13:45:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo242-0000yH-ST; Wed, 07 Jun 2006 13:43:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo240-0000yC-Uy for sip@ietf.org; Wed, 07 Jun 2006 13:43:28 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo23z-0008TH-L0 for sip@ietf.org; Wed, 07 Jun 2006 13:43:28 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 07 Jun 2006 10:43:27 -0700 X-IronPort-AV: i="4.05,217,1146466800"; d="scan'208"; a="290764572:sNHT32231052" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k57HhRPJ003862; Wed, 7 Jun 2006 10:43:27 -0700 Received: from [128.107.138.237] (dhcp-128-107-138-237.cisco.com [128.107.138.237]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k57HhRke007788; Wed, 7 Jun 2006 10:43:27 -0700 (PDT) In-Reply-To: <2B137721-9B8A-4EB1-94A8-6039C06D8F09@softarmor.com> References: <2B137721-9B8A-4EB1-94A8-6039C06D8F09@softarmor.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] What to do with SIP SAML draft Date: Wed, 7 Jun 2006 10:43:22 -0700 To: Dean Willis X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=1750; t=1149702207; x=1150566207; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20What=20to=20do=20with=20SIP=20SAML=20draft; X=v=3Dcisco.com=3B=20h=3DUcUDkGZVoF/tQFUSkMAzPYchmgI=3D; b=DAbAji7cuvXS9tu8eEKx/40Q1mk0JvNx2vYrolMal6rSfqbB8mI4ElepuvAdVAj802eaji6d kEFN5FcjT8RK/vpd1HhKUSmv12yohn72G2IcKWA7hphCw4VqrtFgtTpj; Authentication-Results: sj-dkim-4.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Sip IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org It seems like SAML is likely to end up as useful (and this document will help us use it). However, we don't have very many concrete things defined yet of how we would use it or what all the things are that we would need it to do. It has moments of feeling like a technology looking for a problem. I think that tends to make me thing we should keep working on it, and perhaps if we want to adopt it, change the milestone to specific problems we would solve with it. Cullen On Jun 6, 2006, at 10:56 AM, Dean Willis wrote: > > Our current charter and slightly-stale milestones include a > deliverable for SAML: > > Jul 2006 -- Using SAML for SIP (PS) > > > At the IETF 65, we discussed the Tschofenig draft, currently > available as: > > http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-05.txt > > We didn't have a firm consensus in the room for what to do with > this, so It'd like to discuss it now. > > > Our options include: > > 1) Adopt this draft as a WG document and keep working on it. > > 2) Decide we don't need to solve the problem just yet and abandon > the milestone. > > 3) Let Hannes and team keep working on it until we decide it has > reached critical mass, and keep slipping the milestone along. > > 4) Do something entirely different. > > > So, what do you people think? > > -- > Dean > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 07 14:09:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2R2-0006Ig-Oq; Wed, 07 Jun 2006 14:07:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2R1-0006Go-5Y for sip@ietf.org; Wed, 07 Jun 2006 14:07:15 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo2Qz-0003TS-Ll for sip@ietf.org; Wed, 07 Jun 2006 14:07:15 -0400 Received: from [64.101.149.214] ([64.101.149.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k57I8ahm004539 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 7 Jun 2006 13:08:37 -0500 Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: <2326FA67-696C-494A-B401-DB8A2A91D6AF@softarmor.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Sip IETF From: Dean Willis Date: Wed, 7 Jun 2006 13:07:13 -0500 X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Sip] Any WG -00 drafts to be issued between now and the cutoff for IETF 66? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm not actually expecting any new working-group -00 drafts (other than the HitchHikers Guide), between now and IETF 66, but I've learned to expect the unexpected. Is anyone here working on or aware of anyone working on a new WG draft? -- 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 Jun 07 14:26:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2i0-0000AY-RH; Wed, 07 Jun 2006 14:24:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2hy-000096-PM for sip@ietf.org; Wed, 07 Jun 2006 14:24:46 -0400 Received: from mail126.messagelabs.com ([216.82.250.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fo2hx-0004Gx-Cu for sip@ietf.org; Wed, 07 Jun 2006 14:24:46 -0400 X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-12.tower-126.messagelabs.com!1149704624!9729008!12 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 8431 invoked from network); 7 Jun 2006 18:24:32 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-12.tower-126.messagelabs.com with SMTP; 7 Jun 2006 18:24:32 -0000 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.12) by attrh3i.attrh.att.com (7.2.052) id 4479CA7F00129FD2; Wed, 7 Jun 2006 14:24:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] What to do with SIP SAML draft Date: Wed, 7 Jun 2006 13:24:30 -0500 Message-ID: <28F05913385EAC43AF019413F674A0170DE0C801@OCCLUST04EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] What to do with SIP SAML draft Thread-Index: AcaKXGHgnsFj8MVHR7KDMRBcWsnjPQAAvoHA From: "Dolly, Martin C, ALABS" To: "Cullen Jennings" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Sip IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I support adopting the draft as a WG item. With next steps focusing on use cases. Cheers, Martin=20 -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com]=20 Sent: Wednesday, June 07, 2006 1:43 PM To: Dean Willis Cc: Sip IETF Subject: Re: [Sip] What to do with SIP SAML draft It seems like SAML is likely to end up as useful (and this document =20 will help us use it). However, we don't have very many concrete =20 things defined yet of how we would use it or what all the things are =20 that we would need it to do. It has moments of feeling like a =20 technology looking for a problem. I think that tends to make me thing we should keep working on it, and =20 perhaps if we want to adopt it, change the milestone to specific =20 problems we would solve with it. Cullen On Jun 6, 2006, at 10:56 AM, Dean Willis wrote: > > Our current charter and slightly-stale milestones include a =20 > deliverable for SAML: > > Jul 2006 -- Using SAML for SIP (PS) > > > At the IETF 65, we discussed the Tschofenig draft, currently =20 > available as: > > http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-05.txt > > We didn't have a firm consensus in the room for what to do with =20 > this, so It'd like to discuss it now. > > > Our options include: > > 1) Adopt this draft as a WG document and keep working on it. > > 2) Decide we don't need to solve the problem just yet and abandon =20 > the milestone. > > 3) Let Hannes and team keep working on it until we decide it has =20 > reached critical mass, and keep slipping the milestone along. > > 4) Do something entirely different. > > > So, what do you people think? > > -- > Dean > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 07 14:47:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo31u-0003eT-Ls; Wed, 07 Jun 2006 14:45:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo31t-0003Yi-Dk for sip@ietf.org; Wed, 07 Jun 2006 14:45:21 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo31s-0007Ot-5G for sip@ietf.org; Wed, 07 Jun 2006 14:45:21 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 07 Jun 2006 11:45:20 -0700 X-IronPort-AV: i="4.05,217,1146466800"; d="scan'208"; a="430116955:sNHT1459173870" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k57IjJC8009606; Wed, 7 Jun 2006 11:45:19 -0700 Received: from [128.107.138.237] (dhcp-128-107-138-237.cisco.com [128.107.138.237]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k57IjIke024898; Wed, 7 Jun 2006 11:45:18 -0700 (PDT) In-Reply-To: <475FF955A05DD411980D00508B6D5FB0130F70C3@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB0130F70C3@en0033exch001u.uk.lucent.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3A778504-2382-40C5-8C24-2D93F2D1695E@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Connected-identity and changing the To header field ina response Date: Wed, 7 Jun 2006 11:45:13 -0700 To: "Drage, Keith (Keith)" X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=860; t=1149705919; x=1150569919; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Connected-identity=20and=20changing=20the=20To=20header= 20field=20ina=20response; X=v=3Dcisco.com=3B=20h=3Df84KHgZGNz0QggvC4EBI34LfHus=3D; b=btx2qmLjZC4FovnemW/6V7v1VWruYBgnphAC7Bk39HzmD0bD8YLvBHHQceuzpYlZxQqW+++J LUNCnycRz3BnvId/jxjuB9fpRnwiPBHJ+9H7KCgHzUJ/nIBqbBiM8JHS; Authentication-Results: sj-dkim-2.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: "'Jesske, R'" , "'sip@ietf.org'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 7, 2006, at 6:09 AM, Drage, Keith (Keith) wrote: > Neither identity is clearly wrong. This issue is that the assertion > of each identity may be right for some purposes, but not the best > for others. The public network asserted identity works fine for > charging purposes, and allocation of public network services in > accordance with the subscriber's wishes, but is useless as a dial > back number. For the enterprise network asserted identity, the > opposite applies. Ok, that makes sense. If the requirements are we need an billing identifier and an number where the user (not I said user not device) may be reached we can try to suggest work on something. If the requirement is where the devices (not the user) may be reached we could work on that too. I did not get this out of the requirement document. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 07 15:36:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo3ng-0000SH-4P; Wed, 07 Jun 2006 15:34:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo3nf-0000Qw-1J for sip@ietf.org; Wed, 07 Jun 2006 15:34:43 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo3ne-0005DV-9g for sip@ietf.org; Wed, 07 Jun 2006 15:34:43 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0J0I0070192ISP@siemenscomms.co.uk> for sip@ietf.org; Wed, 07 Jun 2006 20:35:06 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J0I0065S92HF4@siemenscomms.co.uk>; Wed, 07 Jun 2006 20:35:05 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 07 Jun 2006 20:34:40 +0100 Content-return: allowed Date: Wed, 07 Jun 2006 20:34:39 +0100 From: "Elwell, John" Subject: RE: AW: AW: [Sip] Connected-identity and changing the To header f ield ina response To: Cullen Jennings Message-id: <50B1CBA96870A34799A506B2313F2667091C261D@ntht201e.siemenscomms.co.uk> 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: 1094b1c84fa6e846d476f39271f5074f Cc: "Jesske, R" , sip@ietf.org, pkyzivat@cisco.com, roland.jesske@web.de, christer.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen, Yes, with option 3 it would indeed be UPDATE normally. John > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: 07 June 2006 15:00 > To: Elwell, John > Cc: Jesske, R; sip@ietf.org; pkyzivat@cisco.com;=20 > roland.jesske@web.de; christer.holmberg@ericsson.com > Subject: Re: AW: AW: [Sip] Connected-identity and changing=20 > the To header f ield ina response >=20 >=20 > In the reverse direction, why not use UPDATE? >=20 > On Jun 6, 2006, at 12:17 PM, Elwell, John wrote: >=20 > > The requirements have indeed been described in the=20 > tispan-requirements > > draft, but clearly there is still some misunderstanding.=20 > Let me try =20 > > to shed > > some light, although my background is enterprise rather than = =20 > > carrier and I > > don't pretend to understand all practices of PSTN or NGN. > > > > A PSTN carries two identities in each direction - one that has be= en > > "authenticated" or "screened" by the PSTN and one that has been = =20 > > received > > from outside the PSTN and has not been screened. The first type o= f =20 > > identity > > is used for billing, authorisation etc. within the PSTN, and may = =20 > > also be > > delivered to the customer premises equipment. The second type of = =20 > > identity is > > used only for delivery to the customer premises equipment.=20 > What the =20 > > customer > > premises equipment does with the two types of identities is=20 > not really > > specified, but I think enterprise networks (e.g., based on=20 > QSIG) would > > normally use only the first type of identity for passing through = the > > enterprise network to the end user. > > > > I believe TISPAN has ambitions to support these two types of = =20 > > identity in > > NGN, so this leads to the question how to carry the two identitie= s =20 > > in SIP. > > > > For the INVITE request, the first caller identity is carried in t= he > > P-Asserted-Identity header, the first node in the NGN having = =20 > > authenticated > > the source of the request by some means (e.g., through the=20 > certificate > > supplied during TLS handshake). The second caller identity is = =20 > > carried in the > > From header. Obviously the latter is open to falsification unless= =20 > > supported > > by an Identity header. With the Identity header, the second calle= r =20 > > identity > > would be far more useful to the destination customer premises = =20 > > equipment. > > > > For the reverse direction, the first callee identity is=20 > carried in the > > P-Asserted-Identity header, I believe. There are fewer=20 > authentication > > options, but I guess TLS-based authentication is still a =20 > > possibility. So the > > question is how to supply the second callee identity. > > > > Option 1. Modify the To header in the INVITE response.=20 > There have been > > objections to this. Also it would not be authenticated, so=20 > it would =20 > > not be > > nearly as useful as the second identity in the request, which can= be > > authenticated by the Identity header. > > > > Option 2. Use the Reply-To header or some new header in the INVIT= E =20 > > response. > > The objections concerning modifying the To header go away, but = =20 > > again it > > would not be authenticated, so it would not be nearly as=20 > useful as the > > second identity in the request. > > > > Option 3. Use the From header in conjunction with the Identity = =20 > > header in a > > request in the reverse direction, as specified in the Connected-= =20 > > Identity > > draft. This seems to solve the problem, except that it may make = =20 > > interworking > > with PSTN signalling more difficult since PSTN expects the second= =20 > > identity > > in the "answer" message. If a solution to this signalling =20 > > interworking can > > be found, I think option 3 would clearly be the best solution. > > > > John > > > >> -----Original Message----- > >> From: Jesske, R [mailto:R.Jesske@t-com.net] > >> Sent: 01 June 2006 09:42 > >> To: fluffy@cisco.com > >> Cc: sip@ietf.org; pkyzivat@cisco.com; Elwell, John; > >> roland.jesske@web.de; christer.holmberg@ericsson.com > >> Subject: AW: AW: AW: [Sip] Connected-identity and changing > >> the To header f ield ina response > >> > >> The two identities are used for PBX services. > >> Example > >> If a user calls a special hotline for e.G. Computer Services. > >> +496151830. > >> This is the main number of a PBX with several extensions. The > >> user will be at least connected to an Service Expert > >> (Extension No: +496151831111). > >> So now there is a Public Id (+496151830) that is trusted and > >> the all billing is bind to. (TISPAN uses the P-Asserted-Identity= ) > >> and a private not secure id of the Expert. Advantage is that > >> the Caller has now the ability to see the real connected > >> number where the expert can now called directly. > >> > >> This service is widely used within the PSTN/ISDN world and is > >> known as COLP (Connected Line Identification Presentation) > >> Specifies in ITU-T Q.731.5 and in ETSI ETSI EN 300 094 (free > >> downloadable at portal.etsi.org). > >> > >> We have described the Requirements in > >> draft-jesske-sipping-tispan-requirements-01 and did some > >> analysis in the past in draft-jesske-sipping-tispan-analysis-00.= txt > >> > >> Best Regards > >> > >> Roland > >> > >> > >>> -----Urspr=FCngliche Nachricht----- > >>> Von: Cullen Jennings [mailto:fluffy@cisco.com] > >>> Gesendet: Donnerstag, 1. Juni 2006 09:11 > >>> An: Jesske, Roland > >>> Cc: pkyzivat@cisco.com; sip@ietf.org; > >>> john.elwell@siemens.com; roland.jesske@web.de; > >>> christer.holmberg@ericsson.com > >>> Betreff: Re: AW: AW: [Sip] Connected-identity and changing > >>> the To header field ina response > >>> > >>> > >>> > >>> What things use these two identities, what do they get used > >> for, and > >>> what security assumptions come around them. That type of > >> information > >>> would help people on this list understand the problem. > >>> > >>> On May 31, 2006, at 10:28 PM, Jesske, R wrote: > >>> > >>>> Paul, > >>>> in the past we lookes also on the Reply-to header. But per > >>>> definition it is the address where the user want to be > >> connected. > >>>> So it is not in each case the real conected identity. But > >> the COLP > >>>> (TIP) service could be used in the same way. > >>>> So if it would be possible to use Reply-to header in > >> Responses, if > >>>> people are willing and we as TISPAN can narrow it then > >> only to the > >>>> real connected identity (within our walled garden service > >>>> definition) I would be happy. > >>>> > >>>> Best Regards > >>>> > >>>> Roland > >>>> > >>>>> -----Urspr=FCngliche Nachricht----- > >>>>> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>>> Gesendet: Mittwoch, 31. Mai 2006 17:04 > >>>>> An: Jesske, Roland > >>>>> Cc: fluffy@cisco.com; sip@ietf.org; john.elwell@siemens.com; > >>>>> roland.jesske@web.de; christer.holmberg@ericsson.com > >>>>> Betreff: Re: AW: [Sip] Connected-identity and changing the To > >>>>> header field ina response > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Jesske, R wrote: > >>>>>> These are the requirements we already expressed in our > >>>>> draft draft-jesske-sipping-tispan-requirements-02: > >>>>>> > >>>>>> REQ-TIP-1: In addition to any network asserted identity, > >>>>> it must be > >>>>>> possible for the callee to indicate in a SIP > >>>>> response an > >>>>>> additional identity where the user is > >>>>> reachable for future > >>>>>> direct communications. Note that the > >>>>> requirement refers > >>>>>> to the user, not to the same instance of the > >>>>> User Agent. > >>>>>> REQ-TIP-2: The identity mentioned in REQ-TIP-1 must be > >>>>> formatted as a > >>>>>> SIP URI [2] or TEL URL [3]. A translation > >>>>> between SIP URI > >>>>>> and TEL URL by the network is not requested. > >>>>>> REQ-TIP-3: The identity mentioned in REQ-TIP-1 is > >>>>> considered an end > >>>>>> user supplied information that is not > >>> asserted by the > >>>>>> network. > >>>>>> > >>>>>> > >>>>>> As you can see we do not need any authenticated identity in > >>>>> the response. For the authenticated identity we are using the > >>>>> P-Asserted-Identity. So we have two identities in a Response. > >>>>>> For our purposes the user provided identity in a final 200 > >>>>> OK response is sufficient. So that avoids confusion within > >>>>> forking cases. > >>>>> > >>>>> I haven't been paying close attention to this. What > >> header are you > >>>>> planning to use to carry this callee provided identity? > >>>>> > >>>>> The Reply-To header would seem to be appropriate for this > >>>>> purpose, but > >>>>> unfortunately, according to table 2 of 3261, it is only > >>>>> allowed in INVITE. > >>>>> > >>>>> =09Paul > >>>>> > >>>>>> Roland > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Urspr=FCngliche Nachricht----- > >>>>>>> Von: Cullen Jennings [mailto:fluffy@cisco.com] > >>>>>>> Gesendet: Montag, 22. Mai 2006 17:32 > >>>>>>> An: Jesske, Roland > >>>>>>> Cc: John Elwell; sip@ietf.org; Roland Jesske; Christer > >>>>>>> Holmberg (JO/LMF) > >>>>>>> Betreff: Re: [Sip] Connected-identity and changing the To > >>>>>>> header field ina response > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On May 16, 2006, at 7:07 AM, Jesske, R wrote: > >>>>>>> > >>>>>>>> John, > >>>>>>>> it is that we don't can get an connected identity within > >>>>> the final > >>>>>>>> response of the initial INVITE. > >>>>>>>> Your draft proposes a mid dialog request for getting this > >>>>>>> information. > >>>>>>>> That is not usable for the TIP service. > >>>>>>> I think this is part of what I am not understanding. > >> What is the > >>>>>>> requirement here? > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>>>> This list is for NEW development of the core SIP Protocol > >>>>>> Use sip-implementors@cs.columbia.edu for questions on > >> current sip > >>>>>> Use sipping@ietf.org for new developments on the > >>> application of sip > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>>> This list is for NEW development of the core SIP Protocol > >>>>> Use sip-implementors@cs.columbia.edu for questions on=20 > current sip > >>>>> Use sipping@ietf.org for new developments on the > >> application of sip > >>>>> > >>> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current si= p > >> Use sipping@ietf.org for new developments on the application of = sip > >> > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of s= ip >=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 Jun 07 16:34:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo4hS-0004xe-A1; Wed, 07 Jun 2006 16:32:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo4hP-0004Vg-N6 for sip@ietf.org; Wed, 07 Jun 2006 16:32:19 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo4hP-00063o-F3 for sip@ietf.org; Wed, 07 Jun 2006 16:32:19 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k57KWIHo022097; Wed, 7 Jun 2006 20:32:19 GMT Received: from stntexch03.cis.neustar.com ([10.31.13.45]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 16:32:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] What to do with SIP SAML draft Date: Wed, 7 Jun 2006 16:32:18 -0400 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD597054F446F@stntexch03.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] What to do with SIP SAML draft Thread-Index: AcaJkqtQXoPsSUG8TXyE3Nwp32LlcwA3km+w From: "Peterson, Jon" To: "Dean Willis" , "Sip IETF" X-OriginalArrivalTime: 07 Jun 2006 20:32:18.0859 (UTC) FILETIME=[78C287B0:01C68A71] X-Spam-Score: -2.8 (--) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Didn't we already have a mailing list "hum" to adopt this as a WG item = on 3/26/06? Was that deemed inconclusive by the chairs? Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, June 06, 2006 10:56 AM > To: Sip IETF > Subject: [Sip] What to do with SIP SAML draft >=20 >=20 >=20 > Our current charter and slightly-stale milestones include a =20 > deliverable for SAML: >=20 > Jul 2006 -- Using SAML for SIP (PS) >=20 >=20 > At the IETF 65, we discussed the Tschofenig draft, currently =20 > available as: >=20 > http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-05.txt >=20 > We didn't have a firm consensus in the room for what to do=20 > with this, =20 > so It'd like to discuss it now. >=20 >=20 > Our options include: >=20 > 1) Adopt this draft as a WG document and keep working on it. >=20 > 2) Decide we don't need to solve the problem just yet and=20 > abandon the =20 > milestone. >=20 > 3) Let Hannes and team keep working on it until we decide it has =20 > reached critical mass, and keep slipping the milestone along. >=20 > 4) Do something entirely different. >=20 >=20 > So, what do you people think? >=20 > -- > Dean >=20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=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 Jun 07 17:12:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo5Io-0003Uh-7N; Wed, 07 Jun 2006 17:10:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo5Im-0003Uc-II for sip@ietf.org; Wed, 07 Jun 2006 17:10:56 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo5Il-0003AR-4W for sip@ietf.org; Wed, 07 Jun 2006 17:10:56 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 07 Jun 2006 14:10:33 -0700 X-IronPort-AV: i="4.05,217,1146466800"; d="scan'208"; a="1821481437:sNHT7372731300" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k57LAWlo023341; Wed, 7 Jun 2006 14:10:32 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k57LAUCu025475; Wed, 7 Jun 2006 14:10:32 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Jun 2006 14:10:30 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.120.203]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Jun 2006 14:10:29 -0700 Message-Id: <4.3.2.7.2.20060607160938.036be318@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 07 Jun 2006 16:10:28 -0500 To: "Peterson, Jon" , "Dean Willis" , "Sip IETF" From: "James M. Polk" Subject: RE: [Sip] What to do with SIP SAML draft In-Reply-To: <24EAE5D4448B9D4592C6D234CBEBD597054F446F@stntexch03.cis.ne ustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 07 Jun 2006 21:10:30.0015 (UTC) FILETIME=[CE6530F0:01C68A76] DKIM-Signature: a=rsa-sha1; q=dns; l=2044; t=1149714632; x=1150578632; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:RE=3A=20[Sip]=20What=20to=20do=20with=20SIP=20SAML=20draft; X=v=3Dcisco.com=3B=20h=3DklXAfeFWsIQB7VA3NXaqYa6dhGc=3D; b=JZXHJshiAN5oBAgaSrpBVkdm0HBSIigrw+kd5Up/wjfrI6NnKkz17KmXYvRf7k9Cd5sk8irU 2Wmr85mCwbTzn4F2MlfV+Vf2U5YxPueQA4NNI8QZMTAmnvjjrZRq37kZ; Authentication-Results: sj-dkim-4.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 04:32 PM 6/7/2006 -0400, Peterson, Jon wrote: >Didn't we already have a mailing list "hum" to adopt this as a WG item on >3/26/06? Was that deemed inconclusive by the chairs? I thought this was the conclusion too. >Jon Peterson >NeuStar, Inc. > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Tuesday, June 06, 2006 10:56 AM > > To: Sip IETF > > Subject: [Sip] What to do with SIP SAML draft > > > > > > > > Our current charter and slightly-stale milestones include a > > deliverable for SAML: > > > > Jul 2006 -- Using SAML for SIP (PS) > > > > > > At the IETF 65, we discussed the Tschofenig draft, currently > > available as: > > > > http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-05.txt > > > > We didn't have a firm consensus in the room for what to do > > with this, > > so It'd like to discuss it now. > > > > > > Our options include: > > > > 1) Adopt this draft as a WG document and keep working on it. > > > > 2) Decide we don't need to solve the problem just yet and > > abandon the > > milestone. > > > > 3) Let Hannes and team keep working on it until we decide it has > > reached critical mass, and keep slipping the milestone along. > > > > 4) Do something entirely different. > > > > > > So, what do you people think? > > > > -- > > Dean > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 07 17:24:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo5UZ-00054B-2a; Wed, 07 Jun 2006 17:23:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo5UX-000540-KE for sip@ietf.org; Wed, 07 Jun 2006 17:23:05 -0400 Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo5UW-0004qh-4J for sip@ietf.org; Wed, 07 Jun 2006 17:23:05 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 8D83523CD9F for ; Wed, 7 Jun 2006 23:23:03 +0200 (CEST) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 06651-01-51 for ; Wed, 7 Jun 2006 23:23:03 +0200 (CEST) Received: from [192.168.1.5] (155-54-253-72.adsl.um.es [155.54.253.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.um.es (Postfix) with ESMTP id 2A03623CD1F for ; Wed, 7 Jun 2006 23:23:03 +0200 (CEST) Message-ID: <448743B7.4080704@dif.um.es> Date: Wed, 07 Jun 2006 23:23:03 +0200 From: =?ISO-8859-1?Q?=22Antonio_F=2E_G=F3mez_Skarmeta=22?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: es-es, es MIME-Version: 1.0 To: sip@ietf.org Subject: [Sip] What to do with SIP SAML draft References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I support option 1, with further work in the integration with authorizati= on scenarios Regards, Antonio On Jun 6, 2006, at 10:56 AM, Dean Willis wrote: > > Our current charter and slightly-stale milestones include a =20 > deliverable for SAML: > > Jul 2006 -- Using SAML for SIP (PS) > > > At the IETF 65, we discussed the Tschofenig draft, currently =20 > available as: > > http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-05.txt > > We didn't have a firm consensus in the room for what to do with =20 > this, so It'd like to discuss it now. > > > Our options include: > > 1) Adopt this draft as a WG document and keep working on it. > > 2) Decide we don't need to solve the problem just yet and abandon =20 > the milestone. > > 3) Let Hannes and team keep working on it until we decide it has =20 > reached critical mass, and keep slipping the milestone along. > > 4) Do something entirely different. > > > So, what do you people think? > > -- > Dean > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors at cs.columbia.edu for questions on current sip > Use sipping at ietf.org for new developments on the application of sip --=20 ------------------------------------------------------------ Antonio F. G=F3mez Skarmeta Dept. Ingenier=EDa de la Informaci=F3n y las Comunicaciones Facultad de Inform=E1tica Universidad de Murcia Apartado 4021 30001 Murcia Telf: +34-968-364607 fax: +34-968-364151 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 07 22:46:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoAVS-0005pS-IL; Wed, 07 Jun 2006 22:44:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoAVQ-0005pN-7f for sip@ietf.org; Wed, 07 Jun 2006 22:44:20 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoAVO-00038O-Se for sip@ietf.org; Wed, 07 Jun 2006 22:44:20 -0400 Received: from [192.168.2.100] (c-24-1-184-104.hsd1.tx.comcast.net [24.1.184.104]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k582jgQS006339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jun 2006 21:45:43 -0500 Message-ID: <44878FDE.7030001@softarmor.com> Date: Wed, 07 Jun 2006 21:47:58 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" Subject: Re: [Sip] What to do with SIP SAML draft References: <24EAE5D4448B9D4592C6D234CBEBD597054F446F@stntexch03.cis.neustar.com> In-Reply-To: <24EAE5D4448B9D4592C6D234CBEBD597054F446F@stntexch03.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: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Sip IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Peterson, Jon wrote: > Didn't we already have a mailing list "hum" to adopt this as a WG item on 3/26/06? Was that deemed inconclusive by the chairs? > Indeed we did, and the 7 or 8 people who responded were all in favor of adopting the draft. Of course, it's 3 months later now, and the status of the draft hasn't changed a lot (so at the least there's a scheduling issue to resolve), and there's more than 7 or 8 people in the working group. Consider it a recheck for my sanity, which is questionable at best. -- 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 Jun 07 23:09:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoArw-0002QD-09; Wed, 07 Jun 2006 23:07:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoAru-0002Q8-1z for sip@ietf.org; Wed, 07 Jun 2006 23:07:34 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoArs-0006FF-Ns for sip@ietf.org; Wed, 07 Jun 2006 23:07:34 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 07 Jun 2006 20:07:32 -0700 X-IronPort-AV: i="4.05,218,1146466800"; d="scan'208"; a="1821700846:sNHT31258056" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k5837WTa002820; Wed, 7 Jun 2006 20:07:32 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5837VCU022442; Wed, 7 Jun 2006 20:07:32 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Jun 2006 20:07:31 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.120.203]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Jun 2006 20:07:31 -0700 Message-Id: <4.3.2.7.2.20060607220404.019edc98@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 07 Jun 2006 22:07:30 -0500 To: Dean Willis , "Peterson, Jon" From: "James M. Polk" Subject: Re: [Sip] What to do with SIP SAML draft In-Reply-To: <44878FDE.7030001@softarmor.com> References: <24EAE5D4448B9D4592C6D234CBEBD597054F446F@stntexch03.cis.neustar.com> <24EAE5D4448B9D4592C6D234CBEBD597054F446F@stntexch03.cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 08 Jun 2006 03:07:31.0376 (UTC) FILETIME=[AE857B00:01C68AA8] DKIM-Signature: a=rsa-sha1; q=dns; l=1241; t=1149736052; x=1150600052; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Sip]=20What=20to=20do=20with=20SIP=20SAML=20draft; X=v=3Dcisco.com=3B=20h=3DayQ26BtwQlrkSpoipMdrirK0mVQ=3D; b=H4R7yDK+6RtdruB384kmT9ryiMKzO2YFBd8V2WjjWDVoLbqjGvrtLyrnRx3FqjtcvLtenItA 5fXBEUBxh6jNT4z1I2l58FGdJms216dbm3nLMBcINbY3pKmXk4rFDk5b; Authentication-Results: sj-dkim-2.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Sip IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 09:47 PM 6/7/2006 -0500, Dean Willis wrote: >Peterson, Jon wrote: >>Didn't we already have a mailing list "hum" to adopt this as a WG item on >>3/26/06? Was that deemed inconclusive by the chairs? > >Indeed we did, and the 7 or 8 people who responded were all in favor of >adopting the draft. Of course, it's 3 months later now, and the status of >the draft hasn't changed a lot (so at the least there's a scheduling issue >to resolve), and there's more than 7 or 8 people in the working group. > >Consider it a recheck for my sanity, which is questionable at best. Does this mean our next version of the ID (what was draft-tschofenig-sip-saml-05.txt) should now be draft-ietf-sip-saml-00.txt ? If so, #1 - we need to submit it a week earlier than planned and #2 - The WG chairs need to submit a message to the Secretariat that this draft-sip-...-00 is coming >-- >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 Wed Jun 07 23:31:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoBCv-0006Zu-4Q; Wed, 07 Jun 2006 23:29:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoBCu-0006Zo-DQ for sip@ietf.org; Wed, 07 Jun 2006 23:29:16 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoAIl-0007wM-5s for sip@ietf.org; Wed, 07 Jun 2006 22:31:20 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0I003ACSD2KT@szxga01-in.huawei.com> for sip@ietf.org; Thu, 08 Jun 2006 10:31:50 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0I00BUWSD2RS@szxga01-in.huawei.com> for sip@ietf.org; Thu, 08 Jun 2006 10:31:50 +0800 (CST) Received: from z53160 ([10.164.5.15]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0I00JBRSS01Z@szxml04-in.huawei.com> for sip@ietf.org; Thu, 08 Jun 2006 10:40:56 +0800 (CST) Date: Thu, 08 Jun 2006 10:30:21 +0800 From: Harrison Zhou Subject: RE: [Sip] outbound-keepalive question In-reply-to: <8A0592DF-8999-441C-BE99-4A9335A8E4C6@cisco.com> To: 'Cullen Jennings' Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.2627 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: 2409bba43e9c8d580670fda8b695204a Cc: sip@ietf.org, ietf-behave@list.sipfoundry.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, My question's true intent is: can we send Binding Requests using TCP or TLS in Outbound. Because rfc3489bis-03 doesn't say " Binding Requests, sent over TCP or TLS" and it only says " Binding Requests, sent over UDP". Regards, Hong -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Wednesday, June 07, 2006 10:37 PM To: zhou hong Cc: sip@ietf.org Subject: Re: [Sip] outbound-keepalive question On Jun 5, 2006, at 6:51 PM, zhou hong wrote: > But in draft-ietf-behave-rfc3489bis-03 says " There are two types of > requests defined in this specification - Binding Requests, sent over > UDP, and Shared Secret Requests, sent over TLS [6] over TCP ". I think that outbound would not us the shared secret requests. Other STUN usages might. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 08 02:04:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoDbY-0008Tl-KM; Thu, 08 Jun 2006 02:02:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoDbW-0008TJ-NK for sip@ietf.org; Thu, 08 Jun 2006 02:02:50 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoDTW-0007gF-Bh for sip@ietf.org; Thu, 08 Jun 2006 01:54:36 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 07 Jun 2006 22:54:33 -0700 X-IronPort-AV: i="4.05,218,1146466800"; d="scan'208"; a="291197624:sNHT32482890" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k585sXAu010242; Wed, 7 Jun 2006 22:54:33 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k585sX9s022216; Wed, 7 Jun 2006 22:54:33 -0700 (PDT) From: "Dan Wing" To: "'Harrison Zhou'" Subject: RE: [Ietf-behave] RE: [Sip] outbound-keepalive question Date: Wed, 7 Jun 2006 22:54:33 -0700 Message-ID: <042601c68ac0$04657630$95ab6b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcaKo5PDMY7VrLPWQ5+t9GkixdFp1QAG63Zg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 DKIM-Signature: a=rsa-sha1; q=dns; l=881; t=1149746073; x=1150610073; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:RE=3A=20[Ietf-behave]=20RE=3A=20[Sip]=20outbound-keepalive=20question; X=v=3Dcisco.com=3B=20h=3DfSpL3WN4YHDaweDKDCjPc0HpZrI=3D; b=JkGh3xCXeyEXLEVjwFEFiL7npmMIMDfOCmf7rQqOP75JGlD40M99AlGqfLiLtyKj9teK9wmQ KjgiFpR1Dxif2lMpIDcd7SX+iiM5HwNdam7xgp5GspaSQDOVeb6tHGl/; Authentication-Results: sj-dkim-2.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: sip@ietf.org, 'Cullen Jennings' , ietf-behave@list.sipfoundry.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > My question's true intent is: can we send Binding Requests > using TCP or TLS in Outbound. Because rfc3489bis-03 doesn't say > "Binding Requests, sent over TCP or TLS" and it only says " Binding > Requests, sent over UDP". Consensus at the Dallas IETF SIP meeting was to send STUN over TCP connections, too. . -behave-rfc3489bis- hasn't been updated since that meeting. Reference http://www3.ietf.org/proceedings/06mar/minutes/sip.txt which says: ... Proposal: Do STUN for TCP and UDP Do CRLF for TCP and STUN for UDP TCP KeepAlive if supported, 1 or 2 otherwise Resolutions: OS TCP KeepAlive should be used if the client supports it. Need something more because OS TCP KeepAlive is not supported in every client OS. Consensus to use STUN for UDP Consensus to use STUN for TCP, with use of OS TCP keep alive above. ... -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 08 02:07:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoDeV-0002L9-6E; Thu, 08 Jun 2006 02:05:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoDeS-0002L4-UX for sip@ietf.org; Thu, 08 Jun 2006 02:05:52 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoDeQ-0001Ws-9F for sip@ietf.org; Thu, 08 Jun 2006 02:05:52 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Thu, 8 Jun 2006 08:05:48 +0200 Received: by S4DE8PSAANQ.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Jun 2006 08:05:48 +0200 Message-Id: <85108216918A984C8C60172D7C84770A08A55A@S4DE8PSAAGO.mitte.t-com.de> From: "Jesske, R" To: fluffy@cisco.com, drage@lucent.com Subject: AW: [Sip] Connected-identity and changing the To header field ina response Date: Thu, 8 Jun 2006 08:05:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Urspr=FCngliche Nachricht----- > Von: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Gesendet: Mittwoch, 7. Juni 2006 20:45 > An: Drage, Keith (Keith) > Cc: Jesske, Roland; 'sip@ietf.org' > Betreff: Re: [Sip] Connected-identity and changing the To=20 > header field ina response >=20 >=20 >=20 > On Jun 7, 2006, at 6:09 AM, Drage, Keith (Keith) wrote: >=20 > > Neither identity is clearly wrong. This issue is that the=20 > assertion =20 > > of each identity may be right for some purposes, but not the best =20 > > for others. The public network asserted identity works fine for =20 > > charging purposes, and allocation of public network services in =20 > > accordance with the subscriber's wishes, but is useless as a dial =20 > > back number. For the enterprise network asserted identity, the =20 > > opposite applies. >=20 > Ok, that makes sense. If the requirements are we need an billing =20 > identifier and an number where the user (not I said user not device) = > may be reached we can try to suggest work on something. If the =20 > requirement is where the devices (not the user) may be reached we =20 > could work on that too. I did not get this out of the requirement =20 > document. If we are going into Requirement I try to describe it in that way. We have the P-Asserted-Identity so this is the Identity where the = subscriber (not user) will be billed for.=20 For Clarification: A 'subscriber' is a person or other entity that has = contractual relationship with a service provider on behalf of one or = more users. (A subscriber is responsible for the payment of charges due = to that service provider) I took a description of user from the ETSI database = http://webapp.etsi.org/Teddi/ The "additional connected identity" is the identity where the user may = be reached. In the PTSN world it is the line where the Black Phone is = on. In SIP it should be an identity where the user may be reached. Best Regards Roland >=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 Jun 08 02:47:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoEGw-0008C3-9Z; Thu, 08 Jun 2006 02:45:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoEGu-0008By-Vm for sip@ietf.org; Thu, 08 Jun 2006 02:45:36 -0400 Received: from celtic-out.kyocera-wireless.com ([206.169.67.126] helo=celtic.intra.kyocera-wireless.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoEGt-0006Fx-LX for sip@ietf.org; Thu, 08 Jun 2006 02:45:36 -0400 Received: from [172.20.94.168] (pptp168.intra.kyocera-wireless.com [172.20.94.168]) by celtic.intra.kyocera-wireless.com (8.12.8/8.12.3) with ESMTP id k586jWYX006248; Wed, 7 Jun 2006 23:45:32 -0700 (PDT) User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 07 Jun 2006 23:45:25 -0700 Subject: Re: [Ietf-behave] RE: [Sip] outbound-keepalive question From: Tim Thome To: Message-ID: Thread-Topic: [Ietf-behave] RE: [Sip] outbound-keepalive question Thread-Index: AcaKo5PDMY7VrLPWQ5+t9GkixdFp1QAG63ZgAAH3WdI= In-Reply-To: <042601c68ac0$04657630$95ab6b80@amer.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: 'Cullen Jennings' , Dan Wing , ietf-behave@list.sipfoundry.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 6/7/06 10:54 PM, "Dan Wing" wrote: >> My question's true intent is: can we send Binding Requests >> using TCP or TLS in Outbound. Because rfc3489bis-03 doesn't say >> "Binding Requests, sent over TCP or TLS" and it only says " Binding >> Requests, sent over UDP". > > Consensus at the Dallas IETF SIP meeting was to send STUN over TCP > connections, too. . -behave-rfc3489bis- hasn't been updated since that > meeting. Concur... Tim _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 08 02:59:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoESF-0007iD-51; Thu, 08 Jun 2006 02:57:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoESE-0007i8-7t for sip@ietf.org; Thu, 08 Jun 2006 02:57:18 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoESC-0000IC-VB for sip@ietf.org; Thu, 08 Jun 2006 02:57:18 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0J0J00C014O43F@siemenscomms.co.uk> for sip@ietf.org; Thu, 08 Jun 2006 07:57:41 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J0J00B2I4O43X@siemenscomms.co.uk>; Thu, 08 Jun 2006 07:57:40 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 08 Jun 2006 07:57:15 +0100 Content-return: allowed Date: Thu, 08 Jun 2006 07:57:12 +0100 From: "Elwell, John" Subject: RE: [Sip] Connected-identity and changing the To header field ina response To: "Jesske, R" , fluffy@cisco.com, drage@lucent.com Message-id: <50B1CBA96870A34799A506B2313F2667091C2671@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Roland, You wrote: > The "additional connected identity" is the identity where the > user may be reached. In the PTSN world it is the line where > the Black Phone is on. In SIP it should be an identity where > the user may be reached. [JRE] Expressed this way it sounds like a contact URI for a particular UA that is currently registered on behalf of the user. I don't think this is the intention - I think it should be the identity of the particular user (as opposed to the 'subscriber' used for billing purposes). John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 08 11:55:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoMoo-0007v8-O7; Thu, 08 Jun 2006 11:53:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoMom-0007v2-NX for sip@ietf.org; Thu, 08 Jun 2006 11:53:08 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoMom-0004zo-CT for sip@ietf.org; Thu, 08 Jun 2006 11:53:08 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k58FqvAM028688; Thu, 8 Jun 2006 10:53:00 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 8 Jun 2006 16:52:57 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0132CB55B@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Paul Kyzivat , David R Oran Subject: RE: AW: AW: [Sip] Connected-identity and changing the To header f ield ina response Date: Thu, 8 Jun 2006 16:52:55 +0100 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: 8f374d0786b25a451ef87d82c076f593 Cc: "Jesske, R" , fluffy@cisco.com, sip@ietf.org, "Elwell, John" , roland.jesske@web.de, christer.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org In my view, yes. Keith > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 07 June 2006 16:41 > To: David R Oran > Cc: Jesske, R; fluffy@cisco.com; sip@ietf.org; Elwell, John; > roland.jesske@web.de; christer.holmberg@ericsson.com > Subject: Re: AW: AW: [Sip] Connected-identity and changing > the To header > f ield ina response > > > What I am starting to discern here is a desire for multiple > identities > in the same message that are asserted by different authorities. > P-Asserted-Identity clearly can't do that. I guess there potentially > could be multiple instances of sip identity, though the logistics of > getting that asserted could be difficult. It has been suggested here > that P-Asserted-ID and sip identity could be used together to provide > two identities. > > In any case, the value proposition is different if the multiple > identities are all authenticated to the satisfaction of the > recipient, > rather than one of them being untrustworthy. > > So, am I right in thinking the goal is for multiple identities, > authenticated by different parties? > > Thanks, > Paul > > David R Oran wrote: > > > > On Jun 6, 2006, at 3:17 PM, Elwell, John wrote: > > > >> The requirements have indeed been described in the > tispan-requirements > >> draft, but clearly there is still some misunderstanding. > Let me try to > >> shed > >> some light, although my background is enterprise rather > than carrier > >> and I > >> don't pretend to understand all practices of PSTN or NGN. > >> > >> A PSTN carries two identities in each direction - one that has been > >> "authenticated" or "screened" by the PSTN and one that has > been received > >> from outside the PSTN and has not been screened. The first type of > >> identity > >> is used for billing, authorisation etc. within the PSTN, > and may also be > >> delivered to the customer premises equipment. The second type of > >> identity is > >> used only for delivery to the customer premises equipment. > What the > >> customer > >> premises equipment does with the two types of identities > is not really > >> specified, but I think enterprise networks (e.g., based on > QSIG) would > >> normally use only the first type of identity for passing > through the > >> enterprise network to the end user. > >> > >> I believe TISPAN has ambitions to support these two types > of identity in > >> NGN, so this leads to the question how to carry the two > identities in > >> SIP. > >> > >> For the INVITE request, the first caller identity is carried in the > >> P-Asserted-Identity header, the first node in the NGN having > >> authenticated > >> the source of the request by some means (e.g., through the > certificate > >> supplied during TLS handshake). The second caller identity > is carried > >> in the > >> From header. Obviously the latter is open to falsification unless > >> supported > >> by an Identity header. With the Identity header, the second caller > >> identity > >> would be far more useful to the destination customer > premises equipment. > >> > >> For the reverse direction, the first callee identity is > carried in the > >> P-Asserted-Identity header, I believe. There are fewer > authentication > >> options, but I guess TLS-based authentication is still a > possibility. > >> So the > >> question is how to supply the second callee identity. > >> > >> Option 1. Modify the To header in the INVITE response. > There have been > >> objections to this. Also it would not be authenticated, so > it would > >> not be > >> nearly as useful as the second identity in the request, > which can be > >> authenticated by the Identity header. > >> > >> Option 2. Use the Reply-To header or some new header in the INVITE > >> response. > >> The objections concerning modifying the To header go away, > but again it > >> would not be authenticated, so it would not be nearly as > useful as the > >> second identity in the request. > >> > >> Option 3. Use the From header in conjunction with the > Identity header > >> in a > >> request in the reverse direction, as specified in the > Connected-Identity > >> draft. This seems to solve the problem, except that it may make > >> interworking > >> with PSTN signalling more difficult since PSTN expects the second > >> identity > >> in the "answer" message. If a solution to this signalling > interworking > >> can > >> be found, I think option 3 would clearly be the best solution. > >> > > Option 4: Use a Body, since this is strictly end-to-end and various > > forms of connected identity may be useful. > > > >> John > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 08 12:03:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoMx8-0004aO-Tn; Thu, 08 Jun 2006 12:01:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoMx7-0004YV-7i for sip@ietf.org; Thu, 08 Jun 2006 12:01:45 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoMx5-0006D3-V9 for sip@ietf.org; Thu, 08 Jun 2006 12:01:45 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k58G1f4F010486; Thu, 8 Jun 2006 11:01:42 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 8 Jun 2006 17:01:41 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0132CB563@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Cullen Jennings , "Drage, Keith (Keith)" Subject: RE: [Sip] Connected-identity and changing the To header field ina response Date: Thu, 8 Jun 2006 17:01:39 +0100 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: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: "'Jesske, R'" , "'sip@ietf.org'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Note that the ISDN specifications do not explicitly say one of these is a billing identitifier or another is a dial-back number, this is just an example of the uses that these numbers may be appropriate for. If we try to enumerate these uses in the SIP equivalents, then we are probably going to end up in trouble (due to no one being able to agree). I suspect that the usage will have to remain: - if Bob tells me Alice is really Alice, then I will trust that for purposes 1 and 2. - if Charles tells me Alice is really Alice, then I will trust that for purposes 3 and 4. where 1, 2, 3 and 4 are not defined. regards Keith > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: 07 June 2006 19:45 > To: Drage, Keith (Keith) > Cc: 'Jesske, R'; 'sip@ietf.org' > Subject: Re: [Sip] Connected-identity and changing the To header field > ina response > > > > On Jun 7, 2006, at 6:09 AM, Drage, Keith (Keith) wrote: > > > Neither identity is clearly wrong. This issue is that the > assertion > > of each identity may be right for some purposes, but not the best > > for others. The public network asserted identity works fine for > > charging purposes, and allocation of public network services in > > accordance with the subscriber's wishes, but is useless as a dial > > back number. For the enterprise network asserted identity, the > > opposite applies. > > Ok, that makes sense. If the requirements are we need an billing > identifier and an number where the user (not I said user not device) > may be reached we can try to suggest work on something. If the > requirement is where the devices (not the user) may be reached we > could work on that too. I did not get this out of the requirement > document. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 08 12:03:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoMxU-0005hM-6H; Thu, 08 Jun 2006 12:02:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoMxS-0005Tt-0G for sip@ietf.org; Thu, 08 Jun 2006 12:02:06 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoMxR-0006KF-Uc for sip@ietf.org; Thu, 08 Jun 2006 12:02:05 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoMr4-0002JO-40 for sip@ietf.org; Thu, 08 Jun 2006 11:55:33 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 08 Jun 2006 08:55:30 -0700 X-IronPort-AV: i="4.05,220,1146466800"; d="scan'208"; a="430265612:sNHT32380688" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k58FtT4O012792 for ; Thu, 8 Jun 2006 08:55:29 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k58FtSku005088 for ; Thu, 8 Jun 2006 11:55:29 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 11:55:28 -0400 Received: from [192.168.1.101] ([10.86.240.84]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 11:55:28 -0400 Message-ID: <44884870.3060500@cisco.com> Date: Thu, 08 Jun 2006 11:55:28 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David R Oran Subject: Re: [Sip] ISSUE 2 in Hitchhikers guide to SIP: What constitutes Core SIP References: <445F9624.6010401@cisco.com> <68FF84A8-A6F9-4BE6-92C8-720F9B57525D@cisco.com> In-Reply-To: <68FF84A8-A6F9-4BE6-92C8-720F9B57525D@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jun 2006 15:55:28.0716 (UTC) FILETIME=[F6C198C0:01C68B13] DKIM-Signature: a=rsa-sha1; q=dns; l=1901; t=1149782129; x=1150646129; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20ISSUE=202=20in=20Hitchhikers=20guide=20to=20SIP=3A=20Wha t=20constitutes=20Core=0A=20SIP; X=v=3Dcisco.com=3B=20h=3DM2x93CNrwKRgy1BJ3P2alGDJ0E8=3D; b=XWAVLvTS9nRsntBdQHS17c6sisBWoRPR8aunJd3Bak+BfbGMUC8cv01mINHPoMt7epg3abtS Bd7eKJ+xeV2U0LAYLzJk2nrsqky1GD3DcD694KFWh2X+0Ov4DpwXzm+g; Authentication-Results: sj-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org old thread, but the -00 deadline is approaching and I want to get this one submitted. Comments inline: David R Oran wrote: > From the peanut gallery: > > Rather than suck everything that touches SIP into its gravity well > (TLS, DNS) Those are clearly out of scope. > or conversely leave something out that you really need in > order to understand the unified field theory of SIP, let me suggest a > compromise: where there is a convenient grouping of things independent > of SIP itself, introduce a level of indirection. Then let somebody else > write a specification for that area. I think that makes sense for things like enum, RTP, and so on. Indeed I think Cullen suggested it would be good for other working groups to do this too, and to have an NAI-level document that ties it all together. The trouble I'm running into is that, of all of these RAI specs, the SDP in particular is the most tightly coupled to SIP, and hard to separate. I think most folks believe that SDP and rfc3264 are part of the 'sip suite' of specifications. > > One obvious candidate here is to pull out everything having to do with > NAT traversal (STUN, ICE, RFC3605, etc) and let somebody write that up > separately. Well, we more or less have done that with the nat considerations spec, whose purpose is exactly this. But the hitchhikers guide is different, its an enumeration rather than a cookbook. So, my thinking is still to include the SDP stuff as I proposed into the hitchhikers guide. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 08 12:41:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoNYC-0000Jl-9G; Thu, 08 Jun 2006 12:40:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoNY9-0000JQ-Ty for sip@ietf.org; Thu, 08 Jun 2006 12:40:01 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoMxR-0006Hr-VP for sip@ietf.org; Thu, 08 Jun 2006 12:02:05 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoMqy-0002J9-UL for sip@ietf.org; Thu, 08 Jun 2006 11:55:28 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 6FD096C023; Thu, 8 Jun 2006 11:55:24 -0400 (EDT) Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt From: Scott Lawrence To: Cullen Jennings In-Reply-To: <19B7EC33-5163-48FB-A22F-7776BFCCB52F@cisco.com> References: <475FF955A05DD411980D00508B6D5FB00C2908F0@en0033exch001u.uk.lucent.com> <19B7EC33-5163-48FB-A22F-7776BFCCB52F@cisco.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Thu, 08 Jun 2006 11:12:20 -0400 Message-Id: <1149779540.4721.19.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: sip@ietf.org, "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Wed, 2006-06-07 at 07:34 -0700, Cullen Jennings wrote: > I think it still has at least one serious question open - that being > does it help or harm? Or more generally, does it help more than it harms? Diagnosing bad routing can be a real pain - can you imagine running a network without traceroute? > The example in the draft, each via is about 87 octets and imagine it > had 70 hops or so. This would be a real big response - too big for a > UDP packet most likely. To follow the congestion safety, I don't know > how to deal with this. If seems that in many systems, the resource > would simply be dropped because it is too large. It seems like not > getting any response would be far worse than getting getting a > response that did not have the debugging information. In experiments at SIPit we found that all the proxies tested clamped the hop limit to 20 (no one knew why this value was apparently independently chosen by all of them - it was quite a surprise), so it does not seem likely that anything is going to get to 70 hops (why was such a large value chosen - it seems wildly unlikely to me that it would ever be needed in a scenario that results in success). There is advice in the draft on how to select Vias to be returned if want to limit the size of the response (which might be dependent on the transport). Are you suggesting that something stronger is needed? -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.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 Jun 08 13:06:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoNwT-0006wa-TD; Thu, 08 Jun 2006 13:05:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoNwS-0006wV-On for sip@ietf.org; Thu, 08 Jun 2006 13:05:08 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoMxS-0006KF-0h for sip@ietf.org; Thu, 08 Jun 2006 12:02:06 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoMqz-0002JB-LA for sip@ietf.org; Thu, 08 Jun 2006 11:55:27 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id EFBEF6C021; Thu, 8 Jun 2006 11:55:24 -0400 (EDT) Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt From: Scott Lawrence To: "Drage, Keith (Keith)" In-Reply-To: <475FF955A05DD411980D00508B6D5FB0130F705F@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB0130F705F@en0033exch001u.uk.lucent.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Thu, 08 Jun 2006 11:44:20 -0400 Message-Id: <1149781460.4721.36.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: sip@ietf.org, ahawrylyshen@ditechnetworks.com, RjS@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: , Errors-To: sip-bounces@ietf.org On Wed, 2006-06-07 at 11:39 +0100, Drage, Keith (Keith) wrote: > I worked through this document and identified the following points for consideration. Thanks. > Technical > --------- > > 1) Section 2.2, final indented paragraph. Firstly, can we emphasise > that this applies to any method, e.g. by inserting the words: "Any 483 > response, to any method, SHOULD..." Secondly, if we are going to use > SHOULD here, can we insert some informative text relating to why it is > only a SHOULD and not a MUST, and therefore giving the reader the > understanding of why it does not always apply. Why do you think that the method needs to be mentioned? I don't see any ambiguity in "any 483 response". > 2) Section 2.2 and elsewhere, I am not convinced that the use of the > Warning header is consistent with RFC 3261. The clear implication of > RFC 3261 is that Warning headers relate only to the session > description contained in the request. It didn't seem worth the trouble to define a new header, or to require some multipart body just to identify the last server - I'm open to suggestions. It seems a valuable part of the diagnostic information. > 3) Section 2.4. The 3rd (final) paragraph clearly indicates this as a > normative requirement, with SHOULD strength. The second paragraph > contains a similar requirement, but no keyword. Either rephrase to > include a "SHOULD", or change the "It is suggested..." to It is > RECOMMENDED...". Good catch - I'll make that change. > NITS > ---- > > a) Wherever we indicate "483 error response" in the text, can we > follow the style of RFC 3261 and change it to "483 (Too Many Hops) > response code"? I started to make that change, and it seemed to me that this got pretty repetitive if done everywhere. Given that the entire draft is on this one response, I'm not sure this actually improves the clarity. > b) Instead of "sender" and "receiver" (relating to a request) can we > use RFC 3261 terminology "UAC" and "UAS". Occurences at least in the > abstract (where they will need expansion) and in the introduction"? > > c) In the Abstract delete the paragraph relating to "Comments are > solicited..." It's an I-D after all. Yes, that should have come out in this version... > d) In the examples, I note they all use "pingtel.com". Should these be > changed to a more usual example URI. > regards They were originally actual messages copied verbatim from traces, but yes, in the final draft they should be changed... done. > e) In section 2.2, Can we make the two sets of bullets more apparent? I think so. > f) In section 2.2, 1st bullet of 1st bullet list, the reference to RFC > 3261 needs to have the reference identifier. Done. > g) When referring to the "Max Forwards value" use "Max Forwards header > field value", i.e. consistent with RFC 3261 usage. Done. Thanks for the careful reading. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.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 Jun 08 13:31:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoOKe-0002yL-BZ; Thu, 08 Jun 2006 13:30:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoOKc-0002yG-PS for sip@ietf.org; Thu, 08 Jun 2006 13:30:06 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoOKb-0000iI-FG for sip@ietf.org; Thu, 08 Jun 2006 13:30:06 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k58HU0gG029877; Thu, 8 Jun 2006 12:30:01 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 8 Jun 2006 18:30:00 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0132CB58A@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Scott Lawrence Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt Date: Thu, 8 Jun 2006 18:29:57 +0100 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: 31247fb3be228bb596db9127becad0bc Cc: sip@ietf.org, ahawrylyshen@ditechnetworks.com, RjS@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: , Errors-To: sip-bounces@ietf.org See below. I've retained only the points inviting further discussion. regards Keith > -----Original Message----- > From: Scott Lawrence [mailto:slawrence@pingtel.com] > Sent: 08 June 2006 16:44 > To: Drage, Keith (Keith) > Cc: sip@ietf.org; ahawrylyshen@ditechnetworks.com; RjS@nostrum.com > Subject: RE: [Sip] I-D > ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt > > > On Wed, 2006-06-07 at 11:39 +0100, Drage, Keith (Keith) wrote: > > I worked through this document and identified the following > points for consideration. > > Thanks. > > > Technical > > --------- > > > > 1) Section 2.2, final indented paragraph. Firstly, can we emphasise > > that this applies to any method, e.g. by inserting the > words: "Any 483 > > response, to any method, SHOULD..." Secondly, if we are going to use > > SHOULD here, can we insert some informative text relating > to why it is > > only a SHOULD and not a MUST, and therefore giving the reader the > > understanding of why it does not always apply. > > Why do you think that the method needs to be mentioned? I > don't see any > ambiguity in "any 483 response". > Because I read the document twice before I came to the conclusion that the "any" meant "any method" as well as "any point in time that you receive". As all the examples in the document relate to the INVITE request, it seemed to me useful to emphasise that it was more comprehensive. In other words, it seemed to me that there was scope for sloppy reader to get it wrong. > > 2) Section 2.2 and elsewhere, I am not convinced that the > use of the > > Warning header is consistent with RFC 3261. The clear implication of > > RFC 3261 is that Warning headers relate only to the session > > description contained in the request. > > It didn't seem worth the trouble to define a new header, or to require > some multipart body just to identify the last server - I'm open to > suggestions. It seems a valuable part of the diagnostic information. > Well if we continue to use the Warning header, this would be another update of RFC 3261 to extend the usage of Warning, at least in my understanding, and that would need to be defined. Out of interest, what harm would occur by adding it to the Server header? Alternatively, could the Contact header be allowed in a 483 response mean this? > > NITS > > ---- > > > > a) Wherever we indicate "483 error response" in the text, can we > > follow the style of RFC 3261 and change it to "483 (Too Many Hops) > > response code"? > > I started to make that change, and it seemed to me that this > got pretty > repetitive if done everywhere. Given that the entire draft is on this > one response, I'm not sure this actually improves the clarity. > The clarity improvement is I agree not substantial, but I find that it helps if multiple documents present the same information in the same style. > -- > Scott Lawrence tel:+1-781-938-5306;ext=162 or > sip:slawrence@pingtel.com > sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 08 14:05:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoOrP-0005No-97; Thu, 08 Jun 2006 14:03:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoOrN-0005Nj-73 for sip@ietf.org; Thu, 08 Jun 2006 14:03:57 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoOrK-0007Ec-Qk for sip@ietf.org; Thu, 08 Jun 2006 14:03:57 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 3F33D6C017; Thu, 8 Jun 2006 14:03:54 -0400 (EDT) Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt From: Scott Lawrence To: "Drage, Keith (Keith)" In-Reply-To: <475FF955A05DD411980D00508B6D5FB0132CB58A@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB0132CB58A@en0033exch001u.uk.lucent.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Thu, 08 Jun 2006 14:03:53 -0400 Message-Id: <1149789834.4721.108.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: sip@ietf.org, ahawrylyshen@ditechnetworks.com, RjS@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: , Errors-To: sip-bounces@ietf.org On Thu, 2006-06-08 at 18:29 +0100, Drage, Keith (Keith) wrote: > See below. > > I've retained only the points inviting further discussion. > > regards > > Keith > > > -----Original Message----- > > From: Scott Lawrence [mailto:slawrence@pingtel.com] > > Sent: 08 June 2006 16:44 > > To: Drage, Keith (Keith) > > Cc: sip@ietf.org; ahawrylyshen@ditechnetworks.com; RjS@nostrum.com > > Subject: RE: [Sip] I-D > > ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt > > > > > > On Wed, 2006-06-07 at 11:39 +0100, Drage, Keith (Keith) wrote: > > > I worked through this document and identified the following > > points for consideration. > > > > Thanks. > > > > > Technical > > > --------- > > > > > > 1) Section 2.2, final indented paragraph. Firstly, can we emphasise > > > that this applies to any method, e.g. by inserting the > > words: "Any 483 > > > response, to any method, SHOULD..." Secondly, if we are going to use > > > SHOULD here, can we insert some informative text relating > > to why it is > > > only a SHOULD and not a MUST, and therefore giving the reader the > > > understanding of why it does not always apply. > > > > Why do you think that the method needs to be mentioned? I > > don't see any > > ambiguity in "any 483 response". > > > Because I read the document twice before I came to the conclusion that > the "any" meant "any method" as well as "any point in time that you > receive". As all the examples in the document relate to the INVITE > request, it seemed to me useful to emphasise that it was more > comprehensive. In other words, it seemed to me that there was scope > for sloppy reader to get it wrong. Hmmm... well, how about changing: Any 483 response SHOULD be constructed with ... to Whenever a UAS constructs a 483 (Too Many Hops) response to any request whose Max-Forwards header field value has reached zero, the response SHOULD be constructed with ... This reminds me that I didn't address the issue of using 'UAC' and 'UAS' where the current text uses 'sender' and 'receiver'; I'll look at that elsewhere too... > > > 2) Section 2.2 and elsewhere, I am not convinced that the > > use of the > > > Warning header is consistent with RFC 3261. The clear implication of > > > RFC 3261 is that Warning headers relate only to the session > > > description contained in the request. > > > > It didn't seem worth the trouble to define a new header, or to require > > some multipart body just to identify the last server - I'm open to > > suggestions. It seems a valuable part of the diagnostic information. > > > Well if we continue to use the Warning header, this would be another > update of RFC 3261 to extend the usage of Warning, at least in my > understanding, and that would need to be defined. RFC 3261, section 20.43 Warning says: The Warning header field is used to carry additional information about the status of a response. and The currently-defined "warn-code"s are listed below, with a recommended warn-text in English and a description of their meaning. These warnings describe failures induced by the session description. The first digit of warning codes beginning with "3" indicates warnings specific to SIP. Warnings 300 through 329 are reserved for indicating problems with keywords in the session description, 330 through 339 are warnings related to basic network services requested in the session description, 370 through 379 are warnings related to quantitative QoS parameters requested in the session description, and 390 through 399 are miscellaneous warnings that do not fall into one of the above categories. it seems to me that this already explicitly allows for usages other than session description errors by allowing "miscellaneous warnings that do not fall into one of the above categories". Arguably, this could call for actually registering a code in the 39x range; if the WG thinks that's better, I can add an IANA Considerations section to do that. > Out of interest, what harm would occur by adding it to the Server > header? Alternatively, could the Contact header be allowed in a 483 > response mean this? The Server header is defined as providing information about the software of the UAS, and as such the syntax doesn't allow for a field that is identifiably the address or host name. I'm concerned that including a Contact is more likely to confuse implementations that don't expect to see them in an error response (especially since it is often going to be coming from a proxy). > > > NITS > > > ---- > > > > > > a) Wherever we indicate "483 error response" in the text, can we > > > follow the style of RFC 3261 and change it to "483 (Too Many Hops) > > > response code"? > > > > I started to make that change, and it seemed to me that this > > got pretty > > repetitive if done everywhere. Given that the entire draft is on this > > one response, I'm not sure this actually improves the clarity. > > > The clarity improvement is I agree not substantial, but I find that it > helps if multiple documents present the same information in the same > style. It probably should be done that way in at least some places (as in my suggested text above), but I think it's actually detrimental to do it where the code appears 3 times in the same paragraph... -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.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 Jun 08 14:43:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoPRS-0006SK-KW; Thu, 08 Jun 2006 14:41:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoPRR-0006SF-DV for sip@ietf.org; Thu, 08 Jun 2006 14:41:13 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoPRP-0000RK-2F for sip@ietf.org; Thu, 08 Jun 2006 14:41:13 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k58If5e01324; Thu, 8 Jun 2006 14:41:06 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] What to do with SIP SAML draft Date: Thu, 8 Jun 2006 13:40:53 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0A60F209@zrc2hxm0.corp.nortel.com> In-Reply-To: <28F05913385EAC43AF019413F674A0170DE0C801@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] What to do with SIP SAML draft Thread-Index: AcaKXGHgnsFj8MVHR7KDMRBcWsnjPQAAvoHAADLskpA= From: "Francois Audet" To: "Dolly, Martin C, ALABS" , "Cullen Jennings" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: Sip IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Same here. > -----Original Message----- > From: Dolly, Martin C, ALABS [mailto:mdolly@att.com]=20 > Sent: Wednesday, June 07, 2006 11:25 > To: Cullen Jennings; Dean Willis > Cc: Sip IETF > Subject: RE: [Sip] What to do with SIP SAML draft >=20 >=20 > I support adopting the draft as a WG item. With next steps=20 > focusing on use cases. >=20 > Cheers, Martin=20 >=20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: Wednesday, June 07, 2006 1:43 PM > To: Dean Willis > Cc: Sip IETF > Subject: Re: [Sip] What to do with SIP SAML draft >=20 >=20 > It seems like SAML is likely to end up as useful (and this document =20 > will help us use it). However, we don't have very many concrete =20 > things defined yet of how we would use it or what all the things are =20 > that we would need it to do. It has moments of feeling like a =20 > technology looking for a problem. >=20 > I think that tends to make me thing we should keep working on=20 > it, and =20 > perhaps if we want to adopt it, change the milestone to specific =20 > problems we would solve with it. >=20 >=20 > Cullen >=20 >=20 > On Jun 6, 2006, at 10:56 AM, Dean Willis wrote: >=20 > > > > Our current charter and slightly-stale milestones include a > > deliverable for SAML: > > > > Jul 2006 -- Using SAML for SIP (PS) > > > > > > At the IETF 65, we discussed the Tschofenig draft, currently > > available as: > > > > http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-05.txt > > > > We didn't have a firm consensus in the room for what to do with > > this, so It'd like to discuss it now. > > > > > > Our options include: > > > > 1) Adopt this draft as a WG document and keep working on it. > > > > 2) Decide we don't need to solve the problem just yet and abandon =20 > > the milestone. > > > > 3) Let Hannes and team keep working on it until we decide it has =20 > > reached critical mass, and keep slipping the milestone along. > > > > 4) Do something entirely different. > > > > > > So, what do you people think? > > > > -- > > Dean > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip >=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 >=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 Jun 08 15:08:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoPqI-0002dP-SY; Thu, 08 Jun 2006 15:06:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoPqI-0002dK-09 for sip@ietf.org; Thu, 08 Jun 2006 15:06:54 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoPqG-0003LF-NM for sip@ietf.org; Thu, 08 Jun 2006 15:06:53 -0400 X-IronPort-AV: i="4.05,221,1146456000"; d="scan'208"; a="33873692:sNHT41798232" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Status of content indirection mechanism draft Date: Thu, 8 Jun 2006 15:06:46 -0400 Message-ID: <330A23D8336C0346B5C1A5BB196666470303A7C8@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Status of content indirection mechanism draft Thread-Index: AcZ/kOK6FyiC+ivIQ72BHJPe7LCNmALnMOzgAABAyDA= From: "Burger, Eric" To: "Drage, Keith \(Keith\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org RFC 4483. -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 Sent: Wednesday, May 24, 2006 8:17 PM To: 'Martin.Hynar@tietoenator.com'; 'sip@ietf.org' Subject: RE: [Sip] Status of content indirection mechanism draft It is currently in AUTH48 and we are just awaiting one author to confirm OK. He is being chased (particularly as the publication of another RFC is being held up by this one). Expect end of the month at the moment. Note that one a document is is the editor's queue, it cannot by definition expire. It is still in the drafts folder, and you can ignore the date on the cover page. The editor's queue can be viewed here http://www.rfc-editor.org/queue.html regards Keith > -----Original Message----- > From: Martin.Hynar@tietoenator.com=20 > [mailto:Martin.Hynar@tietoenator.com] > Sent: 24 May 2006 08:28 > To: sip@ietf.org > Subject: [Sip] Status of content indirection mechanism draft >=20 >=20 > Hi all, >=20 > I've one simple question regarding status of > draft-ietf-sip-content-indirect-mech-05. It has expired a year ago and > it is still in rfc editor queue. Is there planned some action=20 > with that > draft (rfc release)? >=20 > br, Martin >=20 > Martin Hynar > Software Specialist >=20 > TietoEnator > Czech Software Center > Phone: +420 599 096 022 > E-mail: Martin.Hynar@TietoEnator.com >=20 > Vystavni 292/13 > CZ-709 16 Ostrava >=20 > www.tietoenator.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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 08 15:25:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoQ6C-0001NM-DG; Thu, 08 Jun 2006 15:23:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoQ6B-0001N1-68; Thu, 08 Jun 2006 15:23:19 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoQ69-0004Zk-GZ; Thu, 08 Jun 2006 15:23:19 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 08 Jun 2006 12:23:16 -0700 X-IronPort-AV: i="4.05,221,1146466800"; d="scan'208"; a="291661727:sNHT38200620" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k58JNG1w032185; Thu, 8 Jun 2006 12:23:16 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k58JNEcR009751; Thu, 8 Jun 2006 12:23:16 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 15:23:15 -0400 Received: from [192.168.1.101] ([10.86.240.84]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 15:23:15 -0400 Message-ID: <44887921.20302@cisco.com> Date: Thu, 08 Jun 2006 15:23:13 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Internet-Drafts@ietf.org Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jun 2006 19:23:15.0459 (UTC) FILETIME=[FD839D30:01C68B30] DKIM-Signature: a=rsa-sha1; q=dns; l=6516; t=1149794596; x=1150658596; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20I-D=20ACTION=3Adraft-ietf-sip-hop-limit-diagnostics-02.t xt; X=v=3Dcisco.com=3B=20h=3DbNh0c34VJf6h7+g6FnEK3owlh8o=3D; b=jwCMTincHZFVlAMblNnZM7gOElpgCgYI1NMkADbmxGdaaYkLrrz4FOefrqA3hIQIQYvpLOqI evF6iQnIvp55bw/oz8mwM+pYMZd6nJlnhpkr1pzpD8LCmPJggoE67KxT; Authentication-Results: sj-dkim-8.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: sip@ietf.org, i-d-announce@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Here are some comments on this, broken into major and nits: MAJOR: * Seems like this specification would also be useful in cases of 482 (loop detected as opposed to max-forwards exceeded). Should we expand to include that? * from rfc4485, you need to have sections that more clearly spell out the behavior expected for a UAC, UAS and proxy. * Indeed, I think a UAC needs ot include a message/sipfrag in the Accept header field of a request it sends so that the entity generating the 483 knows that this type is accepted NITS: * expand SIP acronym in title * the document says it 'updates' rfc3261 but its not clear to me it does that; are you saying its doing that because its changing the usage of Warning? * abstract: expand first instance of SIP > . Diagnosing Hop Limit Exceeded Failures > > The SIP protocol imposes a limit on the number of hops a request may expand SIP acronym > When a SIP User > Agent receives a request whose Max-Forwards is zero, it returns a 483 > error response to indicate that the limit was reached. this can happen at a proxy too > The 483 response alone does not provide enough information, for the > sender to determine where the problem lies. extra comma > In the authors > experience, the problem is rarely that the target of the request was Suggest removing 'in the authors experience' - OK to do this in an I-D, but as an RFC its a community document and such terms don't make as much sense. > In practice, there is too little information returned in a 483 > response for it to be of much use as a diagnostic. diagnostic tool > has traversed a series of proxies, the response follows the Vias back > to the requester; in the case of a typical 483 response it can be > difficult to determine even what server the response came from. Its more than difficult; there is nothing in the response which says where it came from. > As an aid to diagnosing problems that result in 483 responses, it > would be useful to know how the failed request arrived at the > rejecting system; both what path it followed to get there, and what > the request looked like when it ran out of hops. I think this is supposed to be a dash and not a semicolon. * I recommend that you move the example in 2.3 to a separate Example section at the end of the draft, consistent with the general way we've been doing our specs with the example in a section at the end > It is suggested in this case that at least all of the Route and Via > headers from the request be returned in the message/sipfrag body. In > the example (Section 2.3), this would at least enable the end user to > determine which proxies were in the routing loop and how the request > arrived there, but not the specific address transformations that > caused the loop. should use SHOULD here * section 3 is good to hear but probably doesn't belong in the final published rfc Thanks, Jonathan R. Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol Working Group of the IETF. > > Title : Diagnostic Responses for SIP Hop Limit Errors > Author(s) : S. Lawrence, et al. > Filename : draft-ietf-sip-hop-limit-diagnostics-02.txt > Pages : 12 > Date : 2006-6-2 > > The SIP protocol imposes a limit on the number of hops a request may > make from a sender to the recipient. When this limit is reached, a > 483 error response is returned. The present form of the 483 response > does not provide enough information for the sender or proxies on the > path to diagnose failures whose symptom is that the hop limit is > reached. This document proposes additional diagnostic information to > be returned in a 483 response. > > Comments are solicited, and should be directed to the SIP working > group list at 'sip@ietf.org'. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-hop-limit-diagnostics-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sip-hop-limit-diagnostics-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sip-hop-limit-diagnostics-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 08 16:17:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoQui-0007Je-2I; Thu, 08 Jun 2006 16:15:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoQug-0007JP-QD for sip@ietf.org; Thu, 08 Jun 2006 16:15:30 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoQue-0005Nu-HN for sip@ietf.org; Thu, 08 Jun 2006 16:15:30 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k58KFPLZ006930; Thu, 8 Jun 2006 15:15:26 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 8 Jun 2006 21:15:25 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0132CB5A0@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Scott Lawrence , Cullen Jennings Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt Date: Thu, 8 Jun 2006 21:15:24 +0100 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: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I guess at the very least we need to ensure that the security considerations details how this is not used as an amplification attack, such that it congests the network. However, do we need more than this? regards Keith > -----Original Message----- > From: Scott Lawrence [mailto:slawrence@pingtel.com] > Sent: 08 June 2006 16:12 > To: Cullen Jennings > Cc: Drage, Keith (Keith); sip@ietf.org > Subject: Re: [Sip] I-D > ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt > > > On Wed, 2006-06-07 at 07:34 -0700, Cullen Jennings wrote: > > I think it still has at least one serious question open - > that being > > does it help or harm? > > Or more generally, does it help more than it harms? Diagnosing bad > routing can be a real pain - can you imagine running a network without > traceroute? > > > The example in the draft, each via is about 87 octets and > imagine it > > had 70 hops or so. This would be a real big response - too > big for a > > UDP packet most likely. To follow the congestion safety, I > don't know > > how to deal with this. If seems that in many systems, the resource > > would simply be dropped because it is too large. It seems like not > > getting any response would be far worse than getting getting a > > response that did not have the debugging information. > > In experiments at SIPit we found that all the proxies tested > clamped the > hop limit to 20 (no one knew why this value was apparently > independently > chosen by all of them - it was quite a surprise), so it does not seem > likely that anything is going to get to 70 hops (why was such a large > value chosen - it seems wildly unlikely to me that it would ever be > needed in a scenario that results in success). > > There is advice in the draft on how to select Vias to be returned if > want to limit the size of the response (which might be > dependent on the > transport). Are you suggesting that something stronger is needed? > > -- > Scott Lawrence tel:+1-781-938-5306;ext=162 or > sip:slawrence@pingtel.com > sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.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 Jun 08 16:30:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoR7K-0002rf-9n; Thu, 08 Jun 2006 16:28:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoR7J-0002pG-9w for sip@ietf.org; Thu, 08 Jun 2006 16:28:33 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoR7I-0005mI-34 for sip@ietf.org; Thu, 08 Jun 2006 16:28:33 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id AEBA16C017; Thu, 8 Jun 2006 16:28:31 -0400 (EDT) Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt From: Scott Lawrence To: "Drage, Keith (Keith)" In-Reply-To: <475FF955A05DD411980D00508B6D5FB0132CB5A0@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB0132CB5A0@en0033exch001u.uk.lucent.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Thu, 08 Jun 2006 16:28:31 -0400 Message-Id: <1149798511.4721.135.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Cullen Jennings , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Thu, 2006-06-08 at 21:15 +0100, Drage, Keith (Keith) wrote: > I guess at the very least we need to ensure that the security > considerations details how this is not used as an amplification > attack, such that it congests the network. I'm not sure what should be said - is there some text that you think is needed? The response message is only going to be slightly larger than the request it is returning (and need not be as large if the returned request is pruned as allowed for). That's not really an amplification (certainly not compared to the forking loop attacks that started this and other threads). -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.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 Jun 08 16:37:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoRDo-0000DQ-1V; Thu, 08 Jun 2006 16:35:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoRDm-0000BY-4F for sip@ietf.org; Thu, 08 Jun 2006 16:35:14 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoRDk-00087O-QW for sip@ietf.org; Thu, 08 Jun 2006 16:35:14 -0400 Received: from [192.168.2.104] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k58KaZMN010509 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 8 Jun 2006 15:36:36 -0500 In-Reply-To: <4.3.2.7.2.20060607220404.019edc98@email.cisco.com> References: <24EAE5D4448B9D4592C6D234CBEBD597054F446F@stntexch03.cis.neustar.com> <24EAE5D4448B9D4592C6D234CBEBD597054F446F@stntexch03.cis.neustar.com> <4.3.2.7.2.20060607220404.019edc98@email.cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] What to do with SIP SAML draft Date: Thu, 8 Jun 2006 15:35:08 -0500 To: "James M. Polk" X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Sip IETF , "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: , Errors-To: sip-bounces@ietf.org On Jun 7, 2006, at 10:07 PM, James M. Polk wrote: > At 09:47 PM 6/7/2006 -0500, Dean Willis wrote: >> Peterson, Jon wrote: >>> Didn't we already have a mailing list "hum" to adopt this as a WG >>> item on 3/26/06? Was that deemed inconclusive by the chairs? >> >> Indeed we did, and the 7 or 8 people who responded were all in >> favor of adopting the draft. Of course, it's 3 months later now, >> and the status of the draft hasn't changed a lot (so at the least >> there's a scheduling issue to resolve), and there's more than 7 or >> 8 people in the working group. >> >> Consider it a recheck for my sanity, which is questionable at best. > > Does this mean our next version of the ID (what was draft- > tschofenig-sip-saml-05.txt) should now be > > draft-ietf-sip-saml-00.txt > > ? > > If so, > > #1 - we need to submit it a week earlier than planned > and > #2 - The WG chairs need to submit a message to the Secretariat that > this draft-sip-...-00 is coming > That was sort of at the root of the question -- I asked if anybody was planning to submit a new -00 draft before cutoff so I could pre- approve, and I didn't hear much back. The current response set (also small) still supports adopting the draft. The AD response seem to indicate support for that position. I've heard no objections and only one suggestion that as postponement might be appropriate, so I'd say we maintain a consensus to adopt, but need to push our delivery milestone out to something like WGLC in November and IESG review in January 2007. Please provide feedback on those dates. Personally, I don't suppose that it matters much which title you use in the next rev, so long as we meet the scheduling and approval constraints appropriate to the title. We can always retitle at the next rev. -- 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 Jun 08 17:02:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoRc0-00085Y-11; Thu, 08 Jun 2006 17:00:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoRbz-00085T-60 for sip@ietf.org; Thu, 08 Jun 2006 17:00:15 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoRbx-00047P-QW for sip@ietf.org; Thu, 08 Jun 2006 17:00:15 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 08 Jun 2006 14:00:13 -0700 X-IronPort-AV: i="4.05,221,1146466800"; d="scan'208"; a="1822338576:sNHT73464616" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k58L0Csb014383; Thu, 8 Jun 2006 14:00:12 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k58L06l4010083; Thu, 8 Jun 2006 14:00:11 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 14:00:11 -0700 Received: from jmpolk-wxp.cisco.com ([10.89.20.20]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 14:00:10 -0700 Message-Id: <4.3.2.7.2.20060608155746.03738680@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 08 Jun 2006 16:00:09 -0500 To: Dean Willis From: "James M. Polk" Subject: Re: [Sip] What to do with SIP SAML draft In-Reply-To: References: <4.3.2.7.2.20060607220404.019edc98@email.cisco.com> <24EAE5D4448B9D4592C6D234CBEBD597054F446F@stntexch03.cis.neustar.com> <24EAE5D4448B9D4592C6D234CBEBD597054F446F@stntexch03.cis.neustar.com> <4.3.2.7.2.20060607220404.019edc98@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 08 Jun 2006 21:00:10.0633 (UTC) FILETIME=[87A0BF90:01C68B3E] DKIM-Signature: a=rsa-sha1; q=dns; l=2382; t=1149800413; x=1150664413; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Sip]=20What=20to=20do=20with=20SIP=20SAML=20draft; X=v=3Dcisco.com=3B=20h=3Dq60nMnky6rq8Zv35J0ptB+WNxZo=3D; b=pBvTBud3NQBtp2R2S1LkVQs5tcDjOKL89PebOvN85W9Hir8XzotFB60jauy0dWJvysCqNTCK wzQDDh1Bzd0tWd+Putmndxn1kpBkwGc4Zg8py6cA//MbZLBnXq1pt8ih; Authentication-Results: sj-dkim-1.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Sip IETF , "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: , Errors-To: sip-bounces@ietf.org Dean Thanks I'll suggest this title to my co-authors: draft-ietf-sip-saml-00.txt I agree more needs to be done here At 03:35 PM 6/8/2006 -0500, Dean Willis wrote: >On Jun 7, 2006, at 10:07 PM, James M. Polk wrote: > >>At 09:47 PM 6/7/2006 -0500, Dean Willis wrote: >>>Peterson, Jon wrote: >>>>Didn't we already have a mailing list "hum" to adopt this as a WG >>>>item on 3/26/06? Was that deemed inconclusive by the chairs? >>> >>>Indeed we did, and the 7 or 8 people who responded were all in >>>favor of adopting the draft. Of course, it's 3 months later now, >>>and the status of the draft hasn't changed a lot (so at the least >>>there's a scheduling issue to resolve), and there's more than 7 or >>>8 people in the working group. >>> >>>Consider it a recheck for my sanity, which is questionable at best. >> >>Does this mean our next version of the ID (what was draft- >>tschofenig-sip-saml-05.txt) should now be >> >> draft-ietf-sip-saml-00.txt >> >>? >> >>If so, >> >>#1 - we need to submit it a week earlier than planned >>and >>#2 - The WG chairs need to submit a message to the Secretariat that >>this draft-sip-...-00 is coming > >That was sort of at the root of the question -- I asked if anybody >was planning to submit a new -00 draft before cutoff so I could pre- >approve, and I didn't hear much back. > >The current response set (also small) still supports adopting the >draft. The AD response seem to indicate support for that position. >I've heard no objections and only one suggestion that as postponement >might be appropriate, so I'd say we maintain a consensus to adopt, >but need to push our delivery milestone out to something like WGLC in >November and IESG review in January 2007. Please provide feedback on >those dates. > >Personally, I don't suppose that it matters much which title you use >in the next rev, so long as we meet the scheduling and approval >constraints appropriate to the title. We can always retitle at the >next rev. > >-- >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 Jun 08 17:05:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoRfO-0004Bp-S0; Thu, 08 Jun 2006 17:03:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoRfN-0004B8-1p; Thu, 08 Jun 2006 17:03:45 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoQvk-0005Qk-D1; Thu, 08 Jun 2006 16:16:36 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoQhp-0006UD-63; Thu, 08 Jun 2006 16:02:15 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 690616C017; Thu, 8 Jun 2006 16:02:12 -0400 (EDT) Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt From: Scott Lawrence To: Jonathan Rosenberg In-Reply-To: <44887921.20302@cisco.com> References: <44887921.20302@cisco.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Thu, 08 Jun 2006 16:02:11 -0400 Message-Id: <1149796932.4721.129.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: sip@ietf.org, Internet-Drafts@ietf.org, i-d-announce@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Thu, 2006-06-08 at 15:23 -0400, Jonathan Rosenberg wrote: > Here are some comments on this, broken into major and nits: > > MAJOR: > > * Seems like this specification would also be useful in cases of 482 > (loop detected as opposed to max-forwards exceeded). Should we expand to > include that? I think that would be a good idea. Are there other errors relevant to message route diagnosis that would also be good? > * from rfc4485, you need to have sections that more clearly spell out > the behavior expected for a UAC, UAS and proxy. I'm not sure I understand what you think is missing. This does not actually define any new header fields, parameters, or body types; it just specifies more clearly how to return useful information using existing mechanisms for an existing error type. > * Indeed, I think a UAC needs ot include a message/sipfrag in the Accept > header field of a request it sends so that the entity generating the 483 > knows that this type is accepted My interpretation is that the Accept header field describes what the UAC wants in a successful response, and is not needed for the (that's why I quoted 3261 in section 2.2 of the draft: RFC 3261 (section 7.4) says: "All responses MAY include a body.". I've been testing this for nearly two years, and have never had a problem with a UA getting this back, except for those that can't assemble fragmented UDP. > NITS: > > * expand SIP acronym in title ok > * the document says it 'updates' rfc3261 but its not clear to me it does > that; are you saying its doing that because its changing the usage of > Warning? No, because it adds a new SHOULD for how to construct the error response. I don't think that it does change Warning. > * abstract: expand first instance of SIP > > > . Diagnosing Hop Limit Exceeded Failures > > > > The SIP protocol imposes a limit on the number of hops a request may > > expand SIP acronym > > > When a SIP User > > Agent receives a request whose Max-Forwards is zero, it returns a 483 > > error response to indicate that the limit was reached. > > this can happen at a proxy too Would "any SIP implementation" be better than "a SIP User Agent"? > > The 483 response alone does not provide enough information, for the > > sender to determine where the problem lies. > > extra comma thx > > In the authors > > experience, the problem is rarely that the target of the request was > > Suggest removing 'in the authors experience' - OK to do this in an I-D, > but as an RFC its a community document and such terms don't make as much > sense. > > In practice, there is too little information returned in a 483 > > response for it to be of much use as a diagnostic. > > diagnostic tool agreed. > > has traversed a series of proxies, the response follows the Vias back > > to the requester; in the case of a typical 483 response it can be > > difficult to determine even what server the response came from. > > Its more than difficult; there is nothing in the response which says > where it came from. > > > As an aid to diagnosing problems that result in 483 responses, it > > would be useful to know how the failed request arrived at the > > rejecting system; both what path it followed to get there, and what > > the request looked like when it ran out of hops. > > I think this is supposed to be a dash and not a semicolon. > > * I recommend that you move the example in 2.3 to a separate Example > section at the end of the draft, consistent with the general way we've > been doing our specs with the example in a section at the end > > > It is suggested in this case that at least all of the Route and Via > > headers from the request be returned in the message/sipfrag body. In > > the example (Section 2.3), this would at least enable the end user to > > determine which proxies were in the routing loop and how the request > > arrived there, but not the specific address transformations that > > caused the loop. > > should use SHOULD here > * section 3 is good to hear but probably doesn't belong in the final > published rfc ok. If that is removed, then just swapping the section on "Pruning Responses" section and "Example" makes the latter last as you suggest... -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.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 Jun 08 17:20:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoRtc-00052U-CV; Thu, 08 Jun 2006 17:18:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoRtb-00051s-Mw for sip@ietf.org; Thu, 08 Jun 2006 17:18:27 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoRta-0005IZ-Fg for sip@ietf.org; Thu, 08 Jun 2006 17:18:27 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k58LIPKb016501 for ; Thu, 8 Jun 2006 16:18:25 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 8 Jun 2006 22:18:24 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0132CB5AC@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org Date: Thu, 8 Jun 2006 22:18:24 +0100 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: ea4ac80f790299f943f0a53be7e1a21a Subject: [Sip] To all SIP authors X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) Now RFC 4485 has made it to the RFC pages http://www.ietf.org/rfc/rfc4485.txt Abstract The Session Initiation Protocol (SIP) is a flexible yet simple tool for establishing interactive communications sessions across the Internet. Part of this flexibility is the ease with which it can be extended. In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions. This document outlines a set of such guidelines for authors of SIP extensions. it is appropriate to remind the authors and editors of all SIP extensions (and that is the major if not entire product of our WG) that these are to be followed. We expect documents to meet these guidelines as early as possible, but all documents should certainly meet these guidelines before WGLC is initiated. So please take the time to read, or reread this document, even if you have 30 SIP extension RFCs already under your belt. regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 09 10:57:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoiON-00077R-Vw; Fri, 09 Jun 2006 10:55:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoiOM-00077H-HR for sip@ietf.org; Fri, 09 Jun 2006 10:55:18 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoiOL-0000mm-66 for sip@ietf.org; Fri, 09 Jun 2006 10:55:18 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 09 Jun 2006 07:55:16 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,224,1146466800"; d="scan'208"; a="29128987:sNHT46555588" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k59EtGno017199; Fri, 9 Jun 2006 10:55:16 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Jun 2006 10:55:16 -0400 Received: from [192.168.1.101] ([10.86.241.56]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Jun 2006 10:55:15 -0400 Message-ID: <44898BD0.7000705@cisco.com> Date: Fri, 09 Jun 2006 10:55:12 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Lawrence Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt References: <44887921.20302@cisco.com> <1149796932.4721.129.camel@localhost.localdomain> In-Reply-To: <1149796932.4721.129.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2006 14:55:15.0785 (UTC) FILETIME=[B7B1D390:01C68BD4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Scott Lawrence wrote: > On Thu, 2006-06-08 at 15:23 -0400, Jonathan Rosenberg wrote: > >>Here are some comments on this, broken into major and nits: >> >>MAJOR: >> >>* Seems like this specification would also be useful in cases of 482 >>(loop detected as opposed to max-forwards exceeded). Should we expand to >>include that? > > > I think that would be a good idea. Are there other errors relevant to > message route diagnosis that would also be good? I would actually argue that, for any non-recoverable error generated by a *proxy*, you might find these useful. In other words, a 407 is excluded, since thats clearly recoverable. But if a proxy generates a 513 (message too large), the diagnostic information would be helpful to figure out what proxy it was that gave you this problem. > > >>* from rfc4485, you need to have sections that more clearly spell out >>the behavior expected for a UAC, UAS and proxy. > > > I'm not sure I understand what you think is missing. This does not > actually define any new header fields, parameters, or body types; it > just specifies more clearly how to return useful information using > existing mechanisms for an existing error type. I understand it doesn't define any new headers or anything, but it does specify new behaviors of SIP entities, and you need to clearly call them out. RFC 4485 recommends a breakdown like this: 1. Proxy Behavior 2. UAC Behavior 3. UAS Behavior I'd advise that the proxy behavior section basically say that you SHOULD include this information in a body, and describe the rules for trimming when its too large, and which header fields to include in the sipfrag. The UAC section should probably talk about Accept header (pending discussion below) and what to do with the body that comes in the response. > > >>* Indeed, I think a UAC needs ot include a message/sipfrag in the Accept >>header field of a request it sends so that the entity generating the 483 >>knows that this type is accepted > > > My interpretation is that the Accept header field describes what the UAC > wants in a successful response, and is not needed for the (that's why I > quoted 3261 in section 2.2 of the draft: > > RFC 3261 (section 7.4) says: "All responses MAY include a body.". > > I've been testing this for nearly two years, and have never had a > problem with a UA getting this back, except for those that can't > assemble fragmented UDP. Hmm, I find no text in either RFC 3261 or 2616 which would indicate whether Accept applies to error responses or not. I don't have a big problem with sending it anyway, but the spec should call out that this would be done regardless of the Accept value and thus the body may not be understood by a UAC. > >>* the document says it 'updates' rfc3261 but its not clear to me it does >>that; are you saying its doing that because its changing the usage of >>Warning? > > > No, because it adds a new SHOULD for how to construct the error > response. I don't think that it does change Warning. I view it as an extension, not an update, but maybe its splitting hairs. >>>When a SIP User >>> Agent receives a request whose Max-Forwards is zero, it returns a 483 >>> error response to indicate that the limit was reached. >> >>this can happen at a proxy too > > > Would "any SIP implementation" be better than "a SIP User Agent"? Server is the appropriate term, as it covers UAC and proxy. >>* section 3 is good to hear but probably doesn't belong in the final >>published rfc > > > ok. If that is removed, then just swapping the section on "Pruning > Responses" section and "Example" makes the latter last as you suggest... > Per above the prunign should go in a section on proxy behavior. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 09 15:50:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FomyB-0002pO-1d; Fri, 09 Jun 2006 15:48:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fomy9-0002mw-Np for sip@ietf.org; Fri, 09 Jun 2006 15:48:33 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fomy8-000363-By for sip@ietf.org; Fri, 09 Jun 2006 15:48:33 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id CCAD56C017; Fri, 9 Jun 2006 15:48:31 -0400 (EDT) Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt From: Scott Lawrence To: Jonathan Rosenberg In-Reply-To: <44898BD0.7000705@cisco.com> References: <44887921.20302@cisco.com> <1149796932.4721.129.camel@localhost.localdomain> <44898BD0.7000705@cisco.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Fri, 09 Jun 2006 15:48:31 -0400 Message-Id: <1149882511.2865.50.camel@sukothai.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) 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: , Errors-To: sip-bounces@ietf.org On Fri, 2006-06-09 at 10:55 -0400, Jonathan Rosenberg wrote: > Scott Lawrence wrote: > > > On Thu, 2006-06-08 at 15:23 -0400, Jonathan Rosenberg wrote: > > > >>MAJOR: > >> > >>* Seems like this specification would also be useful in cases of 482 > >>(loop detected as opposed to max-forwards exceeded). Should we expand to > >>include that? > > > > > > I think that would be a good idea. Are there other errors relevant to > > message route diagnosis that would also be good? > > I would actually argue that, for any non-recoverable error generated by > a *proxy*, you might find these useful. In other words, a 407 is > excluded, since thats clearly recoverable. But if a proxy generates a > 513 (message too large), the diagnostic information would be helpful to > figure out what proxy it was that gave you this problem. I agree. Adding text to that effect will probably add fuel to the issue of how 'Accept' works... see below. > >>* from rfc4485, you need to have sections that more clearly spell out > >>the behavior expected for a UAC, UAS and proxy. > > > > > > I'm not sure I understand what you think is missing. This does not > > actually define any new header fields, parameters, or body types; it > > just specifies more clearly how to return useful information using > > existing mechanisms for an existing error type. > > I understand it doesn't define any new headers or anything, but it does > specify new behaviors of SIP entities, and you need to clearly call them > out. RFC 4485 recommends a breakdown like this: > > 1. Proxy Behavior > > 2. UAC Behavior > > 3. UAS Behavior > > I'd advise that the proxy behavior section basically say that you SHOULD > include this information in a body, and describe the rules for trimming > when its too large, and which header fields to include in the sipfrag. > The UAC section should probably talk about Accept header (pending > discussion below) and what to do with the body that comes in the response. I can certainly rearrange it that way. There have already been enough changes based on the WGLC to justify a respin as soon as the comment rate falls off (I'll do one before the ID cutoff for Montreal in any event at this point). > >>* Indeed, I think a UAC needs ot include a message/sipfrag in the Accept > >>header field of a request it sends so that the entity generating the 483 > >>knows that this type is accepted > > > > > > My interpretation is that the Accept header field describes what the UAC > > wants in a successful response, and is not needed for the (that's why I > > quoted 3261 in section 2.2 of the draft: > > > > RFC 3261 (section 7.4) says: "All responses MAY include a body.". > > > > I've been testing this for nearly two years, and have never had a > > problem with a UA getting this back, except for those that can't > > assemble fragmented UDP. > > Hmm, I find no text in either RFC 3261 or 2616 which would indicate > whether Accept applies to error responses or not. I don't have a big > problem with sending it anyway, but the spec should call out that this > would be done regardless of the Accept value and thus the body may not > be understood by a UAC. I admit that I didn't look hard before writing this draft - my presumption that it is ok came from my HTTP background. I could argue that RFC 2616 (HTTP 1.1) _does_ spell this out (in section 10.4.7 406 Not Acceptable): Note: HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request. In some cases, this may even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of an incoming response to determine if it is acceptable. and that RFC 3261 says, in section 20.1 Accept: The Accept header field follows the syntax defined in [H14.1]. The semantics are also identical, with the exception that if no Accept header field is present, the server SHOULD assume a default value of application/sdp. Whether or not the exception in 3261 invalidates the liberality of 2616 may be controversial. My reading of the discussion I do find on Accept usage in 3261 is all focused on either: how it is used in a request to restrict what is acceptable in a session, or how to reject something and communicate what would have been ok. All of that is focused on UAs, because proxies are explicitly assumed to be agnostic with respect to methods and bodies. I would not have a problem with putting in a section to clarify this point (of course, I'd want to do it with the liberal HTTP-ish interpretation that servers can do whatever they want as long as they understand that it may not work). I feel a wider discussion coming on... if so, I suggest that it get a thread with a title that will draw more eyes... > >>* the document says it 'updates' rfc3261 but its not clear to me it does > >>that; are you saying its doing that because its changing the usage of > >>Warning? > > > > > > No, because it adds a new SHOULD for how to construct the error > > response. I don't think that it does change Warning. > > I view it as an extension, not an update, but maybe its splitting hairs. I'll defer to the process lawyers on this... -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.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 Sat Jun 10 00:29:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fov45-0007qc-5J; Sat, 10 Jun 2006 00:27:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fov41-0007Tg-IB for sip@ietf.org; Sat, 10 Jun 2006 00:27:09 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fov40-0008Ai-AE for sip@ietf.org; Sat, 10 Jun 2006 00:27:09 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 09 Jun 2006 21:27:04 -0700 X-IronPort-AV: i="4.05,225,1146466800"; d="scan'208"; a="1823276813:sNHT31229824" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k5A4R4aL012230; Fri, 9 Jun 2006 21:27:04 -0700 Received: from [10.0.1.7] (sjc-vpn2-505.cisco.com [10.21.113.249]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5A4R1cN000751; Fri, 9 Jun 2006 21:27:04 -0700 (PDT) In-Reply-To: <44898BD0.7000705@cisco.com> References: <44887921.20302@cisco.com> <1149796932.4721.129.camel@localhost.localdomain> <44898BD0.7000705@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <26E13ED4-1582-4CB2-B74E-F5E0985F9810@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt Date: Fri, 9 Jun 2006 21:18:08 -0700 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=489; t=1149913624; x=1150777624; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20I-D=20ACTION=3Adraft-ietf-sip-hop-limit-diagnostics-02.t xt; X=v=3Dcisco.com=3B=20h=3DuuoBsEgzdw6+9X+Y6yGlgJ8d2Es=3D; b=2qnKQfM8zwNLcJvZ1zv3HWMe+aQKuf8gVqLKnS8txk02mmwVSdrik8nkIAUS1wyPd3JzCayL 7EvSv3+X9uq9v4Kveou92WJFiRuIuMxvtn9pihjKrAeqnrQOMj9RU7GV; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 9, 2006, at 7:55 AM, Jonathan Rosenberg wrote: > >>> * the document says it 'updates' rfc3261 but its not clear to me >>> it does that; are you saying its doing that because its changing >>> the usage of Warning? >> No, because it adds a new SHOULD for how to construct the error >> response. I don't think that it does change Warning. > > I view it as an extension, not an update, but maybe its splitting > hairs. I think it is an extention not an update. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 10 00:29:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fov41-0007U5-NA; Sat, 10 Jun 2006 00:27:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fov40-0007PE-PC for sip@ietf.org; Sat, 10 Jun 2006 00:27:08 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fov40-0008Af-4m for sip@ietf.org; Sat, 10 Jun 2006 00:27:08 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 09 Jun 2006 21:27:04 -0700 X-IronPort-AV: i="4.05,225,1146466800"; d="scan'208"; a="1823276808:sNHT35266672" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k5A4R35Q012226; Fri, 9 Jun 2006 21:27:03 -0700 Received: from [10.0.1.7] (sjc-vpn2-505.cisco.com [10.21.113.249]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5A4R1cL000751; Fri, 9 Jun 2006 21:27:02 -0700 (PDT) In-Reply-To: <024601c688e0$19d996e0$640fa8c0@cis.neustar.com> References: <024601c688e0$19d996e0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <06DBCAA6-F8BD-4394-B67C-51532346CD34@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] RE: [Geopriv] Explicit Indication of Location Object Consumer Date: Fri, 9 Jun 2006 21:07:53 -0700 To: Brian Rosen X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=8993; t=1149913623; x=1150777623; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20RE=3A=20[Geopriv]=20Explicit=20Indication=20of=20Locatio n=20Object=20Consumer; X=v=3Dcisco.com=3B=20h=3DFGNAQzUbi3WubFapcf3Rs4g5IeY=3D; b=LRvIQ9gYTVwrdKpUjuGobG8KmluyJr6w58PIGtYD+esEnT2vYvAe6DkTgvE5UpIkjNcnqR5/ Z1XT2KjrLXACijoL3zGGb+5ASF/hExqlHAKIAdPp2PUv7K5XrI15S1lt; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Cc: sip@ietf.org, "'James M. Polk'" , fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A possibly totally irrelevant comment .... Don't take this as gospel but by best crystal ball gazing at how RAI and SEC ADs might look at SIP security items requiring S/MIME .... Given the underwhelming implementation and deployment of S/MIME in SIP, one would hope there was solutions to achieve some minimal level of security that did not rely on S/MIME. If a technique could also be secured with S/MIME, or better security could be achieved using S/MIME, then making that possible (but not required for the minimum) would be fine. On the topic of proxies looking at bodies (but not modifying them), I will point out the end to middle work does some of that. On Jun 5, 2006, at 1:39 PM, Brian Rosen wrote: > I would strongly prefer to leave this as proxy routes with TLS > security. I > wouldn't want to preclude an endpoint from routing with S/MIME > security, but > I don't think that will be common. > > Brian > > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Monday, June 05, 2006 3:07 PM > To: Brian Rosen; fwmiller@cornfed.com > Cc: 'Tschofenig, Hannes'; 'Hannes Tschofenig'; sip@ietf.org > Subject: RE: [Sip] RE: [Geopriv] Explicit Indication of Location > Object > Consumer > > At 11:12 AM 6/4/2006 -0400, Brian Rosen wrote: >> The problem here is S/MIME. No one really uses S/MIME with SIP >> because the >> PKI is too hard to deal with. This case is just as hard as any >> other case. >> >> I also think PLANNING a B2BUA for this is a bad idea. B2BUAs are >> evil. > > B2BUA's are a reality. That ship's sailed already. > > No one does this function yet (routing a message based on the > location of > the caller), so this is greenfield. Someone can write an ID > intending to > become a BCP that says this is the RECOMMENDED practice of any > organization > that wants to route based on the location of the caller, since a > B2BUA can > inspect S/MIME bodies because it IS the desination. At that point, > I think > a 3XX is a waste of BW, as the more efficient means of > communicating with > the exact ultimate destination of that take-out@pizza-hut.com R-URI > from > where you are is determined by that server. > > Remember, a UA may not have their location by-reference to give to > take-out@pizza-hut.com to dereference. That makes the call fail > due to not > having a route; unless you want a less efficient default route that > will > never be right, and cause further delay, and possibly has to be > designed > with user interaction. > > If the B2BUA still wants to give a 302 back, it still can, once > it's read > the S/MIME location body. > > >> Brian >> >> -----Original Message----- >> From: James M. Polk [mailto:jmpolk@cisco.com] >> Sent: Saturday, June 03, 2006 8:49 PM >> To: fwmiller@cornfed.com >> Cc: Brian Rosen; 'Tschofenig, Hannes'; 'Hannes Tschofenig'; >> sip@ietf.org >> Subject: Re: [Sip] RE: [Geopriv] Explicit Indication of Location >> Object >> Consumer >> >> weeeeeell.... "take-out@pizza-hut.com" would be the R-URI in this >> case, >> wouldn't it? I think this has to the case since Brian has no >> knowledge >> which is the closest Pizza-Hut store to contact directly. >> >> Given this, S/MIME should still be the correct way to send >> location in the >> message (e2e). >> >> A 302 would be the response from take-out@pizza-hut.com. >> >> This would necessitate a new INVITE to the new URI given in the >> 302, but >> not necessarily including location in that INVITE at all. This is >> interesting... I need to think about how this can be misused/abused. >> >> At 08:14 PM 6/3/2006 -0400, Frank W. Miller wrote: >> >>> The Web way would be to redirect the request to another address >>> automatically rather than leaving the address alone and routing it >>> transparently under the covers. Think www.whatever going to >>> www12.whatever in a server farm, or whatever.com going to >>> us.whatever.com. You should be doing an end-to-end secure >>> connection to >>> the original address and then a separate end-to-end secure >>> connection to >>> the redirected address. >>> >>> FM >>> >>> >>> >>> On Sat, 2006-06-03 at 17:32 -0500, James M. Polk wrote: >>>> [took Geopriv alias off] >>>> >>>> Question - shouldn't we assume in this example that >> take-out@pizza-hut.com >>>> is a B2BUA, making it a destination - allowing it to open and >>>> read the >>>> S/MIME body? >>>> >>>> I'm asking this because this seems like it could be a logical > operation >> of >>>> Pizza-Hut's SIP infrastructure under the conditions you've laid >>>> out. >>>> >>>> At 11:52 AM 5/22/2006 -0400, Brian Rosen wrote: >>>>> I don't see this as a problem. >>>>> >>>>> Let's take the non-emergency case. >>>>> >>>>> If I call take-out@pizza-hut.com, and I want location based >>>>> routing, > I >> put >>>>> my location header in the call, and send the call with TLS. My >> outbound >>>>> proxy will properly ignore it. The pizza-hut domain is the one >>>>> that >> wants >>>>> to do location based routing, it will get the location and send it > off. >> I >>>>> don't need to tell it to do that. I could imagine a generic >>>>> location >>> based >>>>> routing proxy, but I would not think we would want to mark the > location >>>>> header as the way to get it invoked; we need something else > (directly, >> or >>>>> indirectly, a Route header) to do that. >>>>> >>>>> If I want the endpoint to get it, then I protect it with S/MIME >>>>> and > no >>> proxy >>>>> sees it. >>>>> >>>>> Brian >>>>> >>>>> -----Original Message----- >>>>> From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] >>>>> Sent: Monday, May 22, 2006 10:54 AM >>>>> To: Brian Rosen; Hannes Tschofenig; sip@ietf.org; geopriv@ietf.org >>>>> Subject: AW: [Geopriv] Explicit Indication of Location Object > Consumer >>>>> >>>>> Hi Brian, >>>>> >>>>>> I would say no. If the location is not needed by proxies, >>>>>> then I would say >>>>>> you MUST protect it (S/MIME), or it will not be private. >>>>> I am less concerned about the security aspects here and more >>>>> focused >> the >>>>> protocol operation first. >>>>> Typically, it is good to know for a device whether it has to >>>>> process >> the >>>>> content of the message or not. >>>>> >>>>> If you want to prevent intermediaries to inspect your location >>>>> object >>>>> then S/MIME might be a choice (at least on paper). >>>>> >>>>>> >>>>>> If you have to route on it (emergency or otherwise), then you >>>>>> have to send >>>>>> it with TLS, and the proxies can see it. >>>>>> >>>>>> Brian >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>> Sent: Sunday, May 21, 2006 7:40 AM >>>>>> To: sip@ietf.org; geopriv@ietf.org >>>>>> Subject: [Geopriv] Explicit Indication of Location Object >>>>>> Consumer >>>>>> >>>>>> Hi James >>>>>> Hi Brian, >>>>>> >>>>>> do you plan to put additional info into the SIP message to >>>>>> indicate who >>>>>> should consume the Location Object (explicity rather than >>>>>> implicit info)? >>>>>> >>>>>> Here is an example: Assume that SIP UA Alice wants to give >>>>>> Bob location >>>>>> information (via reference). Now, Alice could easily indicate >>>>>> that >> it >>>>>> wants Bob to resolve the reference and to process the >>>>>> location object. >>>>>> Stating this explicitly would prevent proxies to resolve it >>>>>> and to >>>>>> process the location object. >>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Geopriv mailing list >>>>>> Geopriv@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/geopriv >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Geopriv mailing list >>>>>> Geopriv@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/geopriv >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Geopriv mailing list >>>>> Geopriv@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/geopriv >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 10 00:38:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FovDV-0006Dz-Qb; Sat, 10 Jun 2006 00:36:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FovDU-0006Do-L5 for sip@ietf.org; Sat, 10 Jun 2006 00:36:56 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FovDU-0000nr-4i for sip@ietf.org; Sat, 10 Jun 2006 00:36:56 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Jun 2006 23:37:23 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Fri, 09 Jun 2006 23:37:22 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Jun 2006 23:37:22 -0500 Message-ID: From: "Winterbottom, James" To: "Cullen Jennings" , "Brian Rosen" Date: Fri, 9 Jun 2006 23:37:40 -0500 Subject: RE: [Sip] RE: [Geopriv] Explicit Indication of Location ObjectConsumer MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 10 Jun 2006 04:37:22.0110 (UTC) FILETIME=[9079B5E0:01C68C47] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <06DBCAA6-F8BD-4394-B67C-51532346CD34@cisco.com> Content-class: urn:content-classes:message Thread-Topic: [Sip] RE: [Geopriv] Explicit Indication of Location ObjectConsumer Thread-Index: AcaMRk45ZzOCuGVCQCWo8unFvxn1WwAARpXg X-Spam-Score: 0.0 (/) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc Cc: sip@ietf.org, "James M. Polk" , fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I might point out that in the PSTN today a lot of systems do location dependent routing without providing the location to the final destination and I see this as a very useful property. This will be difficult to perform with S/MIME without a lot of work. > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Saturday, 10 June 2006 2:08 PM > To: Brian Rosen > Cc: sip@ietf.org; 'James M. Polk'; fwmiller@cornfed.com > Subject: Re: [Sip] RE: [Geopriv] Explicit Indication of Location > ObjectConsumer >=20 >=20 > A possibly totally irrelevant comment .... >=20 > Don't take this as gospel but by best crystal ball gazing at how RAI > and SEC ADs might look at SIP security items requiring S/MIME .... > Given the underwhelming implementation and deployment of S/MIME in > SIP, one would hope there was solutions to achieve some minimal > level of security that did not rely on S/MIME. If a technique could > also be secured with S/MIME, or better security could be achieved > using S/MIME, then making that possible (but not required for the > minimum) would be fine. >=20 > On the topic of proxies looking at bodies (but not modifying them), I > will point out the end to middle work does some of that. >=20 > On Jun 5, 2006, at 1:39 PM, Brian Rosen wrote: >=20 > > I would strongly prefer to leave this as proxy routes with TLS > > security. I > > wouldn't want to preclude an endpoint from routing with S/MIME > > security, but > > I don't think that will be common. > > > > Brian > > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Monday, June 05, 2006 3:07 PM > > To: Brian Rosen; fwmiller@cornfed.com > > Cc: 'Tschofenig, Hannes'; 'Hannes Tschofenig'; sip@ietf.org > > Subject: RE: [Sip] RE: [Geopriv] Explicit Indication of Location > > Object > > Consumer > > > > At 11:12 AM 6/4/2006 -0400, Brian Rosen wrote: > >> The problem here is S/MIME. No one really uses S/MIME with SIP > >> because the > >> PKI is too hard to deal with. This case is just as hard as any > >> other case. > >> > >> I also think PLANNING a B2BUA for this is a bad idea. B2BUAs are > >> evil. > > > > B2BUA's are a reality. That ship's sailed already. > > > > No one does this function yet (routing a message based on the > > location of > > the caller), so this is greenfield. Someone can write an ID > > intending to > > become a BCP that says this is the RECOMMENDED practice of any > > organization > > that wants to route based on the location of the caller, since a > > B2BUA can > > inspect S/MIME bodies because it IS the desination. At that point, > > I think > > a 3XX is a waste of BW, as the more efficient means of > > communicating with > > the exact ultimate destination of that take-out@pizza-hut.com R-URI > > from > > where you are is determined by that server. > > > > Remember, a UA may not have their location by-reference to give to > > take-out@pizza-hut.com to dereference. That makes the call fail > > due to not > > having a route; unless you want a less efficient default route that > > will > > never be right, and cause further delay, and possibly has to be > > designed > > with user interaction. > > > > If the B2BUA still wants to give a 302 back, it still can, once > > it's read > > the S/MIME location body. > > > > > >> Brian > >> > >> -----Original Message----- > >> From: James M. Polk [mailto:jmpolk@cisco.com] > >> Sent: Saturday, June 03, 2006 8:49 PM > >> To: fwmiller@cornfed.com > >> Cc: Brian Rosen; 'Tschofenig, Hannes'; 'Hannes Tschofenig'; > >> sip@ietf.org > >> Subject: Re: [Sip] RE: [Geopriv] Explicit Indication of Location > >> Object > >> Consumer > >> > >> weeeeeell.... "take-out@pizza-hut.com" would be the R-URI in this > >> case, > >> wouldn't it? I think this has to the case since Brian has no > >> knowledge > >> which is the closest Pizza-Hut store to contact directly. > >> > >> Given this, S/MIME should still be the correct way to send > >> location in the > >> message (e2e). > >> > >> A 302 would be the response from take-out@pizza-hut.com. > >> > >> This would necessitate a new INVITE to the new URI given in the > >> 302, but > >> not necessarily including location in that INVITE at all. This is > >> interesting... I need to think about how this can be misused/abused. > >> > >> At 08:14 PM 6/3/2006 -0400, Frank W. Miller wrote: > >> > >>> The Web way would be to redirect the request to another address > >>> automatically rather than leaving the address alone and routing it > >>> transparently under the covers. Think www.whatever going to > >>> www12.whatever in a server farm, or whatever.com going to > >>> us.whatever.com. You should be doing an end-to-end secure > >>> connection to > >>> the original address and then a separate end-to-end secure > >>> connection to > >>> the redirected address. > >>> > >>> FM > >>> > >>> > >>> > >>> On Sat, 2006-06-03 at 17:32 -0500, James M. Polk wrote: > >>>> [took Geopriv alias off] > >>>> > >>>> Question - shouldn't we assume in this example that > >> take-out@pizza-hut.com > >>>> is a B2BUA, making it a destination - allowing it to open and > >>>> read the > >>>> S/MIME body? > >>>> > >>>> I'm asking this because this seems like it could be a logical > > operation > >> of > >>>> Pizza-Hut's SIP infrastructure under the conditions you've laid > >>>> out. > >>>> > >>>> At 11:52 AM 5/22/2006 -0400, Brian Rosen wrote: > >>>>> I don't see this as a problem. > >>>>> > >>>>> Let's take the non-emergency case. > >>>>> > >>>>> If I call take-out@pizza-hut.com, and I want location based > >>>>> routing, > > I > >> put > >>>>> my location header in the call, and send the call with TLS. My > >> outbound > >>>>> proxy will properly ignore it. The pizza-hut domain is the one > >>>>> that > >> wants > >>>>> to do location based routing, it will get the location and send it > > off. > >> I > >>>>> don't need to tell it to do that. I could imagine a generic > >>>>> location > >>> based > >>>>> routing proxy, but I would not think we would want to mark the > > location > >>>>> header as the way to get it invoked; we need something else > > (directly, > >> or > >>>>> indirectly, a Route header) to do that. > >>>>> > >>>>> If I want the endpoint to get it, then I protect it with S/MIME > >>>>> and > > no > >>> proxy > >>>>> sees it. > >>>>> > >>>>> Brian > >>>>> > >>>>> -----Original Message----- > >>>>> From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > >>>>> Sent: Monday, May 22, 2006 10:54 AM > >>>>> To: Brian Rosen; Hannes Tschofenig; sip@ietf.org; geopriv@ietf.org > >>>>> Subject: AW: [Geopriv] Explicit Indication of Location Object > > Consumer > >>>>> > >>>>> Hi Brian, > >>>>> > >>>>>> I would say no. If the location is not needed by proxies, > >>>>>> then I would say > >>>>>> you MUST protect it (S/MIME), or it will not be private. > >>>>> I am less concerned about the security aspects here and more > >>>>> focused > >> the > >>>>> protocol operation first. > >>>>> Typically, it is good to know for a device whether it has to > >>>>> process > >> the > >>>>> content of the message or not. > >>>>> > >>>>> If you want to prevent intermediaries to inspect your location > >>>>> object > >>>>> then S/MIME might be a choice (at least on paper). > >>>>> > >>>>>> > >>>>>> If you have to route on it (emergency or otherwise), then you > >>>>>> have to send > >>>>>> it with TLS, and the proxies can see it. > >>>>>> > >>>>>> Brian > >>>>> > >>>>> Ciao > >>>>> Hannes > >>>>> > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>>>> Sent: Sunday, May 21, 2006 7:40 AM > >>>>>> To: sip@ietf.org; geopriv@ietf.org > >>>>>> Subject: [Geopriv] Explicit Indication of Location Object > >>>>>> Consumer > >>>>>> > >>>>>> Hi James > >>>>>> Hi Brian, > >>>>>> > >>>>>> do you plan to put additional info into the SIP message to > >>>>>> indicate who > >>>>>> should consume the Location Object (explicity rather than > >>>>>> implicit info)? > >>>>>> > >>>>>> Here is an example: Assume that SIP UA Alice wants to give > >>>>>> Bob location > >>>>>> information (via reference). Now, Alice could easily indicate > >>>>>> that > >> it > >>>>>> wants Bob to resolve the reference and to process the > >>>>>> location object. > >>>>>> Stating this explicitly would prevent proxies to resolve it > >>>>>> and to > >>>>>> process the location object. > >>>>>> > >>>>>> Ciao > >>>>>> Hannes > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Geopriv mailing list > >>>>>> Geopriv@ietf.org > >>>>>> https://www1.ietf.org/mailman/listinfo/geopriv > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Geopriv mailing list > >>>>>> Geopriv@ietf.org > >>>>>> https://www1.ietf.org/mailman/listinfo/geopriv > >>>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Geopriv mailing list > >>>>> Geopriv@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/geopriv > >>>> > >>>> _______________________________________________ > >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>> This list is for NEW development of the core SIP Protocol > >>>> Use sip-implementors@cs.columbia.edu for questions on current sip > >>>> Use sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 10 00:48:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FovMt-0002H6-F0; Sat, 10 Jun 2006 00:46:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FovMs-0002H1-Ir for sip@ietf.org; Sat, 10 Jun 2006 00:46:38 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FovMr-0002Rd-B4 for sip@ietf.org; Sat, 10 Jun 2006 00:46:38 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 09 Jun 2006 21:46:37 -0700 X-IronPort-AV: i="4.05,225,1146466800"; d="scan'208"; a="1823283012:sNHT30526480" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k5A4kaxI016227; Fri, 9 Jun 2006 21:46:36 -0700 Received: from [10.0.1.7] (sjc-vpn2-505.cisco.com [10.21.113.249]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5A4kaIs002756; Fri, 9 Jun 2006 21:46:36 -0700 (PDT) In-Reply-To: References: <24EAE5D4448B9D4592C6D234CBEBD597054F446F@stntexch03.cis.neustar.com> <24EAE5D4448B9D4592C6D234CBEBD597054F446F@stntexch03.cis.neustar.com> <4.3.2.7.2.20060607220404.019edc98@email.cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] What to do with SIP SAML draft Date: Fri, 9 Jun 2006 20:53:19 -0700 To: Dean Willis X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=352; t=1149914796; x=1150778796; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20What=20to=20do=20with=20SIP=20SAML=20draft; X=v=3Dcisco.com=3B=20h=3DUcUDkGZVoF/tQFUSkMAzPYchmgI=3D; b=ptlrihFmJoyn9Cldnybrzr9o4Uq4reucSNH/TpupBfIoFaI6sLSm/DhYDCavBJ0V6mI7D8GW /T/+QuezcyMwaULdUGDKUWr42a1YEqnMgnZKzCpihOJxgZOYXxvoljNr; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Sip IETF , "James M. Polk" , "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: , Errors-To: sip-bounces@ietf.org On Jun 8, 2006, at 1:35 PM, Dean Willis wrote: > The AD response seem to indicate support for that position. I was pretty vague and have no objections either way. I would guess we will adopt this sooner or later. I am not keen on a "trash this and do something totally different path" but I don't think anyone has been keen on that. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 10 10:47:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fp4iB-00065k-Oc; Sat, 10 Jun 2006 10:45:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fp4iA-00061T-6T for sip@ietf.org; Sat, 10 Jun 2006 10:45:14 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fp4i9-0006Zm-HH for sip@ietf.org; Sat, 10 Jun 2006 10:45:14 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 10 Jun 2006 07:45:13 -0700 X-IronPort-AV: i="4.05,225,1146466800"; d="scan'208"; a="1823419692:sNHT37466208" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k5AEjCSt026988; Sat, 10 Jun 2006 07:45:12 -0700 Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5AEj5Is013357; Sat, 10 Jun 2006 07:45:06 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7CDE1E03-EBD3-42AB-A777-4442CA8395BE@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Sip] RE: [Geopriv] Explicit Indication of Location ObjectConsumer Date: Sat, 10 Jun 2006 10:44:59 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=12172; t=1149950712; x=1150814712; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20[Sip]=20RE=3A=20[Geopriv]=20Explicit=20Indication=20of=20Locatio n=20ObjectConsumer; X=v=3Dcisco.com=3B=20h=3DWvV/Uy+kiv4K0StrmkRg0v6ZC7o=3D; b=o7FNS/UolMkJ132Z63Nmh2XcSM6F5CpXAZJudvxdu9c7nVpp/iM/EKG1eV19XlULILSk2Glm X/RoBUxfmFCI/EK8j6sDGekk11qGN8DqIqYQWsy4X0lit8a3lAX9NkFm; Authentication-Results: sj-dkim-6.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1c0c3d540ad9f95212b1c2a9a2cc2595 Cc: Cullen Jennings , sip@ietf.org, "James M. Polk" , fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 10, 2006, at 12:37 AM, Winterbottom, James wrote: > I might point out that in the PSTN today a lot of systems do location > dependent routing without providing the location to the final > destination and I see this as a very useful property. This will be > difficult to perform with S/MIME without a lot of work. > Let's not confuse the location information provided to intermediaries for the purpose of delivering the call where you want, from the location information delivered to the ultimate recipient so that the application running there can do things with that information. As I've argued many times (and I believe the current drafts are in alignment with) these two locations "conveyances" need to be carried differently (in the case of SIP header versus body), any particular SIP message could carry either or both, the confidentiality and integrity properties for the two may be quite different, and even the content might be different (one or the other might be intentionally "fuzzed" to thwart the "target missiles" command). Can we put this one to bed? Please? Dave. P.S. I know those pesky SBCs screw all this up, just like bunches of other stuff that one wishes were really end-to-end. >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Saturday, 10 June 2006 2:08 PM >> To: Brian Rosen >> Cc: sip@ietf.org; 'James M. Polk'; fwmiller@cornfed.com >> Subject: Re: [Sip] RE: [Geopriv] Explicit Indication of Location >> ObjectConsumer >> >> >> A possibly totally irrelevant comment .... >> >> Don't take this as gospel but by best crystal ball gazing at how RAI >> and SEC ADs might look at SIP security items requiring S/MIME .... >> Given the underwhelming implementation and deployment of S/MIME in >> SIP, one would hope there was solutions to achieve some minimal >> level of security that did not rely on S/MIME. If a technique could >> also be secured with S/MIME, or better security could be achieved >> using S/MIME, then making that possible (but not required for the >> minimum) would be fine. >> >> On the topic of proxies looking at bodies (but not modifying them), I >> will point out the end to middle work does some of that. >> >> On Jun 5, 2006, at 1:39 PM, Brian Rosen wrote: >> >>> I would strongly prefer to leave this as proxy routes with TLS >>> security. I >>> wouldn't want to preclude an endpoint from routing with S/MIME >>> security, but >>> I don't think that will be common. >>> >>> Brian >>> >>> -----Original Message----- >>> From: James M. Polk [mailto:jmpolk@cisco.com] >>> Sent: Monday, June 05, 2006 3:07 PM >>> To: Brian Rosen; fwmiller@cornfed.com >>> Cc: 'Tschofenig, Hannes'; 'Hannes Tschofenig'; sip@ietf.org >>> Subject: RE: [Sip] RE: [Geopriv] Explicit Indication of Location >>> Object >>> Consumer >>> >>> At 11:12 AM 6/4/2006 -0400, Brian Rosen wrote: >>>> The problem here is S/MIME. No one really uses S/MIME with SIP >>>> because the >>>> PKI is too hard to deal with. This case is just as hard as any >>>> other case. >>>> >>>> I also think PLANNING a B2BUA for this is a bad idea. B2BUAs are >>>> evil. >>> >>> B2BUA's are a reality. That ship's sailed already. >>> >>> No one does this function yet (routing a message based on the >>> location of >>> the caller), so this is greenfield. Someone can write an ID >>> intending to >>> become a BCP that says this is the RECOMMENDED practice of any >>> organization >>> that wants to route based on the location of the caller, since a >>> B2BUA can >>> inspect S/MIME bodies because it IS the desination. At that point, >>> I think >>> a 3XX is a waste of BW, as the more efficient means of >>> communicating with >>> the exact ultimate destination of that take-out@pizza-hut.com R-URI >>> from >>> where you are is determined by that server. >>> >>> Remember, a UA may not have their location by-reference to give to >>> take-out@pizza-hut.com to dereference. That makes the call fail >>> due to not >>> having a route; unless you want a less efficient default route that >>> will >>> never be right, and cause further delay, and possibly has to be >>> designed >>> with user interaction. >>> >>> If the B2BUA still wants to give a 302 back, it still can, once >>> it's read >>> the S/MIME location body. >>> >>> >>>> Brian >>>> >>>> -----Original Message----- >>>> From: James M. Polk [mailto:jmpolk@cisco.com] >>>> Sent: Saturday, June 03, 2006 8:49 PM >>>> To: fwmiller@cornfed.com >>>> Cc: Brian Rosen; 'Tschofenig, Hannes'; 'Hannes Tschofenig'; >>>> sip@ietf.org >>>> Subject: Re: [Sip] RE: [Geopriv] Explicit Indication of Location >>>> Object >>>> Consumer >>>> >>>> weeeeeell.... "take-out@pizza-hut.com" would be the R-URI in this >>>> case, >>>> wouldn't it? I think this has to the case since Brian has no >>>> knowledge >>>> which is the closest Pizza-Hut store to contact directly. >>>> >>>> Given this, S/MIME should still be the correct way to send >>>> location in the >>>> message (e2e). >>>> >>>> A 302 would be the response from take-out@pizza-hut.com. >>>> >>>> This would necessitate a new INVITE to the new URI given in the >>>> 302, but >>>> not necessarily including location in that INVITE at all. This is >>>> interesting... I need to think about how this can be > misused/abused. >>>> >>>> At 08:14 PM 6/3/2006 -0400, Frank W. Miller wrote: >>>> >>>>> The Web way would be to redirect the request to another address >>>>> automatically rather than leaving the address alone and routing it >>>>> transparently under the covers. Think www.whatever going to >>>>> www12.whatever in a server farm, or whatever.com going to >>>>> us.whatever.com. You should be doing an end-to-end secure >>>>> connection to >>>>> the original address and then a separate end-to-end secure >>>>> connection to >>>>> the redirected address. >>>>> >>>>> FM >>>>> >>>>> >>>>> >>>>> On Sat, 2006-06-03 at 17:32 -0500, James M. Polk wrote: >>>>>> [took Geopriv alias off] >>>>>> >>>>>> Question - shouldn't we assume in this example that >>>> take-out@pizza-hut.com >>>>>> is a B2BUA, making it a destination - allowing it to open and >>>>>> read the >>>>>> S/MIME body? >>>>>> >>>>>> I'm asking this because this seems like it could be a logical >>> operation >>>> of >>>>>> Pizza-Hut's SIP infrastructure under the conditions you've laid >>>>>> out. >>>>>> >>>>>> At 11:52 AM 5/22/2006 -0400, Brian Rosen wrote: >>>>>>> I don't see this as a problem. >>>>>>> >>>>>>> Let's take the non-emergency case. >>>>>>> >>>>>>> If I call take-out@pizza-hut.com, and I want location based >>>>>>> routing, >>> I >>>> put >>>>>>> my location header in the call, and send the call with TLS. My >>>> outbound >>>>>>> proxy will properly ignore it. The pizza-hut domain is the one >>>>>>> that >>>> wants >>>>>>> to do location based routing, it will get the location and send > it >>> off. >>>> I >>>>>>> don't need to tell it to do that. I could imagine a generic >>>>>>> location >>>>> based >>>>>>> routing proxy, but I would not think we would want to mark the >>> location >>>>>>> header as the way to get it invoked; we need something else >>> (directly, >>>> or >>>>>>> indirectly, a Route header) to do that. >>>>>>> >>>>>>> If I want the endpoint to get it, then I protect it with S/MIME >>>>>>> and >>> no >>>>> proxy >>>>>>> sees it. >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] >>>>>>> Sent: Monday, May 22, 2006 10:54 AM >>>>>>> To: Brian Rosen; Hannes Tschofenig; sip@ietf.org; > geopriv@ietf.org >>>>>>> Subject: AW: [Geopriv] Explicit Indication of Location Object >>> Consumer >>>>>>> >>>>>>> Hi Brian, >>>>>>> >>>>>>>> I would say no. If the location is not needed by proxies, >>>>>>>> then I would say >>>>>>>> you MUST protect it (S/MIME), or it will not be private. >>>>>>> I am less concerned about the security aspects here and more >>>>>>> focused >>>> the >>>>>>> protocol operation first. >>>>>>> Typically, it is good to know for a device whether it has to >>>>>>> process >>>> the >>>>>>> content of the message or not. >>>>>>> >>>>>>> If you want to prevent intermediaries to inspect your location >>>>>>> object >>>>>>> then S/MIME might be a choice (at least on paper). >>>>>>> >>>>>>>> >>>>>>>> If you have to route on it (emergency or otherwise), then you >>>>>>>> have to send >>>>>>>> it with TLS, and the proxies can see it. >>>>>>>> >>>>>>>> Brian >>>>>>> >>>>>>> Ciao >>>>>>> Hannes >>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>> Sent: Sunday, May 21, 2006 7:40 AM >>>>>>>> To: sip@ietf.org; geopriv@ietf.org >>>>>>>> Subject: [Geopriv] Explicit Indication of Location Object >>>>>>>> Consumer >>>>>>>> >>>>>>>> Hi James >>>>>>>> Hi Brian, >>>>>>>> >>>>>>>> do you plan to put additional info into the SIP message to >>>>>>>> indicate who >>>>>>>> should consume the Location Object (explicity rather than >>>>>>>> implicit info)? >>>>>>>> >>>>>>>> Here is an example: Assume that SIP UA Alice wants to give >>>>>>>> Bob location >>>>>>>> information (via reference). Now, Alice could easily indicate >>>>>>>> that >>>> it >>>>>>>> wants Bob to resolve the reference and to process the >>>>>>>> location object. >>>>>>>> Stating this explicitly would prevent proxies to resolve it >>>>>>>> and to >>>>>>>> process the location object. >>>>>>>> >>>>>>>> Ciao >>>>>>>> Hannes >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Geopriv mailing list >>>>>>>> Geopriv@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/geopriv >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Geopriv mailing list >>>>>>>> Geopriv@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/geopriv >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Geopriv mailing list >>>>>>> Geopriv@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/geopriv >>>>>> >>>>>> _______________________________________________ >>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>> This list is for NEW development of the core SIP Protocol >>>>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>>>> Use sipping@ietf.org for new developments on the application of > sip >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > ---------------------------------------------------------------------- > -------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ---------------------------------------------------------------------- > -------------------------- > [mf2] > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 11 02:48:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpJiW-0000U4-UI; Sun, 11 Jun 2006 02:46:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpJiV-0000Tw-OY for sip@ietf.org; Sun, 11 Jun 2006 02:46:35 -0400 Received: from szinterscan.utstar.com.cn ([210.21.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpJiQ-0005tp-PX for sip@ietf.org; Sun, 11 Jun 2006 02:46:35 -0400 Received: from szsmtp.utstar.com.cn ([172.19.224.12]) by szinterscan.utstar.com.cn with InterScan Messaging Security Suite; Sun, 11 Jun 2006 14:52:50 +0800 Received: from SZMAIL11.cn.utstarcom.com (szmail03.cn.utstarcom.com [172.19.30.102] (may be forged)) by szsmtp.utstar.com.cn (8.11.6/8.11.1) with ESMTP id k5B6iqa06120; Sun, 11 Jun 2006 14:44:52 +0800 Subject: =?gb2312?B?tPC4tDogW1NpcF0gUkZDIDQwMjggKFNlc3Npb24gVGltZXIpIHJlbA==?= =?gb2312?B?YXRlZCBxdWVzdGlvbg==?= MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Sun, 11 Jun 2006 14:46:28 +0800 Content-class: urn:content-classes:message X-MIMEOLE: Produced By Microsoft Exchange V6.5.7233.32 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RFC 4028 (Session Timer) related question Thread-Index: AcZ5GyQYT8S/CqcMSXyIEVEEre7APwUBNaFw From: "Gerald Yan" To: "Paul Kyzivat" , "Sergey Markovich" X-Spam-Score: 0.5 (/) X-Scan-Signature: 1094b1c84fa6e846d476f39271f5074f Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I have another question about RFC 4028. In section 7.2: "It is possible that the UAC requested the session timer (and thus = included a Session-Expires header field in the request) and that there = was no Require or Session-Expires header field in the 2xx response. This = will happen when the UAS doesn't support the session timer extension and = only the UAC has asked for a session timer (no proxies have requested = it). In this case, if the UAC still wishes to use the session timer = (which is purely for its benefit alone), it has to perform them. " "If the 2xx response did not contain a Session-Expires header field, = there is no session expiration. In this case, no refreshes need to be = sent. A 2xx without a Session-Expires can come for both initial and = subsequent session refresh requests. This means that the session timer = can be 'turned-off' in mid dialog by receiving a response without a = Session-Expires header field." My question is that how does UAC know the 2xx response without a = Session-Expires header is for "turning off" session timer or a just = response from a UAS which doesn't support session timer. Best regards Gerald =20 -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2006=C4=EA5=D4=C217=C8=D5 3:00 =CA=D5=BC=FE=C8=CB: Sergey Markovich =B3=AD=CB=CD: sip@ietf.org =D6=F7=CC=E2: Re: [Sip] RFC 4028 (Session Timer) related question Sergey, In the situation you describe there is no value to using the session=20 timer mechanism. Since A is a (B2B)UA, it is free to send a reinvite any = time it wants to check on its session with B or C. To do this without=20 perturbing the call, it can send an offerless reinvite to B, take the=20 answer and send it as an offer in a reinvite to C, etc. Or it could simplify and simply send an OPTIONS periodically to B and = C. Session-Timer is really only of importance to stateful proxies. Paul Sergey Markovich wrote: >=20 > Paul, >=20 > I checked with our customer. A is a server but it is B2BUA and not a = proxy. >=20 > A is interested to know that B is alive. So there is no proxy. So the=20 > scenario is the following: >=20 > 1. B and C are endpoints. They do not know anything about Session = > Timer mechanism. > 2. A is a B2BUA. It implements Session Timer mechanism. > 3. C calls A, A calls B, both calls are established. > 4. A is sending reINVITEs with "Session-Expires" header to B=20 > periodically. B is replying with OK without "Session-Expires" or=20 > "Supported:timer", i.e. B does not support the Session Timer = mechanism,=20 > A is a refresher. >=20 > 5. Probably the same happens between A and C (on the other leg of = > B2BUA) > 6. B puts A on hold, i.e. it sends SDP related reINVITE without=20 > "Session-Expires" or "Supported:timer" > 7. A replies with OK without "Session-Expires" and it=20 > stops(disables) the mechanism, i.e. no session timer related callbacks = > anymore, the application does not do refresh (does not send reINVITEs) = > anymore. >=20 > Thank you, >=20 > Sergey >=20 >=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, May 16, 2006 12:16 PM > To: Sergey Markovich > Cc: sip@ietf.org > Subject: Re: [Sip] RFC 4028 (Session Timer) related question >=20 > Sergy, >=20 > Can you restate your problem, showing both UAs and the proxy, and what >=20 > each does? >=20 > Paul >=20 > Sergey Markovich wrote: >=20 >> Paul, >=20 >> >=20 >> A is a proxy in this scenario. Probably I was wrong when I said "A = calls >=20 >> B". A just forwards initial INVITE from somebody else to B. B is an >=20 >> endpoint. >=20 >> >=20 >> Sergey >=20 >> >=20 >> -----Original Message----- >=20 >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >=20 >> Sent: Monday, May 15, 2006 5:46 PM >=20 >> To: Sergey Markovich >=20 >> Cc: sip@ietf.org >=20 >> Subject: Re: [Sip] RFC 4028 (Session Timer) related question >=20 >> >=20 >> Sergey, >=20 >> >=20 >> For this scenario to make sense there should be a proxy involved = that is >=20 >> >=20 >> interested in having a session timer. If there was, then it would = insert >=20 >> >=20 >> a Session-Expires into reinvite of step 4, and A would respond, >=20 >> reestablishing the timer. >=20 >> >=20 >> If there is no proxy doing this, then there is no need for a session >=20 >> timer to be established. If A wants to periodically check the status = of >=20 >> the session, it may do so an any time by sending a reinvite. >=20 >> >=20 >> Paul >=20 >> >=20 >> Sergey Markovich wrote: >=20 >> > We have the following scenario: >=20 >> > >=20 >> >=20 >=20 >> > >=20 >> > 1. A has Session Timer mechanism enabled. >=20 >> > >=20 >> > 2. A calls B, the call is established >=20 >> > >=20 >> > 3. A is sending reINVITEs with "Session-Expires" header to B >=20 >> > periodically. B is replying with OK without "Session-Expires" or >=20 >> > "Supported:timer", i.e. B does not support the Session Timer >=20 >> mechanism, >=20 >> > A is a refresher. >=20 >> > >=20 >> > 4. B puts A on hold, i.e. it sends SDP related reINVITE = without >=20 >> > "Session-Expires" or "Supported:timer" >=20 >> > >=20 >> > 5. A replies with OK without "Session-Expires" and it stops >=20 >> > (disables) the mechanism, i.e. no session timer related callbacks >=20 >> > anymore, the application does not do refresh (does not send = reINVITEs) >=20 >> >=20 >> > anymore. >=20 >> > >=20 >> >=20 >=20 >> > >=20 >> > I am not sure that step 5 is RFC 4028 compliant. >=20 >> > >=20 >> > I know that the default value of "Session-Expires" is infinity, but = I >=20 >> > think it makes sense only when the sending party (B) DOES support = the >=20 >> > mechanism (i.e. does include "Supported:timer", but does not = include >=20 >> > "Session-Expires" in the reINVITE). In that case the reINVITE can = be >=20 >> > used for the negotiation of the mechanism parameters. But in our = case >=20 >> > the reINVITE from step 4 has to be treated as "refresh" only = (because >=20 >> > after step 4 A knows that B is alive). So A has to restart the = timer >=20 >> but >=20 >> > not to disable the mechanism. >=20 >> > >=20 >> >=20 >=20 >> > >=20 >> > It would be appreciated if you comment what should we do in step 5. >=20 >> > >=20 >> >=20 >=20 >> > >=20 >> > Thanks a lot, >=20 >> > >=20 >> >=20 >=20 >> > >=20 >> > Sergey >=20 >> > >=20 >> >=20 >=20 >> > >=20 >> > >=20 >> > >=20 >> = ------------------------------------------------------------------------ >=20 >> > _______________________________________________ >=20 >> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >=20 >> > This list is for NEW development of the core SIP Protocol >=20 >> > Use sip-implementors@cs.columbia.edu for questions on current sip >=20 >> > Use sipping@ietf.org for new developments on the application of sip >=20 >> >=20 >> >=20 >> _______________________________________________ >=20 >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >=20 >> This list is for NEW development of the core SIP Protocol >=20 >> Use sip-implementors@cs.columbia.edu for questions on current sip >=20 >> Use sipping@ietf.org for new developments on the application of sip >=20 >> >=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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 11 03:25:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpKHT-0007tB-1z; Sun, 11 Jun 2006 03:22:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpKHR-0007t6-RI for sip@ietf.org; Sun, 11 Jun 2006 03:22:41 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpKHQ-0000yI-GR for sip@ietf.org; Sun, 11 Jun 2006 03:22:41 -0400 Received: from [192.168.2.104] (c-24-1-184-104.hsd1.tx.comcast.net [24.1.184.104]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5B7O6De023864 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Sun, 11 Jun 2006 02:24:06 -0500 Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Sip IETF From: Dean Willis Date: Sun, 11 Jun 2006 02:22:38 -0500 X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Sip] Supported: in ACK X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org So, I'm having a Table 2 debate with Joel R., who notices these things. I don't like RFC 3261's Table 2 much, as you may recall . . . Can you or should you include a Supported or Require header in an ACK request? Table 2 says "Not applicable", if I'm reading it right. RFC 3261 says: If the UAC supports extensions to SIP that can be applied by the server to the response, the UAC SHOULD include a Supported header field in the request listing the option tags (Section 19.2) for those extensions. And some of our extensions, at least some of the proposed extensions, might actually apply to ACK -- OTOH, there's not a response to ACK, so I'm perplexed as to how the Supported: header would be applied by the server to the response, since there isn't one. JDR has, if I understand him, said several times that one includes Supported: with all extensions in every request, and ACK is a request, sort of. And, some published examples apparently include Supported: in ACK. Should they? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 11 04:49:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpLbV-00032I-QQ; Sun, 11 Jun 2006 04:47:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpLbU-00032C-J6 for sip@ietf.org; Sun, 11 Jun 2006 04:47:28 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FpLbT-0000tD-No for sip@ietf.org; Sun, 11 Jun 2006 04:47:28 -0400 Received: (qmail invoked by alias); 11 Jun 2006 08:47:25 -0000 Received: from p54987B8C.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.123.140] by mail.gmx.net (mp036) with SMTP; 11 Jun 2006 10:47:25 +0200 X-Authenticated: #29516787 Message-ID: <448BD89E.7070201@gmx.net> Date: Sun, 11 Jun 2006 10:47:26 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David R Oran Subject: Re: [Sip] RE: [Geopriv] Explicit Indication of Location ObjectConsumer References: <7CDE1E03-EBD3-42AB-A777-4442CA8395BE@cisco.com> In-Reply-To: <7CDE1E03-EBD3-42AB-A777-4442CA8395BE@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5216aa5b0df24d46eaed76d4f65aa31 Cc: Cullen Jennings , sip@ietf.org, fwmiller@cornfed.com, "James M. Polk" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi David, David R Oran wrote: > > On Jun 10, 2006, at 12:37 AM, Winterbottom, James wrote: > >> I might point out that in the PSTN today a lot of systems do location >> dependent routing without providing the location to the final >> destination and I see this as a very useful property. This will be >> difficult to perform with S/MIME without a lot of work. >> > Let's not confuse the location information provided to intermediaries > for the purpose of delivering the call where you want, from the > location information delivered to the ultimate recipient so that the > application running there can do things with that information. As I've > argued many times (and I believe the current drafts are in alignment > with) these two locations "conveyances" need to be carried differently > (in the case of SIP header versus body), any particular SIP message > could carry either or both, the confidentiality and integrity > properties for the two may be quite different, and even the content > might be different (one or the other might be intentionally "fuzzed" to > thwart the "target missiles" command). Would it be acceptable to carry a PIDF-LO in the SIP header? Otherwise you always have to create a reference and to let the intermediaries fetch the PIDF-LO first. I could imagine that there are cases where this could lead to call setup delays. Ciao Hannes > > Can we put this one to bed? Please? > > Dave. > > P.S. I know those pesky SBCs screw all this up, just like bunches of > other stuff that one wishes were really end-to-end. > > >>> -----Original Message----- >>> From: Cullen Jennings [mailto:fluffy@cisco.com] >>> Sent: Saturday, 10 June 2006 2:08 PM >>> To: Brian Rosen >>> Cc: sip@ietf.org; 'James M. Polk'; fwmiller@cornfed.com >>> Subject: Re: [Sip] RE: [Geopriv] Explicit Indication of Location >>> ObjectConsumer >>> >>> >>> A possibly totally irrelevant comment .... >>> >>> Don't take this as gospel but by best crystal ball gazing at how RAI >>> and SEC ADs might look at SIP security items requiring S/MIME .... >>> Given the underwhelming implementation and deployment of S/MIME in >>> SIP, one would hope there was solutions to achieve some minimal >>> level of security that did not rely on S/MIME. If a technique could >>> also be secured with S/MIME, or better security could be achieved >>> using S/MIME, then making that possible (but not required for the >>> minimum) would be fine. >>> >>> On the topic of proxies looking at bodies (but not modifying them), I >>> will point out the end to middle work does some of that. >>> >>> On Jun 5, 2006, at 1:39 PM, Brian Rosen wrote: >>> >>>> I would strongly prefer to leave this as proxy routes with TLS >>>> security. I >>>> wouldn't want to preclude an endpoint from routing with S/MIME >>>> security, but >>>> I don't think that will be common. >>>> >>>> Brian >>>> >>>> -----Original Message----- >>>> From: James M. Polk [mailto:jmpolk@cisco.com] >>>> Sent: Monday, June 05, 2006 3:07 PM >>>> To: Brian Rosen; fwmiller@cornfed.com >>>> Cc: 'Tschofenig, Hannes'; 'Hannes Tschofenig'; sip@ietf.org >>>> Subject: RE: [Sip] RE: [Geopriv] Explicit Indication of Location >>>> Object >>>> Consumer >>>> >>>> At 11:12 AM 6/4/2006 -0400, Brian Rosen wrote: >>>> >>>>> The problem here is S/MIME. No one really uses S/MIME with SIP >>>>> because the >>>>> PKI is too hard to deal with. This case is just as hard as any >>>>> other case. >>>>> >>>>> I also think PLANNING a B2BUA for this is a bad idea. B2BUAs are >>>>> evil. >>>> >>>> >>>> B2BUA's are a reality. That ship's sailed already. >>>> >>>> No one does this function yet (routing a message based on the >>>> location of >>>> the caller), so this is greenfield. Someone can write an ID >>>> intending to >>>> become a BCP that says this is the RECOMMENDED practice of any >>>> organization >>>> that wants to route based on the location of the caller, since a >>>> B2BUA can >>>> inspect S/MIME bodies because it IS the desination. At that point, >>>> I think >>>> a 3XX is a waste of BW, as the more efficient means of >>>> communicating with >>>> the exact ultimate destination of that take-out@pizza-hut.com R-URI >>>> from >>>> where you are is determined by that server. >>>> >>>> Remember, a UA may not have their location by-reference to give to >>>> take-out@pizza-hut.com to dereference. That makes the call fail >>>> due to not >>>> having a route; unless you want a less efficient default route that >>>> will >>>> never be right, and cause further delay, and possibly has to be >>>> designed >>>> with user interaction. >>>> >>>> If the B2BUA still wants to give a 302 back, it still can, once >>>> it's read >>>> the S/MIME location body. >>>> >>>> >>>>> Brian >>>>> >>>>> -----Original Message----- >>>>> From: James M. Polk [mailto:jmpolk@cisco.com] >>>>> Sent: Saturday, June 03, 2006 8:49 PM >>>>> To: fwmiller@cornfed.com >>>>> Cc: Brian Rosen; 'Tschofenig, Hannes'; 'Hannes Tschofenig'; >>>>> sip@ietf.org >>>>> Subject: Re: [Sip] RE: [Geopriv] Explicit Indication of Location >>>>> Object >>>>> Consumer >>>>> >>>>> weeeeeell.... "take-out@pizza-hut.com" would be the R-URI in this >>>>> case, >>>>> wouldn't it? I think this has to the case since Brian has no >>>>> knowledge >>>>> which is the closest Pizza-Hut store to contact directly. >>>>> >>>>> Given this, S/MIME should still be the correct way to send >>>>> location in the >>>>> message (e2e). >>>>> >>>>> A 302 would be the response from take-out@pizza-hut.com. >>>>> >>>>> This would necessitate a new INVITE to the new URI given in the >>>>> 302, but >>>>> not necessarily including location in that INVITE at all. This is >>>>> interesting... I need to think about how this can be >> >> misused/abused. >> >>>>> >>>>> At 08:14 PM 6/3/2006 -0400, Frank W. Miller wrote: >>>>> >>>>>> The Web way would be to redirect the request to another address >>>>>> automatically rather than leaving the address alone and routing it >>>>>> transparently under the covers. Think www.whatever going to >>>>>> www12.whatever in a server farm, or whatever.com going to >>>>>> us.whatever.com. You should be doing an end-to-end secure >>>>>> connection to >>>>>> the original address and then a separate end-to-end secure >>>>>> connection to >>>>>> the redirected address. >>>>>> >>>>>> FM >>>>>> >>>>>> >>>>>> >>>>>> On Sat, 2006-06-03 at 17:32 -0500, James M. Polk wrote: >>>>>> >>>>>>> [took Geopriv alias off] >>>>>>> >>>>>>> Question - shouldn't we assume in this example that >>>>> >>>>> take-out@pizza-hut.com >>>>> >>>>>>> is a B2BUA, making it a destination - allowing it to open and >>>>>>> read the >>>>>>> S/MIME body? >>>>>>> >>>>>>> I'm asking this because this seems like it could be a logical >>>> >>>> operation >>>> >>>>> of >>>>> >>>>>>> Pizza-Hut's SIP infrastructure under the conditions you've laid >>>>>>> out. >>>>>>> >>>>>>> At 11:52 AM 5/22/2006 -0400, Brian Rosen wrote: >>>>>>> >>>>>>>> I don't see this as a problem. >>>>>>>> >>>>>>>> Let's take the non-emergency case. >>>>>>>> >>>>>>>> If I call take-out@pizza-hut.com, and I want location based >>>>>>>> routing, >>>> >>>> I >>>> >>>>> put >>>>> >>>>>>>> my location header in the call, and send the call with TLS. My >>>>> >>>>> outbound >>>>> >>>>>>>> proxy will properly ignore it. The pizza-hut domain is the one >>>>>>>> that >>>>> >>>>> wants >>>>> >>>>>>>> to do location based routing, it will get the location and send >> >> it >> >>>> off. >>>> >>>>> I >>>>> >>>>>>>> don't need to tell it to do that. I could imagine a generic >>>>>>>> location >>>>>> >>>>>> based >>>>>> >>>>>>>> routing proxy, but I would not think we would want to mark the >>>> >>>> location >>>> >>>>>>>> header as the way to get it invoked; we need something else >>>> >>>> (directly, >>>> >>>>> or >>>>> >>>>>>>> indirectly, a Route header) to do that. >>>>>>>> >>>>>>>> If I want the endpoint to get it, then I protect it with S/MIME >>>>>>>> and >>>> >>>> no >>>> >>>>>> proxy >>>>>> >>>>>>>> sees it. >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] >>>>>>>> Sent: Monday, May 22, 2006 10:54 AM >>>>>>>> To: Brian Rosen; Hannes Tschofenig; sip@ietf.org; >> >> geopriv@ietf.org >> >>>>>>>> Subject: AW: [Geopriv] Explicit Indication of Location Object >>>> >>>> Consumer >>>> >>>>>>>> >>>>>>>> Hi Brian, >>>>>>>> >>>>>>>>> I would say no. If the location is not needed by proxies, >>>>>>>>> then I would say >>>>>>>>> you MUST protect it (S/MIME), or it will not be private. >>>>>>>> >>>>>>>> I am less concerned about the security aspects here and more >>>>>>>> focused >>>>> >>>>> the >>>>> >>>>>>>> protocol operation first. >>>>>>>> Typically, it is good to know for a device whether it has to >>>>>>>> process >>>>> >>>>> the >>>>> >>>>>>>> content of the message or not. >>>>>>>> >>>>>>>> If you want to prevent intermediaries to inspect your location >>>>>>>> object >>>>>>>> then S/MIME might be a choice (at least on paper). >>>>>>>> >>>>>>>>> >>>>>>>>> If you have to route on it (emergency or otherwise), then you >>>>>>>>> have to send >>>>>>>>> it with TLS, and the proxies can see it. >>>>>>>>> >>>>>>>>> Brian >>>>>>>> >>>>>>>> >>>>>>>> Ciao >>>>>>>> Hannes >>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>>> Sent: Sunday, May 21, 2006 7:40 AM >>>>>>>>> To: sip@ietf.org; geopriv@ietf.org >>>>>>>>> Subject: [Geopriv] Explicit Indication of Location Object >>>>>>>>> Consumer >>>>>>>>> >>>>>>>>> Hi James >>>>>>>>> Hi Brian, >>>>>>>>> >>>>>>>>> do you plan to put additional info into the SIP message to >>>>>>>>> indicate who >>>>>>>>> should consume the Location Object (explicity rather than >>>>>>>>> implicit info)? >>>>>>>>> >>>>>>>>> Here is an example: Assume that SIP UA Alice wants to give >>>>>>>>> Bob location >>>>>>>>> information (via reference). Now, Alice could easily indicate >>>>>>>>> that >>>>> >>>>> it >>>>> >>>>>>>>> wants Bob to resolve the reference and to process the >>>>>>>>> location object. >>>>>>>>> Stating this explicitly would prevent proxies to resolve it >>>>>>>>> and to >>>>>>>>> process the location object. >>>>>>>>> >>>>>>>>> Ciao >>>>>>>>> Hannes >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Geopriv mailing list >>>>>>>>> Geopriv@ietf.org >>>>>>>>> https://www1.ietf.org/mailman/listinfo/geopriv >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Geopriv mailing list >>>>>>>>> Geopriv@ietf.org >>>>>>>>> https://www1.ietf.org/mailman/listinfo/geopriv >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Geopriv mailing list >>>>>>>> Geopriv@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/geopriv >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>> This list is for NEW development of the core SIP Protocol >>>>>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>>>>> Use sipping@ietf.org for new developments on the application of >> >> sip >> >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the application of sip >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >> >> >> ---------------------------------------------------------------------- >> -------------------------- >> This message is for the designated recipient only and may >> contain privileged, proprietary, or otherwise private information. >> If you have received it in error, please notify the sender >> immediately and delete the original. Any unauthorized use of >> this email is prohibited. >> ---------------------------------------------------------------------- >> -------------------------- >> [mf2] >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 11 06:51:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpNW2-0007mn-Rx; Sun, 11 Jun 2006 06:49:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpNW1-0007mi-F8 for sip@ietf.org; Sun, 11 Jun 2006 06:49:57 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpNW0-0004IE-Qt for sip@ietf.org; Sun, 11 Jun 2006 06:49:57 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Jun 2006 05:50:25 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Sun, 11 Jun 2006 05:50:25 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Jun 2006 05:50:24 -0500 Message-ID: From: "Winterbottom, James" To: "Hannes Tschofenig" , "David R Oran" Date: Sun, 11 Jun 2006 05:50:12 -0500 Subject: RE: [Sip] RE: [Geopriv] Explicit Indication of Location ObjectConsumer MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 11 Jun 2006 10:50:24.0542 (UTC) FILETIME=[D7DB8BE0:01C68D44] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <448BD89E.7070201@gmx.net> Content-class: urn:content-classes:message Thread-Topic: [Sip] RE: [Geopriv] Explicit Indication of Location ObjectConsumer Thread-Index: AcaNM6uDQiCgNBiZQMiq1I3BY5iY5gADvplA X-Spam-Score: 0.0 (/) X-Scan-Signature: d6c15d82a53e26283536b4a751453103 Cc: Cullen Jennings , sip@ietf.org, "James M. Polk" , fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Hannes, This is true, it may lead to some delays, but unless you have multiple nodes making successive requests then the reference is actually superior in the circumstance mentioned below as only nodes that are entitled to location can get it. If you plonk location in the header then everything that sees the SIP message can see the location, and this is probably not a good plan. If you plonk it in the body then usually the end-point can see it. What if I only want a routing proxy to be able to see my location, and then only for routing purposes?=20 The other case is that a reference allows the node needing location to request it in the form needed by the application, sending a literal value form the end-point pre-supposes that the originator knows the correct form and they may not. The moment negotiations come into play through the sending of a 424 response code then using a reference has the same or fewer message exchanges than the use of a literal location and the added delay argument become somewhat mythical. There are cases for both reference and literal location representation though I remain unconvinced about supporting a literal location in the SIP header. Cheers James =20 =20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Sunday, 11 June 2006 6:47 PM > To: David R Oran > Cc: Winterbottom, James; Cullen Jennings; sip@ietf.org; James M. Polk; > fwmiller@cornfed.com > Subject: Re: [Sip] RE: [Geopriv] Explicit Indication of Location > ObjectConsumer >=20 > Hi David, >=20 > David R Oran wrote: > > > > On Jun 10, 2006, at 12:37 AM, Winterbottom, James wrote: > > > >> I might point out that in the PSTN today a lot of systems do location > >> dependent routing without providing the location to the final > >> destination and I see this as a very useful property. This will be > >> difficult to perform with S/MIME without a lot of work. > >> > > Let's not confuse the location information provided to intermediaries > > for the purpose of delivering the call where you want, from the > > location information delivered to the ultimate recipient so that the > > application running there can do things with that information. As I've > > argued many times (and I believe the current drafts are in alignment > > with) these two locations "conveyances" need to be carried differently > > (in the case of SIP header versus body), any particular SIP message > > could carry either or both, the confidentiality and integrity > > properties for the two may be quite different, and even the content > > might be different (one or the other might be intentionally "fuzzed" to > > thwart the "target missiles" command). >=20 > Would it be acceptable to carry a PIDF-LO in the SIP header? Otherwise > you always have to create a reference and to let the intermediaries > fetch the PIDF-LO first. I could imagine that there are cases where this > could lead to call setup delays. >=20 > Ciao > Hannes >=20 > > > > Can we put this one to bed? Please? > > > > Dave. > > > > P.S. I know those pesky SBCs screw all this up, just like bunches of > > other stuff that one wishes were really end-to-end. > > > > > >>> -----Original Message----- > >>> From: Cullen Jennings [mailto:fluffy@cisco.com] > >>> Sent: Saturday, 10 June 2006 2:08 PM > >>> To: Brian Rosen > >>> Cc: sip@ietf.org; 'James M. Polk'; fwmiller@cornfed.com > >>> Subject: Re: [Sip] RE: [Geopriv] Explicit Indication of Location > >>> ObjectConsumer > >>> > >>> > >>> A possibly totally irrelevant comment .... > >>> > >>> Don't take this as gospel but by best crystal ball gazing at how RAI > >>> and SEC ADs might look at SIP security items requiring S/MIME .... > >>> Given the underwhelming implementation and deployment of S/MIME in > >>> SIP, one would hope there was solutions to achieve some minimal > >>> level of security that did not rely on S/MIME. If a technique could > >>> also be secured with S/MIME, or better security could be achieved > >>> using S/MIME, then making that possible (but not required for the > >>> minimum) would be fine. > >>> > >>> On the topic of proxies looking at bodies (but not modifying them), I > >>> will point out the end to middle work does some of that. > >>> > >>> On Jun 5, 2006, at 1:39 PM, Brian Rosen wrote: > >>> > >>>> I would strongly prefer to leave this as proxy routes with TLS > >>>> security. I > >>>> wouldn't want to preclude an endpoint from routing with S/MIME > >>>> security, but > >>>> I don't think that will be common. > >>>> > >>>> Brian > >>>> > >>>> -----Original Message----- > >>>> From: James M. Polk [mailto:jmpolk@cisco.com] > >>>> Sent: Monday, June 05, 2006 3:07 PM > >>>> To: Brian Rosen; fwmiller@cornfed.com > >>>> Cc: 'Tschofenig, Hannes'; 'Hannes Tschofenig'; sip@ietf.org > >>>> Subject: RE: [Sip] RE: [Geopriv] Explicit Indication of Location > >>>> Object > >>>> Consumer > >>>> > >>>> At 11:12 AM 6/4/2006 -0400, Brian Rosen wrote: > >>>> > >>>>> The problem here is S/MIME. No one really uses S/MIME with SIP > >>>>> because the > >>>>> PKI is too hard to deal with. This case is just as hard as any > >>>>> other case. > >>>>> > >>>>> I also think PLANNING a B2BUA for this is a bad idea. B2BUAs are > >>>>> evil. > >>>> > >>>> > >>>> B2BUA's are a reality. That ship's sailed already. > >>>> > >>>> No one does this function yet (routing a message based on the > >>>> location of > >>>> the caller), so this is greenfield. Someone can write an ID > >>>> intending to > >>>> become a BCP that says this is the RECOMMENDED practice of any > >>>> organization > >>>> that wants to route based on the location of the caller, since a > >>>> B2BUA can > >>>> inspect S/MIME bodies because it IS the desination. At that point, > >>>> I think > >>>> a 3XX is a waste of BW, as the more efficient means of > >>>> communicating with > >>>> the exact ultimate destination of that take-out@pizza-hut.com R-URI > >>>> from > >>>> where you are is determined by that server. > >>>> > >>>> Remember, a UA may not have their location by-reference to give to > >>>> take-out@pizza-hut.com to dereference. That makes the call fail > >>>> due to not > >>>> having a route; unless you want a less efficient default route that > >>>> will > >>>> never be right, and cause further delay, and possibly has to be > >>>> designed > >>>> with user interaction. > >>>> > >>>> If the B2BUA still wants to give a 302 back, it still can, once > >>>> it's read > >>>> the S/MIME location body. > >>>> > >>>> > >>>>> Brian > >>>>> > >>>>> -----Original Message----- > >>>>> From: James M. Polk [mailto:jmpolk@cisco.com] > >>>>> Sent: Saturday, June 03, 2006 8:49 PM > >>>>> To: fwmiller@cornfed.com > >>>>> Cc: Brian Rosen; 'Tschofenig, Hannes'; 'Hannes Tschofenig'; > >>>>> sip@ietf.org > >>>>> Subject: Re: [Sip] RE: [Geopriv] Explicit Indication of Location > >>>>> Object > >>>>> Consumer > >>>>> > >>>>> weeeeeell.... "take-out@pizza-hut.com" would be the R-URI in this > >>>>> case, > >>>>> wouldn't it? I think this has to the case since Brian has no > >>>>> knowledge > >>>>> which is the closest Pizza-Hut store to contact directly. > >>>>> > >>>>> Given this, S/MIME should still be the correct way to send > >>>>> location in the > >>>>> message (e2e). > >>>>> > >>>>> A 302 would be the response from take-out@pizza-hut.com. > >>>>> > >>>>> This would necessitate a new INVITE to the new URI given in the > >>>>> 302, but > >>>>> not necessarily including location in that INVITE at all. This is > >>>>> interesting... I need to think about how this can be > >> > >> misused/abused. > >> > >>>>> > >>>>> At 08:14 PM 6/3/2006 -0400, Frank W. Miller wrote: > >>>>> > >>>>>> The Web way would be to redirect the request to another address > >>>>>> automatically rather than leaving the address alone and routing it > >>>>>> transparently under the covers. Think www.whatever going to > >>>>>> www12.whatever in a server farm, or whatever.com going to > >>>>>> us.whatever.com. You should be doing an end-to-end secure > >>>>>> connection to > >>>>>> the original address and then a separate end-to-end secure > >>>>>> connection to > >>>>>> the redirected address. > >>>>>> > >>>>>> FM > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Sat, 2006-06-03 at 17:32 -0500, James M. Polk wrote: > >>>>>> > >>>>>>> [took Geopriv alias off] > >>>>>>> > >>>>>>> Question - shouldn't we assume in this example that > >>>>> > >>>>> take-out@pizza-hut.com > >>>>> > >>>>>>> is a B2BUA, making it a destination - allowing it to open and > >>>>>>> read the > >>>>>>> S/MIME body? > >>>>>>> > >>>>>>> I'm asking this because this seems like it could be a logical > >>>> > >>>> operation > >>>> > >>>>> of > >>>>> > >>>>>>> Pizza-Hut's SIP infrastructure under the conditions you've laid > >>>>>>> out. > >>>>>>> > >>>>>>> At 11:52 AM 5/22/2006 -0400, Brian Rosen wrote: > >>>>>>> > >>>>>>>> I don't see this as a problem. > >>>>>>>> > >>>>>>>> Let's take the non-emergency case. > >>>>>>>> > >>>>>>>> If I call take-out@pizza-hut.com, and I want location based > >>>>>>>> routing, > >>>> > >>>> I > >>>> > >>>>> put > >>>>> > >>>>>>>> my location header in the call, and send the call with TLS. My > >>>>> > >>>>> outbound > >>>>> > >>>>>>>> proxy will properly ignore it. The pizza-hut domain is the one > >>>>>>>> that > >>>>> > >>>>> wants > >>>>> > >>>>>>>> to do location based routing, it will get the location and send > >> > >> it > >> > >>>> off. > >>>> > >>>>> I > >>>>> > >>>>>>>> don't need to tell it to do that. I could imagine a generic > >>>>>>>> location > >>>>>> > >>>>>> based > >>>>>> > >>>>>>>> routing proxy, but I would not think we would want to mark the > >>>> > >>>> location > >>>> > >>>>>>>> header as the way to get it invoked; we need something else > >>>> > >>>> (directly, > >>>> > >>>>> or > >>>>> > >>>>>>>> indirectly, a Route header) to do that. > >>>>>>>> > >>>>>>>> If I want the endpoint to get it, then I protect it with S/MIME > >>>>>>>> and > >>>> > >>>> no > >>>> > >>>>>> proxy > >>>>>> > >>>>>>>> sees it. > >>>>>>>> > >>>>>>>> Brian > >>>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > >>>>>>>> Sent: Monday, May 22, 2006 10:54 AM > >>>>>>>> To: Brian Rosen; Hannes Tschofenig; sip@ietf.org; > >> > >> geopriv@ietf.org > >> > >>>>>>>> Subject: AW: [Geopriv] Explicit Indication of Location Object > >>>> > >>>> Consumer > >>>> > >>>>>>>> > >>>>>>>> Hi Brian, > >>>>>>>> > >>>>>>>>> I would say no. If the location is not needed by proxies, > >>>>>>>>> then I would say > >>>>>>>>> you MUST protect it (S/MIME), or it will not be private. > >>>>>>>> > >>>>>>>> I am less concerned about the security aspects here and more > >>>>>>>> focused > >>>>> > >>>>> the > >>>>> > >>>>>>>> protocol operation first. > >>>>>>>> Typically, it is good to know for a device whether it has to > >>>>>>>> process > >>>>> > >>>>> the > >>>>> > >>>>>>>> content of the message or not. > >>>>>>>> > >>>>>>>> If you want to prevent intermediaries to inspect your location > >>>>>>>> object > >>>>>>>> then S/MIME might be a choice (at least on paper). > >>>>>>>> > >>>>>>>>> > >>>>>>>>> If you have to route on it (emergency or otherwise), then you > >>>>>>>>> have to send > >>>>>>>>> it with TLS, and the proxies can see it. > >>>>>>>>> > >>>>>>>>> Brian > >>>>>>>> > >>>>>>>> > >>>>>>>> Ciao > >>>>>>>> Hannes > >>>>>>>> > >>>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>>>>>>> Sent: Sunday, May 21, 2006 7:40 AM > >>>>>>>>> To: sip@ietf.org; geopriv@ietf.org > >>>>>>>>> Subject: [Geopriv] Explicit Indication of Location Object > >>>>>>>>> Consumer > >>>>>>>>> > >>>>>>>>> Hi James > >>>>>>>>> Hi Brian, > >>>>>>>>> > >>>>>>>>> do you plan to put additional info into the SIP message to > >>>>>>>>> indicate who > >>>>>>>>> should consume the Location Object (explicity rather than > >>>>>>>>> implicit info)? > >>>>>>>>> > >>>>>>>>> Here is an example: Assume that SIP UA Alice wants to give > >>>>>>>>> Bob location > >>>>>>>>> information (via reference). Now, Alice could easily indicate > >>>>>>>>> that > >>>>> > >>>>> it > >>>>> > >>>>>>>>> wants Bob to resolve the reference and to process the > >>>>>>>>> location object. > >>>>>>>>> Stating this explicitly would prevent proxies to resolve it > >>>>>>>>> and to > >>>>>>>>> process the location object. > >>>>>>>>> > >>>>>>>>> Ciao > >>>>>>>>> Hannes > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> Geopriv mailing list > >>>>>>>>> Geopriv@ietf.org > >>>>>>>>> https://www1.ietf.org/mailman/listinfo/geopriv > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> Geopriv mailing list > >>>>>>>>> Geopriv@ietf.org > >>>>>>>>> https://www1.ietf.org/mailman/listinfo/geopriv > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Geopriv mailing list > >>>>>>>> Geopriv@ietf.org > >>>>>>>> https://www1.ietf.org/mailman/listinfo/geopriv > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>>>>> This list is for NEW development of the core SIP Protocol > >>>>>>> Use sip-implementors@cs.columbia.edu for questions on current sip > >>>>>>> Use sipping@ietf.org for new developments on the application of > >> > >> sip > >> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>> This list is for NEW development of the core SIP Protocol > >>>> Use sip-implementors@cs.columbia.edu for questions on current sip > >>>> Use sipping@ietf.org for new developments on the application of sip > >>> > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol > >>> Use sip-implementors@cs.columbia.edu for questions on current sip > >>> Use sipping@ietf.org for new developments on the application of sip > >> > >> > >> ---------------------------------------------------------------------- > >> -------------------------- > >> This message is for the designated recipient only and may > >> contain privileged, proprietary, or otherwise private information. > >> If you have received it in error, please notify the sender > >> immediately and delete the original. Any unauthorized use of > >> this email is prohibited. > >> ---------------------------------------------------------------------- > >> -------------------------- > >> [mf2] > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > >=20 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 11 08:24:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpOxz-0002PT-Mu; Sun, 11 Jun 2006 08:22:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpOxy-0002PO-2P for sip@ietf.org; Sun, 11 Jun 2006 08:22:54 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FpOxx-0005Vz-44 for sip@ietf.org; Sun, 11 Jun 2006 08:22:54 -0400 Received: (qmail invoked by alias); 11 Jun 2006 12:22:51 -0000 Received: from p54984C53.dip.t-dialin.net (EHLO [192.168.2.32]) [84.152.76.83] by mail.gmx.net (mp029) with SMTP; 11 Jun 2006 14:22:51 +0200 X-Authenticated: #29516787 Message-ID: <448C0B1C.5080803@gmx.net> Date: Sun, 11 Jun 2006 14:22:52 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Winterbottom, James" Subject: Re: [Sip] RE: [Geopriv] Explicit Indication of Location ObjectConsumer References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 835ad9b9deb0975ba747bfa9d7f1aef1 Cc: Cullen Jennings , sip@ietf.org, "James M. Polk" , David R Oran , fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi James, I know all the discussions about location-by-value vs. location-by-reference. I am also seeing the same aspect showing up in other places (e.g., SAML-SIP). It is obvious that some delay is introduced when you use a reference. You certainly have a couple of RTTs and the processing delay to consider. I would like to carry a PIDF-LO and a SAML assertion in a SIP header. Winterbottom, James wrote: > Hi Hannes, > > This is true, it may lead to some delays, but unless you have multiple > nodes making successive requests then the reference is actually superior > in the circumstance mentioned below as only nodes that are entitled to > location can get it. > > If you plonk location in the header then everything that sees the SIP > message can see the location, and this is probably not a good plan. Every SIP proxy sees it, if you use channel security. If > you plonk it in the body then usually the end-point can see it. If you apply E2E encryption. > What if > I only want a routing proxy to be able to see my location, and then only > for routing purposes? > > The other case is that a reference allows the node needing location to > request it in the form needed by the application, sending a literal > value form the end-point pre-supposes that the originator knows the > correct form and they may not. The moment negotiations come into play > through the sending of a 424 response code then using a reference has > the same or fewer message exchanges than the use of a literal location > and the added delay argument become somewhat mythical. I agree that there are some more sophisticated access control mechanisms you can apply. I have no problem to apply these mechanisms if the delay does not matter and the threat scenario demands these properties. > > There are cases for both reference and literal location representation > though I remain unconvinced about supporting a literal location in the > SIP header. Ciao Hannes > > Cheers > James > > > > >>-----Original Message----- >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>Sent: Sunday, 11 June 2006 6:47 PM >>To: David R Oran >>Cc: Winterbottom, James; Cullen Jennings; sip@ietf.org; James M. Polk; >>fwmiller@cornfed.com >>Subject: Re: [Sip] RE: [Geopriv] Explicit Indication of Location >>ObjectConsumer >> >>Hi David, >> >>David R Oran wrote: >> >>>On Jun 10, 2006, at 12:37 AM, Winterbottom, James wrote: >>> >>> >>>>I might point out that in the PSTN today a lot of systems do > > location > >>>>dependent routing without providing the location to the final >>>>destination and I see this as a very useful property. This will be >>>>difficult to perform with S/MIME without a lot of work. >>>> >>> >>>Let's not confuse the location information provided to > > intermediaries > >>>for the purpose of delivering the call where you want, from the >>>location information delivered to the ultimate recipient so that the >>>application running there can do things with that information. As > > I've > >>>argued many times (and I believe the current drafts are in > > alignment > >>>with) these two locations "conveyances" need to be carried > > differently > >>>(in the case of SIP header versus body), any particular SIP message >>>could carry either or both, the confidentiality and integrity >>>properties for the two may be quite different, and even the content >>>might be different (one or the other might be intentionally > > "fuzzed" to > >>>thwart the "target missiles" command). >> >>Would it be acceptable to carry a PIDF-LO in the SIP header? Otherwise >>you always have to create a reference and to let the intermediaries >>fetch the PIDF-LO first. I could imagine that there are cases where > > this > >>could lead to call setup delays. >> >>Ciao >>Hannes >> >> >>>Can we put this one to bed? Please? >>> >>>Dave. >>> >>>P.S. I know those pesky SBCs screw all this up, just like bunches of >>>other stuff that one wishes were really end-to-end. >>> >>> >>> >>>>>-----Original Message----- >>>>>From: Cullen Jennings [mailto:fluffy@cisco.com] >>>>>Sent: Saturday, 10 June 2006 2:08 PM >>>>>To: Brian Rosen >>>>>Cc: sip@ietf.org; 'James M. Polk'; fwmiller@cornfed.com >>>>>Subject: Re: [Sip] RE: [Geopriv] Explicit Indication of Location >>>>>ObjectConsumer >>>>> >>>>> >>>>>A possibly totally irrelevant comment .... >>>>> >>>>>Don't take this as gospel but by best crystal ball gazing at how > > RAI > >>>>>and SEC ADs might look at SIP security items requiring S/MIME .... >>>>>Given the underwhelming implementation and deployment of S/MIME in >>>>>SIP, one would hope there was solutions to achieve some minimal >>>>>level of security that did not rely on S/MIME. If a technique > > could > >>>>>also be secured with S/MIME, or better security could be achieved >>>>>using S/MIME, then making that possible (but not required for the >>>>>minimum) would be fine. >>>>> >>>>>On the topic of proxies looking at bodies (but not modifying > > them), I > >>>>>will point out the end to middle work does some of that. >>>>> >>>>>On Jun 5, 2006, at 1:39 PM, Brian Rosen wrote: >>>>> >>>>> >>>>>>I would strongly prefer to leave this as proxy routes with TLS >>>>>>security. I >>>>>>wouldn't want to preclude an endpoint from routing with S/MIME >>>>>>security, but >>>>>>I don't think that will be common. >>>>>> >>>>>>Brian >>>>>> >>>>>>-----Original Message----- >>>>>>From: James M. Polk [mailto:jmpolk@cisco.com] >>>>>>Sent: Monday, June 05, 2006 3:07 PM >>>>>>To: Brian Rosen; fwmiller@cornfed.com >>>>>>Cc: 'Tschofenig, Hannes'; 'Hannes Tschofenig'; sip@ietf.org >>>>>>Subject: RE: [Sip] RE: [Geopriv] Explicit Indication of Location >>>>>>Object >>>>>>Consumer >>>>>> >>>>>>At 11:12 AM 6/4/2006 -0400, Brian Rosen wrote: >>>>>> >>>>>> >>>>>>>The problem here is S/MIME. No one really uses S/MIME with SIP >>>>>>>because the >>>>>>>PKI is too hard to deal with. This case is just as hard as any >>>>>>>other case. >>>>>>> >>>>>>>I also think PLANNING a B2BUA for this is a bad idea. B2BUAs > > are > >>>>>>>evil. >>>>>> >>>>>> >>>>>>B2BUA's are a reality. That ship's sailed already. >>>>>> >>>>>>No one does this function yet (routing a message based on the >>>>>>location of >>>>>>the caller), so this is greenfield. Someone can write an ID >>>>>>intending to >>>>>>become a BCP that says this is the RECOMMENDED practice of any >>>>>>organization >>>>>>that wants to route based on the location of the caller, since a >>>>>>B2BUA can >>>>>>inspect S/MIME bodies because it IS the desination. At that > > point, > >>>>>>I think >>>>>>a 3XX is a waste of BW, as the more efficient means of >>>>>>communicating with >>>>>>the exact ultimate destination of that take-out@pizza-hut.com > > R-URI > >>>>>>from >>>>>>where you are is determined by that server. >>>>>> >>>>>>Remember, a UA may not have their location by-reference to give > > to > >>>>>>take-out@pizza-hut.com to dereference. That makes the call fail >>>>>>due to not >>>>>>having a route; unless you want a less efficient default route > > that > >>>>>>will >>>>>>never be right, and cause further delay, and possibly has to be >>>>>>designed >>>>>>with user interaction. >>>>>> >>>>>>If the B2BUA still wants to give a 302 back, it still can, once >>>>>>it's read >>>>>>the S/MIME location body. >>>>>> >>>>>> >>>>>> >>>>>>>Brian >>>>>>> >>>>>>>-----Original Message----- >>>>>>>From: James M. Polk [mailto:jmpolk@cisco.com] >>>>>>>Sent: Saturday, June 03, 2006 8:49 PM >>>>>>>To: fwmiller@cornfed.com >>>>>>>Cc: Brian Rosen; 'Tschofenig, Hannes'; 'Hannes Tschofenig'; >>>>>>>sip@ietf.org >>>>>>>Subject: Re: [Sip] RE: [Geopriv] Explicit Indication of Location >>>>>>>Object >>>>>>>Consumer >>>>>>> >>>>>>>weeeeeell.... "take-out@pizza-hut.com" would be the R-URI in > > this > >>>>>>>case, >>>>>>>wouldn't it? I think this has to the case since Brian has no >>>>>>>knowledge >>>>>>>which is the closest Pizza-Hut store to contact directly. >>>>>>> >>>>>>>Given this, S/MIME should still be the correct way to send >>>>>>>location in the >>>>>>>message (e2e). >>>>>>> >>>>>>>A 302 would be the response from take-out@pizza-hut.com. >>>>>>> >>>>>>>This would necessitate a new INVITE to the new URI given in the >>>>>>>302, but >>>>>>>not necessarily including location in that INVITE at all. This > > is > >>>>>>>interesting... I need to think about how this can be >>>> >>>>misused/abused. >>>> >>>> >>>>>>>At 08:14 PM 6/3/2006 -0400, Frank W. Miller wrote: >>>>>>> >>>>>>> >>>>>>>>The Web way would be to redirect the request to another address >>>>>>>>automatically rather than leaving the address alone and routing > > it > >>>>>>>>transparently under the covers. Think www.whatever going to >>>>>>>>www12.whatever in a server farm, or whatever.com going to >>>>>>>>us.whatever.com. You should be doing an end-to-end secure >>>>>>>>connection to >>>>>>>>the original address and then a separate end-to-end secure >>>>>>>>connection to >>>>>>>>the redirected address. >>>>>>>> >>>>>>>>FM >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>On Sat, 2006-06-03 at 17:32 -0500, James M. Polk wrote: >>>>>>>> >>>>>>>> >>>>>>>>>[took Geopriv alias off] >>>>>>>>> >>>>>>>>>Question - shouldn't we assume in this example that >>>>>>> >>>>>>>take-out@pizza-hut.com >>>>>>> >>>>>>> >>>>>>>>>is a B2BUA, making it a destination - allowing it to open and >>>>>>>>>read the >>>>>>>>>S/MIME body? >>>>>>>>> >>>>>>>>>I'm asking this because this seems like it could be a logical >>>>>> >>>>>>operation >>>>>> >>>>>> >>>>>>>of >>>>>>> >>>>>>> >>>>>>>>>Pizza-Hut's SIP infrastructure under the conditions you've > > laid > >>>>>>>>>out. >>>>>>>>> >>>>>>>>>At 11:52 AM 5/22/2006 -0400, Brian Rosen wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>>I don't see this as a problem. >>>>>>>>>> >>>>>>>>>>Let's take the non-emergency case. >>>>>>>>>> >>>>>>>>>>If I call take-out@pizza-hut.com, and I want location based >>>>>>>>>>routing, >>>>>> >>>>>>I >>>>>> >>>>>> >>>>>>>put >>>>>>> >>>>>>> >>>>>>>>>>my location header in the call, and send the call with TLS. > > My > >>>>>>>outbound >>>>>>> >>>>>>> >>>>>>>>>>proxy will properly ignore it. The pizza-hut domain is the > > one > >>>>>>>>>>that >>>>>>> >>>>>>>wants >>>>>>> >>>>>>> >>>>>>>>>>to do location based routing, it will get the location and > > send > >>>>it >>>> >>>> >>>>>>off. >>>>>> >>>>>> >>>>>>>I >>>>>>> >>>>>>> >>>>>>>>>>don't need to tell it to do that. I could imagine a generic >>>>>>>>>>location >>>>>>>> >>>>>>>>based >>>>>>>> >>>>>>>> >>>>>>>>>>routing proxy, but I would not think we would want to mark > > the > >>>>>>location >>>>>> >>>>>> >>>>>>>>>>header as the way to get it invoked; we need something else >>>>>> >>>>>>(directly, >>>>>> >>>>>> >>>>>>>or >>>>>>> >>>>>>> >>>>>>>>>>indirectly, a Route header) to do that. >>>>>>>>>> >>>>>>>>>>If I want the endpoint to get it, then I protect it with > > S/MIME > >>>>>>>>>>and >>>>>> >>>>>>no >>>>>> >>>>>> >>>>>>>>proxy >>>>>>>> >>>>>>>> >>>>>>>>>>sees it. >>>>>>>>>> >>>>>>>>>>Brian >>>>>>>>>> >>>>>>>>>>-----Original Message----- >>>>>>>>>>From: Tschofenig, Hannes > > [mailto:hannes.tschofenig@siemens.com] > >>>>>>>>>>Sent: Monday, May 22, 2006 10:54 AM >>>>>>>>>>To: Brian Rosen; Hannes Tschofenig; sip@ietf.org; >>>> >>>>geopriv@ietf.org >>>> >>>> >>>>>>>>>>Subject: AW: [Geopriv] Explicit Indication of Location Object >>>>>> >>>>>>Consumer >>>>>> >>>>>> >>>>>>>>>>Hi Brian, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>I would say no. If the location is not needed by proxies, >>>>>>>>>>>then I would say >>>>>>>>>>>you MUST protect it (S/MIME), or it will not be private. >>>>>>>>>> >>>>>>>>>>I am less concerned about the security aspects here and more >>>>>>>>>>focused >>>>>>> >>>>>>>the >>>>>>> >>>>>>> >>>>>>>>>>protocol operation first. >>>>>>>>>>Typically, it is good to know for a device whether it has to >>>>>>>>>>process >>>>>>> >>>>>>>the >>>>>>> >>>>>>> >>>>>>>>>>content of the message or not. >>>>>>>>>> >>>>>>>>>>If you want to prevent intermediaries to inspect your > > location > >>>>>>>>>>object >>>>>>>>>>then S/MIME might be a choice (at least on paper). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>If you have to route on it (emergency or otherwise), then > > you > >>>>>>>>>>>have to send >>>>>>>>>>>it with TLS, and the proxies can see it. >>>>>>>>>>> >>>>>>>>>>>Brian >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>Ciao >>>>>>>>>>Hannes >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>-----Original Message----- >>>>>>>>>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>>>>>Sent: Sunday, May 21, 2006 7:40 AM >>>>>>>>>>>To: sip@ietf.org; geopriv@ietf.org >>>>>>>>>>>Subject: [Geopriv] Explicit Indication of Location Object >>>>>>>>>>>Consumer >>>>>>>>>>> >>>>>>>>>>>Hi James >>>>>>>>>>>Hi Brian, >>>>>>>>>>> >>>>>>>>>>>do you plan to put additional info into the SIP message to >>>>>>>>>>>indicate who >>>>>>>>>>>should consume the Location Object (explicity rather than >>>>>>>>>>>implicit info)? >>>>>>>>>>> >>>>>>>>>>>Here is an example: Assume that SIP UA Alice wants to give >>>>>>>>>>>Bob location >>>>>>>>>>>information (via reference). Now, Alice could easily > > indicate > >>>>>>>>>>>that >>>>>>> >>>>>>>it >>>>>>> >>>>>>> >>>>>>>>>>>wants Bob to resolve the reference and to process the >>>>>>>>>>>location object. >>>>>>>>>>>Stating this explicitly would prevent proxies to resolve it >>>>>>>>>>>and to >>>>>>>>>>>process the location object. >>>>>>>>>>> >>>>>>>>>>>Ciao >>>>>>>>>>>Hannes >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>_______________________________________________ >>>>>>>>>>>Geopriv mailing list >>>>>>>>>>>Geopriv@ietf.org >>>>>>>>>>>https://www1.ietf.org/mailman/listinfo/geopriv >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>_______________________________________________ >>>>>>>>>>>Geopriv mailing list >>>>>>>>>>>Geopriv@ietf.org >>>>>>>>>>>https://www1.ietf.org/mailman/listinfo/geopriv >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>_______________________________________________ >>>>>>>>>>Geopriv mailing list >>>>>>>>>>Geopriv@ietf.org >>>>>>>>>>https://www1.ietf.org/mailman/listinfo/geopriv >>>>>>>>> >>>>>>>>> >>>>>>>>>_______________________________________________ >>>>>>>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>>>>This list is for NEW development of the core SIP Protocol >>>>>>>>>Use sip-implementors@cs.columbia.edu for questions on current > > sip > >>>>>>>>>Use sipping@ietf.org for new developments on the application > > of > >>>>sip >>>> >>>> >>>>>> >>>>>>_______________________________________________ >>>>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>This list is for NEW development of the core SIP Protocol >>>>>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>>>>Use sipping@ietf.org for new developments on the application of > > sip > >>>>> >>>>>_______________________________________________ >>>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>This list is for NEW development of the core SIP Protocol >>>>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>>>Use sipping@ietf.org for new developments on the application of > > sip > >>>> >>>> > ---------------------------------------------------------------------- > >>>>-------------------------- >>>>This message is for the designated recipient only and may >>>>contain privileged, proprietary, or otherwise private information. >>>>If you have received it in error, please notify the sender >>>>immediately and delete the original. Any unauthorized use of >>>>this email is prohibited. >>>> > > ---------------------------------------------------------------------- > >>>>-------------------------- >>>>[mf2] >>>> >>>>_______________________________________________ >>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>This list is for NEW development of the core SIP Protocol >>>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>>Use sipping@ietf.org for new developments on the application of sip >>> >>> >>>_______________________________________________ >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sipping@ietf.org for new developments on the application of sip >>> >>> >> > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 11 09:22:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpPrS-0006aL-AM; Sun, 11 Jun 2006 09:20:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpPrQ-0006Pc-5V for sip@ietf.org; Sun, 11 Jun 2006 09:20:12 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpPrO-0003Ll-Ve for sip@ietf.org; Sun, 11 Jun 2006 09:20:12 -0400 Received: from [192.168.0.41] (pool-138-89-46-232.mad.east.verizon.net [138.89.46.232]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k5BDJn4q016584 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sun, 11 Jun 2006 09:19:53 -0400 (EDT) In-Reply-To: <448BD89E.7070201@gmx.net> References: <7CDE1E03-EBD3-42AB-A777-4442CA8395BE@cisco.com> <448BD89E.7070201@gmx.net> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4B4AA2FB-3310-49B1-8504-9AB4CDD06243@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Sip] RE: [Geopriv] Explicit Indication of Location ObjectConsumer Date: Sun, 11 Jun 2006 09:19:47 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.750) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Cullen Jennings , sip@ietf.org, "James M. Polk" , David R Oran , fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > Would it be acceptable to carry a PIDF-LO in the SIP header? > Otherwise you always have to create a reference and to let the > intermediaries fetch the PIDF-LO first. I could imagine that there > are cases where this could lead to call setup delays. Also, not all UAs have a convenient way to "park" such information. Most companies, for example, would have to set up a web server outside their firewall for this purpose. I don't see any particular reason why you couldn't carry a base-64 encoded version of a PIDF-LO object in a header. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 11 09:33:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpQ2H-0005sG-Qg; Sun, 11 Jun 2006 09:31:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpQ2G-0005s6-2C for sip@ietf.org; Sun, 11 Jun 2006 09:31:24 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpQ2F-0003hc-Dd for sip@ietf.org; Sun, 11 Jun 2006 09:31:24 -0400 Received: from [192.168.0.41] (pool-138-89-46-232.mad.east.verizon.net [138.89.46.232]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k5BDVAOO009400 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sun, 11 Jun 2006 09:31:11 -0400 (EDT) In-Reply-To: <448C0B1C.5080803@gmx.net> References: <448C0B1C.5080803@gmx.net> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Sip] RE: [Geopriv] Explicit Indication of Location ObjectConsumer Date: Sun, 11 Jun 2006 09:31:08 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.750) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ce0328cdf9c90e4680655d09dccace5 Cc: Cullen Jennings , "James M. Polk" , sip@ietf.org, David R Oran , fwmiller@cornfed.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org We should just have this location/value debate by reference, as in "argument 42", "no, argument 17!!!". However, the access control one is a red herring. If you can supply the proxy with a secret to query the LIS, you can also set up a public-private key pair for that routing proxy to unwrap the location information. (This does not require a public CA.) In most cases, this is unrealistic. The examples of location-based routing include services such as pizza delivery, and there's no way (and no mechanism) that I'm going to give PizzaHut a password to my LIS. At least with a public key mechanism, I could in theory encrypt the PIDF-LO with the public key of Pizza Hut, so that the NSA agent sitting at the local VSP won't know where I want my pizza sent. Thus, if we're having this discussion again, we might want to more clearly identify the trust relationships assumed. On Jun 11, 2006, at 8:22 AM, Hannes Tschofenig wrote: > Hi James, > > I know all the discussions about location-by-value vs. location-by- > reference. I am also seeing the same aspect showing up in other > places (e.g., SAML-SIP). > > It is obvious that some delay is introduced when you use a > reference. You certainly have a couple of RTTs and the processing > delay to consider. > > I would like to carry a PIDF-LO and a SAML assertion in a SIP header. > > Winterbottom, James wrote: >> Hi Hannes, >> This is true, it may lead to some delays, but unless you have >> multiple >> nodes making successive requests then the reference is actually >> superior >> in the circumstance mentioned below as only nodes that are >> entitled to >> location can get it. >> If you plonk location in the header then everything that sees the SIP >> message can see the location, and this is probably not a good plan. > > Every SIP proxy sees it, if you use channel security. > > If >> you plonk it in the body then usually the end-point can see it. > > If you apply E2E encryption. > >> What if >> I only want a routing proxy to be able to see my location, and >> then only >> for routing purposes? The other case is that a reference allows >> the node needing location to >> request it in the form needed by the application, sending a literal >> value form the end-point pre-supposes that the originator knows the >> correct form and they may not. The moment negotiations come into play >> through the sending of a 424 response code then using a reference has >> the same or fewer message exchanges than the use of a literal >> location >> and the added delay argument become somewhat mythical. > > I agree that there are some more sophisticated access control > mechanisms you can apply. I have no problem to apply these > mechanisms if the delay does not matter and the threat scenario > demands these properties. > >> There are cases for both reference and literal location >> representation >> though I remain unconvinced about supporting a literal location in >> the >> SIP header. > > > Ciao > Hannes > > > > >> Cheers >> James >> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: Sunday, 11 June 2006 6:47 PM >>> To: David R Oran >>> Cc: Winterbottom, James; Cullen Jennings; sip@ietf.org; James M. >>> Polk; >>> fwmiller@cornfed.com >>> Subject: Re: [Sip] RE: [Geopriv] Explicit Indication of Location >>> ObjectConsumer >>> >>> Hi David, >>> >>> David R Oran wrote: >>> >>>> On Jun 10, 2006, at 12:37 AM, Winterbottom, James wrote: >>>> >>>> >>>>> I might point out that in the PSTN today a lot of systems do >> location >>>>> dependent routing without providing the location to the final >>>>> destination and I see this as a very useful property. This will be >>>>> difficult to perform with S/MIME without a lot of work. >>>>> >>>> >>>> Let's not confuse the location information provided to >> intermediaries >>>> for the purpose of delivering the call where you want, from the >>>> location information delivered to the ultimate recipient so that >>>> the >>>> application running there can do things with that information. As >> I've >>>> argued many times (and I believe the current drafts are in >> alignment >>>> with) these two locations "conveyances" need to be carried >> differently >>>> (in the case of SIP header versus body), any particular SIP >>>> message >>>> could carry either or both, the confidentiality and integrity >>>> properties for the two may be quite different, and even the >>>> content >>>> might be different (one or the other might be intentionally >> "fuzzed" to >>>> thwart the "target missiles" command). >>> >>> Would it be acceptable to carry a PIDF-LO in the SIP header? >>> Otherwise >>> you always have to create a reference and to let the intermediaries >>> fetch the PIDF-LO first. I could imagine that there are cases where >> this >>> could lead to call setup delays. >>> >>> Ciao >>> Hannes >>> >>> >>>> Can we put this one to bed? Please? >>>> >>>> Dave. >>>> >>>> P.S. I know those pesky SBCs screw all this up, just like >>>> bunches of >>>> other stuff that one wishes were really end-to-end. >>>> >>>> >>>> >>>>>> -----Original Message----- >>>>>> From: Cullen Jennings [mailto:fluffy@cisco.com] >>>>>> Sent: Saturday, 10 June 2006 2:08 PM >>>>>> To: Brian Rosen >>>>>> Cc: sip@ietf.org; 'James M. Polk'; fwmiller@cornfed.com >>>>>> Subject: Re: [Sip] RE: [Geopriv] Explicit Indication of Location >>>>>> ObjectConsumer >>>>>> >>>>>> >>>>>> A possibly totally irrelevant comment .... >>>>>> >>>>>> Don't take this as gospel but by best crystal ball gazing at how >> RAI >>>>>> and SEC ADs might look at SIP security items requiring S/ >>>>>> MIME .... >>>>>> Given the underwhelming implementation and deployment of S/ >>>>>> MIME in >>>>>> SIP, one would hope there was solutions to achieve some minimal >>>>>> level of security that did not rely on S/MIME. If a technique >> could >>>>>> also be secured with S/MIME, or better security could be achieved >>>>>> using S/MIME, then making that possible (but not required for the >>>>>> minimum) would be fine. >>>>>> >>>>>> On the topic of proxies looking at bodies (but not modifying >> them), I >>>>>> will point out the end to middle work does some of that. >>>>>> >>>>>> On Jun 5, 2006, at 1:39 PM, Brian Rosen wrote: >>>>>> >>>>>> >>>>>>> I would strongly prefer to leave this as proxy routes with TLS >>>>>>> security. I >>>>>>> wouldn't want to preclude an endpoint from routing with S/MIME >>>>>>> security, but >>>>>>> I don't think that will be common. >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: James M. Polk [mailto:jmpolk@cisco.com] >>>>>>> Sent: Monday, June 05, 2006 3:07 PM >>>>>>> To: Brian Rosen; fwmiller@cornfed.com >>>>>>> Cc: 'Tschofenig, Hannes'; 'Hannes Tschofenig'; sip@ietf.org >>>>>>> Subject: RE: [Sip] RE: [Geopriv] Explicit Indication of Location >>>>>>> Object >>>>>>> Consumer >>>>>>> >>>>>>> At 11:12 AM 6/4/2006 -0400, Brian Rosen wrote: >>>>>>> >>>>>>> >>>>>>>> The problem here is S/MIME. No one really uses S/MIME with SIP >>>>>>>> because the >>>>>>>> PKI is too hard to deal with. This case is just as hard as any >>>>>>>> other case. >>>>>>>> >>>>>>>> I also think PLANNING a B2BUA for this is a bad idea. B2BUAs >> are >>>>>>>> evil. >>>>>>> >>>>>>> >>>>>>> B2BUA's are a reality. That ship's sailed already. >>>>>>> >>>>>>> No one does this function yet (routing a message based on the >>>>>>> location of >>>>>>> the caller), so this is greenfield. Someone can write an ID >>>>>>> intending to >>>>>>> become a BCP that says this is the RECOMMENDED practice of any >>>>>>> organization >>>>>>> that wants to route based on the location of the caller, since a >>>>>>> B2BUA can >>>>>>> inspect S/MIME bodies because it IS the desination. At that >> point, >>>>>>> I think >>>>>>> a 3XX is a waste of BW, as the more efficient means of >>>>>>> communicating with >>>>>>> the exact ultimate destination of that take-out@pizza-hut.com >> R-URI >>>>>>> from >>>>>>> where you are is determined by that server. >>>>>>> >>>>>>> Remember, a UA may not have their location by-reference to give >> to >>>>>>> take-out@pizza-hut.com to dereference. That makes the call fail >>>>>>> due to not >>>>>>> having a route; unless you want a less efficient default route >> that >>>>>>> will >>>>>>> never be right, and cause further delay, and possibly has to be >>>>>>> designed >>>>>>> with user interaction. >>>>>>> >>>>>>> If the B2BUA still wants to give a 302 back, it still can, once >>>>>>> it's read >>>>>>> the S/MIME location body. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: James M. Polk [mailto:jmpolk@cisco.com] >>>>>>>> Sent: Saturday, June 03, 2006 8:49 PM >>>>>>>> To: fwmiller@cornfed.com >>>>>>>> Cc: Brian Rosen; 'Tschofenig, Hannes'; 'Hannes Tschofenig'; >>>>>>>> sip@ietf.org >>>>>>>> Subject: Re: [Sip] RE: [Geopriv] Explicit Indication of >>>>>>>> Location >>>>>>>> Object >>>>>>>> Consumer >>>>>>>> >>>>>>>> weeeeeell.... "take-out@pizza-hut.com" would be the R-URI in >> this >>>>>>>> case, >>>>>>>> wouldn't it? I think this has to the case since Brian has no >>>>>>>> knowledge >>>>>>>> which is the closest Pizza-Hut store to contact directly. >>>>>>>> >>>>>>>> Given this, S/MIME should still be the correct way to send >>>>>>>> location in the >>>>>>>> message (e2e). >>>>>>>> >>>>>>>> A 302 would be the response from take-out@pizza-hut.com. >>>>>>>> >>>>>>>> This would necessitate a new INVITE to the new URI given in the >>>>>>>> 302, but >>>>>>>> not necessarily including location in that INVITE at all. This >> is >>>>>>>> interesting... I need to think about how this can be >>>>> >>>>> misused/abused. >>>>> >>>>> >>>>>>>> At 08:14 PM 6/3/2006 -0400, Frank W. Miller wrote: >>>>>>>> >>>>>>>> >>>>>>>>> The Web way would be to redirect the request to another >>>>>>>>> address >>>>>>>>> automatically rather than leaving the address alone and >>>>>>>>> routing >> it >>>>>>>>> transparently under the covers. Think www.whatever going to >>>>>>>>> www12.whatever in a server farm, or whatever.com going to >>>>>>>>> us.whatever.com. You should be doing an end-to-end secure >>>>>>>>> connection to >>>>>>>>> the original address and then a separate end-to-end secure >>>>>>>>> connection to >>>>>>>>> the redirected address. >>>>>>>>> >>>>>>>>> FM >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sat, 2006-06-03 at 17:32 -0500, James M. Polk wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> [took Geopriv alias off] >>>>>>>>>> >>>>>>>>>> Question - shouldn't we assume in this example that >>>>>>>> >>>>>>>> take-out@pizza-hut.com >>>>>>>> >>>>>>>> >>>>>>>>>> is a B2BUA, making it a destination - allowing it to open and >>>>>>>>>> read the >>>>>>>>>> S/MIME body? >>>>>>>>>> >>>>>>>>>> I'm asking this because this seems like it could be a logical >>>>>>> >>>>>>> operation >>>>>>> >>>>>>> >>>>>>>> of >>>>>>>> >>>>>>>> >>>>>>>>>> Pizza-Hut's SIP infrastructure under the conditions you've >> laid >>>>>>>>>> out. >>>>>>>>>> >>>>>>>>>> At 11:52 AM 5/22/2006 -0400, Brian Rosen wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> I don't see this as a problem. >>>>>>>>>>> >>>>>>>>>>> Let's take the non-emergency case. >>>>>>>>>>> >>>>>>>>>>> If I call take-out@pizza-hut.com, and I want location based >>>>>>>>>>> routing, >>>>>>> >>>>>>> I >>>>>>> >>>>>>> >>>>>>>> put >>>>>>>> >>>>>>>> >>>>>>>>>>> my location header in the call, and send the call with TLS. >> My >>>>>>>> outbound >>>>>>>> >>>>>>>> >>>>>>>>>>> proxy will properly ignore it. The pizza-hut domain is the >> one >>>>>>>>>>> that >>>>>>>> >>>>>>>> wants >>>>>>>> >>>>>>>> >>>>>>>>>>> to do location based routing, it will get the location and >> send >>>>> it >>>>> >>>>> >>>>>>> off. >>>>>>> >>>>>>> >>>>>>>> I >>>>>>>> >>>>>>>> >>>>>>>>>>> don't need to tell it to do that. I could imagine a generic >>>>>>>>>>> location >>>>>>>>> >>>>>>>>> based >>>>>>>>> >>>>>>>>> >>>>>>>>>>> routing proxy, but I would not think we would want to mark >> the >>>>>>> location >>>>>>> >>>>>>> >>>>>>>>>>> header as the way to get it invoked; we need something else >>>>>>> >>>>>>> (directly, >>>>>>> >>>>>>> >>>>>>>> or >>>>>>>> >>>>>>>> >>>>>>>>>>> indirectly, a Route header) to do that. >>>>>>>>>>> >>>>>>>>>>> If I want the endpoint to get it, then I protect it with >> S/MIME >>>>>>>>>>> and >>>>>>> >>>>>>> no >>>>>>> >>>>>>> >>>>>>>>> proxy >>>>>>>>> >>>>>>>>> >>>>>>>>>>> sees it. >>>>>>>>>>> >>>>>>>>>>> Brian >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Tschofenig, Hannes >> [mailto:hannes.tschofenig@siemens.com] >>>>>>>>>>> Sent: Monday, May 22, 2006 10:54 AM >>>>>>>>>>> To: Brian Rosen; Hannes Tschofenig; sip@ietf.org; >>>>> >>>>> geopriv@ietf.org >>>>> >>>>> >>>>>>>>>>> Subject: AW: [Geopriv] Explicit Indication of Location >>>>>>>>>>> Object >>>>>>> >>>>>>> Consumer >>>>>>> >>>>>>> >>>>>>>>>>> Hi Brian, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> I would say no. If the location is not needed by proxies, >>>>>>>>>>>> then I would say >>>>>>>>>>>> you MUST protect it (S/MIME), or it will not be private. >>>>>>>>>>> >>>>>>>>>>> I am less concerned about the security aspects here and more >>>>>>>>>>> focused >>>>>>>> >>>>>>>> the >>>>>>>> >>>>>>>> >>>>>>>>>>> protocol operation first. >>>>>>>>>>> Typically, it is good to know for a device whether it has to >>>>>>>>>>> process >>>>>>>> >>>>>>>> the >>>>>>>> >>>>>>>> >>>>>>>>>>> content of the message or not. >>>>>>>>>>> >>>>>>>>>>> If you want to prevent intermediaries to inspect your >> location >>>>>>>>>>> object >>>>>>>>>>> then S/MIME might be a choice (at least on paper). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> If you have to route on it (emergency or otherwise), then >> you >>>>>>>>>>>> have to send >>>>>>>>>>>> it with TLS, and the proxies can see it. >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Ciao >>>>>>>>>>> Hannes >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>>>>>> Sent: Sunday, May 21, 2006 7:40 AM >>>>>>>>>>>> To: sip@ietf.org; geopriv@ietf.org >>>>>>>>>>>> Subject: [Geopriv] Explicit Indication of Location Object >>>>>>>>>>>> Consumer >>>>>>>>>>>> >>>>>>>>>>>> Hi James >>>>>>>>>>>> Hi Brian, >>>>>>>>>>>> >>>>>>>>>>>> do you plan to put additional info into the SIP message to >>>>>>>>>>>> indicate who >>>>>>>>>>>> should consume the Location Object (explicity rather than >>>>>>>>>>>> implicit info)? >>>>>>>>>>>> >>>>>>>>>>>> Here is an example: Assume that SIP UA Alice wants to give >>>>>>>>>>>> Bob location >>>>>>>>>>>> information (via reference). Now, Alice could easily >> indicate >>>>>>>>>>>> that >>>>>>>> >>>>>>>> it >>>>>>>> >>>>>>>> >>>>>>>>>>>> wants Bob to resolve the reference and to process the >>>>>>>>>>>> location object. >>>>>>>>>>>> Stating this explicitly would prevent proxies to resolve it >>>>>>>>>>>> and to >>>>>>>>>>>> process the location object. >>>>>>>>>>>> >>>>>>>>>>>> Ciao >>>>>>>>>>>> Hannes >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Geopriv mailing list >>>>>>>>>>>> Geopriv@ietf.org >>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/geopriv >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Geopriv mailing list >>>>>>>>>>>> Geopriv@ietf.org >>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/geopriv >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Geopriv mailing list >>>>>>>>>>> Geopriv@ietf.org >>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/geopriv >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>>>>> This list is for NEW development of the core SIP Protocol >>>>>>>>>> Use sip-implementors@cs.columbia.edu for questions on current >> sip >>>>>>>>>> Use sipping@ietf.org for new developments on the application >> of >>>>> sip >>>>> >>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>> This list is for NEW development of the core SIP Protocol >>>>>>> Use sip-implementors@cs.columbia.edu for questions on current >>>>>>> sip >>>>>>> Use sipping@ietf.org for new developments on the application of >> sip >>>>>> >>>>>> _______________________________________________ >>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>> This list is for NEW development of the core SIP Protocol >>>>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>>>> Use sipping@ietf.org for new developments on the application of >> sip >>>>> >>>>> >> --------------------------------------------------------------------- >> - >>>>> -------------------------- >>>>> This message is for the designated recipient only and may >>>>> contain privileged, proprietary, or otherwise private information. >>>>> If you have received it in error, please notify the sender >>>>> immediately and delete the original. Any unauthorized use of >>>>> this email is prohibited. >>>>> >> --------------------------------------------------------------------- >> - >>>>> -------------------------- >>>>> [mf2] >>>>> >>>>> _______________________________________________ >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP Protocol >>>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>>> Use sipping@ietf.org for new developments on the application of >>>>> sip >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the application of sip >>>> >>>> >>> >> --------------------------------------------------------------------- >> --------------------------- >> This message is for the designated recipient only and may >> contain privileged, proprietary, or otherwise private >> information. If you have received it in error, please notify the >> sender >> immediately and delete the original. Any unauthorized use of >> this email is prohibited. >> --------------------------------------------------------------------- >> --------------------------- >> [mf2] > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 11 09:46:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpQEw-0003vI-5x; Sun, 11 Jun 2006 09:44:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpQEu-0003vB-9h for sip@ietf.org; Sun, 11 Jun 2006 09:44:28 -0400 Received: from mailhost.iperia.com ([204.57.52.4] helo=iperia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpQEt-0005bU-1W for sip@ietf.org; Sun, 11 Jun 2006 09:44:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Supported: in ACK Date: Sun, 11 Jun 2006 09:44:23 -0400 Message-ID: <8019F8581B5FC14DBD94BAF86844868ECB551B@viridis.IPeria.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Supported: in ACK Thread-Index: AcaNJ9nCr37deBQXQX+6l3Gywp79kgANIG7g From: "Gordon Ledgard" To: "Dean Willis" , "Sip IETF" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Sunday, June 11, 2006 3:23 AM > To: Sip IETF > Subject: [Sip] Supported: in ACK >=20 >=20 > So, I'm having a Table 2 debate with Joel R., who notices these > things. I don't like RFC 3261's Table 2 much, as you may recall . . . >=20 > Can you or should you include a Supported or Require header in an ACK > request? >=20 > Table 2 says "Not applicable", if I'm reading it right. >=20 > RFC 3261 says: >=20 > If the UAC supports extensions to SIP that can be applied by the > server to the response, the UAC SHOULD include a Supported header > field in the request listing the option tags (Section 19.2) for > those > extensions. >=20 > And some of our extensions, at least some of the proposed extensions, > might actually apply to ACK -- OTOH, there's not a response to ACK, > so I'm perplexed as to how the Supported: header would be applied by > the server to the response, since there isn't one. >=20 > JDR has, if I understand him, said several times that one includes > Supported: with all extensions in every request, and ACK is a > request, sort of. "Sort of" is correct. In fact, I would say that, other that the direction of propagation, there is almost nothing about the ACK that is truly a request. >=20 > And, some published examples apparently include Supported: in ACK. > Should they? >=20 What are the extensions that would apply to ACK wherein it would not be appropriate or desirable to have placed the "Supported" in the preceding Request? > -- > Dean >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 11 13:24:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpTe3-0007ef-3X; Sun, 11 Jun 2006 13:22:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpTe2-0007ea-0V for sip@ietf.org; Sun, 11 Jun 2006 13:22:38 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpTe0-0002nA-Gb for sip@ietf.org; Sun, 11 Jun 2006 13:22:37 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 11 Jun 2006 13:22:37 -0400 X-IronPort-AV: i="4.05,227,1146456000"; d="scan'208"; a="89769597:sNHT34658892" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5BHMano016331; Sun, 11 Jun 2006 13:22:36 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 11 Jun 2006 13:22:36 -0400 Received: from [10.86.240.133] ([10.86.240.133]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 11 Jun 2006 13:22:35 -0400 Message-ID: <448C515A.6090805@cisco.com> Date: Sun, 11 Jun 2006 13:22:34 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Gerald Yan Subject: Re: =?GB2312?B?tPC4tDogW1NpcF0gUkZDIDQwMjggKFNlc3Npb24gVGltZXIpIA==?= =?GB2312?B?cmVsYXRlZCBxdWVzdGlvbg==?= References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 11 Jun 2006 17:22:35.0515 (UTC) FILETIME=[A16914B0:01C68D7B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Gerald Yan wrote: > I have another question about RFC 4028. > In section 7.2: > "It is possible that the UAC requested the session timer (and thus included a Session-Expires header field in the request) and that there was no Require or Session-Expires header field in the 2xx response. This will happen when the UAS doesn't support the session timer extension and only the UAC has asked for a session timer (no proxies have requested it). In this case, if the UAC still wishes to use the session timer (which is purely for its benefit alone), it has to perform them. " > "If the 2xx response did not contain a Session-Expires header field, there is no session expiration. In this case, no refreshes need to be sent. A 2xx without a Session-Expires can come for both initial and subsequent session refresh requests. This means that the session timer can be 'turned-off' in mid dialog by receiving a response without a Session-Expires header field." > My question is that how does UAC know the 2xx response without a Session-Expires header is for "turning off" session timer or a just response from a UAS which doesn't support session timer. The presence of a Session-Expires in the 2xx response strikes an agreement between two parties to have a session timer. It might be between the UAC and the UAS, or between the UAC and a proxy, or between the UAS and a proxy. The absence of the Session-Expires in the 2xx means there is no agreement to do session timer. This does not prevent the UAC from periodically doing a reinvite, just as if there *had* been a session timer with it as the refresher, but technically this is not as a result of a session timer. This highlights a point that I keep raising, because many/most people don't seem to get it: the session timer is for the convenience of proxies that can't initiate reinvites on their own. There is no reason for a UA to *request* a session timer, though there is value in indicating support for it. Paul > Best regards > Gerald > > > -----ÓʼþÔ­¼þ----- > ·¢¼þÈË: Paul Kyzivat [mailto:pkyzivat@cisco.com] > ·¢ËÍʱ¼ä: 2006Äê5ÔÂ17ÈÕ 3:00 > ÊÕ¼þÈË: Sergey Markovich > ³­ËÍ: sip@ietf.org > Ö÷Ìâ: Re: [Sip] RFC 4028 (Session Timer) related question > > Sergey, > > In the situation you describe there is no value to using the session > timer mechanism. Since A is a (B2B)UA, it is free to send a reinvite any > time it wants to check on its session with B or C. To do this without > perturbing the call, it can send an offerless reinvite to B, take the > answer and send it as an offer in a reinvite to C, etc. > > Or it could simplify and simply send an OPTIONS periodically to B and C. > > Session-Timer is really only of importance to stateful proxies. > > Paul > > Sergey Markovich wrote: >> Paul, >> >> I checked with our customer. A is a server but it is B2BUA and not a proxy. >> >> A is interested to know that B is alive. So there is no proxy. So the >> scenario is the following: >> >> 1. B and C are endpoints. They do not know anything about Session >> Timer mechanism. >> 2. A is a B2BUA. It implements Session Timer mechanism. >> 3. C calls A, A calls B, both calls are established. >> 4. A is sending reINVITEs with "Session-Expires" header to B >> periodically. B is replying with OK without "Session-Expires" or >> "Supported:timer", i.e. B does not support the Session Timer mechanism, >> A is a refresher. >> >> 5. Probably the same happens between A and C (on the other leg of >> B2BUA) >> 6. B puts A on hold, i.e. it sends SDP related reINVITE without >> "Session-Expires" or "Supported:timer" >> 7. A replies with OK without "Session-Expires" and it >> stops(disables) the mechanism, i.e. no session timer related callbacks >> anymore, the application does not do refresh (does not send reINVITEs) >> anymore. >> >> Thank you, >> >> Sergey >> >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Tuesday, May 16, 2006 12:16 PM >> To: Sergey Markovich >> Cc: sip@ietf.org >> Subject: Re: [Sip] RFC 4028 (Session Timer) related question >> >> Sergy, >> >> Can you restate your problem, showing both UAs and the proxy, and what >> >> each does? >> >> Paul >> >> Sergey Markovich wrote: >> >>> Paul, >>> A is a proxy in this scenario. Probably I was wrong when I said "A calls >>> B". A just forwards initial INVITE from somebody else to B. B is an >>> endpoint. >>> Sergey >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: Monday, May 15, 2006 5:46 PM >>> To: Sergey Markovich >>> Cc: sip@ietf.org >>> Subject: Re: [Sip] RFC 4028 (Session Timer) related question >>> Sergey, >>> For this scenario to make sense there should be a proxy involved that is >>> interested in having a session timer. If there was, then it would insert >>> a Session-Expires into reinvite of step 4, and A would respond, >>> reestablishing the timer. >>> If there is no proxy doing this, then there is no need for a session >>> timer to be established. If A wants to periodically check the status of >>> the session, it may do so an any time by sending a reinvite. >>> Paul >>> Sergey Markovich wrote: >>>> We have the following scenario: >>>> 1. A has Session Timer mechanism enabled. >>>> 2. A calls B, the call is established >>>> 3. A is sending reINVITEs with "Session-Expires" header to B >>>> periodically. B is replying with OK without "Session-Expires" or >>>> "Supported:timer", i.e. B does not support the Session Timer >>> mechanism, >>>> A is a refresher. >>>> 4. B puts A on hold, i.e. it sends SDP related reINVITE without >>>> "Session-Expires" or "Supported:timer" >>>> 5. A replies with OK without "Session-Expires" and it stops >>>> (disables) the mechanism, i.e. no session timer related callbacks >>>> anymore, the application does not do refresh (does not send reINVITEs) >>>> anymore. >>>> I am not sure that step 5 is RFC 4028 compliant. >>>> I know that the default value of "Session-Expires" is infinity, but I >>>> think it makes sense only when the sending party (B) DOES support the >>>> mechanism (i.e. does include "Supported:timer", but does not include >>>> "Session-Expires" in the reINVITE). In that case the reINVITE can be >>>> used for the negotiation of the mechanism parameters. But in our case >>>> the reINVITE from step 4 has to be treated as "refresh" only (because >>>> after step 4 A knows that B is alive). So A has to restart the timer >>> but >>>> not to disable the mechanism. >>>> It would be appreciated if you comment what should we do in step 5. >>>> Thanks a lot, >>>> Sergey >>> ------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the application of sip >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 11 19:10:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZ2y-0006ll-89; Sun, 11 Jun 2006 19:08:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZ2w-0006lb-Ms for sip@ietf.org; Sun, 11 Jun 2006 19:08:42 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpZ2s-0001p7-7w for sip@ietf.org; Sun, 11 Jun 2006 19:08:42 -0400 Received: (qmail 7662 invoked by uid 0); 11 Jun 2006 23:08:32 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 11 Jun 2006 23:08:32 -0000 Message-ID: <013101c68dab$f7e1eb20$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Sip IETF" , "Dean Willis" References: Subject: Re: [Sip] Supported: in ACK Date: Mon, 12 Jun 2006 01:08:36 +0200 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.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean, Before answering, let's discuss the question: should it be split into 1) Can/should you include Supported in ACK 2) Can/should you include (Proxy-)Require in ACK and then perhaps distinguish between ACK to 2xx (end to end) and ACK to non-2xx (hop to hop) Regards, jeroen ----- Original Message ----- From: "Dean Willis" To: "Sip IETF" Sent: Sunday, June 11, 2006 9:22 AM Subject: [Sip] Supported: in ACK > > So, I'm having a Table 2 debate with Joel R., who notices these things. I > don't like RFC 3261's Table 2 much, as you may recall . . . > > Can you or should you include a Supported or Require header in an ACK > request? > > Table 2 says "Not applicable", if I'm reading it right. > > RFC 3261 says: > > If the UAC supports extensions to SIP that can be applied by the > server to the response, the UAC SHOULD include a Supported header > field in the request listing the option tags (Section 19.2) for those > extensions. > > And some of our extensions, at least some of the proposed extensions, > might actually apply to ACK -- OTOH, there's not a response to ACK, so > I'm perplexed as to how the Supported: header would be applied by the > server to the response, since there isn't one. > > JDR has, if I understand him, said several times that one includes > Supported: with all extensions in every request, and ACK is a request, > sort of. > > And, some published examples apparently include Supported: in ACK. Should > they? > > -- > Dean > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 11 19:24:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZGj-0006Gm-G4; Sun, 11 Jun 2006 19:22:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZGh-0006Gh-Pe for sip@ietf.org; Sun, 11 Jun 2006 19:22:55 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpZGd-00023a-Cs for sip@ietf.org; Sun, 11 Jun 2006 19:22:55 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 11 Jun 2006 16:22:51 -0700 X-IronPort-AV: i="4.05,228,1146466800"; d="scan'208"; a="292905807:sNHT32867384" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k5BNMo3x024670; Sun, 11 Jun 2006 16:22:50 -0700 Received: from [192.168.2.102] (rtp-vpn3-205.cisco.com [10.82.216.205]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5BNMkIt011275; Sun, 11 Jun 2006 16:22:49 -0700 (PDT) In-Reply-To: <1148865826.28687.53.camel@niagra.pingtel.com> References: <1148865826.28687.53.camel@niagra.pingtel.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <73730DE6-8529-4997-8B2E-EDF719C7ED9E@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Comments on draft-ietf-sip-outbound-03 Date: Sun, 11 Jun 2006 15:26:34 -0700 To: "Dale R. Worley" X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=3612; t=1150068170; x=1150932170; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Comments=20on=20draft-ietf-sip-outbound-03; X=v=3Dcisco.com=3B=20h=3DdugsHCFoVbZO1TQOsWsCZDXm8Aw=3D; b=RwPoGafmEnbndTXDgUAYvDx8zGD9q8p13p34XflX9IkZHpxGyS96VuaQru9Ctpx0z2wf9Xcy x/0Rqw6YS2LRFRxP6et9Ekwse1xdY90fHeJEijNB/Kcknna4eqp9KyKJ; Authentication-Results: sj-dkim-6.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On May 28, 2006, at 6:23 PM, Dale R. Worley wrote: > Section 1: Introduction > > Since, such detection takes time and leaves a window of opportunity > ... > > should be > > Since such detection takes time and leaves a window of opportunity fixed - thanks. > ... > > Section 4.2.1: Registration by Other Instances > > A User Agent MUST NOT include an instance-id or reg-id in the > Contact > header field of a registration if the registering UA is not the > same > instance as the UA referred to by the target Contact header field. > (This practice is occasionally used to install forwarding policy > into > registrars.) > > This seems overly restrictive. In regard to instance-id, it makes it > impossible for a compliant UA to do a third-party registration that > obtains a GRUU, even if the UA has no intentions of using the flow > mechanism in regard to requests to/from the Contact UA. ISTM that > there should be no restriction on using instance-id independently of > Outbound. agree - fixed > > In regard to reg-id, this restriction would make it difficult for an > edge-proxy to open a flow to a registrar/proxy to provide service for > a UA in some cases, because the edge-proxy could not perform a > third-party registration of the UA. (Although it could forge a > first-party registration to the same effect.) > > Section 5.3: Forwarding Requests > > Note that techniques to ensure that mid-dialog requests are routed > over an existing flow are out of scope and therefore not part of > this > specification. However, an approach such as having the Edge Proxy > Record-Route with a flow token is one way to ensure that mid-dialog > requests are routed over the correct flow. > > ISTM that to achieve the goals of this I-D, it is vital for mid-dialog > requests to be routed over an existing flow. But this paragraph is > not clear as to whether the I-D specifies that "techniques" MUST be > used (but is not specifying what ones are to be used) or just noting > that it's possible to do so. > fixed > Section 7: Mechanisms for All Servers (Proxys, Registars, UAS) > > A SIP device that receives SIP messages directly from a UA needs to > behave as specified in this section. Such devices would generally > include a Registrar and an Edge Proxy, as they both receive > register > requests directly from a UA. > > This should be tightened up, as *any* SIP device can receive SIP > messages directly from a UA. Also, this paragraph does not use the > BCP 14 key words. Fixed - but did not put MUST as later things get that the MUST would be redundant. > > Section 8: Example Message Flow > > In this message flow, there are three REGISTERs: F1, F3, and F15. F1 > and F3, which create flows to two different registrars, have different > Call-Ids, which makes sense. But the I-D says that F15 has a > different Call-Id than F1, despite being a REGISTER to the same proxy, > for the same flow, albeit after the proxy rebooted. It seems to me > that F15 should be a successor to F1, with the same Call-Id and higher > CSeq, as F15 is meant to refresh or replace F1. > > Dale will start separate thread on this. > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 11 19:24:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZGk-0006HT-DX; Sun, 11 Jun 2006 19:22:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZGj-0006HI-Ln for sip@ietf.org; Sun, 11 Jun 2006 19:22:57 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpZGf-00023c-Bi for sip@ietf.org; Sun, 11 Jun 2006 19:22:57 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-6.cisco.com with ESMTP; 11 Jun 2006 16:22:53 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k5BNMqB8010647; Sun, 11 Jun 2006 16:22:52 -0700 Received: from [192.168.2.102] (rtp-vpn3-205.cisco.com [10.82.216.205]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5BNMkIu011275; Sun, 11 Jun 2006 16:22:51 -0700 (PDT) In-Reply-To: <1148865826.28687.53.camel@niagra.pingtel.com> References: <1148865826.28687.53.camel@niagra.pingtel.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <44997218-5E23-4896-874C-604C1EF2AB30@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Sun, 11 Jun 2006 15:28:45 -0700 To: "Dale R. Worley" , Paul H Kyzivat X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=712; t=1150068172; x=1150932172; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re-registration=20open=20issues=20in=20draft-ietf-sip-outbound-03; X=v=3Dcisco.com=3B=20h=3DkwVwDcoznoQOkwYrjhbEXXNKg04=3D; b=ZItaOvycU2350dLg/is1WWiZWF6O8LVdEEUJ9RfvEluobgUQSdSV8ulno7Wa9yE06FFLNEST LXwUUmdLz1B9M1i5p+DeVerWdtFCPRoBhEEM6RUxJafo5L4WlnFowjkC; Authentication-Results: sj-dkim-8.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Sip , Rohan Mahy Subject: [Sip] Re-registration open issues in draft-ietf-sip-outbound-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: , Errors-To: sip-bounces@ietf.org On May 28, 2006, at 6:23 PM, Dale R. Worley wrote: > Section 8: Example Message Flow > > In this message flow, there are three REGISTERs: F1, F3, and F15. F1 > and F3, which create flows to two different registrars, have different > Call-Ids, which makes sense. But the I-D says that F15 has a > different Call-Id than F1, despite being a REGISTER to the same proxy, > for the same flow, albeit after the proxy rebooted. It seems to me > that F15 should be a successor to F1, with the same Call-Id and higher > CSeq, as F15 is meant to refresh or replace F1. > > Dale I'm really never 100% sure about this. I suspect you are right. Does anyone have a problem with me making this change? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 11 19:24:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZGg-0006G5-KT; Sun, 11 Jun 2006 19:22:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZGf-0006G0-W9 for sip@ietf.org; Sun, 11 Jun 2006 19:22:53 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpZGb-00023Y-KJ for sip@ietf.org; Sun, 11 Jun 2006 19:22:53 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-6.cisco.com with ESMTP; 11 Jun 2006 16:22:49 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k5BNMnV5032352; Sun, 11 Jun 2006 16:22:49 -0700 Received: from [192.168.2.102] (rtp-vpn3-205.cisco.com [10.82.216.205]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5BNMkIs011275; Sun, 11 Jun 2006 16:22:47 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4D1E006B-D2E3-4CB9-B417-656E0A0F8F1F@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Supported: in ACK Date: Sun, 11 Jun 2006 15:13:59 -0700 To: Dean Willis X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=1721; t=1150068169; x=1150932169; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Supported=3A=20in=20ACK; X=v=3Dcisco.com=3B=20h=3DSCre2m0qiFNiiwsmujEprwBAVwM=3D; b=gek1Lxxx60XctMwbv8kwksXO4F3UnYq3qCLs9d+Jx0XBhN1rJaA5ksChzvbLYyQBwKyoq60t C0C2zFuUVNIAY6GB6pkJtmBIwnex5lR9bEn0+ABuxiSVKKkcYHb20ygq; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Sip IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Is there any case where the Supported in the ACK might include things that were not in the INVITE? If not, seems like we should suggest that UAS figure out the other sides capabilities by looking at the INVITE not the ACK. On Jun 11, 2006, at 12:22 AM, Dean Willis wrote: > > So, I'm having a Table 2 debate with Joel R., who notices these > things. I don't like RFC 3261's Table 2 much, as you may recall . . . > > Can you or should you include a Supported or Require header in an > ACK request? > > Table 2 says "Not applicable", if I'm reading it right. > > RFC 3261 says: > > If the UAC supports extensions to SIP that can be applied by the > server to the response, the UAC SHOULD include a Supported header > field in the request listing the option tags (Section 19.2) for > those > extensions. > > And some of our extensions, at least some of the proposed > extensions, might actually apply to ACK -- OTOH, there's not a > response to ACK, so I'm perplexed as to how the Supported: header > would be applied by the server to the response, since there isn't one. > > JDR has, if I understand him, said several times that one includes > Supported: with all extensions in every request, and ACK is a > request, sort of. > > And, some published examples apparently include Supported: in ACK. > Should they? > > -- > Dean > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 11 19:24:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZGk-0006HT-DX; Sun, 11 Jun 2006 19:22:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZGj-0006HI-Ln for sip@ietf.org; Sun, 11 Jun 2006 19:22:57 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpZGf-00023c-Bi for sip@ietf.org; Sun, 11 Jun 2006 19:22:57 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-6.cisco.com with ESMTP; 11 Jun 2006 16:22:53 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k5BNMqB8010647; Sun, 11 Jun 2006 16:22:52 -0700 Received: from [192.168.2.102] (rtp-vpn3-205.cisco.com [10.82.216.205]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5BNMkIu011275; Sun, 11 Jun 2006 16:22:51 -0700 (PDT) In-Reply-To: <1148865826.28687.53.camel@niagra.pingtel.com> References: <1148865826.28687.53.camel@niagra.pingtel.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <44997218-5E23-4896-874C-604C1EF2AB30@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Sun, 11 Jun 2006 15:28:45 -0700 To: "Dale R. Worley" , Paul H Kyzivat X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=712; t=1150068172; x=1150932172; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re-registration=20open=20issues=20in=20draft-ietf-sip-outbound-03; X=v=3Dcisco.com=3B=20h=3DkwVwDcoznoQOkwYrjhbEXXNKg04=3D; b=ZItaOvycU2350dLg/is1WWiZWF6O8LVdEEUJ9RfvEluobgUQSdSV8ulno7Wa9yE06FFLNEST LXwUUmdLz1B9M1i5p+DeVerWdtFCPRoBhEEM6RUxJafo5L4WlnFowjkC; Authentication-Results: sj-dkim-8.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Sip , Rohan Mahy Subject: [Sip] Re-registration open issues in draft-ietf-sip-outbound-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: , Errors-To: sip-bounces@ietf.org On May 28, 2006, at 6:23 PM, Dale R. Worley wrote: > Section 8: Example Message Flow > > In this message flow, there are three REGISTERs: F1, F3, and F15. F1 > and F3, which create flows to two different registrars, have different > Call-Ids, which makes sense. But the I-D says that F15 has a > different Call-Id than F1, despite being a REGISTER to the same proxy, > for the same flow, albeit after the proxy rebooted. It seems to me > that F15 should be a successor to F1, with the same Call-Id and higher > CSeq, as F15 is meant to refresh or replace F1. > > Dale I'm really never 100% sure about this. I suspect you are right. Does anyone have a problem with me making this change? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 11 19:24:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZGg-0006G5-KT; Sun, 11 Jun 2006 19:22:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZGf-0006G0-W9 for sip@ietf.org; Sun, 11 Jun 2006 19:22:53 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpZGb-00023Y-KJ for sip@ietf.org; Sun, 11 Jun 2006 19:22:53 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-6.cisco.com with ESMTP; 11 Jun 2006 16:22:49 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k5BNMnV5032352; Sun, 11 Jun 2006 16:22:49 -0700 Received: from [192.168.2.102] (rtp-vpn3-205.cisco.com [10.82.216.205]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5BNMkIs011275; Sun, 11 Jun 2006 16:22:47 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4D1E006B-D2E3-4CB9-B417-656E0A0F8F1F@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Supported: in ACK Date: Sun, 11 Jun 2006 15:13:59 -0700 To: Dean Willis X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=1721; t=1150068169; x=1150932169; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Supported=3A=20in=20ACK; X=v=3Dcisco.com=3B=20h=3DSCre2m0qiFNiiwsmujEprwBAVwM=3D; b=gek1Lxxx60XctMwbv8kwksXO4F3UnYq3qCLs9d+Jx0XBhN1rJaA5ksChzvbLYyQBwKyoq60t C0C2zFuUVNIAY6GB6pkJtmBIwnex5lR9bEn0+ABuxiSVKKkcYHb20ygq; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Sip IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Is there any case where the Supported in the ACK might include things that were not in the INVITE? If not, seems like we should suggest that UAS figure out the other sides capabilities by looking at the INVITE not the ACK. On Jun 11, 2006, at 12:22 AM, Dean Willis wrote: > > So, I'm having a Table 2 debate with Joel R., who notices these > things. I don't like RFC 3261's Table 2 much, as you may recall . . . > > Can you or should you include a Supported or Require header in an > ACK request? > > Table 2 says "Not applicable", if I'm reading it right. > > RFC 3261 says: > > If the UAC supports extensions to SIP that can be applied by the > server to the response, the UAC SHOULD include a Supported header > field in the request listing the option tags (Section 19.2) for > those > extensions. > > And some of our extensions, at least some of the proposed > extensions, might actually apply to ACK -- OTOH, there's not a > response to ACK, so I'm perplexed as to how the Supported: header > would be applied by the server to the response, since there isn't one. > > JDR has, if I understand him, said several times that one includes > Supported: with all extensions in every request, and ACK is a > request, sort of. > > And, some published examples apparently include Supported: in ACK. > Should they? > > -- > Dean > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 11 19:25:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZHr-0006uI-24; Sun, 11 Jun 2006 19:24:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZHp-0006u8-OL for sip@ietf.org; Sun, 11 Jun 2006 19:24:05 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpZHh-00026M-MY for sip@ietf.org; Sun, 11 Jun 2006 19:24:05 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-2.cisco.com with ESMTP; 11 Jun 2006 16:23:58 -0700 X-IronPort-AV: i="4.05,228,1146466800"; d="scan'208"; a="324745927:sNHT32173220" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k5BNNuhv010779; Sun, 11 Jun 2006 16:23:56 -0700 Received: from [192.168.2.102] (rtp-vpn3-205.cisco.com [10.82.216.205]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5BNMkIv011275; Sun, 11 Jun 2006 16:22:52 -0700 (PDT) In-Reply-To: References: <446BFE27.4070909@opencloud.com> <5FE19E1C-71D9-4FF9-A2B3-FBD704CCC9F8@softarmor.com> <446D3E5E.4070800@opencloud.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] draft-ietf-sip-outbound-03: proxy routing question Date: Sun, 11 Jun 2006 15:32:14 -0700 To: Dean Willis , Ben Evans X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=2024; t=1150068236; x=1150932236; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20draft-ietf-sip-outbound-03=3A=20proxy=20routing=20questi on; X=v=3Dcisco.com=3B=20h=3DfaThyhp/aaESPPbFmODObqFCQQ4=3D; b=OrLWji+AorQ0JAGM7z8dauvURrGohLPL73m6Ed/t13MCSggNPCHsM+lIk62Ta/fln86WQfZx b6WzrOyBkbRzlaFJrfalMVkNv67QzogOjg7SoyxMw0L2LmXQMfFkDdz0; Authentication-Results: sj-dkim-8.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Ahhg --- when using GRUU this may just happen without the double R-R. I've no objections to putting some clarifying hints in but I'm really not sure exactly what to add. Anyone want to send text? On May 19, 2006, at 4:52 PM, Dean Willis wrote: > On May 18, 2006, at 10:41 PM, Ben Evans wrote: > >> Dean Willis wrote: >>> >>> On May 17, 2006, at 11:55 PM, Ben Evans wrote: >>>> [...] >>>> Because the ACK's Request-URI contains UA1's contact URI, not the >>>> AOR, the proxy would normally not do a location service lookup (the >>>> contact URI is a physical IP address/port). So how does the proxy >>>> obtain the flow information from the location service so that >>>> it can >>>> send the ACK (and any future mid-dialog requests) on the correct >>>> flow? What am I missing? >>> >>> >>> My theory is that the proxy should use the "double record routing >>> trick". As such, it inserts two R-R values. The first identifies the >>> interface and flow binding for UA1, and the second identifies the >>> interface as seen by UA2. >>> >>> When the proxy receives the ACK at step 6, it pops the first >>> route (its >>> interface facing UA2). It then inspects the next route to figure >>> out >>> where to send. Since this next route is also "local", it pops this >>> route field, picks the flow from the information in that route >>> field, >>> and puts the ACK onto the flow towards UA1. >>> >>> We originally developed this trick to work with proxies that >>> have more >>> than one interface, but since the flow identifier is sort of a >>> "virtual >>> interface", the technique should work here. >> >> Thanks Dean, this worked really well. Should this technique should >> be mentioned in the draft? Or maybe it is already obvious to those >> in the know! > > Good point. Probably wouldn't hurt to mention it. Lots of people > just assume people understand this, so it may not get the needed > coverage. > > Oh Mr. Outbound Editor . . . _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 11 19:26:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZIC-0008Ai-39; Sun, 11 Jun 2006 19:24:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZIA-00087h-DJ for sip@ietf.org; Sun, 11 Jun 2006 19:24:26 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpZI6-000273-4E for sip@ietf.org; Sun, 11 Jun 2006 19:24:26 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-6.cisco.com with ESMTP; 11 Jun 2006 16:24:21 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k5BNOLR0032515; Sun, 11 Jun 2006 16:24:21 -0700 Received: from [192.168.2.102] (rtp-vpn3-205.cisco.com [10.82.216.205]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5BNMkJ1011275; Sun, 11 Jun 2006 16:24:20 -0700 (PDT) In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1CD9@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1CD9@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6803ECBA-56CD-4DB5-91E6-C9A87E6AB69F@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Outbound: Maximum number of flows reached - how to reject? Date: Sun, 11 Jun 2006 15:49:33 -0700 To: Christer Holmberg ((JO/LMF)) X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=550; t=1150068261; x=1150932261; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Outbound=3A=20Maximum=20number=20of=20flows=20reached=20 -=20how=20to=20reject?; X=v=3Dcisco.com=3B=20h=3DNC7OcxJ5pQjrkYJd+xCJLnTQU5Q=3D; b=3Q0X1FTKbvEeR0eyzHFkDH4HMf8SR7LJX8gGdTb0lGM/ZwBD/0sjaotICTLnrCklXmH5aUGv 5EON6g8eJe47vgnZ/nnqXutviZNXHGP6R751wW7Tkgn1pFbdkMjHCJP+; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The upper bound is made by the number of of URIs is the outbound- proxy-set - I think in most cases, UA would choose 1, 2, or all. On Apr 6, 2006, at 2:08 AM, Christer Holmberg ((JO/LMF)) wrote: > Hi, > > I don't know if there is a need to tell the UA to register another > flow. > If the error is temporary, you can send a Retry-After header and > indicate when it is POSSIBLE to register another flow. But, the > decission of how many flows to register (or, try to register) is to be > made by the UA, I believe. > > Regards, _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 11 19:26:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZI8-00086h-55; Sun, 11 Jun 2006 19:24:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZI5-0007x0-Un for sip@ietf.org; Sun, 11 Jun 2006 19:24:21 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpZI1-000273-D4 for sip@ietf.org; Sun, 11 Jun 2006 19:24:21 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-6.cisco.com with ESMTP; 11 Jun 2006 16:24:17 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k5BNOGAm032503; Sun, 11 Jun 2006 16:24:16 -0700 Received: from [192.168.2.102] (rtp-vpn3-205.cisco.com [10.82.216.205]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5BNMkIx011275; Sun, 11 Jun 2006 16:24:15 -0700 (PDT) In-Reply-To: <17507.7302.227190.439598@rautu.tutpro.com> References: <17507.7302.227190.439598@rautu.tutpro.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] outbound i-d update? Date: Sun, 11 Jun 2006 15:37:48 -0700 To: Juha Heinanen X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=1415; t=1150068256; x=1150932256; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20outbound=20i-d=20update?; X=v=3Dcisco.com=3B=20h=3DUiVsMnvEokAmOy0hnZ/QC1ETTAQ=3D; b=SF80ObMcuotW5WC0Khcb54tbLtvmUWl+WWUQA2XdLgt2tmSzJ+0TjivAN2tWY/eND+u9sHiB scf4yWb2baxS6y/TjnL+YamwV0dIQsuweWPBoA/Cjy+w5T/qzGmSuSia; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I tried to fix the the primary backup issues - Some text is at http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-ietf-sip- outbound.html Note this is very much work in progress and *not* what will be submitted as the 04 version of the draft. I suspect you will not find the resolution ideal but it was the best I could come up with and still have things make sense. If you have specific ideas on how to make the primary/backup issue better it, glad to hear them. Cullen On May 11, 2006, at 4:14 AM, Juha Heinanen wrote: > it would be important to get outbound i-d out as rfc asap. i don't > think there are many things that need to be fixing in -03, but i would > like to see them done now rather than waiting for yet another ietf > meeting. > > one of the issues is the notion of "primary" and "backup" proxies that > should go away. it should suffice that UA is configured with at least > two outbound proxies, which may have same or different priority. > > have authors of outbound i-d kept a list of other outstanding issues? > > -- 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 Sun Jun 11 19:26:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZIC-0008Ai-39; Sun, 11 Jun 2006 19:24:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZIA-00087h-DJ for sip@ietf.org; Sun, 11 Jun 2006 19:24:26 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpZI6-000273-4E for sip@ietf.org; Sun, 11 Jun 2006 19:24:26 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-6.cisco.com with ESMTP; 11 Jun 2006 16:24:21 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k5BNOLR0032515; Sun, 11 Jun 2006 16:24:21 -0700 Received: from [192.168.2.102] (rtp-vpn3-205.cisco.com [10.82.216.205]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5BNMkJ1011275; Sun, 11 Jun 2006 16:24:20 -0700 (PDT) In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1CD9@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1CD9@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6803ECBA-56CD-4DB5-91E6-C9A87E6AB69F@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Outbound: Maximum number of flows reached - how to reject? Date: Sun, 11 Jun 2006 15:49:33 -0700 To: Christer Holmberg ((JO/LMF)) X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=550; t=1150068261; x=1150932261; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Outbound=3A=20Maximum=20number=20of=20flows=20reached=20 -=20how=20to=20reject?; X=v=3Dcisco.com=3B=20h=3DNC7OcxJ5pQjrkYJd+xCJLnTQU5Q=3D; b=3Q0X1FTKbvEeR0eyzHFkDH4HMf8SR7LJX8gGdTb0lGM/ZwBD/0sjaotICTLnrCklXmH5aUGv 5EON6g8eJe47vgnZ/nnqXutviZNXHGP6R751wW7Tkgn1pFbdkMjHCJP+; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The upper bound is made by the number of of URIs is the outbound- proxy-set - I think in most cases, UA would choose 1, 2, or all. On Apr 6, 2006, at 2:08 AM, Christer Holmberg ((JO/LMF)) wrote: > Hi, > > I don't know if there is a need to tell the UA to register another > flow. > If the error is temporary, you can send a Retry-After header and > indicate when it is POSSIBLE to register another flow. But, the > decission of how many flows to register (or, try to register) is to be > made by the UA, I believe. > > Regards, _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 11 19:26:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZI8-00086h-55; Sun, 11 Jun 2006 19:24:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZI5-0007x0-Un for sip@ietf.org; Sun, 11 Jun 2006 19:24:21 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpZI1-000273-D4 for sip@ietf.org; Sun, 11 Jun 2006 19:24:21 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-6.cisco.com with ESMTP; 11 Jun 2006 16:24:17 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k5BNOGAm032503; Sun, 11 Jun 2006 16:24:16 -0700 Received: from [192.168.2.102] (rtp-vpn3-205.cisco.com [10.82.216.205]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5BNMkIx011275; Sun, 11 Jun 2006 16:24:15 -0700 (PDT) In-Reply-To: <17507.7302.227190.439598@rautu.tutpro.com> References: <17507.7302.227190.439598@rautu.tutpro.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] outbound i-d update? Date: Sun, 11 Jun 2006 15:37:48 -0700 To: Juha Heinanen X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=1415; t=1150068256; x=1150932256; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20outbound=20i-d=20update?; X=v=3Dcisco.com=3B=20h=3DUiVsMnvEokAmOy0hnZ/QC1ETTAQ=3D; b=SF80ObMcuotW5WC0Khcb54tbLtvmUWl+WWUQA2XdLgt2tmSzJ+0TjivAN2tWY/eND+u9sHiB scf4yWb2baxS6y/TjnL+YamwV0dIQsuweWPBoA/Cjy+w5T/qzGmSuSia; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I tried to fix the the primary backup issues - Some text is at http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-ietf-sip- outbound.html Note this is very much work in progress and *not* what will be submitted as the 04 version of the draft. I suspect you will not find the resolution ideal but it was the best I could come up with and still have things make sense. If you have specific ideas on how to make the primary/backup issue better it, glad to hear them. Cullen On May 11, 2006, at 4:14 AM, Juha Heinanen wrote: > it would be important to get outbound i-d out as rfc asap. i don't > think there are many things that need to be fixing in -03, but i would > like to see them done now rather than waiting for yet another ietf > meeting. > > one of the issues is the notion of "primary" and "backup" proxies that > should go away. it should suffice that UA is configured with at least > two outbound proxies, which may have same or different priority. > > have authors of outbound i-d kept a list of other outstanding issues? > > -- 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 Sun Jun 11 20:34:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpaLq-00076h-KK; Sun, 11 Jun 2006 20:32:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpaLp-00071n-FY for sip@ietf.org; Sun, 11 Jun 2006 20:32:17 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpZWW-0002uw-HF for sip@ietf.org; Sun, 11 Jun 2006 19:39:16 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FpZI4-0003eN-1A for sip@ietf.org; Sun, 11 Jun 2006 19:24:21 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-3.cisco.com with ESMTP; 11 Jun 2006 16:24:19 -0700 X-IronPort-AV: i="4.05,228,1146466800"; d="scan'208"; a="430540719:sNHT30887988" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k5BNOJU7010806; Sun, 11 Jun 2006 16:24:19 -0700 Received: from [192.168.2.102] (rtp-vpn3-205.cisco.com [10.82.216.205]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5BNMkJ0011275; Sun, 11 Jun 2006 16:24:18 -0700 (PDT) In-Reply-To: <7e2ba47a62b9533774cf8a0ba8b5ac0d@ekabal.com> References: <001b01c657ad$4e1f7140$31713b51@BEMBUSTER> <724f0adb9bc60dd7c2470bafe1051049@ekabal.com> <003201c6581a$5dc93820$31713b51@BEMBUSTER> <7e2ba47a62b9533774cf8a0ba8b5ac0d@ekabal.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7BD7675D-B02F-4F60-BA36-AC66A69DEB8D@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Re: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-03.txt Date: Sun, 11 Jun 2006 15:46:36 -0700 To: Rohan Mahy X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=222; t=1150068259; x=1150932259; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20=20Re=3A=20http=3A//www.ietf.org/internet-drafts/draft-i etf-sip-outbound-03.txt; X=v=3Dcisco.com=3B=20h=3DIi3OyAl6/FXc7ellPWKHgJAM3wA=3D; b=DLhYVVOnV3ILtGrBmr5uqjbKDIoTf4DU7N/x45e6iDJbWASHgmgge/lW58YhY024qRqkcaY3 wA1MVqraUQukI1WCEuXHkX4e+bAjBg/q/YVU8FdJZT0ZR2Zv97Q+0KJi; Authentication-Results: sj-dkim-8.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.3 (--) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Apr 8, 2006, at 4:07 PM, Rohan Mahy wrote: >>> 2 - section 11 says "the proxy stores the value of the Path >>> header field", this should be "the registrar" >> >> good catch. thanks, >> -rohan > fixed. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 12 00:13:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpdmQ-0006cM-RL; Mon, 12 Jun 2006 00:11:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpdmO-0006c5-QZ for sip@ietf.org; Mon, 12 Jun 2006 00:11:56 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpdmM-0004tN-Gz for sip@ietf.org; Mon, 12 Jun 2006 00:11:56 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 12 Jun 2006 00:11:55 -0400 X-IronPort-AV: i="4.05,228,1146456000"; d="scan'208"; a="89790132:sNHT31313296" Received: from [192.168.2.102] (rtp-vpn3-205.cisco.com [10.82.216.205]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5C4Brno005134; Mon, 12 Jun 2006 00:11:53 -0400 (EDT) In-Reply-To: <013101c68dab$f7e1eb20$31713b51@BEMBUSTER> References: <013101c68dab$f7e1eb20$31713b51@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <291088A3-E3B0-418C-894F-4AEFB21AADE6@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Supported: in ACK Date: Sun, 11 Jun 2006 21:11:48 -0700 To: Jeroen van Bemmel X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Sip IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 11, 2006, at 4:08 PM, Jeroen van Bemmel wrote: > Dean, > > Before answering, let's discuss the question: should it be split into > > 1) Can/should you include Supported in ACK In thinking of the answer to this, I end up asking, who cares? What would ever read this information or do anything with it? I can imagine there might be a case I am not thinking of but I'm missing the use case for this. > 2) Can/should you include (Proxy-)Require in ACK I suspect the answer is no because the Proxy has no way to reject an ACK so the UA could only require things that it knew the proxy supported which would make requiring them sort of redundant. Put another way, do you really want all the ACKs to just silently disappear? that sounds bad. > > and then perhaps distinguish between ACK to 2xx (end to end) and > ACK to non-2xx (hop to hop) > > Regards, > > jeroen > > ----- Original Message ----- From: "Dean Willis" > > To: "Sip IETF" > Sent: Sunday, June 11, 2006 9:22 AM > Subject: [Sip] Supported: in ACK > > >> >> So, I'm having a Table 2 debate with Joel R., who notices these >> things. I don't like RFC 3261's Table 2 much, as you may recall . . . >> >> Can you or should you include a Supported or Require header in an >> ACK request? >> >> Table 2 says "Not applicable", if I'm reading it right. >> >> RFC 3261 says: >> >> If the UAC supports extensions to SIP that can be applied by the >> server to the response, the UAC SHOULD include a Supported header >> field in the request listing the option tags (Section 19.2) >> for those >> extensions. >> >> And some of our extensions, at least some of the proposed >> extensions, might actually apply to ACK -- OTOH, there's not a >> response to ACK, so I'm perplexed as to how the Supported: header >> would be applied by the server to the response, since there isn't >> one. >> >> JDR has, if I understand him, said several times that one includes >> Supported: with all extensions in every request, and ACK is a >> request, sort of. >> >> And, some published examples apparently include Supported: in >> ACK. Should they? >> >> -- >> 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 Mon Jun 12 03:28:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpgp4-0006ny-8a; Mon, 12 Jun 2006 03:26:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpgp2-0006ns-G9 for sip@ietf.org; Mon, 12 Jun 2006 03:26:52 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpgoy-0006R2-7B for sip@ietf.org; Mon, 12 Jun 2006 03:26:52 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k5C7QhF20581; Mon, 12 Jun 2006 03:26:43 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Supported: in ACK Date: Mon, 12 Jun 2006 02:26:42 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60C9A630A@zrc2hxm2.corp.nortel.com> In-Reply-To: <291088A3-E3B0-418C-894F-4AEFB21AADE6@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Supported: in ACK Thread-Index: AcaN1nav56Sota5PTJel7AR4SOjHtQAFto4w From: "Samir Srivastava" To: "Cullen Jennings" , "Jeroen van Bemmel" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Sip IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > 2) Can/should you include (Proxy-)Require in ACK I suspect the answer is no because the Proxy has no way to reject an ACK so the UA could only require things that it knew the proxy supported which would make requiring them sort of redundant. Put another way, do you really want all the ACKs to just silently disappear? that sounds bad. SS>> will there be use case for _stateless_ proxy to act on these, provided ACK MUST have the same set of tags as that of INVITE. Some applications might be using ACK as trigger for the established Calls (otherwise call will be BYE'ed), They might be passing the initial messages statelessly. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 12 04:02:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FphLr-0000BO-1b; Mon, 12 Jun 2006 04:00:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FphLq-0000BJ-6j for sip@ietf.org; Mon, 12 Jun 2006 04:00:46 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FphLl-0002MQ-Tc for sip@ietf.org; Mon, 12 Jun 2006 04:00:46 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k5C80cV17621 for ; Mon, 12 Jun 2006 04:00:39 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 12 Jun 2006 03:00:33 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60C9A630C@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Outbound's reg-id and REG-EVENT's id Thread-Index: AcaN9kf1L1gGiMiLQsWWya6jznFqzQ== From: "Samir Srivastava" To: "Sip IETF" X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [Sip] Outbound's reg-id and REG-EVENT's id X-BeenThere: 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="===============2142032834==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2142032834== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68DF6.4866ED7C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68DF6.4866ED7C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 REG -EVENT package introduces the contact - id which is to identify contact uniquely.=20 Do we need two unqiue id's in REG-EVENT ? It will be good to have some text for the REG-EVENT in outbound or will it be addressed separately ? Thx Samir ------_=_NextPart_001_01C68DF6.4866ED7C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Outbound's reg-id and REG-EVENT's id

Hi,
 
    REG -EVENT package = introduces the contact - id which is to identify contact uniquely. =

Do we need two unqiue id's in  = REG-EVENT ? It will be good to have some text for the REG-EVENT in = outbound or  will it be addressed separately ?

Thx
Samir

------_=_NextPart_001_01C68DF6.4866ED7C-- --===============2142032834== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2142032834==-- From sip-bounces@ietf.org Mon Jun 12 04:16:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FphZ9-0000i1-B1; Mon, 12 Jun 2006 04:14:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FphZ8-0000eH-9x for sip@ietf.org; Mon, 12 Jun 2006 04:14:30 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FphZ3-0003ex-LI for sip@ietf.org; Mon, 12 Jun 2006 04:14:30 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 04730140018; Mon, 12 Jun 2006 11:14:19 +0300 (EEST) Received: from rautu (guanine173.gprs.dnafinland.fi [62.78.120.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id A34FB13FFEB; Mon, 12 Jun 2006 11:14:09 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 5741BF03C1; Mon, 12 Jun 2006 11:14:22 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17549.8798.26258.703846@rautu.tutpro.com> Date: Mon, 12 Jun 2006 11:14:22 +0300 From: Juha Heinanen To: Cullen Jennings Subject: Re: [Sip] outbound i-d update? In-Reply-To: References: <17507.7302.227190.439598@rautu.tutpro.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org 1. Introduction Since such detection takes time and leaves a window of opportunity for missed incoming requests, this mechanism allows the UA to use multiple flows to the proxy or registrar. i would say: ... to use simultaneous flows to multiple proxy or registrar hosts. since i don't understand what would multiple flows to THE proxy help. 2.1 Definitions outbound-proxy-set The first URI in the set is often refereed too as the primary outbound proxy and the second in as the secondary outbound proxy. There is no difference between the first and second and the primary/secondary does not imply one is preferred over the other. what is the third and fourth referred to? i would simply remove these two sentences. 3.3 Multiple Connections from a User Agent In the example system below, the logical proxy/registrar for the domain is running on two hosts that share the appropriate state and can both provide registrar and proxy functionality for the domain. The UA will form connections to two of the physical hosts that can perform the proxy/registrar function for the domain. Reliability is achieved by having the UA form two TCP connections to the domain. Scalability is achieved by using DNS SRV to load balance the primary connection across a set of machines that can service the primary connection and also using DNS SRV to load balance across a separate set of machines that can service the secondary connection. The deployment here requires that DNS is configured with one entry that resolves to all the primary hosts and another entry that resolves to all the secondary hosts. Designs having only one set were also considered, but in this case there would have to be some way to ensure that the two connection did not accidentally resolve to the same host. Various approaches for this are possible but all probably require extensions to the SIP protocol so they were not included in this specification. This approach can work with the disadvantage that slightly more configuration of DNS is required. i would greatly simplify the text: In the example system below, the logical outbound proxy/registrar for the domain is running on two hosts that share the appropriate state and can both provide registrar and outbound proxy functionality for the domain. The UA will form connections to two of the physical hosts that can perform the outbound proxy/registrar function for the domain. Reliability is achieved by having the UA form two TCP connections to the domain. Scalability is achieved by using DNS SRV records to load balance connections to the set of hosts that represent outbound proxies of the domain." instead of using the term "proxy", the above text uses the defined (2.1) term outbound proxy. more importantly, the details of implementing scalability are left as an internal matter of the domain. The UA is configured with a primary and secondary registration URI. i would say: The UA is configured with at least two URIs that represent at least two outbound proxies. again, use of the defined term "outbound proxy" and get rid of primary/secondary. When a single server fails, ... again a new undefined term "server". i would say When a single outbound proxy host fails, ... If a UA has multiple flows, and one of the servers fails, it can delay some significant time before trying to form a new connection to replace the flow to the server that failed. the "If" surprises me here. i thought that the key idea of outbound-id is that each UA tries to keep more than flow active at all times. if this is not a requirement, then there is no chance for reliable load balancing and we are back in square one. 4.2 Initial Registrations UAs are configured with one or more SIP URIs representing the default outbound-proxy-set. UAs are configured with two or more ... However, a UA MUST support sets with at least two outbound proxy URIs (primary and secondary) and SHOULD support sets with up to four URIs. leave out "(primary and secondary)". -- 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 Mon Jun 12 04:28:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FphkW-0006fB-TB; Mon, 12 Jun 2006 04:26:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FphkV-0006f4-SZ for sip@ietf.org; Mon, 12 Jun 2006 04:26:15 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FphkR-0003y5-JJ for sip@ietf.org; Mon, 12 Jun 2006 04:26:15 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k5C8Q7x12900; Mon, 12 Jun 2006 04:26:07 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound: Maximum number of flows reached - how to reject? Date: Mon, 12 Jun 2006 03:26:06 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60C9A6310@zrc2hxm2.corp.nortel.com> In-Reply-To: <6803ECBA-56CD-4DB5-91E6-C9A87E6AB69F@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: Maximum number of flows reached - how to reject? Thread-Index: AcaNri65GWhlVrrQRruSijXgsbi0LQASrPKg From: "Samir Srivastava" To: "Cullen Jennings" , "Christer Holmberg \(\(JO/LMF\)\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org All ? What about the evil UA registering multiple flows to attack ? These flows cause a lot of traffic, Registrar/Edge Proxy should reject based on available resources etc... Thx Samir -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com]=20 Sent: Sunday, June 11, 2006 3:50 PM To: Christer Holmberg ((JO/LMF)) Cc: Srivastava, Samir [SC100:8826:EXCH]; sip@ietf.org Subject: Re: [Sip] Outbound: Maximum number of flows reached - how to reject? The upper bound is made by the number of of URIs is the outbound- proxy-set - I think in most cases, UA would choose 1, 2, or all. On Apr 6, 2006, at 2:08 AM, Christer Holmberg ((JO/LMF)) wrote: > Hi, > > I don't know if there is a need to tell the UA to register another=20 > flow. > If the error is temporary, you can send a Retry-After header and=20 > indicate when it is POSSIBLE to register another flow. But, the=20 > decission of how many flows to register (or, try to register) is to be > made by the UA, I believe. > > Regards, _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 12 09:27:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpmQ8-0001B5-A2; Mon, 12 Jun 2006 09:25:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpmQ7-0001Az-7w for sip@ietf.org; Mon, 12 Jun 2006 09:25:31 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpmQ6-0008Kg-0F for sip@ietf.org; Mon, 12 Jun 2006 09:25:31 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 93C636C017; Mon, 12 Jun 2006 09:25:29 -0400 (EDT) Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt From: Scott Lawrence To: Cullen Jennings In-Reply-To: <26E13ED4-1582-4CB2-B74E-F5E0985F9810@cisco.com> References: <44887921.20302@cisco.com> <1149796932.4721.129.camel@localhost.localdomain> <44898BD0.7000705@cisco.com> <26E13ED4-1582-4CB2-B74E-F5E0985F9810@cisco.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Mon, 12 Jun 2006 09:25:29 -0400 Message-Id: <1150118729.2822.18.camel@sukothai.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Fri, 2006-06-09 at 21:18 -0700, Cullen Jennings wrote: > On Jun 9, 2006, at 7:55 AM, Jonathan Rosenberg wrote: > > > > >>> * the document says it 'updates' rfc3261 but its not clear to me > >>> it does that; are you saying its doing that because its changing > >>> the usage of Warning? > >> No, because it adds a new SHOULD for how to construct the error > >> response. I don't think that it does change Warning. > > > > I view it as an extension, not an update, but maybe its splitting > > hairs. > > I think it is an extention not an update. Thinking about this further over the weekend, I don't think I agree. I don't care enough - I'll take the 'updates' off the next rev of the draft if there is rough consensus, but I thought it worth pointing out why I used 'updates': - this introduces new normative behavior for all Servers - the new behavior is not controlled or advertised using the mechanisms for identifying extensions (Supported/Requires). The advantage of using the 'updates' attribute is that the RFC Editors' document index entry for 3261 will have the pointer to the new spec, informing any future reader that there is something more to read... -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 12 13:59:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpqft-0007yn-Q5; Mon, 12 Jun 2006 13:58:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpqfs-0007yh-CQ for sip@ietf.org; Mon, 12 Jun 2006 13:58:04 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpqfq-0001VW-T8 for sip@ietf.org; Mon, 12 Jun 2006 13:58:04 -0400 Received: from [192.168.2.104] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5CHxSQq020433 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 12 Jun 2006 12:59:29 -0500 In-Reply-To: References: <446BFE27.4070909@opencloud.com> <5FE19E1C-71D9-4FF9-A2B3-FBD704CCC9F8@softarmor.com> <446D3E5E.4070800@opencloud.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1EA8E825-08B5-4433-8E7B-7BF0699366BD@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] draft-ietf-sip-outbound-03: proxy routing question Date: Mon, 12 Jun 2006 12:58:01 -0500 To: Cullen Jennings X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: sip@ietf.org, Ben Evans X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Why would GRUU keep the proxy from being able to double-R-R? It might change what would go INTO the R-R, which shouldn't be a problem. -- Dean On Jun 11, 2006, at 5:32 PM, Cullen Jennings wrote: > > Ahhg --- when using GRUU this may just happen without the double R- > R. I've no objections to putting some clarifying hints in but I'm > really not sure exactly what to add. Anyone want to send text? > > On May 19, 2006, at 4:52 PM, Dean Willis wrote: > >> On May 18, 2006, at 10:41 PM, Ben Evans wrote: >> >>> Dean Willis wrote: >>>> >>>> On May 17, 2006, at 11:55 PM, Ben Evans wrote: >>>>> [...] >>>>> Because the ACK's Request-URI contains UA1's contact URI, not the >>>>> AOR, the proxy would normally not do a location service lookup >>>>> (the >>>>> contact URI is a physical IP address/port). So how does the proxy >>>>> obtain the flow information from the location service so that >>>>> it can >>>>> send the ACK (and any future mid-dialog requests) on the correct >>>>> flow? What am I missing? >>>> >>>> >>>> My theory is that the proxy should use the "double record routing >>>> trick". As such, it inserts two R-R values. The first identifies >>>> the >>>> interface and flow binding for UA1, and the second identifies the >>>> interface as seen by UA2. >>>> >>>> When the proxy receives the ACK at step 6, it pops the first >>>> route (its >>>> interface facing UA2). It then inspects the next route to >>>> figure out >>>> where to send. Since this next route is also "local", it pops this >>>> route field, picks the flow from the information in that route >>>> field, >>>> and puts the ACK onto the flow towards UA1. >>>> >>>> We originally developed this trick to work with proxies that >>>> have more >>>> than one interface, but since the flow identifier is sort of a >>>> "virtual >>>> interface", the technique should work here. >>> >>> Thanks Dean, this worked really well. Should this technique >>> should be mentioned in the draft? Or maybe it is already obvious >>> to those in the know! >> >> Good point. Probably wouldn't hurt to mention it. Lots of people >> just assume people understand this, so it may not get the needed >> coverage. >> >> Oh Mr. Outbound Editor . . . > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 12 15:18:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fprtn-0003Cy-5R; Mon, 12 Jun 2006 15:16:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fprtm-0003Ct-Dw for sip@ietf.org; Mon, 12 Jun 2006 15:16:30 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fprtl-0001KE-0I for sip@ietf.org; Mon, 12 Jun 2006 15:16:30 -0400 Received: from [192.168.2.104] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5CJHtGa020725 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 12 Jun 2006 14:17:55 -0500 In-Reply-To: <013101c68dab$f7e1eb20$31713b51@BEMBUSTER> References: <013101c68dab$f7e1eb20$31713b51@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <63069486-864A-4FF7-89B1-3CB7586F8687@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Supported: in ACK Date: Mon, 12 Jun 2006 14:16:28 -0500 To: Jeroen van Bemmel X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Sip IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 11, 2006, at 6:08 PM, Jeroen van Bemmel wrote: > Dean, > > Before answering, let's discuss the question: should it be split into > > 1) Can/should you include Supported in ACK Ok, I agree those are separate questions. > 2) Can/should you include (Proxy-)Require in ACK I don't think you can, since a proxy cannot reject an ACK that has a Proxy-Require: that is not supported by the proxy. > > and then perhaps distinguish between ACK to 2xx (end to end) and > ACK to non-2xx (hop to hop) > Not quite sure about this. -- 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 Jun 12 16:45:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FptGV-00071J-LW; Mon, 12 Jun 2006 16:44:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FptGT-0006yW-PP for sip@ietf.org; Mon, 12 Jun 2006 16:44:01 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FptGS-0004Yc-BO for sip@ietf.org; Mon, 12 Jun 2006 16:44:01 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 12 Jun 2006 13:43:59 -0700 X-IronPort-AV: i="4.05,229,1146466800"; d="scan'208"; a="293394454:sNHT33700756" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k5CKhxAP015992; Mon, 12 Jun 2006 13:43:59 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5CKhxIs029537; Mon, 12 Jun 2006 13:43:59 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 13:43:59 -0700 Received: from [128.107.178.16] ([128.107.178.16]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 13:43:59 -0700 Message-ID: <448DB10E.60808@cisco.com> Date: Mon, 12 Jun 2006 14:23:10 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] updated GRUU spec References: <4410B214.30800@cisco.com> <006801c64481$b3b7e080$31713b51@BEMBUSTER> In-Reply-To: <006801c64481$b3b7e080$31713b51@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jun 2006 20:43:59.0335 (UTC) FILETIME=[EE576F70:01C68E60] DKIM-Signature: a=rsa-sha1; q=dns; l=3064; t=1150145039; x=1151009039; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20updated=20GRUU=20spec; X=v=3Dcisco.com=3B=20h=3DCUdLAyjyiWnemXjhyFeXb4tsT1o=3D; b=i+WhrdR9qxGQFhD1+pf9YOEEMwifyKOyDjejVsL4pDQmLuw+KVRdMMhX194o02uznmg0Bsv+ c9pEN6yQOvZ+ys0zX3rkeeqNgUW+Itb997TOVb62BoT0ZY1FXl0sElbS; Authentication-Results: sj-dkim-7.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel wrote: > Jonathan, > > Nice to see this work progressing > > Some minor remarks: > - section 7.1.1.1 : Contacts provided by the UA should probably also not > contain the "gruu" URI parameter, as it should not be a GRUU Yes and no. Yes, in that, if the UA includes an "instance" parameter because it is asking for a gruu to be assigned, you are correct that the "gruu" URI param should be absent. No, in that, if the "instance" parameter is absent, a UA can in fact register a URI that is a gruu, much like it can register a URI that is an AOR. I've clarified that in the text, which reads: Besides the procedures discussed above, the REGISTER request is constructed as it is in the case where this extension was not understood. Specifically, the contact in the REGISTER request SHOUFrom sip-bounces@ietf.org Mon Jun 12 16:45:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FptGV-00071J-LW; Mon, 12 Jun 2006 16:44:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FptGT-0006yW-PP for sip@ietf.org; Mon, 12 Jun 2006 16:44:01 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FptGS-0004Yc-BO for sip@ietf.org; Mon, 12 Jun 2006 16:44:01 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 12 Jun 2006 13:43:59 -0700 X-IronPort-AV: i="4.05,229,1146466800"; d="scan'208"; a="293394454:sNHT33700756" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k5CKhxAP015992; Mon, 12 Jun 2006 13:43:59 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5CKhxIs029537; Mon, 12 Jun 2006 13:43:59 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 13:43:59 -0700 Received: from [128.107.178.16] ([128.107.178.16]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 13:43:59 -0700 Message-ID: <448DB10E.60808@cisco.com> Date: Mon, 12 Jun 2006 14:23:10 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] updated GRUU spec References: <4410B214.30800@cisco.com> <006801c64481$b3b7e080$31713b51@BEMBUSTER> In-Reply-To: <006801c64481$b3b7e080$31713b51@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jun 2006 20:43:59.0335 (UTC) FILETIME=[EE576F70:01C68E60] DKIM-Signature: a=rsa-sha1; q=dns; l=3064; t=1150145039; x=1151009039; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20updated=20GRUU=20spec; X=v=3Dcisco.com=3B=20h=3DCUdLAyjyiWnemXjhyFeXb4tsT1o=3D; b=i+WhrdR9qxGQFhD1+pf9YOEEMwifyKOyDjejVsL4pDQmLuw+KVRdMMhX194o02uznmg0Bsv+ c9pEN6yQOvZ+ys0zX3rkeeqNgUW+Itb997TOVb62BoT0ZY1FXl0sElbS; Authentication-Results: sj-dkim-7.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel wrote: > Jonathan, > > Nice to see this work progressing > > Some minor remarks: > - section 7.1.1.1 : Contacts provided by the UA should probably also not > contain the "gruu" URI parameter, as it should not be a GRUU Yes and no. Yes, in that, if the UA includes an "instance" parameter because it is asking for a gruu to be assigned, you are correct that the "gruu" URI param should be absent. No, in that, if the "instance" parameter is absent, a UA can in fact register a URI that is a gruu, much like it can register a URI that is an AOR. I've clarified that in the text, which reads: Besides the procedures discussed above, the REGISTER request is constructed as it is in the case where this extension was not understood. Specifically, the contact in the REGISTER request SHOULD NOT contain the gruu Contact header field parameter, and the contact URI itself SHOULD NOT contain the "grid" URI parameter defined below. Any such parameters are ignored by the registrar, as the UA cannot propose a GRUU for usage with the contact. Furthermore, the contact URI SHOULD NOT contain the "gruu" URI parameter, since a UA cannot register a GRUU as a contact URI and ask for the registrar to assign that contact a GRUU. Note, however, that a UA could include, in a registration, a contact that is a GRUU; however, in such a case, the "instance" Contact header field would absent. This would be similar to including an AOR in the contact URI of a registration. > - section 7.1.2.1 : should the REGISTER response contain a Supported or > Require header? Neither in fact. In the previous version, Require was required since the UA *had* to use the GRUU in order to properly process the response. As of -07 this is not needed, since with the "gruu" URI param, actual usage of the gruu is now optional, and nothing breaks if the UA doesn't use it. > > I suppose even if the UA is not requesting GRUUs, the registrar could still > indicate support for them, such that the UA knows it can request them. So a > suggestion might be: if REGISTER contains Supported: gruu, response MUST > have Require, else it SHOULD have Supported Per above Require isn't needed. Your idea of including Supported is interesting. However it brings us back into the vortex, discussed a few times on the list, of the scope of these values - does this mean all registrars in the domain support it? Is it supported for the specific AOR being registered or any AOR can get a gruu? etc. So I'd rather avoid it. > > - section 14.3 : This text still refers to Supported: gruu as the mechanism > to indicate that Contact is a GRUU Fixed. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 12 16:45:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FptGW-00071g-Cr; Mon, 12 Jun 2006 16:44:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FptGT-0006yb-Rg for sip@ietf.org; Mon, 12 Jun 2006 16:44:01 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FptGS-0004Yf-F0 for sip@ietf.org; Mon, 12 Jun 2006 16:44:01 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 12 Jun 2006 13:44:00 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k5CKhxpm029943; Mon, 12 Jun 2006 13:43:59 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5CKhxke016366; Mon, 12 Jun 2006 13:43:59 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 13:43:59 -0700 Received: from [128.107.178.16] ([128.107.178.16]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 13:43:58 -0700 Message-ID: <448DACE0.7050306@cisco.com> Date: Mon, 12 Jun 2006 14:05:20 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 TLD NOT contain the gruu Contact header field parameter, and the contact URI itself SHOULD NOT contain the "grid" URI parameter defined below. Any such parameters are ignored by the registrar, as the UA cannot propose a GRUU for usage with the contact. Furthermore, the contact URI SHOULD NOT contain the "gruu" URI parameter, since a UA cannot register a GRUU as a contact URI and ask for the registrar to assign that contact a GRUU. Note, however, that a UA could include, in a registration, a contact that is a GRUU; however, in such a case, the "instance" Contact header field would absent. This would be similar to including an AOR in the contact URI of a registration. > - section 7.1.2.1 : should the REGISTER response contain a Supported or > Require header? Neither in fact. In the previous version, Require was required since the UA *had* to use the GRUU in order to properly process the response. As of -07 this is not needed, since with the "gruu" URI param, actual usage of the gruu is now optional, and nothing breaks if the UA doesn't use it. > > I suppose even if the UA is not requesting GRUUs, the registrar could still > indicate support for them, such that the UA knows it can request them. So a > suggestion might be: if REGISTER contains Supported: gruu, response MUST > have Require, else it SHOULD have Supported Per above Require isn't needed. Your idea of including Supported is interesting. However it brings us back into the vortex, discussed a few times on the list, of the scope of these values - does this mean all registrars in the domain support it? Is it supported for the specific AOR being registered or any AOR can get a gruu? etc. So I'd rather avoid it. > > - section 14.3 : This text still refers to Supported: gruu as the mechanism > to indicate that Contact is a GRUU Fixed. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 12 16:45:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FptGW-00071g-Cr; Mon, 12 Jun 2006 16:44:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FptGT-0006yb-Rg for sip@ietf.org; Mon, 12 Jun 2006 16:44:01 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FptGS-0004Yf-F0 for sip@ietf.org; Mon, 12 Jun 2006 16:44:01 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 12 Jun 2006 13:44:00 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k5CKhxpm029943; Mon, 12 Jun 2006 13:43:59 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5CKhxke016366; Mon, 12 Jun 2006 13:43:59 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 13:43:59 -0700 Received: from [128.107.178.16] ([128.107.178.16]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 13:43:58 -0700 Message-ID: <448DACE0.7050306@cisco.com> Date: Mon, 12 Jun 2006 14:05:20 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fredrik Thulin References: <200603070956.38694.ft@it.su.se> In-Reply-To: <200603070956.38694.ft@it.su.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jun 2006 20:43:58.0870 (UTC) FILETIME=[EE107B60:01C68E60] DKIM-Signature: a=rsa-sha1; q=dns; l=2893; t=1150145039; x=1151009039; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20Questions=20on=20GRUU=20draft=2006; X=v=3Dcisco.com=3B=20h=3DBotOK+PJIIpjfzXtNBk7WL01dUg=3D; b=WImkyvClAAe/JDkgxHg/KUP5f35us0jnf68rTijN9UCgzxYknAw9nTj8LABw9wvaFev0iXwz I2k+d/gK4eB5TwkDVaEOH8uMFYSd4C0i0ZdDC/Pl3Nn128YTETZrAwBm; Authentication-Results: sj-dkim-3.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: sip@ietf.org Subject: [Sip] Re: Questions on GRUU draft 06 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org My apologies for the very, very long delay in responding, but these are good questions here and they deserve to be answered. Responses inline. Fredrik Thulin wrote: > Hi > > I have read draft-ietf-sip-gruu-06.txt, and implemented all the > applicable parts for my open source proxy (YXA). > > Generally I must say that GRUUs are pretty straight forward, if you > don't have to deal with the edge proxy problem (I don't, because my > application serving as an edge proxy handles REGISTER itself without > forwarding it to a 'home proxy' (distributed location database)). > > I have two questions which I really couldn't find an answer to myself : > > > 8.4.1 Request Targeting : > > >>If the Request URI is an >>AOR against which there are multiple registered contacts with the >>same instance ID parameter, the proxy MUST populate the target set so >>that there is never more than one contact at a time with a given >>instance ID. > > > Does this means the GRUU specification updates how a proxy should handle > requests to non-GRUUs as well? No - but sip-outbound does by specifying exactly this behavior. > > If two GRUU capable user agents have registered with an AOR, gotten two > different GRUUs, and then a request arrives for the AoR (_not_ one of > the GRUUs), does this apply? This sounds a bit weird to me. > > Maybe the scenario is about a request to a Request-URI which is a GRUU? > That is not perfectly clear to me at least. > > > 7.1.2.1 Processing a REGISTER Request : > > >>When generating the 200 (OK) response to the REGISTER request, the >>procedures of step 8 of Section 10.3 of RFC 3261 are followed. >>Furthermore, for each Contact header field value placed in the >>response, if the registrar has stored an instance ID associated with >>that contact, that instance ID is returned as a Contact header field >>parameter. > > > Why is this needed? The user agent already knows which instance id it > supplied, so it can't be for the user agents benefit the proxy puts all > the instance ids in there. In cases where more than one UA exists for a particular AOR, the instance ID in the register response allows the UA to find the contact (and expiration time) that it registered. Consider two UA, both behind NAT, each of which registers a SIP URI of sip:10.0.1.1. In such a case, the instance ID is the only thing in the register response that allows each UA to figure out what the expiration time for its contact is. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plo: Fredrik Thulin References: <200603070956.38694.ft@it.su.se> In-Reply-To: <200603070956.38694.ft@it.su.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jun 2006 20:43:58.0870 (UTC) FILETIME=[EE107B60:01C68E60] DKIM-Signature: a=rsa-sha1; q=dns; l=2893; t=1150145039; x=1151009039; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20Questions=20on=20GRUU=20draft=2006; X=v=3Dcisco.com=3B=20h=3DBotOK+PJIIpjfzXtNBk7WL01dUg=3D; b=WImkyvClAAe/JDkgxHg/KUP5f35us0jnf68rTijN9UCgzxYknAw9nTj8LABw9wvaFev0iXwz I2k+d/gK4eB5TwkDVaEOH8uMFYSd4C0i0ZdDC/Pl3Nn128YTETZrAwBm; Authentication-Results: sj-dkim-3.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: sip@ietf.org Subject: [Sip] Re: Questions on GRUU draft 06 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org My apologies for the very, very long delay in responding, but these are good questions here and they deserve to be answered. Responses inline. Fredrik Thulin wrote: > Hi > > I have read draft-ietf-sip-gruu-06.txt, and implemented all the > applicable parts for my open source proxy (YXA). > > Generally I must say that GRUUs are pretty straight forward, if you > don't have to deal with the edge proxy problem (I don't, because my > application serving as an edge proxy handles REGISTER itself without > forwarding it to a 'home proxy' (distributed location database)). > > I have two questions which I really couldn't find an answer to myself : > > > 8.4.1 Request Targeting : > > >>If the Request URI is an >>AOR against which there are multiple registered contacts with the >>same instance ID parameter, the proxy MUST populate the target set so >>that there is never more than one contact at a time with a given >>instance ID. > > > Does this means the GRUU specification updates how a proxy should handle > requests to non-GRUUs as well? No - but sip-outbound does by specifying exactly this behavior. > > If two GRUU capable user agents have registered with an AOR, gotten two > different GRUUs, and then a request arrives for the AoR (_not_ one of > the GRUUs), does this apply? This sounds a bit weird to me. > > Maybe the scenario is about a request to a Request-URI which is a GRUU? > That is not perfectly clear to me at least. > > > 7.1.2.1 Processing a REGISTER Request : > > >>When generating the 200 (OK) response to the REGISTER request, the >>procedures of step 8 of Section 10.3 of RFC 3261 are followed. >>Furthermore, for each Contact header field value placed in the >>response, if the registrar has stored an instance ID associated with >>that contact, that instance ID is returned as a Contact header field >>parameter. > > > Why is this needed? The user agent already knows which instance id it > supplied, so it can't be for the user agents benefit the proxy puts all > the instance ids in there. In cases where more than one UA exists for a particular AOR, the instance ID in the register response allows the UA to find the contact (and expiration time) that it registered. Consider two UA, both behind NAT, each of which registers a SIP URI of sip:10.0.1.1. In such a case, the instance ID is the only thing in the register response that allows each UA to figure out what the expiration time for its contact is. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip aza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 12 20:14:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpwWM-0005iR-4h; Mon, 12 Jun 2006 20:12:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpwWK-0005hg-4f for sip@ietf.org; Mon, 12 Jun 2006 20:12:36 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpwNZ-0001Sw-35 for sip@ietf.org; Mon, 12 Jun 2006 20:03:34 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k5D03Uw20640; Mon, 12 Jun 2006 20:03:30 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Jun 2006 19:03:28 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0A815655@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Error (nit) in RFC 3261 Thread-Index: AcaOfMtmTMikx8//S42pmmaN8aXiyA== From: "Francois Audet" To: , "Dean Willis" , "Keith Drage" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [Sip] Error (nit) in RFC 3261 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I spotted an error in RFC 3261. The Registration response (200) in section 24.1 on p. 214 uses and = Expires Header. Section 10.3, point 8 (on p. 66) states that the 200 MUST use an expires = parameter, not an Expire Header (one for each contact).=20 This is clearly an error. Also, the text says that the 200 SHOULD have a Date header, but the = example on p. 214 doesn't have one. This is not really an error and it seems to be widespread = omission (RFC 3265, outbound,=20 etc.). Not sure what is the process for putting this in the Errata. ---- Fran=E7ois AUDET, Nortel Networks mailto:audet@nortel.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 12 21:25:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpxdP-0003zO-6H; Mon, 12 Jun 2006 21:23:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpxdO-0003zJ-Gt for sip@ietf.org; Mon, 12 Jun 2006 21:23:58 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpxdL-0007ua-S8 for sip@ietf.org; Mon, 12 Jun 2006 21:23:58 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 12 Jun 2006 18:23:56 -0700 X-IronPort-AV: i="4.06,124,1149490800"; d="scan'208"; a="324835400:sNHT36817516" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k5D1NsAT025537; Mon, 12 Jun 2006 18:23:54 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5D1NrCU028221; Mon, 12 Jun 2006 18:23:53 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 18:23:53 -0700 Received: from [128.107.178.16] ([128.107.178.16]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 18:23:52 -0700 Message-ID: <448E13A8.6030702@cisco.com> Date: Mon, 12 Jun 2006 21:23:52 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] draft-ietf-sip-outbound-03: proxy routing question References: <446BFE27.4070909@opencloud.com> <5FE19E1C-71D9-4FF9-A2B3-FBD704CCC9F8@softarmor.com> <446D3E5E.4070800@opencloud.com> <1EA8E825-08B5-4433-8E7B-7BF0699366BD@softarmor.com> In-Reply-To: <1EA8E825-08B5-4433-8E7B-7BF0699366BD@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jun 2006 01:23:52.0930 (UTC) FILETIME=[081AAC20:01C68E88] DKIM-Signature: a=rsa-sha1; q=dns; l=6243; t=1150161835; x=1151025835; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20draft-ietf-sip-outbound-03=3A=20proxy=20routing=20questi on; X=v=3Dcisco.com=3B=20h=3D2ktEldezZAq/MB3q+H7hcEaEWzs=3D; b=jUtIy+yAsZKTaJqGeVC9mEnyWPDjRKeqMs+6YFcT26FEMalTnS7oXxzIqWen4WEmruRPG2uT fMz4qFV+WvrE1t9zEVzOTBhmqsbrbFH8zk5ha/g+sQDIa9fB4Wk2hp/i; Authentication-Results: sj-dkim-3.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: Cullen Jennings , sip@ietf.org, Ben Evans X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The double record-routing is neccesary if one of two conditions are true (or both): 1. a proxy is reachable at different IP addresses/hostnames/ports on each side of the dialog, OR 2. the next hop where a mid-dialog request should go is a function not just of where its going, but where it came from We've traditionally used double-RR in case 1. Its still pretty much undocumented I think. SIP outbound introduces (not sure if its the first time) case number 2. Consider a mid-dialog request from UA1 towards UA2. Such a request would look like: INVITE sip:ua2-contact Route: sip:ua1-rr and from UA2, towards UA1: INVITE sip:ua1-contact Route: sip:ua2-rr The issue that Ben is raising, I think, is that, prior to sip-outbound, the proxy would receive the request, pop the top route (being its own), and then find no more Route headers, thus use RFC 3263 on the r-uri to send it on its way. With sip-outbound, thats not really true. The next hop decision made by the proxy depends on the *direction* the request is coming from. For the request from UA1 towards UA2, its standard DNS SRV. For the request from UA2 towards UA1. However, even though the domain in the r-uri doesn't match that of the proxy, its NOT standard DNS SRV. Rather, the proxy needs to know to place the request on the existing connection towards UA1. How does it know to do that? Should it rely on the value of the R-URI? Turns out thats a bad idea (a bit more on that below). Rather, the value in the Route header field is what would tell it to do that. But, if ua1-rr == ua2-rr, it doesn't work. GRUU, if anything makes this problem even more amplified. Mid-dialog requests towards the client, per gruu-07, will have the registered contact in the Request-URI, as in the examples above. However, that contact got there because the home proxy translated the GRUU that was in the r-uri into that contact. Turns out, there is a decent chance that, if a client has multiple flows registered, the home proxy might get it wrong. This means that the r-uri for mid-dialog requests becomes even less reliable for telling the proxy where to send the mid-dialog request (but ONLY for requests towards the client). This means that the Route header is really the only way to know the algorithm to apply for forwarding (DNS SRV vs. connection mapping). Thus, to make a long story short, I think sip-outbound does in fact push heavily towards double-RR, and GRUU only amplifies this need further. I do think its worth documenting this in sip-outbound. Indeed, while revising gruu today, I more or less convinced myself that sip-outbound needs to almost mandate that a proxy NOT look at the r-uri to determine which connection on which to send a request. Thanks, Jonathan R. Dean Willis wrote: > > > Why would GRUU keep the proxy from being able to double-R-R? It might > change what would go INTO the R-R, which shouldn't be a problem. > > -- > Dean > > > On Jun 11, 2006, at 5:32 PM, Cullen Jennings wrote: > >> >> Ahhg --- when using GRUU this may just happen without the double R- R. >> I've no objections to putting some clarifying hints in but I'm really >> not sure exactly what to add. Anyone want to send text? >> >> On May 19, 2006, at 4:52 PM, Dean Willis wrote: >> >>> On May 18, 2006, at 10:41 PM, Ben Evans wrote: >>> >>>> Dean Willis wrote: >>>> >>>>> >>>>> On May 17, 2006, at 11:55 PM, Ben Evans wrote: >>>>> >>>>>> [...] >>>>>> Because the ACK's Request-URI contains UA1's contact URI, not the >>>>>> AOR, the proxy would normally not do a location service lookup (the >>>>>> contact URI is a physical IP address/port). So how does the proxy >>>>>> obtain the flow information from the location service so that >>>>>> it can >>>>>> send the ACK (and any future mid-dialog requests) on the correct >>>>>> flow? What am I missing? >>>>> >>>>> >>>>> >>>>> My theory is that the proxy should use the "double record routing >>>>> trick". As such, it inserts two R-R values. The first identifies the >>>>> interface and flow binding for UA1, and the second identifies the >>>>> interface as seen by UA2. >>>>> >>>>> When the proxy receives the ACK at step 6, it pops the first >>>>> route (its >>>>> interface facing UA2). It then inspects the next route to figure out >>>>> where to send. Since this next route is also "local", it pops this >>>>> route field, picks the flow from the information in that route >>>>> field, >>>>> and puts the ACK onto the flow towards UA1. >>>>> >>>>> We originally developed this trick to work with proxies that have >>>>> more >>>>> than one interface, but since the flow identifier is sort of a >>>>> "virtual >>>>> interface", the technique should work here. >>>> >>>> >>>> Thanks Dean, this worked really well. Should this technique should >>>> be mentioned in the draft? Or maybe it is already obvious to those >>>> in the know! >>> >>> >>> Good point. Probably wouldn't hurt to mention it. Lots of people >>> just assume people understand this, so it may not get the needed >>> coverage. >>> >>> Oh Mr. Outbound Editor . . . >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 12 21:36:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpxoA-0000oV-A8; Mon, 12 Jun 2006 21:35:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpxo8-0000oQ-Ve for sip@ietf.org; Mon, 12 Jun 2006 21:35:04 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpxo7-000053-Jv for sip@ietf.org; Mon, 12 Jun 2006 21:35:04 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 12 Jun 2006 18:35:03 -0700 X-IronPort-AV: i="4.06,124,1149490800"; d="scan'208"; a="1824413141:sNHT34145148" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k5D1Z3s9027854; Mon, 12 Jun 2006 18:35:03 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5D1Z2cL027029; Mon, 12 Jun 2006 18:35:02 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 18:35:01 -0700 Received: from [128.107.178.16] ([128.107.178.16]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 18:35:01 -0700 Message-ID: <448E1645.8010100@cisco.com> Date: Mon, 12 Jun 2006 21:35:01 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Sip] Re: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-03.txt References: <001b01c657ad$4e1f7140$31713b51@BEMBUSTER> <724f0adb9bc60dd7c2470bafe1051049@ekabal.com> <003201c6581a$5dc93820$31713b51@BEMBUSTER> <7e2ba47a62b9533774cf8a0ba8b5ac0d@ekabal.com> In-Reply-To: <7e2ba47a62b9533774cf8a0ba8b5ac0d@ekabal.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jun 2006 01:35:01.0462 (UTC) FILETIME=[96948F60:01C68E89] DKIM-Signature: a=rsa-sha1; q=dns; l=2167; t=1150162503; x=1151026503; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20=09Re=3A=20http=3A//www.ietf.org/internet-drafts/draft-i etf-sip-outbound-03.txt; X=v=3Dcisco.com=3B=20h=3DXdZqA7ei+GH8jJsYnuYR1UUi6Ps=3D; b=HS0SgGnLn0eb6QkLaaEEHp9Tcv2XRHIpzymqvH40jnCWwrU3X/pNi7LwuWIMRtjqF6dM+BGc bPSw/RbBpCHH5hbFnYJ7VtfAbyMU5+iKeO0pKf3z8RXS0nj128313Fp6; Authentication-Results: sj-dkim-7.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.6 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Rohan Mahy wrote: >> [Jvb] This part I understood. Perhaps my question below wasn't clear. >> (1a) is about the moment a request comes in destined for an AoR which >> has 2 registered contacts. At least one of them (the most recent one) >> has an associated flow, but the other has a higher q-value. Question >> is: which one gets selected? > > > How the proxy selects specific instances (whether determined by unique > instance-id or contact URI) to make up the fork set is (still) proxy > local policy. I know of several proxies that parallel fork all the > instances with the same q-value then wait and parallel fork the > instances with the next q-value. Outbound doesn't change any of this. > Once you decide to try instance xyz then what flow you pick is described > in outbound. I think I understand Jeroen's question and its not what you are talking about. Consider a single UA instance which registers two flows: REGISTER Contact: ;+sip.instance="INSTANCE1" ;reg-id=1 q=1.0 and then, 10 minutes later: REGISTER Contact: ;+sip.instance="INSTANCE1" ;reg-id=2 q=0.5 Now, we have two flows for the same instance. Flow 2 is the most recently registered flow for that instance, and per sip-outbound would be selected. HOWEVER, it has a lower q-value than flow 1. So, which precedence rule wins? Does the proxy pick the flow that is most recently registered, or that has the highest q-value? I would argue that the q-value based selection is ONLY applicable for choosing between different instances, and that q-value is basically irrelevant for choosing between flows to the same instance. The spec should probably make this clearer. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 12 21:42:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpxtP-0003Ss-CG; Mon, 12 Jun 2006 21:40:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpxt7-0003Mo-GC for sip@ietf.org; Mon, 12 Jun 2006 21:40:13 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpxt6-0000bH-4h for sip@ietf.org; Mon, 12 Jun 2006 21:40:13 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 12 Jun 2006 18:40:11 -0700 X-IronPort-AV: i="4.06,124,1149490800"; d="scan'208"; a="293546866:sNHT32303100" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k5D1eBNX019124; Mon, 12 Jun 2006 18:40:11 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5D1eBCU002449; Mon, 12 Jun 2006 18:40:11 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 18:40:11 -0700 Received: from [128.107.178.16] ([128.107.178.16]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 18:40:10 -0700 Message-ID: <448E177A.4000609@cisco.com> Date: Mon, 12 Jun 2006 21:40:10 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Lawrence Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt References: <44887921.20302@cisco.com> <1149796932.4721.129.camel@localhost.localdomain> <44898BD0.7000705@cisco.com> <1149882511.2865.50.camel@sukothai.pingtel.com> In-Reply-To: <1149882511.2865.50.camel@sukothai.pingtel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jun 2006 01:40:10.0665 (UTC) FILETIME=[4EE13190:01C68E8A] DKIM-Signature: a=rsa-sha1; q=dns; l=2681; t=1150162811; x=1151026811; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20I-D=20ACTION=3Adraft-ietf-sip-hop-limit-diagnostics-02.t xt; X=v=3Dcisco.com=3B=20h=3DbNh0c34VJf6h7+g6FnEK3owlh8o=3D; b=E7nHf6cPEg35MGvdFXXsBQuhPFBsmYqJ3Mmw4OSo53nfqAL5yjs7/3JLw2UC5E6JyMVCRN0M /3hXVLndhkLlJtL0IgX5DGZLMZiVeJBy2C1c9KK4ha39cehIaO/0hkS4; Authentication-Results: sj-dkim-4.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Scott Lawrence wrote: >>Hmm, I find no text in either RFC 3261 or 2616 which would indicate >>whether Accept applies to error responses or not. I don't have a big >>problem with sending it anyway, but the spec should call out that this >>would be done regardless of the Accept value and thus the body may not >>be understood by a UAC. > > > I admit that I didn't look hard before writing this draft - my > presumption that it is ok came from my HTTP background. I could argue > that RFC 2616 (HTTP 1.1) _does_ spell this out (in section 10.4.7 406 > Not Acceptable): > > Note: HTTP/1.1 servers are allowed to return responses which are > not acceptable according to the accept headers sent in the > request. In some cases, this may even be preferable to sending a > 406 response. User agents are encouraged to inspect the headers of > an incoming response to determine if it is acceptable. Ah. I had missed this bit in RFC 2616. I had read only the definition of Accept and didn't find it there. > > and that RFC 3261 says, in section 20.1 Accept: > > The Accept header field follows the syntax defined in [H14.1]. The > semantics are also identical, with the exception that if no Accept > header field is present, the server SHOULD assume a default value of > application/sdp. > > Whether or not the exception in 3261 invalidates the liberality of 2616 > may be controversial. At the very least, its not clear. > > My reading of the discussion I do find on Accept usage in 3261 is all > focused on either: how it is used in a request to restrict what is > acceptable in a session, or how to reject something and communicate what > would have been ok. All of that is focused on UAs, because proxies are > explicitly assumed to be agnostic with respect to methods and bodies. > > I would not have a problem with putting in a section to clarify this > point (of course, I'd want to do it with the liberal HTTP-ish > interpretation that servers can do whatever they want as long as they > understand that it may not work). I feel a wider discussion coming > on... if so, I suggest that it get a thread with a title that will draw > more eyes... I'm fine with the more liberal approach. It just needs to be clarified. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 13 04:34:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4KG-0000z9-Au; Tue, 13 Jun 2006 04:32:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4KF-0000yy-4N for sip@ietf.org; Tue, 13 Jun 2006 04:32:39 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq3uI-0005al-I7 for sip@ietf.org; Tue, 13 Jun 2006 04:05:50 -0400 Received: from maild.telecomitalia.it ([156.54.233.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fq3mp-0000gA-QH for sip@ietf.org; Tue, 13 Jun 2006 03:58:11 -0400 Thread-Index: AcaOvxoFWIuYIojcS0KbP4+NJ49m9g== Received: from ptpxch009ba020.idc.cww.telecomitalia.it ([156.54.240.52]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Jun 2006 09:58:03 +0200 Received: from PTPXCH029BA020.idc.cww.telecomitalia.it ([156.54.240.46]) by ptpxch009ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Jun 2006 09:58:03 +0200 Received: from [163.162.113.134] ([163.162.113.134]) by PTPXCH029BA020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Jun 2006 09:58:00 +0200 Message-ID: <448E6FF5.7080608@telecomitalia.it> Date: Tue, 13 Jun 2006 09:57:41 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 Content-Class: urn:content-classes:message Importance: normal Priority: normal From: "Alberto Cuda" User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Dean Willis" Subject: Re: [Sip] Supported: in ACK References: <013101c68dab$f7e1eb20$31713b51@BEMBUSTER> <63069486-864A-4FF7-89B1-3CB7586F8687@softarmor.com> In-Reply-To: <63069486-864A-4FF7-89B1-3CB7586F8687@softarmor.com> X-OriginalArrivalTime: 13 Jun 2006 07:58:00.0804 (UTC) FILETIME=[1755E240:01C68EBF] X-Spam-Score: -2.6 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Sip IETF X-BeenThere: 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="===============1653122598==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1653122598== Content-Type: multipart/alternative; boundary="----=_NextPart_000_143DEC_01C68ECF.DD8E68F0" Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_143DEC_01C68ECF.DD8E68F0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dean Willis wrote: > >> 2) Can/should you include (Proxy-)Require in ACK > > > I don't think you can, since a proxy cannot reject an ACK that has a =20 > Proxy-Require: that is not supported by the proxy. I think it should, otherwise we are causing problems to stateless = proxies: if they reject an INVITE request containing a Proxy-Require they do not understand, they should drop the ACK request as well, or they will try to forward it. Cheers. Alberto. -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please contact us by replying to = webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- ------=_NextPart_000_143DEC_01C68ECF.DD8E68F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Dean Willis = wrote:

>
>> 2) Can/should you include (Proxy-)Require in = ACK
>
>
> I don't think you can, since a proxy cannot reject an = ACK that has a
> Proxy-Require: that is not supported by the = proxy.

I think it should, otherwise we are causing problems to = stateless proxies:
if they reject an INVITE request containing a = Proxy-Require they do not
understand, they should drop the ACK = request as well, or they will try
to forward it.

= Cheers.
Alberto.

--------------------------------------------------------------------=
CONFIDENTIALITY=20 NOTICE
This message and its attachments are addressed solely to the=20 persons
above and may contain confidential information. If you have=20 received
the message in error, be informed that any use of the = content=20 hereof
is prohibited. Please return it immediately to the sender and=20 delete
the message. Should you have any questions, please contact us=20 by
replying to webmaster@telecomitalia.it.
        = Thank=20 you
           =             &= nbsp;           &n= bsp;   =20 www.telecomitalia.it
--------------------------------------------------------------------=
------=_NextPart_000_143DEC_01C68ECF.DD8E68F0-- --===============1653122598== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1653122598==-- From sip-bounces@ietf.org Tue Jun 13 05:56:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq5bn-00045s-74; Tue, 13 Jun 2006 05:54:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq5bl-00045n-Mc for sip@ietf.org; Tue, 13 Jun 2006 05:54:49 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq5bk-0007EN-7j for sip@ietf.org; Tue, 13 Jun 2006 05:54:49 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5D9siTe007095 for ; Tue, 13 Jun 2006 12:54:47 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Jun 2006 12:54:46 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Jun 2006 12:54:47 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [Sip] draft-koivusalo-sip-outbound-discovery-01 published Date: Tue, 13 Jun 2006 12:54:46 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F026C1E4D@esebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-koivusalo-sip-outbound-discovery-01 published Thread-Index: AcaOz2bzKfaKoThcQ9+wcaszN53KOQ== From: To: X-OriginalArrivalTime: 13 Jun 2006 09:54:47.0246 (UTC) FILETIME=[678016E0:01C68ECF] X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I have submitted the second version of the I-D for SIP Outbound autodiscovery. Please check it and let me know what you think about it. Regards, Erkki A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Discovering Proxies Supporting SIP Outbound Author(s) : E. Koivusalo Filename : draft-koivusalo-sip-outbound-discovery-01.txt Pages : 22 Date : 2006-6-1 =09 This document describes modifications to DNS procedures used to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact. These modifications enable the SIP User Agent (UA) to discover those proxies, within the domain of the SIP URI, that support SIP extensions described in draft-ietf-sip-outbound document. The introduced mechanisms update behavior defined in RFC 3263. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-koivusalo-sip-outbound-discove ry-01.txt _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 13 06:22:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq60o-0007fx-M5; Tue, 13 Jun 2006 06:20:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq60n-0007d2-G5 for sip@ietf.org; Tue, 13 Jun 2006 06:20:41 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq60m-00011E-Su for sip@ietf.org; Tue, 13 Jun 2006 06:20:41 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5DAKbmr028479; Tue, 13 Jun 2006 13:20:38 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Jun 2006 13:20:06 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Jun 2006 13:20:06 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] outbound i-d update? Date: Tue, 13 Jun 2006 13:20:05 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F026C1E91@esebe103.NOE.Nokia.com> In-Reply-To: <17549.8798.26258.703846@rautu.tutpro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] outbound i-d update? Thread-Index: AcaN+Js3v5W2tC5TQoaLp+/GCqy+DwA2bm5Q From: To: , X-OriginalArrivalTime: 13 Jun 2006 10:20:06.0214 (UTC) FILETIME=[F0E03660:01C68ED2] X-Spam-Score: 0.2 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Juha and Cullen, > 4.2 Initial Registrations > > UAs are configured with one or more SIP URIs representing=20 >the default > outbound-proxy-set. > >UAs are configured with two or more ... Please do not forget about the effort to get the SIP Outbound autodiscovery defined to rely on configuring only one single URI with which the UA is able to derive the addresses of multiple proxies. I would hope to keep the door still open for such a solution. > If a UA has multiple flows, and one of the servers fails, it can > delay some significant time before trying to form a new connection > to replace the flow to the server that failed. > >the "If" surprises me here. i thought that the key idea of >outbound-id is that each UA tries to keep more than flow active at all >times. if this is not a requirement, then there is no chance for >reliable load balancing and we are back in square one. There has been some requests on the list to have it possible for a mobile device to keep only a single flow open in order to save the battery. I still think SRV has a way to facilitate load balancing even if the basic SRV has always aimed at one single connection per client. By maintaining one single flow the UA does not get as high reliability as with multiple flows, but I think load balancing could still be achieved. Regards, Erkki >-----Original Message----- >From: ext Juha Heinanen [mailto:jh@tutpro.com]=20 >Sent: 12.June.2006 11:14 >To: Cullen Jennings >Cc: sip@ietf.org >Subject: Re: [Sip] outbound i-d update? > > 1. Introduction > > Since such detection takes time and leaves a window of=20 >opportunity for > missed incoming requests, this mechanism allows the UA to=20 >use multiple > flows to the proxy or registrar. > >i would say: > >... to use simultaneous flows to multiple proxy or registrar hosts. > >since i don't understand what would multiple flows to THE proxy help. > > 2.1 Definitions > > outbound-proxy-set > > The first URI in the set is often refereed too as the=20 >primary outbound > proxy and the second in as the secondary outbound=20 >proxy. There is no > difference between the first and second and the=20 >primary/secondary does > not imply one is preferred over the other. > >what is the third and fourth referred to? i would simply remove these >two sentences. > > 3.3 Multiple Connections from a User Agent > > In the example system below, the logical proxy/registrar for the > domain is running on two hosts that share the appropriate state and > can both provide registrar and proxy functionality for the > domain. The UA will form connections to two of the physical hosts > that can perform the proxy/registrar function for the > domain. Reliability is achieved by having the UA form two TCP > connections to the domain. > Scalability is achieved by using DNS SRV to load balance=20 >the primary > connection across a set of machines that can service the primary > connection and also using DNS SRV to load balance across a separate > set of machines that can service the secondary connection. The > deployment here requires that DNS is configured with one entry that > resolves to all the primary hosts and another entry that=20 >resolves to > all the secondary hosts. Designs having only one set were also > considered, but in this case there would have to be some way to > ensure that the two connection did not accidentally resolve to the > same host. Various approaches for this are possible but=20 >all probably > require extensions to the SIP protocol so they were not included in > this specification. This approach can work with the disadvantage > that slightly more configuration of DNS is required. > >i would greatly simplify the text: > >In the example system below, the logical outbound proxy/registrar for >the domain is running on two hosts that share the appropriate state and >can both provide registrar and outbound proxy functionality for the >domain. The UA will form connections to two of the physical hosts that >can perform the outbound proxy/registrar function for the >domain. Reliability is achieved by having the UA form two TCP >connections to the domain. Scalability is achieved by using DNS SRV >records to load balance connections to the set of hosts that represent >outbound proxies of the domain." > >instead of using the term "proxy", the above text uses the=20 >defined (2.1) >term outbound proxy. more importantly, the details of implementing >scalability are left as an internal matter of the domain. > > The UA is configured with a primary and secondary=20 >registration URI.=20 > >i would say: > >The UA is configured with at least two URIs that represent at least two >outbound proxies. > >again, use of the defined term "outbound proxy" and get rid of >primary/secondary. > > When a single server fails, ... > >again a new undefined term "server". i would say > > When a single outbound proxy host fails, ... > > If a UA has multiple flows, and one of the servers fails, it can > delay some significant time before trying to form a new connection > to replace the flow to the server that failed. > >the "If" surprises me here. i thought that the key idea of >outbound-id is that each UA tries to keep more than flow active at all >times. if this is not a requirement, then there is no chance for >reliable load balancing and we are back in square one. > > 4.2 Initial Registrations > > UAs are configured with one or more SIP URIs representing=20 >the default > outbound-proxy-set. > >UAs are configured with two or more ... > > However, a UA MUST support sets with at least two outbound proxy > URIs (primary and secondary) and SHOULD support sets with=20 >up to four > URIs. > >leave out "(primary and secondary)". > >-- 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 Tue Jun 13 07:39:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq7Df-0006Yl-JP; Tue, 13 Jun 2006 07:38:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq7De-0006Yg-48 for sip@ietf.org; Tue, 13 Jun 2006 07:38:02 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq7Dc-0000Iv-OO for sip@ietf.org; Tue, 13 Jun 2006 07:38:02 -0400 Received: from BPenfield [10.0.200.6] by acmepacket.com with ESMTP (SMTPD-9.03) id A38904D0; Tue, 13 Jun 2006 07:37:45 -0400 Message-ID: <008c01c68edd$cb635880$800101df@acmepacket.com> From: "Bob Penfield" To: "Jonathan Rosenberg" , "Rohan Mahy" References: <001b01c657ad$4e1f7140$31713b51@BEMBUSTER> <724f0adb9bc60dd7c2470bafe1051049@ekabal.com> <003201c6581a$5dc93820$31713b51@BEMBUSTER><7e2ba47a62b9533774cf8a0ba8b5ac0d@ekabal.com> <448E1645.8010100@cisco.com> Subject: Re: [Sip] Re:http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-03.txt Date: Tue, 13 Jun 2006 07:37:47 -0400 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.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline ----- Original Message ----- From: "Jonathan Rosenberg" To: "Rohan Mahy" Cc: Sent: Monday, June 12, 2006 9:35 PM Subject: Re: [Sip] Re:http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-03.txt > inline. > > Rohan Mahy wrote: > > >>> [Jvb] This part I understood. Perhaps my question below wasn't clear. >>> (1a) is about the moment a request comes in destined for an AoR which >>> has 2 registered contacts. At least one of them (the most recent one) >>> has an associated flow, but the other has a higher q-value. Question is: >>> which one gets selected? >> >> >> How the proxy selects specific instances (whether determined by unique >> instance-id or contact URI) to make up the fork set is (still) proxy >> local policy. I know of several proxies that parallel fork all the >> instances with the same q-value then wait and parallel fork the instances >> with the next q-value. Outbound doesn't change any of this. Once you >> decide to try instance xyz then what flow you pick is described in >> outbound. > > I think I understand Jeroen's question and its not what you are talking > about. Consider a single UA instance which registers two flows: > > REGISTER > Contact: > ;+sip.instance="INSTANCE1" > ;reg-id=1 > q=1.0 > > and then, 10 minutes later: > > REGISTER > Contact: > ;+sip.instance="INSTANCE1" > ;reg-id=2 > q=0.5 > > Now, we have two flows for the same instance. Flow 2 is the most recently > registered flow for that instance, and per sip-outbound would be selected. > HOWEVER, it has a lower q-value than flow 1. So, which precedence rule > wins? Does the proxy pick the flow that is most recently registered, or > that has the highest q-value? > > I would argue that the q-value based selection is ONLY applicable for > choosing between different instances, and that q-value is basically > irrelevant for choosing between flows to the same instance. The spec > should probably make this clearer. I disagree here. Outbound says "If the instance-id and reg-id are the same as a previous registration for the same AOR, the proxy uses the most recently created registration first". The 2 contacts in your example are for 2 different reg-ids. The UA is expressing a preference for the proxy to use the flow for reg-id 1 over the flow for reg-id 2. In this case, I would think the proxy would use the reg-id 1 flow if it is still alive. > > > Thanks, > Jonathan R. > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 13 09:54:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq9K0-00060T-Ah; Tue, 13 Jun 2006 09:52:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq9Jz-0005zk-DA for sip@ietf.org; Tue, 13 Jun 2006 09:52:43 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq9Jy-0006L5-30 for sip@ietf.org; Tue, 13 Jun 2006 09:52:43 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 13 Jun 2006 06:51:42 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,127,1149490800"; d="scan'208"; a="29376428:sNHT22834128" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5DDpfYL028402; Tue, 13 Jun 2006 09:51:41 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Jun 2006 09:51:41 -0400 Received: from [161.44.79.149] ([161.44.79.149]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Jun 2006 09:51:41 -0400 Message-ID: <448EC2EC.4010001@cisco.com> Date: Tue, 13 Jun 2006 09:51:40 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] Error (nit) in RFC 3261 References: <1ECE0EB50388174790F9694F77522CCF0A815655@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0A815655@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 13 Jun 2006 13:51:41.0089 (UTC) FILETIME=[7F9C6910:01C68EF0] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: sip@ietf.org, Keith Drage , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois Audet wrote: > I spotted an error in RFC 3261. > > The Registration response (200) in section 24.1 on p. 214 uses and Expires Header. > > Section 10.3, point 8 (on p. 66) states that the 200 MUST use an expires parameter, not > an Expire Header (one for each contact). > > This is clearly an error. If/when 3261 gets updated, can we please do something clean? Specifically, say that in a REGISTER request or response the Expires header serves as a default value for any Contact that doesn't have an expires parameter. Paul > Also, the text says that the 200 SHOULD have a Date header, but the example on p. 214 doesn't > have one. This is not really an error and it seems to be widespread omission (RFC 3265, outbound, > etc.). > > Not sure what is the process for putting this in the Errata. > > ---- > François AUDET, Nortel Networks > mailto:audet@nortel.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 13 09:58:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq9Nz-00015B-8V; Tue, 13 Jun 2006 09:56:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq9Nx-0000rq-JG for sip@ietf.org; Tue, 13 Jun 2006 09:56:49 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq9Nw-0006tT-AE for sip@ietf.org; Tue, 13 Jun 2006 09:56:49 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 13 Jun 2006 09:56:48 -0400 X-IronPort-AV: i="4.06,127,1149480000"; d="scan'208"; a="89913763:sNHT39410284" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5DDulno011863; Tue, 13 Jun 2006 09:56:47 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Jun 2006 09:56:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Error (nit) in RFC 3261 Date: Tue, 13 Jun 2006 09:56:47 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301917B8C@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Error (nit) in RFC 3261 Thread-Index: AcaO8LViFPEHbqlBSn+GcLTK5CLtVQAABq6A From: "Michael Hammer \(mhammer\)" To: "Paul Kyzivat \(pkyzivat\)" , "Francois Audet" X-OriginalArrivalTime: 13 Jun 2006 13:56:47.0776 (UTC) FILETIME=[36692200:01C68EF1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: sip@ietf.org, Keith Drage , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org FTI, p. 162 indicates that Expires is optional for Reg. p. 59 indicates that the usage of Expires header that Paul is = suggestiong: Look in "expires" para: "If this parameter is not provided, the value = of the Expires header field is used instead." Mike =20 > -----Original Message----- > From: Paul Kyzivat (pkyzivat)=20 > Sent: Tuesday, June 13, 2006 9:52 AM > To: Francois Audet > Cc: sip@ietf.org; Keith Drage; Dean Willis > Subject: Re: [Sip] Error (nit) in RFC 3261 >=20 >=20 >=20 > Francois Audet wrote: > > I spotted an error in RFC 3261. > >=20 > > The Registration response (200) in section 24.1 on p. 214=20 > uses and Expires Header. > >=20 > > Section 10.3, point 8 (on p. 66) states that the 200 MUST use an=20 > > expires parameter, not an Expire Header (one for each contact). > >=20 > > This is clearly an error. >=20 > If/when 3261 gets updated, can we please do something clean?=20 > Specifically, say that in a REGISTER request or response the=20 > Expires header serves as a default value for any Contact that=20 > doesn't have an expires parameter. >=20 > Paul >=20 > > Also, the text says that the 200 SHOULD have a Date header, but the=20 > > example on p. 214 doesn't have one. This is not really an=20 > error and it=20 > > seems to be widespread omission (RFC 3265, outbound, etc.). > >=20 > > Not sure what is the process for putting this in the Errata. > >=20 > > ---- > > Fran=E7ois AUDET, Nortel Networks > > mailto:audet@nortel.com > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 13 10:05:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq9V3-0003pd-7c; Tue, 13 Jun 2006 10:04:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq9V2-0003pY-8u for sip@ietf.org; Tue, 13 Jun 2006 10:04:08 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq9V0-00079M-Ur for sip@ietf.org; Tue, 13 Jun 2006 10:04:08 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 13 Jun 2006 10:04:07 -0400 X-IronPort-AV: i="4.06,127,1149480000"; d="scan'208"; a="89914928:sNHT31443844" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5DE46YL002241; Tue, 13 Jun 2006 10:04:06 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Jun 2006 10:04:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re:http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-03.txt Date: Tue, 13 Jun 2006 10:04:05 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301917B97@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re:http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-03.txt Thread-Index: AcaOiZ9iH4+OnWguQtCLjMRAra73NgAaDuNA From: "Michael Hammer \(mhammer\)" To: "Jonathan Rosenberg \(jdrosen\)" , "Rohan Mahy" X-OriginalArrivalTime: 13 Jun 2006 14:04:06.0566 (UTC) FILETIME=[3BF32C60:01C68EF2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org By clearer do you mean to write it such that this problem doesn't occur, or handle the problem after it does occur? Could I suggest: "Contacts with the same instance-id MUST have the same q-value." That would take q-value out of the equation. Mike =20 > -----Original Message----- > From: Jonathan Rosenberg (jdrosen)=20 > Sent: Monday, June 12, 2006 9:35 PM > To: Rohan Mahy > Cc: sip@ietf.org > Subject: Re: [Sip]=20 > Re:http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-03.txt >=20 > inline. >=20 > Rohan Mahy wrote: >=20 >=20 > >> [Jvb] This part I understood. Perhaps my question below=20 > wasn't clear.=20 > >> (1a) is about the moment a request comes in destined for=20 > an AoR which=20 > >> has 2 registered contacts. At least one of them (the most=20 > recent one)=20 > >> has an associated flow, but the other has a higher=20 > q-value. Question > >> is: which one gets selected? > >=20 > >=20 > > How the proxy selects specific instances (whether=20 > determined by unique=20 > > instance-id or contact URI) to make up the fork set is=20 > (still) proxy=20 > > local policy. I know of several proxies that parallel fork all the=20 > > instances with the same q-value then wait and parallel fork the=20 > > instances with the next q-value. Outbound doesn't change=20 > any of this. > > Once you decide to try instance xyz then what flow you pick is=20 > > described in outbound. >=20 > I think I understand Jeroen's question and its not what you=20 > are talking about. Consider a single UA instance which=20 > registers two flows: >=20 > REGISTER > Contact: > ;+sip.instance=3D"INSTANCE1" > ;reg-id=3D1 > q=3D1.0 >=20 > and then, 10 minutes later: >=20 > REGISTER > Contact: > ;+sip.instance=3D"INSTANCE1" > ;reg-id=3D2 > q=3D0.5 >=20 > Now, we have two flows for the same instance. Flow 2 is the=20 > most recently registered flow for that instance, and per=20 > sip-outbound would be selected. HOWEVER, it has a lower=20 > q-value than flow 1. So, which precedence rule wins? Does the=20 > proxy pick the flow that is most recently registered, or that=20 > has the highest q-value? >=20 > I would argue that the q-value based selection is ONLY=20 > applicable for choosing between different instances, and that=20 > q-value is basically irrelevant for choosing between flows to=20 > the same instance. The spec should probably make this clearer. >=20 >=20 > Thanks, > Jonathan R. >=20 >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 13 12:06:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqBNF-000661-1b; Tue, 13 Jun 2006 12:04:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqBNE-00065r-Bs for sip@ietf.org; Tue, 13 Jun 2006 12:04:12 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqBND-0002OO-1d for sip@ietf.org; Tue, 13 Jun 2006 12:04:12 -0400 Received: from [192.168.2.103] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5DG5aIb025354 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 13 Jun 2006 11:05:38 -0500 In-Reply-To: <448E6FF5.7080608@telecomitalia.it> References: <013101c68dab$f7e1eb20$31713b51@BEMBUSTER> <63069486-864A-4FF7-89B1-3CB7586F8687@softarmor.com> <448E6FF5.7080608@telecomitalia.it> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <94B6B04F-27C9-420A-BCB8-33015EEA9A3A@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Supported: in ACK Date: Tue, 13 Jun 2006 11:04:09 -0500 To: Alberto Cuda X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Sip IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 13, 2006, at 2:57 AM, Alberto Cuda wrote: > > Dean Willis wrote: > > > > >> 2) Can/should you include (Proxy-)Require in ACK > > > > > > I don't think you can, since a proxy cannot reject an ACK that has a > > Proxy-Require: that is not supported by the proxy. > > I think it should, otherwise we are causing problems to stateless > proxies: > if they reject an INVITE request containing a Proxy-Require they do > not > understand, they should drop the ACK request as well, or they will try > to forward it. That actually sounds quite reasonable, and I think you've changed my mind. -- 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 Jun 13 12:28:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqBif-0000Mk-5h; Tue, 13 Jun 2006 12:26:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqBid-0000Mf-Ax for sip@ietf.org; Tue, 13 Jun 2006 12:26:19 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqBib-00031X-W2 for sip@ietf.org; Tue, 13 Jun 2006 12:26:19 -0400 Received: from [192.168.2.103] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5DGRhB5025386 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 13 Jun 2006 11:27:44 -0500 Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Tue, 13 Jun 2006 11:26:16 -0500 To: Sip IETF X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Keith Drage Subject: [Sip] RFC 4485 Review requested for draft-ietf-sip-answermode X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Despite pleading from the chairs to pay attention to the "Guidelines to the Authors of SIP Extensions", RFC 4485, we haven't really internalized this into our processes yet. I believe that every draft we're sending up to the IESG needs to be at list checklist-reviewed against RFC 4485. We've completed WGLC on draft-ietf-sip-answermode-00.txt and found it to be OK, under our usual procedures. But we haven't made any special effort to verify it against RFC 4485. I think it would be educational to see how well this draft matches up to RFC 4485 so that we can all learn better how to apply the guidelines. It's a short draft, and RFC 4485 is actually a fairly short RFC. It should take maybe a half-hour or so to do this sort of review. So I'd like to ask the list for two or more volunteers to review answermode from an RFC 485 perspective and post their results back to this list. And if he can find the time, I'd really like Jonathan to be one of the reviewers, since he edited RFC 4485. Of course, we're also in the pre-IETF submission deadline crunch, so I can understand that certain individuals might be under-resourced at this time. So, some of you folks who are keen on review please step forward, tell us you're willing to tackle this daunting task, and give us an idea of when you might be finished. And if you happen to develop a checklist that might be useful for other reviewers or authors to use, that would be really handy, so please post that too and I'll try and consolidate these checklists and put them on the web as a tool for future use. Thanks, -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 13 13:04:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqCI3-0000PQ-RQ; Tue, 13 Jun 2006 13:02:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqCI2-0000Oj-ML for sip@ietf.org; Tue, 13 Jun 2006 13:02:54 -0400 Received: from maill.telecomitalia.it ([217.169.121.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqCI0-0006Ag-CN for sip@ietf.org; Tue, 13 Jun 2006 13:02:54 -0400 thread-index: AcaPCzRCUObVNX3jTnGAKrp5gaoYgw== Received: from ptpxch008rm001.idc.cww.telecomitalia.it ([156.54.205.170]) by maill.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Jun 2006 19:02:51 +0200 Received: from ptpxch005rm001.idc.cww.telecomitalia.it ([156.54.205.167]) by ptpxch008rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Jun 2006 19:02:50 +0200 Received: from [163.162.113.134] ([163.162.113.134]) by ptpxch005rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Jun 2006 19:02:50 +0200 Message-ID: <448EEF82.8040905@telecomitalia.it> Date: Tue, 13 Jun 2006 19:01:54 +0200 From: "Alberto Cuda" User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Dean Willis" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 Content-Class: urn:content-classes:message Priority: normal Importance: normal Subject: Re: [Sip] Supported: in ACK References: <013101c68dab$f7e1eb20$31713b51@BEMBUSTER> <63069486-864A-4FF7-89B1-3CB7586F8687@softarmor.com> <448E6FF5.7080608@telecomitalia.it> <94B6B04F-27C9-420A-BCB8-33015EEA9A3A@softarmor.com> In-Reply-To: <94B6B04F-27C9-420A-BCB8-33015EEA9A3A@softarmor.com> X-OriginalArrivalTime: 13 Jun 2006 17:02:50.0516 (UTC) FILETIME=[33EC1540:01C68F0B] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: Sip IETF X-BeenThere: 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="===============1225343747==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1225343747== Content-Type: multipart/alternative; boundary="----=_NextPart_000_24678_01C68F1B.F7CB69B0" Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_24678_01C68F1B.F7CB69B0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dean Willis wrote: > > On Jun 13, 2006, at 2:57 AM, Alberto Cuda wrote: > >> >> I think it should, otherwise we are causing problems to stateless =20 >> proxies: >> if they reject an INVITE request containing a Proxy-Require they do = not >> understand, they should drop the ACK request as well, or they will = try >> to forward it. > > > That actually sounds quite reasonable, and I think you've changed my =20 > mind. In the meantime I've changed mine :-) Actually stateless proxies should be able to detect their own ACKs by some other means, like an hash to put in the To-Tag: there are other cases (e.g. 483) where they can't simply tell if the original INVITE failed and why. Unfortunately I could not find any place in RFC3261 suggesting how stateless proxies can filter their own ACKs, so I wonder how current implementation deal with it... BTW ACKs to non-2xx responses can't have a Proxy-Require header: once removed this use case, IMHO the safe bet is to forbid Proxy-Require from "2xx" ACKs too, since the only effect they could have is to cause retransmissions. Cheers. Alberto. -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please contact us by replying to = webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- ------=_NextPart_000_24678_01C68F1B.F7CB69B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Dean Willis = wrote:

>
> On Jun 13, 2006, at 2:57 AM, Alberto Cuda = wrote:
>
>>
>> I think it should, otherwise we are causing = problems to stateless
>> proxies:
>> if they reject an INVITE = request containing a Proxy-Require they do not
>> understand, they = should drop the ACK request as well, or they will try
>> to forward = it.
>
>
> That actually sounds quite reasonable, and I think = you've changed my
> mind.

In the meantime I've changed mine = :-)

Actually stateless proxies should be able to detect their own = ACKs
by some other means, like an hash to put in the To-Tag: there = are
other cases (e.g. 483) where they can't simply tell if the = original
INVITE failed and why. Unfortunately I could not find any = place
in RFC3261 suggesting how stateless proxies can filter their = own
ACKs, so I wonder how current implementation deal with = it...

BTW ACKs to non-2xx responses can't have a Proxy-Require = header:
once removed this use case, IMHO the safe bet is to = forbid
Proxy-Require from "2xx" ACKs too, since the only effect = they
could have is to cause retransmissions.

Cheers.
= Alberto.



--------------------------------------------------------------------=
CONFIDENTIALITY=20 NOTICE
This message and its attachments are addressed solely to the=20 persons
above and may contain confidential information. If you have=20 received
the message in error, be informed that any use of the = content=20 hereof
is prohibited. Please return it immediately to the sender and=20 delete
the message. Should you have any questions, please contact us=20 by
replying to webmaster@telecomitalia.it.
        = Thank=20 you
           =             &= nbsp;           &n= bsp;   =20 www.telecomitalia.it
--------------------------------------------------------------------=
------=_NextPart_000_24678_01C68F1B.F7CB69B0-- --===============1225343747== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1225343747==-- From sip-bounces@ietf.org Tue Jun 13 14:14:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqDNc-0003Ni-Ji; Tue, 13 Jun 2006 14:12:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqDNb-0003GW-2W for sip@ietf.org; Tue, 13 Jun 2006 14:12:43 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqDNa-0006XY-9l for sip@ietf.org; Tue, 13 Jun 2006 14:12:43 -0400 Received: (qmail 29274 invoked by uid 0); 13 Jun 2006 18:12:35 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 13 Jun 2006 18:12:35 -0000 Message-ID: <001801c68f14$f35f6130$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Alberto Cuda" , "Dean Willis" References: <013101c68dab$f7e1eb20$31713b51@BEMBUSTER> <63069486-864A-4FF7-89B1-3CB7586F8687@softarmor.com> <448E6FF5.7080608@telecomitalia.it> <94B6B04F-27C9-420A-BCB8-33015EEA9A3A@softarmor.com> <448EEF82.8040905@telecomitalia.it> Subject: Re: [Sip] Supported: in ACK Date: Tue, 13 Jun 2006 20:12:36 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Cc: Sip IETF X-BeenThere: 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="===============0342306298==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0342306298== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C68F25.B6B3B3B0" This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C68F25.B6B3B3B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I was just about to write the very same comment... The problem is bigger than only 420 (Bad Extension), it occurs for all = 3xx-6xx responses generated by a stateless proxy. Adding Proxy-Require to the ACK means that it must be remembered or = derived from the 420 response. The former is cumbersome for a stateless = proxy, and the latter is inelegant to say the least Instead, I would propose the following: 1) Standardize a prefix (like Via magic cookie) to be used in the to-tag = by stateless proxies when generating a non-2xx final response. Something = like "error-" 2) When generating an ACK to non-2xx, require elements to insert a = 'Max-Forwards: 0' header (2) makes sense because an ACK to non-2xx should never be forwarded When both these rules are implemented, there is no need for = Proxy-Require in ACK to non-2xx. However, as to Proxy-Require in ACK to 2xx: it is needed in case a = Privacy service is used with "header" Privacy. Regards, jeroen ----- Original Message -----=20 From: Alberto Cuda=20 To: Dean Willis=20 Cc: Jeroen van Bemmel ; Sip IETF=20 Sent: Tuesday, June 13, 2006 7:01 PM Subject: Re: [Sip] Supported: in ACK Dean Willis wrote: > > On Jun 13, 2006, at 2:57 AM, Alberto Cuda wrote: > >> >> I think it should, otherwise we are causing problems to stateless=20 >> proxies: >> if they reject an INVITE request containing a Proxy-Require they do = not >> understand, they should drop the ACK request as well, or they will = try >> to forward it. > > > That actually sounds quite reasonable, and I think you've changed my = > mind. In the meantime I've changed mine :-) Actually stateless proxies should be able to detect their own ACKs by some other means, like an hash to put in the To-Tag: there are other cases (e.g. 483) where they can't simply tell if the original INVITE failed and why. Unfortunately I could not find any place in RFC3261 suggesting how stateless proxies can filter their own ACKs, so I wonder how current implementation deal with it... BTW ACKs to non-2xx responses can't have a Proxy-Require header: once removed this use case, IMHO the safe bet is to forbid Proxy-Require from "2xx" ACKs too, since the only effect they could have is to cause retransmissions. Cheers. Alberto. -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- ------=_NextPart_000_0015_01C68F25.B6B3B3B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I was just about to write the very same = comment...
 
The problem is bigger than only 420 = (Bad=20 Extension), it occurs for all 3xx-6xx responses generated by a stateless = proxy.
 
Adding Proxy-Require to the ACK means = that it must=20 be remembered or derived from the 420 response. The former is cumbersome = for a=20 stateless proxy, and the latter is inelegant to say the = least
 
Instead, I would propose the=20 following:
 
1) Standardize a prefix (like Via magic = cookie) to=20 be used in the to-tag by stateless proxies when generating a non-2xx = final=20 response. Something like "error-"
2) When generating an ACK to non-2xx, = require=20 elements to insert a 'Max-Forwards: 0' header
 
(2) makes sense because an ACK to = non-2xx should=20 never be forwarded
 
When both these rules are implemented, = there is no=20 need for Proxy-Require in ACK to non-2xx.
However, as to=20 Proxy-Require in ACK to 2xx: it is needed in case a Privacy service is = used with=20 "header" Privacy.
 
Regards,
 
jeroen
 
----- Original Message -----
From:=20 Alberto Cuda
Sent: Tuesday, June 13, 2006 = 7:01=20 PM
Subject: Re: [Sip] Supported: = in=20 ACK

 
Dean Willis wrote:

>
> On Jun 13, = 2006, at=20 2:57 AM, Alberto Cuda wrote:
>
>>
>> I think = it=20 should, otherwise we are causing problems to stateless
>>=20 proxies:
>> if they reject an INVITE request containing a=20 Proxy-Require they do not
>> understand, they should drop the = ACK=20 request as well, or they will try
>> to forward=20 it.
>
>
> That actually sounds quite reasonable, and = I think=20 you've changed my
> mind.

In the meantime I've changed = mine=20 :-)

Actually stateless proxies should be able to detect their = own=20 ACKs
by some other means, like an hash to put in the To-Tag: there=20 are
other cases (e.g. 483) where they can't simply tell if the=20 original
INVITE failed and why. Unfortunately I could not find any=20 place
in RFC3261 suggesting how stateless proxies can filter their=20 own
ACKs, so I wonder how current implementation deal with = it...

BTW=20 ACKs to non-2xx responses can't have a Proxy-Require header:
once = removed=20 this use case, IMHO the safe bet is to forbid
Proxy-Require from = "2xx" ACKs=20 too, since the only effect they
could have is to cause=20 retransmissions.

Cheers.
Alberto.



--------------------------------------------------------------------=
CONFIDENTIALITY=20 NOTICE
This message and its attachments are addressed solely to the = persons
above and may contain confidential information. If you have = received
the message in error, be informed that any use of the = content=20 hereof
is prohibited. Please return it immediately to the sender = and=20 delete
the message. Should you have any questions, please contact = us=20 by
replying to webmaster@telecomitalia.it.
        = Thank=20 = you
           =             &= nbsp;           &n= bsp;   =20 www.telecomitalia.it
--------------------------------------------------------------------=
------=_NextPart_000_0015_01C68F25.B6B3B3B0-- --===============0342306298== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0342306298==-- From sip-bounces@ietf.org Tue Jun 13 14:56:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqE22-00049p-3S; Tue, 13 Jun 2006 14:54:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqE20-00049k-Bu for sip@ietf.org; Tue, 13 Jun 2006 14:54:28 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqE1z-00036C-0L for sip@ietf.org; Tue, 13 Jun 2006 14:54:28 -0400 Received: by tutpro.com (Postfix, from userid 65534) id A16F313F912; Tue, 13 Jun 2006 21:54:18 +0300 (EEST) Received: from rautu (in-vitro199.gprs.dnafinland.fi [62.78.121.199]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id CA29013F910; Tue, 13 Jun 2006 21:54:06 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id D85D2F03C1; Tue, 13 Jun 2006 21:54:17 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17551.2521.823396.350526@rautu.tutpro.com> Date: Tue, 13 Jun 2006 21:54:17 +0300 From: Juha Heinanen To: Subject: RE: [Sip] outbound i-d update? In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F026C1E91@esebe103.NOE.Nokia.com> References: <17549.8798.26258.703846@rautu.tutpro.com> <8B1D53AEF7B03449A6D3771B3B7F850F026C1E91@esebe103.NOE.Nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: fluffy@cisco.com, sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Erkki.Koivusalo@nokia.com writes: > Please do not forget about the effort to get the SIP Outbound > autodiscovery defined to rely on configuring only one single URI > with which the UA is able to derive the addresses of multiple > proxies. I would hope to keep the door still open for such a > solution. i don't like a single URI alternative at all, since a single URI may result into a single host. there must be at least two URIs in outbound proxy set. > There has been some requests on the list to have it possible for > a mobile device to keep only a single flow open in order to save > the battery. I still think SRV has a way to facilitate load balancing > even if the basic SRV has always aimed at one single connection per > client. By maintaining one single flow the UA does not get as high > reliability as with multiple flows, but I think load balancing could > still be achieved. if there is only one flow open, you can forget fault tolerance, since there is only one proxy that can at any time reach the UA. -- 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 Tue Jun 13 17:21:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqGIU-0005rR-Lt; Tue, 13 Jun 2006 17:19:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqGIS-0005rM-TP for sip@ietf.org; Tue, 13 Jun 2006 17:19:36 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqGIQ-0000oJ-01 for sip@ietf.org; Tue, 13 Jun 2006 17:19:36 -0400 Received: (qmail 24749 invoked by uid 0); 13 Jun 2006 21:19:31 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 13 Jun 2006 21:19:31 -0000 Message-ID: <004201c68f2f$0e486c20$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Jeroen van Bemmel" , "Alberto Cuda" , "Dean Willis" References: <013101c68dab$f7e1eb20$31713b51@BEMBUSTER><63069486-864A-4FF7-89B1-3CB7586F8687@softarmor.com><448E6FF5.7080608@telecomitalia.it><94B6B04F-27C9-420A-BCB8-33015EEA9A3A@softarmor.com><448EEF82.8040905@telecomitalia.it> <001801c68f14$f35f6130$31713b51@BEMBUSTER> Subject: Re: [Sip] Supported: in ACK Date: Tue, 13 Jun 2006 23:19:27 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.1 (/) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 Cc: Sip IETF X-BeenThere: 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="===============1441064075==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1441064075== Content-Type: multipart/alternative; boundary="----=_NextPart_000_003F_01C68F3F.D101B720" This is a multi-part message in MIME format. ------=_NextPart_000_003F_01C68F3F.D101B720 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On second thought,=20 1) The tag must be unique to the responding proxy. One option might be = to add the value of Max-Forwards after the prefix, i.e. "error-68" if = Max-Forwards is 68. A stateless proxy must then drop an ACK iff to-tag starts with = "error-" and max-forwards equals the number in the tag This has the benefit that it may also aid in debugging. Another = alternative would be to simply recommend each proxy to decide for itself = what unique tag it uses for non-2xx ACK filtering 2) Max-Forwards:0 will not work when there are other stateless proxies = between the UAC and the responding proxy, so not a good idea Jeroen ----- Original Message -----=20 From: Jeroen van Bemmel=20 To: Alberto Cuda ; Dean Willis=20 Cc: Sip IETF=20 Sent: Tuesday, June 13, 2006 8:12 PM Subject: Re: [Sip] Supported: in ACK I was just about to write the very same comment... The problem is bigger than only 420 (Bad Extension), it occurs for all = 3xx-6xx responses generated by a stateless proxy. Adding Proxy-Require to the ACK means that it must be remembered or = derived from the 420 response. The former is cumbersome for a stateless = proxy, and the latter is inelegant to say the least Instead, I would propose the following: 1) Standardize a prefix (like Via magic cookie) to be used in the = to-tag by stateless proxies when generating a non-2xx final response. = Something like "error-" 2) When generating an ACK to non-2xx, require elements to insert a = 'Max-Forwards: 0' header (2) makes sense because an ACK to non-2xx should never be forwarded When both these rules are implemented, there is no need for = Proxy-Require in ACK to non-2xx. However, as to Proxy-Require in ACK to 2xx: it is needed in case a = Privacy service is used with "header" Privacy. Regards, jeroen ----- Original Message -----=20 From: Alberto Cuda=20 To: Dean Willis=20 Cc: Jeroen van Bemmel ; Sip IETF=20 Sent: Tuesday, June 13, 2006 7:01 PM Subject: Re: [Sip] Supported: in ACK Dean Willis wrote: > > On Jun 13, 2006, at 2:57 AM, Alberto Cuda wrote: > >> >> I think it should, otherwise we are causing problems to stateless = >> proxies: >> if they reject an INVITE request containing a Proxy-Require they = do not >> understand, they should drop the ACK request as well, or they = will try >> to forward it. > > > That actually sounds quite reasonable, and I think you've changed = my=20 > mind. In the meantime I've changed mine :-) Actually stateless proxies should be able to detect their own ACKs by some other means, like an hash to put in the To-Tag: there are other cases (e.g. 483) where they can't simply tell if the original INVITE failed and why. Unfortunately I could not find any place in RFC3261 suggesting how stateless proxies can filter their own ACKs, so I wonder how current implementation deal with it... BTW ACKs to non-2xx responses can't have a Proxy-Require header: once removed this use case, IMHO the safe bet is to forbid Proxy-Require from "2xx" ACKs too, since the only effect they could have is to cause retransmissions. Cheers. Alberto. -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- -------------------------------------------------------------------------= ----- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------=_NextPart_000_003F_01C68F3F.D101B720 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
On second thought,
 
1) The tag must be unique to the = responding proxy.=20 One option might be to add the value of Max-Forwards after the prefix, = i.e.=20 "error-68" if Max-Forwards is 68.
  A stateless proxy must then drop = an ACK iff=20 to-tag starts with "error-" and max-forwards equals the number in the=20 tag
 
  This has the benefit that it may = also aid in=20 debugging. Another alternative would be to simply recommend each proxy = to decide=20 for itself what unique tag it uses for non-2xx ACK = filtering
 
2) Max-Forwards:0 will not work when = there are=20 other stateless proxies between the UAC and the responding proxy, = so not a=20 good idea
 
Jeroen
----- Original Message -----
From:=20 Jeroen = van=20 Bemmel
To: Alberto Cuda ; Dean=20 Willis
Sent: Tuesday, June 13, 2006 = 8:12=20 PM
Subject: Re: [Sip] Supported: = in=20 ACK

I was just about to write the very = same=20 comment...
 
The problem is bigger than only 420 = (Bad=20 Extension), it occurs for all 3xx-6xx responses generated by a = stateless=20 proxy.
 
Adding Proxy-Require to the ACK means = that it=20 must be remembered or derived from the 420 response. The former is = cumbersome=20 for a stateless proxy, and the latter is inelegant to say the=20 least
 
Instead, I would propose the=20 following:
 
1) Standardize a prefix (like Via = magic cookie)=20 to be used in the to-tag by stateless proxies when generating a = non-2xx final=20 response. Something like "error-"
2) When generating an ACK to non-2xx, = require=20 elements to insert a 'Max-Forwards: 0' header
 
(2) makes sense because an ACK to = non-2xx should=20 never be forwarded
 
When both these rules are = implemented, there is=20 no need for Proxy-Require in ACK to non-2xx.
However, as to=20 Proxy-Require in ACK to 2xx: it is needed in case a Privacy service is = used=20 with "header" Privacy.
 
Regards,
 
jeroen
 
----- Original Message -----
From:=20 Alberto Cuda =
Cc: Jeroen van Bemmel ; Sip IETF =
Sent: Tuesday, June 13, 2006 = 7:01=20 PM
Subject: Re: [Sip] Supported: = in=20 ACK

 
Dean Willis wrote:

>
> On Jun 13, = 2006, at=20 2:57 AM, Alberto Cuda wrote:
>
>>
>> I think = it=20 should, otherwise we are causing problems to stateless
>>=20 proxies:
>> if they reject an INVITE request containing a=20 Proxy-Require they do not
>> understand, they should drop = the ACK=20 request as well, or they will try
>> to forward=20 it.
>
>
> That actually sounds quite reasonable, = and I=20 think you've changed my
> mind.

In the meantime I've = changed=20 mine :-)

Actually stateless proxies should be able to detect = their=20 own ACKs
by some other means, like an hash to put in the To-Tag: = there=20 are
other cases (e.g. 483) where they can't simply tell if the=20 original
INVITE failed and why. Unfortunately I could not find = any=20 place
in RFC3261 suggesting how stateless proxies can filter = their=20 own
ACKs, so I wonder how current implementation deal with=20 it...

BTW ACKs to non-2xx responses can't have a = Proxy-Require=20 header:
once removed this use case, IMHO the safe bet is to=20 forbid
Proxy-Require from "2xx" ACKs too, since the only effect=20 they
could have is to cause=20 retransmissions.

Cheers.
Alberto.



--------------------------------------------------------------------=
CONFIDENTIALITY=20 NOTICE
This message and its attachments are addressed solely to = the=20 persons
above and may contain confidential information. If you = have=20 received
the message in error, be informed that any use of the = content=20 hereof
is prohibited. Please return it immediately to the sender = and=20 delete
the message. Should you have any questions, please contact = us=20 by
replying to webmaster@telecomitalia.it.
        = Thank=20 = you
           =             &= nbsp;           &n= bsp;   =20 www.telecomitalia.it
--------------------------------------------------------------------=

_______________________________________________
Sip mailing=20 list  https://www1.ietf.org/mailman/listinfo/sip
This list is = for NEW=20 development of the core SIP Protocol
Use = sip-implementors@cs.columbia.edu=20 for questions on current sip
Use sipping@ietf.org for new = developments on=20 the application of sip ------=_NextPart_000_003F_01C68F3F.D101B720-- --===============1441064075== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1441064075==-- From sip-bounces@ietf.org Wed Jun 14 02:35:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqOx2-00071A-Pl; Wed, 14 Jun 2006 02:34:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqOx0-000711-Vs for sip@ietf.org; Wed, 14 Jun 2006 02:34:02 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqOtA-0001nd-UH for sip@ietf.org; Wed, 14 Jun 2006 02:30:07 -0400 Received: (qmail 3730 invoked by uid 0); 14 Jun 2006 06:30:02 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 14 Jun 2006 06:30:02 -0000 Message-ID: <001a01c68f7b$f6547f80$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: Date: Wed, 14 Jun 2006 08:29:59 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Subject: [Sip] Max-Forwards in ACK for non-2xx X-BeenThere: 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="===============0507486646==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0507486646== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01C68F8C.B976C580" This is a multi-part message in MIME format. ------=_NextPart_000_0017_01C68F8C.B976C580 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RFC3261 section 17.1.1.3 describes how an ACK for a non-2xx response = should be constructed. Although not explicitly mentioned in the text = there, the example shows that a Max-Forwards header should be included = (default: 70) as per 8.1.1 Consider a looping INVITE forwarded statefully. When Max-Forwards = reaches 0, a Too Many hops response is generated and sent back upstream. = If this response is sent statelessly, the ACK from the previous element = (which will have a fresh Max-Forwards: 70) will loop for another 70 = hops, in addition to the chain of 1-hop ACKs exchanged between each = stateful element For this scenario, it again seems necessary that a stateless proxy stops = non-2xx ACKs for responses it generated. Moreover, perhaps section = 17.1.1.3 should be updated to say that the Max-Forwards value should be = the same as was used for the INVITE that was forwarded. The ACK should = not propagate further than the INVITE Regards, Jeroen ------=_NextPart_000_0017_01C68F8C.B976C580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
RFC3261 section 17.1.1.3 describes how = an ACK for a=20 non-2xx response should be constructed. Although not explicitly = mentioned in the=20 text there, the example shows that a Max-Forwards header should be = included=20 (default: 70) as per 8.1.1
 
Consider a looping INVITE forwarded = statefully.=20 When Max-Forwards reaches 0, a Too Many hops response is generated and = sent back=20 upstream. If this response is sent statelessly, the ACK from the = previous=20 element (which will have a fresh Max-Forwards: 70) will loop for another = 70=20 hops, in addition to the chain of 1-hop ACKs exchanged between each = stateful=20 element
 
For this scenario, it again seems = necessary that a=20 stateless proxy stops non-2xx ACKs for responses it generated. Moreover, = perhaps=20 section 17.1.1.3 should be updated to say that the Max-Forwards value = should be=20 the same as was used for the INVITE that was forwarded. The ACK should = not=20 propagate further than the INVITE
 
 
Regards,
 
Jeroen
------=_NextPart_000_0017_01C68F8C.B976C580-- --===============0507486646== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0507486646==-- From sip-bounces@ietf.org Wed Jun 14 03:21:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqPfI-0002Im-Lq; Wed, 14 Jun 2006 03:19:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqPfH-0002Ih-9g for sip@ietf.org; Wed, 14 Jun 2006 03:19:47 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqPfF-0005tp-V9 for sip@ietf.org; Wed, 14 Jun 2006 03:19:47 -0400 Received: by tutpro.com (Postfix, from userid 65534) id C30AB13F912; Wed, 14 Jun 2006 10:19:39 +0300 (EEST) Received: from rautu (anneal59.gprs.dnafinland.fi [62.78.105.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id EA5C113F910 for ; Wed, 14 Jun 2006 10:19:33 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 7D41AF03C1; Wed, 14 Jun 2006 10:19:47 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17551.47251.460116.204051@rautu.tutpro.com> Date: Wed, 14 Jun 2006 10:19:47 +0300 From: Juha Heinanen To: sip@ietf.org Subject: RE: [Sip] outbound i-d update? X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org i made a mistake yesterday when i wrote: i don't like a single URI alternative at all, since a single URI may result into a single host. there must be at least two URIs in outbound proxy set. it is OK for me to have only one URI in outbound proxy set, but if that is the case, then outbound-id must say that this single URI MUST resolve to at least two proxy hosts and that each UA MUST keep a flow open to at least two proxy hosts. -- 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 Jun 14 03:25:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqPjV-0004Pj-37; Wed, 14 Jun 2006 03:24:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqPjU-0004Pc-3n for sip@ietf.org; Wed, 14 Jun 2006 03:24:08 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqPjR-0006JA-CP for sip@ietf.org; Wed, 14 Jun 2006 03:24:08 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A33255E0001; Wed, 14 Jun 2006 09:24:04 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 09:24:04 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 09:24:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] outbound i-d update? Date: Wed, 14 Jun 2006 09:24:03 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F10A6@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] outbound i-d update? Thread-Index: AcaPGtcH1IjklqXlR7WUXKnBU9yQ+AAZ/8pQ From: "Christer Holmberg \(JO/LMF\)" To: "Juha Heinanen" , X-OriginalArrivalTime: 14 Jun 2006 07:24:04.0329 (UTC) FILETIME=[83EA3590:01C68F83] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: fluffy@cisco.com, sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>Please do not forget about the effort to get the SIP Outbound autodiscovery defined to rely on configuring only one=20 >>single URI with which the UA is able to derive the addresses of multiple proxies. I would hope to keep the door still=20 >>open for such a solution. > >i don't like a single URI alternative at all, since a single URI may result into a single host. there must be at least=20 >two URIs in outbound proxy set. I think that is a network/DNS configuration issue. >>There has been some requests on the list to have it possible for a mobile device to keep only a single flow open in=20 >>order to save the battery. I still think SRV has a way to facilitate load balancing even if the basic SRV has always=20 >>aimed at one single connection per client. By maintaining one single flow the UA does not get as high reliability as=20 >>with multiple flows, but I think load balancing could still be achieved. > >if there is only one flow open, you can forget fault tolerance, since there is only one proxy that can at any time reach=20 >the UA. I think that can be mentioned in the document, but I still think the operator should be able to choose. Because, there may be other ways to provide fault tolerance than using multiple IP addresses. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 14 04:17:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqQWu-0008Gl-Ha; Wed, 14 Jun 2006 04:15:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqQWt-0008Gg-Il for sip@ietf.org; Wed, 14 Jun 2006 04:15:11 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqQWs-00069f-7M for sip@ietf.org; Wed, 14 Jun 2006 04:15:11 -0400 Received: by tutpro.com (Postfix, from userid 65534) id EC88C13F912; Wed, 14 Jun 2006 11:15:05 +0300 (EEST) Received: from rautu (anneal59.gprs.dnafinland.fi [62.78.105.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id E2EC313F910; Wed, 14 Jun 2006 11:14:54 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 5DDB4F03C1; Wed, 14 Jun 2006 11:15:03 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17551.50567.283816.835349@rautu.tutpro.com> Date: Wed, 14 Jun 2006 11:15:03 +0300 From: Juha Heinanen To: "Christer Holmberg (JO/LMF)" Subject: RE: [Sip] outbound i-d update? In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F10A6@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB594017F10A6@esealmw113.eemea.ericsson.se> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: fluffy@cisco.com, sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) writes: > I think that can be mentioned in the document, but I still think the > operator should be able to choose. Because, there may be other ways to > provide fault tolerance than using multiple IP addresses. i know, since at the moment we are using those "other ways" and i can tell you that they are not fun. but you are right in that if a domain only advertises one outbound URI, which resolves to only one proxy host, then let it be that way. it is domain's call. however, the important thing is that IF domain advertises more than one outbound URI or a single URI that resolve(s) to more than one proxy host, then UA MUST keep flows open to at least two of those proxy hosts. without this above requirement, outbound-id doesn't add any real value over what we have today. -- 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 Jun 14 04:22:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqQbo-0002Tv-T5; Wed, 14 Jun 2006 04:20:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqQbn-0002Tq-Kx for sip@ietf.org; Wed, 14 Jun 2006 04:20:15 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqQbl-0006L7-TH for sip@ietf.org; Wed, 14 Jun 2006 04:20:15 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2A91E4F04B6; Wed, 14 Jun 2006 10:20:13 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 10:20:12 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 10:20:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] outbound i-d update? Date: Wed, 14 Jun 2006 10:20:10 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F10AD@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] outbound i-d update? Thread-Index: AcaPiqezXsEsaKxbRESjdP/EuMb01AAAG5Jw From: "Christer Holmberg \(JO/LMF\)" To: "Juha Heinanen" X-OriginalArrivalTime: 14 Jun 2006 08:20:12.0094 (UTC) FILETIME=[5B425DE0:01C68F8B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: fluffy@cisco.com, sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, If the client receives multiple URIs, and/or IP addresses, the "default = behavior" could be to open flows to at least of those. But, I still think that the client should still be allowed to open a = flow with only a single IP address, because the fact that it receives = multiple URIs/addresses may have nothing to do with fault tolerance. = But, in this case the client must of course have knowledge about that. Regards, Christer -----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com]=20 Sent: 14. kes=E4kuuta 2006 11:15 To: Christer Holmberg (JO/LMF) Cc: Erkki.Koivusalo@nokia.com; fluffy@cisco.com; sip@ietf.org Subject: RE: [Sip] outbound i-d update? Christer Holmberg (JO/LMF) writes: > I think that can be mentioned in the document, but I still think the = > operator should be able to choose. Because, there may be other ways to = > provide fault tolerance than using multiple IP addresses. i know, since at the moment we are using those "other ways" and i can = tell you that they are not fun. but you are right in that if a domain = only advertises one outbound URI, which resolves to only one proxy host, = then let it be that way. it is domain's call. however, the important thing is that IF domain advertises more than one = outbound URI or a single URI that resolve(s) to more than one proxy = host, then UA MUST keep flows open to at least two of those proxy hosts. without this above requirement, outbound-id doesn't add any real value = over what we have today. -- 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 Jun 14 04:23:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqQcm-00038b-Vr; Wed, 14 Jun 2006 04:21:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqQcl-00038V-7V for sip@ietf.org; Wed, 14 Jun 2006 04:21:15 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqQcj-0006Nm-Hh for sip@ietf.org; Wed, 14 Jun 2006 04:21:15 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CECEB4F0001; Wed, 14 Jun 2006 10:21:12 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 10:20:59 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 10:20:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] outbound i-d update? Date: Wed, 14 Jun 2006 10:20:57 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F10AE@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] outbound i-d update? Thread-Index: AcaPiqezXsEsaKxbRESjdP/EuMb01AAAG5JwAAAWd5A= From: "Christer Holmberg \(JO/LMF\)" To: "Christer Holmberg \(JO/LMF\)" , "Juha Heinanen" X-OriginalArrivalTime: 14 Jun 2006 08:20:58.0265 (UTC) FILETIME=[76C78090:01C68F8B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: fluffy@cisco.com, sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org To at least TWO of those, that is...=20 -----Original Message----- From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] = Sent: 14. kes=E4kuuta 2006 11:20 To: Juha Heinanen Cc: fluffy@cisco.com; sip@ietf.org Subject: RE: [Sip] outbound i-d update? Hi, If the client receives multiple URIs, and/or IP addresses, the "default = behavior" could be to open flows to at least of those. But, I still think that the client should still be allowed to open a = flow with only a single IP address, because the fact that it receives = multiple URIs/addresses may have nothing to do with fault tolerance. = But, in this case the client must of course have knowledge about that. Regards, Christer -----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com] Sent: 14. kes=E4kuuta 2006 11:15 To: Christer Holmberg (JO/LMF) Cc: Erkki.Koivusalo@nokia.com; fluffy@cisco.com; sip@ietf.org Subject: RE: [Sip] outbound i-d update? Christer Holmberg (JO/LMF) writes: > I think that can be mentioned in the document, but I still think the = > operator should be able to choose. Because, there may be other ways to = > provide fault tolerance than using multiple IP addresses. i know, since at the moment we are using those "other ways" and i can = tell you that they are not fun. but you are right in that if a domain = only advertises one outbound URI, which resolves to only one proxy host, = then let it be that way. it is domain's call. however, the important thing is that IF domain advertises more than one = outbound URI or a single URI that resolve(s) to more than one proxy = host, then UA MUST keep flows open to at least two of those proxy hosts. without this above requirement, outbound-id doesn't add any real value = over what we have today. -- 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 Jun 14 04:25:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqQfK-00069R-QZ; Wed, 14 Jun 2006 04:23:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqQfJ-0005uh-0Z for sip@ietf.org; Wed, 14 Jun 2006 04:23:53 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqQfF-0006Vc-Kk for sip@ietf.org; Wed, 14 Jun 2006 04:23:52 -0400 Received: by tutpro.com (Postfix, from userid 65534) id B9F7213F912; Wed, 14 Jun 2006 11:23:45 +0300 (EEST) Received: from rautu (anneal59.gprs.dnafinland.fi [62.78.105.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 4187413F910; Wed, 14 Jun 2006 11:23:35 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 3CBD6F03C1; Wed, 14 Jun 2006 11:23:48 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17551.51092.195977.289551@rautu.tutpro.com> Date: Wed, 14 Jun 2006 11:23:48 +0300 From: Juha Heinanen To: "Christer Holmberg (JO/LMF)" Subject: RE: [Sip] outbound i-d update? In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F10AD@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB594017F10AD@esealmw113.eemea.ericsson.se> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: fluffy@cisco.com, sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) writes: > But, I still think that the client should still be allowed to open a > flow with only a single IP address, because the fact that it receives > multiple URIs/addresses may have nothing to do with fault > tolerance. But, in this case the client must of course have knowledge > about that. and how would that knowledge be auto-configured to the client? -- 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 Jun 14 04:37:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqQrC-0002X9-6G; Wed, 14 Jun 2006 04:36:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqQrA-0002X4-MC for sip@ietf.org; Wed, 14 Jun 2006 04:36:08 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqQr9-0006yQ-C0 for sip@ietf.org; Wed, 14 Jun 2006 04:36:08 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C38CE4F045A; Wed, 14 Jun 2006 10:36:06 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 10:36:06 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 10:36:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] outbound i-d update? Date: Wed, 14 Jun 2006 10:36:05 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F10AF@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] outbound i-d update? Thread-Index: AcaPi9wCPVnlSdtCR9WEeSCanVj86wAAV7pA From: "Christer Holmberg \(JO/LMF\)" To: "Juha Heinanen" X-OriginalArrivalTime: 14 Jun 2006 08:36:05.0935 (UTC) FILETIME=[93CAF3F0:01C68F8D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: fluffy@cisco.com, sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, For example, the knowledge could come to the client from the network in = a REGISTER response, i.e. the network tells the client how many flows it = wants to client to establish. Or something like that... I haven't thought much about it, but maybe = it's one possible alternative. Regards, Christer =20 -----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com]=20 Sent: 14. kes=E4kuuta 2006 11:24 To: Christer Holmberg (JO/LMF) Cc: Erkki.Koivusalo@nokia.com; fluffy@cisco.com; sip@ietf.org Subject: RE: [Sip] outbound i-d update? Christer Holmberg (JO/LMF) writes: > But, I still think that the client should still be allowed to open a = > flow with only a single IP address, because the fact that it receives = > multiple URIs/addresses may have nothing to do with fault > = tolerance. But, in this case the client must of course have knowledge > = about that. and how would that knowledge be auto-configured to the client? -- 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 Jun 14 05:38:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqRnR-0007Sl-Ne; Wed, 14 Jun 2006 05:36:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqRnP-0007Sg-Ow for sip@ietf.org; Wed, 14 Jun 2006 05:36:19 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqRnO-0000pI-Fv for sip@ietf.org; Wed, 14 Jun 2006 05:36:19 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k5E9aHkN013065 for ; Wed, 14 Jun 2006 04:36:17 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 14 Jun 2006 10:36:17 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0132CBB04@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org Date: Wed, 14 Jun 2006 10:36:15 +0100 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 Subject: [Sip] Additional uses of 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: , Errors-To: sip-bounces@ietf.org Within the SIP protocol we have done a lot of tidying up as to how extensions are made to the SIP protocol. In particular RFC 3968 and RFC 3969 set up various registries for the session initiation protocol, and RFC 3427 defines rules for definition of headers and event packages. Both within IETF, and in discussions outside IETF, we still see proposals to use the INFO method (RFC 2976) for various purposes, and we have no really clear statements on whether INFO method can be applied to new applications, or not, and if so, who should document those new applications. This is probably complicated by the fact that the INFO RFC http://www.ietf.org/internet-drafts/draft-rosenberg-sip-hitchhikers-guide-00.txt currently lists RFC 2976 under the PSTN interworking specifications, and that is currently the only defined IETF usage, and also indicates under the general infrastructure section: RFC 2976: The INFO Method (S) RFC 2976 [39] was defined as an extension to RFC 2543. It defines a method, INFO, used to transport mid-dialog information that has no impact on SIP itself. Its driving application was the transport of PSTN related information when using SIP between a pair of gateways. Though originally conceived for broader use, it only found standardized usage with SIP-T [33]. It has been used to support numerous proprietary and non-interoperable extensions due to its poorly defined scope. My question is whether it is appropriate to provide some means of clarifying other usages of the INFO method, and who should document them. Should that occur in: i) An update or revision to RFC 2976 ii) An update to RFC 3427 iii) Anywhere else regards Keith Keith Drage drage@lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 14 06:14:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqSMs-00082F-I5; Wed, 14 Jun 2006 06:12:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqSMq-0007vK-K8 for sip@ietf.org; Wed, 14 Jun 2006 06:12:56 -0400 Received: from mail.kodiaknetworks.com ([12.186.66.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqSMq-0002is-2R for sip@ietf.org; Wed, 14 Jun 2006 06:12:56 -0400 X-MessageTextProcessor: DisclaimIt (2.50.252) [Kodiak Networks] X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 Importance: normal Priority: normal Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Additional uses of INFO Date: Wed, 14 Jun 2006 03:12:52 -0700 Message-ID: <7C85DD08A7ABAF4AB2D3FBE46B034F2589514C@niners.inovate.inovate.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Additional uses of INFO thread-index: AcaPliZt+K5NYSM+SqO96TkdMFR4aAAA2bar From: "Nataraju Basavaraju" To: "Drage, Keith \(Keith\)" , X-Spam-Score: 0.5 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1977140160==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1977140160== Content-Transfer-Encoding: 7bit Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68F9B.18F26334" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68F9B.18F26334 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Keith/Jonathan,=20 This new draft lists out the brief details about the CURRENT = standards/drafts related to SIP.=20 Even now itself so many bugs raised against many RFCs but they have not = been fixed in the standard documents.=20 If we dont update the RFCs in ietf repository, We might end up in = writing one more draft to list out additional drafts/RFCs added once = this particular draft becomes an RFC.=20 Hence I feel shall we need to define an interval by which this and other = existing RFCs/drafts would fix the open bugs related respective RFCs.=20 In this way we can help to avoid counfusion for the new entrant to SIP = world...=20 Regards, Nataraju A.B. -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com] Sent: Wed 6/14/2006 2:36 AM To: sip@ietf.org Subject: [Sip] Additional uses of INFO =20 Within the SIP protocol we have done a lot of tidying up as to how = extensions are made to the SIP protocol. In particular RFC 3968 and RFC 3969 set up various registries for the = session initiation protocol, and RFC 3427 defines rules for definition = of headers and event packages. Both within IETF, and in discussions outside IETF, we still see = proposals to use the INFO method (RFC 2976) for various purposes, and we = have no really clear statements on whether INFO method can be applied to = new applications, or not, and if so, who should document those new = applications. This is probably complicated by the fact that the INFO RFC http://www.ietf.org/internet-drafts/draft-rosenberg-sip-hitchhikers-guide= -00.txt currently lists RFC 2976 under the PSTN interworking = specifications, and that is currently the only defined IETF usage, and = also indicates under the general infrastructure section: RFC 2976: The INFO Method (S) RFC 2976 [39] was defined as an extension to RFC 2543. It defines a method, INFO, used to transport mid-dialog information that has no impact on SIP itself. Its driving application was the transport of PSTN related information when using SIP between a pair of gateways. Though originally conceived for broader use, it only found standardized usage with SIP-T [33]. It has been used to support numerous proprietary and non-interoperable extensions due to its poorly defined scope. My question is whether it is appropriate to provide some means of = clarifying other usages of the INFO method, and who should document = them. Should that occur in: i) An update or revision to RFC 2976 ii) An update to RFC 3427 iii) Anywhere else regards Keith Keith Drage drage@lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip The information contained in this message may be confidential to Kodiak = Networks, Inc. and its subsidiaries and protected from disclosure. If = this message did not reach the intended recipient, or an employee or = agent responsible for delivering it to the intended recipient, you are = hereby informed that any distribution or copying of this communication = is prohibited. If you have received this communication in error, please = notify us immediately by replying to the sender of the message and then = delete the message. Thank you. ------_=_NextPart_001_01C68F9B.18F26334 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Additional uses of INFO

Hi Keith/Jonathan,

This new draft lists out the brief details about the CURRENT = standards/drafts related to SIP.

Even now itself so many bugs raised against many RFCs but they have not = been fixed in the standard documents.

If we dont update the RFCs in ietf repository, We might end up in = writing one more draft to list out additional drafts/RFCs added once = this particular draft becomes an RFC.

Hence I feel shall we need to define an interval by which this and other = existing RFCs/drafts would fix the open bugs related respective = RFCs.

In this way we can help to avoid counfusion for the new entrant to SIP = world...

Regards,
Nataraju A.B.

-----Original Message-----
From: Drage, Keith (Keith) [mailto:drage@lucent.com]
Sent: Wed 6/14/2006 2:36 AM
To: sip@ietf.org
Subject: [Sip] Additional uses of INFO

Within the SIP protocol we have done a lot of tidying up as to how = extensions are made to the SIP protocol.

In particular RFC 3968 and RFC 3969 set up various registries for the = session initiation protocol, and RFC 3427 defines rules for definition = of headers and event packages.

Both within IETF, and in discussions outside IETF, we still see = proposals to use the INFO method (RFC 2976) for various purposes, and we = have no really clear statements on whether INFO method can be applied to = new applications, or not, and if so, who should document those new = applications. This is probably complicated by the fact that the INFO = RFC

http://www.ietf.org/internet-drafts/draft-rosenberg-sip-= hitchhikers-guide-00.txt currently lists RFC 2976 under the PSTN = interworking specifications, and that is currently the only defined IETF = usage, and also indicates under the general infrastructure section:

RFC 2976: The INFO Method (S) RFC 2976 [39] was defined as an
      extension to RFC 2543.  It defines a = method, INFO, used to
      transport mid-dialog information that has = no impact on SIP itself.
      Its driving application was the transport = of PSTN related
      information when using SIP between a pair = of gateways.  Though
      originally conceived for broader use, it = only found standardized
      usage with SIP-T [33].  It has been = used to support numerous
      proprietary and non-interoperable = extensions due to its poorly
      defined scope.

My question is whether it is appropriate to provide some means of = clarifying other usages of the INFO method, and who should document = them. Should that occur in:

i)      An update or revision to RFC 2976
ii)     An update to RFC 3427
iii)    Anywhere else

regards

Keith

Keith Drage
drage@lucent.com
tel: +44 1793 776249

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



The information contained in this message may be confidential to Kodiak = Networks, Inc. and its subsidiaries and protected from disclosure. If = this message did not reach the intended recipient, or an employee or = agent responsible for delivering it to the intended recipient, you are = hereby informed that any distribution or copying of this communication = is prohibited. If you have received this communication in error, please = notify us immediately by replying to the sender of the message and then = delete the message. Thank you. ------_=_NextPart_001_01C68F9B.18F26334-- --===============1977140160== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1977140160==-- From sip-bounces@ietf.org Wed Jun 14 09:29:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqVOp-0006yt-Nf; Wed, 14 Jun 2006 09:27:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqVOo-0006yo-38 for sip@ietf.org; Wed, 14 Jun 2006 09:27:10 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqVOm-0003mN-NN for sip@ietf.org; Wed, 14 Jun 2006 09:27:10 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 14 Jun 2006 09:27:08 -0400 X-IronPort-AV: i="4.06,131,1149480000"; d="scan'208"; a="90011137:sNHT31622972" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5EDR4Yb000415; Wed, 14 Jun 2006 09:27:08 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Jun 2006 09:26:41 -0400 Received: from [161.44.79.149] ([161.44.79.149]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Jun 2006 09:26:40 -0400 Message-ID: <44900E90.5050407@cisco.com> Date: Wed, 14 Jun 2006 09:26:40 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Sip] Error (nit) in RFC 3261 References: <072C5B76F7CEAB488172C6F64B30B5E301917B8C@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301917B8C@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 14 Jun 2006 13:26:40.0866 (UTC) FILETIME=[2BD24C20:01C68FB6] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: sip@ietf.org, Francois Audet , Keith Drage , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The relationship of the Expires header to the expires parameter is a mixed bag: - 8.3 on 3xx specifies Expires as default for expires in 3xx responses - same in 10.2 on REGISTER - 10.2.2 on removing bindings requires use of expires=0, no mention of allowing Expires:0 - 10.2.4 allows both - 10.3#6 on removing bindings again only allows expires=0 - 10.3#7 allows both - 10.3#8 on the contacts in the REGISTER response requires an explicit expires parameter in each Contact. No mention of using Expires as a default. - 20.10 (definition of Contact header) defines the expires parameter but doesn't mention relationship to Expires header. - 20.19 (definition of Expires header) says meaning is method dependent but doesn't mention relationship to expires parameter. - 21.3.3 (def of 302 response) mentions both It seems that as written, Expires acts a default for expires in REGISTER, *except* when trying to remove a binding. In responses to REGISTER, the UAC is required to take Expires as a default for a missing expires, but the UAS is required to use an expires parameter, so the default should never apply. It would be good to make this all consistent. I see no reason not to permit use of Expires:0 and no expires parameter when: - removing a binding - in a 3xx response to REGISTER Paul Michael Hammer (mhammer) wrote: > FTI, p. 162 indicates that Expires is optional for Reg. > > p. 59 indicates that the usage of Expires header that Paul is suggestiong: > > Look in "expires" para: "If this parameter is not provided, the value of the Expires header field is used instead." > > Mike > > >> -----Original Message----- >> From: Paul Kyzivat (pkyzivat) >> Sent: Tuesday, June 13, 2006 9:52 AM >> To: Francois Audet >> Cc: sip@ietf.org; Keith Drage; Dean Willis >> Subject: Re: [Sip] Error (nit) in RFC 3261 >> >> >> >> Francois Audet wrote: >>> I spotted an error in RFC 3261. >>> >>> The Registration response (200) in section 24.1 on p. 214 >> uses and Expires Header. >>> Section 10.3, point 8 (on p. 66) states that the 200 MUST use an >>> expires parameter, not an Expire Header (one for each contact). >>> >>> This is clearly an error. >> If/when 3261 gets updated, can we please do something clean? >> Specifically, say that in a REGISTER request or response the >> Expires header serves as a default value for any Contact that >> doesn't have an expires parameter. >> >> Paul >> >>> Also, the text says that the 200 SHOULD have a Date header, but the >>> example on p. 214 doesn't have one. This is not really an >> error and it >>> seems to be widespread omission (RFC 3265, outbound, etc.). >>> >>> Not sure what is the process for putting this in the Errata. >>> >>> ---- >>> François AUDET, Nortel Networks >>> mailto:audet@nortel.com >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sipping@ietf.org for new developments on the application of sip >>> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 14 09:40:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqVZa-0004Go-KE; Wed, 14 Jun 2006 09:38:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqVZZ-0004Ge-Gh for sip@ietf.org; Wed, 14 Jun 2006 09:38:17 -0400 Received: from mail45.messagelabs.com ([216.82.249.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FqVZY-0004IE-5S for sip@ietf.org; Wed, 14 Jun 2006 09:38:17 -0400 X-VirusChecked: Checked X-Env-Sender: Francesco_Paradiso@alliedtelesyn.com X-Msg-Ref: server-18.tower-45.messagelabs.com!1150292278!19668984!27 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [207.170.229.164] Received: (qmail 13398 invoked from network); 14 Jun 2006 13:38:13 -0000 Received: from 207-170-229-164.static.twtelecom.net (HELO SVR-WA-OWA.alliedtelesyn.com) (207.170.229.164) by server-18.tower-45.messagelabs.com with SMTP; 14 Jun 2006 13:38:13 -0000 Received: from svr-wa-exch.alliedtelesyn.com ([149.35.31.11]) by SVR-WA-OWA.alliedtelesyn.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 06:35:33 -0700 Received: from alliedtelesyn.com ([10.17.252.2]) by svr-wa-exch.alliedtelesyn.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 06:35:33 -0700 Received: from svr-mila-e2k1.alliedtelesyn.com ([10.17.39.14] RDNS failed) by alliedtelesyn.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 14 Jun 2006 15:23:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 Jun 2006 15:35:31 +0200 Message-ID: <563047DA3F61634180B39CD3E27D384401A464@svr-mila-e2k1.alliedtelesyn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3-way conference Thread-Index: AcaPt2f7ajI8LpCJRhGje7iq32ghRA== From: "Paradiso, Francesco" To: X-OriginalArrivalTime: 14 Jun 2006 13:23:16.0281 (UTC) FILETIME=[B1E11A90:01C68FB5] X-Spam-Score: 0.3 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: [Sip] 3-way conference X-BeenThere: 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="===============1577171053==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1577171053== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68FB7.68133C9D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68FB7.68133C9D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 a simple question about the 3-way call. If User A, User B and User C has established a conference and=20 if user C hang-up, may user A re-establish the same conference calling User C? =20 =20 is there any rfc about 3-way call using sip? =20 =20 Thanks in advance Best Regards, Francesco =20 =20 ------_=_NextPart_001_01C68FB7.68133C9D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
a = simple question=20 about the 3-way call.
If = User A, User B=20 and User C has established a conference = and 
if = user C=20 hang-up,
may = user=20 A re-establish the same conference calling User=20 C?  
 
is = there any rfc=20 about 3-way call using sip?
 
 
Thanks = in=20 advance

Best = Regards,
Francesco

 

 
------_=_NextPart_001_01C68FB7.68133C9D-- --===============1577171053== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1577171053==-- From sip-bounces@ietf.org Wed Jun 14 11:13:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqX24-0000lN-Uu; Wed, 14 Jun 2006 11:11:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqX23-0000lI-JT for sip@ietf.org; Wed, 14 Jun 2006 11:11:47 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqX22-0002k2-Cf for sip@ietf.org; Wed, 14 Jun 2006 11:11:47 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k5EFBi7P015473; Wed, 14 Jun 2006 10:11:44 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 14 Jun 2006 16:11:43 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0132CBBB2@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "Paradiso, Francesco" , sip@ietf.org Subject: RE: [Sip] 3-way conference Date: Wed, 14 Jun 2006 16:11:39 +0100 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: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Some of the following documents may help: IETF RFC 4353 ( February 2006): "A Framework for Conferencing with the Session Initiation Protocol (SIP)". draft-ietf-sipping-cc-conferencing-07 ( July 2005): "Session Initiation Protocol Call Control - Conferencing for User Agents". draft-ietf-sipping-conference-package-12 ( July 2005): "A Session Initiation Protocol (SIP) Event Package for Conference State". IETF RFC 3515 (April 2003): "The Session Initiation Protocol (SIP) Refer Method". IETF RFC 3840 (August 2004): "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)". IETF RFC 3892 (September 2004): "The Session Initiation Protocol (SIP) Referred-By Mechanism". IETF RFC 3891 (September 2004): " The Session Inititation Protocol (SIP) "Replaces" Header ". There is also related, but incomplete work (apart from the floor control protocol) in IETF XCON. regards Keith -----Original Message----- From: Paradiso, Francesco [mailto:Francesco_Paradiso@alliedtelesyn.com] Sent: 14 June 2006 14:36 To: sip@ietf.org Subject: [Sip] 3-way conference Hi all, a simple question about the 3-way call. If User A, User B and User C has established a conference and if user C hang-up, may user A re-establish the same conference calling User C? is there any rfc about 3-way call using sip? Thanks in advance Best Regards, Francesco _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 14 12:04:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXpI-0004BR-7L; Wed, 14 Jun 2006 12:02:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXpG-00049h-Qf for sip@ietf.org; Wed, 14 Jun 2006 12:02:38 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqXpF-00005Q-EN for sip@ietf.org; Wed, 14 Jun 2006 12:02:38 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 14 Jun 2006 09:02:36 -0700 X-IronPort-AV: i="4.06,132,1149490800"; d="scan'208"; a="294640170:sNHT33744518" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k5EG2a3N000676; Wed, 14 Jun 2006 09:02:36 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5EG2WcP020941; Wed, 14 Jun 2006 09:02:35 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Jun 2006 12:02:32 -0400 Received: from [192.168.1.101] ([10.86.240.14]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Jun 2006 12:02:32 -0400 Message-ID: <44903317.5020609@cisco.com> Date: Wed, 14 Jun 2006 12:02:31 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" Subject: Re: [Sip] Additional uses of INFO References: <475FF955A05DD411980D00508B6D5FB0132CBB04@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB0132CBB04@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jun 2006 16:02:32.0601 (UTC) FILETIME=[F1E3D090:01C68FCB] DKIM-Signature: a=rsa-sha1; q=dns; l=2979; t=1150300956; x=1151164956; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20Additional=20uses=20of=20INFO; X=v=3Dcisco.com=3B=20h=3DKqzyHieIsSjN7XTwqV1QDN0YE20=3D; b=AK1kQWHiaLatyevdXkp3Fp/H5JuHU7UbTZI8aRHD+FTGJY1ETYIh0QZGRDX1GH+s45Xpx1E+ zsWnd0g4/qJbg2K3VS9uMOHK++k2BHWqh+exERnC1fgrjJqEue+mCzCU; Authentication-Results: sj-dkim-7.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Well, my opinion on INFO is that its an exceptionally poor vehicle for doing extensions. A long while back, I wrote an I-D called "INFO considered harmful" which summarized my thinking on this: http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt The conclusion of the document is that we should limit INFO to its only defined usage - for ISUP transport - and I still think this conclusion makes sense. Thanks, Jonathan R. Drage, Keith (Keith) wrote: > Within the SIP protocol we have done a lot of tidying up as to how > extensions are made to the SIP protocol. > > In particular RFC 3968 and RFC 3969 set up various registries for the > session initiation protocol, and RFC 3427 defines rules for > definition of headers and event packages. > > Both within IETF, and in discussions outside IETF, we still see > proposals to use the INFO method (RFC 2976) for various purposes, and > we have no really clear statements on whether INFO method can be > applied to new applications, or not, and if so, who should document > those new applications. This is probably complicated by the fact that > the INFO RFC > > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-hitchhikers-guide-00.txt > currently lists RFC 2976 under the PSTN interworking specifications, > and that is currently the only defined IETF usage, and also indicates > under the general infrastructure section: > > RFC 2976: The INFO Method (S) RFC 2976 [39] was defined as an > extension to RFC 2543. It defines a method, INFO, used to transport > mid-dialog information that has no impact on SIP itself. Its driving > application was the transport of PSTN related information when using > SIP between a pair of gateways. Though originally conceived for > broader use, it only found standardized usage with SIP-T [33]. It > has been used to support numerous proprietary and non-interoperable > extensions due to its poorly defined scope. > > My question is whether it is appropriate to provide some means of > clarifying other usages of the INFO method, and who should document > them. Should that occur in: > > i) An update or revision to RFC 2976 ii) An update to RFC 3427 iii) > Anywhere else > > regards > > Keith > > Keith Drage drage@lucent.com tel: +44 1793 776249 > > _______________________________________________ Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip This list is for NEW > development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 14 12:28:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqYCc-00081l-QQ; Wed, 14 Jun 2006 12:26:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqYCb-00080z-Cp for sip@ietf.org; Wed, 14 Jun 2006 12:26:45 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqYCa-0002cN-1c for sip@ietf.org; Wed, 14 Jun 2006 12:26:45 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k5EGQfVc015295; Wed, 14 Jun 2006 11:26:42 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 14 Jun 2006 17:26:41 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0132CBBD4@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Jonathan Rosenberg Subject: RE: [Sip] Additional uses of INFO Date: Wed, 14 Jun 2006 17:26:39 +0100 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: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Unfortunately you never pushed this through to an RFC, so the WG never formed a consensus opinion one way or the other. What we have is therefore people referring to the INFO RFC and thinking they can use it for everything. What you appear to be saying from your viewpoint is to update something to say either - No usage outside existing ISUP usage; or - Additional usages are RFC required, so that those usages can have expert review for the harm to the SIP environment. Is this right or is there another view? regards Keith > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: 14 June 2006 17:03 > To: Drage, Keith (Keith) > Cc: sip@ietf.org > Subject: Re: [Sip] Additional uses of INFO > > > Well, my opinion on INFO is that its an exceptionally poor vehicle for > doing extensions. A long while back, I wrote an I-D called "INFO > considered harmful" which summarized my thinking on this: > > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt > > The conclusion of the document is that we should limit INFO > to its only > defined usage - for ISUP transport - and I still think this > conclusion > makes sense. > > Thanks, > Jonathan R. > > Drage, Keith (Keith) wrote: > > > Within the SIP protocol we have done a lot of tidying up as to how > > extensions are made to the SIP protocol. > > > > In particular RFC 3968 and RFC 3969 set up various > registries for the > > session initiation protocol, and RFC 3427 defines rules for > > definition of headers and event packages. > > > > Both within IETF, and in discussions outside IETF, we still see > > proposals to use the INFO method (RFC 2976) for various > purposes, and > > we have no really clear statements on whether INFO method can be > > applied to new applications, or not, and if so, who should document > > those new applications. This is probably complicated by the > fact that > > the INFO RFC > > > > > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-hitchh > ikers-guide-00.txt > > currently lists RFC 2976 under the PSTN interworking specifications, > > and that is currently the only defined IETF usage, and also > indicates > > under the general infrastructure section: > > > > RFC 2976: The INFO Method (S) RFC 2976 [39] was defined as an > > extension to RFC 2543. It defines a method, INFO, used to transport > > mid-dialog information that has no impact on SIP itself. Its driving > > application was the transport of PSTN related information when using > > SIP between a pair of gateways. Though originally conceived for > > broader use, it only found standardized usage with SIP-T [33]. It > > has been used to support numerous proprietary and non-interoperable > > extensions due to its poorly defined scope. > > > > My question is whether it is appropriate to provide some means of > > clarifying other usages of the INFO method, and who should document > > them. Should that occur in: > > > > i) An update or revision to RFC 2976 ii) An update to > RFC 3427 iii) > > Anywhere else > > > > regards > > > > Keith > > > > Keith Drage drage@lucent.com tel: +44 1793 776249 > > > > _______________________________________________ Sip mailing list > > https://www1.ietf.org/mailman/listinfo/sip This list is for NEW > > development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 14 12:33:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqYHO-0003yo-PU; Wed, 14 Jun 2006 12:31:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqYHN-0003vx-CY for sip@ietf.org; Wed, 14 Jun 2006 12:31:41 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqYHL-0002pc-W6 for sip@ietf.org; Wed, 14 Jun 2006 12:31:41 -0400 Received: from [192.168.2.104] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5EGX5xI030703 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 14 Jun 2006 11:33:07 -0500 In-Reply-To: <44903317.5020609@cisco.com> References: <475FF955A05DD411980D00508B6D5FB0132CBB04@en0033exch001u.uk.lucent.com> <44903317.5020609@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Additional uses of INFO Date: Wed, 14 Jun 2006 11:31:38 -0500 To: Sip IETF X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Keith Drage X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org And now, for a view from the other side of the peanut gallery: I think INFO is potentially a great mechanism for exchanging structured data within dialog-bounded applications (perhaps not extensions -- I don't agree that every new application should require a new extension), but that we've harnessed the power of that mechanism poorly. Currently, we lack both a mechanism for describing the usage of INFO, and a mechanism for negotiating that usage between nodes. If we were to do anything further with it, it might make sense to emulate the model of event packages, which so far seems to have worked well enough. I proposed this in: http://www.softarmor.com/wgdb/docs/draft-willis-sip-infopackage-00.txt I personally think it's a really BAD idea to keep introducing new SIP extensions that just shuttle blobs of stuff between UAs. We need only one extension for this, and a way of cleanly declaring what the stuff is and what should be done with it and of finding out whether a correspondent would understand that declaration. And yes, I think MESSAGE is pretty much just INFO with its name changed to protect the innocent. -- Dean On Jun 14, 2006, at 11:02 AM, Jonathan Rosenberg wrote: > Well, my opinion on INFO is that its an exceptionally poor vehicle for > doing extensions. A long while back, I wrote an I-D called "INFO > considered harmful" which summarized my thinking on this: > > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt > > The conclusion of the document is that we should limit INFO to its > only > defined usage - for ISUP transport - and I still think this > conclusion makes sense. > > >> My question is whether it is appropriate to provide some means of >> clarifying other usages of the INFO method, and who should document >> them. Should that occur in: >> i) An update or revision to RFC 2976 ii) An update to RFC 3427 iii) >> Anywhere else >> regards >> Keith >> Keith Drage drage@lucent.com tel: +44 1793 776249 >> _______________________________________________ Sip mailing list _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 14 12:40:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqYOL-0008Su-LA; Wed, 14 Jun 2006 12:38:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqYOK-0008Rz-4h for sip@ietf.org; Wed, 14 Jun 2006 12:38:52 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqYOI-00037D-SX for sip@ietf.org; Wed, 14 Jun 2006 12:38:52 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k5EGcmdM028303; Wed, 14 Jun 2006 11:38:48 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 14 Jun 2006 17:38:45 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0132CBBDE@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Dean Willis , Sip IETF Subject: RE: [Sip] Additional uses of INFO Date: Wed, 14 Jun 2006 17:38:43 +0100 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: 0fa76816851382eb71b0a882ccdc29ac Cc: Keith Drage X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org And in terms of the questions I asked in relation to INFO, does this mean that you also consider that such usages should have the same level of review as an event package (as defined in RFC 3427), i.e. informational RFC with approval conditional on SIP expert review. regards Keith > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 14 June 2006 17:32 > To: Sip IETF > Cc: Keith Drage; Jonathan Rosenberg > Subject: Re: [Sip] Additional uses of INFO > > > > And now, for a view from the other side of the peanut gallery: > > I think INFO is potentially a great mechanism for exchanging > structured data within dialog-bounded applications (perhaps not > extensions -- I don't agree that every new application should > require > a new extension), but that we've harnessed the power of that > mechanism poorly. > > Currently, we lack both a mechanism for describing the usage > of INFO, > and a mechanism for negotiating that usage between nodes. If we were > to do anything further with it, it might make sense to emulate the > model of event packages, which so far seems to have worked > well enough. > > I proposed this in: > > http://www.softarmor.com/wgdb/docs/draft-willis-sip-infopackage-00.txt > > > I personally think it's a really BAD idea to keep introducing > new SIP > extensions that just shuttle blobs of stuff between UAs. We > need only > one extension for this, and a way of cleanly declaring what > the stuff > is and what should be done with it and of finding out whether a > correspondent would understand that declaration. And yes, I think > MESSAGE is pretty much just INFO with its name changed to > protect the > innocent. > > -- > Dean > > > On Jun 14, 2006, at 11:02 AM, Jonathan Rosenberg wrote: > > > Well, my opinion on INFO is that its an exceptionally poor > vehicle for > > doing extensions. A long while back, I wrote an I-D called "INFO > > considered harmful" which summarized my thinking on this: > > > > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt > > The conclusion of the document is that we should limit INFO to its > only > defined usage - for ISUP transport - and I still think this > conclusion makes sense. > > >> My question is whether it is appropriate to provide some means of >> clarifying other usages of the INFO method, and who should document >> them. Should that occur in: >> i) An update or revision to RFC 2976 ii) An update to RFC 3427 iii) >> Anywhere else >> regards >> Keith >> Keith Drage drage@lucent.com tel: +44 1793 776249 >> _______________________________________________ Sip mailing list _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 14 12:57:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqYf4-0007uM-Lu; Wed, 14 Jun 2006 12:56:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqYf2-0007tE-TH for sip@ietf.org; Wed, 14 Jun 2006 12:56:08 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqYf1-0004Ro-Ht for sip@ietf.org; Wed, 14 Jun 2006 12:56:08 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 14 Jun 2006 12:56:07 -0400 X-IronPort-AV: i="4.06,132,1149480000"; d="scan'208"; a="90035298:sNHT31273928" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5EGu7no015175; Wed, 14 Jun 2006 12:56:07 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Jun 2006 12:56:07 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.20.84]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Jun 2006 12:56:06 -0400 Message-Id: <4.3.2.7.2.20060614115113.018f6ef8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Jun 2006 11:56:05 -0500 To: "Drage, Keith (Keith)" , Jonathan Rosenberg From: "James M. Polk" Subject: RE: [Sip] Additional uses of INFO In-Reply-To: <475FF955A05DD411980D00508B6D5FB0132CBBD4@en0033exch001u.uk .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 14 Jun 2006 16:56:06.0589 (UTC) FILETIME=[6D9376D0:01C68FD3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 05:26 PM 6/14/2006 +0100, Drage, Keith (Keith) wrote: >Unfortunately you never pushed this through to an RFC, so the WG never >formed a consensus opinion one way or the other. > >What we have is therefore people referring to the INFO RFC and thinking >they can use it for everything. > >What you appear to be saying from your viewpoint is to update something to >say either > >- No usage outside existing ISUP usage; or >- Additional usages are RFC required, so that those usages can have >expert review for the harm to the SIP environment. Hitchiker's states: "It defines a method, INFO, used to transport mid-dialog information that has no impact on SIP itself." This means no impact on SIP, so why would a review be required - unless you want a review that there is no harm caused to SIP. >Is this right or is there another view? > >regards > >Keith > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > Sent: 14 June 2006 17:03 > > To: Drage, Keith (Keith) > > Cc: sip@ietf.org > > Subject: Re: [Sip] Additional uses of INFO > > > > > > Well, my opinion on INFO is that its an exceptionally poor vehicle for > > doing extensions. A long while back, I wrote an I-D called "INFO > > considered harmful" which summarized my thinking on this: > > > > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt > > > > The conclusion of the document is that we should limit INFO > > to its only > > defined usage - for ISUP transport - and I still think this > > conclusion > > makes sense. > > > > Thanks, > > Jonathan R. > > > > Drage, Keith (Keith) wrote: > > > > > Within the SIP protocol we have done a lot of tidying up as to how > > > extensions are made to the SIP protocol. > > > > > > In particular RFC 3968 and RFC 3969 set up various > > registries for the > > > session initiation protocol, and RFC 3427 defines rules for > > > definition of headers and event packages. > > > > > > Both within IETF, and in discussions outside IETF, we still see > > > proposals to use the INFO method (RFC 2976) for various > > purposes, and > > > we have no really clear statements on whether INFO method can be > > > applied to new applications, or not, and if so, who should document > > > those new applications. This is probably complicated by the > > fact that > > > the INFO RFC > > > > > > > > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-hitchh > > ikers-guide-00.txt > > > currently lists RFC 2976 under the PSTN interworking specifications, > > > and that is currently the only defined IETF usage, and also > > indicates > > > under the general infrastructure section: > > > > > > RFC 2976: The INFO Method (S) RFC 2976 [39] was defined as an > > > extension to RFC 2543. It defines a method, INFO, used to transport > > > mid-dialog information that has no impact on SIP itself. Its driving > > > application was the transport of PSTN related information when using > > > SIP between a pair of gateways. Though originally conceived for > > > broader use, it only found standardized usage with SIP-T [33]. It > > > has been used to support numerous proprietary and non-interoperable > > > extensions due to its poorly defined scope. > > > > > > My question is whether it is appropriate to provide some means of > > > clarifying other usages of the INFO method, and who should document > > > them. Should that occur in: > > > > > > i) An update or revision to RFC 2976 ii) An update to > > RFC 3427 iii) > > > Anywhere else > > > > > > regards > > > > > > Keith > > > > > > Keith Drage drage@lucent.com tel: +44 1793 776249 > > > > > > _______________________________________________ Sip mailing list > > > https://www1.ietf.org/mailman/listinfo/sip This list is for NEW > > > development of the core SIP Protocol Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sipping@ietf.org for new developments on the application of sip > > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ > > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 14 14:27:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqa3t-0003Th-92; Wed, 14 Jun 2006 14:25:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqa3r-0003Sj-7D; Wed, 14 Jun 2006 14:25:51 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqa3o-00081T-Qr; Wed, 14 Jun 2006 14:25:51 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k5EIPmiS006644; Wed, 14 Jun 2006 11:25:48 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k5EIPmW0006643; Wed, 14 Jun 2006 11:25:48 -0700 Date: Wed, 14 Jun 2006 11:25:48 -0700 Message-Id: <200606141825.k5EIPmW0006643@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: sip@ietf.org, rfc-editor@rfc-editor.org Subject: [Sip] RFC 4538 on Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4538 Title: Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP) Author: J. Rosenberg Status: Standards Track Date: June 2006 Mailbox: jdrosen@cisco.com Pages: 17 Characters: 36089 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sip-target-dialog-03.txt URL: http://www.rfc-editor.org/rfc/rfc4538.txt This specification defines the Target-Dialog header field for the Session Initiation Protocol (SIP), and the corresponding option tag, tdialog. This header field is used in requests that create SIP dialogs. It indicates to the recipient that the sender is aware of an existing dialog with the recipient, either because the sender is on the other side of that dialog, or because it has access to the dialog identifiers. The recipient can then authorize the request based on this awareness. [STANDARDS TRACK] This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: 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 ... _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 14 14:36:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqaCP-0007Lp-UE; Wed, 14 Jun 2006 14:34:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqaCN-0007L7-Bk for sip@ietf.org; Wed, 14 Jun 2006 14:34:39 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqaCL-0000XZ-PT for sip@ietf.org; Wed, 14 Jun 2006 14:34:39 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 964B36C020 for ; Wed, 14 Jun 2006 14:34:35 -0400 (EDT) Subject: Re: [Sip] Max-Forwards in ACK for non-2xx From: "Dale R. Worley" To: Sip In-Reply-To: <001a01c68f7b$f6547f80$31713b51@BEMBUSTER> References: <001a01c68f7b$f6547f80$31713b51@BEMBUSTER> Content-Type: text/plain Date: Wed, 14 Jun 2006 14:34:35 -0400 Message-Id: <1150310075.25224.20.camel@niagra.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Wed, 2006-06-14 at 08:29 +0200, Jeroen van Bemmel wrote: > For this scenario, it again seems necessary that a stateless proxy > stops non-2xx ACKs for responses it generated. Moreover, perhaps > section 17.1.1.3 should be updated to say that the Max-Forwards value > should be the same as was used for the INVITE that was forwarded. The > ACK should not propagate further than the INVITE This seems to be a particularly nasty case of a general truth: if a SIP agent generates a response, it really can't do so statelessly, as it is acting more like a UA than a proxy, in that it is creating a to-tag, etc. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 14 16:39:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqc6z-0007Rk-4c; Wed, 14 Jun 2006 16:37:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqc6x-0007RO-LA for sip@ietf.org; Wed, 14 Jun 2006 16:37:11 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqc6w-0007OK-2h for sip@ietf.org; Wed, 14 Jun 2006 16:37:11 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 14 Jun 2006 13:37:09 -0700 X-IronPort-AV: i="4.06,133,1149490800"; d="scan'208"; a="294811286:sNHT33311004" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k5EKb9va012422; Wed, 14 Jun 2006 13:37:09 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5EKb8cN014939; Wed, 14 Jun 2006 13:37:08 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Jun 2006 16:37:07 -0400 Received: from [192.168.1.101] ([10.86.240.14]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Jun 2006 16:37:07 -0400 Message-ID: <44907372.5010808@cisco.com> Date: Wed, 14 Jun 2006 16:37:06 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" Subject: Re: [Sip] Additional uses of INFO References: <475FF955A05DD411980D00508B6D5FB0132CBBD4@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB0132CBBD4@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jun 2006 20:37:07.0480 (UTC) FILETIME=[4DAED980:01C68FF2] DKIM-Signature: a=rsa-sha1; q=dns; l=4647; t=1150317429; x=1151181429; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20Additional=20uses=20of=20INFO; X=v=3Dcisco.com=3B=20h=3DKqzyHieIsSjN7XTwqV1QDN0YE20=3D; b=JA3j8K0OoB5Rng6aZec3h/4aSq6lMZTs1gc739943qqaX7PquCfsFU7bHcOAFo6H/yL1mR69 PGNyhVrFzeWAKdgb7YZsX6Z/6gySGAR5DG46kFrxDywa4wMC1zvUkJCg; Authentication-Results: sj-dkim-5.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm saying that there are no usages outside of the ISUP usage. If you want to define some kind of way to transport mid-dialog data between A and B then define a method for it, with the semantics appropriate based on what you are trying to do. -Jonathan R. Drage, Keith (Keith) wrote: > Unfortunately you never pushed this through to an RFC, so the WG > never formed a consensus opinion one way or the other. > > What we have is therefore people referring to the INFO RFC and > thinking they can use it for everything. > > What you appear to be saying from your viewpoint is to update > something to say either > > - No usage outside existing ISUP usage; or - Additional usages are > RFC required, so that those usages can have expert review for the > harm to the SIP environment. > > Is this right or is there another view? > > regards > > Keith > > >> -----Original Message----- From: Jonathan Rosenberg >> [mailto:jdrosen@cisco.com] Sent: 14 June 2006 17:03 To: Drage, >> Keith (Keith) Cc: sip@ietf.org Subject: Re: [Sip] Additional uses >> of INFO >> >> >> Well, my opinion on INFO is that its an exceptionally poor vehicle >> for doing extensions. A long while back, I wrote an I-D called >> "INFO considered harmful" which summarized my thinking on this: >> >> http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt >> >> >> The conclusion of the document is that we should limit INFO to its >> only defined usage - for ISUP transport - and I still think this >> conclusion makes sense. >> >> Thanks, Jonathan R. >> >> Drage, Keith (Keith) wrote: >> >> >>> Within the SIP protocol we have done a lot of tidying up as to >>> how extensions are made to the SIP protocol. >>> >>> In particular RFC 3968 and RFC 3969 set up various >> >> registries for the >> >>> session initiation protocol, and RFC 3427 defines rules for >>> definition of headers and event packages. >>> >>> Both within IETF, and in discussions outside IETF, we still see >>> proposals to use the INFO method (RFC 2976) for various >> >> purposes, and >> >>> we have no really clear statements on whether INFO method can be >>> applied to new applications, or not, and if so, who should >>> document those new applications. This is probably complicated by >>> the >> >> fact that >> >>> the INFO RFC >>> >>> >> >> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-hitchh >> ikers-guide-00.txt >> >>> currently lists RFC 2976 under the PSTN interworking >>> specifications, and that is currently the only defined IETF >>> usage, and also >> >> indicates >> >>> under the general infrastructure section: >>> >>> RFC 2976: The INFO Method (S) RFC 2976 [39] was defined as an >>> extension to RFC 2543. It defines a method, INFO, used to >>> transport mid-dialog information that has no impact on SIP >>> itself. Its driving application was the transport of PSTN related >>> information when using SIP between a pair of gateways. Though >>> originally conceived for broader use, it only found standardized >>> usage with SIP-T [33]. It has been used to support numerous >>> proprietary and non-interoperable extensions due to its poorly >>> defined scope. >>> >>> My question is whether it is appropriate to provide some means of >>> clarifying other usages of the INFO method, and who should >>> document them. Should that occur in: >>> >>> i) An update or revision to RFC 2976 ii) An update to >> >> RFC 3427 iii) >> >>> Anywhere else >>> >>> regards >>> >>> Keith >>> >>> Keith Drage drage@lucent.com tel: +44 1793 776249 >>> >>> _______________________________________________ Sip mailing list >>> https://www1.ietf.org/mailman/listinfo/sip This list is for NEW >>> development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sipping@ietf.org for new developments on the application of sip >>> >> >> -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Cisco Fellow Parsippany, NJ >> 07054-2711 Cisco Systems jdrosen@cisco.com >> FAX: (973) 952-5050 http://www.jdrosen.net >> PHONE: (973) 952-5000 http://www.cisco.com >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 14 16:44:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqcCa-0006FE-0v; Wed, 14 Jun 2006 16:43:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqcCY-0006F2-Lk for sip@ietf.org; Wed, 14 Jun 2006 16:42:58 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqcCY-0007mv-7w for sip@ietf.org; Wed, 14 Jun 2006 16:42:58 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 14 Jun 2006 16:42:58 -0400 X-IronPort-AV: i="4.06,133,1149480000"; d="scan'208"; a="90061843:sNHT33255292" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5EKgvno019253; Wed, 14 Jun 2006 16:42:57 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Jun 2006 16:42:57 -0400 Received: from [192.168.1.101] ([10.86.240.14]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Jun 2006 16:42:56 -0400 Message-ID: <449074D0.4090609@cisco.com> Date: Wed, 14 Jun 2006 16:42:56 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Sip] Additional uses of INFO References: <4.3.2.7.2.20060614115113.018f6ef8@email.cisco.com> In-Reply-To: <4.3.2.7.2.20060614115113.018f6ef8@email.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jun 2006 20:42:57.0011 (UTC) FILETIME=[1E050C30:01C68FF3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: sip@ietf.org, "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The problem is that this 'no impact on SIP' is really quite meaningless. Does it mean the dialog state? Does it mean that it is always passed to a human user? Considering dialog state for example, we have methods that have no impact on the SIP dialog states (such as MESSAGE), yet we have chosen (correctly I think) to define methods for them. The reality is that, one way or another, you need to define specifications that allow entity A to send information to entity B if you expect it to be processed by an automata. I'm suggesting that, if the protocol used to transport that information is SIP, we have several defined techniques for extensibility (new method, body, params, etc.) which are sufficient. I see no need for a *new* extensibility vehicle. Thanks, Jonathan R. James M. Polk wrote: > At 05:26 PM 6/14/2006 +0100, Drage, Keith (Keith) wrote: > >> Unfortunately you never pushed this through to an RFC, so the WG never >> formed a consensus opinion one way or the other. >> >> What we have is therefore people referring to the INFO RFC and >> thinking they can use it for everything. >> >> What you appear to be saying from your viewpoint is to update >> something to say either >> >> - No usage outside existing ISUP usage; or >> - Additional usages are RFC required, so that those usages can >> have expert review for the harm to the SIP environment. > > > Hitchiker's states: > > "It defines a method, INFO, used to transport > mid-dialog information that has no impact on > SIP itself." > > This means no impact on SIP, so why would a review be required - unless > you want a review that there is no harm caused to SIP. > > >> Is this right or is there another view? >> >> regards >> >> Keith >> >> > -----Original Message----- >> > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >> > Sent: 14 June 2006 17:03 >> > To: Drage, Keith (Keith) >> > Cc: sip@ietf.org >> > Subject: Re: [Sip] Additional uses of INFO >> > >> > >> > Well, my opinion on INFO is that its an exceptionally poor vehicle for >> > doing extensions. A long while back, I wrote an I-D called "INFO >> > considered harmful" which summarized my thinking on this: >> > >> > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt >> > >> > The conclusion of the document is that we should limit INFO >> > to its only >> > defined usage - for ISUP transport - and I still think this >> > conclusion >> > makes sense. >> > >> > Thanks, >> > Jonathan R. >> > >> > Drage, Keith (Keith) wrote: >> > >> > > Within the SIP protocol we have done a lot of tidying up as to how >> > > extensions are made to the SIP protocol. >> > > >> > > In particular RFC 3968 and RFC 3969 set up various >> > registries for the >> > > session initiation protocol, and RFC 3427 defines rules for >> > > definition of headers and event packages. >> > > >> > > Both within IETF, and in discussions outside IETF, we still see >> > > proposals to use the INFO method (RFC 2976) for various >> > purposes, and >> > > we have no really clear statements on whether INFO method can be >> > > applied to new applications, or not, and if so, who should document >> > > those new applications. This is probably complicated by the >> > fact that >> > > the INFO RFC >> > > >> > > >> > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-hitchh >> > ikers-guide-00.txt >> > > currently lists RFC 2976 under the PSTN interworking specifications, >> > > and that is currently the only defined IETF usage, and also >> > indicates >> > > under the general infrastructure section: >> > > >> > > RFC 2976: The INFO Method (S) RFC 2976 [39] was defined as an >> > > extension to RFC 2543. It defines a method, INFO, used to transport >> > > mid-dialog information that has no impact on SIP itself. Its driving >> > > application was the transport of PSTN related information when using >> > > SIP between a pair of gateways. Though originally conceived for >> > > broader use, it only found standardized usage with SIP-T [33]. It >> > > has been used to support numerous proprietary and non-interoperable >> > > extensions due to its poorly defined scope. >> > > >> > > My question is whether it is appropriate to provide some means of >> > > clarifying other usages of the INFO method, and who should document >> > > them. Should that occur in: >> > > >> > > i) An update or revision to RFC 2976 ii) An update to >> > RFC 3427 iii) >> > > Anywhere else >> > > >> > > regards >> > > >> > > Keith >> > > >> > > Keith Drage drage@lucent.com tel: +44 1793 776249 >> > > >> > > _______________________________________________ Sip mailing list >> > > https://www1.ietf.org/mailman/listinfo/sip This list is for NEW >> > > development of the core SIP Protocol Use >> > > sip-implementors@cs.columbia.edu for questions on current sip Use >> > > sipping@ietf.org for new developments on the application of sip >> > > >> > >> > -- >> > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> > Cisco Fellow Parsippany, NJ >> > 07054-2711 >> > Cisco Systems >> > jdrosen@cisco.com FAX: (973) 952-5050 >> > http://www.jdrosen.net PHONE: (973) 952-5000 >> > http://www.cisco.com >> > >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 14 17:17:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqchq-0001oT-Sm; Wed, 14 Jun 2006 17:15:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqchp-0001oO-MH for sip@ietf.org; Wed, 14 Jun 2006 17:15:17 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqcho-0001EC-Dy for sip@ietf.org; Wed, 14 Jun 2006 17:15:17 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 14 Jun 2006 14:15:15 -0700 X-IronPort-AV: i="4.06,133,1149490800"; d="scan'208"; a="294836522:sNHT32702952" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k5ELFFKD011551; Wed, 14 Jun 2006 14:15:15 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5ELFEIs017708; Wed, 14 Jun 2006 14:15:15 -0700 (PDT) From: "Dan Wing" To: "'Cullen Jennings \(fluffy\)'" , "'Jon Peterson'" , "'Jason Fischl'" , Date: Wed, 14 Jun 2006 14:15:14 -0700 Message-ID: <067601c68ff7$a16bd2d0$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaP96A9CMknXKFmRrm02WXiAlYqjg== DKIM-Signature: a=rsa-sha1; q=dns; l=550; t=1150319715; x=1151183715; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:draft-ietf-sip-certs=20and=20retargeting; X=v=3Dcisco.com=3B=20h=3DGoICT/6OGZBo25v4ac4BdLapwdo=3D; b=N/j3YovIJMbbb29pp2ZErmJ5h4d7iPIUvByHI1O3HKoER83lFaKEGAkDf592TCTivj78YBYr EpweqfW0WrjEJCwxzI8hrYNtarzhvzPUrJD68yJYEQFSVbwqOTtY5bcA; Authentication-Results: sj-dkim-8.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Sip] draft-ietf-sip-certs and retargeting X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org In section 4, draft-ietf-sip-certs-00 reads: The details of how a UA deals with receiving encrypted messages is outside the scope of this specification but it is worth noting that if Charlie's UAS receives a request that is encrypted to Bob, it would be valid and legal for that UA to send a 302 redirecting the call to Charlie. I'm confused by which UA is referred to by "that UA". Shouldn't the sentence above instead be: ... valid and legal for Charlie's UA to send a 302 redirecting the call to Bob. -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 14 18:44:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqe4C-0004pe-Uf; Wed, 14 Jun 2006 18:42:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqe4C-0004pZ-CZ for sip@ietf.org; Wed, 14 Jun 2006 18:42:28 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqe4B-0004xG-1d for sip@ietf.org; Wed, 14 Jun 2006 18:42:28 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 14 Jun 2006 18:42:27 -0400 X-IronPort-AV: i="4.06,133,1149480000"; d="scan'208"; a="90072519:sNHT30441176" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5EMgQnq013959; Wed, 14 Jun 2006 18:42:26 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Jun 2006 18:42:26 -0400 Received: from [161.44.79.149] ([161.44.79.149]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Jun 2006 18:42:26 -0400 Message-ID: <449090D1.7090600@cisco.com> Date: Wed, 14 Jun 2006 18:42:25 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] outbound i-d update? References: <5EB80D22825EEE42872083AD5BFFB594017F10AF@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F10AF@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 14 Jun 2006 22:42:26.0120 (UTC) FILETIME=[CF244480:01C69003] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: fluffy@cisco.com, 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: , Errors-To: sip-bounces@ietf.org The decision about how many to keep open is *policy*. It may be that there is a UA that doesn't care about reliability very much, so its policy is to keep only one connection up. (Outbound is still useful for nat traversal.) Both ends of the connection may have a policy about this. If so, those need to be reconciled somehow. But I don't see why that should be wired into this specification. IMO it would be sufficient to specify a default that SHOULD apply unless there is explicit policy to the contrary. Paul Christer Holmberg (JO/LMF) wrote: > Hi, > > For example, the knowledge could come to the client from the network in a REGISTER response, i.e. the network tells the client how many flows it wants to client to establish. > > Or something like that... I haven't thought much about it, but maybe it's one possible alternative. > > Regards, > > Christer > > > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com] > Sent: 14. kesäkuuta 2006 11:24 > To: Christer Holmberg (JO/LMF) > Cc: Erkki.Koivusalo@nokia.com; fluffy@cisco.com; sip@ietf.org > Subject: RE: [Sip] outbound i-d update? > > Christer Holmberg (JO/LMF) writes: > > > But, I still think that the client should still be allowed to open a > flow with only a single IP address, because the fact that it receives > multiple URIs/addresses may have nothing to do with fault > tolerance. But, in this case the client must of course have knowledge > about that. > > and how would that knowledge be auto-configured to the client? > > -- 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 Jun 14 21:45:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqgt9-0003IJ-2S; Wed, 14 Jun 2006 21:43:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqgt6-0003IB-AM for sip@ietf.org; Wed, 14 Jun 2006 21:43:12 -0400 Received: from natklopstock.rzone.de ([81.169.145.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqgt4-0007r3-OX for sip@ietf.org; Wed, 14 Jun 2006 21:43:12 -0400 Received: from snom.de ([195.2.174.186]) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k5F1ggAY016782; Thu, 15 Jun 2006 03:42:42 +0200 (MEST) 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] 3-way conference X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 15 Jun 2006 03:42:38 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] 3-way conference Thread-Index: AcaPxXiurojF4ty/TbyS+7hlWU+H0AAV18wg From: "Christian Stredicke" To: "Drage, Keith \(Keith\)" , "Paradiso, Francesco" , X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Also, RFC 3911 (October 2004): The Session Initiation Protocol (SIP) "Join" Header=20 CS > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 > Sent: Wednesday, June 14, 2006 11:16 AM > To: Paradiso, Francesco; sip@ietf.org > Subject: RE: [Sip] 3-way conference >=20 > Some of the following documents may help: >=20 > IETF RFC 4353 ( February 2006): "A Framework for Conferencing=20 > with the Session Initiation Protocol (SIP)". > draft-ietf-sipping-cc-conferencing-07 ( July 2005): "Session=20 > Initiation Protocol Call Control - Conferencing for User Agents". > draft-ietf-sipping-conference-package-12 ( July 2005): "A=20 > Session Initiation Protocol (SIP) Event Package for Conference State". > IETF RFC 3515 (April 2003): "The Session Initiation Protocol=20 > (SIP) Refer Method". > IETF RFC 3840 (August 2004): "Indicating User Agent=20 > Capabilities in the Session Initiation Protocol (SIP)". > IETF RFC 3892 (September 2004): "The Session Initiation=20 > Protocol (SIP) Referred-By Mechanism". > IETF RFC 3891 (September 2004): " The Session Inititation=20 > Protocol (SIP) "Replaces" Header ". >=20 > There is also related, but incomplete work (apart from the=20 > floor control protocol) in IETF XCON. >=20 > regards >=20 > Keith >=20 >=20 > -----Original Message----- > From: Paradiso, Francesco=20 > [mailto:Francesco_Paradiso@alliedtelesyn.com] > Sent: 14 June 2006 14:36 > To: sip@ietf.org > Subject: [Sip] 3-way conference >=20 >=20 > Hi all, >=20 > a simple question about the 3-way call. > If User A, User B and User C has established a conference and=20 > if user C hang-up, may user A re-establish the same=20 > conference calling User C? =20 >=20 > is there any rfc about 3-way call using sip? >=20 >=20 > Thanks in advance > Best Regards, > Francesco > =20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 14 22:01:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqh9N-0004sh-0R; Wed, 14 Jun 2006 22:00:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqh9K-0004qk-Gy for sip@ietf.org; Wed, 14 Jun 2006 21:59:58 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqh9J-00030J-7N for sip@ietf.org; Wed, 14 Jun 2006 21:59:58 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 14 Jun 2006 21:59:57 -0400 X-IronPort-AV: i="4.06,133,1149480000"; d="scan'208"; a="90081915:sNHT30486836" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5F1xvYN029885 for ; Wed, 14 Jun 2006 21:59:57 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Jun 2006 21:59:57 -0400 Received: from [192.168.1.101] ([10.86.242.29]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Jun 2006 21:59:56 -0400 Message-ID: <4490BF1C.4050304@cisco.com> Date: Wed, 14 Jun 2006 21:59:56 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jun 2006 01:59:56.0792 (UTC) FILETIME=[66B14F80:01C6901F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Subject: [Sip] updated GRUU spec X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I've just submitted an update to the GRUU spec. Until it appears, you can grab a copy here: http://www.jdrosen.net/papers/draft-ietf-sip-gruu-08.txt Here are the changes: * Clarified that when a PSTN GW or media server constructs its own gruu that routes directly to itself, it still needs to include the GRUU URI param * Clarify that you should still use "supported: gruu" in dialog forming requests and responses (per rfc3261) even though you don't need that to determine if a uri is a gruu * changed the structure of the grammar, in terms of how we represent extensions to existing grammar. In particular, it now uses the =/ construct defined in RFC 4234, instead of redefining the grammar for the parameter it extends. This is a much better way of defining grammars since it allows for all of the extensions for a particular protocol to be unioned together and still accurately represent the overall grammar. * Previously, if a UA didn't insert a grid parameter into its gruu, there was no way to differentiate whether an incoming request was sent to a gruu vs. an AOR. Since there are differing authorization rules for requests sent to GRUU vs. AOR, this is problematic. Unfortunately, a problem was reported with just using grid. The problem is that the correspondent might remove the grid before sending a request to the GRUU. To fix this, the spec now says that when a home proxy receives a request sent to a gruu, and the gruu didn't have a grid param and value in it already, the proxy adds a grid parameter to the r-uri in the outgoing request, but with no value. The BNF for the grid parameter has been updated so that it can appear with no value. * for mid-dialog requests at the home proxy, if there are no route headers beyond the home proxy (i.e., pointing to an edge proxy), but there are Path values, those Path values get inserted into the request as Route headers * Security considerations section has a paragraph detailing attacks where a malicious correspondent strips or modifies grid, opaque and gruu parameters. * changed grammar for DQUOTE to LDQUOT/RDQUOT * clarified when the "gruu" URI param can be used in the contact of a REGISTER. In particular, it says that you can in fact register a gruu to an AOR, but only if that gruu is associated with a different AOR. Otherwise, you get infinite loops. Added a check in registrar processing that rejects a registration that binds a gruu to its associated AOR * clarified that a REGISTER response needs neither Require or Supported * IANA registry clarifies that gruu option tag does not imply usage of GRUU * Removed home proxy processing which was requiring it to remember, for the duration of a dialog, which contact/flow a request arrived on, or was sent to. This was previously used to help the home proxy figure out which contact to use for a GRUU when there were more than one (which happnes only in the sip-outbound case when a client registers multiple flows). Originally I thought that you needed to match up the contact in the mid-dialog request with the flow the original request came on, but after much consideration it turns out not to matter, as long as an edge proxy in sip-outbound doesn't look at the r-uri when delvering a mid-dialog request towards a UA. This is now clear in the latest sip-outbound, so we are OK. * updated references * clarified that third party registrations are permitted Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 14 23:46:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqin1-0003fw-Fu; Wed, 14 Jun 2006 23:45:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqimz-0003cA-OF for sip@ietf.org; Wed, 14 Jun 2006 23:45:01 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqimx-0003qM-B7 for sip@ietf.org; Wed, 14 Jun 2006 23:45:01 -0400 Received: from [192.168.2.104] (c-24-1-184-104.hsd1.tx.comcast.net [24.1.184.104]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5F3jRO4000459 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 14 Jun 2006 22:46:28 -0500 In-Reply-To: <475FF955A05DD411980D00508B6D5FB0132CBBDE@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB0132CBBDE@en0033exch001u.uk.lucent.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Additional uses of INFO Date: Wed, 14 Jun 2006 22:45:01 -0500 To: "Drage, Keith (Keith)" X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: Sip IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org That would be my preference. However, I'll agree that my position here is controversial. -- Dean On Jun 14, 2006, at 11:38 AM, Drage, Keith (Keith) wrote: > And in terms of the questions I asked in relation to INFO, does > this mean that you also consider that such usages should have the > same level of review as an event package (as defined in RFC 3427), > i.e. informational RFC with approval conditional on SIP expert review. > > regards > > Keith > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: 14 June 2006 17:32 >> To: Sip IETF >> Cc: Keith Drage; Jonathan Rosenberg >> Subject: Re: [Sip] Additional uses of INFO >> >> >> >> And now, for a view from the other side of the peanut gallery: >> >> I think INFO is potentially a great mechanism for exchanging >> structured data within dialog-bounded applications (perhaps not >> extensions -- I don't agree that every new application should >> require >> a new extension), but that we've harnessed the power of that >> mechanism poorly. >> >> Currently, we lack both a mechanism for describing the usage >> of INFO, >> and a mechanism for negotiating that usage between nodes. If we were >> to do anything further with it, it might make sense to emulate the >> model of event packages, which so far seems to have worked >> well enough. >> >> I proposed this in: >> >> http://www.softarmor.com/wgdb/docs/draft-willis-sip- >> infopackage-00.txt >> >> >> I personally think it's a really BAD idea to keep introducing >> new SIP >> extensions that just shuttle blobs of stuff between UAs. We >> need only >> one extension for this, and a way of cleanly declaring what >> the stuff >> is and what should be done with it and of finding out whether a >> correspondent would understand that declaration. And yes, I think >> MESSAGE is pretty much just INFO with its name changed to >> protect the >> innocent. >> >> -- >> Dean >> >> >> On Jun 14, 2006, at 11:02 AM, Jonathan Rosenberg wrote: >> >>> Well, my opinion on INFO is that its an exceptionally poor >> vehicle for >>> doing extensions. A long while back, I wrote an I-D called "INFO >>> considered harmful" which summarized my thinking on this: >>> >>> > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt >> >> The conclusion of the document is that we should limit INFO to its >> only >> defined usage - for ISUP transport - and I still think this >> conclusion makes sense. >> >> >>> My question is whether it is appropriate to provide some means of >>> clarifying other usages of the INFO method, and who should document >>> them. Should that occur in: >>> i) An update or revision to RFC 2976 ii) An update to RFC 3427 iii) >>> Anywhere else >>> regards >>> Keith >>> Keith Drage drage@lucent.com tel: +44 1793 776249 >>> _______________________________________________ Sip mailing list > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 14 23:55:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqiv9-00086F-8V; Wed, 14 Jun 2006 23:53:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqiv7-00086A-8s for sip@ietf.org; Wed, 14 Jun 2006 23:53:25 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqiv3-0005uQ-Tt for sip@ietf.org; Wed, 14 Jun 2006 23:53:25 -0400 Received: from [192.168.2.104] (c-24-1-184-104.hsd1.tx.comcast.net [24.1.184.104]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5F3snb0000504 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 14 Jun 2006 22:54:50 -0500 In-Reply-To: <449074D0.4090609@cisco.com> References: <4.3.2.7.2.20060614115113.018f6ef8@email.cisco.com> <449074D0.4090609@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Additional uses of INFO Date: Wed, 14 Jun 2006 22:53:23 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: sip@ietf.org, "James M. Polk" , "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 14, 2006, at 3:42 PM, Jonathan Rosenberg wrote: > The problem is that this 'no impact on SIP' is really quite > meaningless. Does it mean the dialog state? Does it mean that it > is always passed to a human user? Considering dialog state for > example, we have methods that have no impact on the SIP dialog > states (such as MESSAGE), yet we have chosen (correctly I think) to > define methods for them. > > The reality is that, one way or another, you need to define > specifications that allow entity A to send information to entity B > if you expect it to be processed by an automata. I'm suggesting > that, if the protocol used to transport that information is SIP, we > have several defined techniques for extensibility (new method, > body, params, etc.) which are sufficient. I see no need for a *new* > extensibility vehicle. And, as always, I see no good reason to keep changing the core protocol, adding stuff to parsers, B2BUAs, and so on, just to pass hunks of data that do not, in and of themselves, interact with the SIP state machine. MESSAGE is INFO, except that INFO is supposedly always in a dialog (it doesn't really have to be) whereas as MESSAGE could be but really sortof is not supposed to be, and MESSAGE is supposedly always presented to the user (which we know is not true in practice). Personally, I'd suggest unifying the two with a stronger explication of content-disposition and be done with it. I think the "info package" model gives us that stronger explication. Do we have to change HTTP every time somebody uses it to get a new type of image file or to build a new type of web application? Let me think . . . nope, we don't. Now, there is a reason (albeit possibly not "good") to keep extending SIP willy-illy. That is, we've already got so many half-baked, sort- of-overlapping extensions that making the protocol properly layered for transport just isn't going to happen, so we might as well keep adding stuff the way we've been doing it. It may well be true that changing horses (or extension methodology) in midstream will do more harm than good. -- 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 Jun 14 23:57:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqixT-0000hD-64; Wed, 14 Jun 2006 23:55:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqixR-0000h8-Mf for sip@ietf.org; Wed, 14 Jun 2006 23:55:49 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqixQ-0006TF-CC for sip@ietf.org; Wed, 14 Jun 2006 23:55:49 -0400 Received: from [192.168.2.104] (c-24-1-184-104.hsd1.tx.comcast.net [24.1.184.104]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5F3vGKH000527 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 14 Jun 2006 22:57:16 -0500 In-Reply-To: <4490BF1C.4050304@cisco.com> References: <4490BF1C.4050304@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] updated GRUU spec Date: Wed, 14 Jun 2006 22:55:50 -0500 To: IETF SIP List X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Keith Drage X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 14, 2006, at 8:59 PM, Jonathan Rosenberg wrote: > I've just submitted an update to the GRUU spec. Until it appears, > you can grab a copy here: > > http://www.jdrosen.net/papers/draft-ietf-sip-gruu-08.txt > > Here are the changes: > Yay! Thank you, Jonathan, for this heroic effort. Ok, kids. The log book says "GRUU is done". Could you be so kind as to read through the new draft and make sure that's right, ASAP? I'd like to know whether we have any remaining issues that justify taking agenda time in Montreal in time to get the agenda figured out. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 15 01:51:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqkj3-00032a-1k; Thu, 15 Jun 2006 01:49:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqkiR-0002VE-7C for sip@ietf.org; Thu, 15 Jun 2006 01:48:27 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqkap-0006WI-NO for sip@ietf.org; Thu, 15 Jun 2006 01:40:37 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0V004VBZC3M1@szxga01-in.huawei.com> for sip@ietf.org; Thu, 15 Jun 2006 13:31:15 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0V006AQZC30X@szxga01-in.huawei.com> for sip@ietf.org; Thu, 15 Jun 2006 13:31:15 +0800 (CST) Received: from RahulSrivastava ([10.18.8.74]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0V00COOZR4I1@szxml04-in.huawei.com> for sip@ietf.org; Thu, 15 Jun 2006 13:40:20 +0800 (CST) Date: Thu, 15 Jun 2006 10:59:40 +0530 From: rahul In-reply-to: To: sip@ietf.org Message-id: <000101c6903c$b34cf340$4a08120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Sip] RE: Sip Digest, Vol 26, Issue 25 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rahuls@huawei.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I agree with Dean. Info is a great method for reusing the protocol for propriety uses and it lets any of propriety information to flow through INFO message. I think its better if we don't start defining its uses (as mentioned in RFC) since it lets two party exchange any data. Examples could be transfer of passwords in a secured and encrypted format in mid-dialog if both party has agreed before (since Info allows any sort of payload). One of the principal advantages of SIP I feel is its usability as compared to other protocols since it allows the users to define their own uses and SIP just provides framework rather protocols governing the implementation. Though this is my opinion my question to the group is there a plan to limit the use of Info to some specific uses? (Looking from the Jonathen text as it plans to limit it to PSTN uses) .If so is there a plan to specify the messages exchanged for some of the the following scenarios: 1. To send a password securely to the SIP UAS/UAC to continue functioning. 2. To send a wav file to a prepaid IP multimedia phone so that it could be played during a mid-call when the account is about to expire. Though my knowledge in SIP is limited so please don't mind if they seem too simple to you. Thanks, Rahul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 15 04:04:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqmoF-0004Au-BH; Thu, 15 Jun 2006 04:02:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqmoD-0004Ab-6h for sip@ietf.org; Thu, 15 Jun 2006 04:02:33 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqmoB-0005I1-MU for sip@ietf.org; Thu, 15 Jun 2006 04:02:33 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5F82Qp4002799; Thu, 15 Jun 2006 11:02:28 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 11:01:51 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 11:01:51 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] outbound i-d update? Date: Thu, 15 Jun 2006 11:01:50 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F026F413A@esebe103.NOE.Nokia.com> In-Reply-To: <449090D1.7090600@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] outbound i-d update? Thread-Index: AcaQBCCImhEMUymeS1mSypuP2PKAXwATWEiw From: To: , X-OriginalArrivalTime: 15 Jun 2006 08:01:51.0330 (UTC) FILETIME=[F590DC20:01C69051] X-Spam-Score: 0.2 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: fluffy@cisco.com, sip@ietf.org, jh@tutpro.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, > and how would that knowledge be auto-configured to the client? In the next version of draft-koivusalo-sip-outbound-discovery it might be possible to introduce a configuration option to tell the UA whether it should keep one or two flows open. The spec might tell that the default value for this option SHOULD be two and that the operator/user could override this default behaviour e.g. in order to save battery or some other policy related reasons. Comments ? Regards, Erkki >-----Original Message----- >From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 >Sent: 15.June.2006 01:42 >To: Christer Holmberg (JO/LMF) >Cc: fluffy@cisco.com; sip@ietf.org; Juha Heinanen >Subject: Re: [Sip] outbound i-d update? > >The decision about how many to keep open is *policy*. It may be that=20 >there is a UA that doesn't care about reliability very much, so its=20 >policy is to keep only one connection up. (Outbound is still=20 >useful for=20 >nat traversal.) > >Both ends of the connection may have a policy about this. If so, those=20 >need to be reconciled somehow. But I don't see why that should=20 >be wired=20 >into this specification. > >IMO it would be sufficient to specify a default that SHOULD=20 >apply unless=20 >there is explicit policy to the contrary. > > Paul > >Christer Holmberg (JO/LMF) wrote: >> Hi, >>=20 >> For example, the knowledge could come to the client from the=20 >network in a REGISTER response, i.e. the network tells the=20 >client how many flows it wants to client to establish. >>=20 >> Or something like that... I haven't thought much about it,=20 >but maybe it's one possible alternative. >>=20 >> Regards, >>=20 >> Christer >> =20 >>=20 >> -----Original Message----- >> From: Juha Heinanen [mailto:jh@tutpro.com]=20 >> Sent: 14. kes=E4kuuta 2006 11:24 >> To: Christer Holmberg (JO/LMF) >> Cc: Erkki.Koivusalo@nokia.com; fluffy@cisco.com; sip@ietf.org >> Subject: RE: [Sip] outbound i-d update? >>=20 >> Christer Holmberg (JO/LMF) writes: >>=20 >> > But, I still think that the client should still be=20 >allowed to open a > flow with only a single IP address,=20 >because the fact that it receives > multiple URIs/addresses=20 >may have nothing to do with fault > tolerance. But, in this=20 >case the client must of course have knowledge > about that. >>=20 >> and how would that knowledge be auto-configured to the client? >>=20 >> -- juha >>=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 Thu Jun 15 04:12:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqmwG-000768-Ck; Thu, 15 Jun 2006 04:10:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqmwF-000751-JV for sip@ietf.org; Thu, 15 Jun 2006 04:10:51 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqmwF-0005jR-I2 for sip@ietf.org; Thu, 15 Jun 2006 04:10:51 -0400 Received: from mailm.telecomitalia.it ([217.169.121.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FqmvQ-0002rl-Kz for sip@ietf.org; Thu, 15 Jun 2006 04:10:02 -0400 thread-index: AcaQUxe6yL1kaLIlS4qRo1a6/AuV+A== Received: from ptpxch007rm001.idc.cww.telecomitalia.it ([156.54.205.169]) by mailm.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 10:09:58 +0200 Received: from ptpxch004rm001.idc.cww.telecomitalia.it ([156.54.205.166]) by ptpxch007rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 10:09:57 +0200 Received: from [163.162.113.133] ([163.162.113.133]) by ptpxch004rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 10:09:57 +0200 Message-ID: <4491158B.2080605@telecomitalia.it> Date: Thu, 15 Jun 2006 10:08:43 +0200 From: "Alberto Cuda" User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Jeroen van Bemmel" Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 Subject: Re: [Sip] Supported: in ACK References: <013101c68dab$f7e1eb20$31713b51@BEMBUSTER> <63069486-864A-4FF7-89B1-3CB7586F8687@softarmor.com> <448E6FF5.7080608@telecomitalia.it> <94B6B04F-27C9-420A-BCB8-33015EEA9A3A@softarmor.com> <448EEF82.8040905@telecomitalia.it> <001801c68f14$f35f6130$31713b51@BEMBUSTER> In-Reply-To: <001801c68f14$f35f6130$31713b51@BEMBUSTER> X-OriginalArrivalTime: 15 Jun 2006 08:09:57.0163 (UTC) FILETIME=[172517B0:01C69053] X-Spam-Score: -2.6 (--) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Sip IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0247273555==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0247273555== Content-Type: multipart/alternative; boundary="----=_NextPart_000_45F93_01C69063.DB4349E0" Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_45F93_01C69063.DB4349E0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jeroen van Bemmel wrote: > However, as to Proxy-Require in ACK to 2xx: it is needed in case a=20 > Privacy service is used with "header" Privacy. > =20 Do you mean also in cases where some failure happens? In that case, I = guess this holds true also for CANCEL & non-2xx requests... Cheers. Alberto. -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please contact us by replying to = webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- ------=_NextPart_000_45F93_01C69063.DB4349E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Jeroen van Bemmel = wrote:

> However, as to Proxy-Require in ACK to 2xx: it is needed = in case a
> Privacy service is used with "header" Privacy.
> =

Do you mean also in cases where some failure happens? In that = case, I guess
this holds true also for CANCEL & non-2xx = requests...

Cheers.
Alberto.

--------------------------------------------------------------------=
CONFIDENTIALITY=20 NOTICE
This message and its attachments are addressed solely to the=20 persons
above and may contain confidential information. If you have=20 received
the message in error, be informed that any use of the = content=20 hereof
is prohibited. Please return it immediately to the sender and=20 delete
the message. Should you have any questions, please contact us=20 by
replying to webmaster@telecomitalia.it.
        = Thank=20 you
           =             &= nbsp;           &n= bsp;   =20 www.telecomitalia.it
--------------------------------------------------------------------=
------=_NextPart_000_45F93_01C69063.DB4349E0-- --===============0247273555== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0247273555==-- From sip-bounces@ietf.org Thu Jun 15 04:13:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqmx2-0007vS-Ri; Thu, 15 Jun 2006 04:11:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqmx1-0007vA-Lm for sip@ietf.org; Thu, 15 Jun 2006 04:11:39 -0400 Received: from mailm.telecomitalia.it ([217.169.121.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqmx0-00061I-9U for sip@ietf.org; Thu, 15 Jun 2006 04:11:39 -0400 thread-index: AcaQU1Ksbx6nx3hwRFWKwQpx67DE9w== Received: from ptpxch007rm001.idc.cww.telecomitalia.it ([156.54.205.169]) by mailm.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 10:11:36 +0200 Received: from ptpxch004rm001.idc.cww.telecomitalia.it ([156.54.205.166]) by ptpxch007rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 10:11:35 +0200 Received: from [163.162.113.133] ([163.162.113.133]) by ptpxch004rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 10:11:35 +0200 Message-ID: <449115ED.7060908@telecomitalia.it> Date: Thu, 15 Jun 2006 10:10:21 +0200 From: "Alberto Cuda" User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Alberto Cuda" Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 Subject: Re: [Sip] Supported: in ACK References: <013101c68dab$f7e1eb20$31713b51@BEMBUSTER> <63069486-864A-4FF7-89B1-3CB7586F8687@softarmor.com> <448E6FF5.7080608@telecomitalia.it> <94B6B04F-27C9-420A-BCB8-33015EEA9A3A@softarmor.com> <448EEF82.8040905@telecomitalia.it> <001801c68f14$f35f6130$31713b51@BEMBUSTER> <4491158B.2080605@telecomitalia.it> In-Reply-To: <4491158B.2080605@telecomitalia.it> X-OriginalArrivalTime: 15 Jun 2006 08:11:35.0412 (UTC) FILETIME=[51B4B340:01C69053] X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Sip IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1987330870==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1987330870== Content-Type: multipart/alternative; boundary="----=_NextPart_000_46160_01C69064.1634DB90" Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_46160_01C69064.1634DB90 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Alberto Cuda wrote: > Jeroen van Bemmel wrote: > >> However, as to Proxy-Require in ACK to 2xx: it is needed in case a=20 >> Privacy service is used with "header" Privacy. >> =20 > > > Do you mean also in cases where some failure happens? In that case, I=20 > guess > this holds true also for CANCEL & non-2xx requests... (Of course I meant non-2xx ACK requests). -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please contact us by replying to = webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- ------=_NextPart_000_46160_01C69064.1634DB90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Alberto Cuda = wrote:

> Jeroen van Bemmel wrote:
>
>> However, as to = Proxy-Require in ACK to 2xx: it is needed in case a
>> Privacy = service is used with "header" Privacy.
>>
>
>
> Do you = mean also in cases where some failure happens? In that case, I
> = guess
> this holds true also for CANCEL & non-2xx = requests...

(Of course I meant non-2xx ACK = requests).


--------------------------------------------------------------------=
CONFIDENTIALITY=20 NOTICE
This message and its attachments are addressed solely to the=20 persons
above and may contain confidential information. If you have=20 received
the message in error, be informed that any use of the = content=20 hereof
is prohibited. Please return it immediately to the sender and=20 delete
the message. Should you have any questions, please contact us=20 by
replying to webmaster@telecomitalia.it.
        = Thank=20 you
           =             &= nbsp;           &n= bsp;   =20 www.telecomitalia.it
--------------------------------------------------------------------=
------=_NextPart_000_46160_01C69064.1634DB90-- --===============1987330870== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1987330870==-- From sip-bounces@ietf.org Thu Jun 15 04:20:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqn3a-0003AO-RR; Thu, 15 Jun 2006 04:18:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqn3Z-000393-PS for sip@ietf.org; Thu, 15 Jun 2006 04:18:25 -0400 Received: from maild.telecomitalia.it ([156.54.233.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqn3X-0006GE-GA for sip@ietf.org; Thu, 15 Jun 2006 04:18:25 -0400 Thread-Index: AcaQVEPiT4YhonE2ThKyX+K9tKp/PA== Received: from ptpxch007ba020.idc.cww.telecomitalia.it ([156.54.240.50]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 10:18:21 +0200 Received: from PTPXCH029BA020.idc.cww.telecomitalia.it ([156.54.240.46]) by ptpxch007ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 10:18:21 +0200 Received: from [163.162.113.133] ([163.162.113.133]) by PTPXCH029BA020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 10:18:20 +0200 Message-ID: <44911782.40506@telecomitalia.it> Date: Thu, 15 Jun 2006 10:17:06 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 Content-Class: urn:content-classes:message Importance: normal Priority: normal From: "Alberto Cuda" User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Dale R. Worley" Subject: Re: [Sip] Max-Forwards in ACK for non-2xx References: <001a01c68f7b$f6547f80$31713b51@BEMBUSTER> <1150310075.25224.20.camel@niagra.pingtel.com> In-Reply-To: <1150310075.25224.20.camel@niagra.pingtel.com> X-OriginalArrivalTime: 15 Jun 2006 08:18:20.0455 (UTC) FILETIME=[43215B70:01C69054] X-Spam-Score: 0.1 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1893285607==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1893285607== Content-Type: multipart/alternative; boundary="----=_NextPart_000_1E9E71_01C69065.076BCDC0" Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_1E9E71_01C69065.076BCDC0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dale R. Worley wrote: >On Wed, 2006-06-14 at 08:29 +0200, Jeroen van Bemmel wrote: > =20 > >>For this scenario, it again seems necessary that a stateless proxy >>stops non-2xx ACKs for responses it generated. Moreover, perhaps >>section 17.1.1.3 should be updated to say that the Max-Forwards value >>should be the same as was used for the INVITE that was forwarded. The >>ACK should not propagate further than the INVITE >> =20 >> > >This seems to be a particularly nasty case of a general truth: if a SIP >agent generates a response, it really can't do so statelessly, as it is >acting more like a UA than a proxy, in that it is creating a to-tag, >etc. > =20 > Why does it need to be stateful? I suppose that if it uses some hash on invariant fields (like the top Via header), it does not need to be more stateful than when it is forwarding a retransmission and has to generate the same branch tag... Cheers. Alberto. -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please contact us by replying to = webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- ------=_NextPart_000_1E9E71_01C69065.076BCDC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Dale R. Worley = wrote:

>On Wed, 2006-06-14 at 08:29 +0200, Jeroen van Bemmel = wrote:
>
>
>>For this scenario, it again seems necessary that = a stateless proxy
>>stops non-2xx ACKs for responses it generated. = Moreover, perhaps
>>section 17.1.1.3 should be updated to say that = the Max-Forwards value
>>should be the same as was used for the = INVITE that was forwarded. The
>>ACK should not propagate further = than the INVITE
>>
>>
>
>This seems to be a particularly = nasty case of a general truth: if a SIP
>agent generates a response, = it really can't do so statelessly, as it is
>acting more like a UA = than a proxy, in that it is creating a to-tag,
>etc.
> =
>
Why does it need to be stateful? I suppose that if it uses = some
hash on invariant fields (like the top Via header), it does = not
need to be more stateful than when it is forwarding = a
retransmission and has to generate the same branch tag...

= Cheers.
Alberto.

--------------------------------------------------------------------=
CONFIDENTIALITY=20 NOTICE
This message and its attachments are addressed solely to the=20 persons
above and may contain confidential information. If you have=20 received
the message in error, be informed that any use of the = content=20 hereof
is prohibited. Please return it immediately to the sender and=20 delete
the message. Should you have any questions, please contact us=20 by
replying to webmaster@telecomitalia.it.
        = Thank=20 you
           =             &= nbsp;           &n= bsp;   =20 www.telecomitalia.it
--------------------------------------------------------------------=
------=_NextPart_000_1E9E71_01C69065.076BCDC0-- --===============1893285607== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1893285607==-- From sip-bounces@ietf.org Thu Jun 15 04:24:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqn7y-0006FH-77; Thu, 15 Jun 2006 04:22:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqn7w-0006FC-2M for sip@ietf.org; Thu, 15 Jun 2006 04:22:56 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqn7t-0006rr-Ev for sip@ietf.org; Thu, 15 Jun 2006 04:22:56 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DAF2A5E0001; Thu, 15 Jun 2006 10:22:52 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 10:22:47 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 10:22:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] outbound i-d update? Date: Thu, 15 Jun 2006 10:22:46 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F10D3@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] outbound i-d update? Thread-Index: AcaQA9C9x9pX+geOQHi2kAyzT0ydpwAUJHow From: "Christer Holmberg \(JO/LMF\)" To: "Paul Kyzivat" X-OriginalArrivalTime: 15 Jun 2006 08:22:47.0281 (UTC) FILETIME=[E22BC610:01C69054] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: fluffy@cisco.com, 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: , Errors-To: sip-bounces@ietf.org Hi,=20 >The decision about how many to keep open is *policy*. It may be that = there is a UA that doesn't care about reliability=20 >very much, so its policy is to keep only one connection up. (Outbound = is still useful for nat traversal.) Yes, but the policy could also be in the network, because the UA may = simply not know whether one or multiple flows are required in order to = achieve reliability. Like I said earlier, there may be systems where you = can achieve reliability with a single IP address. >Both ends of the connection may have a policy about this. If so, those = need to be reconciled somehow. But I don't see why=20 >that should be wired into this specification. > >IMO it would be sufficient to specify a default that SHOULD apply = unless there is explicit policy to the contrary. I have nothing against that. But, I still think it would be useful if = the network could tell the client how many flows it wants to client to = establish (then it is an implementation issue what happens if the client = does not establish the numbers of flows it's asked to). Regards, Christer Christer Holmberg (JO/LMF) wrote: > Hi, >=20 > For example, the knowledge could come to the client from the network = in a REGISTER response, i.e. the network tells the client how many flows = it wants to client to establish. >=20 > Or something like that... I haven't thought much about it, but maybe = it's one possible alternative. >=20 > Regards, >=20 > Christer > =20 >=20 > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com] > Sent: 14. kes=E4kuuta 2006 11:24 > To: Christer Holmberg (JO/LMF) > Cc: Erkki.Koivusalo@nokia.com; fluffy@cisco.com; sip@ietf.org > Subject: RE: [Sip] outbound i-d update? >=20 > Christer Holmberg (JO/LMF) writes: >=20 > > But, I still think that the client should still be allowed to open = a > flow with only a single IP address, because the fact that it = receives > multiple URIs/addresses may have nothing to do with fault > = tolerance. But, in this case the client must of course have knowledge > = about that. >=20 > and how would that knowledge be auto-configured to the client? >=20 > -- juha >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 15 04:27:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqnB1-0001Nb-TD; Thu, 15 Jun 2006 04:26:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqnB0-0001MK-2B for sip@ietf.org; Thu, 15 Jun 2006 04:26:06 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqnAx-000717-Ay for sip@ietf.org; Thu, 15 Jun 2006 04:26:06 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 052B74F0077; Thu, 15 Jun 2006 10:25:24 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 10:25:23 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 10:25:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] outbound i-d update? Date: Thu, 15 Jun 2006 10:25:22 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F10D4@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] outbound i-d update? Thread-Index: AcaQBCCImhEMUymeS1mSypuP2PKAXwATWEiwAADccGA= From: "Christer Holmberg \(JO/LMF\)" To: , X-OriginalArrivalTime: 15 Jun 2006 08:25:23.0102 (UTC) FILETIME=[3F0C2BE0:01C69055] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: fluffy@cisco.com, sip@ietf.org, jh@tutpro.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>and how would that knowledge be auto-configured to the client? >In the next version of draft-koivusalo-sip-outbound-discovery >it might be possible to introduce a configuration option to tell the UA = whether it should keep one or two flows open. The=20 >spec might tell that the default value for this option SHOULD be two = and that the operator/user could override this=20 >default behaviour e.g. in order to save battery or some other policy = related reasons. > >Comments ? That sounds ok. But, as I've said, I think it would be useful if the = network could indicate (e.g. In the first REGISTER response) how many = flows it wants the client to establish. Because, the numbers of flows = wanted may not always be static, so having a UA configuration parameter = as the only option may not always be very feasible. Regards, Christer >-----Original Message----- >From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >Sent: 15.June.2006 01:42 >To: Christer Holmberg (JO/LMF) >Cc: fluffy@cisco.com; sip@ietf.org; Juha Heinanen >Subject: Re: [Sip] outbound i-d update? > >The decision about how many to keep open is *policy*. It may be that=20 >there is a UA that doesn't care about reliability very much, so its=20 >policy is to keep only one connection up. (Outbound is still useful for = >nat traversal.) > >Both ends of the connection may have a policy about this. If so, those=20 >need to be reconciled somehow. But I don't see why that should be wired = >into this specification. > >IMO it would be sufficient to specify a default that SHOULD apply=20 >unless there is explicit policy to the contrary. > > Paul > >Christer Holmberg (JO/LMF) wrote: >> Hi, >>=20 >> For example, the knowledge could come to the client from the >network in a REGISTER response, i.e. the network tells the client how=20 >many flows it wants to client to establish. >>=20 >> Or something like that... I haven't thought much about it, >but maybe it's one possible alternative. >>=20 >> Regards, >>=20 >> Christer >> =20 >>=20 >> -----Original Message----- >> From: Juha Heinanen [mailto:jh@tutpro.com] >> Sent: 14. kes=E4kuuta 2006 11:24 >> To: Christer Holmberg (JO/LMF) >> Cc: Erkki.Koivusalo@nokia.com; fluffy@cisco.com; sip@ietf.org >> Subject: RE: [Sip] outbound i-d update? >>=20 >> Christer Holmberg (JO/LMF) writes: >>=20 >> > But, I still think that the client should still be >allowed to open a > flow with only a single IP address, because the=20 >fact that it receives > multiple URIs/addresses may have nothing to do = >with fault > tolerance. But, in this case the client must of course=20 >have knowledge > about that. >>=20 >> and how would that knowledge be auto-configured to the client? >>=20 >> -- juha >>=20 >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use=20 >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 >> sipping@ietf.org for new developments on the application of sip >>=20 > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use=20 >sip-implementors@cs.columbia.edu for questions on current sip Use=20 >sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 15 04:33:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqnG9-0004UM-1W; Thu, 15 Jun 2006 04:31:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqnG6-0004UD-Q3 for sip@ietf.org; Thu, 15 Jun 2006 04:31:22 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqnG5-0007JY-8E for sip@ietf.org; Thu, 15 Jun 2006 04:31:22 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AC4CA500003; Thu, 15 Jun 2006 10:31:20 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 10:31:20 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 10:31:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] outbound i-d update? Date: Thu, 15 Jun 2006 10:31:19 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F10D5@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] outbound i-d update? Thread-Index: AcaQSWmRP4Grx9hvS3CJB/10gUf9nwAC9sGQ From: "Christer Holmberg \(JO/LMF\)" To: "Juha Heinanen" , "Paul Kyzivat" X-OriginalArrivalTime: 15 Jun 2006 08:31:20.0205 (UTC) FILETIME=[13E5C3D0:01C69056] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: fluffy@cisco.com, sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>Both ends of the connection may have a policy about this. If so, those > need to be reconciled somehow. But I don't see=20 >>why that should be wired into this specification. >if you don't wire it in the spec that UA must keep more than flow open when there is more than one outbound proxy=20 >defined, then it will VERY likely happen that UA vendors make outbound implementations that are NOT capable of keeping=20 >more than one flow open and still they can claim outbound compliance. There are a number of 100rel compliant products out there - do they all support offer/answer with PRACK? :) Seriously, I think the make-sure-a-product-is-compliant issue should be solved in another way. The only thing we can say in the spec is that a client must be ABLE to establish more than one flow. >>IMO it would be sufficient to specify a default that SHOULD apply unless > there is explicit policy to the contrary. >that would be acceptable if EVERY implementation that claims outbound compatibility IS CAPABLE of keeping more than flow=20 >open and will do so unless manually overridden. wording of this must be made very clear in the spec. Yes. >>Outbound is still useful for nat traversal.) >is not true, because as i have told on this list at least four times already, NAT traversal can and is successfully=20 >handled from proxy's end. so the only REAL added value of outbound is reliability. Outbound, using STUN for keep-alives, also allows you to detect if a NAT has rebooted, which is also one type of reliability. But, you don't need multiple flows for that. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 15 04:59:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqnfZ-0001ra-0t; Thu, 15 Jun 2006 04:57:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqnfX-0001rU-KR for sip@ietf.org; Thu, 15 Jun 2006 04:57:39 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqnfW-0003Jd-9K for sip@ietf.org; Thu, 15 Jun 2006 04:57:39 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 1FDD013F91D; Thu, 15 Jun 2006 11:57:34 +0300 (EEST) Received: from rautu (eukaryote235.gprs.dnafinland.fi [62.78.106.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 7A8FD13F917; Thu, 15 Jun 2006 11:57:22 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id E7CE2F03C1; Thu, 15 Jun 2006 11:57:31 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17553.8443.528379.235814@rautu.tutpro.com> Date: Thu, 15 Jun 2006 11:57:31 +0300 From: Juha Heinanen To: Subject: RE: [Sip] outbound i-d update? In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F026F413A@esebe103.NOE.Nokia.com> References: <449090D1.7090600@cisco.com> <8B1D53AEF7B03449A6D3771B3B7F850F026F413A@esebe103.NOE.Nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: fluffy@cisco.com, sip@ietf.org, pkyzivat@cisco.com, christer.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Erkki.Koivusalo@nokia.com writes: > In the next version of draft-koivusalo-sip-outbound-discovery > it might be possible to introduce a configuration option to tell > the UA whether it should keep one or two flows open. The spec > might tell that the default value for this option SHOULD be two > and that the operator/user could override this default behaviour > e.g. in order to save battery or some other policy related reasons. > > Comments ? that is fine with me as long as it is NOT POSSIBLE to build a outbound compliant UA that is able to keep only one flow open. -- 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 Jun 15 05:58:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqoav-0007ju-JR; Thu, 15 Jun 2006 05:56:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqoau-0007jg-0t for sip@ietf.org; Thu, 15 Jun 2006 05:56:56 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqmYd-0001HZ-Rk for sip@ietf.org; Thu, 15 Jun 2006 03:46:27 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FqlqA-0001gl-JL for sip@ietf.org; Thu, 15 Jun 2006 03:00:31 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 5715413F914; Thu, 15 Jun 2006 10:00:25 +0300 (EEST) Received: from rautu (eukaryote235.gprs.dnafinland.fi [62.78.106.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 5F80E13F911; Thu, 15 Jun 2006 10:00:04 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id B5F76F03C1; Thu, 15 Jun 2006 10:00:08 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17553.1400.633975.689895@rautu.tutpro.com> Date: Thu, 15 Jun 2006 10:00:08 +0300 From: Juha Heinanen To: Paul Kyzivat Subject: Re: [Sip] outbound i-d update? In-Reply-To: <449090D1.7090600@cisco.com> References: <5EB80D22825EEE42872083AD5BFFB594017F10AF@esealmw113.eemea.ericsson.se> <449090D1.7090600@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: -2.6 (--) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: fluffy@cisco.com, sip@ietf.org, "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul Kyzivat writes: > Both ends of the connection may have a policy about this. If so, those > need to be reconciled somehow. But I don't see why that should be wired > into this specification. if you don't wire it in the spec that UA must keep more than flow open when there is more than one outbound proxy defined, then it will VERY likely happen that UA vendors make outbound implementations that are NOT capable of keeping more than one flow open and still they can claim outbound compliance. > IMO it would be sufficient to specify a default that SHOULD apply unless > there is explicit policy to the contrary. that would be acceptable if EVERY implementation that claims outbound compatibility IS CAPABLE of keeping more than flow open and will do so unless manually overridden. wording of this must be made very clear in the spec. your note that > (Outbound is still useful for nat traversal.) is not true, because as i have told on this list at least four times already, NAT traversal can and is successfully handled from proxy's end. so the only REAL added value of outbound is reliability. -- 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 Jun 15 08:43:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqrAd-00068d-8Y; Thu, 15 Jun 2006 08:41:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqrAb-00068T-RZ for sip@ietf.org; Thu, 15 Jun 2006 08:41:57 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqrAa-0006iW-Kg for sip@ietf.org; Thu, 15 Jun 2006 08:41:57 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 4B3136C017 for ; Thu, 15 Jun 2006 08:41:56 -0400 (EDT) Subject: Re: [Sip] Max-Forwards in ACK for non-2xx From: "Dale R. Worley" To: Sip In-Reply-To: <44911782.40506@telecomitalia.it> References: <001a01c68f7b$f6547f80$31713b51@BEMBUSTER> <1150310075.25224.20.camel@niagra.pingtel.com> <44911782.40506@telecomitalia.it> Content-Type: text/plain Date: Thu, 15 Jun 2006 08:41:55 -0400 Message-Id: <1150375316.22193.6.camel@niagra.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Thu, 2006-06-15 at 10:17 +0200, Alberto Cuda wrote: > Why does it need to be stateful? I suppose that if it uses some > hash on invariant fields (like the top Via header), it does not > need to be more stateful than when it is forwarding a > retransmission and has to generate the same branch tag... Yes, that's true. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 15 09:04:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqrUX-0000Ds-Sc; Thu, 15 Jun 2006 09:02:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqrUW-0000Dm-By for sip@ietf.org; Thu, 15 Jun 2006 09:02:32 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqrUU-0002LC-Vy for sip@ietf.org; Thu, 15 Jun 2006 09:02:32 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 5C0756C017 for ; Thu, 15 Jun 2006 09:02:28 -0400 (EDT) Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt From: "Dale R. Worley" To: Sip In-Reply-To: <1149789834.4721.108.camel@localhost.localdomain> References: <475FF955A05DD411980D00508B6D5FB0132CB58A@en0033exch001u.uk.lucent.com> <1149789834.4721.108.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 15 Jun 2006 09:02:28 -0400 Message-Id: <1150376548.22193.12.camel@niagra.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Thu, 2006-06-08 at 14:03 -0400, Scott Lawrence wrote: > Arguably, this could call for actually registering a code in the 39x > range; if the WG thinks that's better, I can add an IANA Considerations > section to do that. That seems like a good idea. Since there is hope that an automaton (traceroute-like program) will be able to interpret the responses, a known warning code would be a label that the message/sipfrag body part is one of these diagnostic messages. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 15 09:08:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqrYi-0001PJ-7Y; Thu, 15 Jun 2006 09:06:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqrYg-0001In-Rm for sip@ietf.org; Thu, 15 Jun 2006 09:06:50 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqrYf-0002Xq-Az for sip@ietf.org; Thu, 15 Jun 2006 09:06:50 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 238556C017 for ; Thu, 15 Jun 2006 09:06:48 -0400 (EDT) Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt From: "Dale R. Worley" To: Sip In-Reply-To: <475FF955A05DD411980D00508B6D5FB0130F705F@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB0130F705F@en0033exch001u.uk.lucent.com> Content-Type: text/plain Date: Thu, 15 Jun 2006 09:06:47 -0400 Message-Id: <1150376807.22193.14.camel@niagra.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Wed, 2006-06-07 at 11:39 +0100, Drage, Keith (Keith) wrote: > c) In the Abstract delete the paragraph relating to "Comments are > solicited..." It's an I-D after all. But after the document becomes a Request For Comments, comments on it will no longer be solicited! ;-) Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 15 09:56:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqsJP-0007ch-7P; Thu, 15 Jun 2006 09:55:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqsJO-0007cX-1C for sip@ietf.org; Thu, 15 Jun 2006 09:55:06 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqsJM-0000Ih-KK for sip@ietf.org; Thu, 15 Jun 2006 09:55:06 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 15 Jun 2006 06:55:03 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,137,1149490800"; d="scan'208"; a="29578187:sNHT24112448" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5FDsxo2028393; Thu, 15 Jun 2006 09:55:02 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Jun 2006 09:54:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] outbound i-d update? Date: Thu, 15 Jun 2006 09:54:54 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30197BBD6@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] outbound i-d update? Thread-Index: AcaQBCCImhEMUymeS1mSypuP2PKAXwATWEiwAADccGAAC3U5EA== From: "Michael Hammer \(mhammer\)" To: "Christer Holmberg \(JO/LMF\)" , , "Paul Kyzivat \(pkyzivat\)" X-OriginalArrivalTime: 15 Jun 2006 13:54:55.0498 (UTC) FILETIME=[48505EA0:01C69083] X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: "Cullen Jennings \(fluffy\)" , sip@ietf.org, jh@tutpro.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org So, keeping score: Client must be capable of establishing a minimum of 2 flows. Network must provide max-flows in Register response. Client must not exceed max-flows when establishing flows. Client should attempt to equal max-flows if terminal capabilities = allows. Did I miss anything? Mike > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Sent: Thursday, June 15, 2006 4:25 AM > To: Erkki.Koivusalo@nokia.com; Paul Kyzivat (pkyzivat) > Cc: Cullen Jennings (fluffy); sip@ietf.org; jh@tutpro.com > Subject: RE: [Sip] outbound i-d update? >=20 >=20 > Hi,=20 >=20 > >>and how would that knowledge be auto-configured to the client? > >In the next version of draft-koivusalo-sip-outbound-discovery > >it might be possible to introduce a configuration option to=20 > tell the UA=20 > >whether it should keep one or two flows open. The spec might=20 > tell that=20 > >the default value for this option SHOULD be two and that the=20 > operator/user could override this default behaviour e.g. in=20 > order to save battery or some other policy related reasons. > > > >Comments ? >=20 > That sounds ok. But, as I've said, I think it would be useful=20 > if the network could indicate (e.g. In the first REGISTER=20 > response) how many flows it wants the client to establish.=20 > Because, the numbers of flows wanted may not always be=20 > static, so having a UA configuration parameter as the only=20 > option may not always be very feasible. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > >-----Original Message----- > >From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > >Sent: 15.June.2006 01:42 > >To: Christer Holmberg (JO/LMF) > >Cc: fluffy@cisco.com; sip@ietf.org; Juha Heinanen > >Subject: Re: [Sip] outbound i-d update? > > > >The decision about how many to keep open is *policy*. It may be that=20 > >there is a UA that doesn't care about reliability very much, so its=20 > >policy is to keep only one connection up. (Outbound is still=20 > useful for=20 > >nat traversal.) > > > >Both ends of the connection may have a policy about this. If=20 > so, those=20 > >need to be reconciled somehow. But I don't see why that=20 > should be wired=20 > >into this specification. > > > >IMO it would be sufficient to specify a default that SHOULD apply=20 > >unless there is explicit policy to the contrary. > > > > Paul > > > >Christer Holmberg (JO/LMF) wrote: > >> Hi, > >>=20 > >> For example, the knowledge could come to the client from the > >network in a REGISTER response, i.e. the network tells the=20 > client how=20 > >many flows it wants to client to establish. > >>=20 > >> Or something like that... I haven't thought much about it, > >but maybe it's one possible alternative. > >>=20 > >> Regards, > >>=20 > >> Christer > >> =20 > >>=20 > >> -----Original Message----- > >> From: Juha Heinanen [mailto:jh@tutpro.com] > >> Sent: 14. kes=E4kuuta 2006 11:24 > >> To: Christer Holmberg (JO/LMF) > >> Cc: Erkki.Koivusalo@nokia.com; fluffy@cisco.com; sip@ietf.org > >> Subject: RE: [Sip] outbound i-d update? > >>=20 > >> Christer Holmberg (JO/LMF) writes: > >>=20 > >> > But, I still think that the client should still be > >allowed to open a > flow with only a single IP address, because the=20 > >fact that it receives > multiple URIs/addresses may have=20 > nothing to do=20 > >with fault > tolerance. But, in this case the client must of course=20 > >have knowledge > about that. > >>=20 > >> and how would that knowledge be auto-configured to the client? > >>=20 > >> -- juha > >>=20 > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >>=20 > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol Use=20 > >sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >sipping@ietf.org for new developments on the application of sip > > >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 15 09:59:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqsMA-0000nJ-OK; Thu, 15 Jun 2006 09:57:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqsM9-0000nB-54 for sip@ietf.org; Thu, 15 Jun 2006 09:57:57 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqsM7-0000Up-6G for sip@ietf.org; Thu, 15 Jun 2006 09:57:57 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 85DFB4F0001; Thu, 15 Jun 2006 15:57:54 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 15:57:54 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 15:57:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] outbound i-d update? Date: Thu, 15 Jun 2006 15:57:53 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F10F2@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] outbound i-d update? Thread-Index: AcaQBCCImhEMUymeS1mSypuP2PKAXwATWEiwAADccGAAC3U5EAAAJ9zQ From: "Christer Holmberg \(JO/LMF\)" To: "Michael Hammer \(mhammer\)" , , "Paul Kyzivat \(pkyzivat\)" X-OriginalArrivalTime: 15 Jun 2006 13:57:54.0276 (UTC) FILETIME=[B2DFBA40:01C69083] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: "Cullen Jennings \(fluffy\)" , sip@ietf.org, jh@tutpro.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Mike, We can discuss whether the network MUST provide max-flows, or if = MAY/SHOULD/RECOMMENDED is enough (in which case the terminal decideds = how many flows it creates, based on configuration or a default value), = but otherwise what you say sounds like my proposal. Regards, Christer=20 -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: 15. kes=E4kuuta 2006 16:55 To: Christer Holmberg (JO/LMF); Erkki.Koivusalo@nokia.com; Paul Kyzivat = (pkyzivat) Cc: Cullen Jennings (fluffy); sip@ietf.org; jh@tutpro.com Subject: RE: [Sip] outbound i-d update? So, keeping score: Client must be capable of establishing a minimum of 2 flows. Network must provide max-flows in Register response. Client must not exceed max-flows when establishing flows. Client should attempt to equal max-flows if terminal capabilities = allows. Did I miss anything? Mike > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, June 15, 2006 4:25 AM > To: Erkki.Koivusalo@nokia.com; Paul Kyzivat (pkyzivat) > Cc: Cullen Jennings (fluffy); sip@ietf.org; jh@tutpro.com > Subject: RE: [Sip] outbound i-d update? >=20 >=20 > Hi, >=20 > >>and how would that knowledge be auto-configured to the client? > >In the next version of draft-koivusalo-sip-outbound-discovery > >it might be possible to introduce a configuration option to > tell the UA > >whether it should keep one or two flows open. The spec might > tell that > >the default value for this option SHOULD be two and that the > operator/user could override this default behaviour e.g. in order to=20 > save battery or some other policy related reasons. > > > >Comments ? >=20 > That sounds ok. But, as I've said, I think it would be useful if the=20 > network could indicate (e.g. In the first REGISTER > response) how many flows it wants the client to establish.=20 > Because, the numbers of flows wanted may not always be static, so=20 > having a UA configuration parameter as the only option may not always=20 > be very feasible. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > >-----Original Message----- > >From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > >Sent: 15.June.2006 01:42 > >To: Christer Holmberg (JO/LMF) > >Cc: fluffy@cisco.com; sip@ietf.org; Juha Heinanen > >Subject: Re: [Sip] outbound i-d update? > > > >The decision about how many to keep open is *policy*. It may be that=20 > >there is a UA that doesn't care about reliability very much, so its=20 > >policy is to keep only one connection up. (Outbound is still > useful for > >nat traversal.) > > > >Both ends of the connection may have a policy about this. If > so, those > >need to be reconciled somehow. But I don't see why that > should be wired > >into this specification. > > > >IMO it would be sufficient to specify a default that SHOULD apply=20 > >unless there is explicit policy to the contrary. > > > > Paul > > > >Christer Holmberg (JO/LMF) wrote: > >> Hi, > >>=20 > >> For example, the knowledge could come to the client from the > >network in a REGISTER response, i.e. the network tells the > client how > >many flows it wants to client to establish. > >>=20 > >> Or something like that... I haven't thought much about it, > >but maybe it's one possible alternative. > >>=20 > >> Regards, > >>=20 > >> Christer > >> =20 > >>=20 > >> -----Original Message----- > >> From: Juha Heinanen [mailto:jh@tutpro.com] > >> Sent: 14. kes=E4kuuta 2006 11:24 > >> To: Christer Holmberg (JO/LMF) > >> Cc: Erkki.Koivusalo@nokia.com; fluffy@cisco.com; sip@ietf.org > >> Subject: RE: [Sip] outbound i-d update? > >>=20 > >> Christer Holmberg (JO/LMF) writes: > >>=20 > >> > But, I still think that the client should still be > >allowed to open a > flow with only a single IP address, because the=20 > >fact that it receives > multiple URIs/addresses may have > nothing to do > >with fault > tolerance. But, in this case the client must of course=20 > >have knowledge > about that. > >>=20 > >> and how would that knowledge be auto-configured to the client? > >>=20 > >> -- juha > >>=20 > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >>=20 > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol Use=20 > >sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >sipping@ietf.org for new developments on the application of sip > > >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 15 10:00:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqsMd-0001P2-OW; Thu, 15 Jun 2006 09:58:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqsMc-0001Ox-CG for sip@ietf.org; Thu, 15 Jun 2006 09:58:26 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqsMb-0000W6-1O for sip@ietf.org; Thu, 15 Jun 2006 09:58:26 -0400 Received: by tutpro.com (Postfix, from userid 65534) id DE65A13F917; Thu, 15 Jun 2006 16:58:20 +0300 (EEST) Received: from rautu (eukaryote235.gprs.dnafinland.fi [62.78.106.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 2ED0A13F91C; Thu, 15 Jun 2006 16:58:13 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id A08F2F03C1; Thu, 15 Jun 2006 16:58:25 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17553.26497.609527.346803@rautu.tutpro.com> Date: Thu, 15 Jun 2006 16:58:25 +0300 From: Juha Heinanen To: "Michael Hammer (mhammer)" Subject: RE: [Sip] outbound i-d update? In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E30197BBD6@xmb-rtp-20b.amer.cisco.com> References: <072C5B76F7CEAB488172C6F64B30B5E30197BBD6@xmb-rtp-20b.amer.cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: "Cullen Jennings \(fluffy\)" , sip@ietf.org, "Paul Kyzivat \(pkyzivat\)" , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Michael Hammer (mhammer) writes: > Client must be capable of establishing a minimum of 2 flows. > > Network must provide max-flows in Register response. > > Client must not exceed max-flows when establishing flows. > > Client should attempt to equal max-flows if terminal capabilities allows. > > Did I miss anything? ok with me, -- 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 Jun 15 11:57:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FquBs-00018A-Rz; Thu, 15 Jun 2006 11:55:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FquBo-00014b-Sb for sip@ietf.org; Thu, 15 Jun 2006 11:55:24 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqu79-0003mb-UE for sip@ietf.org; Thu, 15 Jun 2006 11:50:37 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 15 Jun 2006 08:50:35 -0700 X-IronPort-AV: i="4.06,137,1149490800"; d="scan'208"; a="1826264640:sNHT32927552" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k5FFoZTk017844; Thu, 15 Jun 2006 08:50:35 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5FFoXcR023906; Thu, 15 Jun 2006 08:50:34 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Jun 2006 11:50:34 -0400 Received: from [161.44.55.132] ([161.44.55.132]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Jun 2006 11:50:33 -0400 Message-ID: <449181C9.70803@cisco.com> Date: Thu, 15 Jun 2006 11:50:33 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Supported: in ACK References: <013101c68dab$f7e1eb20$31713b51@BEMBUSTER> <63069486-864A-4FF7-89B1-3CB7586F8687@softarmor.com> In-Reply-To: <63069486-864A-4FF7-89B1-3CB7586F8687@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jun 2006 15:50:33.0645 (UTC) FILETIME=[6FC595D0:01C69093] DKIM-Signature: a=rsa-sha1; q=dns; l=2310; t=1150386635; x=1151250635; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20Supported=3A=20in=20ACK; X=v=3Dcisco.com=3B=20h=3DBca13JNiSygjHNxR3uCTUvMchAk=3D; b=hcbdACoTu+7e4WmlXn5JaLr7BRk+4FqHVELWRP5zUojUSn0YzolFULK6/Sbqw7DQWQvCSWHs aDheNemaSJux8knIt1/6H/ZLCzIyzfD/2yYD7ZLQ2JsdEj61U5rpB31/; Authentication-Results: sj-dkim-5.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Sip IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Dean Willis wrote: > > On Jun 11, 2006, at 6:08 PM, Jeroen van Bemmel wrote: > >> Dean, >> >> Before answering, let's discuss the question: should it be split into >> >> 1) Can/should you include Supported in ACK > > > Ok, I agree those are separate questions. Yes, and you need to further split it into ACK for 2xx and non-2xx. In both cases though, Supported makes no sense since the purpose would be to tell the UAS that it can apply certain processing to the response. Since there is no response, this is moot. > >> 2) Can/should you include (Proxy-)Require in ACK > > > I don't think you can, since a proxy cannot reject an ACK that has a > Proxy-Require: that is not supported by the proxy. Not true. Let us consider ACK-2xx and ACK-non-2xx separately. For non-2xx, Section 8.2.2.3 has the definitive word on this, and it says: Note that Require and Proxy-Require MUST NOT be used in a SIP CANCEL request, or in an ACK request sent for a non-2xx response. These header fields MUST be ignored if they are present in these requests. However, for ACK-2xx, it says this: An ACK request for a 2xx response MUST contain only those Require and Proxy-Require values that were present in the initial request. It may very well be the case that an ACK cannot be succesfully processed unless a particular extension is understood, in which case Require/Proxy-Require make sense. But what about it being rejected? Well, it won't ever need to be, because the ACK-2xx cannot contain anything that wasn't in the INVITE. So, if a particular option tag was in the INVITE, and not supported by the UAS, that would have produced a 420 and an ACK-non-2xx without any Require. However, if the option tag was supported, there would have been a 200 OK followed by ACK-200 that includes that very same option tag. But, we know its supported so the ACK would never need to be rejected. HTH, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 15 12:40:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqurG-0007tw-OH; Thu, 15 Jun 2006 12:38:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqurF-0007tr-Gj for sip@ietf.org; Thu, 15 Jun 2006 12:38:13 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqurD-0000B9-Uo for sip@ietf.org; Thu, 15 Jun 2006 12:38:13 -0400 Received: (qmail 5491 invoked by uid 0); 15 Jun 2006 16:38:09 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 15 Jun 2006 16:38:09 -0000 Message-ID: <004f01c6909a$13c94a40$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Alberto Cuda" , "Dale R. Worley" References: <001a01c68f7b$f6547f80$31713b51@BEMBUSTER><1150310075.25224.20.camel@niagra.pingtel.com> <44911782.40506@telecomitalia.it> Subject: Re: [Sip] Max-Forwards in ACK for non-2xx Date: Thu, 15 Jun 2006 18:38:04 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.1 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0827856114==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0827856114== Content-Type: multipart/alternative; boundary="----=_NextPart_000_004C_01C690AA.D68C5940" This is a multi-part message in MIME format. ------=_NextPart_000_004C_01C690AA.D68C5940 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable inline Regards, jeroen ----- Original Message -----=20 From: Alberto Cuda=20 To: Dale R. Worley=20 Cc: Sip=20 Sent: Thursday, June 15, 2006 10:17 AM Subject: Re: [Sip] Max-Forwards in ACK for non-2xx Dale R. Worley wrote: >On Wed, 2006-06-14 at 08:29 +0200, Jeroen van Bemmel wrote: >=20 > >>For this scenario, it again seems necessary that a stateless proxy >>stops non-2xx ACKs for responses it generated. Moreover, perhaps >>section 17.1.1.3 should be updated to say that the Max-Forwards = value >>should be the same as was used for the INVITE that was forwarded. = The >>ACK should not propagate further than the INVITE >>=20 >> > >This seems to be a particularly nasty case of a general truth: if a = SIP >agent generates a response, it really can't do so statelessly, as it = is >acting more like a UA than a proxy, in that it is creating a to-tag, >etc. >=20 > Why does it need to be stateful? I suppose that if it uses some hash on invariant fields (like the top Via header), it does not need to be more stateful than when it is forwarding a retransmission and has to generate the same branch tag... [JvB] It can be done statelessly (and for example authentication = challenges are RECOMMENDED to be done statelessly), but it puts an extra = requirement on the handling of ACKs. This should IMHO be stated more = clearly in a future update of RFC3261 ------=_NextPart_000_004C_01C690AA.D68C5940 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
inline
 
Regards,
 
jeroen
----- Original Message -----
From:=20 Alberto Cuda
Cc: Sip
Sent: Thursday, June 15, 2006 = 10:17=20 AM
Subject: Re: [Sip] Max-Forwards = in ACK=20 for non-2xx

 
Dale R. Worley wrote:

>On Wed, 2006-06-14 at 08:29 = +0200,=20 Jeroen van Bemmel wrote:
>
>
>>For this = scenario, it=20 again seems necessary that a stateless proxy
>>stops non-2xx = ACKs for=20 responses it generated. Moreover, perhaps
>>section 17.1.1.3 = should=20 be updated to say that the Max-Forwards value
>>should be the = same as=20 was used for the INVITE that was forwarded. The
>>ACK should = not=20 propagate further than the INVITE
>> =
>>
>
>This=20 seems to be a particularly nasty case of a general truth: if a=20 SIP
>agent generates a response, it really can't do so = statelessly, as=20 it is
>acting more like a UA than a proxy, in that it is = creating a=20 to-tag,
>etc.
>
>
Why does it need to be = stateful? I=20 suppose that if it uses some
hash on invariant fields (like the top = Via=20 header), it does not
need to be more stateful than when it is = forwarding=20 a
retransmission and has to generate the same branch=20 tag...
[JvB] It can be done statelessly (and = for example=20 authentication challenges are RECOMMENDED to be done statelessly), but = it puts=20 an extra requirement on the handling of ACKs. This should IMHO be stated = more=20 clearly in a future update of RFC3261
 
------=_NextPart_000_004C_01C690AA.D68C5940-- --===============0827856114== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0827856114==-- From sip-bounces@ietf.org Thu Jun 15 12:53:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqv40-0006wF-5i; Thu, 15 Jun 2006 12:51:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqv3y-0006wA-15 for sip@ietf.org; Thu, 15 Jun 2006 12:51:22 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqv3w-0001yU-EI for sip@ietf.org; Thu, 15 Jun 2006 12:51:22 -0400 Received: (qmail 25265 invoked by uid 0); 15 Jun 2006 16:51:18 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 15 Jun 2006 16:51:18 -0000 Message-ID: <006701c6909b$ea1d30b0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Alberto Cuda" References: <013101c68dab$f7e1eb20$31713b51@BEMBUSTER> <63069486-864A-4FF7-89B1-3CB7586F8687@softarmor.com> <448E6FF5.7080608@telecomitalia.it> <94B6B04F-27C9-420A-BCB8-33015EEA9A3A@softarmor.com> <448EEF82.8040905@telecomitalia.it> <001801c68f14$f35f6130$31713b51@BEMBUSTER> <4491158B.2080605@telecomitalia.it> <449115ED.7060908@telecomitalia.it> Subject: Re: [Sip] Supported: in ACK Date: Thu, 15 Jun 2006 18:51:14 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: Sip IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0107884789==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0107884789== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0064_01C690AC.AD86DFF0" This is a multi-part message in MIME format. ------=_NextPart_000_0064_01C690AC.AD86DFF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Only if the proxy providing the privacy service forwards CANCEL and = INVITE statelessly. Since CANCEL cannot have Proxy-Require, this implies that a proxy = providing RFC3323 privacy service MUST handle INVITE and CANCEL = statefully. This is not clearly stated in the RFC (and probably true for = any extension using Proxy-Require) Regards, Jeroen ----- Original Message -----=20 From: Alberto Cuda=20 To: Alberto Cuda=20 Cc: Jeroen van Bemmel ; Dean Willis ; Sip IETF=20 Sent: Thursday, June 15, 2006 10:10 AM Subject: Re: [Sip] Supported: in ACK Alberto Cuda wrote: > Jeroen van Bemmel wrote: > >> However, as to Proxy-Require in ACK to 2xx: it is needed in case a=20 >> Privacy service is used with "header" Privacy. >>=20 > > > Do you mean also in cases where some failure happens? In that case, = I=20 > guess > this holds true also for CANCEL & non-2xx requests... (Of course I meant non-2xx ACK requests). -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- ------=_NextPart_000_0064_01C690AC.AD86DFF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Only if the proxy providing the privacy = service=20 forwards CANCEL and INVITE statelessly.
 
Since CANCEL cannot have Proxy-Require, = this=20 implies that a proxy providing RFC3323 privacy service MUST handle = INVITE and=20 CANCEL statefully. This is not clearly stated in the RFC (and probably = true for=20 any extension using Proxy-Require)
 
Regards,
 
Jeroen
----- Original Message -----
From:=20 Alberto Cuda
To: Alberto Cuda
Cc: Jeroen van Bemmel ; Dean=20 Willis ; Sip = IETF=20
Sent: Thursday, June 15, 2006 = 10:10=20 AM
Subject: Re: [Sip] Supported: = in=20 ACK

 
Alberto Cuda wrote:

> Jeroen van Bemmel=20 wrote:
>
>> However, as to Proxy-Require in ACK to 2xx: = it is=20 needed in case a
>> Privacy service is used with "header"=20 Privacy.
>>
>
>
> Do you mean also in = cases where=20 some failure happens? In that case, I
> guess
> this = holds true=20 also for CANCEL & non-2xx requests...

(Of course I meant = non-2xx=20 ACK requests).


--------------------------------------------------------------------=
CONFIDENTIALITY=20 NOTICE
This message and its attachments are addressed solely to the = persons
above and may contain confidential information. If you have = received
the message in error, be informed that any use of the = content=20 hereof
is prohibited. Please return it immediately to the sender = and=20 delete
the message. Should you have any questions, please contact = us=20 by
replying to webmaster@telecomitalia.it.
        = Thank=20 = you
           =             &= nbsp;           &n= bsp;   =20 www.telecomitalia.it
--------------------------------------------------------------------=
------=_NextPart_000_0064_01C690AC.AD86DFF0-- --===============0107884789== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0107884789==-- From sip-bounces@ietf.org Thu Jun 15 13:24:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqvYL-0007CH-DZ; Thu, 15 Jun 2006 13:22:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqvYJ-0007CC-Ce for sip@ietf.org; Thu, 15 Jun 2006 13:22:43 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqvYH-0005zi-U8 for sip@ietf.org; Thu, 15 Jun 2006 13:22:43 -0400 Received: (qmail 29047 invoked by uid 0); 15 Jun 2006 17:22:39 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 15 Jun 2006 17:22:39 -0000 Message-ID: <007b01c690a0$4b0b59c0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Dean Willis" , "IETF SIP List" References: <4490BF1C.4050304@cisco.com> Subject: Re: [Sip] updated GRUU spec Date: Thu, 15 Jun 2006 19:22:35 +0200 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.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Keith Drage X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org OK, Dean. Here goes 1) The protocol bits that trigger issueing of a GRUU are "Supported: gruu" and a sip.instance id in the Contact header. If "supported" then "MUST issue GRUU". If you compare this with e.g. 100rel it seems a bit odd, Supported: 100rel does not force the server to use it. How about Supported -> SHOULD, Require -> MUST ? (could a domain have reasons not to honor the request for GRUUs?) 1a) Which error response if "Supported: gruu" but missing sip.instance? bad request? 2) There are several references to "dialog-creating" requests and responses for which GRUU can be used. This should be extended to include "target-refresh" requests such as UPDATE, and REGISTER (in rare cases) 3) section 6: the list on GRUU properties that MUST be exhibited should probably include "if the URI includes an "opaque" parameter, the base MUST be an AoR". The text later on depends on this 4) 7.1.1.1 says "MUST include Supported" . Does "Require" imply "Supported"? 5) 7.1.2.1 the part that says "MUST do so at this time" is too early. The REGISTER might be constructed according to outbound without Supported: gruu. I think 7.1.2.1 should start with "If REGISTER contains Supported: gruu, THEN { process as described here }" 6) 7.1.2.1 talks only about Supported, should probably say "Supported or Require" 7) 8.2.1 : I still feel that GRUU offers a great opportunity to start introducing looser routing. The spec already requires modifications to both proxies and UAs, so saying "proxy adds Route header" instead of "proxy rewrites request URI" seems a small effort. We'll be sorry later if we don't 8) c-p-gruu = "gruu" EQUAL LDQUOT (SIP-URI / SIPS-URI) RDQUOT, another draft authored by JR uses "DQUOTE" here...do we want consistency? 9) Section 12: some of the to-headers have the closing '>' one line too early; last message is missing an start tag Regards, jeroen > > On Jun 14, 2006, at 8:59 PM, Jonathan Rosenberg wrote: > >> I've just submitted an update to the GRUU spec. Until it appears, you >> can grab a copy here: >> >> http://www.jdrosen.net/papers/draft-ietf-sip-gruu-08.txt >> >> Here are the changes: >> > > Yay! Thank you, Jonathan, for this heroic effort. > > > Ok, kids. The log book says "GRUU is done". Could you be so kind as to > read through the new draft and make sure that's right, ASAP? I'd like to > know whether we have any remaining issues that justify taking agenda time > in Montreal in time to get the agenda figured out. > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 15 14:19:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqwPC-0001gM-0V; Thu, 15 Jun 2006 14:17:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqwPA-0001gH-L7 for sip@ietf.org; Thu, 15 Jun 2006 14:17:20 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqwP9-0002r8-7a for sip@ietf.org; Thu, 15 Jun 2006 14:17:20 -0400 Received: (qmail 9845 invoked by uid 0); 15 Jun 2006 18:17:13 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 15 Jun 2006 18:17:13 -0000 Message-ID: <00b401c690a7$eccaa700$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: Date: Thu, 15 Jun 2006 20:17:12 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Sip] http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-03.txt and UDP X-BeenThere: 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="===============0485697984==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0485697984== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B1_01C690B8.B01312A0" This is a multi-part message in MIME format. ------=_NextPart_000_00B1_01C690B8.B01312A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable outbound section 5.3: "the proxy MUST forward the request over the flow that received the REGISTER request that caused the flow identifier token to be created" I think it should be spelled out that for an UDP flow, the proxy MUST = not switch to TCP if the message size comes above 1300 Regards, jeroen ------=_NextPart_000_00B1_01C690B8.B01312A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
outbound section 5.3: "the proxy MUST = forward the=20 request over the
   flow that received the REGISTER request = that=20 caused the flow
   identifier token to be = created"
 
I think it should be spelled out that = for an UDP=20 flow, the proxy MUST not switch to TCP if the message size comes above=20 1300
 
Regards,
 
jeroen
------=_NextPart_000_00B1_01C690B8.B01312A0-- --===============0485697984== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0485697984==-- From sip-bounces@ietf.org Thu Jun 15 16:33:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqyUr-0003gY-Bc; Thu, 15 Jun 2006 16:31:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqyUp-0003fA-EH for sip@ietf.org; Thu, 15 Jun 2006 16:31:19 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqyUn-0006MM-RY for sip@ietf.org; Thu, 15 Jun 2006 16:31:19 -0400 Received: from [64.101.149.173] (dhcp-64-101-149-173.cisco.com [64.101.149.173]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5FKWi6C004746 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 15 Jun 2006 15:32:45 -0500 In-Reply-To: <007b01c690a0$4b0b59c0$31713b51@BEMBUSTER> References: <4490BF1C.4050304@cisco.com> <007b01c690a0$4b0b59c0$31713b51@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3BA07DF8-55FF-4836-9EF7-4235310D8D30@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] updated GRUU spec Date: Thu, 15 Jun 2006 15:31:05 -0500 To: Jeroen van Bemmel X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: IETF SIP List , Keith Drage X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 15, 2006, at 12:22 PM, Jeroen van Bemmel wrote: > OK, Dean. Here goes ask and ye shall receive . . . > > 1) The protocol bits that trigger issueing of a GRUU are > "Supported: gruu" and a sip.instance id in the Contact header. If > "supported" then "MUST issue GRUU". If you compare this with e.g. > 100rel it seems a bit odd, Supported: 100rel does not force the > server to use it. How about Supported -> SHOULD, Require -> MUST ? > (could a domain have reasons not to honor the request for GRUUs?) > We had an extended thread on that one, and ended up with the current position. Supported: alone cannot require a UAS to do anything. It's just a hint that tells the UAS (in this case the registrar) that the UAC supports a specific extension and cn be expected to behave accordingly. Require: also cannot force a UAS to use an extension -- it just makes sure that the UAS understand the extension, which is not the same thing. For example, I understand polygamy, I just don't use it (well, I might someday, but I'm single right now). The basic idea is that it any UA that supports GRUU and issues a request with a sip.instance ID is asking for and really wants A GRUU. So a registrar that understands GRUU must issues one when the client asks for it or reject the request if it can't. > 1a) Which error response if "Supported: gruu" but missing > sip.instance? bad request? > None. We just don't issue a gruu if we don't want to. The UAC hasn't insisted that it really wants one, so that's OK. > 2) There are several references to "dialog-creating" requests and > responses for which GRUU can be used. This should be extended to > include "target-refresh" requests such as UPDATE, and REGISTER (in > rare cases) Yeah, probably true. > > 3) section 6: the list on GRUU properties that MUST be exhibited > should probably include "if the URI includes an "opaque" parameter, > the base MUST be an AoR". The text later on depends on this > Ok, that's worthy of consideration. > 4) 7.1.1.1 says "MUST include Supported" . Does "Require" imply > "Supported"? > Nope. Require does not imply Supported. Strange but true. > 5) 7.1.2.1 the part that says "MUST do so at this time" is too > early. The REGISTER might be constructed according to outbound > without Supported: gruu. I think 7.1.2.1 should start with "If > REGISTER contains Supported: gruu, THEN { process as described here }" > Ok, this might need talking about. > 6) 7.1.2.1 talks only about Supported, should probably say > "Supported or Require" > I don't think so -- as above, Require does not imply Supported. > 7) 8.2.1 : I still feel that GRUU offers a great opportunity to > start introducing looser routing. The spec already requires > modifications to both proxies and UAs, so saying "proxy adds Route > header" instead of "proxy rewrites request URI" seems a small > effort. We'll be sorry later if we don't I'm already sorry ;-(. But we seem to have a consensus to do the route construction modification separately. > > 8) c-p-gruu = "gruu" EQUAL LDQUOT (SIP-URI / SIPS-URI) > RDQUOT, another draft authored by JR uses "DQUOTE" here...do we > want consistency? I thought the grammar guideline changed when the new grammar RFC came out. I'm not a BNF whiz though -- anybody know for sure? > > 9) Section 12: some of the to-headers have the closing '>' one line > too early; last message is missing an start tag Grr. Ok, that's a bug. Ok, we have some probably things listed above that would need to be fixed before sending to IESG and are probably not needing a realtime discussion: your questions 2, 8, and 9 probably fall into this. 3 and 5 need talking about. 1, 4, and 6 I think I've answered, and 7 we had a pre-existing consensus about that we can change our minds on but probably won't. Let's try and dissect 3 and 5 on the list in the next day or so and see if they close off. Thanks! -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 15 17:52:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqzj6-0003ZX-LF; Thu, 15 Jun 2006 17:50:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqzj5-0003ZD-BL for sip@ietf.org; Thu, 15 Jun 2006 17:50:07 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqzj3-0000ko-Vu for sip@ietf.org; Thu, 15 Jun 2006 17:50:07 -0400 Received: from [64.101.149.173] (dhcp-64-101-149-173.cisco.com [64.101.149.173]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5FLpY9Q005138 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 15 Jun 2006 16:51:35 -0500 Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: <18F72A6C-6A17-411B-B5C1-91F3DA886A50@softarmor.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF SIP List From: Dean Willis Date: Thu, 15 Jun 2006 16:50:01 -0500 X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Sip] Certs draft movement? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Once upon a time, a friend of mine had a dog that we thought liked to chase squirrels. When a squirrel would run up a tree, the dog would run to the tree and start barking. After a while, we noticed that the dog was just barking at trees whether they had a squirrel in them or not, and we realized that the dog wasn't all that worried about squirrels anymore. He'd gotten so used to barking at trees that he thought this was now his goal. So in putting the draft agenda together for Montreal, I noticed the new certs draft, draft-ietf-sip-certs-00.txt, and I thought about how I felt about the topic. It's definitely something I once chased after, like that dog chasing a squirrel. But Now I'm wondering where the "certs squirrel" went. Do we really believe in the certs draft, or are we just barking at a tree out of habit? -- 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 Jun 15 18:52:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr0f9-0001x5-Go; Thu, 15 Jun 2006 18:50:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr0f4-0001nj-De; Thu, 15 Jun 2006 18:50:02 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr0f4-0006Gb-23; Thu, 15 Jun 2006 18:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5FMo1Rx026165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Jun 2006 22:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fr0f3-0000vd-No; Thu, 15 Jun 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 15 Jun 2006 18:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-gruu-08.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sip-gruu-08.txt Pages : 37 Date : 2006-6-15 Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI that can be used by anyone on the Internet to route a call to that specific UA instance. A URI that routes to a specific UA instance is called a Globally Routable UA URI (GRUU). This document describes an extension to SIP for obtaining a GRUU from a server and for communicating a GRUU to a peer within a dialog. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-gruu-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-gruu-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-15153847.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-gruu-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-gruu-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-15153847.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Thu Jun 15 19:03:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr0q2-0002zO-2B; Thu, 15 Jun 2006 19:01:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr0q1-0002zJ-DE for sip@ietf.org; Thu, 15 Jun 2006 19:01:21 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr0q0-00080G-2u for sip@ietf.org; Thu, 15 Jun 2006 19:01:21 -0400 Received: from [64.101.149.173] (dhcp-64-101-149-173.cisco.com [64.101.149.173]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5FN2kEc005528 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 15 Jun 2006 18:02:49 -0500 Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: <64E65A00-DA40-4650-AEDB-8E186358F6EB@softarmor.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF SIP List From: Dean Willis Date: Thu, 15 Jun 2006 18:01:14 -0500 X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Sip] Draft agenda for SIP at IETF 66 posted X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Please eyeball or otherwise inspect the draft agenda at: https://www.softarmor.com/sipwg/meets/ietf66/agenda.html -- 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 Jun 15 22:02:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr3dZ-0008RX-Sz; Thu, 15 Jun 2006 22:00:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr3dX-0008RN-WF for sip@ietf.org; Thu, 15 Jun 2006 22:00:40 -0400 Received: from [2001:5c0:8fff:fffe::4c3d] (helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr3dW-0003cj-6s for sip@ietf.org; Thu, 15 Jun 2006 22:00:39 -0400 Received: from [192.168.1.105] ([71.204.151.47]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k5G20Tlp028198 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 15 Jun 2006 21:00:34 -0500 (CDT) (envelope-from ben@estacado.net) In-Reply-To: <18F72A6C-6A17-411B-B5C1-91F3DA886A50@softarmor.com> References: <18F72A6C-6A17-411B-B5C1-91F3DA886A50@softarmor.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9D40506D-61F0-4EAC-B824-A165DB9CB979@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Sip] Certs draft movement? Date: Thu, 15 Jun 2006 21:00:22 -0500 To: Dean Willis X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I, for one, think there is a squirrel in that particular tree. On Jun 15, 2006, at 4:50 PM, Dean Willis wrote: > > Once upon a time, a friend of mine had a dog that we thought liked > to chase squirrels. When a squirrel would run up a tree, the dog > would run to the tree and start barking. After a while, we noticed > that the dog was just barking at trees whether they had a squirrel > in them or not, and we realized that the dog wasn't all that > worried about squirrels anymore. He'd gotten so used to barking at > trees that he thought this was now his goal. > > So in putting the draft agenda together for Montreal, I noticed the > new certs draft, draft-ietf-sip-certs-00.txt, and I thought about > how I felt about the topic. It's definitely something I once chased > after, like that dog chasing a squirrel. But Now I'm wondering > where the "certs squirrel" went. > > Do we really believe in the certs draft, or are we just barking at > a tree out of habit? > > -- > 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 Jun 15 23:37:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr57t-0004CT-8n; Thu, 15 Jun 2006 23:36:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr57r-00046y-P4 for sip@ietf.org; Thu, 15 Jun 2006 23:36:03 -0400 Received: from [210.72.128.8] (helo=sict.ac.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr57n-0002xh-Rt for sip@ietf.org; Thu, 15 Jun 2006 23:36:03 -0400 Received: from zhangwei ([210.72.128.109]) by sict.ac.cn (Merak 7.2.0) with SMTP id 42U08685 for ; Fri, 16 Jun 2006 11:35:28 +0800 Message-ID: <001101c690f5$eb5e7060$378ba8c0@zhangwei> From: "zhangwei" To: Date: Fri, 16 Jun 2006 11:35:31 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.2 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Sip] INVITE request after 302 response X-BeenThere: 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="===============1931158217==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1931158217== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C69138.F950DC60" This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C69138.F950DC60 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksDQoNCiAgIEluIFNJUCwgMzAyIE1vdmVkIFRlbXBvcmFyaWx5IGNhbiBiZSB1c2VkIGJ5IFVz ZXIgQWdlbnQgdG8gc2V0IGNhbGwgZm9yd2FyZGluZy4gV2hlbiB0aGUgY2FsbGVyIHJlY2VpdmVk IDMwMiwgaXQgc2hvdWxkIHJlLWNyZWF0ZSBhIG5ldyBJTlZJVEUgcmVxdWVzdCB0byBmb3J3YXJk IGNhbGwgdG8gYSBnaXZlbiBjb250YWN0Lg0KDQogICBNeSBxdWVzdGlvbiBpcyBob3cgUHJveHkg U2VydmVyIGRldGVjdCB3aGV0aGVyIElOVklURSBpcyBjcmVhdGVkIGFmdGVyIGhhdmluZyByZWNl aXZlZCAzMDIgcmVzcG9uc2UuIFRoZSBQcm94eSBTZXJ2ZXIgaXMgdHJhbnNhY3Rpb24gc3RhdGVm dWwuIFdoYXQncyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIElOVklURSBhZnRlciAzMDIgYW5kIHRo ZSBub3JtYWwgSU5WSVRFID8gDQoNCg0KUmVnYXJkcw0KWmhhbmcgV2Vp ------=_NextPart_000_000E_01C69138.F950DC60 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjI5MTIiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5IaSw8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj4mbmJzcDsmbmJzcDsgSW4gU0lQLCAzMDImbmJzcDtNb3ZlZCBUZW1wb3JhcmlseSBjYW4gYmUg dXNlZCBieSANClVzZXIgQWdlbnQgdG8gc2V0IGNhbGwgZm9yd2FyZGluZy4gV2hlbiB0aGUgY2Fs bGVyIHJlY2VpdmVkIDMwMiwgaXQgc2hvdWxkIA0KcmUtY3JlYXRlIGEgbmV3IElOVklURSByZXF1 ZXN0IHRvIGZvcndhcmQgY2FsbCB0byBhIGdpdmVuIGNvbnRhY3QuPC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5i c3A7Jm5ic3A7IE15IHF1ZXN0aW9uIGlzIGhvdyBQcm94eSBTZXJ2ZXIgDQpkZXRlY3QmbmJzcDt3 aGV0aGVyIElOVklURSZuYnNwO2lzIGNyZWF0ZWQgYWZ0ZXIgaGF2aW5nIHJlY2VpdmVkIDMwMiBy ZXNwb25zZS4gDQpUaGUgUHJveHkgU2VydmVyIGlzIHRyYW5zYWN0aW9uIHN0YXRlZnVsLiBXaGF0 J3MgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiANCklOVklURSZuYnNwO2FmdGVyIDMwMiBhbmQgdGhl IG5vcm1hbCBJTlZJVEUgPyZuYnNwOzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwv Rk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPlJlZ2FyZHM8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj5aaGFuZyBXZWk8L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_000E_01C69138.F950DC60-- --===============1931158217== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1931158217==-- From sip-bounces@ietf.org Fri Jun 16 06:30:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrBZO-0003zC-W4; Fri, 16 Jun 2006 06:28:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrBZM-0003z7-EB for sip@ietf.org; Fri, 16 Jun 2006 06:28:52 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrBZL-0002KQ-0p for sip@ietf.org; Fri, 16 Jun 2006 06:28:52 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5GASleH008928 for ; Fri, 16 Jun 2006 13:28:50 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jun 2006 13:28:48 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jun 2006 13:28:48 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Jun 2006 13:28:47 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F026F49AE@esebe103.NOE.Nokia.com> In-Reply-To: <20060616112021737.00000003956@jrogde-se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-koivusalo-sip-outbound-discovery-02 sent for publication Thread-Index: AcaRJtCE3YcB1RVhQW+zhc4KbMadPAAB+t4A From: To: X-OriginalArrivalTime: 16 Jun 2006 10:28:48.0227 (UTC) FILETIME=[A7425330:01C6912F] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Sip] draft-koivusalo-sip-outbound-discovery-02 sent for publication X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I have sent the draft-koivusalo-sip-outbound-discovery-02 to be published. Summary of changes since 01 version is as follows: - Adopted the terminology primary and secodary flow in those cases where the secondary flow is not specifically having backup status. Primary flow just means the one that the UA creates first and secondary the other one. - Added text to define how the UA determines the number of=20 flows to create. - Clarified how the UA uses the created flows: when the two flows should be used in an equal way and when the primary and backup status really matter for the UA. 02 is the version to be discussed in IETF#66 meeting, according to the draft SIP WG agenda. Regards, Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 16 10:09:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrEyu-000754-NC; Fri, 16 Jun 2006 10:07:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrEyt-00074z-3W for sip@ietf.org; Fri, 16 Jun 2006 10:07:27 -0400 Received: from [210.72.128.8] (helo=sict.ac.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrEyn-0008HM-Ee for sip@ietf.org; Fri, 16 Jun 2006 10:07:27 -0400 Received: from zhangwei ([210.72.128.41]) by sict.ac.cn (Merak 7.2.0) with SMTP id 42U08685; Fri, 16 Jun 2006 22:04:24 +0800 Message-ID: <00c501c6914d$c2fc45e0$378ba8c0@zhangwei> From: "zhangwei" To: "Sumit Dhar" , , "Lei Weimin" References: Date: Fri, 16 Jun 2006 22:04:19 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.4 (/) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc Cc: Subject: [Sip] Re: INVITE request after 302 response X-BeenThere: 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="===============1597083646==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1597083646== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C2_01C69190.D0F65300" This is a multi-part message in MIME format. ------=_NextPart_000_00C2_01C69190.D0F65300 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGVsbG8gU3VtaXQsDQoNClRoYW5rcyBmb3IgeW91ciByZXNwb25zZS4NCg0KVGFrZSBhbiBleGFt cGxlIGZvciB0aGUgYXBwbGljYXRpb24uDQoNClVBMSAgICAgIFByb3h5IFNlcnZlciAgICBVQTIg ICAgVUEzDQp8ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgIHwgICAgICAgICB8 DQp8LS0tSU5WSVRFLS0tPnwgICAgICAgICAgICAgICAgICB8ICAgICAgICAgfA0KfCAgICAgICAg ICAgICAgICAgIHwtLS1JTlZJVEUtLT4gfCAgICAgICAgIHwNCnwgICAgICAgICAgICAgICAgICB8 PC0tLS0zMDIgLS0tLS0tfCAgICAgICAgIHwNCnw8LS0tLTMwMi0tLS0tLS18ICAgICAgICAgICAg ICAgICAgfCAgICAgICAgIHwNCnwgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg fCAgICAgICAgIHwNCnwtLS0tLUFDSy0tLS0+fCAgICAgICAgICAgICAgICAgIHwgICAgICAgICB8 DQp8ICAgICAgICAgICAgICAgICAgfC0tLUFDSy0tLS0tLT58ICAgICAgICAgfA0KfC0tLUlOVklU RS0tLT58ICAgICAgICAgICAgICAgICAgfCAgICAgICAgIHwNCnwgICAgICAgICAgICAgICAgICB8 LS0tLS0tLS0tLS0tSU5WSVRFLS0tLT58DQp8ICAgICAgICAgICAgICAgICAgfDwtLTEwMC8xODAv MjAwLS0tLS0tfA0KfDEwMC8xODAvMjAwfCAgICAgICAgICAgICAgICAgIHwgICAgICAgICB8DQp8 ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgIHwgICAgICAgICB8DQp8LS0tLUFD Sy0tLS0tPnwgICAgICAgICAgICAgICAgICB8ICAgICAgICAgfA0KfCAgICAgICAgICAgICAgICAg IHwtLS0tLS0tLS0tLS0tLUFDSy0tLS0tPnwNCg0KDQpPdXIgcHJvamVjdCBuZWVkIHRvIGFjY291 bnQgYWNjb3JkaW5nIHRvIElOVklURS8yMDAvQUNLIGFuZCBCWUUuICANCg0KRm9yIHRoZSBpbnN0 YW5jZSBhYm92ZSwgd2Ugd2FudCB0byBtYWtlIHR3byBhY2NvdW50aW5ncy4gT25lIGlzIFVBMSBj YWxsIFVBMi4gVGhlIG90aGVyIGlzIFVBMiBjYWxsIFVBMy4NCg0KT3VyIFByb3h5IFNlcnZlciBp cyB0cmFuc2FjdGlvbiBzdGF0ZWZ1bC4gQnV0IHdlIHdhbnQgdGhhdCBQcm94eSBTZXJ2ZXIgY2Fu IG9idGFpbiBVQTEgVUEyIGFuZCBVQTMncyBpbmZvIG9ubHkgZnJvbSB0aGUgc2Vjb25kIElOVklU RSByZXF1ZXN0Lg0KDQpIb3cgY2FuIG15IFByb3h5IFNlcnZlciBvYnRhaW4gVUEyJ3MgaW5mbyBv bmx5IGZyb20gdGhlIHNlY29uZCBJTlZJVEUgcmVxdWVzdD8gDQoNCg0KVGhhbmtzICYgQmVzdCBy ZWdhcmRzDQoNClpoYW5nIFdlaQ0KDQogIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQog IEZyb206IFN1bWl0IERoYXIgDQogIFRvOiB6aGFuZ3dlaSANCiAgU2VudDogRnJpZGF5LCBKdW5l IDE2LCAyMDA2IDc6MDggUE0NCiAgU3ViamVjdDogUmU6IElOVklURSByZXF1ZXN0IGFmdGVyIDMw MiByZXNwb25zZQ0KDQoNCg0KICBIZWxsbyBNciBaaGFuZywgDQoNCiAgVGhhbmtzIGZvciB5b3Vy IG1haWwuIA0KDQogIEkgd2FzbnQgdG9vIHN1cmUgaG93ZXZlciBhcyB0byB3aGVyZSB5b3UgZ290 IG15IGNvbnRhY3RzIGZyb20uIEkgaGF2ZSBhbnl3YXlzIG9yZ2FuaXplZCBhIHJlc3BvbnNlIGZv ciB5b3VyIHF1ZXN0aW9uIHdoaWNoIGlzIGVuY2xvc2VkIGluIG15IG1haWwuIA0KDQogIE1heSBJ IHJlcXVlc3QgdG8ga25vdyBtb3JlIGRldGFpbHMgYWJvdXQgdGhlIHByb2plY3QgeW91IGFyZSB3 b3JraW5nIG9uLCBhbmQgaWYgd2UgY2FuIHBvc3NpYmxlIGNvbGxhYm9yYXRlIC4gDQoNCiAgVGhh bmtzICYgQmVzdCBSZWdhcmRzLCANCg0KICBTdW1pdCANCg0KICBSZXNwb25zZT4gDQogIEEgdHlw aWNhbCAzMjYxIGNvbXBsaWFudCB0cmFuc2FjdGlvbiBzdGF0ZWZ1bCBwcm94eSB3b3VsZCBub3Qg YmUgYWJsZSB0byBkaXN0aW5ndWlzaCBpZiBhbiBJTlZJVEUgaXMgYW4gaW5pdGlhbCBJTlZJVEUg c2VudCBieSBhIFVBIA0KICBPUiB3YXMgc2VudCBzdWJzZXF1ZW50IHRvIHRoZSByZWNlcHRpb24g b2YgYSAzMDIgcmVzcG9uc2UuIEFsc28sIGEgdHJhbnNhdGNpb24gc3RhdGVmdWwgcHJveHkgbmVl ZCBub3Qga25vdyBpdC4gDQogIEFuIGV4Y2VwdGlvbiBob3dldmVyIGlzIHdoZW4gYSBwcm94eSBp cyBjYXBhYmxlIHRvIHBlcmZvcm1pbmcgcmVjdXJzaW9uLiBJbiB0aGlzIGNhc2UsIHRoZSBwcm94 eSB3b3VsZCBpbnRlcnByZXQgdGhlIDMwMiByZXNwb25zZSANCiAgYnkgaXRzZWxmIGFuZCBzZW5k IGEgbmV3IElOVklURSB0byB0aGUgcmVkaXJlY3RlZCBjb250YWN0IGFkZHJlc3MuIA0KDQoNCiAg SWYgaG93ZXZlciwgdGhlcmUgaXMgYSBuZWVkIHRvIGtub3cgdGhhdCBhbiBJTlZJVEUgd2FzIHJl ZGlyZWN0ZWQsIG9uZSBvcHRpb24gaXMgdG8gY2hlY2sgdGhlIGNzZXEgbnVtYmVyLi4gDQogIFJG QyAzMjYxIHJlY29tbWVuZHMgdGhhdCB0aGUgVUEgdXNlcyB0aGUgc2FtZSBjYWxsLWlkLCBmcm9t LXRhZywgdG8tdGFnIGV0YyBhbmQganVzdCBpbmNyZW1lbnQgdGhlIGNzZXEgbnVtYmVyIGZvciAN CiAgYSBuZXcgSU5WSVRFIHRvd2FyZHMgdGhlIHJlZGlyZWN0ZWQgYWRkcmVzcy4gSG93ZXZlciwg dGhpcyBpcyBqdXN0IGEgcmVjb21tZW5kYXRpb24gYW5kIG1heSBub3QgYmUgYWRoZXJlZCB0byBi eSB0aGUgVUEuIA0KDQoNCg0KDQoNCiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgIFN1bWl0IERoYXIgICAgICAgICAgIA0KICAgU2Vn bWVudCBNYW5hZ2VyLA0KICAgU2VydmljZSBQcm92aWRlciBQcm9kdWN0cyBCdXNpbmVzcywNCiAg IEZsZXh0cm9uaWNzIFNvZnR3YXJlIFN5c3RlbXMNCiAgIChGb3JtZXJseSBIdWdoZXMgU29mdHdh cmUgU3lzdGVtcykNCiAgIE5vLiAxOCwgT3V0ZXIgUmluZyBSb2FkLCBQYW5hdGh1ciBQb3N0LA0K ICAgQmFuZ2Fsb3JlIC01NjAgMDg3LCAgSW5kaWEgICAgICAgICAgICAgICANCiAgIFBob25lICA6 ICs5MS04MC00MTA2IDcxMzggIEZheCAgICAgOiArOTEtODAtNDEyNiA2NTAxICAgDQogICB2aXNp dCB1cyBhdCBodHRwOi8vd3d3LmZsZXh0cm9uaWNzc29mdHdhcmUuY29tIA0KDQoNCiAgICAgICAg InpoYW5nd2VpIiA8emhhbmd3ZWlAc2ljdC5hYy5jbj4gDQogICAgICAgIDA2LzE2LzIwMDYgMDE6 MTEgUE0gDQoNCiAgICAgICBUbyBTdW1pdCBEaGFyL0JMUi9IU1NASFNTICANCiAgICAgICAgICAg ICAgY2MgIA0KICAgICAgICAgICAgICBTdWJqZWN0IElOVklURSByZXF1ZXN0IGFmdGVyIDMwMiBy ZXNwb25zZSANCg0KICAgICAgICAgICAgICANCg0KICAgICAgIA0KDQoNCg0KICBIaSwgDQogICAg DQogICAgIEluIFNJUCwgMzAyIE1vdmVkIFRlbXBvcmFyaWx5IGNhbiBiZSB1c2VkIGJ5IFVzZXIg QWdlbnQgdG8gc2V0IGNhbGwgZm9yd2FyZGluZy4gV2hlbiB0aGUgY2FsbGVyIHJlY2VpdmVkIDMw MiwgaXQgc2hvdWxkIHJlLWNyZWF0ZSBhIG5ldyBJTlZJVEUgcmVxdWVzdCB0byBmb3J3YXJkIGNh bGwgdG8gYSBnaXZlbiBjb250YWN0LiANCiAgICANCiAgICAgTXkgcXVlc3Rpb24gaXMgaG93IFBy b3h5IFNlcnZlciBkZXRlY3Qgd2hldGhlciBJTlZJVEUgaXMgY3JlYXRlZCBhZnRlciBoYXZpbmcg cmVjZWl2ZWQgMzAyIHJlc3BvbnNlLiBUaGUgUHJveHkgU2VydmVyIGlzIHRyYW5zYWN0aW9uIHN0 YXRlZnVsLiBXaGF0J3MgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBJTlZJVEUgYWZ0ZXIgMzAyIGFu ZCB0aGUgbm9ybWFsIElOVklURSA/IA0KICAgIA0KICAgIA0KICBSZWdhcmRzIA0KICBaaGFuZyBX ZWkgDQoNCg0KICAqKioqKioqKioqKioqKioqKioqKioqKiAgRlNTLSBDb25maWRlbnRpYWwgICAq KioqKioqKioqKioqKioqKioqKioqKiAiRElTQ0xBSU1FUjogVGhpcyBtZXNzYWdlIGlzIHByb3By aWV0YXJ5IHRvIEZsZXh0cm9uaWNzIFNvZnR3YXJlIFN5c3RlbXMgKEZTUykgYW5kIGlzIGludGVu ZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiANCnRoZSBpbmRpdmlkdWFsIHRvIHdob20gaXQgaXMg YWRkcmVzc2VkLiBJdCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbCBpbmZv cm1hdGlvbiBhbmQgc2hvdWxkIG5vdCBiZSANCmNpcmN1bGF0ZWQgb3IgdXNlZCBmb3IgYW55IHB1 cnBvc2Ugb3RoZXIgdGhhbiBmb3Igd2hhdCBpdCBpcyBpbnRlbmRlZC4gSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCANCnBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0 b3IgaW1tZWRpYXRlbHkuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlv dSBhcmUgbm90aWZpZWQgdGhhdCB5b3UgYXJlIHN0cmljdGx5DQpwcm9oaWJpdGVkIGZyb20gdXNp bmcsIGNvcHlpbmcsIGFsdGVyaW5nLCBvciBkaXNjbG9zaW5nIHRoZSBjb250ZW50cyBvZiB0aGlz IG1lc3NhZ2UuIEZTUyBhY2NlcHRzIG5vIHJlc3BvbnNpYmlsaXR5IGZvciANCmxvc3Mgb3IgZGFt YWdlIGFyaXNpbmcgZnJvbSB0aGUgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBi eSB0aGlzIGVtYWlsIGluY2x1ZGluZyBkYW1hZ2UgZnJvbSB2aXJ1cy4iDQogDQo= ------=_NextPart_000_00C2_01C69190.D0F65300 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjkwMC4yOTEyIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5I ZWxsbyZuYnNwO1N1bWl0LDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXpl PTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5UaGFu a3MgZm9yIHlvdXIgcmVzcG9uc2UuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFs IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0y PlRha2UgYW4gZXhhbXBsZSBmb3IgdGhlIGFwcGxpY2F0aW9uLjwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPlVBMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBQcm94eSANClNlcnZlciZuYnNwOyZuYnNwOyZuYnNwOyBVQTImbmJzcDsmbmJzcDsmbmJz cDsgVUEzPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIA0Kc2l6ZT0yPnwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQombmJzcDsgDQp8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KJm5ic3A7IHwmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgDQpz aXplPTI+fC0tLUlOVklURS0tLSZndDt8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IA0KfCZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCANCnNpemU9Mj58Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfC0tLTxGT05UIGNvbG9y PSNmZjAwMDA+SU5WSVRFPC9GT05UPi0tJmd0OyB8Jm5ic3A7Jm5ic3A7IA0KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwg DQpzaXplPTI+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAN CnwmbHQ7LS0tLTMwMiAtLS0tLS18Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIA0Kc2l6ZT0yPnwm bHQ7LS0tLTMwMi0tLS0tLS18Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IA0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsgDQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+fDwvRk9OVD48Rk9O VCANCnNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJz cDsgDQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvRk9OVD48L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgDQpzaXplPTI+fC0tLS0tQUNLLS0tLSZndDt8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KJm5ic3A7fCZuYnNwOyZuYnNwOyZu YnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT1BcmlhbCANCnNpemU9Mj58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IA0KJm5ic3A7fC0tLUFDSy0tLS0tLSZndDt8Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyANCnw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwg DQpzaXplPTI+fC0tLUlOVklURS0tLSZndDt8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KJm5ic3A7fCZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCANCnNpemU9Mj58Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfC0tLS0tLS0tLS0t LTxGT05UIGNvbG9yPSNmZjAwMDA+SU5WSVRFPC9GT05UPi0tLS0mZ3Q7fDwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1BcmlhbCANCnNpemU9Mj58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KJm5ic3A7Jm5ic3A7fCZsdDstLTEwMC8xODAvMjAwLS0tLS0tfDwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+fDEwMC8xODAvMjAwfCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IA0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 QXJpYWwgDQpzaXplPTI+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyANCnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgDQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyZuYnNwOyZuYnNwOyANCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBmYWNlPUFyaWFsIA0Kc2l6ZT0yPnwtLS0tQUNLLS0tLS0mZ3Q7fCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiZuYnNwOyB8Jm5ic3A7Jm5ic3A7ICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFy aWFsIA0Kc2l6ZT0yPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgDQp8LS0tLS0tLS0tLS0tLS1BQ0stLS0tLSZndDt8PC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBm YWNlPUFyaWFsIHNpemU9Mj5PdXIgcHJvamVjdCBuZWVkIHRvIGFjY291bnQgYWNjb3JkaW5nIHRv IA0KSU5WSVRFLzIwMC9BQ0sgYW5kIEJZRS4mbmJzcDsmbmJzcDs8L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT1BcmlhbCBzaXplPTI+Rm9yIHRoZSBpbnN0YW5jZSBhYm92ZSwgd2Ugd2FudCB0byBtYWtl IHR3byANCmFjY291bnRpbmdzLiBPbmUgaXMgVUExIGNhbGwgVUEyLiBUaGUgb3RoZXIgaXMgVUEy IGNhbGwgVUEzLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9G T05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5PdXIgUHJveHkg U2VydmVyIGlzIHRyYW5zYWN0aW9uIHN0YXRlZnVsLiBCdXQgd2UgDQp3YW50IHRoYXQgUHJveHkg U2VydmVyIGNhbiBvYnRhaW4gVUExIFVBMiBhbmQgVUEzJ3MgaW5mbyBvbmx5IGZyb20gdGhlIHNl Y29uZCANCklOVklURSByZXF1ZXN0LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1Bcmlh bCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9 Mj5Ib3cgY2FuIG15IFByb3h5IFNlcnZlciBvYnRhaW4gVUEyJ3MgaW5mbyZuYnNwO29ubHkgDQpm cm9tIHRoZSBzZWNvbmQgSU5WSVRFIHJlcXVlc3Q/Jm5ic3A7PC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9QXJpYWwgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1Bcmlh bCBzaXplPTI+VGhhbmtzICZhbXA7IEJlc3QgcmVnYXJkczwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNl PUFyaWFsIHNpemU9Mj5aaGFuZyBXZWk8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJp YWwgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxCTE9DS1FVT1RFIA0Kc3R5bGU9IlBBRERJ TkctUklHSFQ6IDBweDsgUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRF Ui1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8RElWIHN0 eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAt LS0tLSA8L0RJVj4NCiAgPERJViBzdHlsZT0iQkFDS0dST1VORDogI2U0ZTRlNDsgRk9OVDogOXB0 ICYjMjM0MzU7JiMyMDMwNzs7IGZvbnQtY29sb3I6IGJsYWNrIj48Qj5Gcm9tOjwvQj4gDQogIDxB IHRpdGxlPXN1bWl0LmRoYXJAZmxleHRyb25pY3Nzb2Z0d2FyZS5jb20gDQogIGhyZWY9Im1haWx0 bzpzdW1pdC5kaGFyQGZsZXh0cm9uaWNzc29mdHdhcmUuY29tIj5TdW1pdCBEaGFyPC9BPiA8L0RJ Vj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlRvOjwvQj4g PEEgdGl0bGU9emhhbmd3ZWlAc2ljdC5hYy5jbiANCiAgaHJlZj0ibWFpbHRvOnpoYW5nd2VpQHNp Y3QuYWMuY24iPnpoYW5nd2VpPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYj MjM0MzU7JiMyMDMwNzsiPjxCPlNlbnQ6PC9CPiBGcmlkYXksIEp1bmUgMTYsIDIwMDYgNzowOCBQ TTwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U3Vi amVjdDo8L0I+IFJlOiBJTlZJVEUgcmVxdWVzdCBhZnRlciAzMDIgDQogIHJlc3BvbnNlPC9ESVY+ DQogIDxESVY+PEJSPjwvRElWPjxCUj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPkhlbGxv IE1yIFpoYW5nLDwvRk9OVD4gDQogIDxCUj48QlI+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9 Mj5UaGFua3MgZm9yIHlvdXIgbWFpbC48L0ZPTlQ+IA0KICA8QlI+PEJSPjxGT05UIGZhY2U9c2Fu cy1zZXJpZiBzaXplPTI+SSB3YXNudCB0b28gc3VyZSBob3dldmVyIGFzIHRvIHdoZXJlIHlvdSAN CiAgZ290IG15IGNvbnRhY3RzIGZyb20uIEkgaGF2ZSBhbnl3YXlzIG9yZ2FuaXplZCBhIHJlc3Bv bnNlIGZvciB5b3VyIHF1ZXN0aW9uIA0KICB3aGljaCBpcyBlbmNsb3NlZCBpbiBteSBtYWlsLjwv Rk9OVD4gPEJSPjxCUj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPk1heSANCiAgSSByZXF1 ZXN0IHRvIGtub3cgbW9yZSBkZXRhaWxzIGFib3V0IHRoZSBwcm9qZWN0IHlvdSBhcmUgd29ya2lu ZyBvbiwgYW5kIGlmIHdlIA0KICBjYW4gcG9zc2libGUgY29sbGFib3JhdGUgLjwvRk9OVD4gPEJS PjxCUj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPlRoYW5rcyANCiAgJmFtcDsgQmVzdCBS ZWdhcmRzLDwvRk9OVD4gPEJSPjxCUj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPlN1bWl0 PC9GT05UPiANCiAgPEJSPjxCUj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPlJlc3BvbnNl Jmd0OzwvRk9OVD4gPEJSPjxGT05UIA0KICBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPkEgdHlwaWNh bCAzMjYxIGNvbXBsaWFudCB0cmFuc2FjdGlvbiBzdGF0ZWZ1bCBwcm94eSANCiAgd291bGQgbm90 IGJlIGFibGUgdG8gZGlzdGluZ3Vpc2ggaWYgYW4gSU5WSVRFIGlzIGFuIGluaXRpYWwgSU5WSVRF IHNlbnQgYnkgYSANCiAgVUEgPC9GT05UPjxCUj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0y Pk9SIHdhcyBzZW50IHN1YnNlcXVlbnQgdG8gdGhlIA0KICByZWNlcHRpb24gb2YgYSAzMDIgcmVz cG9uc2UuIEFsc28sIGEgdHJhbnNhdGNpb24gc3RhdGVmdWwgcHJveHkgbmVlZCBub3Qga25vdyAN CiAgaXQuPC9GT05UPiA8QlI+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj5BbiBleGNlcHRp b24gaG93ZXZlciBpcyB3aGVuIGEgDQogIHByb3h5IGlzIGNhcGFibGUgdG8gcGVyZm9ybWluZyBy ZWN1cnNpb24uIEluIHRoaXMgY2FzZSwgdGhlIHByb3h5IHdvdWxkIA0KICBpbnRlcnByZXQgdGhl IDMwMiByZXNwb25zZTwvRk9OVD4gPEJSPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+Ynkg aXRzZWxmIA0KICBhbmQgc2VuZCBhIG5ldyBJTlZJVEUgdG8gdGhlIHJlZGlyZWN0ZWQgY29udGFj dCBhZGRyZXNzLiANCiAgPC9GT05UPjxCUj48QlI+PEJSPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBz aXplPTI+SWYgaG93ZXZlciwgdGhlcmUgaXMgYSBuZWVkIHRvIA0KICBrbm93IHRoYXQgYW4gSU5W SVRFIHdhcyByZWRpcmVjdGVkLCBvbmUgb3B0aW9uIGlzIHRvIGNoZWNrIHRoZSBjc2VxIA0KICBu dW1iZXIuLjwvRk9OVD4gPEJSPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+UkZDIDMyNjEg cmVjb21tZW5kcyB0aGF0IHRoZSANCiAgVUEgdXNlcyB0aGUgc2FtZSBjYWxsLWlkLCBmcm9tLXRh ZywgdG8tdGFnIGV0YyBhbmQganVzdCBpbmNyZW1lbnQgdGhlIGNzZXEgDQogIG51bWJlciBmb3I8 L0ZPTlQ+IDxCUj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPmEgbmV3IElOVklURSB0b3dh cmRzIHRoZSANCiAgcmVkaXJlY3RlZCBhZGRyZXNzLiBIb3dldmVyLCB0aGlzIGlzIGp1c3QgYSBy ZWNvbW1lbmRhdGlvbiBhbmQgbWF5IG5vdCBiZSANCiAgYWRoZXJlZCB0byBieSB0aGUgVUEuPC9G T05UPiA8QlI+PEJSPjxGT05UIGZhY2U9c2Fucy1zZXJpZiANCiAgc2l6ZT0yPjxCUj48QlI+PEJS PjxCUj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLTxCUj4mbmJzcDtTdW1pdCANCiAgRGhhciAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IDxCUj4mbmJzcDtTZWdtZW50IA0KICBNYW5hZ2VyLDxCUj4mbmJzcDtTZXJ2aWNlIFBy b3ZpZGVyIFByb2R1Y3RzIEJ1c2luZXNzLDxCUj4mbmJzcDtGbGV4dHJvbmljcyANCiAgU29mdHdh cmUgU3lzdGVtczxCUj4mbmJzcDsoRm9ybWVybHkgSHVnaGVzIFNvZnR3YXJlIFN5c3RlbXMpPEJS PiZuYnNwO05vLiAxOCwgDQogIE91dGVyIFJpbmcgUm9hZCwgUGFuYXRodXIgUG9zdCw8QlI+Jm5i c3A7QmFuZ2Fsb3JlIC01NjAgMDg3LCAmbmJzcDtJbmRpYSANCiAgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxCUj4mbmJzcDtQaG9uZSAmbmJzcDs6IA0K ICArOTEtODAtNDEwNiA3MTM4ICZuYnNwO0ZheCAmbmJzcDsgJm5ic3A7IDogKzkxLTgwLTQxMjYg NjUwMSAmbmJzcDsgDQogIDxCUj4mbmJzcDt2aXNpdCB1cyBhdCBodHRwOi8vd3d3LmZsZXh0cm9u aWNzc29mdHdhcmUuY29tPC9GT05UPiA8QlI+PEJSPjxCUj4NCiAgPFRBQkxFIHdpZHRoPSIxMDAl Ij4NCiAgICA8VEJPRFk+DQogICAgPFRSIHZBbGlnbj10b3A+DQogICAgICA8VEQgd2lkdGg9IjQw JSI+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT48Qj4iemhhbmd3ZWkiIA0KICAgICAgICAm bHQ7emhhbmd3ZWlAc2ljdC5hYy5jbiZndDs8L0I+IDwvRk9OVD4NCiAgICAgICAgPFA+PEZPTlQg ZmFjZT1zYW5zLXNlcmlmIHNpemU9MT4wNi8xNi8yMDA2IDAxOjExIFBNPC9GT05UPiA8QlI+PC9Q Pg0KICAgICAgPFREIHdpZHRoPSI1OSUiPg0KICAgICAgICA8VEFCTEUgd2lkdGg9IjEwMCUiPg0K ICAgICAgICAgIDxUQk9EWT4NCiAgICAgICAgICA8VFI+DQogICAgICAgICAgICA8VEQ+DQogICAg ICAgICAgICAgIDxESVYgYWxpZ249cmlnaHQ+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT5U bzwvRk9OVD48L0RJVj4NCiAgICAgICAgICAgIDxURCB2QWxpZ249dG9wPjxGT05UIGZhY2U9c2Fu cy1zZXJpZiBzaXplPTE+U3VtaXQgDQogICAgICAgICAgICAgIERoYXIvQkxSL0hTU0BIU1M8L0ZP TlQ+IA0KICAgICAgICAgIDxUUj4NCiAgICAgICAgICAgIDxURD4NCiAgICAgICAgICAgICAgPERJ ViBhbGlnbj1yaWdodD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0xPmNjPC9GT05UPjwvRElW Pg0KICAgICAgICAgICAgPFREIHZBbGlnbj10b3A+DQogICAgICAgICAgPFRSPg0KICAgICAgICAg ICAgPFREPg0KICAgICAgICAgICAgICA8RElWIGFsaWduPXJpZ2h0PjxGT05UIGZhY2U9c2Fucy1z ZXJpZiBzaXplPTE+U3ViamVjdDwvRk9OVD48L0RJVj4NCiAgICAgICAgICAgIDxURCB2QWxpZ249 dG9wPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTE+SU5WSVRFIHJlcXVlc3QgYWZ0ZXIgDQog ICAgICAgICAgICAgIDMwMiByZXNwb25zZTwvRk9OVD48L1RSPjwvVEJPRFk+PC9UQUJMRT48QlI+ DQogICAgICAgIDxUQUJMRT4NCiAgICAgICAgICA8VEJPRFk+DQogICAgICAgICAgPFRSIHZBbGln bj10b3A+DQogICAgICAgICAgICA8VEQ+DQogICAgICAgICAgICA8VEQ+PC9UUj48L1RCT0RZPjwv VEFCTEU+PEJSPjwvVFI+PC9UQk9EWT48L1RBQkxFPjxCUj48QlI+PEJSPjxGT05UIA0KICBmYWNl PXNhbnMtc2VyaWYgc2l6ZT0yPkhpLDwvRk9OVD4gPEJSPjxGT05UIGZhY2U9c2Fucy1zZXJpZiAN CiAgc2l6ZT0zPiZuYnNwOzwvRk9OVD4gPEJSPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+ Jm5ic3A7ICZuYnNwO0luIFNJUCwgMzAyIA0KICBNb3ZlZCBUZW1wb3JhcmlseSBjYW4gYmUgdXNl ZCBieSBVc2VyIEFnZW50IHRvIHNldCBjYWxsIGZvcndhcmRpbmcuIFdoZW4gdGhlIA0KICBjYWxs ZXIgcmVjZWl2ZWQgMzAyLCBpdCBzaG91bGQgcmUtY3JlYXRlIGEgbmV3IElOVklURSByZXF1ZXN0 IHRvIGZvcndhcmQgY2FsbCANCiAgdG8gYSBnaXZlbiBjb250YWN0LjwvRk9OVD4gPEJSPjxGT05U IGZhY2U9c2Fucy1zZXJpZiBzaXplPTM+Jm5ic3A7PC9GT05UPiANCiAgPEJSPjxGT05UIGZhY2U9 c2Fucy1zZXJpZiBzaXplPTI+Jm5ic3A7ICZuYnNwO015IHF1ZXN0aW9uIGlzIGhvdyBQcm94eSBT ZXJ2ZXIgDQogIGRldGVjdCB3aGV0aGVyIElOVklURSBpcyBjcmVhdGVkIGFmdGVyIGhhdmluZyBy ZWNlaXZlZCAzMDIgcmVzcG9uc2UuIFRoZSBQcm94eSANCiAgU2VydmVyIGlzIHRyYW5zYWN0aW9u IHN0YXRlZnVsLiBXaGF0J3MgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBJTlZJVEUgYWZ0ZXIgMzAy IA0KICBhbmQgdGhlIG5vcm1hbCBJTlZJVEUgPyA8L0ZPTlQ+PEJSPjxGT05UIGZhY2U9c2Fucy1z ZXJpZiBzaXplPTM+Jm5ic3A7PC9GT05UPiANCiAgPEJSPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBz aXplPTM+Jm5ic3A7PC9GT05UPiA8QlI+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIA0KICBzaXplPTI+ UmVnYXJkczwvRk9OVD4gPEJSPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+WmhhbmcgV2Vp PC9GT05UPiANCiAgPEJSPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PEJSPjxCUj4qKioq KioqKioqKioqKioqKioqKioqKiAmbmJzcDtGU1MtIA0KICBDb25maWRlbnRpYWwgJm5ic3A7ICoq KioqKioqKioqKioqKioqKioqKioqPC9GT05UPiANCiAgPFRBQkxFPg0KICAgIDxUQk9EWT4NCiAg ICA8VFI+DQogICAgICA8VEQgYmdDb2xvcj0jZmZmZmZmPjxGT05UIGNvbG9yPSMwMDAwMDA+PFBS RT4iRElTQ0xBSU1FUjogVGhpcyBtZXNzYWdlIGlzIHByb3ByaWV0YXJ5IHRvIEZsZXh0cm9uaWNz IFNvZnR3YXJlIFN5c3RlbXMgKEZTUykgYW5kIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVz ZSBvZiANCnRoZSBpbmRpdmlkdWFsIHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBJdCBtYXkgY29u dGFpbiBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBhbmQgc2hvdWxkIG5v dCBiZSANCmNpcmN1bGF0ZWQgb3IgdXNlZCBmb3IgYW55IHB1cnBvc2Ugb3RoZXIgdGhhbiBmb3Ig d2hhdCBpdCBpcyBpbnRlbmRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGlu IGVycm9yLCANCnBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3IgaW1tZWRpYXRlbHkuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgbm90aWZpZWQgdGhhdCB5 b3UgYXJlIHN0cmljdGx5DQpwcm9oaWJpdGVkIGZyb20gdXNpbmcsIGNvcHlpbmcsIGFsdGVyaW5n LCBvciBkaXNjbG9zaW5nIHRoZSBjb250ZW50cyBvZiB0aGlzIG1lc3NhZ2UuIEZTUyBhY2NlcHRz IG5vIHJlc3BvbnNpYmlsaXR5IGZvciANCmxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUg dXNlIG9mIHRoZSBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBieSB0aGlzIGVtYWlsIGluY2x1ZGlu ZyBkYW1hZ2UgZnJvbSB2aXJ1cy4iDQo8L1BSRT48L0ZPTlQ+PC9URD48L1RSPjwvVEJPRFk+PC9U QUJMRT48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_00C2_01C69190.D0F65300-- --===============1597083646== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1597083646==-- From sip-bounces@ietf.org Fri Jun 16 10:29:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrFIE-0003RP-Jm; Fri, 16 Jun 2006 10:27:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrFID-0003RA-FA for sip@ietf.org; Fri, 16 Jun 2006 10:27:25 -0400 Received: from [217.205.209.100] (helo=vegastream.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrFIB-0000uq-G4 for sip@ietf.org; Fri, 16 Jun 2006 10:27:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Re: INVITE request after 302 response Date: Fri, 16 Jun 2006 15:27:22 +0100 Message-ID: <8F1F2062CA7D754A838F0E66097D23A074216C@veg-brk-svr-pri.vegastream> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: INVITE request after 302 response thread-index: AcaRTj1v5eRcBeZuQP+zB+sfiZCvqAAAiq6Q From: "Attila Sipos" To: "zhangwei" , "Sumit Dhar" , , "Lei Weimin" X-Spam-Score: 0.2 (/) X-Scan-Signature: e9eeacd7fe925d5f7faae01ed8f85b97 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0157278655==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0157278655== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69150.FB0EB898" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69150.FB0EB898 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 I am not an expert on it but maybe RFC4244 -"An Extension to the Session Initiation Protocol (SIP) for Request History Information" - can be used. ftp://ftp.rfc-editor.org/in-notes/rfc4244.txt =20 =20 Regards, =20 Attila =20 Attila Sipos http://www.vegastream.com =20 =20 -----Original Message----- From: zhangwei [mailto:zhangwei@sict.ac.cn] Sent: 16 June 2006 15:04 To: Sumit Dhar; sip@ietf.org; Lei Weimin Subject: [Sip] Re: INVITE request after 302 response Hello Sumit, =20 Thanks for your response. =20 Take an example for the application. =20 UA1 Proxy Server UA2 UA3 | | | | |---INVITE--->| | | | |---INVITE--> | | | |<----302 ------| | |<----302-------| | | | | | | |-----ACK---->| | | | |---ACK------>| | |---INVITE--->| | | | |------------INVITE---->| | |<--100/180/200------| |100/180/200| | | | | | | |----ACK----->| | | | |--------------ACK----->| =20 =20 Our project need to account according to INVITE/200/ACK and BYE. =20 =20 For the instance above, we want to make two accountings. One is UA1 call = UA2. The other is UA2 call UA3. =20 Our Proxy Server is transaction stateful. But we want that Proxy Server = can obtain UA1 UA2 and UA3's info only from the second INVITE request. =20 How can my Proxy Server obtain UA2's info only from the second INVITE = request?=20 =20 =20 Thanks & Best regards =20 Zhang Wei =20 ----- Original Message -----=20 From: Sumit Dhar =20 To: zhangwei =20 Sent: Friday, June 16, 2006 7:08 PM Subject: Re: INVITE request after 302 response Hello Mr Zhang,=20 Thanks for your mail.=20 I wasnt too sure however as to where you got my contacts from. I have = anyways organized a response for your question which is enclosed in my = mail.=20 May I request to know more details about the project you are working on, = and if we can possible collaborate .=20 Thanks & Best Regards,=20 Sumit=20 Response>=20 A typical 3261 compliant transaction stateful proxy would not be able to = distinguish if an INVITE is an initial INVITE sent by a UA=20 OR was sent subsequent to the reception of a 302 response. Also, a = transatcion stateful proxy need not know it.=20 An exception however is when a proxy is capable to performing recursion. = In this case, the proxy would interpret the 302 response=20 by itself and send a new INVITE to the redirected contact address.=20 If however, there is a need to know that an INVITE was redirected, one = option is to check the cseq number..=20 RFC 3261 recommends that the UA uses the same call-id, from-tag, to-tag = etc and just increment the cseq number for=20 a new INVITE towards the redirected address. However, this is just a = recommendation and may not be adhered to by the UA.=20 -------------------------------------------------------- Sumit Dhar =20 Segment Manager, Service Provider Products Business, Flextronics Software Systems (Formerly Hughes Software Systems) No. 18, Outer Ring Road, Panathur Post, Bangalore -560 087, India =20 Phone : +91-80-4106 7138 Fax : +91-80-4126 6501 =20 visit us at http://www.flextronicssoftware.com=20 "zhangwei" =20 06/16/2006 01:11 PM=20 To Sumit Dhar/BLR/HSS@HSS=20 cc Subject INVITE request after 302 response=09 =09 Hi,=20 =20 In SIP, 302 Moved Temporarily can be used by User Agent to set call = forwarding. When the caller received 302, it should re-create a new = INVITE request to forward call to a given contact.=20 =20 My question is how Proxy Server detect whether INVITE is created = after having received 302 response. The Proxy Server is transaction = stateful. What's the difference between INVITE after 302 and the normal = INVITE ?=20 =20 =20 Regards=20 Zhang Wei=20 *********************** FSS- Confidential ***********************=20 "DISCLAIMER: This message is proprietary to Flextronics Software Systems = (FSS) and is intended solely for the use of=20 the individual to whom it is addressed. It may contain privileged or = confidential information and should not be=20 circulated or used for any purpose other than for what it is intended. = If you have received this message in error,=20 please notify the originator immediately. If you are not the intended = recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of = this message. FSS accepts no responsibility for=20 loss or damage arising from the use of the information transmitted by = this email including damage from virus." ------_=_NextPart_001_01C69150.FB0EB898 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
I am=20 not an expert on it but maybe RFC4244 -"An=20 Extension
to the=20 Session Initiation Protocol (SIP) for Request = History
Information" - can be = used.
ftp://ftp.rfc-edit= or.org/in-notes/rfc4244.txt
 
 
Regards,
 
Attila
 
Attila=20 Sipos
http://www.vegastream.com
 
 
-----Original Message-----
From: zhangwei=20 [mailto:zhangwei@sict.ac.cn]
Sent: 16 June 2006 = 15:04
To:=20 Sumit Dhar; sip@ietf.org; Lei Weimin
Subject: [Sip] Re: = INVITE=20 request after 302 response

Hello Sumit,
 
Thanks for your = response.
 
Take an example for the = application.
 
UA1      = Proxy=20 Server    UA2    UA3
|          &nb= sp;    =20  =20 = |            =    =20   |         |
|---INVITE--->|       &nbs= p;         =20 |         |
|          &nb= sp;      =20 |---INVITE--> |  =20       |
|          &nb= sp;      =20 |<----302 ------|         = |
|<----302-------|       &n= bsp; =20         |  =20       |
|          &nbs= p;      =20 |       =20           |  =20       |
|-----ACK---->|       &nbs= p;        =20  |         |
|          &nb= sp;     =20  |---ACK------>|        =20 |
|---INVITE--->|       &nbs= p;        =20  |         |
|          &nb= sp;      =20 |------------INVITE---->|
|          &nb= sp;    =20   |<--100/180/200------|
|100/180/200|      =20            = |  =20       |
|          &nb= sp;      =20 |         =20         |   =20      |
|----ACK----->|       &nbs= p;       =20   |         |
|          &nb= sp;      =20 |--------------ACK----->|
 
 
Our project need to account according = to=20 INVITE/200/ACK and BYE.  
 
For the instance above, we want to = make two=20 accountings. One is UA1 call UA2. The other is UA2 call = UA3.
 
Our Proxy Server is transaction = stateful. But we=20 want that Proxy Server can obtain UA1 UA2 and UA3's info only from the = second=20 INVITE request.
 
How can my Proxy Server obtain UA2's=20 info only from the second INVITE request? 
 
 
Thanks & Best = regards
 
Zhang Wei
 
----- Original Message = -----
From: Sumit Dhar =
Sent: Friday, June = 16, 2006 7:08 PM
Subject: Re: INVITE = request after 302=20 response


Hello Mr = Zhang,=20

Thanks for your = mail.=20

I wasnt too sure however as = to where=20 you got my contacts from. I have anyways organized a response for = your=20 question which is enclosed in my mail.

May I request to know more details about the project you = are working=20 on, and if we can possible collaborate .

Thanks & Best Regards, =

Sumit

Response>
A = typical 3261=20 compliant transaction stateful proxy would not be able to = distinguish if an=20 INVITE is an initial INVITE sent by a UA
OR was sent subsequent to the reception of a 302 response. = Also, a=20 transatcion stateful proxy need not know it.
An exception however is when a proxy is = capable to=20 performing recursion. In this case, the proxy would interpret the = 302=20 response
by itself and = send a new=20 INVITE to the redirected contact address.


If however, there is a need to know that = an INVITE=20 was redirected, one option is to check the cseq number.. =
RFC 3261 recommends that the UA uses the = same=20 call-id, from-tag, to-tag etc and just increment the cseq number = for=20
a new INVITE towards the = redirected=20 address. However, this is just a recommendation and may not be = adhered to by=20 the UA.





------------------------------------------------= --------
 Sumit=20 Dhar          
 Segment=20 Manager,
 Service Provider Products = Business,
 Flextronics=20 Software Systems
 (Formerly Hughes Software = Systems)
 No.=20 18, Outer Ring Road, Panathur Post,
 Bangalore -560 087, =  India=20              
 Phone =  :=20 +91-80-4106 7138  Fax     : +91-80-4126 6501  =20
 visit us at http://www.flextronicssoftware.com =


"zhangwei" = <zhangwei@sict.ac.cn>

06/16/2006 01:11 PM =

To
Sumit=20 Dhar/BLR/HSS@HSS=20
cc
Subject
INVITE = request after=20 302 response

=




<= FONT=20 face=3Dsans-serif size=3D2>Hi,
 
  =  In SIP,=20 302 Moved Temporarily can be used by User Agent to set call = forwarding. When=20 the caller received 302, it should re-create a new INVITE request to = forward=20 call to a given contact.
 
  =  My=20 question is how Proxy Server detect whether INVITE is created after = having=20 received 302 response. The Proxy Server is transaction stateful. = What's the=20 difference between INVITE after 302 and the normal INVITE ? =
 
 
Regards=20
Zhang Wei


***********************  FSS- Confidential =  =20 ***********************=20 
"DISCLAIMER: =
This message is proprietary to Flextronics Software Systems (FSS) and is =
intended solely for the use of=20
the individual to whom it is addressed. It may contain privileged or =
confidential information and should not be=20
circulated or used for any purpose other than for what it is intended. =
If you have received this message in error,=20
please notify the originator immediately. If you are not the intended =
recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of =
this message. FSS accepts no responsibility for=20
loss or damage arising from the use of the information transmitted by =
this email including damage from virus."
<= /HTML> ------_=_NextPart_001_01C69150.FB0EB898-- --===============0157278655== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0157278655==-- From sip-bounces@ietf.org Fri Jun 16 10:33:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrFMq-0006ZU-Ue; Fri, 16 Jun 2006 10:32:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrFMp-0006ZI-CN for sip@ietf.org; Fri, 16 Jun 2006 10:32:11 -0400 Received: from [217.205.209.100] (helo=vegastream.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrFMm-0001Us-QN for sip@ietf.org; Fri, 16 Jun 2006 10:32:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: INVITE request after 302 response Date: Fri, 16 Jun 2006 15:32:08 +0100 Message-ID: <8F1F2062CA7D754A838F0E66097D23A0C23CDA@veg-brk-svr-pri.vegastream> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: INVITE request after 302 response thread-index: AcaRTj1v5eRcBeZuQP+zB+sfiZCvqAAAiq6QAABvYMA= From: "Attila Sipos" To: "zhangwei" , "Sumit Dhar" , , "Lei Weimin" X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think "Appendix B. Voicemail" has an example that may be useful for you.... UA1 Proxy UA-A UA-B UA-VM | | | | | |--INVITE F1-->| | | | | | | | | | |--INVITE F2-->| | | |<--100 F3-----| | | | | |<-302 F4------| | | | | | | | | |--------INVITE F5---------->| | | | | | | | |<--------180 F6-------------| | |<---180 F7----| | | | | . . . | | | | | |------retransmit INVITE---->| | | . . . | | | | | | (timeout) | | | | | | | | |-------INVITE F8---------------------->| | | | | | | |<-200 F9-------------------------------| | | | | | |<-200 F10-----| | | | | | | | | |--ACK F11-------------------------------------------->| Regards, Attila -----Original Message----- From: Attila Sipos=20 Sent: 16 June 2006 15:27 To: 'zhangwei'; Sumit Dhar; sip@ietf.org; Lei Weimin Subject: RE: [Sip] Re: INVITE request after 302 response I am not an expert on it but maybe RFC4244 -"An Extension to the Session Initiation Protocol (SIP) for Request History Information" - can be used. ftp://ftp.rfc-editor.org/in-notes/rfc4244.txt Regards, Attila Attila Sipos http://www.vegastream.com -----Original Message----- From: zhangwei [mailto:zhangwei@sict.ac.cn] Sent: 16 June 2006 15:04 To: Sumit Dhar; sip@ietf.org; Lei Weimin Subject: [Sip] Re: INVITE request after 302 response Hello Sumit, Thanks for your response. Take an example for the application. UA1 Proxy Server UA2 UA3 | | | | |---INVITE--->| | | | |---INVITE--> | | | |<----302 ------| | |<----302-------| | | | | | | |-----ACK---->| | | | |---ACK------>| | |---INVITE--->| | | | |------------INVITE---->| | |<--100/180/200------| |100/180/200| | | | | | | |----ACK----->| | | | |--------------ACK----->| Our project need to account according to INVITE/200/ACK and BYE. =20 For the instance above, we want to make two accountings. One is UA1 call = UA2. The other is UA2 call UA3. Our Proxy Server is transaction stateful. But we want that Proxy Server = can obtain UA1 UA2 and UA3's info only from the second INVITE request. How can my Proxy Server obtain UA2's info only from the second INVITE = request?=20 Thanks & Best regards Zhang Wei ----- Original Message -----=20 From: Sumit Dhar=20 To: zhangwei=20 Sent: Friday, June 16, 2006 7:08 PM Subject: Re: INVITE request after 302 response Hello Mr Zhang,=20 Thanks for your mail.=20 I wasnt too sure however as to where you got my contacts from. I have = anyways organized a response for your question which is enclosed in my = mail.=20 May I request to know more details about the project you are working on, = and if we can possible collaborate .=20 Thanks & Best Regards,=20 Sumit=20 Response>=20 A typical 3261 compliant transaction stateful proxy would not be able to = distinguish if an INVITE is an initial INVITE sent by a UA=20 OR was sent subsequent to the reception of a 302 response. Also, a = transatcion stateful proxy need not know it.=20 An exception however is when a proxy is capable to performing recursion. = In this case, the proxy would interpret the 302 response=20 by itself and send a new INVITE to the redirected contact address.=20 If however, there is a need to know that an INVITE was redirected, one = option is to check the cseq number..=20 RFC 3261 recommends that the UA uses the same call-id, from-tag, to-tag = etc and just increment the cseq number for=20 a new INVITE towards the redirected address. However, this is just a = recommendation and may not be adhered to by the UA.=20 -------------------------------------------------------- Sumit Dhar =20 Segment Manager, Service Provider Products Business, Flextronics Software Systems (Formerly Hughes Software Systems) No. 18, Outer Ring Road, Panathur Post, Bangalore -560 087, India =20 Phone : +91-80-4106 7138 Fax : +91-80-4126 6501 =20 visit us at http://www.flextronicssoftware.com=20 "zhangwei" =20 06/16/2006 01:11 PM=20 ToSumit Dhar/BLR/HSS@HSS=20 cc SubjectINVITE request after 302 response Hi,=20 =20 In SIP, 302 Moved Temporarily can be used by User Agent to set call = forwarding. When the caller received 302, it should re-create a new = INVITE request to forward call to a given contact.=20 =20 My question is how Proxy Server detect whether INVITE is created = after having received 302 response. The Proxy Server is transaction = stateful. What's the difference between INVITE after 302 and the normal = INVITE ?=20 =20 =20 Regards=20 Zhang Wei=20 *********************** FSS- Confidential *********************** = "DISCLAIMER: This message is proprietary to Flextronics Software Systems = (FSS) and is intended solely for the use of=20 the individual to whom it is addressed. It may contain privileged or = confidential information and should not be=20 circulated or used for any purpose other than for what it is intended. = If you have received this message in error,=20 please notify the originator immediately. If you are not the intended = recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of = this message. FSS accepts no responsibility for=20 loss or damage arising from the use of the information transmitted by = this email including damage from virus." _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 16 13:47:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIOL-0005ey-8Q; Fri, 16 Jun 2006 13:45:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIOK-0005et-7S for sip@ietf.org; Fri, 16 Jun 2006 13:45:56 -0400 Received: from [2001:5c0:8fff:fffe::4c49] (helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrIOH-00055K-KE for sip@ietf.org; Fri, 16 Jun 2006 13:45:56 -0400 Received: from [172.17.2.252] (dsl001-129-070.dfw1.dsl.speakeasy.net [72.1.129.70]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k5GHjin6034951 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 16 Jun 2006 12:45:49 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <18F72A6C-6A17-411B-B5C1-91F3DA886A50@softarmor.com> References: <18F72A6C-6A17-411B-B5C1-91F3DA886A50@softarmor.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <01C1A6BF-E499-4287-BDEB-546BC5991963@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Certs draft movement? Date: Fri, 16 Jun 2006 12:45:43 -0500 To: Dean Willis X-Mailer: Apple Mail (2.750) Received-SPF: pass (nostrum.com: 72.1.129.70 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I still believe what's in this draft is a good, and important, idea and am contributing to finish the work. RjS (and I've got plenty of other things to do than bark at a draft just for the, um, joy of barking) On Jun 15, 2006, at 4:50 PM, Dean Willis wrote: > > Once upon a time, a friend of mine had a dog that we thought liked > to chase squirrels. When a squirrel would run up a tree, the dog > would run to the tree and start barking. After a while, we noticed > that the dog was just barking at trees whether they had a squirrel > in them or not, and we realized that the dog wasn't all that > worried about squirrels anymore. He'd gotten so used to barking at > trees that he thought this was now his goal. > > So in putting the draft agenda together for Montreal, I noticed the > new certs draft, draft-ietf-sip-certs-00.txt, and I thought about > how I felt about the topic. It's definitely something I once chased > after, like that dog chasing a squirrel. But Now I'm wondering > where the "certs squirrel" went. > > Do we really believe in the certs draft, or are we just barking at > a tree out of habit? > > -- > 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 Jun 16 13:59:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIZK-0004Uv-NN; Fri, 16 Jun 2006 13:57:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIZI-0004TM-RB for sip@ietf.org; Fri, 16 Jun 2006 13:57:16 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FrIZH-0005i3-Ci for sip@ietf.org; Fri, 16 Jun 2006 13:57:16 -0400 Received: (qmail invoked by alias); 16 Jun 2006 17:57:13 -0000 Received: from p549877FA.dip.t-dialin.net (EHLO [192.168.2.35]) [84.152.119.250] by mail.gmx.net (mp040) with SMTP; 16 Jun 2006 19:57:13 +0200 X-Authenticated: #29516787 Message-ID: <4492F0F7.7050700@gmx.net> Date: Fri, 16 Jun 2006 19:57:11 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Certs draft movement? References: <18F72A6C-6A17-411B-B5C1-91F3DA886A50@softarmor.com> In-Reply-To: <18F72A6C-6A17-411B-B5C1-91F3DA886A50@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Dean, at the last IETF I volunteered to contribute to this draft. I think it is a very important piece in the (SIP) security puzzle. Ciao Hannes Dean Willis wrote: > > Once upon a time, a friend of mine had a dog that we thought liked to > chase squirrels. When a squirrel would run up a tree, the dog would run > to the tree and start barking. After a while, we noticed that the dog > was just barking at trees whether they had a squirrel in them or not, > and we realized that the dog wasn't all that worried about squirrels > anymore. He'd gotten so used to barking at trees that he thought this > was now his goal. > > So in putting the draft agenda together for Montreal, I noticed the new > certs draft, draft-ietf-sip-certs-00.txt, and I thought about how I > felt about the topic. It's definitely something I once chased after, > like that dog chasing a squirrel. But Now I'm wondering where the > "certs squirrel" went. > > Do we really believe in the certs draft, or are we just barking at a > tree out of habit? > > -- > 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 Jun 16 14:11:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIlk-0003gM-4x; Fri, 16 Jun 2006 14:10:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIlj-0003gF-3l for sip@ietf.org; Fri, 16 Jun 2006 14:10:07 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrIlh-0006fZ-PK for sip@ietf.org; Fri, 16 Jun 2006 14:10:07 -0400 Received: from [192.168.2.104] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5GIBYl3009580 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 16 Jun 2006 13:11:35 -0500 Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF SIP List From: Dean Willis Date: Fri, 16 Jun 2006 13:10:03 -0500 X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Sip] Agenda revised X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org based on some initial feedback, I've tweaked the draft agenda a bit: https://www.softarmor.com/sipwg/meets/ietf66/agenda.html -- 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 Jun 16 14:16:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIpk-0007ib-Ns; Fri, 16 Jun 2006 14:14:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIpj-0007iO-IS for sip@ietf.org; Fri, 16 Jun 2006 14:14:15 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrIpi-0007TR-8K for sip@ietf.org; Fri, 16 Jun 2006 14:14:15 -0400 Received: from [192.168.2.104] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5GIFhaK009606 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 16 Jun 2006 13:15:43 -0500 Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Fri, 16 Jun 2006 13:14:12 -0500 To: sip@ietf.org X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Cullen Jennings , Keith Drage Subject: [Sip] Special breakout for the lock-icon discussion? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org We had this 500-message wacky thread about SIP security, sips:, tls, and the hopping bunny "lock icon" problem. My hunch is there's more there than can be wedged into a regular meeting, and that it's more important than we had previously realized. If we could get a break-out room in Montreal for an "ad-hoc" discussion of the SIP Lock Icon problem, how many people think they might show up? -- 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 Jun 16 14:22:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIw2-0003Nl-T0; Fri, 16 Jun 2006 14:20:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIw1-0003Ng-88 for sip@ietf.org; Fri, 16 Jun 2006 14:20:45 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrIvz-0008Ok-W7 for sip@ietf.org; Fri, 16 Jun 2006 14:20:45 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 16 Jun 2006 14:20:44 -0400 X-IronPort-AV: i="4.06,143,1149480000"; d="scan'208"; a="90238811:sNHT29703696" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5GIKhYL012573; Fri, 16 Jun 2006 14:20:43 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Jun 2006 14:20:43 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.16.150]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Jun 2006 14:20:42 -0400 Message-Id: <4.3.2.7.2.20060616132004.03da9ea0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 16 Jun 2006 13:20:41 -0500 To: Dean Willis , sip@ietf.org From: "James M. Polk" Subject: Re: [Sip] Special breakout for the lock-icon discussion? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 16 Jun 2006 18:20:42.0901 (UTC) FILETIME=[941EB450:01C69171] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Cullen Jennings , Keith Drage X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 01:14 PM 6/16/2006 -0500, Dean Willis wrote: >We had this 500-message wacky thread about SIP security, sips:, tls, >and the hopping bunny "lock icon" problem. > >My hunch is there's more there than can be wedged into a regular >meeting, and that it's more important than we had previously realized. > >If we could get a break-out room in Montreal for an "ad-hoc" >discussion of the SIP Lock Icon problem, how many people think they >might show up? conflicts matter in answering... >-- >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 Jun 16 15:20:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrJq4-0002Qm-80; Fri, 16 Jun 2006 15:18:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrJq2-0002Qg-Sd for sip@ietf.org; Fri, 16 Jun 2006 15:18:38 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrJq1-0007HR-7Y for sip@ietf.org; Fri, 16 Jun 2006 15:18:38 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 16 Jun 2006 12:18:36 -0700 X-IronPort-AV: i="4.06,144,1149490800"; d="scan'208"; a="296064715:sNHT162756422" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k5GJIaiD021877; Fri, 16 Jun 2006 12:18:36 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5GJIZcN001306; Fri, 16 Jun 2006 12:18:36 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Jun 2006 15:18:35 -0400 Received: from [192.168.1.101] ([10.82.225.127]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Jun 2006 15:18:35 -0400 Message-ID: <4493040A.5040307@cisco.com> Date: Fri, 16 Jun 2006 15:18:34 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] updated GRUU spec References: <4490BF1C.4050304@cisco.com> <007b01c690a0$4b0b59c0$31713b51@BEMBUSTER> <3BA07DF8-55FF-4836-9EF7-4235310D8D30@softarmor.com> In-Reply-To: <3BA07DF8-55FF-4836-9EF7-4235310D8D30@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2006 19:18:35.0548 (UTC) FILETIME=[A9FA95C0:01C69179] DKIM-Signature: a=rsa-sha1; q=dns; l=6671; t=1150485516; x=1151349516; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20updated=20GRUU=20spec; X=v=3Dcisco.com=3B=20h=3DCUdLAyjyiWnemXjhyFeXb4tsT1o=3D; b=KGeolEWGDyMF4cnV9aYcsnHXJVo1skB45OFW91cS4mNNiF4/ILALyeXgNPt8YW8aKVfuVV4J fHLN9OpRliTiacRPv/gee6QRQfvpeScmdEzy8Yb4fH3znp3F47VtixIw; Authentication-Results: sj-dkim-5.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: IETF SIP List , Keith Drage X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Dean Willis wrote: > > On Jun 15, 2006, at 12:22 PM, Jeroen van Bemmel wrote: > >> OK, Dean. Here goes > > > ask and ye shall receive . . . > > >> >> 1) The protocol bits that trigger issueing of a GRUU are "Supported: >> gruu" and a sip.instance id in the Contact header. If "supported" >> then "MUST issue GRUU". If you compare this with e.g. 100rel it seems >> a bit odd, Supported: 100rel does not force the server to use it. How >> about Supported -> SHOULD, Require -> MUST ? (could a domain have >> reasons not to honor the request for GRUUs?) >> > > We had an extended thread on that one, and ended up with the current > position. > > Supported: alone cannot require a UAS to do anything. It's just a hint > that tells the UAS (in this case the registrar) that the UAC supports a > specific extension and cn be expected to behave accordingly. > > Require: also cannot force a UAS to use an extension -- it just makes > sure that the UAS understand the extension, which is not the same > thing. For example, I understand polygamy, I just don't use it (well, I > might someday, but I'm single right now). > > The basic idea is that it any UA that supports GRUU and issues a > request with a sip.instance ID is asking for and really wants A GRUU. > So a registrar that understands GRUU must issues one when the client > asks for it or reject the request if it can't. The thing that is requiring the registrar to give out a GRUU is the spceification itself. As Dean says, Supported means that the client understands gruu and is prepared to receive one. The registrar hands one out if it supports gruu too. If the registrar doesn't, the registration is processed normally. The bit I disagree with Dean on is that the registrar never rejects the request. Only case that happens is if the client puts a Require in the REGISTER, and the registrar doesn't support gruu. Indeed, note that the registrar will create a gruu even if the client doesn't support it, as long as instance ID was there. The reason is that even though the client doesn't support gruu, other elements listening to reg-event will get notified, and with the gruu reg-event extension, need to see that gruu. This is called out later in the spec: Inclusion of a GRUU in the "gruu" Contact header field parameter of a REGISTER response is separate from the computation and storage of the GRUU. It is possible that the registrar has computed a GRUU for one UA, but a different UA that queries for the current set of registrations doesn't understand GRUU. In that case, the REGISTER response sent to that second UA would not contain the "gruu" Contact header field parameter, even though the UA has a GRUU for that contact. > >> 1a) Which error response if "Supported: gruu" but missing >> sip.instance? bad request? >> > > None. We just don't issue a gruu if we don't want to. The UAC hasn't > insisted that it really wants one, so that's OK. Slight correction - it *can't* issue a gruu at all for contacts without instance ID. Remember that a GRUU is bound to an AOR and instance ID. So, unless you have both, you can't issue one. Its not like it just doesn't want to; it cannot. Its really important to understand that in NO WAY is this an error condition (contacts without instance ID). Third party registrations, for example, are allowed and will typically not contian an instance ID. > >> 2) There are several references to "dialog-creating" requests and >> responses for which GRUU can be used. This should be extended to >> include "target-refresh" requests such as UPDATE, and REGISTER (in >> rare cases) > > > Yeah, probably true. Right - fixed. > >> >> 3) section 6: the list on GRUU properties that MUST be exhibited >> should probably include "if the URI includes an "opaque" parameter, >> the base MUST be an AoR". The text later on depends on this >> > > Ok, that's worthy of consideration. Correct. I added that. > > >> 4) 7.1.1.1 says "MUST include Supported" . Does "Require" imply >> "Supported"? >> > > Nope. Require does not imply Supported. Strange but true. Right. I added a sentence to clarify that. > >> 5) 7.1.2.1 the part that says "MUST do so at this time" is too early. >> The REGISTER might be constructed according to outbound without >> Supported: gruu. I think 7.1.2.1 should start with "If REGISTER >> contains Supported: gruu, THEN { process as described here }" >> > > Ok, this might need talking about. I don't understand the issue you are raising. If the REGISTER is constructed using sip-outbound there is still an instnace ID. What changes? > >> 6) 7.1.2.1 talks only about Supported, should probably say "Supported >> or Require" >> > > I don't think so -- as above, Require does not imply Supported. Right - its just Supported. > >> 7) 8.2.1 : I still feel that GRUU offers a great opportunity to start >> introducing looser routing. The spec already requires modifications >> to both proxies and UAs, so saying "proxy adds Route header" instead >> of "proxy rewrites request URI" seems a small effort. We'll be sorry >> later if we don't > > > I'm already sorry ;-(. > > But we seem to have a consensus to do the route construction > modification separately. Right. We have the tools (via Require/Supported) to negotiate it separately. > >> >> 8) c-p-gruu = "gruu" EQUAL LDQUOT (SIP-URI / SIPS-URI) >> RDQUOT, another draft authored by JR uses "DQUOTE" here...do we want >> consistency? > > > I thought the grammar guideline changed when the new grammar RFC came > out. I'm not a BNF whiz though -- anybody know for sure? No - this is a change I made based on private comments on the draft. Doing this makes it consistent with 3261 syntax, which uses LDQUOT/RDQUOT around header parameters. > >> >> 9) Section 12: some of the to-headers have the closing '>' one line >> too early; last message is missing an start tag > > > Grr. Ok, that's a bug. Good catch. I fixed two instances of the early '>' and the missing allOneLine. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 16 16:15:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrKgy-000553-8h; Fri, 16 Jun 2006 16:13:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrKgw-00053s-3c for sip@ietf.org; Fri, 16 Jun 2006 16:13:18 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrKgu-0004Nd-Ro for sip@ietf.org; Fri, 16 Jun 2006 16:13:18 -0400 Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126]) by borg.juniper.net with ESMTP; 16 Jun 2006 13:13:15 -0700 X-IronPort-AV: i="4.06,143,1149490800"; d="scan'208,217"; a="559976115:sNHT63307152" Received: from hadron.jnpr.net ([172.24.15.25]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jun 2006 13:13:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 16 Jun 2006 13:13:15 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Latest draft that references draft-ietf-simple-im-session-00 Thread-Index: AcaRgUzE3EWwmoPZQ5K42lNIiOF64A== From: "Anil Bollineni" To: X-OriginalArrivalTime: 16 Jun 2006 20:13:15.0979 (UTC) FILETIME=[4D44A1B0:01C69181] X-Spam-Score: 0.2 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: sip@ietf.org Subject: [Sip] Latest draft that references draft-ietf-simple-im-session-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2042583266==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2042583266== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69181.4CE18C67" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69181.4CE18C67 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi All, =20 Can you tell me what is the latest draft that replaces "draft-ietf-simple-im-session-00" draft.=20 =20 Thanks, Anil ------_=_NextPart_001_01C69181.4CE18C67 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi All,

 

Can you tell me what is the latest draft that = replaces “draft-ietf-simple-im-session-00” draft.

 

Thanks,

Anil

------_=_NextPart_001_01C69181.4CE18C67-- --===============2042583266== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2042583266==-- From sip-bounces@ietf.org Fri Jun 16 17:36:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrLy1-0001Me-Tp; Fri, 16 Jun 2006 17:35:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrLxz-0001Jo-Mm for sip@ietf.org; Fri, 16 Jun 2006 17:34:59 -0400 Received: from [2001:5c0:8fff:fffe::4c3d] (helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrLnw-0003qg-8T for sip@ietf.org; Fri, 16 Jun 2006 17:24:38 -0400 Received: from [172.17.1.114] ([172.17.1.114]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k5GLOLwE058705 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 16 Jun 2006 16:24:22 -0500 (CDT) (envelope-from ben@estacado.net) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Message-Id: <5298599C-6192-43BE-B6B9-EC541952EC79@estacado.net> From: Ben Campbell Subject: Re: [Sip] Latest draft that references draft-ietf-simple-im-session-00 Date: Fri, 16 Jun 2006 16:24:15 -0500 To: Anil Bollineni X-Mailer: Apple Mail (2.750) X-Spam-Score: -2.8 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip@ietf.org, sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0765176602==" Errors-To: sip-bounces@ietf.org --===============0765176602== Content-Type: multipart/alternative; boundary=Apple-Mail-1-387163411 --Apple-Mail-1-387163411 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Assuming you mean "message-sessions" rather than "im-session": http://www.ietf.org/internet-drafts/draft-ietf-simple-message-=20 sessions-14.txt On Jun 16, 2006, at 3:13 PM, Anil Bollineni wrote: > Hi All, > > > > Can you tell me what is the latest draft that replaces =93draft-ietf-=20= > simple-im-session-00=94 draft. > > > > Thanks, > > Anil > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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-1-387163411 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252
Assuming you mean = "message-sessions" rather than "im-session":


On Jun 16, 2006, at 3:13 PM, = Anil Bollineni wrote:

Hi = All,

=A0

Can you tell me what is = the latest draft that replaces = =93draft-ietf-simple-im-session-00=94 draft. =

=A0

Thanks,

Anil

This list is = for NEW development of the core SIP Protocol
Use sip-implementors@cs.colum= bia.edu for questions on current sip
Use sipping@ietf.org for new = developments on the application of sip
=

= --Apple-Mail-1-387163411-- --===============0765176602== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0765176602==-- From sip-bounces@ietf.org Fri Jun 16 17:37:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrLz3-00033h-8c; Fri, 16 Jun 2006 17:36:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrLxr-0001Ge-Kf for sip@ietf.org; Fri, 16 Jun 2006 17:34:51 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrLxe-0004Ug-B2 for sip@ietf.org; Fri, 16 Jun 2006 17:34:39 -0400 Received: (qmail 9967 invoked by uid 0); 16 Jun 2006 21:34:30 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 16 Jun 2006 21:34:30 -0000 Message-ID: <00f901c6918c$a60767f0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Jonathan Rosenberg" , "Dean Willis" References: <4490BF1C.4050304@cisco.com> <007b01c690a0$4b0b59c0$31713b51@BEMBUSTER> <3BA07DF8-55FF-4836-9EF7-4235310D8D30@softarmor.com> <4493040A.5040307@cisco.com> Subject: Re: [Sip] updated GRUU spec Date: Fri, 16 Jun 2006 23:34:29 +0200 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.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: IETF SIP List , Keith Drage X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan, inline Regards, jeroen > Indeed, note that the registrar will create a gruu even if the client > doesn't support it, as long as instance ID was there. The reason is that > even though the client doesn't support gruu, other elements listening to > reg-event will get notified, and with the gruu reg-event extension, need > to see that gruu. This is called out later in the spec: > > Inclusion of a GRUU in the "gruu" Contact header field parameter of a > REGISTER response is separate from the computation and storage of the > GRUU. It is possible that the registrar has computed a GRUU for one > UA, but a different UA that queries for the current set of > registrations doesn't understand GRUU. In that case, the REGISTER > response sent to that second UA would not contain the "gruu" Contact > header field parameter, even though the UA has a GRUU for that > contact. > I did not make the connection that through reg-event another element could receive the GRUU, and use it / distribute it. As a consequence, the UA could receive a request with a request URI containing something else than its registered Contact. Harmless enough I suppose >> >>> 1a) Which error response if "Supported: gruu" but missing sip.instance? >>> bad request? >>> >> >> None. We just don't issue a gruu if we don't want to. The UAC hasn't >> insisted that it really wants one, so that's OK. > > Slight correction - it *can't* issue a gruu at all for contacts without > instance ID. Remember that a GRUU is bound to an AOR and instance ID. So, > unless you have both, you can't issue one. Its not like it just doesn't > want to; it cannot. > > Its really important to understand that in NO WAY is this an error > condition (contacts without instance ID). Third party registrations, for > example, are allowed and will typically not contian an instance ID. > > Perhaps worth mentioning as a valid case (note to implementors) >> >>> 5) 7.1.2.1 the part that says "MUST do so at this time" is too early. >>> The REGISTER might be constructed according to outbound without >>> Supported: gruu. I think 7.1.2.1 should start with "If REGISTER >>> contains Supported: gruu, THEN { process as described here }" >>> >> >> Ok, this might need talking about. > > I don't understand the issue you are raising. If the REGISTER is > constructed using sip-outbound there is still an instnace ID. What > changes? > it was related to my assumption that a registrar would have no need to create a GRUU if the UA did not support it _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 16 18:01:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrMME-0004NO-HV; Fri, 16 Jun 2006 18:00:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrMMD-0004N9-H2 for sip@ietf.org; Fri, 16 Jun 2006 18:00:01 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrMMB-0007jV-R9 for sip@ietf.org; Fri, 16 Jun 2006 18:00:01 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id D50316C017 for ; Fri, 16 Jun 2006 17:59:57 -0400 (EDT) From: Scott Lawrence To: SIP WG List Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Fri, 16 Jun 2006 17:59:57 -0400 Message-Id: <1150495197.10237.51.camel@sukothai.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Sip] draft-ietf-sip-hop-limit-diagnostics-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: , Errors-To: sip-bounces@ietf.org I've just submitted another version of "Diagnostic Responses for Session Initiation Protocol Hop Limit Errors". It should appear in the canonical places soon, but in the mean time you can get it from: http://scm.sipfoundry.org/rep/ietf-drafts/lawrence/hopcopy/draft-ietf-sip-hop-limit-diagnostics-03.html or http://scm.sipfoundry.org/rep/ietf-drafts/lawrence/hopcopy/draft-ietf-sip-hop-limit-diagnostics-03.txt I've addressed most of the comments we got over the last couple of weeks, and the spec is better for it. There are, I think, two issues remaining for discussion: 1) Should a specific warning code be defined for this usage so that, as Dale suggests "there is hope that an automaton (traceroute-like program) will be able to interpret the responses". 2) Should the suggested usage of this error response be expanded to include more unrecoverable errors. The argument being that it's probably useful for other conditions that the UA would otherwise be unable to diagnose. My own feeling is that it should, and I'm happy to suggest a specific list of such errors, but it seemed to me and to my co-authors that this would be an expansion of the scope and deserved WG discussion. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.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 Jun 16 18:10:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrMV4-0005IC-94; Fri, 16 Jun 2006 18:09:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrMV2-0005I7-PM for sip@ietf.org; Fri, 16 Jun 2006 18:09:08 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrMV1-0000DR-HI for sip@ietf.org; Fri, 16 Jun 2006 18:09:08 -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 k5GM96Fm015844; Fri, 16 Jun 2006 17:09:06 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k5GM93E24679; Fri, 16 Jun 2006 17:09:06 -0500 (CDT) Message-ID: <44932C00.9010705@lucent.com> Date: Fri, 16 Jun 2006 17:09:04 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Special breakout for the lock-icon discussion? 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: 7d33c50f3756db14428398e2bdedd581 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > We had this 500-message wacky thread about SIP security, sips:, tls, > and the hopping bunny "lock icon" problem. > > My hunch is there's more there than can be wedged into a regular > meeting, and that it's more important than we had previously realized. > > If we could get a break-out room in Montreal for an "ad-hoc" discussion > of the SIP Lock Icon problem, how many people think they might show up? I will. An I-D on this will be submitted before the -00 deadline (yikes! less than 72 hours to go!) Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 16 18:57:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrNEM-0005WG-Be; Fri, 16 Jun 2006 18:55:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrNEK-0005Vj-0v for sip@ietf.org; Fri, 16 Jun 2006 18:55:56 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrNEI-0007HN-Co for sip@ietf.org; Fri, 16 Jun 2006 18:55:56 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 16 Jun 2006 15:55:54 -0700 X-IronPort-AV: i="4.06,144,1149490800"; d="scan'208"; a="296182584:sNHT35333494" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k5GMtrXs022786; Fri, 16 Jun 2006 15:55:53 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5GMtpcL029873; Fri, 16 Jun 2006 15:55:51 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Jun 2006 15:55:53 -0700 Received: from [192.168.1.101] ([10.82.225.127]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Jun 2006 15:55:52 -0700 Message-ID: <449336F7.9020908@cisco.com> Date: Fri, 16 Jun 2006 18:55:51 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] updated GRUU spec References: <4490BF1C.4050304@cisco.com> <007b01c690a0$4b0b59c0$31713b51@BEMBUSTER> <3BA07DF8-55FF-4836-9EF7-4235310D8D30@softarmor.com> <4493040A.5040307@cisco.com> <00f901c6918c$a60767f0$31713b51@BEMBUSTER> In-Reply-To: <00f901c6918c$a60767f0$31713b51@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2006 22:55:52.0602 (UTC) FILETIME=[04AB27A0:01C69198] DKIM-Signature: a=rsa-sha1; q=dns; l=4408; t=1150498553; x=1151362553; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20updated=20GRUU=20spec; X=v=3Dcisco.com=3B=20h=3DCUdLAyjyiWnemXjhyFeXb4tsT1o=3D; b=MPdhkSnQo9U6Dz0TnJaOytI7j/4Im9JooKuFOVFvB5B0g3OFtRBj1VE+xtB/LQ/A1fWrlidq x8HGTFLHY/kgV9XenQvSPEeqWsIe6A8Npgk6+1ttI1IycnwOIvQKTvdj; Authentication-Results: sj-dkim-5.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: IETF SIP List , Keith Drage , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Jeroen van Bemmel wrote: > >> Indeed, note that the registrar will create a gruu even if the client >> doesn't support it, as long as instance ID was there. The reason is >> that even though the client doesn't support gruu, other elements >> listening to reg-event will get notified, and with the gruu reg-event >> extension, need to see that gruu. This is called out later in the spec: >> >> Inclusion of a GRUU in the "gruu" Contact header field parameter of a >> REGISTER response is separate from the computation and storage of the >> GRUU. It is possible that the registrar has computed a GRUU for one >> UA, but a different UA that queries for the current set of >> registrations doesn't understand GRUU. In that case, the REGISTER >> response sent to that second UA would not contain the "gruu" Contact >> header field parameter, even though the UA has a GRUU for that >> contact. >> > > I did not make the connection that through reg-event another element > could receive the GRUU, and use it / distribute it. As a consequence, > the UA could receive a request with a request URI containing something > else than its registered Contact. Harmless enough I suppose Not quite. When the reg-event subscriber sends a request to the GRUU, it will arrive at the home proxy, where the r-uri is translated to the registered contact. The only bit of weirdness is that, per the -08, that request will have a grid parameter added to it, and the UA will receive a request whose r-uri looks like its registered contact except with the addition of grid. There should be no harm in that. TO clarify that this use case is possible, I updated the above paragraph as follows: Inclusion of a GRUU in the "gruu" Contact header field parameter of a REGISTER response is separate from the computation and storage of the GRUU. It is possible that the registrar has computed a GRUU for one UA, but a different UA that queries for the current set of registrations doesn't understand GRUU. In that case, the REGISTER response sent to that second UA would not contain the "gruu" Contact header field parameter, even though the UA has a GRUU for that contact. Similarly, a UA might send a REGISTER request with a contact containing a "+sip.instance" Contact header field but no "gruu" option tag in the Supported header field. The registrar can still assign a GRUU, and indeed, a subscriber to the registration event package could learn the GRUU from the notification . > >>> >>>> 1a) Which error response if "Supported: gruu" but missing >>>> sip.instance? bad request? >>>> >>> >>> None. We just don't issue a gruu if we don't want to. The UAC hasn't >>> insisted that it really wants one, so that's OK. >> >> >> Slight correction - it *can't* issue a gruu at all for contacts >> without instance ID. Remember that a GRUU is bound to an AOR and >> instance ID. So, unless you have both, you can't issue one. Its not >> like it just doesn't want to; it cannot. >> >> Its really important to understand that in NO WAY is this an error >> condition (contacts without instance ID). Third party registrations, >> for example, are allowed and will typically not contian an instance ID. >> >> > > Perhaps worth mentioning as a valid case (note to implementors) OK, I added a sentence about that, so it reads: A UA MAY perform third party registrations (registrations where the entity performing the registration is not the same as the AOR in the To header field of the registration), and as in the above paragraph, MAY register contacts that do not point to the UA performing the registration. In addition, a UA MAY register contacts which omit the "+sip.instance" Contact header field parameter, in which case they would not be associated with any GRUU. Look OK? I'll submit a -09 if it looks like your comments are all addressed. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jun 17 04:52:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrWW2-0004PY-6f; Sat, 17 Jun 2006 04:50:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrWW0-0004PT-Pq for sip@ietf.org; Sat, 17 Jun 2006 04:50:48 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrWVz-0000wY-HB for sip@ietf.org; Sat, 17 Jun 2006 04:50:48 -0400 Received: (qmail 19662 invoked by uid 0); 17 Jun 2006 08:50:41 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 17 Jun 2006 08:50:41 -0000 Message-ID: <000e01c691eb$1bd8e860$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Jonathan Rosenberg" References: <4490BF1C.4050304@cisco.com> <007b01c690a0$4b0b59c0$31713b51@BEMBUSTER> <3BA07DF8-55FF-4836-9EF7-4235310D8D30@softarmor.com> <4493040A.5040307@cisco.com> <00f901c6918c$a60767f0$31713b51@BEMBUSTER> <449336F7.9020908@cisco.com> Subject: Re: [Sip] updated GRUU spec Date: Sat, 17 Jun 2006 10:50:39 +0200 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.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: IETF SIP List , Keith Drage , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > Look OK? I'll submit a -09 if it looks like your comments are all > addressed. Yes, please proceed Regards, Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 17 08:32:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrZwK-0001pM-Em; Sat, 17 Jun 2006 08:30:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrAV3-0000NX-W7 for sip@ietf.org; Fri, 16 Jun 2006 05:20:21 -0400 Received: from agminet01.oracle.com ([141.146.126.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrAV3-0006SY-Gv for sip@ietf.org; Fri, 16 Jun 2006 05:20:21 -0400 Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k5G9KGZF012858; Fri, 16 Jun 2006 04:20:16 -0500 Received: from se.oracle.com (dhcp-22-3-185.se.oracle.com [144.22.3.185]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k5G9KCuQ009447 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 16 Jun 2006 03:20:13 -0600 From: =?iso-8859-1?B?IkphbiBS9mdkZSI=?= To: "Michael Hammer (mhammer)" , "Christer Holmberg (JO/LMF)" , "Erkki.Koivusalo@nokia.com" , "Paul Kyzivat (pkyzivat)" Subject: RE: [Sip] outbound i-d update? Date: Fri, 16 Jun 2006 11:20:21 +0200 Organization: Oracle Message-ID: <20060616112021737.00000003956@jrogde-se> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E30197BBD6@xmb-rtp-20b.amer.cisco.com> X-Mailer: Oracle Connector for Outlook 10.1.2.0.0 71006 (11.0.8010) X-Accept-Language: sv-se, sv MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee X-Mailman-Approved-At: Sat, 17 Jun 2006 08:30:10 -0400 Cc: "Cullen Jennings \(fluffy\)" , "sip@ietf.org" , "jh@tutpro.com" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "jan.rogde@oracle.com" List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A couple of questions that I think are related to this discussion. * Assume the client wants reliability so it is prepared to set up multiple = connections. * Study the scenario in chapter 8 "Example Message Flow". * Since the terms Backup and Primary are obsolete now (right?) assume that = there are multiple proxy/registrars hosting the domain. * As in the example, the proxy that was in involved in the call setup goes = down. * The BYE arrives at another proxy server, because the Record-Route just st= ated the domain name, which in the example "happens" to have a connection t= o the callee. So, for this to work in the general case I guess that the client really nee= ds to have a connection to ALL proxy servers hosting the domain, it is not = enough to just have "multiple flows"? = Or maybe outbound alone should not solve this case? If combined with GRUU i= t would be enough to have a few connections open to "make sure" that the re= quest will reach the recipient. And finally moving slightly off topic, wouldn't it be easier for everyone i= nvolved if outbound and gruu was combined? That combination solves a proble= m... /Jappe = -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] = Sent: den 15 juni 2006 15:55 To: Christer Holmberg (JO/LMF); Erkki.Koivusalo@nokia.com; Paul Kyzivat (pk= yzivat) Cc: Cullen Jennings (fluffy); sip@ietf.org; jh@tutpro.com Subject: RE: [Sip] outbound i-d update? So, keeping score: Client must be capable of establishing a minimum of 2 flows. Network must provide max-flows in Register response. Client must not exceed max-flows when establishing flows. Client should attempt to equal max-flows if terminal capabilities allows. Did I miss anything? Mike > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, June 15, 2006 4:25 AM > To: Erkki.Koivusalo@nokia.com; Paul Kyzivat (pkyzivat) > Cc: Cullen Jennings (fluffy); sip@ietf.org; jh@tutpro.com > Subject: RE: [Sip] outbound i-d update? > = > = > Hi, > = > >>and how would that knowledge be auto-configured to the client? > >In the next version of draft-koivusalo-sip-outbound-discovery > >it might be possible to introduce a configuration option to > tell the UA > >whether it should keep one or two flows open. The spec might > tell that > >the default value for this option SHOULD be two and that the > operator/user could override this default behaviour e.g. in order to = > save battery or some other policy related reasons. > > > >Comments ? > = > That sounds ok. But, as I've said, I think it would be useful if the = > network could indicate (e.g. In the first REGISTER > response) how many flows it wants the client to establish. = > Because, the numbers of flows wanted may not always be static, so = > having a UA configuration parameter as the only option may not always = > be very feasible. > = > Regards, > = > Christer > = > = > = > = > >-----Original Message----- > >From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > >Sent: 15.June.2006 01:42 > >To: Christer Holmberg (JO/LMF) > >Cc: fluffy@cisco.com; sip@ietf.org; Juha Heinanen > >Subject: Re: [Sip] outbound i-d update? > > > >The decision about how many to keep open is *policy*. It may be that = > >there is a UA that doesn't care about reliability very much, so its = > >policy is to keep only one connection up. (Outbound is still > useful for > >nat traversal.) > > > >Both ends of the connection may have a policy about this. If > so, those > >need to be reconciled somehow. But I don't see why that > should be wired > >into this specification. > > > >IMO it would be sufficient to specify a default that SHOULD apply = > >unless there is explicit policy to the contrary. > > > > Paul > > > >Christer Holmberg (JO/LMF) wrote: > >> Hi, > >> = > >> For example, the knowledge could come to the client from the > >network in a REGISTER response, i.e. the network tells the > client how > >many flows it wants to client to establish. > >> = > >> Or something like that... I haven't thought much about it, > >but maybe it's one possible alternative. > >> = > >> Regards, > >> = > >> Christer > >> = > >> = > >> -----Original Message----- > >> From: Juha Heinanen [mailto:jh@tutpro.com] > >> Sent: 14. kes=E4kuuta 2006 11:24 > >> To: Christer Holmberg (JO/LMF) > >> Cc: Erkki.Koivusalo@nokia.com; fluffy@cisco.com; sip@ietf.org > >> Subject: RE: [Sip] outbound i-d update? > >> = > >> Christer Holmberg (JO/LMF) writes: > >> = > >> > But, I still think that the client should still be > >allowed to open a > flow with only a single IP address, because the = > >fact that it receives > multiple URIs/addresses may have > nothing to do > >with fault > tolerance. But, in this case the client must of course = > >have knowledge > about that. > >> = > >> and how would that knowledge be auto-configured to the client? > >> = > >> -- 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 > > > = > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use = > sip-implementors@cs.columbia.edu for questions on current sip Use = > sipping@ietf.org for new developments on the application of sip > = _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implement= ors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for n= ew developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 17 08:32:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrZx6-0002Ah-0J; Sat, 17 Jun 2006 08:31:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqbfM-0007Cg-84 for sip@ietf.org; Wed, 14 Jun 2006 16:08:40 -0400 Received: from outbound-ash.frontbridge.com ([206.16.192.249] helo=outbound1-ash-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqbfK-0004bM-Tm for sip@ietf.org; Wed, 14 Jun 2006 16:08:40 -0400 Received: from outbound1-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-ash-R.bigfish.com (Postfix) with ESMTP id 9F979CB73D8 for ; Wed, 14 Jun 2006 20:08:23 +0000 (UTC) Received: from mail74-ash-R.bigfish.com (unknown [172.18.2.3]) by outbound1-ash.bigfish.com (Postfix) with ESMTP id 97E8ACB42DE for ; Wed, 14 Jun 2006 20:08:23 +0000 (UTC) Received: from mail74-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by mail74-ash-R.bigfish.com (Postfix) with ESMTP id 8D3A64FD133 for ; Wed, 14 Jun 2006 20:08:23 +0000 (UTC) X-BigFish: V Received: by mail74-ash (MessageSwitch) id 115031570329390_12469; Wed, 14 Jun 2006 20:08:23 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail74-ash.bigfish.com (Postfix) with ESMTP id DF6F24F9151 for ; Wed, 14 Jun 2006 20:08:22 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id k5EK87g0029872 for ; Wed, 14 Jun 2006 15:08:17 -0500 (CDT) Received: from pdawg05a.ad.sprint.com (PDAWG05A.corp.sprint.com [10.122.2.38]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k5EK85g11973 for ; Wed, 14 Jun 2006 15:08:05 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by pdawg05a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 15:08:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 Jun 2006 15:08:02 -0500 Message-ID: <858217C310A3D94182FA8AAE42860A135DAE68@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A Hitchhikers Guide to the Session Initiation Protocol (SIP) Thread-Index: AcaP7j2TuJxGzvvpT0GP32Qb/Z7A4g== From: "Khan, Sohel Q [CTO]" To: X-OriginalArrivalTime: 14 Jun 2006 20:08:05.0338 (UTC) FILETIME=[3F4913A0:01C68FEE] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac X-Mailman-Approved-At: Sat, 17 Jun 2006 08:30:58 -0400 Subject: [Sip] A Hitchhikers Guide to the Session Initiation Protocol (SIP) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0819696077==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0819696077== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68FEE.1B046E7D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68FEE.1B046E7D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable First, I am looking for the updated version of "A Hitchhikers Guide to the Session Initiation Protocol (SIP)" draft. Also, in old version, I think, it will be nice if Core SIP Specification chapter precedes the SIP family chapter. I am also thinking, how often this document will be updated and whether all SIPPING and SIMPLE RFCs would be included. Sohel Khan, Ph.D. Technology Strategist Sprint-Nextel ------_=_NextPart_001_01C68FEE.1B046E7D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A Hitchhikers Guide to the Session Initiation Protocol = (SIP)

First, I am looking for the updated = version of "A Hitchhikers Guide to the Session Initiation Protocol = (SIP)" draft.

Also, in old version, I think, it will = be nice if Core SIP Specification chapter precedes the SIP family = chapter.

I am also thinking, how often this = document will be updated and whether all SIPPING and SIMPLE RFCs would = be included.


Sohel Khan, Ph.D.
Technology Strategist
Sprint-Nextel



------_=_NextPart_001_01C68FEE.1B046E7D-- --===============0819696077== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0819696077==-- From sip-bounces@ietf.org Sat Jun 17 16:39:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrhXz-0002fN-J2; Sat, 17 Jun 2006 16:37:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrhXy-0002YK-4N for sip@ietf.org; Sat, 17 Jun 2006 16:37:34 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrhXw-0006Tb-ST for sip@ietf.org; Sat, 17 Jun 2006 16:37:34 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 17 Jun 2006 16:37:32 -0400 X-IronPort-AV: i="4.06,145,1149480000"; d="scan'208"; a="90312044:sNHT29696108" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5HKbSYL026175; Sat, 17 Jun 2006 16:37:28 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 17 Jun 2006 16:37:28 -0400 Received: from [10.86.242.233] ([10.86.242.233]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 17 Jun 2006 16:37:27 -0400 Message-ID: <44946807.9050201@cisco.com> Date: Sat, 17 Jun 2006 16:37:27 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: zhangwei Subject: Re: [Sip] INVITE request after 302 response References: <001101c690f5$eb5e7060$378ba8c0@zhangwei> In-Reply-To: <001101c690f5$eb5e7060$378ba8c0@zhangwei> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jun 2006 20:37:27.0739 (UTC) FILETIME=[D8FF60B0:01C6924D] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org zhangwei wrote: > Hi, > > In SIP, 302 Moved Temporarily can be used by User Agent to set call forwarding. When the caller received 302, it should re-create a new INVITE request to forward call to a given contact. > > My question is how Proxy Server detect whether INVITE is created after having received 302 response. The Proxy Server is transaction stateful. What's the difference between INVITE after 302 and the normal INVITE ? In general there is no way to detect this. And in general there is no reason why the proxy should need to detect it. Of course in certain network architectures the proxy may want to detect this - to coordinat billing actions perhaps. To do so without maintaining state in the proxy will require some creativity. E.g. the contact address in the 302 might be modified in some way to facilitate this. Paul > Regards > Zhang Wei > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 17 16:59:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrhrY-00089x-EX; Sat, 17 Jun 2006 16:57:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrhrX-00089s-I6 for sip@ietf.org; Sat, 17 Jun 2006 16:57:47 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrhrW-0000Ue-9r for sip@ietf.org; Sat, 17 Jun 2006 16:57:47 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 17 Jun 2006 13:57:46 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,145,1149490800"; d="scan'208"; a="29775359:sNHT23695484" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5HKvjno008566; Sat, 17 Jun 2006 16:57:45 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 17 Jun 2006 16:57:45 -0400 Received: from [10.86.242.233] ([10.86.242.233]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 17 Jun 2006 16:57:44 -0400 Message-ID: <44946CC8.5050801@cisco.com> Date: Sat, 17 Jun 2006 16:57:44 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Special breakout for the lock-icon discussion? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jun 2006 20:57:44.0833 (UTC) FILETIME=[AE712F10:01C69250] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: sip@ietf.org, Cullen Jennings , Keith Drage X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I will. Paul Dean Willis wrote: > > We had this 500-message wacky thread about SIP security, sips:, tls, and > the hopping bunny "lock icon" problem. > > My hunch is there's more there than can be wedged into a regular > meeting, and that it's more important than we had previously realized. > > If we could get a break-out room in Montreal for an "ad-hoc" discussion > of the SIP Lock Icon problem, how many people think they might show up? > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 18 12:16:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Frzuf-00058i-S0; Sun, 18 Jun 2006 12:14:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Frzud-00058d-Fp for sip@ietf.org; Sun, 18 Jun 2006 12:14:11 -0400 Received: from jaguar.hughesbpo.net ([61.246.186.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Frzua-0002Nv-Tn for sip@ietf.org; Sun, 18 Jun 2006 12:14:11 -0400 Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by jaguar.hughesbpo.net (8.13.6/8.13.6) with ESMTP id k5IGDj27007937; Sun, 18 Jun 2006 21:43:59 +0530 Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id k5IGEf624361; Sun, 18 Jun 2006 21:44:42 +0530 (IST) Importance: Normal X-Priority: 3 (Normal) Subject: Re: [Sip] Re: INVITE request after 302 response MIME-Version: 1.0 From: Rayees Khan To: "zhangwei" Date: Sun, 18 Jun 2006 21:43:38 +0530 Message-ID: X-MIMETrack: Serialize by Notes Server on Zarf/HSS(Release 6.5.1|January 21, 2004) at 06/18/2006 09:43:38 PM, Serialize complete at 06/18/2006 09:43:38 PM, Itemize by Notes Server on Zarf/HSS(Release 6.5.1|January 21, 2004) at 06/18/2006 09:43:38 PM, Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 18/06/2006 09:43:40 PM, Serialize complete at 18/06/2006 09:43:40 PM MIME-Version: 1.0 X-Spam-Score: 3.2 (+++) X-Scan-Signature: 65215b440f7ab00ca9514de4a7a89926 Cc: sip@ietf.org, Sumit Dhar , Lei Weimin X-BeenThere: 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="===============0765398639==" Errors-To: sip-bounces@ietf.org --===============0765398639== Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Hi Mr Zhang, =20

As far as I understand the behaviour of UAs the normal procedure = is that on receiving 302 response the UA would extract the information from= contact of 302 and put it into request line of new INVITE. The INVITE that= would be generated by UA as a result of this redirection would have UA3 in= request line and UA2 in 'To' header. However, it is not mandatory, and UA = can choose to change both.
One of the ways I can think of is to have so= me kind of intelligence in proxy to keep track of the 302 responses that ar= e proxied. The INVITE generated form these UAs after 302 are most likely to= be result of 302, though again there is no guarantee. Additionally, one mo= re interesting point is that the From header is likely to be retained.
<= br>
regards
Rayees




-= ----"zhangwei" <zhangwei@sict.ac.cn> wrote: -----

To: Sumit Dhar/BLR/H= SS@HSS, <sip@ietf.org>, "Lei Weimin" <leiwm@sict.ac.cn>
From= : "zhangwei" <zhangwei@sict.ac.cn>
Date: 06/16/2006 03:04PM
Sub= ject: [Sip] Re: INVITE request after 302 response

Hello Sumit,
 
Thanks for your response.
 
Take an example for the applicat= ion.
 
UA1     = ; Proxy=20 Server    UA2    UA3
|    =            =20  =20 |            &n= bsp;  =20   |         |
|---INVITE--->| &= nbsp;           &nbs= p;   =20 |         |
|    =             &nb= sp;=20 |--- INVITE --> |  =20       |
|    =             &nb= sp;=20 |<----302 ------|         |
|<----302-------| = ;        =20         |  =20       |
|         &nb= sp;        =20 |       =20           |  =20       |
|-----ACK---->|=             &nb= sp;   =20  |         |
|    =             =20  |---ACK------>|        =20 |
|---INVITE--->| &= nbsp;           &nbs= p;  =20  |         |
|    =             &nb= sp;=20 |------------ INVITE ---->|
|    =            =20   |<--100/180/200------|
|100/180/200|  =     =20            |   =       |
|    =             &nb= sp;=20 |         =20         |   =20      |
|----ACK----->| &= nbsp;           &nbs= p; =20   |         |
|    =             &nb= sp;=20 |--------------ACK----->|
 
 
Our project need to account acco= rding to=20 INVITE/200/ACK and BYE.  
 
For the instance above, we want = to make two=20 accountings. One is UA1 call UA2. The other is UA2 call UA3.
 
Our Proxy Server is transaction = stateful. But we=20 want that Proxy Server can obtain UA1 UA2 and UA3's info only from the seco= nd=20 INVITE request.
 
How can my Proxy Server obtain U= A2's info only=20 from the second INVITE request? 
 
 
Thanks & Best regards
 
Zhang Wei
 
=20
----- Original Message -----=20
=20
Fro= m: =20 =20 Sumit Dhar =20
=20
To: =20 zhangw= ei =20
=20
Sent: Friday, June 16, 2006 7:08 PM
=20
Subject: Re: INVITE request after 302=20 response
=20


Hello Mr Zhang, =20

Thanks for your mail. =20

I wasnt too sure however as = to where you=20 got my contacts from. I have anyways organized a response for your questi= on=20 which is enclosed in my mail.

May=20 I request to know more details about the project you are working on, and = if we=20 can possible collaborate .

Thanks=20 & Best Regards,

Sumit =20

Response>
A typical 3261 compliant t= ransaction stateful proxy=20 would not be able to distinguish if an INVITE is an initial INVITE sent b= y a=20 UA=20
OR was sent subsequent to t= he=20 reception of a 302 response. Also, a transatcion stateful proxy need not = know=20 it.
An exception however is wh= en a=20 proxy is capable to performing recursion. In this case, the proxy would=20 interpret the 302 response
by itself=20 and send a new INVITE to the redirected contact address.=20 =20


If however, there i= s a need to=20 know that an INVITE was redirected, one option is to check the cseq=20 number..
RFC 3261 recommends that t= he=20 UA uses the same call-id, from-tag, to-tag etc and just increment the cse= q=20 number for
a new INVITE towards the=20 redirected address. However, this is just a recommendation and may not be= =20 adhered to by the UA.





------= --------------------------------------------------
 Sumit=20 Dhar          
 Segment=20 Manager,
 Service Provider Products Business,
 Flextronic= s=20 Software Systems
 (Formerly Hughes Software Systems)
 No.= 18,=20 Outer Ring Road, Panathur Post,
 Bangalore -560 087,  India =              
 Phone  : = +91-80-4106 7138  Fax     : +91-80-4126 6501  =20
 visit us at http://www.flextronicssoftware.com


=20 =20 =20 =20
"zhangwei"=20 <zhangwei@sict.ac.cn> =20 =20

06/16/2006 01:11 PM

=20 		=20 =20 =20 =20 =20 =20
=20
To
=20 		Sumit=20 Dhar/BLR/HSS@HSS =20 =20
=20
cc
=20 		=20
=20
Subject
=20 		INVITE request= after=20 302 response

=20 =20 =20 =20
=20




Hi,
 
   In SIP, 302=20 Moved Temporarily can be used by User Agent to set call forwarding. When = the=20 caller received 302, it should re-create a new INVITE request to forward = call=20 to a given contact.
  =20
   My question is how = Proxy Server=20 detect whether INVITE is created after having received 302 response. The = Proxy=20 Server is transaction stateful. What's the difference between INVITE afte= r 302=20 and the normal INVITE ?=20
  =20
 
Regards
Zhang Wei =20


*********************** =  FSS-=20 Confidential   *********************** =20 =20 =20 =20 =20 =
"DISCLAIMER: This message is proprietary to Flextronics Software S= ystems (FSS) and is intended solely for the use of
the individual to wh= om it is addressed. It may contain privileged or confidential information a= nd should not be
circulated or used for any purpose other than for what= it is intended. If you have received this message in error,
please not= ify the originator immediately. If you are not the intended recipient, you = are notified that you are strictly
prohibited from using, copying, alter= ing, or disclosing the contents of this message. FSS accepts no responsibil= ity for
loss or damage arising from the use of the information transmit= ted by this email including damage from virus."
=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Sip mailing li= st  https://www= 1.ietf.org/mailman/listinfo/sip
This list is for NEW development of = the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions= on current sip
Use sipping@ietf.org for new developments on the applica= tion of sip

*****FSS-Private *****" DISCLAIMER: = This message is proprietary to Flextronics Software Systems Limited (FSS) a= nd is intended solely for the use of the individual to whom it is addressed= . It may contain privileged or confidential information and should not be = circulated or used for any purpose other than for what it is intended. If y= ou have received this message in error, please notify the originator im= mediately. If you are not the intended recipient, you are notified that= you are strictly prohibited from using, copying, altering, or = disclosing the contents of this message. FSS accepts no responsibility for = loss or damage arising from the use of the information transmitted by this = email including damage from virus."
= --===============0765398639== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0765398639==-- From sip-bounces@ietf.org Sun Jun 18 20:36:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fs7iU-0002CY-QW; Sun, 18 Jun 2006 20:34:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fs7iU-0002CT-0N for sip@ietf.org; Sun, 18 Jun 2006 20:34:10 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fs7iP-0007sL-Nz for sip@ietf.org; Sun, 18 Jun 2006 20:34:09 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 62F4C6C01F for ; Sun, 18 Jun 2006 20:34:05 -0400 (EDT) From: "Dale R. Worley" To: Sip Content-Type: text/plain Date: Sun, 18 Jun 2006 20:34:05 -0400 Message-Id: <1150677245.1174.2.camel@niagra.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Sip] The Five Meanings of the REFER 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: , Errors-To: sip-bounces@ietf.org Now that the deadline is upon me, I've written up my catalog of the different uses of the REFER method, draft-worley-sip-many-refers-00, "The Five Meanings of the REFER Method". Until it shows up in the I-D directories, you can fetch it from: http://scm.sipfoundry.org/rep/ietf-drafts/worley/draft-worley-sip-many- refers-00.{txt,html,xml} The REFER method is defined in RFC 3515. That RFC defines the syntax of the REFER request and some of the machinery involved in its execution, but it defines the semantics of the method only so far as to specify that the recipient will initiate a request to the target specified in the Refer-To header. But since almost all requests that can be sent by the recipient are inherently part of an encompassing UA action that affects the state of the recipient in ways that are not directly reflected in SIP protocol actions, the standardized action of initiating a request implicitly has further consequences which are often not clearly specified. As a result, various SIP call-control proposals assume that a UA receiving a REFER will perform the UA operation that is needed at that moment without specifying clearly how the UA recognizes which UA operation is needed. As a result there are now five semantically distinct defined uses of REFER. All five uses bear a family resemblance, and each involves sending a SIP request, but the exact meaning of each use is logically independent of the others, and the rules by which a UA distinguishes the five cases are at best implicit. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 19 02:22:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsD88-0001BW-As; Mon, 19 Jun 2006 02:21:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsD86-0001A3-N7 for sip@ietf.org; Mon, 19 Jun 2006 02:20:58 -0400 Received: from [203.200.4.5] (helo=serversmb.kodiaknetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsD82-0000RM-1g for sip@ietf.org; Mon, 19 Jun 2006 02:20:58 -0400 Received: from Nataraju ([192.168.3.66]) by serversmb.kodiaknetworks.com (8.11.6/8.11.6) with ESMTP id k5J6K2a32413; Mon, 19 Jun 2006 11:50:03 +0530 From: "Nataraju A B" To: "'Rayees Khan'" , "'zhangwei'" Subject: RE: [Sip] Re: INVITE request after 302 response Date: Mon, 19 Jun 2006 11:49:10 +0530 Message-ID: <007201c69368$48b28a20$0132a8c0@Nataraju> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: 761aaf8c3399e40ede8a65f8228b015c Cc: sip@ietf.org, 'Sumit Dhar' , 'Lei Weimin' X-BeenThere: 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="===============1887976568==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1887976568== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0073_01C69396.626AC620" This is a multi-part message in MIME format. ------=_NextPart_000_0073_01C69396.626AC620 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks & Regards, Nataraju A.B. -----Original Message----- From: Rayees Khan [mailto:rayees.khan@flextronicssoftware.com] Sent: Sunday, June 18, 2006 9:44 PM To: zhangwei Cc: sip@ietf.org; Sumit Dhar; Lei Weimin Subject: Re: [Sip] Re: INVITE request after 302 response Hi Mr Zhang, As far as I understand the behaviour of UAs the normal procedure is that on receiving 302 response the UA would extract the information from contact of 302 and put it into request line of new INVITE. The INVITE that would be generated by UA as a result of this redirection would have UA3 in request line and UA2 in 'To' header. However, it is not mandatory, and UA can choose to change both. One of the ways I can think of is to have some kind of intelligence in proxy to keep track of the 302 responses that are proxied. The INVITE generated form these UAs after 302 are most likely to be result of 302, though again there is no guarantee. Additionally, one more interesting point is that the From header is likely to be retained. [ABN] if the INVITE is generated because of 302, then the new INVITE would have the same TO header which was there in the received request. Otherwise this might lead to dialog match in the UAC once final response received from UA3 by UAC (UA1). Only R-URI would be changed with the contact address received in the 302 response. regards Rayees -----"zhangwei" wrote: ----- To: Sumit Dhar/BLR/HSS@HSS, , "Lei Weimin" From: "zhangwei" Date: 06/16/2006 03:04PM Subject: [Sip] Re: INVITE request after 302 response Hello Sumit, Thanks for your response. Take an example for the application. UA1 Proxy Server UA2 UA3 | | | | |---INVITE--->| | | | |--- INVITE --> | | | |<----302 ------| | |<----302-------| | | | | | | |-----ACK---->| | | | |---ACK------>| | |---INVITE--->| | | | |------------ INVITE ---->| | |<--100/180/200------| |100/180/200| | | | | | | |----ACK----->| | | | |--------------ACK----->| Our project need to account according to INVITE/200/ACK and BYE. For the instance above, we want to make two accountings. One is UA1 call UA2. The other is UA2 call UA3. Our Proxy Server is transaction stateful. But we want that Proxy Server can obtain UA1 UA2 and UA3's info only from the second INVITE request. How can my Proxy Server obtain UA2's info only from the second INVITE request? Thanks & Best regards Zhang Wei ----- Original Message ----- From: Sumit Dhar To: zhangwei Sent: Friday, June 16, 2006 7:08 PM Subject: Re: INVITE request after 302 response Hello Mr Zhang, Thanks for your mail. I wasnt too sure however as to where you got my contacts from. I have anyways organized a response for your question which is enclosed in my mail. May I request to know more details about the project you are working on, and if we can possible collaborate . Thanks & Best Regards, Sumit Response> A typical 3261 compliant transaction stateful proxy would not be able to distinguish if an INVITE is an initial INVITE sent by a UA OR was sent subsequent to the reception of a 302 response. Also, a transatcion stateful proxy need not know it. An exception however is when a proxy is capable to performing recursion. In this case, the proxy would interpret the 302 response by itself and send a new INVITE to the redirected contact address. If however, there is a need to know that an INVITE was redirected, one option is to check the cseq number.. RFC 3261 recommends that the UA uses the same call-id, from-tag, to-tag etc and just increment the cseq number for a new INVITE towards the redirected address. However, this is just a recommendation and may not be adhered to by the UA. -------------------------------------------------------- Sumit Dhar Segment Manager, Service Provider Products Business, Flextronics Software Systems (Formerly Hughes Software Systems) No. 18, Outer Ring Road, Panathur Post, Bangalore -560 087, India Phone : +91-80-4106 7138 Fax : +91-80-4126 6501 visit us at http://www.flextronicssoftware.com "zhangwei" 06/16/2006 01:11 PM To Sumit Dhar/BLR/HSS@HSS cc Subject INVITE request after 302 response Hi, In SIP, 302 Moved Temporarily can be used by User Agent to set call forwarding. When the caller received 302, it should re-create a new INVITE request to forward call to a given contact. My question is how Proxy Server detect whether INVITE is created after having received 302 response. The Proxy Server is transaction stateful. What's the difference between INVITE after 302 and the normal INVITE ? Regards Zhang Wei *********************** FSS- Confidential *********************** "DISCLAIMER: This message is proprietary to Flextronics Software Systems (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip *****FSS-Private *****" DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." ------=_NextPart_000_0073_01C69396.626AC620 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

=

 

=

Thanks & = Regards,

Nataraju = A.B.

-----Original Message-----
From: = Rayees Khan [mailto:rayees.khan@flextronicssoftware.com]
Sent: Sunday, June 18, 2006 = 9:44 PM
To: zhangwei
Cc: sip@ietf.org; Sumit = Dhar; Lei Weimin
Subject: Re: [Sip] Re: = INVITE request after 302 response

 


Hi Mr Zhang,

As far as I understand the behaviour of UAs the normal procedure is that = on receiving 302 response the UA would extract the information from contact = of 302 and put it into request line of new INVITE. The INVITE that would be = generated by UA as a result of this redirection would have UA3 in request line and = UA2 in 'To' header. However, it is not mandatory, and UA can choose to change = both.
One of the ways I can think of is to have some kind of intelligence in = proxy to keep track of the 302 responses that are proxied. The INVITE generated = form these UAs after 302 are most likely to be result of 302, though again = there is no guarantee. Additionally, one more interesting point is that the From header is likely to be retained.

[ABN] if the INVITE is generated because of 302, then the new INVITE would have the same TO = header which was there in the received request. Otherwise this might lead to = dialog match in the UAC once final response received from UA3 by UAC (UA1). = Only R-URI would be changed with the contact address received in the 302 response. =

regards
Rayees



-----"zhangwei" <zhangwei@sict.ac.cn> wrote: -----

To: Sumit Dhar/BLR/HSS@HSS, <sip@ietf.org>, "Lei Weimin" <leiwm@sict.ac.cn>
From: "zhangwei" <zhangwei@sict.ac.cn>
Date: 06/16/2006 03:04PM
Subject: [Sip] Re: INVITE request after 302 = response

Hello Sumit,

 

Thanks for your response. =

 

Take an example for the application. =

 

UA1      Proxy Server    UA2    UA3 =

|         = ;         |            =       |         | =

|---INVITE--->|      =             |         | =

|         = ;         |--- INVITE = --> |         | =

|         = ;         |<----302 ------|         | =

|<----302-------|     &nbs= p;            |         |

|             &= nbsp;     |                  |         |

|-----ACK---->|      =             |         | =

|         = ;         |---ACK------>|         | =

|---INVITE--->|      =             |         | =

|         = ;         |------------ INVITE = ---->|

|         = ;         |<--100/180/200------|

|100/180/200|                  = |         |

|         = ;         |                  |         |

|----ACK----->|      =             |         | =

|         = ;         |--------------ACK----->|

 

 

Our project need to account according to = INVITE/200/ACK and BYE.  

 

For the instance above, we want to make two = accountings. One is UA1 call UA2. The other is UA2 call UA3. =

 

Our Proxy Server is transaction stateful. But we want = that Proxy Server can obtain UA1 UA2 and UA3's info only from the second = INVITE request.

 

How can my Proxy Server obtain UA2's info only = from the second INVITE request? 

 

 

Thanks & Best regards =

 

Zhang Wei

 

----- Original Message ----- =

From: = Sumit Dhar =

Sent: Friday, = June 16, 2006 7:08 PM

Subject: Re: = INVITE request after 302 response

 


Hello Mr Zhang,

Thanks for your mail.

I wasnt too sure however as to where you got my contacts from. I have = anyways organized a response for your question which is enclosed in my mail. =

May I request to know more details about the project you are working on, and = if we can possible collaborate .

Thanks & Best Regards,

Sumit

Response>
A typical 3261 compliant transaction stateful proxy would not be able to distinguish if an INVITE is an initial INVITE sent by a UA =
OR was sent subsequent to the reception of a 302 response. Also, a = transatcion stateful proxy need not know it.
An exception however is when a proxy is capable to performing recursion. In = this case, the proxy would interpret the 302 response
by itself and send a new INVITE to the redirected contact address. =


If however, there is a need to know that an INVITE was redirected, one = option is to check the cseq number..
RFC 3261 recommends that the UA uses the same call-id, from-tag, to-tag etc = and just increment the cseq number for
a new INVITE towards the redirected address. However, this is just a recommendation and may not be adhered to by the UA.





--------------------------------------------------------
 Sumit Dhar          
 Segment Manager,
 Service Provider Products Business,
 Flextronics Software Systems
 (Formerly Hughes Software Systems)
 No. 18, Outer Ring Road, Panathur Post,
 Bangalore -560 087,  India           =    
 Phone  : +91-80-4106 7138  Fax     : = +91-80-4126 6501  
 visit us at http://www.flextronicssoftware.com

"zhangwei" <zhangwei@sict.ac.cn>

06/16/2006 01:11 PM

To =

Sumit Dhar/BLR/HSS@HSS =

cc =

 

Subject

INVITE request after 302 response =

 

 

 




Hi,
  =
   In SIP, 302 Moved Temporarily can be used by User Agent to set = call forwarding. When the caller received 302, it should re-create a new = INVITE request to forward call to a given contact.
  =
   My question is how Proxy Server detect whether INVITE is created = after having received 302 response. The Proxy Server is transaction stateful. = What's the difference between INVITE after 302 and the normal INVITE ? =
  =
  =
Regards
Zhang Wei


***********************  FSS- Confidential   = ***********************

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

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



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

------=_NextPart_000_0073_01C69396.626AC620-- --===============1887976568== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1887976568==-- From sip-bounces@ietf.org Mon Jun 19 02:50:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsDYp-0006mQ-GF; Mon, 19 Jun 2006 02:48:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsDYo-0006mL-C3 for sip@ietf.org; Mon, 19 Jun 2006 02:48:34 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsDYm-00024N-IU for sip@ietf.org; Mon, 19 Jun 2006 02:48:34 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J13000PJHC5Y0@szxga01-in.huawei.com> for sip@ietf.org; Mon, 19 Jun 2006 14:43:17 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J130061SHC55A@szxga01-in.huawei.com> for sip@ietf.org; Mon, 19 Jun 2006 14:43:17 +0800 (CST) Received: from z53160 ([10.164.5.15]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1300F52HBWSC@szxml03-in.huawei.com> for sip@ietf.org; Mon, 19 Jun 2006 14:43:11 +0800 (CST) Date: Mon, 19 Jun 2006 14:41:36 +0800 From: Harrison Zhou To: Sip Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcaTa2kLuwL+D8yWTdCgWltjtUyNNQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Sip] question about outbound? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I have a simple question about outbound: Does the user agent need to keep a flow to its registrar/proxy if the user agent doesn't locate behide NATs? If need not, how to know that? If need, but the user agent doesn't support outbound and it use different port for send and receive message, then the user agent can't receive requests from registrar/proxy. Regards, Hong _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 19 05:42:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsGF0-00061R-7p; Mon, 19 Jun 2006 05:40:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsGEz-00061M-7F for sip@ietf.org; Mon, 19 Jun 2006 05:40:17 -0400 Received: from mx1-out.cegetel.fr ([195.115.41.100] helo=mx1.cegetel.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsGEx-0004Vw-R4 for sip@ietf.org; Mon, 19 Jun 2006 05:40:17 -0400 Received: from EXRPP003.univers.cegetel.fr (localhost [127.0.0.1]) by mx1.cegetel.fr (8.9.3+Sun/tCegetel.fr) with ESMTP id LAA02923 for ; Mon, 19 Jun 2006 11:41:28 +0200 (MET DST) Received: from EXVPP001.univers.cegetel.fr ([10.18.77.18]) by EXRPP003.univers.cegetel.fr with Microsoft SMTPSVC(6.0.3790.0); Mon, 19 Jun 2006 11:39:28 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 19 Jun 2006 11:39:27 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: REFER_split Thread-Index: AcaThEHp2TCn9/oYQFGeZ16OxoM+Tg== From: "HADDAD Nicolas" To: X-OriginalArrivalTime: 19 Jun 2006 09:39:28.0406 (UTC) FILETIME=[424EBB60:01C69384] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Subject: [Sip] REFER_split X-BeenThere: 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="===============1930406701==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1930406701== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69384.423674F1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69384.423674F1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Im new to this, soi m gonna begin with my fisrt question. Is it possible with the method REFER to have our calls split. That means, using REFER to transfer my call, but having the call split on 2 new devices, one for the video and the other for the voice, for exemple. =20 Nicolas. ------_=_NextPart_001_01C69384.423674F1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Im new to this, soi m gonna begin with my fisrt = question.

Is it possible with the method REFER to have our = calls split. That means, using REFER to transfer my = call,

but having the call split on 2 new devices, one for = the video  and the other for the voice, for = exemple.

 

Nicolas.

------_=_NextPart_001_01C69384.423674F1-- --===============1930406701== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1930406701==-- From sip-bounces@ietf.org Mon Jun 19 05:56:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsGTJ-00040r-6c; Mon, 19 Jun 2006 05:55:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsGTI-00040O-CL for sip@ietf.org; Mon, 19 Jun 2006 05:55:04 -0400 Received: from ausmtp04.au.ibm.com ([202.81.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsGTE-0006RI-Kf for sip@ietf.org; Mon, 19 Jun 2006 05:55:04 -0400 Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp04.au.ibm.com (8.13.6/8.13.5) with ESMTP id k5J9wiwj248986 for ; Mon, 19 Jun 2006 19:58:45 +1000 Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.250.237]) by sd0208e0.au.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k5J9wClq083606 for ; Mon, 19 Jun 2006 19:58:12 +1000 Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k5J9soJJ017544 for ; Mon, 19 Jun 2006 19:54:50 +1000 Received: from d23m0037.cn.ibm.com (d23m0037.cn.ibm.com [9.181.2.105]) by d23av04.au.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k5J9sbEu016806 for ; Mon, 19 Jun 2006 19:54:50 +1000 From: Xin Sheng Mao To: sip@ietf.org Message-ID: Date: Mon, 19 Jun 2006 17:57:34 +0800 X-MIMETrack: Serialize by Router on D23M0037/23/M/IBM(Release 7.0HF124 | January 12, 2006) at 06/19/2006 17:57:39 MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Sip] Xin Sheng Mao/China/IBM 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: , Content-Type: multipart/mixed; boundary="===============0883959290==" Errors-To: sip-bounces@ietf.org --===============0883959290== Content-type: multipart/alternative; Boundary="0__=C7BBFB01DFA533EF8f9e8a93df938690918cC7BBFB01DFA533EF" Content-Disposition: inline --0__=C7BBFB01DFA533EF8f9e8a93df938690918cC7BBFB01DFA533EF Content-type: text/plain; charset=US-ASCII I will be out of the office starting 06/18/2006 and will not return until 06/25/2006. I am out of office on trip... I will have limited email check. For urgency, pls call me at my cell phone (86) 13501183394 --0__=C7BBFB01DFA533EF8f9e8a93df938690918cC7BBFB01DFA533EF Content-type: text/html; charset=US-ASCII Content-Disposition: inline

I will be out of the office starting 06/18/2006 and will not return until 06/25/2006.

I am out of office on trip... I will have limited email check. For urgency, pls call me at my cell phone (86) 13501183394 --0__=C7BBFB01DFA533EF8f9e8a93df938690918cC7BBFB01DFA533EF-- --===============0883959290== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0883959290==-- From sip-bounces@ietf.org Mon Jun 19 05:59:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsGVt-00054k-Gp; Mon, 19 Jun 2006 05:57:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsGVs-00054d-JV for sip@ietf.org; Mon, 19 Jun 2006 05:57:44 -0400 Received: from jaguar.hughesbpo.net ([61.246.186.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsGVo-0006py-Oj for sip@ietf.org; Mon, 19 Jun 2006 05:57:44 -0400 Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by jaguar.hughesbpo.net (8.13.6/8.13.6) with ESMTP id k5J9vAQH030315; Mon, 19 Jun 2006 15:27:24 +0530 Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id k5J9L6L21133; Mon, 19 Jun 2006 14:51:07 +0530 (IST) Importance: Normal X-Priority: 3 (Normal) Subject: RE: [Sip] Re: INVITE request after 302 response MIME-Version: 1.0 From: Rayees Khan To: "Nataraju A B" Date: Mon, 19 Jun 2006 13:44:00 +0530 Message-ID: X-MIMETrack: Serialize by Notes Server on Zarf/HSS(Release 6.5.1|January 21, 2004) at 06/19/2006 01:44:00 PM, Serialize complete at 06/19/2006 01:44:00 PM, Itemize by Notes Server on Zarf/HSS(Release 6.5.1|January 21, 2004) at 06/19/2006 01:44:00 PM, Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 19/06/2006 02:50:04 PM, Serialize complete at 19/06/2006 02:50:04 PM MIME-Version: 1.0 X-Spam-Score: 3.2 (+++) X-Scan-Signature: d67762704726a1bed57e7f4595960d34 Cc: sip@ietf.org, Sumit Dhar , 'Lei Weimin' X-BeenThere: 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="===============1843817987==" Errors-To: sip-bounces@ietf.org --===============1843817987== Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1


I fully agree that it should have same 'To' header as is recomende= d in RFC 3261 section 8.1.3.4
However, it is recomendataion and not a MU= ST. It does carry on to mention that Call-ID may be changed. Nothing is men= tioned about other headers.

In practice, many UACs start a new dial= og altogather with request line and To header populated with URI received i= n 302 response.


regards
Rayees



-----"Nataraju A B" <bnataraju@kodiaknetworks.com> wr= ote: -----

To: Rayees Khan/HSS@HSS, "'zhangwei'" <zhangwei@sict.ac.cn>=
From: "Nataraju A B" <bnataraju@kodiaknetworks.com>
Date: 06/1= 9/2006 07:19AM
cc: <sip@ietf.org>, Sumit Dhar/BLR/HSS@HSS, "'Lei W= eimin'" <leiwm@sict.ac.cn>
Subject: RE: [Sip] Re: INVITE request a= fter 302 response

 

 

Thanks = & Regards,

Nataraju A.B.

-----Original Message-----
From: =20 Rayees Khan [mailto:rayees.khan@flextronicssof= tware.com ]
Sent : =20 Sund= ay, June 18, 2006 =20 9:44 PM
To: zhangwei
Cc: sip@ietf.org; Sumit Dhar; Lei Weimin
Subject: Re: [Sip] Re: INVITE request after 302 response

 


Hi=20 Mr Zhang,=20

As far as I understand the behaviour of UAs the norma= l procedure is that on receiving 302 response the UA would extract the information from contact of= 302 and put it into request line of new INVITE. The INVITE that would be genera= ted by UA as a result of this redirection would have UA3 in request line and UA= 2 in 'To' header. However, it is not mandatory, and UA can choose to change both= .
One of the ways I can think of is to have some kind of intelligence i= n proxy to keep track of the 302 responses that are proxied. The INVITE generated form these UAs after 302 are most likely to be result of 302, though again there= is no guarantee. Additionally, one more interesting point is that the=20 From header is likely to be retained.
[ABN] if the INVITE is generated because of 302, then the new INVITE would have the same TO hea= der which was there in the received request. Otherwise this might lead to dialog match in the UAC once final response received from UA3 by UAC (UA1). Only R= -URI would be changed with the contact address received in the 302 response.=20

regards
Rayees


-----"zhangwei" <zhangwei@sict.ac.cn> wrote: -----

To: Sumit Dhar/BLR/HSS@HSS, <sip@ietf.org>, "Lei Weimin" <leiwm@sict.ac.cn>
From: "zhangwei" <zhangwei@sict.ac.cn>Date: 06/16/2006 03:04PM
Subject: [Sip] Re: INVITE request after 302 re= sponse

Hello&nb= sp;Sumit,=20

 =20

= Thanks for your response.=20

 =20

= Take an example for the application.=20

 =20

= UA1      Proxy Server    UA2    UA3=20

= |            &n= bsp;     |            &n= bsp;     |         |=20

= |---INVITE--->|         &nb= sp;        |         |=20

= |            &n= bsp;     |---=20 INVITE=20 --> |         |=20

= |            &n= bsp;     |<----302 ------|         |=20

= |<----302-------|                  |         |=20

|             &nb= sp;     |                  |         |=20

= |-----ACK---->|         &nb= sp;        |         |=20

= |            &n= bsp;     |---ACK------>|         |=20

= |---INVITE--->|         &nb= sp;        |         |=20

= |            &n= bsp;     |------------=20 INVITE=20 ---->|

= |            &n= bsp;     |<--100/180/200------|=20

= |100/180/200|                  |         |=20

= |            &n= bsp;     |                  |         |=20

= |----ACK----->|         &nb= sp;        |         |=20

= |            &n= bsp;     |--------------ACK----->|=20

 =20

 =20

= Our project need to account according to INVITE/200/ACK and BYE.  =20

 =20

= For the instance above, we want to make two accountings. One is UA1 call UA2. The other is UA2 call UA3.=20

 =20

= Our Proxy Server is transaction stateful. But we want that Proxy Server can obtain UA1 UA2 and UA3's info only from the second INVITE request.=20

 =20

= How can my Proxy Server obtain UA2's info only from the second INVITE request? =20

 =20

 =20

= Thanks & Best regards=20

 =20

= Zhang Wei=20

 =20

----- Orig= inal Message -----=20

From:=20 = Sumit Dhar=20

= To:=20 zhangwei=20

<= div style=3D"font-size-adjust: none; font-stretch: normal;">

Sent:=20 Friday, June 16, 2006 7:08 PM=20

Subject:=20 Re: INVITE request after 302 response=20

 


Hello Mr Zhang,= =20

Thanks for your mail.=20

I wasnt too sure however as to where you got my contacts from. I have anyways organized a response for your question which is enclosed in my mail.=20

May I request to know more details about the project you are working on, and if= we can possible collaborate .=20

Thanks & Best Regards,=20

Sumit

Response>
A typical 3261 compliant transaction stateful proxy would not be able to distinguish if an INVITE is an initial INVITE sent by a UA=20
OR was sent subsequent to the reception of a 302 response. Also, a transatcion stateful proxy need not know it.=20
An exception however is when a proxy is capable to performing recursion. In th= is case, the proxy would interpret the 302 response=20
by itself and send a new INVITE to the redirected contact address.=20


If however, there is a need to know that an INVITE was redirected, one option = is to check the cseq number..=20
RFC 3261 recommends that the UA uses the same call-id, from-tag, to-tag etc and just increment the cseq number for=20
a new INVITE towards the redirected address. However, this is just a recommendation and may not be adhered to by the UA.=20





-----------------= ---------------------------------------
 Sumit Dhar     &= nbsp;    
 Segment Manager,
 Service Provider Pr= oducts Business,
 Flextronics Software Systems
 (Formerly H= ughes Software Systems)
 No. 18, Outer Ring Road, Panathur Post, Bangalore -560 087,  India           &= nbsp;  
 Phone  : +91-80-4106 7138  Fax     : += 91-80-4126 6501  
 visit us at http://www.flextronicssoftware.com=20

=20 =20 =20 =20
=20

"zhangwe= i" <zhangwei@sict.ac.cn>=20


06/16/2006 01:11 PM=20

=20 		=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20
=20

To=20

=20 		=20

Sumit Dhar/BLR/HSS@HSS=20

=20
=20

cc=20

=20 		=20

 

=20
=20

Subject =20

=20 		=20

INVITE request after 302 respon= se=20

=20
=20

 

=20 =20 =20 =20 =20 =20
=20

 

=20 		=20

 

=20
=20

=20




Hi,=20
 =20
   In SIP, 302 Moved Temporarily can be used by User Agent to set call forwarding. When the caller received 302, it should re-create a new INVITE request to forward call to a given contact.=20
 =20
   My question is how Proxy Server detect whether INVITE is created after having received 302 response. The Proxy Server is transaction stateful. Wha= t's the difference between INVITE after 302 and the normal INVITE ?=20
 =20
 =20
Regards
Zhang Wei=20


***********************  = ;FSS- Confidential   ***********************=20

=20 =20 =20
=20

= "DIS= CLAIMER: This message is proprietary to Flextronics Software Systems (FSS) and is intended solely for the use of
the individual to whom it is address= ed. It may contain privileged or confidential information and should not be
circulated or used for a= ny purpose other than for what it is intended. If you have received this message in error,
please notify the originator i= mmediately. If you are not the intended recipient, you are notified that you are strictly
prohibited from us= ing, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for
loss or damage arising f= rom the use of the information transmitted by this email including damage from virus."

=20

= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Sip m= ailing list   https://www1.ietf.or= g/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use si= p-implementors@cs.columbia.edu for questions on current sip
Use sipping@= ietf.org for new developments on the application of sip



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




*****FSS-= Private *****" DISCLAIMER: This message is proprietary to Flextronics Softw= are Systems Limited (FSS) and is intended solely for the use of the individ= ual to whom it is addressed. It may contain privileged or confidential inf= ormation and should not be circulated or used for any purpose other than fo= r what it is intended. If you have received this message in error, plea= se notify the originator immediately. If you are not the intended recipient= , you are notified that you are strictly prohibited from using, cop= ying, altering, or disclosing the contents of this message. FSS acc= epts no responsibility for loss or damage arising from the use of the infor= mation transmitted by this email including damage from virus."
= --===============1843817987== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1843817987==-- From sip-bounces@ietf.org Mon Jun 19 08:34:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsIw6-00059P-Gf; Mon, 19 Jun 2006 08:32:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsH9y-0000sO-4n for sip@ietf.org; Mon, 19 Jun 2006 06:39:10 -0400 Received: from ns.infinet.ru ([195.38.45.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsH9w-0003iQ-Ga for sip@ietf.org; Mon, 19 Jun 2006 06:39:10 -0400 Received: from [195.38.45.84] (light.infinet.ru [195.38.45.84]) by ns.infinet.ru (8.13.1/8.13.1) with ESMTP id k5JAd5Hd049633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 19 Jun 2006 16:39:05 +0600 (ESD) Message-ID: <44967EC9.4010307@infinet.ru> Date: Mon, 19 Jun 2006 16:39:05 +0600 From: Andrew Nesheret Organization: InfiNet Wireless Ltd. User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: sip@ietf.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.5 (ns.infinet.ru [195.38.45.65]); Mon, 19 Jun 2006 16:39:06 +0600 (ESD) X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-Mailman-Approved-At: Mon, 19 Jun 2006 08:32:57 -0400 Subject: [Sip] SIP proto clarification needed. X-BeenThere: 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="===============1349079626==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1349079626== Content-Type: multipart/alternative; boundary="------------060100080003020508090202" This is a multi-part message in MIME format. --------------060100080003020508090202 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit I'm implementing class 5 SIP switch. The problem is to identify calling gateway (by it's INVITE request) which was previously registered on the switch (using REGISTER request). I see two options here. 1. By "From" header field. 2. By "Contact" header field. In first case "From" header field must be equal to gateway's AOR. Disadvantage of this case is inability to pass real caller address. Second case seems very reasonable to me. But, RFC 3261 not directly clarifies this situation. I'm very sorry, if this already covered in some documents. If so, please, provide me a link. -- ------------------------------------------------------------------------ WBR, Andrew Nesheret *ICQ*: /10518066/ --------------060100080003020508090202 Content-Type: text/html; charset=KOI8-R Content-Transfer-Encoding: 7bit I'm implementing class 5 SIP switch. The problem is to identify calling gateway (by it's INVITE request) which was previously registered on the switch (using REGISTER request). I see two options here.
1. By "From" header field.
2. By "Contact" header field.
In first case "From" header field must be equal to gateway's AOR. Disadvantage of this case is inability to pass real caller address.
Second case seems very reasonable to me. But, RFC 3261 not directly clarifies this situation.

I'm very sorry, if this already covered in some documents. If so, please, provide me a link.

--
WBR, Andrew Nesheret ICQ: 10518066
--------------060100080003020508090202-- --===============1349079626== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1349079626==-- From sip-bounces@ietf.org Mon Jun 19 08:35:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsIwh-0005ex-TR; Mon, 19 Jun 2006 08:33:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsIwh-0005es-0c for sip@ietf.org; Mon, 19 Jun 2006 08:33:35 -0400 Received: from ns.infinet.ru ([195.38.45.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsIwf-00030B-Fz for sip@ietf.org; Mon, 19 Jun 2006 08:33:34 -0400 Received: from [195.38.45.84] (light.infinet.ru [195.38.45.84]) by ns.infinet.ru (8.13.1/8.13.1) with ESMTP id k5JCXVv0053050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 19 Jun 2006 18:33:32 +0600 (ESD) Message-ID: <4496999B.8020908@infinet.ru> Date: Mon, 19 Jun 2006 18:33:31 +0600 From: Andrew Nesheret Organization: InfiNet Wireless Ltd. User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: sip@ietf.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.5 (ns.infinet.ru [195.38.45.65]); Mon, 19 Jun 2006 18:33:32 +0600 (ESD) X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [Sip] SIP proto clarification needed. X-BeenThere: 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="===============1349605517==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1349605517== Content-Type: multipart/alternative; boundary="------------070200040108050309060606" This is a multi-part message in MIME format. --------------070200040108050309060606 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Hi. I'm implementing class 5 SIP switch. The problem is to identify calling gateway (by it's INVITE request) which was previously registered on the switch (using REGISTER request). I see two options here. 1. By "From" header field. 2. By "Contact" header field. In first case "From" header field must be equal to gateway's AOR. Disadvantage of this case is inability to pass real caller address. Second case seems very reasonable to me. But, RFC 3261 not directly clarifies this situation. I'm very sorry, if this already covered in some documents. If so, please, provide me a link. -- ------------------------------------------------------------------------ WBR, Andrew Nesheret *ICQ*: /10518066/ --------------070200040108050309060606 Content-Type: text/html; charset=KOI8-R Content-Transfer-Encoding: 7bit Hi.

I'm implementing class 5 SIP switch. The problem is to identify calling gateway (by it's INVITE request) which was previously registered on the switch (using REGISTER request). I see two options here.
1. By "From" header field.
2. By "Contact" header field.
In first case "From" header field must be equal to gateway's AOR. Disadvantage of this case is inability to pass real caller address.
Second case seems very reasonable to me. But, RFC 3261 not directly clarifies this situation.

I'm very sorry, if this already covered in some documents. If so, please, provide me a link.

--
WBR, Andrew Nesheret ICQ: 10518066
--------------070200040108050309060606-- --===============1349605517== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1349605517==-- From sip-bounces@ietf.org Mon Jun 19 09:28:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsJmI-00060u-4u; Mon, 19 Jun 2006 09:26:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsJmH-0005zd-3Z for sip@ietf.org; Mon, 19 Jun 2006 09:26:53 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsJmF-00008h-Rd for sip@ietf.org; Mon, 19 Jun 2006 09:26:53 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 19 Jun 2006 09:26:51 -0400 X-IronPort-AV: i="4.06,151,1149480000"; d="scan'208"; a="90423481:sNHT28220116" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5JDQpYL001641 for ; Mon, 19 Jun 2006 09:26:51 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Jun 2006 09:26:51 -0400 Received: from [192.168.1.101] ([10.82.225.127]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Jun 2006 09:26:51 -0400 Message-ID: <4496A61A.7080905@cisco.com> Date: Mon, 19 Jun 2006 09:26:50 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jun 2006 13:26:51.0170 (UTC) FILETIME=[06075020:01C693A4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Sip] New draft on coexistence of SIP identity and P-Asserted-ID X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org As folks know, we have defined both P-Asserted-ID and SIP-identity. Though the intention is for SIP-identity to replace P-Asserted-ID, there are a number of practical challenges in doing this. SIP identity requires both sides of the call to support it, and it doesn't work at all with b2buas with media (whether THAT is a bug or a feature is a matter of perspective). I've written an I-D that describes a pretty straightforward technique for allowing both mechanisms to simultaneously co-exist. Its backwards compatible with rfc3325 and works in the presence of b2bua's under many (but not all) conditions. The essential idea is to use SIP identity inter-domain and P-Asserted-ID intra-domain. Until it appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-rosenberg-sip-identity-coexistence-00.txt Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 19 09:32:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsJq6-0008D8-QU; Mon, 19 Jun 2006 09:30:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsJq4-0008D3-SV for sip@ietf.org; Mon, 19 Jun 2006 09:30:48 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsJq3-0000Jc-Fl for sip@ietf.org; Mon, 19 Jun 2006 09:30:48 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 19 Jun 2006 06:30:47 -0700 X-IronPort-AV: i="4.06,151,1149490800"; d="scan'208"; a="1828242255:sNHT36412032" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k5JDUk2n014877 for ; Mon, 19 Jun 2006 06:30:46 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5JDUiJ2004543 for ; Mon, 19 Jun 2006 06:30:46 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Jun 2006 09:30:45 -0400 Received: from [192.168.1.101] ([10.82.225.127]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Jun 2006 09:30:45 -0400 Message-ID: <4496A704.6020705@cisco.com> Date: Mon, 19 Jun 2006 09:30:44 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jun 2006 13:30:45.0111 (UTC) FILETIME=[9177E070:01C693A4] DKIM-Signature: a=rsa-sha1; q=dns; l=2703; t=1150723846; x=1151587846; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Updated=20hitchhikers=20guide; X=v=3Dcisco.com=3B=20h=3D9XXpOMcKrecsn0YSDQfaAyH0008=3D; b=R9UqbxX9zQOGMSaS9hEghaqzCVOlJGNog5MFVra5IvFNa4BlsTL3GpQsBOcAZmnZhQz8ffyK 0s6xPAZfvgzEJnTQ6P4z3MioIQUxhPT2T4nUYq23J6R/oQXeX5zXro+O; Authentication-Results: sj-dkim-8.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: [Sip] Updated hitchhikers guide X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I've submitted an update to the hitchhikers guide draft, now as a SIP WG -00 draft. Until it appears, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-sip-hitchhikers-guide-00.txt The changes from the last version are: * Removed concept of SIP family of specifications; as suggested at the last meeting this really belongs in some kind of draft-ietf-rai document * redefined set of documents in scope to now include SDP extensions and MIME objects meant for SIP. * redefined core specifications per my proposal on the list, moved RFC 3323 to general purpose, and added RFC 3264, SDP-new, callee-caps, ICE, rtcp sdp attribute, sdp grouping framework, fork-loop-fix and connected-identity to the set of core specs * added a new topic area of confernecing, and moved the conference event package, media-label attribute, Join header field, and uri-list-conferencing there. Join also appears under call control primitives, and the conference package under event packages * clarified in the introduciton that specifications can appear in more than one place * updated references for those drafts that have issued as RFC since the last version * added RFC 3204 (MIME objects for ISUP and QSIG), RFC 3959 (early session disposition type) to telephony specs * added RFC 4483 (content indirection), RFC 3890 (transport independent bandwidth modifier), SDP-bfcp, connectivity preconditions, SDP content attribute as a minor extension * added RFC 3420 (message/sipfrag), RFC 4145 (SDP comedia), RFC 4091 (SDP ANAT) and ICE-tcp to general purpose extensions * added RFC 3893 (AIB), comedia-tls, draft-ietf-sip-certs, security preconditions, to security extensions * added RFC 3524 (SDP grouping for mapping media streams to resource reservation flows) to QoS specs * did NOT add sdescriptions or kmgmt-ext to the list, largely because we are still sorting out what really is the media encryption solution for RTP. * added session specific policy package to the event packages list, added event-list subscription there * added RFC 4240 (netann) to SIP service URIs * didnt add draft-ietf-sipping-xcap-config yet; wait to see how this fully shakes out * added reference [42] to hitchhikers guide * added towel reference * expanded PGGB to Pan Galactic Gargle Blaster Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 19 10:34:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsKoI-00034Z-7U; Mon, 19 Jun 2006 10:33:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsKoG-00033P-Fo for sip@ietf.org; Mon, 19 Jun 2006 10:33:00 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsKoE-0002PW-5m for sip@ietf.org; Mon, 19 Jun 2006 10:33:00 -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 k5JEWvkm004163 for ; Mon, 19 Jun 2006 09:32:57 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k5JEWua09952; Mon, 19 Jun 2006 09:32:56 -0500 (CDT) Message-ID: <4496B598.1060505@lucent.com> Date: Mon, 19 Jun 2006 09:32:56 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Sip] The SIPSEC URI I-D X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Folks: Based on the "wacky thread with the hopping bunny" discussions, an I-D has been submitted on the SIPSEC URI. Until it appears in the archives, you can grab a copy from: http://www.iit.edu/~gurbvij/I-D/draft-gurbani-sip-sipsec-00.txt http://www.iit.edu/~gurbvij/I-D/draft-gurbani-sip-sipsec-00.html Comments and feedback welcome. Thank you. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 19 11:05:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsLIH-0000Ft-9U; Mon, 19 Jun 2006 11:04:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsLIF-0000Fo-LP for sip@ietf.org; Mon, 19 Jun 2006 11:03:59 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsLIE-00077Z-9Q for sip@ietf.org; Mon, 19 Jun 2006 11:03:59 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 19 Jun 2006 08:03:57 -0700 X-IronPort-AV: i="4.06,152,1149490800"; d="scan'208"; a="297039052:sNHT33458852" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k5JF3vFZ025748; Mon, 19 Jun 2006 08:03:57 -0700 Received: from [10.20.235.241] (sjc-vpn4-884.cisco.com [10.21.83.115]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5JF3rcO021876; Mon, 19 Jun 2006 08:03:57 -0700 (PDT) In-Reply-To: <18F72A6C-6A17-411B-B5C1-91F3DA886A50@softarmor.com> References: <18F72A6C-6A17-411B-B5C1-91F3DA886A50@softarmor.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <83A15395-2643-40DF-82AD-9996509FCCF6@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Certs draft movement? Date: Mon, 19 Jun 2006 05:33:39 -0700 To: Dean Willis X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=1840; t=1150729437; x=1151593437; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Certs=20draft=20movement?; X=v=3Dcisco.com=3B=20h=3DoUhS31803pjk8YIYB2byMqjYbqw=3D; b=quU8KiqqtjL0FzDVa0JOQYpPNmwAd5GFTubGn4Yg5FD1CRuZ/dUCT79EFUsIyADNcrtnwT6W fPmQNbh/UlKQh5tQ1UgMmgFHQCYNqyuhYW5x45SG8FFDK1yY/u9dtKKd; Authentication-Results: sj-dkim-7.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org We continue to define security mechanism based on certificates (the new mikey RSA-R draft being the latest example to soon be approved as an RFC). Unless we have a serious proposal of how to solve the problems we are using user certificates for in the many RFCs that require them, I think we should keep moving forward with this. I do have concerns about if any of this will deploy but certs is part of the puzzle that can help make it deployable. Cullen PS. Dogs do worse things to trees than bark at them :-) On Jun 15, 2006, at 2:50 PM, Dean Willis wrote: > > Once upon a time, a friend of mine had a dog that we thought liked > to chase squirrels. When a squirrel would run up a tree, the dog > would run to the tree and start barking. After a while, we noticed > that the dog was just barking at trees whether they had a squirrel > in them or not, and we realized that the dog wasn't all that > worried about squirrels anymore. He'd gotten so used to barking at > trees that he thought this was now his goal. > > So in putting the draft agenda together for Montreal, I noticed the > new certs draft, draft-ietf-sip-certs-00.txt, and I thought about > how I felt about the topic. It's definitely something I once chased > after, like that dog chasing a squirrel. But Now I'm wondering > where the "certs squirrel" went. > > Do we really believe in the certs draft, or are we just barking at > a tree out of habit? > > -- > 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 Jun 19 11:58:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsM7Q-0007wN-Ju; Mon, 19 Jun 2006 11:56:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsM7P-0007wI-AR for sip@ietf.org; Mon, 19 Jun 2006 11:56:51 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsM7N-0006qf-Ve for sip@ietf.org; Mon, 19 Jun 2006 11:56:51 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-1.cisco.com with ESMTP; 19 Jun 2006 08:56:48 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k5JFun7W015617; Mon, 19 Jun 2006 08:56:49 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5JFuncL011778; Mon, 19 Jun 2006 08:56:49 -0700 (PDT) Received: from [216.102.208.13] (sjc-vpn5-401.cisco.com [10.21.89.145]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k5JFq5nM014641; Mon, 19 Jun 2006 08:52:10 -0700 Message-ID: <4496C932.70004@cisco.com> Date: Mon, 19 Jun 2006 08:56:34 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] Certs draft movement? References: <18F72A6C-6A17-411B-B5C1-91F3DA886A50@softarmor.com> <83A15395-2643-40DF-82AD-9996509FCCF6@cisco.com> In-Reply-To: <83A15395-2643-40DF-82AD-9996509FCCF6@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-5.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=2859; t=1150732609; x=1151596609; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:Michael=20Thomas=20 |Subject:Re=3A=20[Sip]=20Certs=20draft=20movement?; X=v=3Dcisco.com=3B=20h=3DOThg2IrTgjt4ByVF+XXKn+cA39A=3D; b=OlHZXwHIq69UyyEtXtyM/l9x3lVXXZF5yannkhuUT/cWQ5v6EzgqnjvhmfvbVj7Ywq2EAFns iFTVMftJBb3ocO9XQ24cKHWHmqU5Buf830aBxzCscwxMJ0LmNxizhfYp; X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: IETF SIP List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen Jennings wrote: > > We continue to define security mechanism based on certificates (the > new mikey RSA-R draft being the latest example to soon be approved as > an RFC). Unless we have a serious proposal of how to solve the > problems we are using user certificates for in the many RFCs that > require them, I think we should keep moving forward with this. I do > have concerns about if any of this will deploy but certs is part of > the puzzle that can help make it deployable. What I see: lots and lots and lots of effort on things that first posit: IFF there were widespread user certificate deployment *then* this work should be useful. In reality, we so next to no deployment of user certificates, and lots of standards work that has never been debugged even though it's getting to PS. Doesn't this make anybody else want to step back and do some root cause analysis? Or do people just have lots of time on their hands to chug out standards that have proven time and again that there's no route to deployment? Mike, and domain based certs are barely better > > Cullen > > PS. Dogs do worse things to trees than bark at them :-) > > > On Jun 15, 2006, at 2:50 PM, Dean Willis wrote: > >> >> Once upon a time, a friend of mine had a dog that we thought liked >> to chase squirrels. When a squirrel would run up a tree, the dog >> would run to the tree and start barking. After a while, we noticed >> that the dog was just barking at trees whether they had a squirrel >> in them or not, and we realized that the dog wasn't all that worried >> about squirrels anymore. He'd gotten so used to barking at trees >> that he thought this was now his goal. >> >> So in putting the draft agenda together for Montreal, I noticed the >> new certs draft, draft-ietf-sip-certs-00.txt, and I thought about >> how I felt about the topic. It's definitely something I once chased >> after, like that dog chasing a squirrel. But Now I'm wondering where >> the "certs squirrel" went. >> >> Do we really believe in the certs draft, or are we just barking at a >> tree out of habit? >> >> -- >> 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 Mon Jun 19 12:03:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsMC6-0002f0-0D; Mon, 19 Jun 2006 12:01:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsMC4-0002eq-3K for sip@ietf.org; Mon, 19 Jun 2006 12:01:40 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsMC2-0007ie-Rt for sip@ietf.org; Mon, 19 Jun 2006 12:01:40 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 19 Jun 2006 12:01:39 -0400 X-IronPort-AV: i="4.06,152,1149480000"; d="scan'208"; a="90469073:sNHT28688116" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5JG1cno005931 for ; Mon, 19 Jun 2006 12:01:38 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Jun 2006 12:01:38 -0400 Received: from [161.44.34.189] ([161.44.34.189]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Jun 2006 12:01:37 -0400 Message-ID: <4496CA61.30601@cisco.com> Date: Mon, 19 Jun 2006 12:01:37 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jun 2006 16:01:38.0251 (UTC) FILETIME=[A58F69B0:01C693B9] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Sip] updated GRUU spec X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I've just submitted a -09 which is a minor update based on some good comments from Jeroen. Until it appears you can pick it up at: http://www.jdrosen.net/papers/draft-ietf-sip-gruu-09.txt the changes are: * note applicability to target refresh requests * note required property of GRUU, which is that if its constructed with opaque parameter, stripping it off must produce aor * mention the use case of where reg-event is used to subscribe in order to get gruu, even when UA doesn't support it * fixed bugs in examples Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 19 13:51:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsNs9-00014m-Uc; Mon, 19 Jun 2006 13:49:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsNs8-00014g-HU for sip@ietf.org; Mon, 19 Jun 2006 13:49:12 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsNs7-0004Dh-4J for sip@ietf.org; Mon, 19 Jun 2006 13:49:12 -0400 Received: (qmail 22010 invoked by uid 0); 19 Jun 2006 17:49:08 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 19 Jun 2006 17:49:08 -0000 Message-ID: <002401c693c8$aab13400$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: Date: Mon, 19 Jun 2006 19:49:08 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Subject: [Sip] draft-ietf-sip-certs-00, communicating private keys and self-signed certificates X-BeenThere: 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="===============1500065443==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1500065443== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C693D9.6DE68CD0" This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C693D9.6DE68CD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If a dog barks at a tree and no-one hears it, did the dog make a sound? OK, leaving aside the dogs and the trees for the moment, a short = question about the contents: The draft states "The certificates discussed in this draft are generally = self signed". It then talks about how the credential service can be used = to obtain the credentials using an authenticated SUBSCRIBE/NOTIFY = sequence. What puzzles me: why would a UA use the credential service to obtain a = previously submitted self-signed certificate, instead of simply = generating a new one by itself? Regards, Jeroen ------=_NextPart_000_0021_01C693D9.6DE68CD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If a dog barks at a tree and = no-one hears it,=20 did the dog make a sound?
 
OK, leaving aside the dogs and the = trees for the=20 moment, a short question about the contents:
The draft states "The certificates = discussed in=20 this draft are generally self signed". It then talks about how the = credential=20 service can be used to obtain the credentials using an authenticated=20 SUBSCRIBE/NOTIFY sequence.
 
What puzzles me: why would a UA use the = credential=20 service to obtain a previously submitted self-signed certificate, = instead of=20 simply generating a new one by itself?
 
Regards,
 
Jeroen
 
 
------=_NextPart_000_0021_01C693D9.6DE68CD0-- --===============1500065443== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1500065443==-- From sip-bounces@ietf.org Mon Jun 19 13:52:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsNu5-0002Y3-37; Mon, 19 Jun 2006 13:51:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsNu3-0002Xv-0i for sip@ietf.org; Mon, 19 Jun 2006 13:51:11 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsNu1-0004LO-C7 for sip@ietf.org; Mon, 19 Jun 2006 13:51:10 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5616F4F005C for ; Mon, 19 Jun 2006 19:51:08 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 19:51:08 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 19:51:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Jun 2006 19:51:07 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F1138@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Outbound: keep-alive, outbound and 3489bis Thread-Index: AcaTyPC/k4rk7sp7TES6rUQhvcP4qw== From: "Christer Holmberg \(JO/LMF\)" To: X-OriginalArrivalTime: 19 Jun 2006 17:51:08.0094 (UTC) FILETIME=[F17DE5E0:01C693C8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Subject: [Sip] Outbound: keep-alive, outbound and 3489bis X-BeenThere: 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="===============1853091622==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1853091622== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C693C8.F0D9DD49" This is a multi-part message in MIME format. ------_=_NextPart_001_01C693C8.F0D9DD49 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, A few issues on the outbound draft: Q1: ----- The outbound draft currently defines the usage of STUN for NAT keep-alive. However, since NAT keep-alive has been added as a STUN usage to the STUN specification (3489bis) itself, I guess the outbound draft only needs to refer to 3489bis and "apply" it to SIP, e.g. by defining the keepalive URI parameter. Q2: ----- If a client supports STUN for keep-alive, but not the other parts of the outbound extension (instance-id, reg-id etc), it will not insert the instance-id etc, but it will still include the 'keepalive' URI parameter. Now, the outbound draft does not FORBID this, as far as I can see, but I wonder if we more clearly should point that out in the draft. OR, the SIP usage of STUN keep-alive should be described in a separate draft, now when the usage itself is part of 3489bis. OR, if I only use STUN for keep-alive, without the rest of the outbound stuff, should I not use the 'keepalive' parameter in the first place? Regards, Christer ------_=_NextPart_001_01C693C8.F0D9DD49 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Outbound: keep-alive, outbound and 3489bis

Hi,

A few issues on the outbound = draft:

Q1:
-----

The outbound draft currently defines = the usage of STUN for NAT keep-alive.

However, since NAT keep-alive has been = added as a STUN usage to the STUN specification (3489bis) itself, I = guess the outbound draft only needs to refer to 3489bis and = "apply" it to SIP, e.g. by defining the keepalive URI = parameter.


Q2:
-----

If a client supports STUN for = keep-alive, but not the other parts of the outbound extension = (instance-id, reg-id etc), it will not insert the instance-id etc, but = it will still include the 'keepalive' URI parameter.

Now, the outbound draft does not FORBID = this, as far as I can see, but I wonder if we more clearly should point = that out in the draft.

OR, the SIP usage of STUN keep-alive = should be described in a separate draft, now when the usage itself is = part of 3489bis.

OR, if I only use STUN for keep-alive, = without the rest of the outbound stuff, should I not use the 'keepalive' = parameter in the first place?



Regards,

Christer

------_=_NextPart_001_01C693C8.F0D9DD49-- --===============1853091622== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1853091622==-- From sip-bounces@ietf.org Mon Jun 19 15:59:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsPsO-0007bd-AE; Mon, 19 Jun 2006 15:57:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsPl9-0006kl-EA; Mon, 19 Jun 2006 15:50:07 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsPl8-0000T6-A3; Mon, 19 Jun 2006 15:50:06 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=willow.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FsPl4-0005IA-Lb; Mon, 19 Jun 2006 15:50:06 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5JJo2Rx002281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FsPl4-0007a7-8s; Mon, 19 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Jun 2006 15:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-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: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Diagnostic Responses for Session Initiation Protocol Hop Limit Errors Author(s) : S. Lawrence, et al. Filename : draft-ietf-sip-hop-limit-diagnostics-03.txt Pages : 17 Date : 2006-6-19 The Session Initiation Protocol (SIP) imposes a limit on the number of hops a request can transit on the way to its destination. When this limit is reached, a 483 (Too Many Hops) error response is returned. The present form of the 483 response does not provide enough information for the UAC or proxy on the path to diagnose failures whose symptom is that the hop limit is reached. This document specifies additional diagnostic information to be returned in a 483 response. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-hop-limit-diagnostics-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-hop-limit-diagnostics-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-hop-limit-diagnostics-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: <2006-6-19142606.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-hop-limit-diagnostics-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-hop-limit-diagnostics-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-19142606.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Mon Jun 19 17:23:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsRC6-0007DD-17; Mon, 19 Jun 2006 17:22:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsRC4-0007D0-9D for sip@ietf.org; Mon, 19 Jun 2006 17:22:00 -0400 Received: from smtp122.iad.emailsrvr.com ([207.97.245.122] helo=smtp132.iad.emailsrvr.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsRC2-0001I5-Tg for sip@ietf.org; Mon, 19 Jun 2006 17:22:00 -0400 Received: from bremen (unknown [64.251.86.193]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: derek@counterpath.com) by relay2.r2.iad.emailsrvr.com (SMTP Server) with ESMTP id D843844DD02; Mon, 19 Jun 2006 17:21:53 -0400 (EDT) From: "Derek MacDonald" To: "'Paul Kyzivat'" , "'Dean Willis'" Subject: RE: [Sip] Special breakout for the lock-icon discussion? Date: Mon, 19 Jun 2006 14:21:52 -0700 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: <44946CC8.5050801@cisco.com> x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaSUMLOHEatSlwES3SkPsSpUgYN0wBlZKsg Message-Id: <20060619212153.D843844DD02@relay2.r2.iad.emailsrvr.com> X-Virus-Scanned: OK X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sip@ietf.org, 'Cullen Jennings' , 'Keith Drage' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I would. --Derek > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Saturday, June 17, 2006 1:58 PM > To: Dean Willis > Cc: sip@ietf.org; Cullen Jennings; Keith Drage > Subject: Re: [Sip] Special breakout for the lock-icon discussion? > > I will. > > Paul > > Dean Willis wrote: > > > > We had this 500-message wacky thread about SIP security, sips:, tls, and > > the hopping bunny "lock icon" problem. > > > > My hunch is there's more there than can be wedged into a regular > > meeting, and that it's more important than we had previously realized. > > > > If we could get a break-out room in Montreal for an "ad-hoc" discussion > > of the SIP Lock Icon problem, how many people think they might show up? > > > > -- > > 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 Mon Jun 19 19:09:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsSq7-0008Va-Hy; Mon, 19 Jun 2006 19:07:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsSq6-0008VV-Fl for sip@ietf.org; Mon, 19 Jun 2006 19:07:26 -0400 Received: from au.padl.com ([203.13.32.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsSq4-00084H-O9 for sip@ietf.org; Mon, 19 Jun 2006 19:07:26 -0400 Received: from au.padl.com (localhost.padl.com [127.0.0.1]) by au.padl.com (8.12.11/8.12.11) with ESMTP id k5JN7C22029732 for ; Tue, 20 Jun 2006 09:07:12 +1000 (EST) (envelope-from lukeh@au.padl.com) Received: (from lukeh@localhost) by au.padl.com (8.12.11/8.12.11/Submit) id k5JN7BVU029731; Tue, 20 Jun 2006 09:07:11 +1000 (EST) (envelope-from lukeh) From: Luke Howard Message-Id: <200606192307.k5JN7BVU029731@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: sip@ietf.org Date: Tue, 20 Jun 2006 09:07:11 +1000 Versions: dmail (bsd44) 2.6d/makemail 2.10 X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on au.padl.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Sip] GSS-API and SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lukeh@padl.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Has anyone specified how to use GSS-API mechanisms to secure SIP exchanges and, if so, how it interacts with SRTP key exchange? It appears that MS RTC supports Kerberos authentication in SIP, but the mechanism seems different to draft-jaganathan-kerberos-http-01.txt and it's not clear whether the SDP payload is secured. -- Luke -- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 19 19:36:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTGu-0004BK-7s; Mon, 19 Jun 2006 19:35:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTGs-0004Ax-TE for sip@ietf.org; Mon, 19 Jun 2006 19:35:06 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsTGo-0001F7-5o for sip@ietf.org; Mon, 19 Jun 2006 19:35:06 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 19 Jun 2006 16:34:59 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,153,1149490800"; d="scan'208"; a="29995817:sNHT22724636" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5JNYxno024277 for ; Mon, 19 Jun 2006 19:34:59 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Jun 2006 19:34:59 -0400 Received: from [161.44.79.149] ([161.44.79.149]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Jun 2006 19:34:59 -0400 Message-ID: <449734A3.30400@cisco.com> Date: Mon, 19 Jun 2006 19:34:59 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] New draft on coexistence of SIP identity and P-Asserted-ID References: <4496A61A.7080905@cisco.com> In-Reply-To: <4496A61A.7080905@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jun 2006 23:34:59.0612 (UTC) FILETIME=[FAD5B5C0:01C693F8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan, I really agree we need something more or less like this to arrive at a practical and workable identity solution. I had been thinking (vaguely) of something like this, but never got around to clarifying my thoughts and writing them down. I have a few comments from first reading: - Why should the terminating UA check the identity header. It makes sense to do if it wants to distinguish if there was a B2BUA with media in the path on the terminating side. But it doesn't distinguish if there was one on the sending side. Is there much value in that? Or in detecting it at all? I suppose it might in some special cases, but knowing such nuances is only useful if they affect the subsequent action. Without some sophisticated and likely confusing user interface this info probably won't be much use. - I don't know how much detail is needed here, but depending on topology it may not be the edge proxy that does the authentication. It isn't important that it be done there. All that is necessary is that the P-Asserted-Identity be inserted only after authentication has been done. - While it is clear that you are trying to tighten up the security of identity from what it is in 3325, I'm not convinced that requiring the removal of P-Asserted-Identity when receiving a request from another domain actually achieves anything. Suppose it were left in? That means that if some server along the path was bad or inept the assertion might be a lie. But a bad or inept server in the originating network, before signing, can also result in an assertion that is a lie, and then result in a signature for that lie, and then to that being trusted in the terminating network. Paul Jonathan Rosenberg wrote: > As folks know, we have defined both P-Asserted-ID and SIP-identity. > Though the intention is for SIP-identity to replace P-Asserted-ID, there > are a number of practical challenges in doing this. SIP identity > requires both sides of the call to support it, and it doesn't work at > all with b2buas with media (whether THAT is a bug or a feature is a > matter of perspective). > > I've written an I-D that describes a pretty straightforward technique > for allowing both mechanisms to simultaneously co-exist. Its backwards > compatible with rfc3325 and works in the presence of b2bua's under many > (but not all) conditions. The essential idea is to use SIP identity > inter-domain and P-Asserted-ID intra-domain. Until it appears in the > archives, you can pick up a copy at: > > http://www.jdrosen.net/papers/draft-rosenberg-sip-identity-coexistence-00.txt > > > Thanks, > Jonathan R. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 19 20:14:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTrQ-0005mi-VQ; Mon, 19 Jun 2006 20:12:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTrP-0005md-JR for sip@ietf.org; Mon, 19 Jun 2006 20:12:51 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsTrO-00064s-Ac for sip@ietf.org; Mon, 19 Jun 2006 20:12:51 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 19 Jun 2006 17:12:50 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,153,1149490800"; d="scan'208"; a="29997746:sNHT24269696" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5K0CnYL014733; Mon, 19 Jun 2006 20:12:49 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Jun 2006 20:12:49 -0400 Received: from [161.44.79.149] ([161.44.79.149]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Jun 2006 20:12:49 -0400 Message-ID: <44973D81.5030307@cisco.com> Date: Mon, 19 Jun 2006 20:12:49 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Sip] The SIPSEC URI I-D References: <4496B598.1060505@lucent.com> In-Reply-To: <4496B598.1060505@lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 00:12:49.0329 (UTC) FILETIME=[43B10A10:01C693FE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Vijay, Thanks for taking the first step! My first comment is that I question whether the requirements you have proposed are the right ones. While they might be sufficient, I suspect that in many environments a solution meeting those requirements will be unacceptable. I suspect that a less ambitious set of requirements may still be a useful improvement over the current state of affairs and be more widely implementable. Specifically, a guarantee that depends on hop-by-hop trust may be quite acceptable if it at least guarantees: - nobody but the endpoints and intermediaries on the signaling path can see the signaling - nobody but the endpoints and intermediaries on the signaling path have the keys to the media (Both assuming you trust the intermediaries) This is (just a little) more than SIPS. But I think it is comparable to what is available from the PSTN, and so could be advertised as "just as good". Going back to your proposals, I was thinking maybe your SIPSEC URI scheme might just be used as the contact in a target refresh request. I think that would solve a number of the problems, though perhaps introducing some new ones. Used this way, a session would be established normally and then a reINVITE or UPDATE used to negotiate an e2e secure signaling session. Then the keys for a media session would be exchanged. This would perhaps normally be opportunistic. If required then callerprefs could be used to exclude those that can't or don't want to play. The caller could make a normal, insecure, offer. If the answerer wants security, it could accept the request but refuse all the media. Once the session is established, one side would send a target refresh using SIPSEC, (or maybe SIPS would be enough here). In that exchange the media, including keys, would be negotiated. Paul Vijay K. Gurbani wrote: > Folks: Based on the "wacky thread with the hopping bunny" > discussions, an I-D has been submitted on the SIPSEC URI. Until > it appears in the archives, you can grab a copy from: > > http://www.iit.edu/~gurbvij/I-D/draft-gurbani-sip-sipsec-00.txt > http://www.iit.edu/~gurbvij/I-D/draft-gurbani-sip-sipsec-00.html > > Comments and feedback welcome. > > Thank you. > > - vijay _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 19 22:15:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsVju-0003rj-O8; Mon, 19 Jun 2006 22:13:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsVjs-0003rO-Dx for sip@ietf.org; Mon, 19 Jun 2006 22:13:12 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsVjr-0004gW-4x for sip@ietf.org; Mon, 19 Jun 2006 22:13:12 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 19 Jun 2006 22:13:12 -0400 X-IronPort-AV: i="4.06,153,1149480000"; d="scan'208"; a="90539511:sNHT30873788" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5K2DAno017123 for ; Mon, 19 Jun 2006 22:13:10 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Jun 2006 22:13:10 -0400 Received: from [192.168.1.101] ([10.86.243.91]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Jun 2006 22:13:10 -0400 Message-ID: <449759B5.1080701@cisco.com> Date: Mon, 19 Jun 2006 22:13:09 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] New draft on coexistence of SIP identity and P-Asserted-ID References: <4496A61A.7080905@cisco.com> <449734A3.30400@cisco.com> In-Reply-To: <449734A3.30400@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 02:13:10.0611 (UTC) FILETIME=[13E93A30:01C6940F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Paul Kyzivat wrote: > Jonathan, > > I really agree we need something more or less like this to arrive at a > practical and workable identity solution. I had been thinking (vaguely) > of something like this, but never got around to clarifying my thoughts > and writing them down. > > I have a few comments from first reading: > > - Why should the terminating UA check the identity header. It makes > sense to do if it wants to distinguish if there was a B2BUA with media > in the path on the terminating side. But it doesn't distinguish if there > was one on the sending side. Is there much value in that? Or in > detecting it at all? I suppose it might in some special cases, but > knowing such nuances is only useful if they affect the subsequent > action. Without some sophisticated and likely confusing user interface > this info probably won't be much use. I had in mind that the UA might like to make sophisticated policy decisions that would reqiure sip-identity; but thinking about this more, as long as the UAS is sure that the terminating network verified the identity, everything it needs for policy checks is in P-Asserted-ID - the domain and identity of the requestor. So perhaps you are right and there is no point. > > - I don't know how much detail is needed here, but depending on topology > it may not be the edge proxy that does the authentication. It isn't > important that it be done there. All that is necessary is that the > P-Asserted-Identity be inserted only after authentication has been done. Right. > > - While it is clear that you are trying to tighten up the security of > identity from what it is in 3325, I'm not convinced that requiring the > removal of P-Asserted-Identity when receiving a request from another > domain actually achieves anything. Suppose it were left in? That means > that if some server along the path was bad or inept the assertion might > be a lie. But a bad or inept server in the originating network, before > signing, can also result in an assertion that is a lie, and then result > in a signature for that lie, and then to that being trusted in the > terminating network. The main point is that I am trying to change the scope of P-Asserted-ID to intra-domain, and thus by definition any value received from outside the domain is meaningless. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 19 22:43:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsWBp-0002Jw-TW; Mon, 19 Jun 2006 22:42:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsWBn-0002JL-R0 for sip@ietf.org; Mon, 19 Jun 2006 22:42:03 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsWBm-0008BP-Jj for sip@ietf.org; Mon, 19 Jun 2006 22:42:03 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 19 Jun 2006 22:42:02 -0400 X-IronPort-AV: i="4.06,153,1149480000"; d="scan'208"; a="90541224:sNHT29286896" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5K2g2YL008302 for ; Mon, 19 Jun 2006 22:42:02 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Jun 2006 22:42:01 -0400 Received: from [192.168.1.101] ([10.86.243.91]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Jun 2006 22:42:01 -0400 Message-ID: <44976078.6020408@cisco.com> Date: Mon, 19 Jun 2006 22:42:00 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 02:42:01.0517 (UTC) FILETIME=[1B9C85D0:01C69413] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Sip] Updated acr-code 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: , Errors-To: sip-bounces@ietf.org I've just submitted a minor update to the ACR code draft. Until it appears, you can pick it up at: http://www.jdrosen.net/papers/draft-ietf-sip-acr-code-01.txt The changes were to add the required RFC 2119 boilerplate and fix some spell check errors. The document is complete AFAIK and has had no discussion since the last revision. I believe it ready for WGLC. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 20 01:45:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsZ1T-0003xc-IM; Tue, 20 Jun 2006 01:43:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsZ1S-0003xX-7v for sip@ietf.org; Tue, 20 Jun 2006 01:43:34 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsZ1P-0004pH-Sn for sip@ietf.org; Tue, 20 Jun 2006 01:43:34 -0400 Received: from [192.168.1.5] (65-65-155-30.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5K5j1mh019531 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 20 Jun 2006 00:45:02 -0500 In-Reply-To: <4496999B.8020908@infinet.ru> References: <4496999B.8020908@infinet.ru> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0AA1BDBF-DAB7-4FE1-A2B3-4AFDA6932F68@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] SIP proto clarification needed. Date: Tue, 20 Jun 2006 00:43:24 -0500 To: Andrew Nesheret X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 19, 2006, at 7:33 AM, Andrew Nesheret wrote: > Hi. > > I'm implementing class 5 SIP switch. The problem is to identify > calling gateway (by it's INVITE request) which was previously > registered on the switch (using REGISTER request). I see two > options here. > 1. By "From" header field. > 2. By "Contact" header field. > In first case "From" header field must be equal to gateway's AOR. > Disadvantage of this case is inability to pass real caller address. > Second case seems very reasonable to me. But, RFC 3261 not directly > clarifies this situation. > > I'm very sorry, if this already covered in some documents. If so, > please, provide me a link. > sounds like you have several discrete pieces of functionality intertwingled, none of which do what you may need to do. Why does the class 5 switch need to identify the calling gateway in an INVITE? Does it make an authentication/authorization decision, apply different routing rules based on which gateway called, or what? And how on earth are you getting a gateway to register? What is it registering? Every phone number it might possibly be able to reach? What does the REGISTER request have to do with a subsequent INVITE? Most of our identity mechanisms are about expressing the identity of the PSTN caller behind the gateway. This is more or less what comes out in From:, P-Asserted-Identity, Remote-Party-ID, and so on. -- 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 Jun 20 01:47:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsZ3P-0005LB-SR; Tue, 20 Jun 2006 01:45:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsZ3M-0005Jh-Qu for sip@ietf.org; Tue, 20 Jun 2006 01:45:32 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsZ3J-0005Jd-Hq for sip@ietf.org; Tue, 20 Jun 2006 01:45:32 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 19 Jun 2006 22:45:29 -0700 X-IronPort-AV: i="4.06,153,1149490800"; d="scan'208"; a="297557543:sNHT31248696" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k5K5jTuc013288; Mon, 19 Jun 2006 22:45:29 -0700 Received: from [192.168.1.2] (sjc-vpn6-723.cisco.com [10.21.122.211]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5K5jMkh021909; Mon, 19 Jun 2006 22:45:28 -0700 (PDT) In-Reply-To: <1150118729.2822.18.camel@sukothai.pingtel.com> References: <44887921.20302@cisco.com> <1149796932.4721.129.camel@localhost.localdomain> <44898BD0.7000705@cisco.com> <26E13ED4-1582-4CB2-B74E-F5E0985F9810@cisco.com> <1150118729.2822.18.camel@sukothai.pingtel.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt Date: Mon, 19 Jun 2006 17:15:35 -0700 To: Scott Lawrence X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=516; t=1150782329; x=1151646329; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20I-D=20ACTION=3Adraft-ietf-sip-hop-limit-diagnostics-02.t xt; X=v=3Dcisco.com=3B=20h=3DuuoBsEgzdw6+9X+Y6yGlgJ8d2Es=3D; b=RatMCp135G2+/XVlaYKxGGWkrIp2YH2v6NBbG0b+ShPBzDLfbR2WT54NiR51gPwso0L1qYf/ LLPeN2PxBCCPNRL4Rt4luL5eO9YJTVcxaElGYDr4lrGncHunyOY/B6Hq; Authentication-Results: sj-dkim-2.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 12, 2006, at 6:25 AM, Scott Lawrence wrote: > - this introduces new normative behavior for all Servers > > - the new behavior is not controlled or advertised using the > mechanisms > for identifying extensions (Supported/Requires). If both of these are true, I agree with you. But I don't see why this draft would need both of these. I see no reason this can not be optional behavior. Anyways, this is a nit, the serious issues in the draft has to do with the size of the responses. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 20 02:57:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsa9B-0006L6-V1; Tue, 20 Jun 2006 02:55:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsa9B-0006L1-3O for sip@ietf.org; Tue, 20 Jun 2006 02:55:37 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsa98-00063C-A5 for sip@ietf.org; Tue, 20 Jun 2006 02:55:37 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 37F4C4F0060; Tue, 20 Jun 2006 08:55:31 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 08:55:28 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 08:55:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] New draft on coexistence of SIP identity and P-Asserted-ID Date: Tue, 20 Jun 2006 08:55:27 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F1143@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New draft on coexistence of SIP identity and P-Asserted-ID Thread-Index: AcaT+Q/1v0YFi03FQYicFKsMNMSIiwAO+EUQ From: "Christer Holmberg \(JO/LMF\)" To: "Jonathan Rosenberg" X-OriginalArrivalTime: 20 Jun 2006 06:55:27.0870 (UTC) FILETIME=[834DD9E0:01C69436] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Hi Jonathan, Assume the UAC, sending a request, is located in domain A (originating domain). The request then exists domain A via egress proxy A, and enters domain B (transit domain) via ingress proxy B. The behavior of those proxies are described in the draft. Now, the request exits domain B, via proxy X, and enters domain C (terminating domain) via ingress proxy C, and then reaches the UAS located in domain C. My question is: what is proxy X? As far as I understand it's not an egress proxy (as defined by the draft), since the domain (domain B) does not match the From header (domain A). Does the mechanism in the draft have any impacts on proxy X behavior (should it add/remove P-Asserted/Identity-Info etc) in the first place? Regards, Christer (NOTE: In this example none of the proxies are B2BUAs, so the question is not related to the issue with having B2BUAs in a transit domain.) > As folks know, we have defined both P-Asserted-ID and SIP-identity.=20 > Though the intention is for SIP-identity to replace P-Asserted-ID,=20 > there are a number of practical challenges in doing this. SIP identity > requires both sides of the call to support it, and it doesn't work at=20 > all with b2buas with media (whether THAT is a bug or a feature is a=20 > matter of perspective). >=20 > I've written an I-D that describes a pretty straightforward technique=20 > for allowing both mechanisms to simultaneously co-exist. Its backwards > compatible with rfc3325 and works in the presence of b2bua's under=20 > many (but not all) conditions. The essential idea is to use SIP=20 > identity inter-domain and P-Asserted-ID intra-domain. Until it appears > in the archives, you can pick up a copy at: >=20 > http://www.jdrosen.net/papers/draft-rosenberg-sip-identity-coexistence > -00.txt >=20 >=20 > Thanks, > Jonathan R. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 20 03:13:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsaOw-0006GA-1b; Tue, 20 Jun 2006 03:11:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsaOu-0006EB-Me for sip@ietf.org; Tue, 20 Jun 2006 03:11:52 -0400 Received: from ns.infinet.ru ([195.38.45.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsaOs-0007xe-Uy for sip@ietf.org; Tue, 20 Jun 2006 03:11:52 -0400 Received: from [195.38.45.84] (light.infinet.ru [195.38.45.84]) by ns.infinet.ru (8.13.1/8.13.1) with ESMTP id k5K7Bm51084726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jun 2006 13:11:48 +0600 (ESD) Message-ID: <44979FB4.8080708@infinet.ru> Date: Tue, 20 Jun 2006 13:11:48 +0600 From: Andrew Nesheret Organization: InfiNet Wireless Ltd. User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] SIP proto clarification needed. References: <4496999B.8020908@infinet.ru> <0AA1BDBF-DAB7-4FE1-A2B3-4AFDA6932F68@softarmor.com> In-Reply-To: <0AA1BDBF-DAB7-4FE1-A2B3-4AFDA6932F68@softarmor.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.5 (ns.infinet.ru [195.38.45.65]); Tue, 20 Jun 2006 13:11:49 +0600 (ESD) X-Spam-Score: 0.1 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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="===============0619492599==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0619492599== Content-Type: multipart/alternative; boundary="------------080108080306000506090908" This is a multi-part message in MIME format. --------------080108080306000506090908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi. Dean Willis wrote: > Why does the class 5 switch need to identify the calling gateway in an > INVITE? > > Does it make an authentication/authorization decision, apply different > routing rules based on which gateway called, or what? Exactly. > > And how on earth are you getting a gateway to register? What is it > registering? Every phone number it might possibly be able to reach? > What does the REGISTER request have to do with a subsequent INVITE? Gateway registers own contacts for it's AOR like any other endpoint. But there is number of endpoints behind that GW. Active AOR (AOR with bound contacts) means that this gateway is _online_. Switch respectively configured to route number of destinations thru that GW (and possible some other GWs). And V-V switch allows calls from that destinations to came out of this GW. So, while GW (or no matter what else) initiates the call, first i need to know which _registered_ entity acting now. And second what is the number (SIP URI) of originating station. Hope this clarifies something. -- ------------------------------------------------------------------------ WBR, Andrew Nesheret *ICQ*: /10518066/ --------------080108080306000506090908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi.

Dean Willis wrote:
Why does the class 5 switch need to identify the calling gateway in an INVITE?

Does it make an authentication/authorization decision, apply different routing rules based on which gateway called, or what?
Exactly.

And how on earth are you getting a gateway to register? What is it registering? Every phone number it might possibly be able to reach? What does the REGISTER request have to do with a subsequent INVITE?
Gateway registers own contacts for it's AOR like any other endpoint. But there is number of endpoints behind that GW. Active AOR (AOR with bound contacts) means that this gateway is _online_. Switch respectively configured to route number of destinations thru that GW (and possible some other GWs). And V-V switch allows calls from that destinations to came out of this GW.

So, while GW (or no matter what else) initiates the call, first i need to know which _registered_ entity acting now.
And second what is the number (SIP URI) of originating station.

Hope this clarifies something.



--
WBR, Andrew Nesheret ICQ: 10518066
--------------080108080306000506090908-- --===============0619492599== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0619492599==-- From sip-bounces@ietf.org Tue Jun 20 08:34:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsfPQ-0004IA-Lz; Tue, 20 Jun 2006 08:32:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsfPO-0004I5-Bm for sip@ietf.org; Tue, 20 Jun 2006 08:32:42 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsfPN-0001Od-02 for sip@ietf.org; Tue, 20 Jun 2006 08:32:42 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 20 Jun 2006 08:32:41 -0400 X-IronPort-AV: i="4.06,155,1149480000"; d="scan'208"; a="90563655:sNHT29106400" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5KCWeYL004739; Tue, 20 Jun 2006 08:32:40 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Jun 2006 08:32:40 -0400 Received: from [161.44.79.149] ([161.44.79.149]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Jun 2006 08:32:40 -0400 Message-ID: <4497EAE7.9090700@cisco.com> Date: Tue, 20 Jun 2006 08:32:39 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] draft-ietf-sip-certs-00, communicating private keys and self-signed certificates References: <002401c693c8$aab13400$31713b51@BEMBUSTER> In-Reply-To: <002401c693c8$aab13400$31713b51@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 12:32:40.0022 (UTC) FILETIME=[9E9B3F60:01C69465] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel wrote: > If a dog barks at a tree and no-one hears it, did the dog make a sound? > > OK, leaving aside the dogs and the trees for the moment, a short question about the contents: > The draft states "The certificates discussed in this draft are generally self signed". It then talks about how the credential service can be used to obtain the credentials using an authenticated SUBSCRIBE/NOTIFY sequence. > > What puzzles me: why would a UA use the credential service to obtain a previously submitted self-signed certificate, instead of simply generating a new one by itself? Because several UAs share the same AOR and they all want to use a common cert? 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 Tue Jun 20 09:06:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsfuC-0005Nr-5U; Tue, 20 Jun 2006 09:04:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsfuA-0005Nm-H9 for sip@ietf.org; Tue, 20 Jun 2006 09:04:30 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsfu9-0005Ck-6f for sip@ietf.org; Tue, 20 Jun 2006 09:04:30 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 20 Jun 2006 09:04:30 -0400 X-IronPort-AV: i="4.06,155,1149480000"; d="scan'208"; a="90566149:sNHT125909804" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5KD4Sno014751 for ; Tue, 20 Jun 2006 09:04:28 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Jun 2006 09:04:28 -0400 Received: from [161.44.79.149] ([161.44.79.149]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Jun 2006 09:04:28 -0400 Message-ID: <4497F25C.1010200@cisco.com> Date: Tue, 20 Jun 2006 09:04:28 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] New draft on coexistence of SIP identity and P-Asserted-ID References: <4496A61A.7080905@cisco.com> <449734A3.30400@cisco.com> <449759B5.1080701@cisco.com> In-Reply-To: <449759B5.1080701@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 13:04:28.0756 (UTC) FILETIME=[104CF140:01C6946A] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: >> - While it is clear that you are trying to tighten up the security of >> identity from what it is in 3325, I'm not convinced that requiring the >> removal of P-Asserted-Identity when receiving a request from another >> domain actually achieves anything. Suppose it were left in? That means >> that if some server along the path was bad or inept the assertion >> might be a lie. But a bad or inept server in the originating network, >> before signing, can also result in an assertion that is a lie, and >> then result in a signature for that lie, and then to that being >> trusted in the terminating network. > > The main point is that I am trying to change the scope of P-Asserted-ID > to intra-domain, and thus by definition any value received from outside > the domain is meaningless. I think this begs the question of what it means for a message flow between a sender and a receiver to be "in the domain" vs "outside the domain". When sip:edge1.atlanta.com sends a message to sip:home3.atlanta.com, how do they decide they are in the same domain, and that it is the atlanta.com domain? Isn't that itself all a matter of trust? Or is there some formal definition of it? If it is all a matter of trust, then why is it ok for sip:home3.atlanta.com to trust sip:edge1.atlanta.com but not ok to trust sip:edge5.biloxi.com? Are all the atlanta.com servers supposed to be using TLS with mutual authentication and certs that say they are in atlanta.com? But then how do they prove they are the specific server they claim? Even in this case, why is it ok to trust the proxies in your own domain but not ok to trust those in another domain. Some providers are federations of semi-autonomous divisions, but want to appear to be a single domain. But that doesn't make them all equally competent. The trust of one division by another may not be as great as its trust in some other domain. 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 Tue Jun 20 11:28:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsi89-0007DV-7o; Tue, 20 Jun 2006 11:27:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsi87-0007DQ-On for sip@ietf.org; Tue, 20 Jun 2006 11:27:03 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsi85-0003Z6-Gl for sip@ietf.org; Tue, 20 Jun 2006 11:27:03 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id B150E6C01D; Tue, 20 Jun 2006 11:27:00 -0400 (EDT) Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt From: Scott Lawrence To: Cullen Jennings In-Reply-To: References: <44887921.20302@cisco.com> <1149796932.4721.129.camel@localhost.localdomain> <44898BD0.7000705@cisco.com> <26E13ED4-1582-4CB2-B74E-F5E0985F9810@cisco.com> <1150118729.2822.18.camel@sukothai.pingtel.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Tue, 20 Jun 2006 11:27:00 -0400 Message-Id: <1150817220.2889.50.camel@sukothai.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mon, 2006-06-19 at 17:15 -0700, Cullen Jennings wrote: > On Jun 12, 2006, at 6:25 AM, Scott Lawrence wrote: > > > - this introduces new normative behavior for all Servers > > > > - the new behavior is not controlled or advertised using the > > mechanisms > > for identifying extensions (Supported/Requires). > > If both of these are true, I agree with you. But I don't see why this > draft would need both of these. I'm not sure I understand what you mean. It introduces a new SHOULD. It does not specify any related feature/option tag. If you think either of these statements need to be changed, say how and why. > I see no reason this can not be optional behavior. I generally prefer to make everything mandatory that is not forbidden. Optional behavior is harmful to interoperability and confusing to implementors. > Anyways, this is a nit, the serious issues in the > draft has to do with the size of the responses. Do you have some suggestion with respect to that? -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 20 15:53:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsmFb-0003i1-Ny; Tue, 20 Jun 2006 15:51:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsmEe-0001Ss-Kr; Tue, 20 Jun 2006 15:50:04 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsmEc-0003Tk-Dp; Tue, 20 Jun 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5KJo2Rx015715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FsmEc-0003bO-2G; Tue, 20 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 20 Jun 2006 15:50:02 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-saml-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : SIP SAML Profile and Binding Author(s) : H. Tschofenig, et al. Filename : draft-ietf-sip-saml-00.txt Pages : 47 Date : 2006-6-20 This document specifies a Session Initiation Protocol (SIP) profile of Security Assertion Markup Language (SAML) as well as a SAML SIP binding. The defined SIP SAML Profile composes with the mechanisms defined in the SIP Identity specification and satisfy requirements presented in "Trait-based Authorization Requirements for the Session Initiation Protocol (SIP)". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-saml-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-saml-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-saml-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-20114635.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-saml-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-saml-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-20114635.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Tue Jun 20 16:07:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsmTp-0000Hz-OG; Tue, 20 Jun 2006 16:05:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsmTn-0000Ho-Dz for sip@ietf.org; Tue, 20 Jun 2006 16:05:43 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsmTl-0006Z2-4Y for sip@ietf.org; Tue, 20 Jun 2006 16:05:43 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 20 Jun 2006 13:05:40 -0700 X-IronPort-AV: i="4.06,158,1149490800"; d="scan'208"; a="1829325285:sNHT40438314" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k5KK5ePe021522; Tue, 20 Jun 2006 13:05:40 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5KK5d9s019865; Tue, 20 Jun 2006 13:05:39 -0700 (PDT) Received: from [171.71.97.11] (dhcp-171-71-97-11.cisco.com [171.71.97.11]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k5KK13Lg019215; Tue, 20 Jun 2006 13:01:04 -0700 Message-ID: <44985514.4010107@cisco.com> Date: Tue, 20 Jun 2006 13:05:40 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] draft-ietf-sip-certs-00, communicating private keys and self-signed certificates References: <002401c693c8$aab13400$31713b51@BEMBUSTER> <4497EAE7.9090700@cisco.com> In-Reply-To: <4497EAE7.9090700@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-4.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1066; t=1150833940; x=1151697940; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:Michael=20Thomas=20 |Subject:Re=3A=20[Sip]=20draft-ietf-sip-certs-00, =09communicating=20private=20key s=20and=0A=20self-signed=20certificates; X=v=3Dcisco.com=3B=20h=3DtOkffTLqRd6xPtl3JUjWoP2yWPY=3D; b=fJZgszJHmSdQ0G5eONr58N14P41IsSoUcx/1GM5qKu/8DgyX+N8/fjc5EqtaK8cBlUCMA1Tf NAgeeVEdqwXHB1iq14BbKSDBswRw6rl1AuY5yAeXQb1EvImFVouExaAF; X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: > > > Jeroen van Bemmel wrote: > >> If a dog barks at a tree and no-one hears it, did the dog make a sound? >> >> OK, leaving aside the dogs and the trees for the moment, a short >> question about the contents: >> The draft states "The certificates discussed in this draft are >> generally self signed". It then talks about how the credential >> service can be used to obtain the credentials using an authenticated >> SUBSCRIBE/NOTIFY sequence. >> >> What puzzles me: why would a UA use the credential service to obtain >> a previously submitted self-signed certificate, instead of simply >> generating a new one by itself? > > > Because several UAs share the same AOR and they all want to use a > common cert? Let us keep in mind that a certificate is nothing more than a key to identity binding. There is absolutely nothing wrong with having multiple keys being able to assert a given binding. Private keys should be thought of as roach motels: they check in, but they don't check out. 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 Tue Jun 20 16:28:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsmnx-0005ub-5Y; Tue, 20 Jun 2006 16:26:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsmnw-0005sg-0Q for sip@ietf.org; Tue, 20 Jun 2006 16:26:32 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsmnu-0000EB-Mq for sip@ietf.org; Tue, 20 Jun 2006 16:26:31 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k5KKQRA23856 for ; Tue, 20 Jun 2006 16:26:28 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C694A7.CE729C62" Date: Tue, 20 Jun 2006 15:26:12 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60CCDFD8B@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Cipher suites in SIP Thread-Index: AcaUovIyLMaT20ZTSWWUwYDlkv23kwABIAmw From: "Samir Srivastava" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [Sip] Cipher suites in SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C694A7.CE729C62 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In "wacky thread" I replied to David Oran's question on Cipher suites. Now it is available as ID. I will appreciate your comments on this. Mike Hammer also came up with the same viewpoint. But due to 00 version deadline and me working on weekend, I could not connect with him.=20 I was referring to one of discussion thread between Jonathan and Dean on the Proxy-Require / Supported after the submission. I think transport security level features were not considered earlier. For the ironclad encryption protection, we need Proxy-Require for ACK of non-2xx. This is due to _stateless_ proxies. Naturally it need to have the same tag as that of INVITE.=20 There has been warnings for SRV etc lookups for the stateless proxies in Section 4.4 of RFC 3263. We can add the similar warnings for this or allow Proxy-Require/Require. This point has been missed in this version. Or have I missed something ? Thx Samir=20 Title : Ensuring End to End Cipher Suites in SIP Author(s) : S. Srivastava Filename : draft-srivastava-sip-e2e-ciphersuites-00.txt Pages : 8 Date : 2006-6-20 =09 The security mechanism currently offered by SIP is essentially hop- by-hop and not end-to-end. The current SIP specification doesn't guarantee that a specific level of security (encryption, digest etc) is employed at each hop. This version of the draft outlines the solution broadly. As the solution progresses, it will have exact details in the subsequent versions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-srivastava-sip-e2e-ciphersuite s-00.txt =20 ------_=_NextPart_001_01C694A7.CE729C62 Content-Type: application/octet-stream; name="draft-srivastava-sip-e2e-ciphersuites-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-srivastava-sip-e2e-ciphersuites-00.URL Content-Disposition: attachment; filename="draft-srivastava-sip-e2e-ciphersuites-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1zcml2YXN0YXZhLXNpcC1lMmUtY2lwaGVyc3VpdGVzLTAwLnR4dA0K ------_=_NextPart_001_01C694A7.CE729C62 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C694A7.CE729C62-- From sip-bounces@ietf.org Tue Jun 20 16:37:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsmwW-0004Uf-MZ; Tue, 20 Jun 2006 16:35:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsmwU-0004Rh-Qr for sip@ietf.org; Tue, 20 Jun 2006 16:35:22 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsmwT-0002b9-G7 for sip@ietf.org; Tue, 20 Jun 2006 16:35:22 -0400 Received: from [192.168.1.5] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5KKan9K023020 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 20 Jun 2006 15:36:51 -0500 In-Reply-To: <44979FB4.8080708@infinet.ru> References: <4496999B.8020908@infinet.ru> <0AA1BDBF-DAB7-4FE1-A2B3-4AFDA6932F68@softarmor.com> <44979FB4.8080708@infinet.ru> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] SIP proto clarification needed. Date: Tue, 20 Jun 2006 15:35:10 -0500 To: Andrew Nesheret X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 20, 2006, at 2:11 AM, Andrew Nesheret wrote: > Hi. > > Dean Willis wrote: >> Why does the class 5 switch need to identify the calling gateway >> in an INVITE? >> >> Does it make an authentication/authorization decision, apply >> different routing rules based on which gateway called, or what? > Exactly. >> >> And how on earth are you getting a gateway to register? What is it >> registering? Every phone number it might possibly be able to >> reach? What does the REGISTER request have to do with a subsequent >> INVITE? > Gateway registers own contacts for it's AOR like any other > endpoint. But there is number of endpoints behind that GW. Active > AOR (AOR with bound contacts) means that this gateway is _online_. > Switch respectively configured to route number of destinations thru > that GW (and possible some other GWs). And V-V switch allows calls > from that destinations to came out of this GW. > > So, while GW (or no matter what else) initiates the call, first i > need to know which _registered_ entity acting now. > And second what is the number (SIP URI) of originating station. > > Hope this clarifies something. > No, but I'm more intrigued than ever. The gateways I'm familiar with (cisco) either don't register anything, or they send a registration for each phone number reachable behind the gateway. There's no AOR for the gateway itself. What does it mean to send an INVITE to the gateway's AOR? Does the gateway respond with a 200 OK? If so, who are you talking to? It sounds like you're sort of working backwards through registration to determine gateway reachability. If there is a contact for the gateway, you seem to be assuming the gateway is online and can be reached to reach the phone numbers that are (in some provisioning system) associated with the gateway. That's a novel use of registration, but highly inconsistent with the usual usage of registration. Most commonly, the registration interval is 3600 seconds, so the presence of a contact doesn't tell you a gateway is online now, it tells you the gateway was online within the last hour. Some systems use a live "heartbeat" mechanism for determining real- time reachability. Now, as for determining which gateway an INVITE is coming from: At its heart, this is an authentication question. Literally, answering "which gateway was that?" You might consider using the standard authentication mechanism for this. This would allow not only assertion "I claim to be gateway #1", but verification -- "I claim to be gateway #1, and I can prove it because I can present credentials." -- 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 Jun 20 17:07:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsnPZ-00065f-C7; Tue, 20 Jun 2006 17:05:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsnPX-0005zo-QV for sip@ietf.org; Tue, 20 Jun 2006 17:05:23 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsnPW-0000Y0-DE for sip@ietf.org; Tue, 20 Jun 2006 17:05:23 -0400 Received: (qmail 31170 invoked by uid 0); 20 Jun 2006 21:05:19 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 20 Jun 2006 21:05:19 -0000 Message-ID: <002f01c694ad$3c5479a0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Michael Thomas" , "Paul Kyzivat" References: <002401c693c8$aab13400$31713b51@BEMBUSTER> <4497EAE7.9090700@cisco.com> <44985514.4010107@cisco.com> Subject: Re: [Sip] draft-ietf-sip-certs-00, communicating private keys and self-signed certificates Date: Tue, 20 Jun 2006 23:05:18 +0200 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.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ----- Original Message ----- From: "Michael Thomas" To: "Paul Kyzivat" Cc: "Jeroen van Bemmel" ; Sent: Tuesday, June 20, 2006 10:05 PM Subject: Re: [Sip] draft-ietf-sip-certs-00, communicating private keys and self-signed certificates > Paul Kyzivat wrote: > >> >> >> Jeroen van Bemmel wrote: >> >>> If a dog barks at a tree and no-one hears it, did the dog make a sound? >>> >>> OK, leaving aside the dogs and the trees for the moment, a short >>> question about the contents: >>> The draft states "The certificates discussed in this draft are generally >>> self signed". It then talks about how the credential service can be used >>> to obtain the credentials using an authenticated SUBSCRIBE/NOTIFY >>> sequence. >>> >>> What puzzles me: why would a UA use the credential service to obtain a >>> previously submitted self-signed certificate, instead of simply >>> generating a new one by itself? >> >> >> Because several UAs share the same AOR and they all want to use a common >> cert? > > Let us keep in mind that a certificate is nothing more than a key to > identity > binding. There is absolutely nothing wrong with having multiple keys being > able to assert a given binding. Private keys should be thought of as roach > motels: > they check in, but they don't check out. > My thinking was that for some use cases (perhaps not all, e.g. not for the example in section 9.1) a user could obtain a list of certificates (or perhaps only their fingerprints) from the credential service. The UAC would then setup a TLS connection, and verify that the certificate presented by the other side is in the list. In this way, perhaps one could avoid sending private credentials across the network altogether. Small question on the Security considerations: it says 200 responses are omitted because "they do not have much to do with the overall security" - what about mutual authentication, using Authentication-Info? Should mutual authentication be RECOMMENDED, or would that be overkill (given that the TLS server cert is also verified)? Regards, jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 20 17:25:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsnhg-0001an-WE; Tue, 20 Jun 2006 17:24:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsnhe-0001ah-TH for sip@ietf.org; Tue, 20 Jun 2006 17:24:06 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsnhd-0001xN-9t for sip@ietf.org; Tue, 20 Jun 2006 17:24:06 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 20 Jun 2006 14:24:04 -0700 X-IronPort-AV: i="4.06,158,1149490800"; d="scan'208"; a="1829386979:sNHT45864196" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k5KLO4Yq026200; Tue, 20 Jun 2006 14:24:04 -0700 Received: from [192.168.1.3] (sjc-vpn2-409.cisco.com [10.21.113.153]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5KLO39s006671; Tue, 20 Jun 2006 14:24:03 -0700 (PDT) In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F026C1E91@esebe103.NOE.Nokia.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F026C1E91@esebe103.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <89CB8624-A6FE-48AA-BAF7-4A529E9D26AA@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] outbound i-d update? Date: Tue, 20 Jun 2006 11:19:18 -0700 To: "" X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=6935; t=1150838644; x=1151702644; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20outbound=20i-d=20update?; X=v=3Dcisco.com=3B=20h=3DUiVsMnvEokAmOy0hnZ/QC1ETTAQ=3D; b=Fz4c1az6FvSKO1d9f5DCXUee23qp+xQnch+1nwIeZAYT2IeOqtiCvvTDDr3RWYuf3U1BFmiB AWFobb+lutO1BAV07LghRVkMTRVD/y+zx6hK/+xNW9cQwNo+xfPUhne4; Authentication-Results: sj-dkim-4.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Outbound is still useful even if you only have one flow. For example, a system that was not trying to be high reliable but just wanted to use TLS. I think the next draft is OK for these use cases but let me know if I messed it up. On Jun 13, 2006, at 3:20 AM, wrote: > > Juha and Cullen, > >> 4.2 Initial Registrations >> >> UAs are configured with one or more SIP URIs representing >> the default >> outbound-proxy-set. >> >> UAs are configured with two or more ... > > Please do not forget about the effort to get the SIP Outbound > autodiscovery defined to rely on configuring only one single URI > with which the UA is able to derive the addresses of multiple > proxies. I would hope to keep the door still open for such a > solution. > >> If a UA has multiple flows, and one of the servers fails, it can >> delay some significant time before trying to form a new connection >> to replace the flow to the server that failed. >> >> the "If" surprises me here. i thought that the key idea of >> outbound-id is that each UA tries to keep more than flow active at >> all >> times. if this is not a requirement, then there is no chance for >> reliable load balancing and we are back in square one. > > There has been some requests on the list to have it possible for > a mobile device to keep only a single flow open in order to save > the battery. I still think SRV has a way to facilitate load balancing > even if the basic SRV has always aimed at one single connection per > client. By maintaining one single flow the UA does not get as high > reliability as with multiple flows, but I think load balancing could > still be achieved. > > Regards, > > Erkki > >> -----Original Message----- >> From: ext Juha Heinanen [mailto:jh@tutpro.com] >> Sent: 12.June.2006 11:14 >> To: Cullen Jennings >> Cc: sip@ietf.org >> Subject: Re: [Sip] outbound i-d update? >> >> 1. Introduction >> >> Since such detection takes time and leaves a window of >> opportunity for >> missed incoming requests, this mechanism allows the UA to >> use multiple >> flows to the proxy or registrar. >> >> i would say: >> >> ... to use simultaneous flows to multiple proxy or registrar hosts. >> >> since i don't understand what would multiple flows to THE proxy help. >> >> 2.1 Definitions >> >> outbound-proxy-set >> >> The first URI in the set is often refereed too as the >> primary outbound >> proxy and the second in as the secondary outbound >> proxy. There is no >> difference between the first and second and the >> primary/secondary does >> not imply one is preferred over the other. >> >> what is the third and fourth referred to? i would simply remove >> these >> two sentences. >> >> 3.3 Multiple Connections from a User Agent >> >> In the example system below, the logical proxy/registrar for the >> domain is running on two hosts that share the appropriate state >> and >> can both provide registrar and proxy functionality for the >> domain. The UA will form connections to two of the physical hosts >> that can perform the proxy/registrar function for the >> domain. Reliability is achieved by having the UA form two TCP >> connections to the domain. >> Scalability is achieved by using DNS SRV to load balance >> the primary >> connection across a set of machines that can service the primary >> connection and also using DNS SRV to load balance across a >> separate >> set of machines that can service the secondary connection. The >> deployment here requires that DNS is configured with one entry >> that >> resolves to all the primary hosts and another entry that >> resolves to >> all the secondary hosts. Designs having only one set were also >> considered, but in this case there would have to be some way to >> ensure that the two connection did not accidentally resolve to the >> same host. Various approaches for this are possible but >> all probably >> require extensions to the SIP protocol so they were not >> included in >> this specification. This approach can work with the disadvantage >> that slightly more configuration of DNS is required. >> >> i would greatly simplify the text: >> >> In the example system below, the logical outbound proxy/registrar for >> the domain is running on two hosts that share the appropriate >> state and >> can both provide registrar and outbound proxy functionality for the >> domain. The UA will form connections to two of the physical hosts >> that >> can perform the outbound proxy/registrar function for the >> domain. Reliability is achieved by having the UA form two TCP >> connections to the domain. Scalability is achieved by using DNS SRV >> records to load balance connections to the set of hosts that >> represent >> outbound proxies of the domain." >> >> instead of using the term "proxy", the above text uses the >> defined (2.1) >> term outbound proxy. more importantly, the details of implementing >> scalability are left as an internal matter of the domain. >> >> The UA is configured with a primary and secondary >> registration URI. >> >> i would say: >> >> The UA is configured with at least two URIs that represent at >> least two >> outbound proxies. >> >> again, use of the defined term "outbound proxy" and get rid of >> primary/secondary. >> >> When a single server fails, ... >> >> again a new undefined term "server". i would say >> >> When a single outbound proxy host fails, ... >> >> If a UA has multiple flows, and one of the servers fails, it can >> delay some significant time before trying to form a new connection >> to replace the flow to the server that failed. >> >> the "If" surprises me here. i thought that the key idea of >> outbound-id is that each UA tries to keep more than flow active at >> all >> times. if this is not a requirement, then there is no chance for >> reliable load balancing and we are back in square one. >> >> 4.2 Initial Registrations >> >> UAs are configured with one or more SIP URIs representing >> the default >> outbound-proxy-set. >> >> UAs are configured with two or more ... >> >> However, a UA MUST support sets with at least two outbound proxy >> URIs (primary and secondary) and SHOULD support sets with >> up to four >> URIs. >> >> leave out "(primary and secondary)". >> >> -- 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 Tue Jun 20 17:25:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsnhm-0001bV-RD; Tue, 20 Jun 2006 17:24:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsnhl-0001bQ-S4 for sip@ietf.org; Tue, 20 Jun 2006 17:24:13 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsnhk-0001xN-Ju for sip@ietf.org; Tue, 20 Jun 2006 17:24:13 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 20 Jun 2006 14:24:12 -0700 X-IronPort-AV: i="4.06,158,1149490800"; d="scan'208"; a="1829387092:sNHT111776586" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k5KLOCmX006211; Tue, 20 Jun 2006 14:24:12 -0700 Received: from [192.168.1.3] (sjc-vpn2-409.cisco.com [10.21.113.153]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5KLO39t006671; Tue, 20 Jun 2006 14:24:11 -0700 (PDT) In-Reply-To: <17551.50567.283816.835349@rautu.tutpro.com> References: <5EB80D22825EEE42872083AD5BFFB594017F10A6@esealmw113.eemea.ericsson.se> <17551.50567.283816.835349@rautu.tutpro.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] outbound i-d update? Date: Tue, 20 Jun 2006 11:21:10 -0700 To: Juha Heinanen X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=591; t=1150838652; x=1151702652; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20outbound=20i-d=20update?; X=v=3Dcisco.com=3B=20h=3DUiVsMnvEokAmOy0hnZ/QC1ETTAQ=3D; b=W8c49A+ktZxwxsKgQiUhZSrHTWi84hDKVURWF6fUXwmu+2Mqk/SQ30gsBvYTaiZnXqXnyGns MwBzzaUivt+0CRlA5o/91enuJL3YVBbG7G74H2z8Ky2PFjEO79rdQCV+; Authentication-Results: sj-dkim-2.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: sip@ietf.org, "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 14, 2006, at 1:15 AM, Juha Heinanen wrote: > however, the important thing is that IF domain advertises more than > one > outbound URI or a single URI that resolve(s) to more than one proxy > host, then UA MUST keep flows open to at least two of those proxy > hosts. > > without this above requirement, outbound-id doesn't add any real value > over what we have today. Agree - I been tryiing to write this so the UA need to implement support for multliple flows - at least two and should do four can do more Operator of a domain can choose how many to use _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 20 17:26:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsnht-0001kP-Om; Tue, 20 Jun 2006 17:24:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsnhs-0001kK-Nc for sip@ietf.org; Tue, 20 Jun 2006 17:24:20 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsnhr-0001y4-Fi for sip@ietf.org; Tue, 20 Jun 2006 17:24:20 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 20 Jun 2006 14:24:17 -0700 X-IronPort-AV: i="4.06,158,1149490800"; d="scan'208"; a="298038889:sNHT295457164" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k5KLOHVV026457; Tue, 20 Jun 2006 14:24:17 -0700 Received: from [192.168.1.3] (sjc-vpn2-409.cisco.com [10.21.113.153]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5KLO39u006671; Tue, 20 Jun 2006 14:24:17 -0700 (PDT) In-Reply-To: <20060616112021737.00000003956@jrogde-se> References: <20060616112021737.00000003956@jrogde-se> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Cullen Jennings Subject: Re: [Sip] outbound i-d update? Date: Tue, 20 Jun 2006 11:45:13 -0700 To: "jan.rogde@oracle.com" X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=347; t=1150838657; x=1151702657; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20outbound=20i-d=20update?; X=v=3Dcisco.com=3B=20h=3DrZ5gmqNyhAntk/N2pG2BgeEZQGE=3D; b=OIjpVT+UIxQ29bdT2x05sk6LNpQ9algWr1yUUNKVvvzOppmXG81wYMrPw/Cl5qYh9DM8WK5D lv79f4+qLmaMqByZehm6gtDQ0dZKwXYWUyuhP39vpmHf/WxDA47+iPcy; Authentication-Results: sj-dkim-4.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 16, 2006, at 2:20 AM, Jan R=F6gde wrote: > wouldn't it be easier for everyone involved if outbound and gruu =20 > was combined? I feel very strongly this would complicate things. They can be =20 seperated and I think we should keep them this way. These have all =20 take too long and combining them would only slow things donw. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 20 17:43:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsnyS-0000DO-2H; Tue, 20 Jun 2006 17:41:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsnyR-0000DJ-6e for sip@ietf.org; Tue, 20 Jun 2006 17:41:27 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsnyP-0003cF-Sq for sip@ietf.org; Tue, 20 Jun 2006 17:41:27 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 20 Jun 2006 14:41:24 -0700 X-IronPort-AV: i="4.06,158,1149490800"; d="scan'208"; a="298052222:sNHT33218920" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k5KLfPmU016810; Tue, 20 Jun 2006 14:41:25 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5KLfOke004650; Tue, 20 Jun 2006 14:41:24 -0700 (PDT) Received: from [171.71.97.11] (dhcp-171-71-97-11.cisco.com [171.71.97.11]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k5KLamJo021291; Tue, 20 Jun 2006 14:36:48 -0700 Message-ID: <44986B85.3090904@cisco.com> Date: Tue, 20 Jun 2006 14:41:25 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] draft-ietf-sip-certs-00, communicating private keys and self-signed certificates References: <002401c693c8$aab13400$31713b51@BEMBUSTER> <4497EAE7.9090700@cisco.com> <44985514.4010107@cisco.com> <002f01c694ad$3c5479a0$31713b51@BEMBUSTER> In-Reply-To: <002f01c694ad$3c5479a0$31713b51@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-3.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=2508; t=1150839685; x=1151703685; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:Michael=20Thomas=20 |Subject:Re=3A=20[Sip]=20draft-ietf-sip-certs-00, =09communicating=20private=20key s=20and=0A=20self-signed=20certificates; X=v=3Dcisco.com=3B=20h=3DtOkffTLqRd6xPtl3JUjWoP2yWPY=3D; b=WHt6+9LwZgySehIeRZFWy8Ht3FyxfuiqgLptBiL7BwDL0oMnDRK0iBnnUikOA3fVsLojOaeT GainlONMu6NEFPq4pyPQMw122ZsAh8xxsbjgRXd8zOpsEt2En71EvldX; X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: sip@ietf.org, Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel wrote: > > ----- Original Message ----- From: "Michael Thomas" > To: "Paul Kyzivat" > Cc: "Jeroen van Bemmel" ; > Sent: Tuesday, June 20, 2006 10:05 PM > Subject: Re: [Sip] draft-ietf-sip-certs-00, communicating private keys > and self-signed certificates > > >> Paul Kyzivat wrote: >> >>> >>> >>> Jeroen van Bemmel wrote: >>> >>>> If a dog barks at a tree and no-one hears it, did the dog make a >>>> sound? >>>> >>>> OK, leaving aside the dogs and the trees for the moment, a short >>>> question about the contents: >>>> The draft states "The certificates discussed in this draft are >>>> generally self signed". It then talks about how the credential >>>> service can be used to obtain the credentials using an >>>> authenticated SUBSCRIBE/NOTIFY sequence. >>>> >>>> What puzzles me: why would a UA use the credential service to >>>> obtain a previously submitted self-signed certificate, instead of >>>> simply generating a new one by itself? >>> >>> >>> >>> Because several UAs share the same AOR and they all want to use a >>> common cert? >> >> >> Let us keep in mind that a certificate is nothing more than a key to >> identity >> binding. There is absolutely nothing wrong with having multiple keys >> being >> able to assert a given binding. Private keys should be thought of as >> roach motels: >> they check in, but they don't check out. >> > > My thinking was that for some use cases (perhaps not all, e.g. not for > the example in section 9.1) a user could obtain a list of certificates > (or perhaps only their fingerprints) from the credential service. The > UAC would then setup a TLS connection, and verify that the certificate > presented by the other side is in the list. This is a different beast than moving private keys around. Transporting *public* keys is perfectly OK. > In this way, perhaps one could avoid sending private credentials > across the network altogether. Yes, sending private keys is a no-no. Mike > Small question on the Security considerations: it says 200 responses > are omitted because "they do not have much to do with the overall > security" - what about mutual authentication, using > Authentication-Info? Should mutual authentication be RECOMMENDED, or > would that be overkill (given that the TLS server cert is also verified)? > > Regards, > > jeroen > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 20 17:54:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fso9a-0003bT-Rx; Tue, 20 Jun 2006 17:52:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fso9Z-0003bO-PU for sip@ietf.org; Tue, 20 Jun 2006 17:52:57 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fso9Y-00060k-GC for sip@ietf.org; Tue, 20 Jun 2006 17:52:57 -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 k5KLqs6c021349; Tue, 20 Jun 2006 16:52:54 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k5KLqsc17784; Tue, 20 Jun 2006 16:52:54 -0500 (CDT) Message-ID: <44986E36.5090408@lucent.com> Date: Tue, 20 Jun 2006 16:52:54 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] The SIPSEC URI I-D References: <4496B598.1060505@lucent.com> <44973D81.5030307@cisco.com> In-Reply-To: <44973D81.5030307@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: > Vijay, > > Thanks for taking the first step! Paul: Thanks for a reading of the draft! > My first comment is that I question whether the requirements you have > proposed are the right ones. While they might be sufficient, I suspect > that in many environments a solution meeting those requirements will be > unacceptable. I can't say you are wrong; but other environments (P2P?) may find the requirements a bit more attractive. > Specifically, a guarantee that depends on hop-by-hop trust may be quite > acceptable if it at least guarantees: > - nobody but the endpoints and intermediaries on the signaling path > can see the signaling > - nobody but the endpoints and intermediaries on the signaling path > have the keys to the media > (Both assuming you trust the intermediaries) I thought that trusting the intermediaries was the basic problem, since nothing short of an end-to-end cert exchange would suffice. As the draft now states, the intermediaries are used to rendezvous, but then they become conduits to opaque information flowing between the endpoints. > Going back to your proposals, I was thinking maybe your SIPSEC URI > scheme might just be used as the contact in a target refresh request. I > think that would solve a number of the problems, though perhaps > introducing some new ones. Used this way, a session would be established > normally and then a reINVITE or UPDATE used to negotiate an e2e secure > signaling session. Then the keys for a media session would be exchanged. > This would perhaps normally be opportunistic. If required then > callerprefs could be used to exclude those that can't or don't want to > play. Right. > The caller could make a normal, insecure, offer. If the answerer wants > security, it could accept the request but refuse all the media. Once the > session is established, one side would send a target refresh using > SIPSEC, (or maybe SIPS would be enough here). In that exchange the > media, including keys, would be negotiated. Right. Thanks, Paul. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 20 19:37:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fspkh-0005D8-5n; Tue, 20 Jun 2006 19:35:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fspkf-0005Cg-Nh for sip@ietf.org; Tue, 20 Jun 2006 19:35:21 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fspke-0000Hw-3E for sip@ietf.org; Tue, 20 Jun 2006 19:35:21 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 20 Jun 2006 16:35:19 -0700 X-IronPort-AV: i="4.06,158,1149490800"; d="scan'208"; a="1829456812:sNHT37301250" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k5KNZJHW031414; Tue, 20 Jun 2006 16:35:19 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5KNZIcL017651; Tue, 20 Jun 2006 16:35:18 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Jun 2006 19:35:17 -0400 Received: from [161.44.79.149] ([161.44.79.149]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Jun 2006 19:35:17 -0400 Message-ID: <44988634.7040604@cisco.com> Date: Tue, 20 Jun 2006 19:35:16 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Sip] The SIPSEC URI I-D References: <4496B598.1060505@lucent.com> <44973D81.5030307@cisco.com> <44986E36.5090408@lucent.com> In-Reply-To: <44986E36.5090408@lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 23:35:17.0514 (UTC) FILETIME=[2FEB16A0:01C694C2] DKIM-Signature: a=rsa-sha1; q=dns; l=4697; t=1150846519; x=1151710519; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20The=20SIPSEC=20URI=20I-D; X=v=3Dcisco.com=3B=20h=3DEQP9ur1JNFpniTswXdiNXm8AugM=3D; b=O/F7bBRffcXrDH8GWaRUF4D2Q4Vn8sCR8lyXy1vTY6+8k3ZlgH2G+bGlWA1xjmbRDwyJjTiu xGLPT4CmD1+ioIWhk3CjeLmudhF9p4xnYcpr0kOgLSYcGrem0PzFZ1KP; Authentication-Results: sj-dkim-8.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Vijay K. Gurbani wrote: > Paul Kyzivat wrote: >> Vijay, >> >> Thanks for taking the first step! > > Paul: Thanks for a reading of the draft! > >> My first comment is that I question whether the requirements you have >> proposed are the right ones. While they might be sufficient, I suspect >> that in many environments a solution meeting those requirements will >> be unacceptable. > > I can't say you are wrong; but other environments (P2P?) may find > the requirements a bit more attractive. > >> Specifically, a guarantee that depends on hop-by-hop trust may be >> quite acceptable if it at least guarantees: >> - nobody but the endpoints and intermediaries on the signaling path >> can see the signaling >> - nobody but the endpoints and intermediaries on the signaling path >> have the keys to the media >> (Both assuming you trust the intermediaries) > > I thought that trusting the intermediaries was the basic problem, > since nothing short of an end-to-end cert exchange would suffice. > As the draft now states, the intermediaries are used to rendezvous, > but then they become conduits to opaque information flowing between > the endpoints. Well, in retrospect, its obvious we can't talk about whether these requirements are correct or not. There may be different sets of correct requirements. Your requirements are stronger than what I was suggesting. In a perfect world I would rather have a system built to your requirements. The current status quo is considerably worse than relying on trusted intermediaries. I would rather have have a lesser set of requirements that actually get implemented on the systems that people use. E.g. I would like something that gets implemented on Vonage and its cousins, and IMS and its cousins. Anything that gets implemented as a replacement for "regular phone service". If it is "as good as" the security of "regular phone service" then it is a big improvement over what we have now. After I responded the other day I was thinking that one thing we lack is some concrete use cases to measure this against. Here are some initial thoughts on that: - There exist a set (one or more) copywrited/branded icons corresponding to various levels of security. Each has a thorough specification of what guarantees that particular icon denotes. - devices / software loads for devices are certified for the right to display one of these icons. To achieve certification the device must have been verified that it follows the appropriate specifications. - when a user originates or terminates a call, the device displays a security icon iff the call conforms to the corresponding spec. - some devices may be configurable to accept a call only if the call will conform to particular security specifications. - some devices may be configurable to only complete a call it originates if the call will conform to a particular security spec. (Ideally the call will only be offered to those that can conform.) That is all very generic. Based on a framework like that we can then discuss what particular security specifications make sense, and how many of them it makes sense for there to be for general use. I am having difficulty imagining more than three levels being useful, and even three is a stretch: - SECURE You know for certain the identity you are connected to (though it might not be who you thought you were calling.) Not even the NSA can tap your call. - PSTN-SECURITY You are assured that your device, in conjunction with others, performed due diligence (documented) in determining the identity displayed (if any) for the connected party. Your provider and its trusted peers, most likely including legal authorities, may intervene and tap. They are legally bound regarding what they will do. There is assurance that others cannot intervene tap your call. - INSECURITY You can count on no security at all. (This is what a lot of SIP calls provide today.) If PSTN-SECURITY began to be offered, people would likely start to ask why a system doesn't always offer something at least that good. The only answers that would hold much water are: - not our fault. we can do better if the other end can. - this is cheap (i.e. free) and you get what you pay for I expect PSTN-SECURITY would become the low bar, at least for any paid service. And as long as many calls have one end in the PSTN, there will be many that can't do better than that, so it is an important level of security to offer. SECURE then can become a premium service. 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 Tue Jun 20 19:42:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsppz-0001gp-J6; Tue, 20 Jun 2006 19:40:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsppy-0001co-0V for sip@ietf.org; Tue, 20 Jun 2006 19:40:50 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsppw-0000tZ-OW for sip@ietf.org; Tue, 20 Jun 2006 19:40:49 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 20 Jun 2006 19:40:48 -0400 X-IronPort-AV: i="4.06,158,1149480000"; d="scan'208"; a="90629201:sNHT31392612" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5KNemYL020384; Tue, 20 Jun 2006 19:40:48 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Jun 2006 19:40:47 -0400 Received: from [192.168.1.101] ([10.86.243.91]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Jun 2006 19:40:47 -0400 Message-ID: <4498877F.70805@cisco.com> Date: Tue, 20 Jun 2006 19:40:47 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Nesheret Subject: Re: [Sip] SIP proto clarification needed. References: <4496999B.8020908@infinet.ru> <0AA1BDBF-DAB7-4FE1-A2B3-4AFDA6932F68@softarmor.com> <44979FB4.8080708@infinet.ru> In-Reply-To: <44979FB4.8080708@infinet.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 23:40:47.0807 (UTC) FILETIME=[F4C9CCF0:01C694C2] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: sip@ietf.org, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Andrew Nesheret wrote: >> >> And how on earth are you getting a gateway to register? What is it >> registering? Every phone number it might possibly be able to reach? >> What does the REGISTER request have to do with a subsequent INVITE? > > Gateway registers own contacts for it's AOR like any other endpoint. But > there is number of endpoints behind that GW. Active AOR (AOR with bound > contacts) means that this gateway is _online_. Switch respectively > configured to route number of destinations thru that GW (and possible > some other GWs). And V-V switch allows calls from that destinations to > came out of this GW. This sounds like tgrep: http://www.ietf.org/internet-drafts/draft-ietf-iptel-tgrep-07.txt -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 20 19:46:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsptI-0004UI-IG; Tue, 20 Jun 2006 19:44:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsptH-0004T0-55 for sip@ietf.org; Tue, 20 Jun 2006 19:44:15 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsptF-0001Z8-T8 for sip@ietf.org; Tue, 20 Jun 2006 19:44:15 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 20 Jun 2006 16:44:13 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,158,1149490800"; d="scan'208"; a="30092683:sNHT21588678" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5KNiDno015531; Tue, 20 Jun 2006 19:44:13 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Jun 2006 19:44:13 -0400 Received: from [192.168.1.101] ([10.86.243.91]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Jun 2006 19:44:13 -0400 Message-ID: <4498884C.1030607@cisco.com> Date: Tue, 20 Jun 2006 19:44:12 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] New draft on coexistence of SIP identity and P-Asserted-ID References: <5EB80D22825EEE42872083AD5BFFB594017F1143@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F1143@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 23:44:13.0260 (UTC) FILETIME=[6F3F70C0:01C694C3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Christer Holmberg (JO/LMF) wrote: > > Hi Jonathan, > > Assume the UAC, sending a request, is located in domain A (originating > domain). The request then exists domain A via egress proxy A, and enters > domain B (transit domain) via ingress proxy B. The behavior of those > proxies are described in the draft. > > Now, the request exits domain B, via proxy X, and enters domain C > (terminating domain) via ingress proxy C, and then reaches the UAS > located in domain C. > > My question is: what is proxy X? As far as I understand it's not an > egress proxy (as defined by the draft), since the domain (domain B) does > not match the From header (domain A). Right. > Does the mechanism in the draft > have any impacts on proxy X behavior (should it add/remove > P-Asserted/Identity-Info etc) in the first place? Yeah, this isn't in the draft. it would remove P-Asserted-ID if present. It shouldn't normally be present since the ingress to domain B would have removed it if there. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 20 19:50:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fspxk-0007U8-HU; Tue, 20 Jun 2006 19:48:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fspxi-0007TM-Uw for sip@ietf.org; Tue, 20 Jun 2006 19:48:50 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fspxh-0001ly-Lt for sip@ietf.org; Tue, 20 Jun 2006 19:48:50 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 20 Jun 2006 16:48:49 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,158,1149490800"; d="scan'208"; a="30093001:sNHT23466608" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5KNmnno016582 for ; Tue, 20 Jun 2006 19:48:49 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Jun 2006 19:48:49 -0400 Received: from [192.168.1.101] ([10.86.243.91]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Jun 2006 19:48:48 -0400 Message-ID: <44988960.1000500@cisco.com> Date: Tue, 20 Jun 2006 19:48:48 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] New draft on coexistence of SIP identity and P-Asserted-ID References: <4496A61A.7080905@cisco.com> <449734A3.30400@cisco.com> <449759B5.1080701@cisco.com> <4497F25C.1010200@cisco.com> In-Reply-To: <4497F25C.1010200@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 23:48:48.0780 (UTC) FILETIME=[137874C0:01C694C4] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I view a domain, in the SIP context, as a set of proxies under single administrative control. This is also somewhat loosely defined, I admit. The main idea is that, since a single administrative entity manages the proxies (configuring them, operating them, etc.), it has complete confidence that it knows the precise and absolute conditions under which P-Asserted-ID was inserted into the request. There is trust inter-domain, but knowledge about the configuration of the proxy that resulted in insertion of P-Asserted-ID isn't known directly - its known indirectly by trusting that the peer domain did its job. I think thats different. -Jonathan R. Paul Kyzivat wrote: > > > Jonathan Rosenberg wrote: > >>> - While it is clear that you are trying to tighten up the security of >>> identity from what it is in 3325, I'm not convinced that requiring >>> the removal of P-Asserted-Identity when receiving a request from >>> another domain actually achieves anything. Suppose it were left in? >>> That means that if some server along the path was bad or inept the >>> assertion might be a lie. But a bad or inept server in the >>> originating network, before signing, can also result in an assertion >>> that is a lie, and then result in a signature for that lie, and then >>> to that being trusted in the terminating network. >> >> >> The main point is that I am trying to change the scope of >> P-Asserted-ID to intra-domain, and thus by definition any value >> received from outside the domain is meaningless. > > > I think this begs the question of what it means for a message flow > between a sender and a receiver to be "in the domain" vs "outside the > domain". When sip:edge1.atlanta.com sends a message to > sip:home3.atlanta.com, how do they decide they are in the same domain, > and that it is the atlanta.com domain? > > Isn't that itself all a matter of trust? Or is there some formal > definition of it? If it is all a matter of trust, then why is it ok for > sip:home3.atlanta.com to trust sip:edge1.atlanta.com but not ok to trust > sip:edge5.biloxi.com? > > Are all the atlanta.com servers supposed to be using TLS with mutual > authentication and certs that say they are in atlanta.com? But then how > do they prove they are the specific server they claim? > > Even in this case, why is it ok to trust the proxies in your own domain > but not ok to trust those in another domain. Some providers are > federations of semi-autonomous divisions, but want to appear to be a > single domain. But that doesn't make them all equally competent. The > trust of one division by another may not be as great as its trust in > some other domain. > > Paul > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 20 19:53:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsq0D-0002Lt-VP; Tue, 20 Jun 2006 19:51:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsq0C-0002IX-Ah for sip@ietf.org; Tue, 20 Jun 2006 19:51:24 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsq0A-0001tm-0a for sip@ietf.org; Tue, 20 Jun 2006 19:51:24 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 20 Jun 2006 16:51:22 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,158,1149490800"; d="scan'208"; a="30093180:sNHT23047912" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5KNpLno017182; Tue, 20 Jun 2006 19:51:21 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Jun 2006 19:51:21 -0400 Received: from [192.168.1.101] ([10.86.243.91]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Jun 2006 19:51:21 -0400 Message-ID: <449889F8.30107@cisco.com> Date: Tue, 20 Jun 2006 19:51:20 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] Outbound: keep-alive, outbound and 3489bis References: <5EB80D22825EEE42872083AD5BFFB594017F1138@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F1138@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 23:51:21.0369 (UTC) FILETIME=[6E6BB090:01C694C4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think we should allow the STUN keepalives without the rest of the stuff. Its a handy tool for inter-server keepalives in cases where there are no NAT or firewalls. -Jonathan R. Christer Holmberg (JO/LMF) wrote: > > Hi, > > A few issues on the outbound draft: > > Q1: > ----- > > The outbound draft currently defines the usage of STUN for NAT keep-alive. > > However, since NAT keep-alive has been added as a STUN usage to the STUN > specification (3489bis) itself, I guess the outbound draft only needs to > refer to 3489bis and "apply" it to SIP, e.g. by defining the keepalive > URI parameter. > > > Q2: > ----- > > If a client supports STUN for keep-alive, but not the other parts of the > outbound extension (instance-id, reg-id etc), it will not insert the > instance-id etc, but it will still include the 'keepalive' URI parameter. > > Now, the outbound draft does not FORBID this, as far as I can see, but I > wonder if we more clearly should point that out in the draft. > > OR, the SIP usage of STUN keep-alive should be described in a separate > draft, now when the usage itself is part of 3489bis. > > OR, if I only use STUN for keep-alive, without the rest of the outbound > stuff, should I not use the 'keepalive' parameter in the first place? > > > > Regards, > > Christer > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 20 20:34:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsqeG-0007Le-05; Tue, 20 Jun 2006 20:32:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsqeE-0007In-St for sip@ietf.org; Tue, 20 Jun 2006 20:32:46 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsqeD-0003Gj-HO for sip@ietf.org; Tue, 20 Jun 2006 20:32:46 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k5L0RIK26048; Tue, 20 Jun 2006 20:27:18 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound: keep-alive, outbound and 3489bis X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 20 Jun 2006 19:32:39 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0ABDCBD1@zrc2hxm0.corp.nortel.com> In-Reply-To: <449889F8.30107@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: keep-alive, outbound and 3489bis Thread-Index: AcaUxH78o1L8GTO6R1ynXp/ysgni3wABQCVg From: "Francois Audet" To: "Jonathan Rosenberg" , "Christer Holmberg \(JO/LMF\)" , "Cullen Jennings" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I agree. It would be nice if in Outbound, there was some sort of indication on what is required to be there if only the keepalive is done. Maybe a little paragraph on this in the section on keep-alive in sip-outbound-04 would help. I think it would really help to have some guidance on this to answer the question that Christer has. (Besides the use that Jonathan points to, it could be useful in certain=20 environments to phase out PINGs, short-lived registration, CRLFs and other legacy mechanisms. I can see an option on a phone to use STUN-in-SIP for keep-alive as implementable today). > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Tuesday, June 20, 2006 16:51 > To: Christer Holmberg (JO/LMF) > Cc: sip@ietf.org > Subject: Re: [Sip] Outbound: keep-alive, outbound and 3489bis >=20 >=20 > I think we should allow the STUN keepalives without the rest of the=20 > stuff. Its a handy tool for inter-server keepalives in cases=20 > where there=20 > are no NAT or firewalls. >=20 > -Jonathan R. >=20 > Christer Holmberg (JO/LMF) wrote: >=20 > >=20 > > Hi, > >=20 > > A few issues on the outbound draft: > >=20 > > Q1: > > ----- > >=20 > > The outbound draft currently defines the usage of STUN for NAT=20 > > keep-alive. > >=20 > > However, since NAT keep-alive has been added as a STUN usage to the=20 > > STUN > > specification (3489bis) itself, I guess the outbound draft=20 > only needs to=20 > > refer to 3489bis and "apply" it to SIP, e.g. by defining=20 > the keepalive=20 > > URI parameter. > >=20 > >=20 > > Q2: > > ----- > >=20 > > If a client supports STUN for keep-alive, but not the other=20 > parts of=20 > > the > > outbound extension (instance-id, reg-id etc), it will not=20 > insert the=20 > > instance-id etc, but it will still include the 'keepalive'=20 > URI parameter. > >=20 > > Now, the outbound draft does not FORBID this, as far as I=20 > can see, but=20 > > I > > wonder if we more clearly should point that out in the draft. > >=20 > > OR, the SIP usage of STUN keep-alive should be described in=20 > a separate > > draft, now when the usage itself is part of 3489bis. > >=20 > > OR, if I only use STUN for keep-alive, without the rest of the=20 > > outbound > > stuff, should I not use the 'keepalive' parameter in the=20 > first place? > >=20 > >=20 > >=20 > > Regards, > >=20 > > Christer > >=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=20 > current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sipping@ietf.org for new developments on the=20 > application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 20 22:46:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsshZ-0004LJ-NO; Tue, 20 Jun 2006 22:44:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsshY-0004K4-ES for sip@ietf.org; Tue, 20 Jun 2006 22:44:20 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsshX-0003BI-64 for sip@ietf.org; Tue, 20 Jun 2006 22:44:20 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 20 Jun 2006 19:44:18 -0700 X-IronPort-AV: i="4.06,158,1149490800"; d="scan'208"; a="298183355:sNHT32068468" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k5L2iIZf023978; Tue, 20 Jun 2006 19:44:18 -0700 Received: from [192.168.1.2] (sjc-vpn7-662.cisco.com [10.21.146.150]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5L2iHcL011863; Tue, 20 Jun 2006 19:44:17 -0700 (PDT) In-Reply-To: References: <4.3.2.7.2.20060614115113.018f6ef8@email.cisco.com> <449074D0.4090609@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <94BC0886-3E82-456C-AEFB-90710612ADDC@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Additional uses of INFO Date: Tue, 20 Jun 2006 19:44:15 -0700 To: Dean Willis X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=997; t=1150857858; x=1151721858; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Additional=20uses=20of=20INFO; X=v=3Dcisco.com=3B=20h=3DsEQPL8dAsj/gnpqxQfAZl9puQtM=3D; b=csUD/muCCNpZWVdJGs66vPqdBNnRFz7N7SP2jvQg6p0gvdaSRlqN3kt67cq0vKd8ImH74Kar Ku5vICG9VJeqkrdTM3hETkD7eUsyC8G7tXIHsS2+EatUisYJsLqQWWxS; Authentication-Results: sj-dkim-8.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: sip@ietf.org, "James M. Polk" , "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 14, 2006, at 8:53 PM, Dean Willis wrote: > Do we have to change HTTP every time somebody uses it to get a new > type of image file or to build a new type of web application? Let > me think . . . nope, we don't. Clearly some applications fit inside the extensibility model that HTTP had - others, such as webdav, caldav, atom may not change HTTP but were some pretty serious extensions - and Don't even ask about how ETag works consistently across all theses. Back to the topics of SIP ... I have not gone and read the various drafts on this but it seems like we have some recommendation on how to extend SIP (RFC 4485). Now I'm sure eventually things will come up where this is not enough but discussing it in the abstract is pretty hard. I'd rather not build new extensibility mechanisms until we saw some things that would use them - I'd be very afraid whatever we build would not meet the needs of anything if it was done in the abstract. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 20 23:17:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FstCE-0002LA-RE; Tue, 20 Jun 2006 23:16:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FstCD-0002L3-8Y for sip@ietf.org; Tue, 20 Jun 2006 23:16:01 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FstCB-0008CL-U9 for sip@ietf.org; Tue, 20 Jun 2006 23:16:01 -0400 Received: from [192.168.1.5] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5L3HTlL024360 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 20 Jun 2006 22:17:31 -0500 In-Reply-To: <4498877F.70805@cisco.com> References: <4496999B.8020908@infinet.ru> <0AA1BDBF-DAB7-4FE1-A2B3-4AFDA6932F68@softarmor.com> <44979FB4.8080708@infinet.ru> <4498877F.70805@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <28BC5370-2519-40B7-8C67-19D8F310D990@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] SIP proto clarification needed. Date: Tue, 20 Jun 2006 22:15:53 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 20, 2006, at 6:40 PM, Jonathan Rosenberg wrote: > inline. > > Andrew Nesheret wrote: > > >>> >>> And how on earth are you getting a gateway to register? What is >>> it registering? Every phone number it might possibly be able to >>> reach? What does the REGISTER request have to do with a >>> subsequent INVITE? >> Gateway registers own contacts for it's AOR like any other >> endpoint. But there is number of endpoints behind that GW. Active >> AOR (AOR with bound contacts) means that this gateway is _online_. >> Switch respectively configured to route number of destinations >> thru that GW (and possible some other GWs). And V-V switch allows >> calls from that destinations to came out of this GW. > > This sounds like tgrep: > > http://www.ietf.org/internet-drafts/draft-ietf-iptel-tgrep-07.txt > Not the way I'm reading it. It seems more like we have a proposal for an AOR for "the gateway". The gateway registers a contact against the AOR. One might use such an AOR with something like an event package so that the gateway could report on utilization -- send a "SUBSCRIBE" to the gateway on the to-be-specified "gateway event package" and get NOTIFY messages talking about what the gateway is doing. Now, assume a route provisioning system that knows about "gateway1@example.com" and "gateway2@example.com". It knows that both of these have a set of routes, which we might assume are completely overlapping (they route to the same destinations). If we get a call that we need to send to a destination in that route set, which gateway do we use? I believe the proposal is that we pick from the set of gateways that currently have a registered contact, on the assumption that a gateway that has a registered contact is more likely to be "live" than a gateway that has let its registrations expire. I think this is a clumsy way to figure out if a gateway is reachable, but it seems to be the intent of Andrew's system as I understand it. But I think tgrep plus a heartbeat or liveness probe would probably be more effective. -- 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 Jun 21 02:08:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsvqw-0007lm-Tj; Wed, 21 Jun 2006 02:06:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsvqv-0007kX-B4 for sip@ietf.org; Wed, 21 Jun 2006 02:06:13 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsvqs-0008RT-W3 for sip@ietf.org; Wed, 21 Jun 2006 02:06:13 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-2.cisco.com with ESMTP; 20 Jun 2006 23:06:11 -0700 X-IronPort-AV: i="4.06,158,1149490800"; d="scan'208"; a="325400136:sNHT35526880" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k5L66Ais011185; Tue, 20 Jun 2006 23:06:10 -0700 Received: from [192.168.1.2] (sjc-vpn7-662.cisco.com [10.21.146.150]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5L669Is023820; Tue, 20 Jun 2006 23:06:09 -0700 (PDT) In-Reply-To: <1150817220.2889.50.camel@sukothai.pingtel.com> References: <44887921.20302@cisco.com> <1149796932.4721.129.camel@localhost.localdomain> <44898BD0.7000705@cisco.com> <26E13ED4-1582-4CB2-B74E-F5E0985F9810@cisco.com> <1150118729.2822.18.camel@sukothai.pingtel.com> <1150817220.2889.50.camel@sukothai.pingtel.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9B35A371-360F-48CB-AEB9-11377CE896EA@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt Date: Tue, 20 Jun 2006 23:06:07 -0700 To: Scott Lawrence X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=2369; t=1150869970; x=1151733970; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20I-D=20ACTION=3Adraft-ietf-sip-hop-limit-diagnostics-02.t xt; X=v=3Dcisco.com=3B=20h=3DuuoBsEgzdw6+9X+Y6yGlgJ8d2Es=3D; b=bgKl8KCc8P7MuvGhC8L9RRiNzZzrdX7BovYKF07qXaZ4RpVrlkgqg+Ru8FlmfJA2Mwdu2Q9G X2v0J/N0ejsfmveFnmrxaSIZnjhbkyZzRKd+IsqBm6/AvvIJCJ8D9ao4; Authentication-Results: sj-dkim-8.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 20, 2006, at 8:27 AM, Scott Lawrence wrote: > On Mon, 2006-06-19 at 17:15 -0700, Cullen Jennings wrote: >> On Jun 12, 2006, at 6:25 AM, Scott Lawrence wrote: >> >>> - this introduces new normative behavior for all Servers >>> >>> - the new behavior is not controlled or advertised using the >>> mechanisms >>> for identifying extensions (Supported/Requires). >> >> If both of these are true, I agree with you. But I don't see why this >> draft would need both of these. > > I'm not sure I understand what you mean. It introduces a new SHOULD. > It does not specify any related feature/option tag. If you think > either > of these statements need to be changed, say how and why. > >> I see no reason this can not be optional behavior. > > I generally prefer to make everything mandatory that is not forbidden. > Optional behavior is harmful to interoperability and confusing to > implementors. I am suggesting that you say that servers that support this RFC need to do this and let servers decide if they want to support it or not. This is comparable to say REFER. You will note that REFER does not update 3261. A device can decide if it wants to implement this or not. Perhaps I misunderstood your intent and you are saying that everything that does 3261 should have to implement this. > >> Anyways, this is a nit, the serious issues in the >> draft has to do with the size of the responses. > > Do you have some suggestion with respect to that? Yes - I believe the magic number we agreed on for UDP was something close to 1200. You need to say that if any of the hops used UDP, the response MUST NOT be larger than 1200 octets. You then need to show some scheme for a making the response smaller than this. In a typical example with default max hops, I really don't see how this will be possible. I've be very interested in seeing how large a typical example that had the full trace in from actually is. I know this is not very satisfying - I hope some can think of a better way to solve this but I'm not coming up with one. > > -- > Scott Lawrence tel:+1-781-938-5306;ext=162 or > sip:slawrence@pingtel.com > sipXpbx project coordinator - SIPfoundry http:// > www.sipfoundry.org/sipX > Chief Architect - Pingtel Corp. http://www.pingtel.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 Jun 21 02:13:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsvvx-0002Dg-6z; Wed, 21 Jun 2006 02:11:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsvvw-0002Db-He for sip@ietf.org; Wed, 21 Jun 2006 02:11:24 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsvvs-00015J-1n for sip@ietf.org; Wed, 21 Jun 2006 02:11:21 -0400 Received: (qmail 21779 invoked by uid 0); 21 Jun 2006 06:11:13 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 21 Jun 2006 06:11:13 -0000 Message-ID: <001c01c694f9$81039120$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Jonathan Rosenberg" , "IETF SIP List" References: <44976078.6020408@cisco.com> Subject: Re: [Sip] Updated acr-code draft Date: Wed, 21 Jun 2006 08:11:15 +0200 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.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan, (Only) one comment: What about privacy service behavior? In particular I am thinking about a privacy service that anonymized the request, and receives a 433. If the privacy service is acting as a B2BUA, it should probably not retry the request "non-anonymously" (this could constitute a downgrade attack). This is also something worth mentioning in the security considerations: the retrying of the request SHOULD be based on an explicit decision by the user making the request, it SHOULD NOT be done automatically Regards, Jeroen ----- Original Message ----- From: "Jonathan Rosenberg" To: "IETF SIP List" Sent: Tuesday, June 20, 2006 4:42 AM Subject: [Sip] Updated acr-code draft > I've just submitted a minor update to the ACR code draft. Until it > appears, you can pick it up at: > > http://www.jdrosen.net/papers/draft-ietf-sip-acr-code-01.txt > > The changes were to add the required RFC 2119 boilerplate and fix some > spell check errors. The document is complete AFAIK and has had no > discussion since the last revision. I believe it ready for WGLC. > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 21 02:22:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsw4h-00083g-LW; Wed, 21 Jun 2006 02:20:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsw4f-00083P-NZ for sip@ietf.org; Wed, 21 Jun 2006 02:20:26 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsw4e-0001Qp-9x for sip@ietf.org; Wed, 21 Jun 2006 02:20:25 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Wed, 21 Jun 2006 08:20:23 +0200 Received: by S4DE8PSAANQ.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Jun 2006 08:20:23 +0200 Message-Id: <85108216918A984C8C60172D7C84770A08A598@S4DE8PSAAGO.mitte.t-com.de> From: "Jesske, R" To: dean.willis@softarmor.com, jdrosen@cisco.com Subject: AW: [Sip] Additional uses of INFO Date: Wed, 21 Jun 2006 08:20:18 +0200 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: 9466e0365fc95844abaf7c3f15a05c7d Cc: sip@ietf.org, jmpolk@cisco.com, drage@lucent.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > MESSAGE is INFO, except that INFO is supposedly always in a dialog > (it doesn't really have to be) whereas as MESSAGE could be > but really > sortof is not supposed to be, and MESSAGE is supposedly always > presented to the user (which we know is not true in practice). > Personally, I'd suggest unifying the two with a stronger explication > of content-disposition and be done with it. I think the "info > package" model gives us that stronger explication. > There are thoughts to use INFO for MCID (Malicious Communication Identification) to fulfil a TISPAN requirement described in draft-jesske-sipping-tispan-requirements-02. MCID is a regulatory service. One requirement is: REQ-MCID-2: For interoperability reasons, the MCID simulation service logic needs to get the knowledge that, even if the originator identity is missing in the signalling, it can available upon request. This is due to, e.g., interworking with the PSTN network, where, in some cases, the originator's identity is only available upon explicit request. The information can be received asynchronously in a time-frame of 1-30 seconds even after the session has been closed. So we need the binding to the dialog to have a proper interworking with the PSTN/ISDN to retrieve the information. So after this discussion it looks for me that INFO is a good candidate and can be used but we need some further description to rule the content of INFO out as Dean pointed out. Am I correct. Thanks Best Regards Roland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 21 05:30:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsz0i-0007S6-EE; Wed, 21 Jun 2006 05:28:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsz0g-0007NM-MX for sip@ietf.org; Wed, 21 Jun 2006 05:28:30 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsz0e-00040O-5e for sip@ietf.org; Wed, 21 Jun 2006 05:28:30 -0400 Received: from rly01b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly01b.srv.mailcontrol.com (MailControl) with ESMTP id k5L9SRYu002712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 21 Jun 2006 10:28:27 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly01b.srv.mailcontrol.com (MailControl) id k5L9Rt19001760 for sip@ietf.org; Wed, 21 Jun 2006 10:27:55 +0100 Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly01b-eth0.srv.mailcontrol.com (envelope-sender cboulton@ubiquity.net) (MIMEDefang) with ESMTP id k5L9RsnO001699; Wed, 21 Jun 2006 10:27:55 +0100 (BST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Sip] Additional uses of INFO Date: Wed, 21 Jun 2006 10:27:54 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE03118A99@gbnewp0758m.eu.ubiquity.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Additional uses of INFO Thread-Index: AcaP0Eto3WeKmq1BTc66j/652HnTEgFRCHkQ From: "Chris Boulton" To: "Dean Willis" , "Sip IETF" X-Scanned-By: MailControl A-07-00-10 (www.mailcontrol.com) on 10.66.1.111 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Keith Drage X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org And now, for a view from the other side of the peanut gallery: I think INFO is potentially a great mechanism for exchanging=20=20 structured data within dialog-bounded applications (perhaps not=20=20 extensions=20 [Chris Boulton] Dean - You should really take a look at the new Control Framework (http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework -02.txt) that is currently being worked on by a bunch of folks for the primary purpose of media server control. It has the agnostic structure and explicit extension mechanism for exchanging 'structured data' in a reliable manner. It might require a new, more suitable primitive, but that bit is easy. Chris. Information contained in this e-mail and any attachments are intended for t= he use of the addressee only, and may contain confidential information of U= biquity Software Corporation. All unauthorized use, disclosure or distribu= tion is strictly prohibited. If you are not the addressee, please notify t= he sender immediately and destroy all copies of this email. Unless otherwi= se expressly agreed in writing signed by an officer of Ubiquity Software Co= rporation, nothing in this communication shall be deemed to be legally bind= ing. Thank you. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 21 06:32:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FszyJ-0004In-Eg; Wed, 21 Jun 2006 06:30:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FszyH-0004Id-Ch for sip@ietf.org; Wed, 21 Jun 2006 06:30:05 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FszyF-0002dk-MT for sip@ietf.org; Wed, 21 Jun 2006 06:30:05 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 6C7043C0BB for ; Wed, 21 Jun 2006 12:30:02 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15020-01-50 for ; Wed, 21 Jun 2006 12:30:01 +0200 (CEST) Received: from dhcp-wavelan-vo-57.publik.su.se (dhcp-wavelan-vo-57.publik.su.se [193.11.30.57]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 2D7E73BE67 for ; Wed, 21 Jun 2006 12:30:01 +0200 (CEST) From: Fredrik Thulin To: sip@ietf.org Date: Wed, 21 Jun 2006 12:29:57 +0200 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606211229.57450.ft@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.641 tagged_above=-99 required=7 tests=[AWL=0.024, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Subject: [Sip] Comments on draft-ietf-sip-identity-06 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi I've read the sip-identity draft, and have a number of comments/questions (in the order the text appear in the document) : >4. Overview of Operations >... >and thus can validates that the domain indicated nit: should be "can validate" >5. Authentication Service Behavior >... > Note that if that proxy > server is maintaining a TLS connection with the client over which > the client had previously authenticated itself using Digest > authentication, the identity value obtained from that previous > authentication step can be reused without an additional Digest > challenge. How can the authentication service know for sure that a TLS connection was initiated by the client, and not an intermediate SIP ALG in front of a wifi hotspot for example (assuming that the client does not present a client certificate)? The SIP ALG might be hiding the inside topology so that there is only a single Via header present. I realize that this is non-normative text, but I think it is bad advice security-wise unless it is said explicitly that it only applies if the client has a SSL client certificate. > If the authentication service is instantiated by a SIP user agent, > a user agent can be said to authenticate its user on the grounds > that the user can provision the user agent with the private key of > the domain, or preferably by providing a password that unlocks > said private key I'm sure this is not what is intended, but this almost sound as if you think it is perfectly normal to make the private key available publicly as long as it is protected by a password. That might be true if the password is _stronger_ than the certificate, but passwords typically aren't. I propose that you remove the last part (", or preferably ..."). > Finally, the authentication service MUST forward the message > normally. I don't think you need RFC2119 language to describe that someone must do what they normally would. >6. Verifier Behavior >... > Once the certificate is acquired, it MUST be > validated following the procedures in RFC3280 [9]. If the > certificate cannot be validated (it is self-signed and untrusted, or > signed by an untrusted or unknown certificate authority, expired, or > revoked), the verifier MUST send a 437 'Unsupported Certificate' > response. I understand that your intentions are good, but I'm afraid that this part will make deployment on the open internet close to impossible until there is a global PKI root (will not happen), or the number of bridge CA's make close to 100% of all certificates verifiable. For example, Swedish universitys can join the SwUPKI PKI, and those of us that have typically only use certificates issued by sub-CA's to SwUPKI. I won't be deploying sip-identity if it makes the chances of my users calls being accepted by any third party on the Internet fail, if the alternative is to NOT implement it, and have the calls succeed although without identity assertions. Note that there are several reasons why small-scale PKIs are common, most of them have nothing to do with economy. There is a trend towards bridging PKIs which eventually will bring several local community PKIs into a loosly connected network of trust but this is a gradual process which will take several years and one which will never be entierly complete. Since, as you say in the draft, a man-in-the-middle attacker can just strip the sip-dentity related headers from requests, I really think it is reasonable that the text above opens up for a identity validator that receives something signed by an unknown party _removes_ the identity related headers, and forwards the request as if there were no identity headers if local policy says that this is what should be done. Text could be ", the verifier SHOULD send a 437 'Unsupported Certificate' response. The verifier MAY forward the request as if no Identity headers were present, if local policy permits, but in this case it MUST remove the Identity and Identity-Info headers from the request". >9. Header Syntax >... >the first letter of each week and month MUST be capitalized nit: should be weekday I believe >10.2. Identity for a Request with no MIME body or Contact >... > When the authentication service receives the BYE, it authenticates > Bob by sending a 407 response. Can a BYE really be challenged? RFC3261 15.1.1 (UAC Behavior) says a UA can consider the session terminated as soon as the BYE is passed to it's transaction layer. In my experience, user agents aren't trying very hard to clean up network state for sessions they themselves consider terminated, although I agree they should. This issue was discussed for example in this thread on sip-implementors : http://www1.ietf.org/mail-archive/web/sip/current/msg11118.html I'm not sure what to do from the sip-identity perspective. My personal preference would be to push for making UAs actually handle challenges to BYE, but as Paul Kyzivat said in the message linked above, that ain't going to happen if the credentials have expired and the user has walked away from the terminal. If some kind of change to the draft is made, then the update of Table 2 of RFC 3261 in section 9 of the draft might also need updating. >13.1. Handling of digest-string Elements >... > Implementations MUST also record Call-IDs received in > valid requests containing an Identity header, and MUST remember those > Call-IDs for at least the duration of a single Date interval (i.e. > commonly 3600 seconds). Because a SIP-compliant UA never generates > the same Call-ID twice, verifiers can use the Call-ID to recognize > cut-and-paste attacks; the Call-ID serves as a nonce. This seem problematic 1) This applies to _all_ the verifiers in a domain. If the verification is done by a domains SIP servers (not the callee's user agent) then they will have to use a distributed database or a single point of failure database to remember the Call-Ids seen by _any_ of the verifiers. 2) If the verification is done by the callee's end user agents, I beleive it would be possible for an attacker to capture a request (say a MESSAGE) sent from sip:bob@biloxi to sip:alice@atlanta, and then send an identical MESSAGE with From: sip:bob@biloxi, To: sip:alice@atlanta but Request-URI sip:carol@atlanta. I'm not sure there will ever be a value for any attacker in doing this, but it seems possible since Alice and Carol's user agents are very unlikely to share information about previously seen Call-Ids. Even if it seems to be a meaningless attack, it is still an attack, or have I missed something making this impossible? 3) This IS a problem if the Call-Ids generated by a UA is predictable, although unique. I beleive RFC3261 doesn't say that Call-Ids must not be predictable, even though it says they must be unique. For example, say that Alice has a UA that produces sequential Call-Ids with the IP address as 'what makes these unique'. Alice calls me, so I get her UAs current Call-Id. She tells me that she is going to call sip:someone@example.org right after our call. I want to prevent her from doing that. During our call, I send requests to example.org with the Call-Id's I predict Alices UA will use. Alices call to sip:someone@example.org will get rejected Also, what makes subsequent requests in the same dialog as the first one not get rejected? They will have the same Call-Id. >13.2. Display Names and Identity >... >SIP accounts with arbitrarily display-names. nit: I'm not a native english speaker, but I believe it should be "arbitrary". >13.4. Domain Names and Subordination >... su.se has about ~120 subdomains for different parts of the organization. Many of these run their own web servers and so on, some with SSL certificates for the domain name. It is not an appealing idea to have all these certificates on our SIP identity providing servers. There have been a couple of different proposals of how to create certificates for specific services of a domain. I think this draft should point at draft-ietf-pkix-srvsan as how this should be done, as this is the sollution I believe have gained most acceptance, but I might be wrong... /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 21 07:03:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft0SX-0006Kj-EU; Wed, 21 Jun 2006 07:01:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsYUD-00045p-LR for sip@ietf.org; Tue, 20 Jun 2006 01:09:13 -0400 Received: from [203.200.4.5] (helo=serversmb.kodiaknetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsYU5-0001vT-Rh for sip@ietf.org; Tue, 20 Jun 2006 01:09:13 -0400 Received: from Nataraju ([192.168.3.66]) by serversmb.kodiaknetworks.com (8.11.6/8.11.6) with ESMTP id k5K58Ha00872; Tue, 20 Jun 2006 10:38:18 +0530 From: "Nataraju A B" To: "'Lei Weimin'" , "'Rayees Khan'" Subject: RE: [Sip] Re: INVITE request after 302 response Date: Tue, 20 Jun 2006 10:37:25 +0530 Message-ID: <005501c69427$6c841a30$0132a8c0@Nataraju> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <004a01c693ff$a5b6ec10$338ba8c0@leiwm> Importance: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: 9121ca079d965f33ea826aa6b20ceaa1 X-Mailman-Approved-At: Wed, 21 Jun 2006 07:01:20 -0400 Cc: sip@ietf.org, sumit.dhar@flextronicssoftware.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="===============0764590751==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0764590751== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0056_01C69455.863C5630" This is a multi-part message in MIME format. ------=_NextPart_000_0056_01C69455.863C5630 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is very similar to REFER/Referred-BY scenarios. But this redirected INVITE (from 3xx) does not have any header similar to Referred-BY header. If we really need we can extend with referred-by, but this is again a workaround for the problem. But we can make it workable. Thanks & Regards, Nataraju A.B. -----Original Message----- From: Lei Weimin [mailto:leiwm@sict.ac.cn] Sent: Tuesday, June 20, 2006 5:53 AM To: Rayees Khan Cc: bnataraju@kodiaknetworks.com; Zhang Wei; Lei Weimin; sip@ietf.org; sumit.dhar@flextronicssoftware.com Subject: Re: [Sip] Re: INVITE request after 302 response Thanks for your kind response. Just as Rayees said, I also think these is NO general solution to the problem at present. We have to find a specific solution to keep accounts for the "302 Invite" Thanks a lot. Lei Weimin leiwm@sict.ac.cn http://www.sipsys.com From: Rayees Khan To: rathi.kartheek@wipro.com Cc: bnataraju@kodiaknetworks.com ; zhangwei@sict.ac.cn ; Sumit Dhar ; leiwm@sict.ac.cn Sent: Monday, June 19, 2006 11:35 PM Subject: RE: [Sip] Re: INVITE request after 302 response There is no general solution to the problem at the moment. Any solution would be implementation specific. Since the only thing that is common in the first INVITE and re-directed INVITE is From header and the URI in re-directed INVITE is same as contact in 302. Something needs to be worked out form that. regards Rayees ----- wrote: ----- To: Rayees Khan/HSS@HSS From: Date: 06/19/2006 02:54PM cc: , , Sumit Dhar/BLR/HSS@HSS, Subject: RE: [Sip] Re: INVITE request after 302 response Hi Rayees, If CC-Diversion Header is not followed, what alternative do u have to indicate the info of UA2 to UA3 when the call gets forwarded ? Regards, Rathi -----Original Message----- From: Rayees Khan [mailto:rayees.khan@flextronicssoftware.com] Sent: Monday, June 19, 2006 6:14 PM To: Rathi Kartheek (WT01 - Broadband Networks) Cc: bnataraju@kodiaknetworks.com; zhangwei@sict.ac.cn; Sumit Dhar; leiwm@sict.ac.cn Subject: RE: [Sip] Re: INVITE request after 302 response Hi Rathi, There are very few UAs which support draft-levy-sip-diversion so normally, as of today, we do not see any Cc Diversion headers. However, as I had mentioned the From header does not change for sure. regards Rayees ----- wrote: ----- To: , Rayees Khan/HSS@HSS, From: Date: 06/19/2006 10:02AM cc: Sumit Dhar/BLR/HSS@HSS, Subject: RE: [Sip] Re: INVITE request after 302 response {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman";} Hi , Difference between INVITE after 302 and the normal INVITE ? and How can my Proxy Server obtain UA2's info only from the second INVITE request? 1. Invite after 302 will contain an additional header called : CC-Diversion header which contains the contact of the person who has forwarded the call. That is - 302 message will contain CC-Diversion header(indicating that it is forwarding the call). This header is extracted and put in the new invite. Also- cseq number is be incremented by one. Thus UA2's info is obtained by the UA3 by looking at the CC-Diversion header. 2. To header will now contain the address of the contact(UA3's URI) which is received in 302.(That is to whom u r intending to forward the call) 3. From header is retained as it is. Regards, Rathi -----Original Message----- From: Nataraju A B [mailto:bnataraju@kodiaknetworks.com] Sent: Monday, June 19, 2006 11:49 AM To: 'Rayees Khan'; 'zhangwei' Cc: sip@ietf.org; 'Sumit Dhar'; 'Lei Weimin' Subject: RE: [Sip] Re: INVITE request after 302 response Thanks & Regards, Nataraju A.B. -----Original Message----- From: Rayees Khan [mailto:rayees.khan@flextronicssoftware.com ] Sent : Sunday, June 18, 2006 9:44 PM To: zhangwei Cc: sip@ietf.org; Sumit Dhar; Lei Weimin Subject: Re: [Sip] Re: INVITE request after 302 response Hi Mr Zhang, As far as I understand the behaviour of UAs the normal procedure is that on receiving 302 response the UA would extract the information from contact of 302 and put it into request line of new INVITE. The INVITE that would be generated by UA as a result of this redirection would have UA3 in request line and UA2 in 'To' header. However, it is not mandatory, and UA can choose to change both. One of the ways I can think of is to have some kind of intelligence in proxy to keep track of the 302 responses that are proxied. The INVITE generated form these UAs after 302 are most likely to be result of 302, though again there is no guarantee. Additionally, one more interesting point is that the From header is likely to be retained. [ABN] if the INVITE is generated because of 302, then the new INVITE would have the same TO header which was there in the received request. Otherwise this might lead to dialog match in the UAC once final response received from UA3 by UAC (UA1). Only R-URI would be changed with the contact address received in the 302 response. regards Rayees -----"zhangwei" wrote: ----- To: Sumit Dhar/BLR/HSS@HSS, , "Lei Weimin" From: "zhangwei" Date: 06/16/2006 03:04PM Subject: [Sip] Re: INVITE request after 302 response Hello Sumit, Thanks for your response. Take an example for the application. UA1 Proxy Server UA2 UA3 | | | | |---INVITE--->| | | | |--- INVITE --> | | | |<----302 ------| | |<----302-------| | | | | | | |-----ACK---->| | | | |---ACK------>| | |---INVITE--->| | | | |------------ INVITE ---->| | |<--100/180/200------| |100/180/200| | | | | | | |----ACK----->| | | | |--------------ACK----->| Our project need to account according to INVITE/200/ACK and BYE. For the instance above, we want to make two accountings. One is UA1 call UA2. The other is UA2 call UA3. Our Proxy Server is transaction stateful. But we want that Proxy Server can obtain UA1 UA2 and UA3's info only from the second INVITE request. How can my Proxy Server obtain UA2's info only from the second INVITE request? Thanks & Best regards Zhang Wei ----- Original Message ----- From: Sumit Dhar To: zhangwei Sent: Friday, June 16, 2006 7:08 PM Subject: Re: INVITE request after 302 response Hello Mr Zhang, Thanks for your mail. I wasnt too sure however as to where you got my contacts from. I have anyways organized a response for your question which is enclosed in my mail. May I request to know more details about the project you are working on, and if we can possible collaborate . Thanks & Best Regards, Sumit Response> A typical 3261 compliant transaction stateful proxy would not be able to distinguish if an INVITE is an initial INVITE sent by a UA OR was sent subsequent to the reception of a 302 response. Also, a transatcion stateful proxy need not know it. An exception however is when a proxy is capable to performing recursion. In this case, the proxy would interpret the 302 response by itself and send a new INVITE to the redirected contact address. If however, there is a need to know that an INVITE was redirected, one option is to check the cseq number.. RFC 3261 recommends that the UA uses the same call-id, from-tag, to-tag etc and just increment the cseq number for a new INVITE towards the redirected address. However, this is just a recommendation and may not be adhered to by the UA. -------------------------------------------------------- Sumit Dhar Segment Manager, Service Provider Products Business, Flextronics Software Systems (Formerly Hughes Software Systems) No. 18, Outer Ring Road, Panathur Post, Bangalore -560 087, India Phone : +91-80-4106 7138 Fax : +91-80-4126 6501 visit us at http://www.flextronicssoftware.com "zhangwei" 06/16/2006 01:11 PM To Sumit Dhar/BLR/HSS@HSS cc Subject INVITE request after 302 response Hi, In SIP, 302 Moved Temporarily can be used by User Agent to set call forwarding. When the caller received 302, it should re-create a new INVITE request to forward call to a given contact. My question is how Proxy Server detect whether INVITE is created after having received 302 response. The Proxy Server is transaction stateful. What's the difference between INVITE after 302 and the normal INVITE ? Regards Zhang Wei *********************** FSS- Confidential *********************** "DISCLAIMER: This message is proprietary to Flextronics Software Systems (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip *****FSS-Private *****" DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com *****FSS-Private *****" DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com *****FSS-Private *****" DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." ------=_NextPart_000_0056_01C69455.863C5630 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is very similar to = REFER/Referred-BY scenarios. But this redirected INVITE (from 3xx) does not have any = header similar to Referred-BY header.

 

=

If we really need we can extend = with referred-by, but this is again a workaround for the problem. But we can = make it workable…

 

=

Thanks & = Regards,

Nataraju = A.B.

-----Original Message-----
From: = Lei Weimin = [mailto:leiwm@sict.ac.cn]
Sent: Tuesday, June 20, 2006 5:53 = AM
To: = Rayees Khan
Cc: = bnataraju@kodiaknetworks.com; Zhang Wei; Lei = Weimin; = sip@ietf.org<= /st1:PersonName>; sumit.dhar@flextronicssoftware.com
Subject: Re: [Sip] Re: = INVITE request after 302 response

 

 

Thanks for your kind response.

Just as Rayees said, I also think these is = NO general solution to the problem at present.

 

We have to find a specific solution to keep accounts = for the "302 Invite"

 

Thanks a lot.

 

 

Lei Weimin

 

 

 

 

From: Rayees Khan =

Sent: = Monday, June 19, 2006 11:35 PM

Subject: RE: = [Sip] Re: INVITE request after 302 response

 


There is no general solution to the problem at the moment. Any solution = would be implementation specific.

Since the only thing that is common in the first INVITE and re-directed = INVITE is From header and the URI in re-directed INVITE is same as contact in = 302. Something needs to be worked out form that.

regards
Rayees


-----<rathi.kartheek@wipro.com>= wrote: -----

To: Rayees Khan/HSS@HSS
From: <rathi.kartheek@wipro.com>=
Date: 06/19/2006 02:54PM
cc: <bnataraju@kodiaknetworks.com= >, <zhangwei@sict.ac.cn>, = Sumit Dhar/BLR/HSS@HSS, <leiwm@sict.ac.cn>
Subject: RE: [Sip] Re: INVITE request after 302 = response

Hi Rayees= ,

If CC-Diversion Header is not = followed,

what alternative do u have to = indicate the info of UA2 to UA3

when the call = gets forwarded ? = =

Regards, =

Rathi =

-----Original = Message-----
From: Rayees Khan = [mailto:rayees.khan@flextronicssoftware.com]
Sent: Monday, June 19, = 2006 6:14 PM
To: Rathi Kartheek (WT01 = - Broadband Networks)
Cc: = bnataraju@kodiaknetworks.com; zhangwei@sict.ac.cn; Sumit Dhar; leiwm@sict.ac.cn
Subject: RE: [Sip] Re: = INVITE request after 302 response


Hi Rathi,

There are very few UAs which support draft-levy-sip-diversion so = normally, as of today, we do not see any Cc Diversion headers. However, as I had = mentioned the From header does not change for sure.


regards
Rayees

-----<rathi.kartheek@wipro.co= m> wrote: -----

To: <bnataraju@kodiaknetworks.com>, Rayees Khan/HSS@HSS, <zhangwei@sict.ac.cn>
From: <rathi.kartheek@wipro.com>
Date: 06/19/2006 10:02AM
cc: Sumit Dhar/BLR/HSS@HSS, <leiwm@sict.ac.cn>
Subject: RE: [Sip] Re: INVITE request after 302 response

     {mso-style-name:"Table Normal";         mso-tstyle-rowband-size:0;         mso-tstyle-colband-size:0;         = mso-style-noshow:yes;         mso-style-parent:"";         = mso-padding-alt:0in 5.4pt 0in 5.4pt;         = mso-para-margin:0in;         mso-para-margin-bottom:.0001pt;         mso-pagination:widow-orphan;         = font-size:10.0pt;         font-family:"Times New = Roman";}

Hi ,

Difference between INVITE after 302 and the normal = INVITE ? and

How can my Proxy Server = obtain UA2's=20 info only from the second INVITE request? =20 1. Invite after = 302 will contain an additional header called :

   = CC-Diversion header which contains the contact of the person

   = who has forwarded the call.

   = That is - 302 message will contain CC-Diversion header(indicating that it is = forwarding the call).

  &n= bsp;This header is extracted and put in the new invite. =

   Also-  cseq number is be incremented by = one.

   = Thus UA2's info is obtained by the UA3 by looking at the CC-Diversion header. =

  &n= bsp;  

2. To header will now contain the = address of the contact(UA3's URI)

  &n= bsp; which is received in 302.(That is to whom u r intending to forward the = call)

3. = From header is retained as it is. =

Regards,

Rathi =

 



-----Original = Message-----
From: Nataraju A B [mailto:bnataraju@kodiaknetworks.com]
Sent: Monday, June 19, = 2006 11:49 AM
To: 'Rayees Khan'; = 'zhangwei'
Cc: sip@ietf.org; 'Sumit = Dhar'; 'Lei Weimin'
Subject: RE: [Sip] Re: = INVITE request after 302 response

 

 

Thanks & Regards, =

Nataraju A.B. =

-----Original Message-----
From: = Rayees Khan = [mailto:rayees.khan@flextronicssoftware.com ]
Sent = : Sunday, June 18, 2006 9:44 PM =
To: = zhangwei
Cc: sip@ietf.org; Sumit = Dhar; Lei Weimin
Subject: Re: [Sip] Re: = INVITE request after 302 response

  =


Hi Mr Zhang,

As far as I understand the behaviour of UAs the normal procedure is that = on receiving 302 response the UA would extract the information from contact = of 302 and put it into request line of new INVITE. The INVITE that would be = generated by UA as a result of this redirection would have UA3 in request line and = UA2 in 'To' header. However, it is not mandatory, and UA can choose to change = both.
One of the ways I can think of is to have some kind of intelligence in = proxy to keep track of the 302 responses that are proxied. The INVITE generated = form these UAs after 302 are most likely to be result of 302, though again = there is no guarantee. Additionally, one more interesting point is that the From header is likely to be retained.
<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->

[ABN] if the INVITE is generated because of 302, then the = new INVITE would have the same TO header which was there in the received = request. Otherwise this might lead to dialog match in the UAC once final response received from UA3 by UAC (UA1). Only R-URI would be changed with the = contact address received in the 302 response.

regards
Rayees


<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->

-----"zhangwei" <zhangwei@sict.ac.cn> = wrote: -----

To: = Sumit Dhar/BLR/HSS@HSS, <sip@ietf.org>, "Lei Weimin" <leiwm@sict.ac.cn>
From: "zhangwei" <zhangwei@sict.ac.cn>
Date: 06/16/2006 03:04PM
Subject: [Sip] Re: INVITE request after 302 response =

Hello Sumit,

  =

Thanks for your response.

  =

Take an example for the application.

  =

UA1    &= nbsp; Proxy Server    UA2    UA3 =

|    &nb= sp;             |            =       |         | =

|---INVITE--->| &nbs= p;            = ;    |         | =

|    &nb= sp;           &nbs= p; |--- INVITE = --> |         | =

|    &nb= sp;           &nbs= p; |<----302 ------|         | =

|<----302-------| &n= bsp;                |         | =

|             &= nbsp;     |                  |         | =

|-----ACK---->| &nbs= p;            = ;    |         | =

|    &nb= sp;             |---ACK------>|         | =

|---INVITE--->| &nbs= p;            = ;    |         | =

|    &nb= sp;           &nbs= p; |------------ INVITE = ---->|

|    &nb= sp;             |<--100/180/200------| =

|100/180/200|  &nb= sp;               = |         | =

|    &nb= sp;           &nbs= p; |                  |         |

|----ACK----->| &nbs= p;            = ;    |         | =

|    &nb= sp;           &nbs= p; |--------------ACK----->|

  =

  =

Our project need to account according to INVITE/200/ACK and BYE.   =

  =

For the instance above, we want to make two accountings. One is UA1 call UA2. = The other is UA2 call UA3.

  =

Our Proxy Server is transaction stateful. But we want that Proxy Server can obtain = UA1 UA2 and UA3's info only from the second INVITE request. =

  =

How can my Proxy Server obtain UA2's info only from the second INVITE request?  =

  =

  =

Thanks & Best regards

  =

Zhang Wei =

  =

----- Original Message ----- =

From: = Sumit Dhar =

Sent: = Friday, June 16, 2006 7:08 PM =

Subject: = Re: INVITE request after 302 response =

  =


Hello Mr Zhang,

Thanks for your mail.

I wasnt too sure however as to where you got my contacts from. I have = anyways organized a response for your question which is enclosed in my mail. =

May I request to know more details about the project you are working on, = and if we can possible collaborate .

Thanks & Best Regards,

Sumit

Response>
A typical 3261 compliant transaction stateful proxy would not be able to distinguish if an INVITE is an initial INVITE sent by a UA
OR was sent subsequent to the reception of a 302 response. Also, a = transatcion stateful proxy need not know it.
An exception however is when a proxy is capable to performing recursion. = In this case, the proxy would interpret the 302 response
by itself and send a new INVITE to the redirected contact address.


If however, there is a need to know that an INVITE was redirected, one = option is to check the cseq number..
RFC 3261 recommends that the UA uses the same call-id, from-tag, to-tag = etc and just increment the cseq number for
a new INVITE towards the redirected address. However, this is just a recommendation and may not be adhered to by the UA.





--------------------------------------------------------
 Sumit Dhar          
 Segment Manager,
 Service Provider Products Business,
 Flextronics Software Systems
 (Formerly Hughes Software Systems)
 No. 18, Outer Ring Road, Panathur Post,
 Bangalore -560 087,  India           =    
 Phone  : +91-80-4106 7138  Fax     : = +91-80-4126 6501  
 visit us at http://www.flextronicssoftware.com
<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->

"zhangwei" <zhangwei@sict.ac.cn> =

06/16/2006 01:11 PM

To

Sumit Dhar/BLR/HSS@HSS =

cc

 

Subject

INVITE request after 302 response =

  =

 

 




Hi,
 
   In SIP, 302 Moved Temporarily can be used by User Agent to = set call forwarding. When the caller received 302, it should re-create a new = INVITE request to forward call to a given contact.
 
   My question is how Proxy Server detect whether INVITE is = created after having received 302 response. The Proxy Server is transaction = stateful. What's the difference between INVITE after 302 and the normal INVITE ? =
 
 
Regards
Zhang Wei


***********************  FSS- Confidential   = ***********************

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

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



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


The information contained in this electronic message and any = attachments to this message are intended for the exclusive use of the addressee(s) = and may contain proprietary, confidential or privileged information. If you = are not the intended recipient, you should not disseminate, distribute or copy = this e-mail. Please notify the sender immediately and destroy all copies of = this message and any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient = should check this email and any attachments for the presence of viruses. The = company accepts no liability for any damage caused by any virus transmitted by = this email.

www.wipro.com



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


The information contained in this electronic message and any = attachments to this message are intended for the exclusive use of the addressee(s) = and may contain proprietary, confidential or privileged information. If you = are not the intended recipient, you should not disseminate, distribute or copy = this e-mail. Please notify the sender immediately and destroy all copies of = this message and any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient = should check this email and any attachments for the presence of viruses. The = company accepts no liability for any damage caused by any virus transmitted by = this email.

www.wipro.com



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

------=_NextPart_000_0056_01C69455.863C5630-- --===============0764590751== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0764590751==-- From sip-bounces@ietf.org Wed Jun 21 07:25:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft0oP-0002gl-Pv; Wed, 21 Jun 2006 07:23:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft0oO-0002gg-QZ for sip@ietf.org; Wed, 21 Jun 2006 07:23:56 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft0oN-0008I5-IG for sip@ietf.org; Wed, 21 Jun 2006 07:23:56 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k5LBNs4q024779 for ; Wed, 21 Jun 2006 06:23:54 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 21 Jun 2006 12:23:53 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C29090C@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'sip@ietf.org'" Date: Wed, 21 Jun 2006 12:23:47 +0100 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: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Sip] Mailing list usage X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Your two WG chairs have the boring task of wading through the rubbish that gets rejected by the mailing list. Sometimes pearls do end up here, as all posts by non-members go here until they are validated, and messages that are too long also go here. We do try and identify these and forward them on, but we are fallible and things do get lost. Here are some pointers to try and avoid this happening: i) Try and post from a list member address. There is nothing that stops multiple addresses being members of the mailing list, and there are various mailing list control options you can set yourself, or if you are really stuck, that we can set for you. ii) Use of something other than text, or use of attachments, frequently end up being too long. Remember that on IETF lists, only text is allowed, and attachments should not be sent. This also applies to those lovely vcard footers people insist on attaching, and to people that think RTF or HTTP messages are wonderful - they still more than double the length of the message. iii) If replying to a long thread, please feel free to cut off all the irrelevant detritus from two months back that have no impact on what you are replying to. iv) Please remove or truncate the list of addresses other than the mailing list address if your reply is no longer relevant to those people. Two many addresses will cause the list to bounce the message. And further - keep the comments relevant to SIP protocol development. There are other lists that may be more appropriate, in particular: sipping@ietf.org for issues that belong the the SIPPING group simple@ietf.org for issues on drafts that belong to presence and the SIMPLE group mmusic@ietf.org for issues on SDP and the MMUSIC group sip-implementors@cs.columbia.edu for implementation issues. If in doubt as to which list, read the charter pages!!!!!!!!!!!!! (which are all at http://www.ietf.org/html.charters/wg-dir.html) regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 21 08:02:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft1OI-0002Oy-Lo; Wed, 21 Jun 2006 08:01:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft1OH-0002Ot-4g for sip@ietf.org; Wed, 21 Jun 2006 08:01:01 -0400 Received: from agminet01.oracle.com ([141.146.126.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft1OF-0005SA-PI for sip@ietf.org; Wed, 21 Jun 2006 08:01:01 -0400 Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k5LC0wRM026925; Wed, 21 Jun 2006 07:00:58 -0500 Received: from se.oracle.com (dhcp-22-3-185.se.oracle.com [144.22.3.185]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k5LC0uBa011699 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 21 Jun 2006 06:00:57 -0600 From: =?iso-8859-1?B?IkphbiBS9mdkZSI=?= To: "Cullen Jennings" Subject: RE: [Sip] outbound i-d update? Date: Wed, 21 Jun 2006 14:01:08 +0200 Organization: Oracle Message-ID: <20060621140108758.00000000656@jrogde-se> In-Reply-To: X-Mailer: Oracle Connector for Outlook 10.1.2.0.0 71006 (11.0.8010) X-Accept-Language: sv-se, sv MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "jan.rogde@oracle.com" List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Ok, that was the answer I expected although I don't agree... :-) Anyway, I would appreciate a comment from someone regarding the failover sc= enario which was the main purpose of my previous mail. Basically, the list = seems to agree on this (your last comment to Juha): " * UA need to implement support for multliple flows - at least two and shoul= d do four can do more * Operator of a domain can choose how many to use " My point is just that I do not see how this solves the failover scenario in= chapter 8. However, combined with GRUU it would. Am I right or am I wrong?= I include my previous mail below for easy access, Jappe Previous mail: "A couple of questions that I think are related to this discussion. * Assume the client wants reliability so it is prepared to set up multiple = connections. * Study the scenario in chapter 8 "Example Message Flow". * Since the terms Backup and Primary are obsolete now (right?) assume that = there are multiple proxy/registrars hosting the domain. * As in the example, the proxy that was in involved in the call setup goes = down. * The BYE arrives at another proxy server, because the Record-Route just st= ated the domain name, which in the example "happens" to have a connection t= o the callee. So, for this to work in the general case I guess that the client really nee= ds to have a connection to ALL proxy servers hosting the domain, it is not = enough to just have "multiple flows"? = Or maybe outbound alone should not solve this case? If combined with GRUU i= t would be enough to have a few connections open to "make sure" that the re= quest will reach the recipient. And finally moving slightly off topic, wouldn't it be easier for everyone i= nvolved if outbound and gruu was combined? That combination solves a proble= m..." -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] = Sent: den 20 juni 2006 20:45 To: jan.rogde@oracle.com Cc: IETF SIP List Subject: Re: [Sip] outbound i-d update? On Jun 16, 2006, at 2:20 AM, Jan R=F6gde wrote: > wouldn't it be easier for everyone involved if outbound and gruu was = > combined? I feel very strongly this would complicate things. They can be seperated an= d I think we should keep them this way. These have all take too long and co= mbining them would only slow things donw. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implement= ors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for n= ew developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 21 08:29:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft1oA-0002o1-5m; Wed, 21 Jun 2006 08:27:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft1o8-0002jn-3H for sip@ietf.org; Wed, 21 Jun 2006 08:27:44 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft1o6-0006Qc-I1 for sip@ietf.org; Wed, 21 Jun 2006 08:27:44 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 1E22B140018; Wed, 21 Jun 2006 15:27:38 +0300 (EEST) Received: from rautu (unknown [62.78.107.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 3A14313FEBE; Wed, 21 Jun 2006 15:27:26 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 65F62F03C1; Wed, 21 Jun 2006 15:27:31 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <17561.15155.345910.342981@rautu.tutpro.com> Date: Wed, 21 Jun 2006 15:27:31 +0300 From: Juha Heinanen To: "jan.rogde@oracle.com" Subject: RE: [Sip] outbound i-d update? In-Reply-To: <20060621140108758.00000000656@jrogde-se> References: <20060621140108758.00000000656@jrogde-se> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, TO_ADDRESS_EQ_REAL autolearn=no version=3.0.3 X-Spam-Score: 0.5 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Cullen Jennings , IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org "Jan R=F6gde" writes: > * The BYE arrives at another proxy server, because the Record-Route > * just stated the domain name, which in the example "happens" to hav= e > * a connection to the callee. my proxys don't use domain names in rr headers that they insert. -- 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 Jun 21 08:58:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2GK-0004cG-71; Wed, 21 Jun 2006 08:56:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2GI-0004Zk-KV for sip@ietf.org; Wed, 21 Jun 2006 08:56:50 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft2GH-0001HP-BE for sip@ietf.org; Wed, 21 Jun 2006 08:56:50 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k5LCukNP022324; Wed, 21 Jun 2006 07:56:46 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 21 Jun 2006 13:56:43 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C290910@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Cullen Jennings'" , Dean Willis Subject: RE: [Sip] Additional uses of INFO Date: Wed, 21 Jun 2006 13:56:38 +0100 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: cab78e1e39c4b328567edb48482b6a69 Cc: sip@ietf.org, "James M. Polk" , "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The problem I am seeing is what we have at the moment is hiding the issue under the carpet. Because we have no clear statement on whether INFO applications are regulated, or even allowed, and anybody in the past who has made a proposal for the use of INFO has been cast into the abyss, anybody using them just invents it and uses it, with no reference to IETF. By the way RFC 4485 does not provide guidance on how to extend SIP. It tells you how to document an extension once you have invented it. That is why I suggested maybe addressing the issue in RFC 3427. regards Keith > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: 21 June 2006 03:44 > To: Dean Willis > Cc: Jonathan Rosenberg; sip@ietf.org; James M. Polk; Drage, Keith > (Keith) > Subject: Re: [Sip] Additional uses of INFO > > > > On Jun 14, 2006, at 8:53 PM, Dean Willis wrote: > > > Do we have to change HTTP every time somebody uses it to get a new > > type of image file or to build a new type of web application? Let > > me think . . . nope, we don't. > > Clearly some applications fit inside the extensibility model that > HTTP had - others, such as webdav, caldav, atom may not change HTTP > but were some pretty serious extensions - and Don't even ask about > how ETag works consistently across all theses. > > Back to the topics of SIP ... I have not gone and read the various > drafts on this but it seems like we have some recommendation on how > to extend SIP (RFC 4485). Now I'm sure eventually things will > come up > where this is not enough but discussing it in the abstract is pretty > hard. I'd rather not build new extensibility mechanisms until we saw > some things that would use them - I'd be very afraid whatever we > build would not meet the needs of anything if it was done in the > abstract. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 21 09:21:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2cF-0001l2-1l; Wed, 21 Jun 2006 09:19:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2cC-0001ku-Qg for sip@ietf.org; Wed, 21 Jun 2006 09:19:28 -0400 Received: from rgminet01.oracle.com ([148.87.113.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft2cB-0002Lc-6z for sip@ietf.org; Wed, 21 Jun 2006 09:19:28 -0400 Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k5LDJO59025474; Wed, 21 Jun 2006 07:19:24 -0600 Received: from se.oracle.com (dhcp-22-3-185.se.oracle.com [144.22.3.185]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k5LDJMEv009480 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 21 Jun 2006 07:19:24 -0600 From: =?iso-8859-1?B?IkphbiBS9mdkZSI=?= To: "Juha Heinanen" Subject: RE: [Sip] outbound i-d update? Date: Wed, 21 Jun 2006 15:19:34 +0200 Organization: Oracle Message-ID: <20060621151934865.00000000656@jrogde-se> In-Reply-To: <17561.15155.345910.342981@rautu.tutpro.com> X-Mailer: Oracle Connector for Outlook 10.1.2.0.0 71006 (11.0.8010) X-Accept-Language: sv-se, sv MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "jan.rogde@oracle.com" List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > my proxys don't use domain names in rr headers that they insert. I'm just trying to follow the example in chapter 8 (with Primary and Backup= changed to multiple proxies for the domain as I believe that was the sugge= stion for the next version). >From the example: " The messages in the call flow are very normal. The only interesting thing to note is that the INVITE in message 6 contains the following Record-Route header field: Record-Route: " /Jappe -----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com] = Sent: den 21 juni 2006 14:28 To: jan.rogde@oracle.com Cc: Cullen Jennings; IETF SIP List Subject: RE: [Sip] outbound i-d update? "Jan R=F6gde" writes: > * The BYE arrives at another proxy server, because the Record-Route > *= just stated the domain name, which in the example "happens" to have > * a= connection to the callee. my proxys don't use domain names in rr headers that they insert. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implement= ors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for n= ew developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 21 09:28:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2jd-0007Do-6v; Wed, 21 Jun 2006 09:27:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2jb-0007DX-Mz for sip@ietf.org; Wed, 21 Jun 2006 09:27:07 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft2ja-0002hd-D0 for sip@ietf.org; Wed, 21 Jun 2006 09:27:07 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 21 Jun 2006 06:27:07 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,162,1149490800"; d="scan'208"; a="30130586:sNHT23249624" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5LDR5no021806; Wed, 21 Jun 2006 09:27:05 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Jun 2006 09:27:05 -0400 Received: from [192.168.1.101] ([10.86.243.91]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Jun 2006 09:27:05 -0400 Message-ID: <44994928.4050501@cisco.com> Date: Wed, 21 Jun 2006 09:27:04 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" Subject: Re: [Sip] Additional uses of INFO References: <475FF955A05DD411980D00508B6D5FB00C290910@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C290910@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jun 2006 13:27:05.0370 (UTC) FILETIME=[63518FA0:01C69536] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: 'Cullen Jennings' , sip@ietf.org, "James M. Polk" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm all for making a clear statement, and indeed this is why I wrote the I-D on INFO harmful. But from the brief discussion so far we obviously have a diversity of opinion on the topic. I guess the question then is whether we want to endeavor to make a statement on this? I.e., should we add a charter item whose objective is to document the appropriate and inappropriate usages of INFO? I think Cullen is suggesting that its hard to do this in absence of specific use cases. -Jonathan R. Drage, Keith (Keith) wrote: > The problem I am seeing is what we have at the moment is hiding the issue under the carpet. > > Because we have no clear statement on whether INFO applications are regulated, or even allowed, and anybody in the past who has made a proposal for the use of INFO has been cast into the abyss, anybody using them just invents it and uses it, with no reference to IETF. > > By the way RFC 4485 does not provide guidance on how to extend SIP. It tells you how to document an extension once you have invented it. > > That is why I suggested maybe addressing the issue in RFC 3427. > > regards > > Keith > > > > >>-----Original Message----- >>From: Cullen Jennings [mailto:fluffy@cisco.com] >>Sent: 21 June 2006 03:44 >>To: Dean Willis >>Cc: Jonathan Rosenberg; sip@ietf.org; James M. Polk; Drage, Keith >>(Keith) >>Subject: Re: [Sip] Additional uses of INFO >> >> >> >>On Jun 14, 2006, at 8:53 PM, Dean Willis wrote: >> >> >>>Do we have to change HTTP every time somebody uses it to get a new >>>type of image file or to build a new type of web application? Let >>>me think . . . nope, we don't. >> >>Clearly some applications fit inside the extensibility model that >>HTTP had - others, such as webdav, caldav, atom may not change HTTP >>but were some pretty serious extensions - and Don't even ask about >>how ETag works consistently across all theses. >> >>Back to the topics of SIP ... I have not gone and read the various >>drafts on this but it seems like we have some recommendation on how >>to extend SIP (RFC 4485). Now I'm sure eventually things will >>come up >>where this is not enough but discussing it in the abstract is pretty >>hard. I'd rather not build new extensibility mechanisms until we saw >>some things that would use them - I'd be very afraid whatever we >>build would not meet the needs of anything if it was done in the >>abstract. >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 21 09:30:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2kn-0007hy-Se; Wed, 21 Jun 2006 09:28:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2kl-0007hp-H4 for sip@ietf.org; Wed, 21 Jun 2006 09:28:19 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft2kl-0002rF-2a for sip@ietf.org; Wed, 21 Jun 2006 09:28:19 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k5LDSHQA022052; Wed, 21 Jun 2006 08:28:18 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 21 Jun 2006 14:28:16 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C290912@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Fredrik Thulin'" , sip@ietf.org Subject: RE: [Sip] Comments on draft-ietf-sip-identity-06 Date: Wed, 21 Jun 2006 14:28:05 +0100 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: 6a45e05c1e4343200aa6b327df2c43fc Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (as WG chair) This document is in AUTH48, i.e. it has been approved by the IESG, edited by the RFC editor, and had an RFC number assigned, and is just waiting the editor's to validate that this really is the document that the WG finished with, before it hits the published RFC directory. While we can ask for the document to be withdrawn from publication, this is exceptional, and we will need to persuade the IESG that something really is wrong with the document. Please concentrate on identifying any such issues and the justification (VERY VERY QUICKLY). The status of all documents can be discovered using https://datatracker.ietf.org/public/pidtracker.cgi regards Keith > -----Original Message----- > From: Fredrik Thulin [mailto:ft@it.su.se] > Sent: 21 June 2006 11:30 > To: sip@ietf.org > Subject: [Sip] Comments on draft-ietf-sip-identity-06 > > > Hi > > I've read the sip-identity draft, and have a number of > comments/questions (in the order the text appear in the document) : > > >4. Overview of Operations > >... > >and thus can validates that the domain indicated > > nit: should be "can validate" > > >5. Authentication Service Behavior > >... > > Note that if that proxy > > server is maintaining a TLS connection with the client over which > > the client had previously authenticated itself using Digest > > authentication, the identity value obtained from that previous > > authentication step can be reused without an additional Digest > > challenge. > > How can the authentication service know for sure that a TLS > connection > was initiated by the client, and not an intermediate SIP ALG in front > of a wifi hotspot for example (assuming that the client does not > present a client certificate)? The SIP ALG might be hiding the inside > topology so that there is only a single Via header present. > > I realize that this is non-normative text, but I think it is > bad advice > security-wise unless it is said explicitly that it only > applies if the > client has a SSL client certificate. > > > If the authentication service is instantiated by a SIP > user agent, > > a user agent can be said to authenticate its user on the grounds > > that the user can provision the user agent with the > private key of > > the domain, or preferably by providing a password that unlocks > > said private key > > I'm sure this is not what is intended, but this almost sound > as if you > think it is perfectly normal to make the private key > available publicly > as long as it is protected by a password. That might be true if the > password is _stronger_ than the certificate, but passwords typically > aren't. I propose that you remove the last part (", or > preferably ..."). > > > Finally, the authentication service MUST forward the message > > normally. > > I don't think you need RFC2119 language to describe that > someone must do > what they normally would. > > >6. Verifier Behavior > >... > > Once the certificate is acquired, it MUST be > > validated following the procedures in RFC3280 [9]. If the > > certificate cannot be validated (it is self-signed and > untrusted, or > > signed by an untrusted or unknown certificate authority, > expired, or > > revoked), the verifier MUST send a 437 'Unsupported Certificate' > > response. > > I understand that your intentions are good, but I'm afraid that this > part will make deployment on the open internet close to impossible > until there is a global PKI root (will not happen), or the number of > bridge CA's make close to 100% of all certificates verifiable. > > For example, Swedish universitys can join the SwUPKI PKI, and > those of > us that have typically only use certificates issued by sub-CA's to > SwUPKI. I won't be deploying sip-identity if it makes the > chances of my > users calls being accepted by any third party on the Internet > fail, if > the alternative is to NOT implement it, and have the calls succeed > although without identity assertions. > > Note that there are several reasons why small-scale PKIs are common, > most of them have nothing to do with economy. There is a trend towards > bridging PKIs which eventually will bring several local community PKIs > into a loosly connected network of trust but this is a gradual process > which will take several years and one which will never be entierly > complete. > > Since, as you say in the draft, a man-in-the-middle attacker can just > strip the sip-dentity related headers from requests, I really > think it > is reasonable that the text above opens up for a identity validator > that receives something signed by an unknown party _removes_ the > identity related headers, and forwards the request as if > there were no > identity headers if local policy says that this is what > should be done. > > Text could be ", the verifier SHOULD send a 437 'Unsupported > Certificate' response. The verifier MAY forward the request as if no > Identity headers were present, if local policy permits, but in this > case it MUST remove the Identity and Identity-Info headers from the > request". > > >9. Header Syntax > >... > >the first letter of each week and month MUST be capitalized > > nit: should be weekday I believe > > >10.2. Identity for a Request with no MIME body or Contact > >... > > When the authentication service receives the BYE, it authenticates > > Bob by sending a 407 response. > > Can a BYE really be challenged? RFC3261 15.1.1 (UAC Behavior) > says a UA > can consider the session terminated as soon as the BYE is passed to > it's transaction layer. In my experience, user agents aren't trying > very hard to clean up network state for sessions they themselves > consider terminated, although I agree they should. This issue was > discussed for example in this thread on sip-implementors : > > http://www1.ietf.org/mail-archive/web/sip/current/msg11118.html > > I'm not sure what to do from the sip-identity perspective. My > personal > preference would be to push for making UAs actually handle challenges > to BYE, but as Paul Kyzivat said in the message linked above, that > ain't going to happen if the credentials have expired and the > user has > walked away from the terminal. > > If some kind of change to the draft is made, then the update > of Table 2 > of RFC 3261 in section 9 of the draft might also need updating. > > >13.1. Handling of digest-string Elements > >... > > Implementations MUST also record Call-IDs received in > > valid requests containing an Identity header, and MUST > remember those > > Call-IDs for at least the duration of a single Date interval (i.e. > > commonly 3600 seconds). Because a SIP-compliant UA never generates > > the same Call-ID twice, verifiers can use the Call-ID to recognize > > cut-and-paste attacks; the Call-ID serves as a nonce. > > This seem problematic > > 1) This applies to _all_ the verifiers in a domain. If the > verification > is done by a domains SIP servers (not the callee's user agent) then > they will have to use a distributed database or a single point of > failure database to remember the Call-Ids seen by _any_ of the > verifiers. > > 2) If the verification is done by the callee's end user agents, I > beleive it would be possible for an attacker to capture a > request (say > a MESSAGE) sent from sip:bob@biloxi to sip:alice@atlanta, and > then send > an identical MESSAGE with From: sip:bob@biloxi, To: sip:alice@atlanta > but Request-URI sip:carol@atlanta. > > I'm not sure there will ever be a value for any attacker in > doing this, > but it seems possible since Alice and Carol's user agents are very > unlikely to share information about previously seen Call-Ids. Even if > it seems to be a meaningless attack, it is still an attack, or have I > missed something making this impossible? > > 3) This IS a problem if the Call-Ids generated by a UA is > predictable, > although unique. I beleive RFC3261 doesn't say that Call-Ids must not > be predictable, even though it says they must be unique. For example, > say that Alice has a UA that produces sequential Call-Ids with the IP > address as 'what makes these unique'. Alice calls me, so I > get her UAs > current Call-Id. She tells me that she is going to call > sip:someone@example.org right after our call. I want to prevent her > from doing that. During our call, I send requests to example.org with > the Call-Id's I predict Alices UA will use. Alices call to > sip:someone@example.org will get rejected > > Also, what makes subsequent requests in the same dialog as > the first one > not get rejected? They will have the same Call-Id. > > >13.2. Display Names and Identity > >... > >SIP accounts with arbitrarily display-names. > > nit: I'm not a native english speaker, but I believe it should be > "arbitrary". > > >13.4. Domain Names and Subordination > >... > > su.se has about ~120 subdomains for different parts of the > organization. > Many of these run their own web servers and so on, some with SSL > certificates for the domain name. It is not an appealing idea to have > all these certificates on our SIP identity providing servers. There > have been a couple of different proposals of how to create > certificates > for specific services of a domain. I think this draft should point at > draft-ietf-pkix-srvsan as how this should be done, as this is the > sollution I believe have gained most acceptance, but I might be > wrong... > > /Fredrik > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 21 09:30:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2kw-0007r8-QF; Wed, 21 Jun 2006 09:28:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2ku-0007nm-Rh for sip@ietf.org; Wed, 21 Jun 2006 09:28:28 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft2kt-0002sb-0Q for sip@ietf.org; Wed, 21 Jun 2006 09:28:28 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 85020140026; Wed, 21 Jun 2006 16:28:20 +0300 (EEST) Received: from rautu (unknown [62.78.107.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id F0CB213F918; Wed, 21 Jun 2006 16:28:06 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 2D324F03C1; Wed, 21 Jun 2006 16:28:04 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <17561.18787.847409.996689@rautu.tutpro.com> Date: Wed, 21 Jun 2006 16:28:03 +0300 From: Juha Heinanen To: "jan.rogde@oracle.com" Subject: RE: [Sip] outbound i-d update? In-Reply-To: <20060621151934865.00000000656@jrogde-se> References: <17561.15155.345910.342981@rautu.tutpro.com> <20060621151934865.00000000656@jrogde-se> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, TO_ADDRESS_EQ_REAL autolearn=no version=3.0.3 X-Spam-Score: 0.5 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org "Jan R=F6gde" writes: > I'm just trying to follow the example in chapter 8 (with Primary and= > Backup changed to multiple proxies for the domain as I believe that > was the suggestion for the next version). perhaps the example has a problem in it. it is not a good idea to use domain names in rr headers if you want that in-dialog requests hit the same proxy as initial one. -- 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 Jun 21 09:45:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2zr-000877-OA; Wed, 21 Jun 2006 09:43:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2zp-00086d-My for sip@ietf.org; Wed, 21 Jun 2006 09:43:53 -0400 Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft2zo-0004kp-8o for sip@ietf.org; Wed, 21 Jun 2006 09:43:53 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id 6A5E2742C1; Wed, 21 Jun 2006 15:43:51 +0200 (CEST) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 23930-01-24; Wed, 21 Jun 2006 15:43:50 +0200 (CEST) Received: from dhcp-wavelan-vo-57.publik.su.se (dhcp-wavelan-vo-57.publik.su.se [193.11.30.57]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id E4866741B9; Wed, 21 Jun 2006 15:43:50 +0200 (CEST) From: Fredrik Thulin To: "Drage, Keith (Keith)" Subject: Re: [Sip] Comments on draft-ietf-sip-identity-06 Date: Wed, 21 Jun 2006 15:43:47 +0200 User-Agent: KMail/1.9.1 References: <475FF955A05DD411980D00508B6D5FB00C290912@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C290912@en0033exch001u.uk.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606211543.47771.ft@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.635 tagged_above=-99 required=7 tests=[AWL=0.030, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Wednesday 21 June 2006 15:28, Drage, Keith (Keith) wrote: > (as WG chair) > > This document is in AUTH48, i.e. it has been approved by the IESG, > edited by the RFC editor, and had an RFC number assigned, and is just > waiting the editor's to validate that this really is the document > that the WG finished with, before it hits the published RFC > directory. > > While we can ask for the document to be withdrawn from publication, > this is exceptional, and we will need to persuade the IESG that > something really is wrong with the document. Please concentrate on > identifying any such issues and the justification (VERY VERY > QUICKLY). > > The status of all documents can be discovered using > https://datatracker.ietf.org/public/pidtracker.cgi Hi Yes, I realized the state of the document after I posted my previous message. I fully understand the problems with rising questions about a document in AUTH48, but hope that people view it as better that potential issues are raised in AUTH48 than not at all. I would think the Call-Id issues are the most important ones. Most of the others are more opinions that I would not have posted if I had realized the state of the document. This question was apparently also raised by Brian Carpenter, or if it was Lakshminath Dondeti (from https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=769&filename=draft-ietf-sip-identity ) : >Normally a hash of the message is stored and compared against for >replay protection in addition to things like integrity protected >timestamps (Date). Does the Call-ID provide the same capability >(uniqueness)? I haven't been able to see this question addressed anywhere, but I might not know where to look. Possibly, the text suggesting that only the first request (for a specific From:) over a TLS session needs to be Digest-authenticated, could also be of the dignity that it needs adressing - since it is "merely" a matter of removing a sentence. I cannot judge whether these issues are serious enough to request withdrawal from the RFC-ed queue, others will have to give their view. /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 21 10:29:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3fr-0003zp-27; Wed, 21 Jun 2006 10:27:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3fW-0003zO-Et for sip@ietf.org; Wed, 21 Jun 2006 10:26:58 -0400 Received: from agminet01.oracle.com ([141.146.126.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft3fV-0008CH-4w for sip@ietf.org; Wed, 21 Jun 2006 10:26:58 -0400 Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k5LEQtEU013803; Wed, 21 Jun 2006 09:26:55 -0500 Received: from se.oracle.com (dhcp-22-3-185.se.oracle.com [144.22.3.185]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k5LEQrfm012084 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 21 Jun 2006 08:26:54 -0600 From: =?iso-8859-1?B?IkphbiBS9mdkZSI=?= To: "Juha Heinanen" Subject: RE: [Sip] outbound i-d update? Date: Wed, 21 Jun 2006 16:27:05 +0200 Organization: Oracle Message-ID: <20060621162705419.00000000656@jrogde-se> In-Reply-To: <17561.18787.847409.996689@rautu.tutpro.com> X-Mailer: Oracle Connector for Outlook 10.1.2.0.0 71006 (11.0.8010) X-Accept-Language: sv-se, sv MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "jan.rogde@oracle.com" List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yes, but the idea is to handle a fail-over scenario. If it record-route with its own IP-address, in-dialog requests will fail if= that proxy goes down. If it record-route with a domain-name as in the exam= ple, in-dialog requests could end up at any working proxy and then UA would= need a connection to ALL the proxies for the domain-name. But on the list = you all seem to agree that a fixed number (min 2 connections) is enough. So again, is outbound intended to solve the reliability problem? If so, the= draft is not clear about this. = /Jappe -----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com] = Sent: den 21 juni 2006 15:28 To: jan.rogde@oracle.com Cc: IETF SIP List Subject: RE: [Sip] outbound i-d update? "Jan R=F6gde" writes: > I'm just trying to follow the example in chapter 8 (with Primary and > = Backup changed to multiple proxies for the domain as I believe that > was = the suggestion for the next version). perhaps the example has a problem in it. it is not a good idea to use doma= in names in rr headers if you want that in-dialog requests hit the same pro= xy as initial one. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implement= ors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for n= ew developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 21 11:05:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4Ex-0001Un-8o; Wed, 21 Jun 2006 11:03:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4Ew-0001Ud-1N for sip@ietf.org; Wed, 21 Jun 2006 11:03:34 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft4Er-0006ip-LB for sip@ietf.org; Wed, 21 Jun 2006 11:03:34 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 5A8E6140018; Wed, 21 Jun 2006 18:03:21 +0300 (EEST) Received: from rautu (unknown [62.78.107.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 9C6BF13F8B0; Wed, 21 Jun 2006 18:03:10 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 78515F03C1; Wed, 21 Jun 2006 18:03:19 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <17561.24503.103276.318354@rautu.tutpro.com> Date: Wed, 21 Jun 2006 18:03:19 +0300 From: Juha Heinanen To: "jan.rogde@oracle.com" Subject: RE: [Sip] outbound i-d update? In-Reply-To: <20060621162705419.00000000656@jrogde-se> References: <17561.18787.847409.996689@rautu.tutpro.com> <20060621162705419.00000000656@jrogde-se> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, TO_ADDRESS_EQ_REAL autolearn=no version=3.0.3 X-Spam-Score: 0.5 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org "Jan R=F6gde" writes: > If it record-route with its own IP-address, in-dialog requests will > fail if that proxy goes down. If it record-route with a domain-name > as in the example, in-dialog requests could end up at any working > proxy and then UA would need a connection to ALL the proxies for the= > domain-name. But on the list you all seem to agree that a fixed > number (min 2 connections) is enough. UA can try the two to which it has established a flow, but if both of them fail to respond to BYE, nothing prevents it from trying other proxies in outbound set even if UA does not currently have flow open with them. -- 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 Jun 21 11:23:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4Wa-0000Rj-AH; Wed, 21 Jun 2006 11:21:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4WZ-0000Re-LL for sip@ietf.org; Wed, 21 Jun 2006 11:21:47 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft4WW-00081g-A2 for sip@ietf.org; Wed, 21 Jun 2006 11:21:47 -0400 Received: from [192.168.1.5] (65-65-155-30.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5LFNEaF027247 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 21 Jun 2006 10:23:15 -0500 In-Reply-To: <44994928.4050501@cisco.com> References: <475FF955A05DD411980D00508B6D5FB00C290910@en0033exch001u.uk.lucent.com> <44994928.4050501@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Additional uses of INFO Date: Wed, 21 Jun 2006 10:21:37 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: 'Cullen Jennings' , sip@ietf.org, "Drage, Keith \(Keith\)" , "James M. Polk" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 21, 2006, at 8:27 AM, Jonathan Rosenberg wrote: > I'm all for making a clear statement, and indeed this is why I > wrote the I-D on INFO harmful. But from the brief discussion so far > we obviously have a diversity of opinion on the topic. > > I guess the question then is whether we want to endeavor to make a > statement on this? I.e., should we add a charter item whose > objective is to document the appropriate and inappropriate usages > of INFO? I think Cullen is suggesting that its hard to do this in > absence of specific use cases. Fair question. What is fundamentally different about documenting appropriate/inappropriate uses of INFO from documenting the same aspect of event packages? -- 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 Jun 21 11:28:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4bQ-0001r5-PX; Wed, 21 Jun 2006 11:26:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4bQ-0001r0-1F for sip@ietf.org; Wed, 21 Jun 2006 11:26:48 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft4bO-0008OS-Lu for sip@ietf.org; Wed, 21 Jun 2006 11:26:48 -0400 Received: from [192.168.1.5] (65-65-155-30.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5LFSHdV027277 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 21 Jun 2006 10:28:19 -0500 In-Reply-To: <200606211543.47771.ft@it.su.se> References: <475FF955A05DD411980D00508B6D5FB00C290912@en0033exch001u.uk.lucent.com> <200606211543.47771.ft@it.su.se> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <677393C5-0C4E-4AD4-8F51-4473F433ABD3@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Comments on draft-ietf-sip-identity-06 Date: Wed, 21 Jun 2006 10:26:40 -0500 To: Fredrik Thulin X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: sip@ietf.org, "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > Yes, I realized the state of the document after I posted my previous > message. I fully understand the problems with rising questions about a > document in AUTH48, but hope that people view it as better that > potential issues are raised in AUTH48 than not at all. > > I would think the Call-Id issues are the most important ones. Most of > the others are more opinions that I would not have posted if I had > realized the state of the document. This question was apparently also > raised by Brian Carpenter, or if it was Lakshminath Dondeti (from > https://datatracker.ietf.org/public/pidtracker.cgi? > command=print_ballot&ballot_id=769&filename=draft-ietf-sip-identity > ) : Call-ID and typos like extra "s" can easily be fixed in Auth48. More substantive changes can, if absolutely necessary, be made by explicit approval of the supervising AD, who may have to refer some questions to the larger IESG. Restructuring your note to concisely focus on only those things that can reasonably be fixed in Auth 48 would probably be useful to the editior, who is currently performing the Auth48 editing task. -- 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 Jun 21 12:22:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5RU-0004aS-As; Wed, 21 Jun 2006 12:20:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5RT-0004aN-AP for sip@ietf.org; Wed, 21 Jun 2006 12:20:35 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft5RR-0004qD-VT for sip@ietf.org; Wed, 21 Jun 2006 12:20:35 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-6.cisco.com with ESMTP; 21 Jun 2006 09:20:33 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k5LGKWx5030306; Wed, 21 Jun 2006 09:20:32 -0700 Received: from [192.168.1.2] (sjc-vpn7-752.cisco.com [10.21.146.240]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5LGKVcL024248; Wed, 21 Jun 2006 09:20:31 -0700 (PDT) In-Reply-To: <20060621140108758.00000000656@jrogde-se> References: <20060621140108758.00000000656@jrogde-se> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <004B7A7C-0A3E-4B57-A22E-453FC8D6D85A@cisco.com> Content-Transfer-Encoding: quoted-printable From: Cullen Jennings Subject: Re: [Sip] outbound i-d update? Date: Wed, 21 Jun 2006 09:20:28 -0700 To: "jan.rogde@oracle.com" X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=3766; t=1150906832; x=1151770832; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20outbound=20i-d=20update?; X=v=3Dcisco.com=3B=20h=3DrZ5gmqNyhAntk/N2pG2BgeEZQGE=3D; b=Hkj45/JW3JHNu3eiHUaaYUrNRF3X3BjhGzKeY58VktNlvBNekkNwIt7Lmri+zxIo285MQs7X Uou69JbyBfs5sV8oMaVaLSTpmk11jcZwnKcJAtzbGL91FYorG3FJb/BO; Authentication-Results: sj-dkim-6.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The proxy farm needs a way of providing high reliability - that would =20= mean getting the BYE that arrived at one server to a server that =20 actually had a connection to the UA. There have been many proposals =20 on how to do this - one of them was have the UA connect to every host =20= in the farm. Others have involved moving TCP connections from one =20 server to another. Others have limited the machines that might act as =20= a backup for the failed machine and making sure it has a connection. =20 Others have involved internal routing the BYE around the proxy farm. =20 The point is, there are many ways and the outbound draft (and the =20 GRUU draft) do not pretend to tell someone how to build a high =20 reliably proxy farm. However, it does seem to work with all the =20 various proposal people have come up with. On Jun 21, 2006, at 5:01 AM, Jan R=F6gde wrote: > > Ok, that was the answer I expected although I don't agree... :-) > > Anyway, I would appreciate a comment from someone regarding the =20 > failover scenario which was the main purpose of my previous mail. =20 > Basically, the list seems to agree on this (your last comment to =20 > Juha): > " > * UA need to implement support for multliple flows - at least two =20 > and should do four can do more > * Operator of a domain can choose how many to use > " > > My point is just that I do not see how this solves the failover =20 > scenario in chapter 8. However, combined with GRUU it would. Am I =20 > right or am I wrong? > > I include my previous mail below for easy access, > Jappe > > Previous mail: > "A couple of questions that I think are related to this discussion. > > * Assume the client wants reliability so it is prepared to set up =20 > multiple connections. > * Study the scenario in chapter 8 "Example Message Flow". > * Since the terms Backup and Primary are obsolete now (right?) =20 > assume that there are multiple proxy/registrars hosting the domain. > * As in the example, the proxy that was in involved in the call =20 > setup goes down. > * The BYE arrives at another proxy server, because the Record-Route =20= > just stated the domain name, which in the example "happens" to have =20= > a connection to the callee. > > So, for this to work in the general case I guess that the client =20 > really needs to have a connection to ALL proxy servers hosting the =20 > domain, it is not enough to just have "multiple flows"? > > Or maybe outbound alone should not solve this case? If combined =20 > with GRUU it would be enough to have a few connections open to =20 > "make sure" that the request will reach the recipient. > > And finally moving slightly off topic, wouldn't it be easier for =20 > everyone involved if outbound and gruu was combined? That =20 > combination solves a problem..." > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: den 20 juni 2006 20:45 > To: jan.rogde@oracle.com > Cc: IETF SIP List > Subject: Re: [Sip] outbound i-d update? > > > On Jun 16, 2006, at 2:20 AM, Jan R=F6gde wrote: > >> wouldn't it be easier for everyone involved if outbound and gruu was >> combined? > > I feel very strongly this would complicate things. They can be =20 > seperated and I think we should keep them this way. These have all =20 > take too long and combining them would only slow things donw. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use sip-=20 > implementors@cs.columbia.edu for questions on current sip Use =20 > sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 21 13:00:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft61u-00034Z-B2; Wed, 21 Jun 2006 12:58:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft61t-00034U-5q for sip@ietf.org; Wed, 21 Jun 2006 12:58:13 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft61q-0002MX-80 for sip@ietf.org; Wed, 21 Jun 2006 12:58:13 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E116D4F0036; Wed, 21 Jun 2006 18:57:45 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 18:57:45 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 18:57:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound: keep-alive, outbound and 3489bis Date: Wed, 21 Jun 2006 18:57:44 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F1165@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: keep-alive, outbound and 3489bis Thread-Index: AcaUxH78o1L8GTO6R1ynXp/ysgni3wABQCVgABhGauA= From: "Christer Holmberg \(JO/LMF\)" To: "Francois Audet" , "Jonathan Rosenberg" , "Cullen Jennings" X-OriginalArrivalTime: 21 Jun 2006 16:57:45.0085 (UTC) FILETIME=[D12D02D0:01C69553] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, There must also be a way for the edge proxy to indicate to the client = that it supports the STUN keep-alive usage. Because, if the other = outbound features aren't supported/requested, there will be no = "outbound" in the Supported header of the registration response. Regards, Christer =20 -----Original Message----- From: Francois Audet [mailto:audet@nortel.com]=20 Sent: 21. kes=E4kuuta 2006 3:33 To: Jonathan Rosenberg; Christer Holmberg (JO/LMF); Cullen Jennings Cc: sip@ietf.org Subject: RE: [Sip] Outbound: keep-alive, outbound and 3489bis I agree. It would be nice if in Outbound, there was some sort of indication on = what is required to be there if only the keepalive is done. Maybe a little paragraph on this in the section on keep-alive in sip-outbound-04 would help. I think it would really help to have some guidance on this = to answer the question that Christer has. (Besides the use that Jonathan points to, it could be useful in certain = environments to phase out PINGs, short-lived registration, CRLFs and = other legacy mechanisms. I can see an option on a phone to use = STUN-in-SIP for keep-alive as implementable today). > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Tuesday, June 20, 2006 16:51 > To: Christer Holmberg (JO/LMF) > Cc: sip@ietf.org > Subject: Re: [Sip] Outbound: keep-alive, outbound and 3489bis >=20 >=20 > I think we should allow the STUN keepalives without the rest of the=20 > stuff. Its a handy tool for inter-server keepalives in cases where=20 > there are no NAT or firewalls. >=20 > -Jonathan R. >=20 > Christer Holmberg (JO/LMF) wrote: >=20 > >=20 > > Hi, > >=20 > > A few issues on the outbound draft: > >=20 > > Q1: > > ----- > >=20 > > The outbound draft currently defines the usage of STUN for NAT=20 > > keep-alive. > >=20 > > However, since NAT keep-alive has been added as a STUN usage to the=20 > > STUN specification (3489bis) itself, I guess the outbound draft > only needs to > > refer to 3489bis and "apply" it to SIP, e.g. by defining > the keepalive > > URI parameter. > >=20 > >=20 > > Q2: > > ----- > >=20 > > If a client supports STUN for keep-alive, but not the other > parts of > > the > > outbound extension (instance-id, reg-id etc), it will not > insert the > > instance-id etc, but it will still include the 'keepalive'=20 > URI parameter. > >=20 > > Now, the outbound draft does not FORBID this, as far as I > can see, but > > I > > wonder if we more clearly should point that out in the draft. > >=20 > > OR, the SIP usage of STUN keep-alive should be described in > a separate > > draft, now when the usage itself is part of 3489bis. > >=20 > > OR, if I only use STUN for keep-alive, without the rest of the=20 > > outbound stuff, should I not use the 'keepalive' parameter in the > first place? > >=20 > >=20 > >=20 > > Regards, > >=20 > > Christer > >=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=20 > current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sipping@ietf.org for new developments on the=20 > application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 21 13:14:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6FT-0007C3-FA; Wed, 21 Jun 2006 13:12:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6FS-0007By-JZ for sip@ietf.org; Wed, 21 Jun 2006 13:12:14 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft6FR-00031u-B7 for sip@ietf.org; Wed, 21 Jun 2006 13:12:14 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 21 Jun 2006 10:12:12 -0700 X-IronPort-AV: i="4.06,162,1149490800"; d="scan'208"; a="298622023:sNHT30358166" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k5LHCCpf002043; Wed, 21 Jun 2006 10:12:12 -0700 Received: from [192.168.1.2] (sjc-vpn7-752.cisco.com [10.21.146.240]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5LHCB9s009902; Wed, 21 Jun 2006 10:12:12 -0700 (PDT) In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F1165@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB594017F1165@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <95F811A2-E35C-4078-B78D-48D950CBEBA0@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Outbound: keep-alive, outbound and 3489bis Date: Wed, 21 Jun 2006 10:12:09 -0700 To: Christer Holmberg ((JO/LMF)) X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=435; t=1150909932; x=1151773932; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Outbound=3A=20keep-alive,=20outbound=20and=203489bis; X=v=3Dcisco.com=3B=20h=3DT4jXfBhLh9Tdo4opUqHplGAd4WM=3D; b=JzzwtLldPHd/5zithvmZ6sqs4JNzda3g5bkmx8j5qQMZ0QzOqrBL86a35IPnMSK6Qe2kve5c qh9dj6jXN8lsZVtKYYCEB5pm9ga08gw2uSltz6hlkA9afy096JGhxc/8; Authentication-Results: sj-dkim-4.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: sip@ietf.org, Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 21, 2006, at 9:57 AM, Christer Holmberg ((JO/LMF)) wrote: > There must also be a way for the edge proxy to indicate to the > client that it supports the STUN keep-alive usage. Because, if the > other outbound features aren't supported/requested, there will be > no "outbound" in the Supported header of the registration response. this is done with the keepalive=stun parameter in the URI for the edge proxy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 21 13:17:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6IZ-0007pT-O5; Wed, 21 Jun 2006 13:15:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6IX-0007p7-Ux for sip@ietf.org; Wed, 21 Jun 2006 13:15:25 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft6IW-0003Hv-D4 for sip@ietf.org; Wed, 21 Jun 2006 13:15:25 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CC1C4A8F; Wed, 21 Jun 2006 19:15:23 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 19:15:23 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 19:15:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound: keep-alive, outbound and 3489bis Date: Wed, 21 Jun 2006 19:15:22 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F1168@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: keep-alive, outbound and 3489bis Thread-Index: AcaVVdeVYt5EOcDKS0CCNMjtOePdjQAACPNw From: "Christer Holmberg \(JO/LMF\)" To: "Cullen Jennings" X-OriginalArrivalTime: 21 Jun 2006 17:15:23.0481 (UTC) FILETIME=[48076C90:01C69556] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: sip@ietf.org, Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >>There must also be a way for the edge proxy to indicate to the client=20 >>that it supports the STUN keep-alive usage. Because, if the other=20 >>outbound features aren't supported/requested, there will be no=20 >>"outbound" in the Supported header of the registration response. >this is done with the keepalive=3Dstun parameter in the URI for the = edge proxy What if the edge proxy - for whatever reason - then doesn't support/isn't able to provide STUN support for NAT keep-alive at a certain point? Should it reject the REGISTER? What does a URI parameter really mean, as far as supported capabilities of the receiver is concerned? Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 21 13:44:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6jD-0002DL-Ge; Wed, 21 Jun 2006 13:42:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6jC-0002DG-Es for sip@ietf.org; Wed, 21 Jun 2006 13:42:58 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft6jB-0006Gg-5K for sip@ietf.org; Wed, 21 Jun 2006 13:42:58 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 21 Jun 2006 10:42:57 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k5LHgueV010247; Wed, 21 Jun 2006 10:42:56 -0700 Received: from [192.168.1.2] (sjc-vpn7-752.cisco.com [10.21.146.240]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5LHgt9s003103; Wed, 21 Jun 2006 10:42:55 -0700 (PDT) In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F1168@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB594017F1168@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <803BC899-53D0-4EF0-A753-FCA285A5546A@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Outbound: keep-alive, outbound and 3489bis Date: Wed, 21 Jun 2006 10:42:52 -0700 To: Christer Holmberg ((JO/LMF)) X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=1374; t=1150911776; x=1151775776; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Outbound=3A=20keep-alive,=20outbound=20and=203489bis; X=v=3Dcisco.com=3B=20h=3DT4jXfBhLh9Tdo4opUqHplGAd4WM=3D; b=lYxalZu2ng5vonA8b1K92YuWijXPuN4pEN/im6bIjl5/SaokAaaoD+gciXzgEAntmudMR/DL +O7C7WbfkxkPD07YTbuju3E7sLyJFcZ9SNr8P41cTEDtjvAq2vIyVa4W; Authentication-Results: sj-dkim-3.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: sip@ietf.org, Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org It's the same way as sigcomp. The URI for the edge proxy comes from somewhere - the UA does not make it up. Wherever it comes from know if it does sigcmpl or stun and includes that in the URI. The UA looks at the URI and knows if it can do sigcomp or stun. On Jun 21, 2006, at 10:15 AM, Christer Holmberg ((JO/LMF)) wrote: > >>> There must also be a way for the edge proxy to indicate to the >>> client >>> that it supports the STUN keep-alive usage. Because, if the other >>> outbound features aren't supported/requested, there will be no >>> "outbound" in the Supported header of the registration response. >> this is done with the keepalive=stun parameter in the URI for the >> edge > proxy > > What if the edge proxy - for whatever reason - then doesn't > support/isn't able to provide STUN support for NAT keep-alive at a > certain point? Should it reject the REGISTER? > > What does a URI parameter really mean, as far as supported > capabilities > of the receiver is concerned? > > Regards, > > Christer > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 21 14:01:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6yu-0004Fy-36; Wed, 21 Jun 2006 13:59:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6ys-0004Ft-27 for sip@ietf.org; Wed, 21 Jun 2006 13:59:10 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft6yq-0008DZ-P1 for sip@ietf.org; Wed, 21 Jun 2006 13:59:10 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k5LHx3o26854; Wed, 21 Jun 2006 13:59:04 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] Outbound: keep-alive, outbound and 3489bis Date: Wed, 21 Jun 2006 12:59:00 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0AC99DB0@zrc2hxm0.corp.nortel.com> In-Reply-To: <95F811A2-E35C-4078-B78D-48D950CBEBA0@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: keep-alive, outbound and 3489bis Thread-Index: AcaVVfDZrHtfNSY8SxOwfTFgHPU7MQABgOXQ From: "Francois Audet" To: "Cullen Jennings" , "Christer Holmberg \(\(JO/LMF\)\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I guess it could also be configured in the phone (STUN-in-SIP =3D=3D = TRUE). But if we want to have the keepalive=3Dtrue in the URI as mandatory, I'm perfectly happy with that. It just means that instead of configuring it seperately, it's inferred from the URI, which is better because it is one less thing to worry about. That's exactly the type of thing that I'd like to see in the paragraph. > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: Wednesday, June 21, 2006 10:12 > To: Christer Holmberg ((JO/LMF)) > Cc: sip@ietf.org; Audet, Francois [SC100:3055:EXCH] > Subject: Re: [Sip] Outbound: keep-alive, outbound and 3489bis >=20 >=20 >=20 > On Jun 21, 2006, at 9:57 AM, Christer Holmberg ((JO/LMF)) wrote: >=20 > > There must also be a way for the edge proxy to indicate to the > > client that it supports the STUN keep-alive usage. Because, if the =20 > > other outbound features aren't supported/requested, there will be =20 > > no "outbound" in the Supported header of the registration response. >=20 > this is done with the keepalive=3Dstun parameter in the URI for the =20 > edge proxy >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sipping@ietf.org for new developments on the=20 > application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 21 14:05:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft73W-0008EH-CE; Wed, 21 Jun 2006 14:03:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft73U-0008E7-UQ for sip@ietf.org; Wed, 21 Jun 2006 14:03:56 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft73T-00007O-KS for sip@ietf.org; Wed, 21 Jun 2006 14:03:56 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 638E96C018; Wed, 21 Jun 2006 14:03:55 -0400 (EDT) Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt From: Scott Lawrence To: Cullen Jennings In-Reply-To: <9B35A371-360F-48CB-AEB9-11377CE896EA@cisco.com> References: <44887921.20302@cisco.com> <1149796932.4721.129.camel@localhost.localdomain> <44898BD0.7000705@cisco.com> <26E13ED4-1582-4CB2-B74E-F5E0985F9810@cisco.com> <1150118729.2822.18.camel@sukothai.pingtel.com> <1150817220.2889.50.camel@sukothai.pingtel.com> <9B35A371-360F-48CB-AEB9-11377CE896EA@cisco.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Wed, 21 Jun 2006 14:03:55 -0400 Message-Id: <1150913035.2893.73.camel@sukothai.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Tue, 2006-06-20 at 23:06 -0700, Cullen Jennings wrote: > On Jun 20, 2006, at 8:27 AM, Scott Lawrence wrote: > > > On Mon, 2006-06-19 at 17:15 -0700, Cullen Jennings wrote: > >> On Jun 12, 2006, at 6:25 AM, Scott Lawrence wrote: > >> > >>> - this introduces new normative behavior for all Servers > >>> > >>> - the new behavior is not controlled or advertised using the > >>> mechanisms > >>> for identifying extensions (Supported/Requires). > >> > >> If both of these are true, I agree with you. But I don't see why this > >> draft would need both of these. > > > > I'm not sure I understand what you mean. It introduces a new SHOULD. > > It does not specify any related feature/option tag. If you think > > either > > of these statements need to be changed, say how and why. > > > >> I see no reason this can not be optional behavior. > > > > I generally prefer to make everything mandatory that is not forbidden. > > Optional behavior is harmful to interoperability and confusing to > > implementors. > > I am suggesting that you say that servers that support this RFC need > to do this and let servers decide if they want to support it or not. > This is comparable to say REFER. You will note that REFER does not > update 3261. A device can decide if it wants to implement this or > not. Perhaps I misunderstood your intent and you are saying that > everything that does 3261 should have to implement this. Yes, that is my intent. A new method does have a defined mechanism for signaling whether or not it is implemented, so it counts as an extension, not an update. > >> Anyways, this is a nit, the serious issues in the > >> draft has to do with the size of the responses. > > > > Do you have some suggestion with respect to that? > > Yes - I believe the magic number we agreed on for UDP was something > close to 1200. You need to say that if any of the hops used UDP, the > response MUST NOT be larger than 1200 octets. You then need to show > some scheme for a making the response smaller than this. In a typical > example with default max hops, I really don't see how this will be > possible. I've be very interested in seeing how large a typical > example that had the full trace in from actually is. I know this is > not very satisfying - I hope some can think of a better way to solve > this but I'm not coming up with one. Well, I didn't cite the number mostly because it's already provided elsewhere and I saw no need to duplicate either the number or the requirement that the response be under that limit. If you can point to where that rule is clearly stated in an existing spec, then I think a reference to it would be good (I hate it when every document repeats rules already stated in some other document - this should be 'updates', not 'obsoletes'). I did describe how the response should be trimmed to get it under whatever limit the implementation wants to get it under. I'm not particularly interested in examples with the default max hops if by that you mean 70. I think that number is way too large, and I doubt there are many deployed proxies that would pass it (all the proxies we used at SIPit to explore the forking amplification attack clipped Max-Forwards to 20, if I recall), and I'd bet there are no real calls that would need it and actually work. Forget whether or not the error response would fit in 1200 bytes - the request wouldn't. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.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 Jun 21 14:57:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft7rt-0007pv-0X; Wed, 21 Jun 2006 14:56:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft7rr-0007ly-VL for sip@ietf.org; Wed, 21 Jun 2006 14:55:59 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft7rp-00065T-1V for sip@ietf.org; Wed, 21 Jun 2006 14:55:59 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 21 Jun 2006 11:55:19 -0700 X-IronPort-AV: i="4.06,163,1149490800"; d="scan'208"; a="298698329:sNHT3960997696" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k5LItKTc024791; Wed, 21 Jun 2006 11:55:20 -0700 Received: from [192.168.1.2] (sjc-vpn7-752.cisco.com [10.21.146.240]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5LItJ9s018192; Wed, 21 Jun 2006 11:55:19 -0700 (PDT) In-Reply-To: <1150913035.2893.73.camel@sukothai.pingtel.com> References: <44887921.20302@cisco.com> <1149796932.4721.129.camel@localhost.localdomain> <44898BD0.7000705@cisco.com> <26E13ED4-1582-4CB2-B74E-F5E0985F9810@cisco.com> <1150118729.2822.18.camel@sukothai.pingtel.com> <1150817220.2889.50.camel@sukothai.pingtel.com> <9B35A371-360F-48CB-AEB9-11377CE896EA@cisco.com> <1150913035.2893.73.camel@sukothai.pingtel.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <75A6226C-55DB-4EB9-8FF8-F38EAF45F752@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt Date: Wed, 21 Jun 2006 11:55:16 -0700 To: Scott Lawrence X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=4331; t=1150916120; x=1151780120; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20I-D=20ACTION=3Adraft-ietf-sip-hop-limit-diagnostics-02.t xt; X=v=3Dcisco.com=3B=20h=3DuuoBsEgzdw6+9X+Y6yGlgJ8d2Es=3D; b=mWrNis27eCyaf4QOreA2Gt7swUYa7zvQv1HznYnQXK/lu/6v5IV0jXE9bblS+sjZYjQuo/Sp 8vtxGGx4C1As1sCbzoC6J5ddfvkduyQLOToJ0R6t9dcpghu6FWM6MESY; Authentication-Results: sj-dkim-2.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline On Jun 21, 2006, at 11:03 AM, Scott Lawrence wrote: > On Tue, 2006-06-20 at 23:06 -0700, Cullen Jennings wrote: >> On Jun 20, 2006, at 8:27 AM, Scott Lawrence wrote: >> >>> On Mon, 2006-06-19 at 17:15 -0700, Cullen Jennings wrote: >>>> On Jun 12, 2006, at 6:25 AM, Scott Lawrence wrote: >>>> >>>>> - this introduces new normative behavior for all Servers >>>>> >>>>> - the new behavior is not controlled or advertised using the >>>>> mechanisms >>>>> for identifying extensions (Supported/Requires). >>>> >>>> If both of these are true, I agree with you. But I don't see why >>>> this >>>> draft would need both of these. >>> >>> I'm not sure I understand what you mean. It introduces a new >>> SHOULD. >>> It does not specify any related feature/option tag. If you think >>> either >>> of these statements need to be changed, say how and why. >>> >>>> I see no reason this can not be optional behavior. >>> >>> I generally prefer to make everything mandatory that is not >>> forbidden. >>> Optional behavior is harmful to interoperability and confusing to >>> implementors. >> >> I am suggesting that you say that servers that support this RFC need >> to do this and let servers decide if they want to support it or not. >> This is comparable to say REFER. You will note that REFER does not >> update 3261. A device can decide if it wants to implement this or >> not. Perhaps I misunderstood your intent and you are saying that >> everything that does 3261 should have to implement this. > > Yes, that is my intent. > > A new method does have a defined mechanism for signaling whether or > not > it is implemented, so it counts as an extension, not an update. > >>>> Anyways, this is a nit, the serious issues in the >>>> draft has to do with the size of the responses. >>> >>> Do you have some suggestion with respect to that? >> >> Yes - I believe the magic number we agreed on for UDP was something >> close to 1200. You need to say that if any of the hops used UDP, the >> response MUST NOT be larger than 1200 octets. You then need to show >> some scheme for a making the response smaller than this. In a typical >> example with default max hops, I really don't see how this will be >> possible. I've be very interested in seeing how large a typical >> example that had the full trace in from actually is. I know this is >> not very satisfying - I hope some can think of a better way to solve >> this but I'm not coming up with one. > > Well, I didn't cite the number mostly because it's already provided > elsewhere and I saw no need to duplicate either the number or the > requirement that the response be under that limit. If you can > point to > where that rule is clearly stated in an existing spec, then I think a > reference to it would be good (I hate it when every document repeats > rules already stated in some other document - this should be > 'updates', > not 'obsoletes'). > I had the number wrong but have a look at section 18.1.1 of RFC 3261. I think it is good to point out to implementers that they need to meet this and how they might do it. I agree we don't want this draft redefining > I did describe how the response should be trimmed to get it under > whatever limit the implementation wants to get it under. > > I'm not particularly interested in examples with the default max > hops if > by that you mean 70. I think that number is way too large, and I > doubt > there are many deployed proxies that would pass it (all the proxies we > used at SIPit to explore the forking amplification attack clipped > Max-Forwards to 20, if I recall), and I'd bet there are no real calls > that would need it and actually work. Forget whether or not the error > response would fit in 1200 bytes - the request wouldn't. Well, if you think the default Max-Frorwards needs to be changed, you likely need to start a thread on that. My experience on deployed systems has certainly not been that it always get's clipped to 20. > > -- > Scott Lawrence tel:+1-781-938-5306;ext=162 or > sip:slawrence@pingtel.com > sipXpbx project coordinator - SIPfoundry http:// > www.sipfoundry.org/sipX > Chief Architect - Pingtel Corp. http://www.pingtel.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 Jun 21 15:06:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft802-0002gh-TJ; Wed, 21 Jun 2006 15:04:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft800-0002gc-UE for sip@ietf.org; Wed, 21 Jun 2006 15:04:24 -0400 Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft7zz-0006Hi-GE for sip@ietf.org; Wed, 21 Jun 2006 15:04:24 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id 6CB8274133; Wed, 21 Jun 2006 21:04:22 +0200 (CEST) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14148-03-43; Wed, 21 Jun 2006 21:04:21 +0200 (CEST) Received: from [192.168.123.15] (c-0cfbe055.1161-1-64736c11.cust.bredbandsbolaget.se [85.224.251.12]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id 7AAC5740BD; Wed, 21 Jun 2006 21:04:17 +0200 (CEST) From: Fredrik Thulin To: sip@ietf.org Subject: Re: [Sip] Comments on draft-ietf-sip-identity-06 Date: Wed, 21 Jun 2006 21:04:06 +0200 User-Agent: KMail/1.9.1 References: <475FF955A05DD411980D00508B6D5FB00C290912@en0033exch001u.uk.lucent.com> <200606211543.47771.ft@it.su.se> <677393C5-0C4E-4AD4-8F51-4473F433ABD3@softarmor.com> In-Reply-To: <677393C5-0C4E-4AD4-8F51-4473F433ABD3@softarmor.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606212104.07057.ft@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.554 tagged_above=-99 required=7 tests=[AWL=0.111, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: "Drage, Keith \(Keith\)" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Wednesday 21 June 2006 17:26, Dean Willis wrote: > > Yes, I realized the state of the document after I posted my > > previous message. I fully understand the problems with rising > > questions about a document in AUTH48, but hope that people view it > > as better that potential issues are raised in AUTH48 than not at > > all. > > > > I would think the Call-Id issues are the most important ones. Most > > of the others are more opinions that I would not have posted if I > > had realized the state of the document. This question was > > apparently also raised by Brian Carpenter, or if it was Lakshminath > > Dondeti (from https://datatracker.ietf.org/public/pidtracker.cgi? > > command=print_ballot&ballot_id=769&filename=draft-ietf-sip-identity > > ) : > > Call-ID and typos like extra "s" can easily be fixed in Auth48. I'm not sure I understand you here, did you read what I wrote about Call-ID issues? I think the issues would require far more changes than could be done during AUTH48. > More substantive changes can, if absolutely necessary, be made by > explicit approval of the supervising AD, who may have to refer some > questions to the larger IESG. After some thought, I personally think that if I haven't misunderstood something, the Call-ID related issues I brought up (and Lakshminath Dondeti brought up before me, although I didn't know about it) really do needs to be addressed. Call-IDs are potentially too predictable to be used for determining if a call should be rejected (because of a duplicate Call-ID) or not. > Restructuring your note to concisely focus on only those things that > can reasonably be fixed in Auth 48 would probably be useful to the > editior, who is currently performing the Auth48 editing task. Who is the AUTH48 editor? I'll do as you suggest and make a short list of proposed AUTH48 changes and send it to this list since I don't know who is the AUTH48 editor. Thanks for both of your advice /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 21 15:13:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft86z-0007MD-6l; Wed, 21 Jun 2006 15:11:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft86x-0007Hl-If for sip@ietf.org; Wed, 21 Jun 2006 15:11:35 -0400 Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft86w-0007Hu-4r for sip@ietf.org; Wed, 21 Jun 2006 15:11:35 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id 95760741F4 for ; Wed, 21 Jun 2006 21:11:33 +0200 (CEST) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 11593-02-34 for ; Wed, 21 Jun 2006 21:11:33 +0200 (CEST) Received: from [192.168.123.15] (c-0cfbe055.1161-1-64736c11.cust.bredbandsbolaget.se [85.224.251.12]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id 18B0D74133 for ; Wed, 21 Jun 2006 21:11:32 +0200 (CEST) From: Fredrik Thulin To: sip@ietf.org Date: Wed, 21 Jun 2006 21:11:27 +0200 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606212111.27935.ft@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.555 tagged_above=-99 required=7 tests=[AWL=0.110, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [Sip] AUTH48 suggested changes for draft-ietf-sip-identity-06 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi The following are the parts of my longer mail about draft-sip-identity (http://www1.ietf.org/mail-archive/web/sip/current/msg14841.html) that I think (or hope) can actually be addressed during AUTH48 : >4. Overview of Operations >... >and thus can validates that the domain indicated nit: should be "can validate" >5. Authentication Service Behavior >... > Note that if that proxy > server is maintaining a TLS connection with the client over which > the client had previously authenticated itself using Digest > authentication, the identity value obtained from that previous > authentication step can be reused without an additional Digest > challenge. Remove this part about a possibility to avoid authenticating a user more than once per TLS session. The proxy server can't know that it is only a single UA that can send messages to it using a given TLS session unless the UA has identified itself with a client certificate, so this is, IMO, bad advice security-wise. > If the authentication service is instantiated by a SIP user agent, > a user agent can be said to authenticate its user on the grounds > that the user can provision the user agent with the private key of > the domain, or preferably by providing a password that unlocks > said private key I'm sure this is not what is intended, but this almost sound as if you think it is perfectly normal to make the private key available publicly as long as it is protected by a password. That might be true if the password is _stronger_ than the private key, but passwords typically aren't. I propose that you remove the last part (", or preferably ..."). >9. Header Syntax >... >the first letter of each week and month MUST be capitalized nit: should be weekday I believe >13.2. Display Names and Identity >... >SIP accounts with arbitrarily display-names. nit: I'm not a native english speaker, but I believe it should be "arbitrary". /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 21 15:35:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft8SZ-0005XB-3E; Wed, 21 Jun 2006 15:33:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft8SX-0005UE-5j for sip@ietf.org; Wed, 21 Jun 2006 15:33:53 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft8SV-0008KG-Pe for sip@ietf.org; Wed, 21 Jun 2006 15:33:53 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 700496C01C; Wed, 21 Jun 2006 15:33:51 -0400 (EDT) Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt From: Scott Lawrence To: Cullen Jennings In-Reply-To: <75A6226C-55DB-4EB9-8FF8-F38EAF45F752@cisco.com> References: <44887921.20302@cisco.com> <1149796932.4721.129.camel@localhost.localdomain> <44898BD0.7000705@cisco.com> <26E13ED4-1582-4CB2-B74E-F5E0985F9810@cisco.com> <1150118729.2822.18.camel@sukothai.pingtel.com> <1150817220.2889.50.camel@sukothai.pingtel.com> <9B35A371-360F-48CB-AEB9-11377CE896EA@cisco.com> <1150913035.2893.73.camel@sukothai.pingtel.com> <75A6226C-55DB-4EB9-8FF8-F38EAF45F752@cisco.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Wed, 21 Jun 2006 15:33:51 -0400 Message-Id: <1150918431.2893.83.camel@sukothai.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Wed, 2006-06-21 at 11:55 -0700, Cullen Jennings wrote: > >>>> Anyways, this is a nit, the serious issues in the > >>>> draft has to do with the size of the responses. > >>> > >>> Do you have some suggestion with respect to that? > >> > >> Yes - I believe the magic number we agreed on for UDP was something > >> close to 1200. You need to say that if any of the hops used UDP, the > >> response MUST NOT be larger than 1200 octets. You then need to show > >> some scheme for a making the response smaller than this. In a typical > >> example with default max hops, I really don't see how this will be > >> possible. I've be very interested in seeing how large a typical > >> example that had the full trace in from actually is. I know this is > >> not very satisfying - I hope some can think of a better way to solve > >> this but I'm not coming up with one. > > > > Well, I didn't cite the number mostly because it's already provided > > elsewhere and I saw no need to duplicate either the number or the > > requirement that the response be under that limit. If you can > > point to > > where that rule is clearly stated in an existing spec, then I think a > > reference to it would be good (I hate it when every document repeats > > rules already stated in some other document - this should be > > 'updates', > > not 'obsoletes'). > > > > I had the number wrong but have a look at section 18.1.1 of RFC 3261. > I think it is good to point out to implementers that they need to > meet this and how they might do it. I agree we don't want this draft > redefining Section 18.1.1 is on sending requests, not responses. I don't find anything in the sections on responses about requiring that they be below any particular size. Even if I am responding positively and sending SDP, on a long path my response may (often will) exceed the 1300 byte limit for requests, but if I follow the rules in 18.2.2 on sending responses I may find myself sending UDP that will fragment. I am not particularly interested in arguing that there should be such a limit, but if there is one in current requirements, I'm happy to cite it. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.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 Jun 21 15:52:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft8iF-0000ZV-Py; Wed, 21 Jun 2006 15:50:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft8iB-0000Wb-3Q; Wed, 21 Jun 2006 15:50:03 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft8i9-0002sm-PC; Wed, 21 Jun 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5LJo1WR028010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Ft8i9-0003lX-Hm; Wed, 21 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 21 Jun 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-hitchhikers-guide-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : A Hitchhikers Guide to the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sip-hitchhikers-guide-00.txt Pages : 29 Date : 2006-6-21 The Session Initiation Protocol (SIP) is the subject of numerous specifications that have been produced by the IETF. It can be difficult to locate the right document, or even to determine the set of Request for Comments (RFC) about SIP. Don't Panic! This specification serves as a guide to the SIP RFC series. It lists the specifications under the SIP umbrella, briefly summarizes each, and groups them into categories. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-hitchhikers-guide-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-hitchhikers-guide-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-hitchhikers-guide-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-21105027.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-hitchhikers-guide-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-hitchhikers-guide-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-21105027.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Wed Jun 21 16:56:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft9ia-0001Vt-BT; Wed, 21 Jun 2006 16:54:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft9iY-0001Vi-T8 for sip@ietf.org; Wed, 21 Jun 2006 16:54:30 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft9iX-0004GJ-F5 for sip@ietf.org; Wed, 21 Jun 2006 16:54:30 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0J1800A01A31OR@siemenscomms.co.uk> for sip@ietf.org; Wed, 21 Jun 2006 21:54:37 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J180062L9DO7N@siemenscomms.co.uk>; Wed, 21 Jun 2006 21:39:25 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 21 Jun 2006 21:38:59 +0100 Content-return: allowed Date: Wed, 21 Jun 2006 21:38:01 +0100 From: "Elwell, John" Subject: RE: [Sip] New draft on coexistence of SIP identity and P-Asserted -ID To: Jonathan Rosenberg , IETF SIP List Message-id: <50B1CBA96870A34799A506B2313F26670937BA29@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: "Jesske, R" , ernst.horvath@siemens.com, drage@lucent.com, mdolly@att.com, christer.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan, Interesting. I have posted the following draft: http://www.ietf.org/internet-drafts/draft-elwell-sip-tispan-connected-identi ty-00.txt ETSI TISPAN has presented Next Generation Network (NGN) requirements for the delivery of two identities for the caller and two identities for the callee in a SIP INVITE-initiated dialog. Although the solution for this in SIP is relatively straightforward for caller identity, the delivery of callee identity presents some additional problems. This document discusses the issues and suggests some candidate solutions. This has arisen from my recent discussions with some ETSI TISPAN people following some discussions a few weeks ago on the SIP list. Basically TISPAN wants to support the concept of delivering two numbers to identify a party, as indicated in their requirements draft (draft-jesske-sipping-tispan-requirements-02 - now expired). For this purpose they are using PAI and From for the two identities (where the From identity could be authenticated by Identity). This does seem to be in conflict with the proposal in your draft. I think we need to find some way of accommodating TISPAN requirements as well as finding a way to encourage the deployment of Identity. John > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: 19 June 2006 14:27 > To: IETF SIP List > Subject: [Sip] New draft on coexistence of SIP identity and > P-Asserted-ID > > As folks know, we have defined both P-Asserted-ID and SIP-identity. > Though the intention is for SIP-identity to replace > P-Asserted-ID, there > are a number of practical challenges in doing this. SIP identity > requires both sides of the call to support it, and it doesn't work at > all with b2buas with media (whether THAT is a bug or a feature is a > matter of perspective). > > I've written an I-D that describes a pretty straightforward technique > for allowing both mechanisms to simultaneously co-exist. Its > backwards > compatible with rfc3325 and works in the presence of b2bua's > under many > (but not all) conditions. The essential idea is to use SIP identity > inter-domain and P-Asserted-ID intra-domain. Until it appears in the > archives, you can pick up a copy at: > > http://www.jdrosen.net/papers/draft-rosenberg-sip-identity-coe > xistence-00.txt > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 21 17:25:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtABD-0002MZ-SO; Wed, 21 Jun 2006 17:24:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtABC-0002MT-Ic for sip@ietf.org; Wed, 21 Jun 2006 17:24:06 -0400 Received: from web36406.mail.mud.yahoo.com ([209.191.85.141]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FtABA-0007Fe-94 for sip@ietf.org; Wed, 21 Jun 2006 17:24:06 -0400 Received: (qmail 47034 invoked by uid 60001); 21 Jun 2006 21:24:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Mas5WwMTIpggvek+n+AHhzpemLo2rH7ueZ3AaPSBt4QSEkaU+m30ch9umG+PF23xzat6Bvsx7Lc9j62sEA91DMFQ1ckoQkhnxavSWvVPWnRCrEYKFP6Jqke9j+aIRwQgASVWB13VyL0ymnBCTH4Q9tvwcBiOQoR5L6g2Htuzt3k= ; Message-ID: <20060621212403.47032.qmail@web36406.mail.mud.yahoo.com> Received: from [86.214.70.22] by web36406.mail.mud.yahoo.com via HTTP; Wed, 21 Jun 2006 14:24:03 PDT Date: Wed, 21 Jun 2006 14:24:03 -0700 (PDT) From: Alan Bergmin Subject: Re: [Sip] Additional uses of INFO To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: 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="===============0059440122==" Errors-To: sip-bounces@ietf.org --===============0059440122== Content-Type: multipart/alternative; boundary="0-810514741-1150925043=:44481" Content-Transfer-Encoding: 8bit --0-810514741-1150925043=:44481 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit > MESSAGE is INFO, except that INFO is supposedly always > in a dialog > Do we have to change HTTP every time somebody uses > it to get a new type of image file or to build a new type > of web application? Let me think . . . nope, we don't. I fully agree. I think that discussions about a new CONSENT request have shown that people do not want to increase the complexity of the SIP protocol with new requests. I really prefer new content-types for an existing INFO request. --------------------------------- Yahoo! Groups gets better. Check out the new email design. Plus there’s much more to come. --0-810514741-1150925043=:44481 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
> MESSAGE is INFO, except that INFO is supposedly always
> in a dialog

> Do we have to change HTTP every time somebody uses
> it to get a new type of image file or to build a new type
> of web application? Let me think . . . nope, we don't.
I fully agree. I think that discussions about a new CONSENT request have shown that people do not want to increase the complexity of the SIP protocol with new requests. I really prefer new content-types for an existing INFO request.
 
 
 
 
 
 
 
 
 
 

Yahoo! Groups gets better. Check out the new email design. Plus there’s much more to come. --0-810514741-1150925043=:44481-- --===============0059440122== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0059440122==-- From sip-bounces@ietf.org Wed Jun 21 17:44:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtATH-0003fL-Tn; Wed, 21 Jun 2006 17:42:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtASW-0003Gm-3b for sip@ietf.org; Wed, 21 Jun 2006 17:42:00 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft9jG-0004JN-4Q for sip@ietf.org; Wed, 21 Jun 2006 16:55:14 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ft9a6-0005Ui-Nr for sip@ietf.org; Wed, 21 Jun 2006 16:45:51 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8206C4F0015; Wed, 21 Jun 2006 22:43:07 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 22:43:06 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 22:43:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound: keep-alive, outbound and 3489bis Date: Wed, 21 Jun 2006 22:43:06 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F116A@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: keep-alive, outbound and 3489bis Thread-Index: AcaVVfDZrHtfNSY8SxOwfTFgHPU7MQABgOXQAAWnPvA= From: "Christer Holmberg \(JO/LMF\)" To: "Francois Audet" , "Cullen Jennings" X-OriginalArrivalTime: 21 Jun 2006 20:43:06.0777 (UTC) FILETIME=[4CBB7890:01C69573] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -2.6 (--) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I'm happy with using the keepalive parameter.=20 Francois, I guess the parameter value would still be "stun" (instead of = "true", as in your example), right? The other question is still whether it should be specified in the = outbound draft, or in a separate draft. Again, IF it remains in the = outbound draft we need to clearly separate the keep-alive usage from the = outbound mechanism itself. Regards, Christer =20 -----Original Message----- From: Francois Audet [mailto:audet@nortel.com]=20 Sent: 21. kes=E4kuuta 2006 20:59 To: Cullen Jennings; Christer Holmberg (JO/LMF) Cc: sip@ietf.org Subject: RE: [Sip] Outbound: keep-alive, outbound and 3489bis I guess it could also be configured in the phone (STUN-in-SIP =3D=3D = TRUE). But if we want to have the keepalive=3Dtrue in the URI as mandatory, I'm = perfectly happy with that. It just means that instead of configuring it = seperately, it's inferred from the URI, which is better because it is = one less thing to worry about. That's exactly the type of thing that I'd like to see in the paragraph. > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Wednesday, June 21, 2006 10:12 > To: Christer Holmberg ((JO/LMF)) > Cc: sip@ietf.org; Audet, Francois [SC100:3055:EXCH] > Subject: Re: [Sip] Outbound: keep-alive, outbound and 3489bis >=20 >=20 >=20 > On Jun 21, 2006, at 9:57 AM, Christer Holmberg ((JO/LMF)) wrote: >=20 > > There must also be a way for the edge proxy to indicate to the=20 > > client that it supports the STUN keep-alive usage. Because, if the=20 > > other outbound features aren't supported/requested, there will be no = > > "outbound" in the Supported header of the registration response. >=20 > this is done with the keepalive=3Dstun parameter in the URI for the = edge=20 > proxy >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 21 17:49:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtAY3-0006cp-27; Wed, 21 Jun 2006 17:47:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtAY0-0006cS-Vv for sip@ietf.org; Wed, 21 Jun 2006 17:47:40 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtAXz-0002kK-Lo for sip@ietf.org; Wed, 21 Jun 2006 17:47:40 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k5LLlZQ12054; Wed, 21 Jun 2006 17:47:36 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound: keep-alive, outbound and 3489bis Date: Wed, 21 Jun 2006 16:47:32 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0AC9A26B@zrc2hxm0.corp.nortel.com> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F116A@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: keep-alive, outbound and 3489bis Thread-Index: AcaVVfDZrHtfNSY8SxOwfTFgHPU7MQABgOXQAAWnPvAAAmvhwA== From: "Francois Audet" To: "Christer Holmberg \(JO/LMF\)" , "Cullen Jennings" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Correct. That was just a "logical" example. > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Sent: Wednesday, June 21, 2006 13:43 > To: Audet, Francois [SC100:3055:EXCH]; Cullen Jennings > Cc: sip@ietf.org > Subject: RE: [Sip] Outbound: keep-alive, outbound and 3489bis >=20 >=20 >=20 > Hi, >=20 > I'm happy with using the keepalive parameter.=20 >=20 > Francois, I guess the parameter value would still be "stun"=20 > (instead of "true", as in your example), right? >=20 > The other question is still whether it should be specified in=20 > the outbound draft, or in a separate draft. Again, IF it=20 > remains in the outbound draft we need to clearly separate the=20 > keep-alive usage from the outbound mechanism itself. >=20 > Regards, >=20 > Christer > =20 >=20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com]=20 > Sent: 21. kes=E4kuuta 2006 20:59 > To: Cullen Jennings; Christer Holmberg (JO/LMF) > Cc: sip@ietf.org > Subject: RE: [Sip] Outbound: keep-alive, outbound and 3489bis >=20 > I guess it could also be configured in the phone (STUN-in-SIP=20 > =3D=3D TRUE). >=20 > But if we want to have the keepalive=3Dtrue in the URI as=20 > mandatory, I'm perfectly happy with that. It just means that=20 > instead of configuring it seperately, it's inferred from the=20 > URI, which is better because it is one less thing to worry about. >=20 > That's exactly the type of thing that I'd like to see in the=20 > paragraph. >=20 > > -----Original Message----- > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > Sent: Wednesday, June 21, 2006 10:12 > > To: Christer Holmberg ((JO/LMF)) > > Cc: sip@ietf.org; Audet, Francois [SC100:3055:EXCH] > > Subject: Re: [Sip] Outbound: keep-alive, outbound and 3489bis > >=20 > >=20 > >=20 > > On Jun 21, 2006, at 9:57 AM, Christer Holmberg ((JO/LMF)) wrote: > >=20 > > > There must also be a way for the edge proxy to indicate to the > > > client that it supports the STUN keep-alive usage.=20 > Because, if the=20 > > > other outbound features aren't supported/requested, there=20 > will be no=20 > > > "outbound" in the Supported header of the registration response. > >=20 > > this is done with the keepalive=3Dstun parameter in the URI=20 > for the edge > > proxy > >=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=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 22 05:53:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtLr0-0002d3-T8; Thu, 22 Jun 2006 05:52:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtLqz-0002Qf-Sk for sip@ietf.org; Thu, 22 Jun 2006 05:52:01 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtLqw-0000R3-Ct for sip@ietf.org; Thu, 22 Jun 2006 05:51:59 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0J1900F01A1SZH@siemenscomms.co.uk> for sip@ietf.org; Thu, 22 Jun 2006 10:51:38 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J1900EH59YREU@siemenscomms.co.uk>; Thu, 22 Jun 2006 10:49:39 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 22 Jun 2006 10:49:14 +0100 Content-return: allowed Date: Thu, 22 Jun 2006 10:48:59 +0100 From: "Elwell, John" Subject: RE: [Sip] The SIPSEC URI I-D To: Paul Kyzivat , "Vijay K. Gurbani" Message-id: <50B1CBA96870A34799A506B2313F26670937BD5E@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul, Ironically, it is on calls to/from the PSTN where it will be most difficult (probably impossible) to assert PSTN-SECURITY. We might determine this for the local SIP hop from the caller/callee to the PSTN gateway. We have no idea what happens beyond the PSTN, where there could be an unsecured IP hop. John > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 21 June 2006 00:35 > To: Vijay K. Gurbani > Cc: IETF SIP List > Subject: Re: [Sip] The SIPSEC URI I-D > > > > Vijay K. Gurbani wrote: > > Paul Kyzivat wrote: > >> Vijay, > >> > >> Thanks for taking the first step! > > > > Paul: Thanks for a reading of the draft! > > > >> My first comment is that I question whether the > requirements you have > >> proposed are the right ones. While they might be > sufficient, I suspect > >> that in many environments a solution meeting those > requirements will > >> be unacceptable. > > > > I can't say you are wrong; but other environments (P2P?) may find > > the requirements a bit more attractive. > > > >> Specifically, a guarantee that depends on hop-by-hop trust may be > >> quite acceptable if it at least guarantees: > >> - nobody but the endpoints and intermediaries on the signaling path > >> can see the signaling > >> - nobody but the endpoints and intermediaries on the signaling path > >> have the keys to the media > >> (Both assuming you trust the intermediaries) > > > > I thought that trusting the intermediaries was the basic problem, > > since nothing short of an end-to-end cert exchange would suffice. > > As the draft now states, the intermediaries are used to rendezvous, > > but then they become conduits to opaque information flowing between > > the endpoints. > > Well, in retrospect, its obvious we can't talk about whether these > requirements are correct or not. There may be different sets > of correct > requirements. > > Your requirements are stronger than what I was suggesting. In > a perfect > world I would rather have a system built to your requirements. > > The current status quo is considerably worse than relying on trusted > intermediaries. I would rather have have a lesser set of requirements > that actually get implemented on the systems that people use. E.g. I > would like something that gets implemented on Vonage and its cousins, > and IMS and its cousins. Anything that gets implemented as a > replacement > for "regular phone service". If it is "as good as" the security of > "regular phone service" then it is a big improvement over > what we have now. > > After I responded the other day I was thinking that one thing > we lack is > some concrete use cases to measure this against. Here are > some initial > thoughts on that: > > - There exist a set (one or more) copywrited/branded icons > corresponding > to various levels of security. Each has a thorough specification of > what guarantees that particular icon denotes. > > - devices / software loads for devices are certified for the right to > display one of these icons. To achieve certification the > device must > have been verified that it follows the appropriate specifications. > > - when a user originates or terminates a call, the device displays > a security icon iff the call conforms to the corresponding spec. > > - some devices may be configurable to accept a call only if the call > will conform to particular security specifications. > > - some devices may be configurable to only complete a call it > originates if the call will conform to a particular security spec. > (Ideally the call will only be offered to those that can conform.) > > That is all very generic. Based on a framework like that we can then > discuss what particular security specifications make sense, > and how many > of them it makes sense for there to be for general use. I am having > difficulty imagining more than three levels being useful, and > even three > is a stretch: > > - SECURE > > You know for certain the identity you are connected to > (though it might not be who you thought you were calling.) > Not even the NSA can tap your call. > > - PSTN-SECURITY > > You are assured that your device, in conjunction with > others, performed due diligence (documented) in determining > the identity displayed (if any) for the connected party. > Your provider and its trusted peers, most likely including > legal authorities, may intervene and tap. They are legally > bound regarding what they will do. > There is assurance that others cannot intervene tap your call. > > - INSECURITY > > You can count on no security at all. > (This is what a lot of SIP calls provide today.) > > If PSTN-SECURITY began to be offered, people would likely > start to ask > why a system doesn't always offer something at least that > good. The only > answers that would hold much water are: > - not our fault. we can do better if the other end can. > - this is cheap (i.e. free) and you get what you pay for > > I expect PSTN-SECURITY would become the low bar, at least for > any paid > service. And as long as many calls have one end in the PSTN, > there will > be many that can't do better than that, so it is an important > level of > security to offer. SECURE then can become a premium service. > > 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 22 07:24:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtNGV-00068U-57; Thu, 22 Jun 2006 07:22:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtNGT-00068P-5U for sip@ietf.org; Thu, 22 Jun 2006 07:22:25 -0400 Received: from mx0.aculab.com ([213.249.233.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtNGR-0005A6-NP for sip@ietf.org; Thu, 22 Jun 2006 07:22:25 -0400 Received: from localhost (localhost [127.0.0.1]) by mx0.aculab.com (Postfix) with ESMTP id BF8228738A for ; Thu, 22 Jun 2006 12:22:22 +0100 (BST) Received: from mx0.aculab.com ([127.0.0.1]) by localhost (mx0.aculab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30673-01 for ; Thu, 22 Jun 2006 12:22:10 +0100 (BST) Received: from saturn.Aculab.com (saturn [10.202.163.6]) by mx0.aculab.com (Postfix) with ESMTP id EA54787373 for ; Thu, 22 Jun 2006 12:22:10 +0100 (BST) Received: by saturn.Aculab.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Jun 2006 12:22:06 +0100 Message-ID: <826EB38238D76947BE8A865F645C7BC7026C281D@saturn.Aculab.com> From: Matthew Gardiner To: IETF SIP List Date: Thu, 22 Jun 2006 12:22:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Aculab-Com-Scanned: by amavisd-new-20030616-p10 (Debian) at aculab.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Subject: [Sip] draft-audet-sip-sips-guidelines - usage of transport=tcp X-BeenThere: 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="===============1367780855==" Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1367780855== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C695EE.17E7545D" 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_01C695EE.17E7545D Content-Type: text/plain; charset="iso-8859-1" Hi, I have been reading version 1 of the above draft and I am confused at finding the following string "sips:registrar.example.com;transport=tcp" in request-URI of the REGISTER examples. I assume that the presence of the sips scheme is to instruct the UAC's stack to use a secure mechanism, SSL, to send the REGISTER. I am unsure as to why transport=tcp is also stated, though I accept that transport=tls is deprecated by 3261. In that case I think would be clearer just to write "sips:registrar.example.com" as surely this implies SSL over TCP. Is "sips:registrar.example.com;transport=tcp" suggested by the draft because "sips:registrar.example.com" might also imply a "secure mechanism whose underlying transport is UDP based"? Could someone clarify? thanks Matthew Gardiner Software Engineer Aculab ------_=_NextPart_001_01C695EE.17E7545D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-audet-sip-sips-guidelines - usage of = transport=3Dtcp

Hi,

I have been reading version 1 of the = above draft and I am confused at finding the following string

"sips:registrar.example.com;transport=3Dtcp"

in request-URI of the REGISTER = examples.

I assume that the presence of the sips = scheme is to instruct the UAC's stack to use a secure mechanism, SSL, = to send the REGISTER. I am unsure as to why transport=3Dtcp is also = stated, though I accept that transport=3Dtls is deprecated by 3261. In = that case I think would be clearer just to write 

"sips:registrar.example.com"

as surely this implies SSL over = TCP.

Is = "sips:registrar.example.com;transport=3Dtcp" suggested by the = draft because "sips:registrar.example.com" might also imply a = "secure mechanism whose underlying transport is UDP = based"?


Could someone clarify?

thanks

Matthew Gardiner
Software Engineer
Aculab





------_=_NextPart_001_01C695EE.17E7545D-- --===============1367780855== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1367780855==-- From sip-bounces@ietf.org Thu Jun 22 11:23:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtR0G-00032X-Kd; Thu, 22 Jun 2006 11:21:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtR0E-00031g-98 for sip@ietf.org; Thu, 22 Jun 2006 11:21:54 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtR0C-0001Y7-NJ for sip@ietf.org; Thu, 22 Jun 2006 11:21:54 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 22 Jun 2006 08:21:52 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,166,1149490800"; d="scan'208"; a="30252680:sNHT25022096" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5MFLpYL001168; Thu, 22 Jun 2006 11:21:51 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Jun 2006 11:21:51 -0400 Received: from [161.44.79.149] ([161.44.79.149]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Jun 2006 11:21:51 -0400 Message-ID: <449AB58E.8080400@cisco.com> Date: Thu, 22 Jun 2006 11:21:50 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [Sip] The SIPSEC URI I-D References: <50B1CBA96870A34799A506B2313F26670937BD5E@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F26670937BD5E@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jun 2006 15:21:51.0301 (UTC) FILETIME=[9610FF50:01C6960F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: IETF SIP List , "Vijay K. Gurbani" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Elwell, John wrote: > Paul, > > Ironically, it is on calls to/from the PSTN where it will be most difficult > (probably impossible) to assert PSTN-SECURITY. We might determine this for > the local SIP hop from the caller/callee to the PSTN gateway. We have no > idea what happens beyond the PSTN, where there could be an unsecured IP hop. Well, I don't know much (if anything) about the details of the PSTN network. My impression is that, often, it provides better security than IP over the internet, that is provided by transitive trust over parties that must be vetted in some way to be connected. One hole in that (I suppose there are many) is that the PSTN currently does allow PSTN interconnect with VoIP systems that may have no security at all. So maybe the security of the PSTN is in fact the same as INSECURE. If so, there may still be a place for a transitive trust level of security that has some legal teeth behind it. Paul > John > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 21 June 2006 00:35 >> To: Vijay K. Gurbani >> Cc: IETF SIP List >> Subject: Re: [Sip] The SIPSEC URI I-D >> >> >> >> Vijay K. Gurbani wrote: >>> Paul Kyzivat wrote: >>>> Vijay, >>>> >>>> Thanks for taking the first step! >>> Paul: Thanks for a reading of the draft! >>> >>>> My first comment is that I question whether the >> requirements you have >>>> proposed are the right ones. While they might be >> sufficient, I suspect >>>> that in many environments a solution meeting those >> requirements will >>>> be unacceptable. >>> I can't say you are wrong; but other environments (P2P?) may find >>> the requirements a bit more attractive. >>> >>>> Specifically, a guarantee that depends on hop-by-hop trust may be >>>> quite acceptable if it at least guarantees: >>>> - nobody but the endpoints and intermediaries on the signaling path >>>> can see the signaling >>>> - nobody but the endpoints and intermediaries on the signaling path >>>> have the keys to the media >>>> (Both assuming you trust the intermediaries) >>> I thought that trusting the intermediaries was the basic problem, >>> since nothing short of an end-to-end cert exchange would suffice. >>> As the draft now states, the intermediaries are used to rendezvous, >>> but then they become conduits to opaque information flowing between >>> the endpoints. >> Well, in retrospect, its obvious we can't talk about whether these >> requirements are correct or not. There may be different sets >> of correct >> requirements. >> >> Your requirements are stronger than what I was suggesting. In >> a perfect >> world I would rather have a system built to your requirements. >> >> The current status quo is considerably worse than relying on trusted >> intermediaries. I would rather have have a lesser set of requirements >> that actually get implemented on the systems that people use. E.g. I >> would like something that gets implemented on Vonage and its cousins, >> and IMS and its cousins. Anything that gets implemented as a >> replacement >> for "regular phone service". If it is "as good as" the security of >> "regular phone service" then it is a big improvement over >> what we have now. >> >> After I responded the other day I was thinking that one thing >> we lack is >> some concrete use cases to measure this against. Here are >> some initial >> thoughts on that: >> >> - There exist a set (one or more) copywrited/branded icons >> corresponding >> to various levels of security. Each has a thorough specification of >> what guarantees that particular icon denotes. >> >> - devices / software loads for devices are certified for the right to >> display one of these icons. To achieve certification the >> device must >> have been verified that it follows the appropriate specifications. >> >> - when a user originates or terminates a call, the device displays >> a security icon iff the call conforms to the corresponding spec. >> >> - some devices may be configurable to accept a call only if the call >> will conform to particular security specifications. >> >> - some devices may be configurable to only complete a call it >> originates if the call will conform to a particular security spec. >> (Ideally the call will only be offered to those that can conform.) >> >> That is all very generic. Based on a framework like that we can then >> discuss what particular security specifications make sense, >> and how many >> of them it makes sense for there to be for general use. I am having >> difficulty imagining more than three levels being useful, and >> even three >> is a stretch: >> >> - SECURE >> >> You know for certain the identity you are connected to >> (though it might not be who you thought you were calling.) >> Not even the NSA can tap your call. >> >> - PSTN-SECURITY >> >> You are assured that your device, in conjunction with >> others, performed due diligence (documented) in determining >> the identity displayed (if any) for the connected party. >> Your provider and its trusted peers, most likely including >> legal authorities, may intervene and tap. They are legally >> bound regarding what they will do. >> There is assurance that others cannot intervene tap your call. >> >> - INSECURITY >> >> You can count on no security at all. >> (This is what a lot of SIP calls provide today.) >> >> If PSTN-SECURITY began to be offered, people would likely >> start to ask >> why a system doesn't always offer something at least that >> good. The only >> answers that would hold much water are: >> - not our fault. we can do better if the other end can. >> - this is cheap (i.e. free) and you get what you pay for >> >> I expect PSTN-SECURITY would become the low bar, at least for >> any paid >> service. And as long as many calls have one end in the PSTN, >> there will >> be many that can't do better than that, so it is an important >> level of >> security to offer. SECURE then can become a premium service. >> >> 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 >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 22 12:53:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtSPO-00005W-7s; Thu, 22 Jun 2006 12:51:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtSPN-0008Ud-2w for sip@ietf.org; Thu, 22 Jun 2006 12:51:57 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtSPK-0000Hq-Bc for sip@ietf.org; Thu, 22 Jun 2006 12:51:57 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-6.cisco.com with ESMTP; 22 Jun 2006 09:51:53 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k5MGprLp001488; Thu, 22 Jun 2006 09:51:53 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5MGppcT021360; Thu, 22 Jun 2006 09:51:53 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Jun 2006 12:51:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] The SIPSEC URI I-D Date: Thu, 22 Jun 2006 12:51:49 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3019E992E@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The SIPSEC URI I-D Thread-Index: AcaWD6rqzb3ZkurBRDCBJAeCT7COZQACmCpw From: "Michael Hammer \(mhammer\)" To: "Paul Kyzivat \(pkyzivat\)" , "Elwell, John" X-OriginalArrivalTime: 22 Jun 2006 16:51:51.0651 (UTC) FILETIME=[28ED0330:01C6961C] DKIM-Signature: a=rsa-sha1; q=dns; l=8175; t=1150995113; x=1151859113; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Sip]=20The=20SIPSEC=20URI=20I-D; X=v=3Dcisco.com=3B=20h=3DBJQ7MD1d8OKRJcRA3JrP37XduNM=3D; b=rZ7n8Z7MQ7gKBTJv0wl75YvP66zvRb6HU6zp2GNT92PakKIG7hQD5bHBdZEPwaELMXEU1zfX k8gWPQL15CfdnWbafSHEZYmZpmThDFeTrrVOxVeQFo3hHMBHNjxIWh1G; Authentication-Results: sj-dkim-7.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: IETF SIP List , "Vijay K. Gurbani" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org But, if there were such thing as a PSTN-SECURITY defined for IP, then PSTNs would then require that as part of connecting to the legacy PSTN. These sort of arguments can be self-fulfilling prophecies. Mike > -----Original Message----- > From: Paul Kyzivat (pkyzivat)=20 > Sent: Thursday, June 22, 2006 11:22 AM > To: Elwell, John > Cc: IETF SIP List; Vijay K. Gurbani > Subject: Re: [Sip] The SIPSEC URI I-D >=20 >=20 >=20 > Elwell, John wrote: > > Paul, > >=20 > > Ironically, it is on calls to/from the PSTN where it will be most=20 > > difficult (probably impossible) to assert PSTN-SECURITY. We might=20 > > determine this for the local SIP hop from the caller/callee to the=20 > > PSTN gateway. We have no idea what happens beyond the PSTN,=20 > where there could be an unsecured IP hop. >=20 > Well, I don't know much (if anything) about the details of=20 > the PSTN network. My impression is that, often, it provides=20 > better security than IP over the internet, that is provided=20 > by transitive trust over parties that must be vetted in some=20 > way to be connected. >=20 > One hole in that (I suppose there are many) is that the PSTN=20 > currently does allow PSTN interconnect with VoIP systems that=20 > may have no security at all. >=20 > So maybe the security of the PSTN is in fact the same as=20 > INSECURE. If so, there may still be a place for a transitive=20 > trust level of security that has some legal teeth behind it. >=20 > Paul >=20 > > John > >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: 21 June 2006 00:35 > >> To: Vijay K. Gurbani > >> Cc: IETF SIP List > >> Subject: Re: [Sip] The SIPSEC URI I-D > >> > >> > >> > >> Vijay K. Gurbani wrote: > >>> Paul Kyzivat wrote: > >>>> Vijay, > >>>> > >>>> Thanks for taking the first step! > >>> Paul: Thanks for a reading of the draft! > >>> > >>>> My first comment is that I question whether the > >> requirements you have > >>>> proposed are the right ones. While they might be > >> sufficient, I suspect > >>>> that in many environments a solution meeting those > >> requirements will > >>>> be unacceptable.=20 > >>> I can't say you are wrong; but other environments (P2P?) may find=20 > >>> the requirements a bit more attractive. > >>> > >>>> Specifically, a guarantee that depends on hop-by-hop=20 > trust may be=20 > >>>> quite acceptable if it at least guarantees: > >>>> - nobody but the endpoints and intermediaries on the=20 > signaling path > >>>> can see the signaling > >>>> - nobody but the endpoints and intermediaries on the=20 > signaling path > >>>> have the keys to the media > >>>> (Both assuming you trust the intermediaries) > >>> I thought that trusting the intermediaries was the basic problem,=20 > >>> since nothing short of an end-to-end cert exchange would suffice. > >>> As the draft now states, the intermediaries are used to=20 > rendezvous,=20 > >>> but then they become conduits to opaque information=20 > flowing between=20 > >>> the endpoints. > >> Well, in retrospect, its obvious we can't talk about whether these=20 > >> requirements are correct or not. There may be different sets of=20 > >> correct requirements. > >> > >> Your requirements are stronger than what I was suggesting. In a=20 > >> perfect world I would rather have a system built to your=20 > >> requirements. > >> > >> The current status quo is considerably worse than relying=20 > on trusted=20 > >> intermediaries. I would rather have have a lesser set of=20 > requirements=20 > >> that actually get implemented on the systems that people=20 > use. E.g. I=20 > >> would like something that gets implemented on Vonage and=20 > its cousins,=20 > >> and IMS and its cousins. Anything that gets implemented as a=20 > >> replacement for "regular phone service". If it is "as good as" the=20 > >> security of "regular phone service" then it is a big=20 > improvement over=20 > >> what we have now. > >> > >> After I responded the other day I was thinking that one=20 > thing we lack=20 > >> is some concrete use cases to measure this against. Here are some=20 > >> initial thoughts on that: > >> > >> - There exist a set (one or more) copywrited/branded icons=20 > >> corresponding > >> to various levels of security. Each has a thorough=20 > specification of > >> what guarantees that particular icon denotes. > >> > >> - devices / software loads for devices are certified for=20 > the right to > >> display one of these icons. To achieve certification the device=20 > >> must > >> have been verified that it follows the appropriate=20 > specifications. > >> > >> - when a user originates or terminates a call, the device displays > >> a security icon iff the call conforms to the corresponding spec. > >> > >> - some devices may be configurable to accept a call only=20 > if the call > >> will conform to particular security specifications. > >> > >> - some devices may be configurable to only complete a call it > >> originates if the call will conform to a particular=20 > security spec. > >> (Ideally the call will only be offered to those that=20 > can conform.) > >> > >> That is all very generic. Based on a framework like that=20 > we can then=20 > >> discuss what particular security specifications make=20 > sense, and how=20 > >> many of them it makes sense for there to be for general use. I am=20 > >> having difficulty imagining more than three levels being=20 > useful, and=20 > >> even three is a stretch: > >> > >> - SECURE > >> > >> You know for certain the identity you are connected to > >> (though it might not be who you thought you were calling.) > >> Not even the NSA can tap your call. > >> > >> - PSTN-SECURITY > >> > >> You are assured that your device, in conjunction with > >> others, performed due diligence (documented) in determining > >> the identity displayed (if any) for the connected party. > >> Your provider and its trusted peers, most likely including > >> legal authorities, may intervene and tap. They are legally > >> bound regarding what they will do. > >> There is assurance that others cannot intervene tap your call. > >> > >> - INSECURITY > >> > >> You can count on no security at all. > >> (This is what a lot of SIP calls provide today.) > >> > >> If PSTN-SECURITY began to be offered, people would likely start to=20 > >> ask why a system doesn't always offer something at least=20 > that good.=20 > >> The only answers that would hold much water are: > >> - not our fault. we can do better if the other end can. > >> - this is cheap (i.e. free) and you get what you pay for > >> > >> I expect PSTN-SECURITY would become the low bar, at least for any=20 > >> paid service. And as long as many calls have one end in the PSTN,=20 > >> there will be many that can't do better than that, so it is an=20 > >> important level of security to offer. SECURE then can become a=20 > >> premium service. > >> > >> Paul > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >> > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 22 13:44:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtTCt-0007OS-LS; Thu, 22 Jun 2006 13:43:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtTCr-0007ON-Np for sip@ietf.org; Thu, 22 Jun 2006 13:43:05 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtTCr-0002ip-CI for sip@ietf.org; Thu, 22 Jun 2006 13:43:05 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5MHh4Rw010818; Thu, 22 Jun 2006 17:43:04 GMT Received: from stntexch03.cis.neustar.com ([10.31.13.45]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 13:43:04 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] Comments on draft-ietf-sip-identity-06 Date: Thu, 22 Jun 2006 13:43:03 -0400 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD597054F4499@stntexch03.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comments on draft-ietf-sip-identity-06 Thread-Index: AcaVONrgshG1jqCsT4K77qVJtawPiAA3xJwg From: "Peterson, Jon" To: "Fredrik Thulin" , "Drage, Keith \(Keith\)" X-OriginalArrivalTime: 22 Jun 2006 17:43:04.0344 (UTC) FILETIME=[5064C180:01C69623] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Regarding the Call-ID issue raised by Lakshminath, we did address this = in a response to GEN-ART during the approval process of sip-identity. = Unfortunately, that mail thread wasn't captured publicly anywhere. The properties that the authors believe we derive from the Call-ID are = described in sip-identity 13.1. The Call-ID is given in the hash in = order to provide a nonce, of sorts, that helps verifiers to identify = cut-and-paste attacks. The ability of an attacker to predict this nonce = does not degrade the security of the mechanism in any way. The Call-ID = alone, of course, would be insufficient to prevent a cut-and-paste = attack; it is used in concert with the Date header especially to allow = verifiers to record received Call-IDs during a Date interval in order to = identify replays. To your specific points: > 1) This applies to _all_ the verifiers in a domain. If the = verification=20 > is done by a domains SIP servers (not the callee's user agent) then=20 > they will have to use a distributed database or a single point of=20 > failure database to remember the Call-Ids seen by _any_ of the=20 > verifiers. I agree that instantiating the verifier role on an intermediary can be = onerus for a number of reasons. It is of course preferable for the = Identity header to be verified directly by the UAS. Do note that that = draft only requires Call-IDs to be remembered for the duration of the = Date interval. I imagine that if multiple verifiers acted on a message, = each might have its own repository for storing Call-IDs it has seen. = Annoying, though, for intermediaries. > 2) If the verification is done by the callee's end user agents, I=20 > beleive it would be possible for an attacker to capture a request (say = > a MESSAGE) sent from sip:bob@biloxi to sip:alice@atlanta, and then = send=20 > an identical MESSAGE with From: sip:bob@biloxi, To: sip:alice@atlanta=20 > but Request-URI sip:carol@atlanta. So, you mean basically forwarding a message to a third party. Yes, you = can do that in any messaging system with any sort of message, signed or = not, whether you are the intended recipient of the message or an = eavesdropper. Only confidentiality properties, which sip-identity does = not provide, can help you with this sort of thing. Most messaging = systems, including SIP, have some concept that messages can be forwarded = by intermediaries, and that the original target address may differ from = the destination identified by intermediaries. This is in a nutshell the = difference between the To and Request-URI fields. > I'm not sure there will ever be a value for any attacker in doing = this,=20 > but it seems possible since Alice and Carol's user agents are very=20 > unlikely to share information about previously seen Call-Ids. Even if=20 > it seems to be a meaningless attack, it is still an attack, or have I=20 > missed something making this impossible? =20 In what sense is forwarding a message an attack? Carol will be able to = ascertain that the message was sent To: Alice, and her UA could apply = automated policies to messages exhibiting this property. Or Carol the = human could react to it if it were merely rendered by her UI. If = messages to Alice mean nothing to Carol, they'll be discarded, either = way. It is worth noting that the sip-identity document is focused on = preventing impersonation. While it might seem plausible to considering = inappropriate forwarding of messages to be a form of impersonation, I = wouldn't say that it is, within the scope of the draft. The original = sender, destination, and content of the message are integrity-protected. = Nothing is being impersonated. It's not like the attacker would be able = to receive responses sent by Carol (if her UA responded) or somehow get = involved with the media. In any event, the relevance of this to the Call-ID is questionable. You = seem to be arguing that the presence of the Call-ID in the hash was = intended to prevent forwarding, and that it isn't working. That = certainly was not the stated motivation for the inclusion of the Call-ID = in the sip-identity draft. Even if you believe this sort of forwarding = does constitute an attack, no properties of the Call-ID especially = prevent or enable "attacks" of this sort. > 3) This IS a problem if the Call-Ids generated by a UA is predictable, = > although unique. I beleive RFC3261 doesn't say that Call-Ids must not=20 > be predictable, even though it says they must be unique. For example,=20 > say that Alice has a UA that produces sequential Call-Ids with the IP=20 > address as 'what makes these unique'. Alice calls me, so I get her UAs = > current Call-Id. She tells me that she is going to call=20 > sip:someone@example.org right after our call. I want to prevent her=20 > from doing that.=20 > > During our call, I send requests to example.org with=20 > the Call-Id's I predict Alices UA will use. Alices call to=20 > sip:someone@example.org will get rejected=20 So, the idea is that you send a seemingly valid, signed request with the = predicted Call-ID to sip:someone before Alice can send her request, so = that sip:someone will reject Alice's request when it shows up because it = has previously accepted a request with the same Call-ID from the same = source. Well, your primary problem with launching an attack like this would be = controlling Alice's authentication service. You would have to, in order = to be able to send a request with an Identity header posing as her. = Guessing her Call-ID doesn't do you any good unless you can somehow = construct the signed Identity header that her authentication service = would generate for that Call-ID. If you're considering requests sent without an Identity header, well, = sip-identity can't help you with those.=20 > Also, what makes subsequent requests in the same dialog as the first = one=20 > not get rejected? They will have the same Call-Id. The CSeq, which is also included in the Identity hash. The same way that = SIP differentiates individual transactions associated with a dialog. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Fredrik Thulin [mailto:ft@it.su.se] > Sent: Wednesday, June 21, 2006 6:44 AM > To: Drage, Keith (Keith) > Cc: sip@ietf.org > Subject: Re: [Sip] Comments on draft-ietf-sip-identity-06 >=20 > [snip] > I would think the Call-Id issues are the most important ones. Most of=20 > the others are more opinions that I would not have posted if I had=20 > realized the state of the document. This question was apparently also=20 > raised by Brian Carpenter, or if it was Lakshminath Dondeti (from=20 > https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dpri nt_ballot&ballot_id=3D769&filename=3Ddraft-ietf-sip-identity ) : >Normally a hash of the message is stored and compared against for=20 >replay protection in addition to things like integrity protected=20 >timestamps (Date). Does the Call-ID provide the same capability=20 >(uniqueness)? I haven't been able to see this question addressed anywhere, but I might = not know where to look. Possibly, the text suggesting that only the first request (for a=20 specific From:) over a TLS session needs to be Digest-authenticated,=20 could also be of the dignity that it needs adressing - since it is=20 "merely" a matter of removing a sentence. I cannot judge whether these issues are serious enough to request=20 withdrawal from the RFC-ed queue, others will have to give their view. /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 22 13:46:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtTEG-0008DI-KD; Thu, 22 Jun 2006 13:44:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtTEE-0008D8-Vl for sip@ietf.org; Thu, 22 Jun 2006 13:44:30 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtTED-0002lD-KU for sip@ietf.org; Thu, 22 Jun 2006 13:44:30 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 22 Jun 2006 10:44:29 -0700 X-IronPort-AV: i="4.06,166,1149490800"; d="scan'208"; a="1830757616:sNHT32434872" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k5MHiTqk021525; Thu, 22 Jun 2006 10:44:29 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5MHiMcX014301; Thu, 22 Jun 2006 10:44:28 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Jun 2006 13:44:28 -0400 Received: from [192.168.1.101] ([10.86.240.32]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Jun 2006 13:44:27 -0400 Message-ID: <449AD6FB.4030402@cisco.com> Date: Thu, 22 Jun 2006 13:44:27 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Bergmin Subject: Re: [Sip] Additional uses of INFO References: <20060621212403.47032.qmail@web36406.mail.mud.yahoo.com> In-Reply-To: <20060621212403.47032.qmail@web36406.mail.mud.yahoo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 22 Jun 2006 17:44:27.0801 (UTC) FILETIME=[82234890:01C69623] DKIM-Signature: a=rsa-sha1; q=dns; l=1760; t=1150998269; x=1151862269; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20Additional=20uses=20of=20INFO; X=v=3Dcisco.com=3B=20h=3Di0N3Fh4uA5dD6ciYsz+MswbDqO8=3D; b=Z0Y6/mpDsSVz+KcFNz3tMa37qw/it1pdW6xfP5Jo7Pb2kmMkqj8VOWzq56cz2DxXOG5BJ6zZ bWfWin1mxcBYaTsGtBNjFx9Lodi+i7nfElXjHI0CQF3J3S5KV4KYfG8F; Authentication-Results: sj-dkim-8.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This whole argument is based on the model that a new method is somehow a big change in SIP, whereas a new body is a small one. Why is that? -Jonathan R. Alan Bergmin wrote: > > MESSAGE is INFO, except that INFO is supposedly always > > in a dialog > > > Do we have to change HTTP every time somebody uses > > it to get a new type of image file or to build a new type > > of web application? Let me think . . . nope, we don't. > I fully agree. I think that discussions about a new CONSENT request have > shown that people do not want to increase the complexity of the SIP > protocol with new requests. I really prefer new content-types for an > existing INFO request. > > > > > > > > > > > > ------------------------------------------------------------------------ > Yahoo! Groups gets better. Check out the new email design. > > Plus there’s much more to come. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 22 15:10:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtUXp-0006D9-MQ; Thu, 22 Jun 2006 15:08:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtUXo-0006D3-0N for sip@ietf.org; Thu, 22 Jun 2006 15:08:48 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtUXm-0003vr-MQ for sip@ietf.org; Thu, 22 Jun 2006 15:08:47 -0400 Received: from [192.168.1.7] (65-65-155-30.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5MJAJZW002119 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 22 Jun 2006 14:10:20 -0500 In-Reply-To: <449AD6FB.4030402@cisco.com> References: <20060621212403.47032.qmail@web36406.mail.mud.yahoo.com> <449AD6FB.4030402@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6A371E14-EAB1-46A6-A253-60BA8EC3AA39@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Additional uses of INFO Date: Thu, 22 Jun 2006 14:08:42 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 22, 2006, at 12:44 PM, Jonathan Rosenberg wrote: > This whole argument is based on the model that a new method is > somehow a big change in SIP, whereas a new body is a small one. > Why is that? > because it is true? The bodies are normally processed in code external to the SIP stack, whereas methods are processed in the SIP stack itself. Again, I'd like to resort to "HTTP as a model". It's not incredibly clean, but it has had some successes. Even with Netscape Navigator version 1.0, we could define "helper applications" for different body types. Using this technique, a browser could deliver content with any arbitrary MIME type to the right application without changing the browser code in any way. The content doesn't change the function of HTTP, which is still doing the same old "get" and "put" and "post" operations. This doesn't mean the the content is unimportant to the HTTP-using application. For example, someone might decide they like the image displayed next to a link and therefore click the link. This doesn't make the "attractiveness of that image" a part of the HTTP protocol. In fact, HTTP doesn't even know that the blob was an image -- it just sees it as an arbitrary stream of bytes associated with a content- type tag. SIP applications could benefit from the same sort of layering. SIP should do its INVITE, SUBSCRIBE, REGISTER, NOTIFY, and INFO operations completely independently of the bodies being carried by the SIP messages. The SIP design pattern of using a new request-type for every "data purpose" is analogous to trying to encode HTML mark-up into the HTTP protocol itself. Imagine a bizarro-world variation on HTTP, where one issued a "GET- TEXT" request to get the plain text on a page, then a "GET-LINK" request for each link, a "GET-IMAGE" request for each image on the page, "GET-SOUND" for embedded sound (and so on) and used some sort of XPATH variation to knit everything back into an HTML document that could be rendered. Then try and do this in real-time, and you'd get something very much like where the current SIP pattern is taking us. -- 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 Jun 22 15:16:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtUdi-00056y-Na; Thu, 22 Jun 2006 15:14:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtUdh-00056t-O1 for sip@ietf.org; Thu, 22 Jun 2006 15:14:53 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtUde-0007wK-DL for sip@ietf.org; Thu, 22 Jun 2006 15:14:53 -0400 Received: from [192.168.0.101] (S010600095b9792b5.vc.shawcable.net [70.79.6.118]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id k5MJEol15823; Thu, 22 Jun 2006 13:14:50 -0600 Message-ID: <449AEC28.8020401@ntt-at.com> Date: Thu, 22 Jun 2006 12:14:48 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] New draft on coexistence of SIP identity and P-Asserted-ID References: <4496A61A.7080905@cisco.com> In-Reply-To: <4496A61A.7080905@cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jonathan; Few comments. Section 3.3 > If the ingress proxy strips the P-A-ID before it verifies the SIP-Identity, there shouldn't be a case where you get a P-A-ID with SIP-Identity that does not verify. If there is, the procedure in section 4.3 for this is missing. > I don't understand why P-A-ID + "support for coexist" is better than P-A-ID alone. Section 4.3 is missing the behavior of ingress proxy when only P-A-ID is present. Section 8. > Third bullet reads " Makes P-A-ID applicable only in intra-domain.." I think "only" does not belong here. Regards Shida Jonathan Rosenberg wrote: > As folks know, we have defined both P-Asserted-ID and SIP-identity. > Though the intention is for SIP-identity to replace P-Asserted-ID, > there are a number of practical challenges in doing this. SIP identity > requires both sides of the call to support it, and it doesn't work at > all with b2buas with media (whether THAT is a bug or a feature is a > matter of perspective). > > I've written an I-D that describes a pretty straightforward technique > for allowing both mechanisms to simultaneously co-exist. Its backwards > compatible with rfc3325 and works in the presence of b2bua's under > many (but not all) conditions. The essential idea is to use SIP > identity inter-domain and P-Asserted-ID intra-domain. Until it appears > in the archives, you can pick up a copy at: > > http://www.jdrosen.net/papers/draft-rosenberg-sip-identity-coexistence-00.txt > > > Thanks, > Jonathan R. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 22 15:25:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtUmX-0004nW-GW; Thu, 22 Jun 2006 15:24:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtUmW-0004k3-Aa for sip@ietf.org; Thu, 22 Jun 2006 15:24:00 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtUmW-0002RX-2A for sip@ietf.org; Thu, 22 Jun 2006 15:24:00 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5MJNxHo024822; Thu, 22 Jun 2006 19:23:59 GMT Received: from stntexch03.cis.neustar.com ([10.31.13.45]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 15:23:59 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] AUTH48 suggested changes for draft-ietf-sip-identity-06 Date: Thu, 22 Jun 2006 15:23:58 -0400 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD597054F449A@stntexch03.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] AUTH48 suggested changes for draft-ietf-sip-identity-06 Thread-Index: AcaVZtm5i0Et5INbRqCXmysp6akeHQAvEqfg From: "Peterson, Jon" To: "Fredrik Thulin" , X-OriginalArrivalTime: 22 Jun 2006 19:23:59.0079 (UTC) FILETIME=[694BFF70:01C69631] X-Spam-Score: -2.8 (--) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Your nits are valid, I'll get those into the document. Regarding your = other points: > >5. Authentication Service Behavior > >... > > Note that if that proxy > > server is maintaining a TLS connection with the client over which > > the client had previously authenticated itself using Digest > > authentication, the identity value obtained from that previous > > authentication step can be reused without an additional Digest > > challenge. >=20 > Remove this part about a possibility to avoid authenticating a user = more=20 > than once per TLS session. The proxy server can't know that it is only = > a single UA that can send messages to it using a given TLS session=20 > unless the UA has identified itself with a client certificate, so this = > is, IMO, bad advice security-wise. In the absence of a direct TLS connection between the UA and the = authentication service, the whole sip-identity mechanism becomes less = secure for a number of reasons - you raise one. The sentence above was = intended to apply only to cases where such a direct connection exists, = but I see how it could be read otherwise. I will fix that. Moreover, I = think it is possible for the authentication service to determine whether = or not a direct connection has been established in the absence of a = client certificate, though I'm not sure that I want to specify that in = this draft, necessarily. > > If the authentication service is instantiated by a SIP user = agent, > > a user agent can be said to authenticate its user on the grounds > > that the user can provision the user agent with the private key = of > > the domain, or preferably by providing a password that unlocks > > said private key >=20 > I'm sure this is not what is intended, but this almost sound as if you = > think it is perfectly normal to make the private key available = publicly=20 > as long as it is protected by a password. That might be true if the=20 > password is _stronger_ than the private key, but passwords typically=20 > aren't. I propose that you remove the last part (", or=20 > preferably ..."). There is certainly no connotation whatsoever here of making a private = key available publicly. The text describes how a user provisions a user = agent with a private key so that a user agent can instantiate the = authentication service role. For cases where a user agent serves = multiple users, it is sensible to password-protect these private keys so = that the user agent can "authenticate" its user. That much said, I can = try to reword it a bit, since it does scan a little awkwardly. 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 Jun 22 15:40:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtV0H-0001DT-6z; Thu, 22 Jun 2006 15:38:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtV0F-0001DO-Kb for sip@ietf.org; Thu, 22 Jun 2006 15:38:11 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtV0E-0003YG-9o for sip@ietf.org; Thu, 22 Jun 2006 15:38:11 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5MJc8Ho025416; Thu, 22 Jun 2006 19:38:09 GMT Received: from stntexch03.cis.neustar.com ([10.31.13.45]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 15:38:08 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] New draft on coexistence of SIP identity and P-Asserted-ID Date: Thu, 22 Jun 2006 15:38:07 -0400 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD597054F449B@stntexch03.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New draft on coexistence of SIP identity and P-Asserted-ID Thread-Index: AcaUxBwhZJCYwV4kQfqviJGawoAYdABbSCvw From: "Peterson, Jon" To: "Jonathan Rosenberg" , "Paul Kyzivat" X-OriginalArrivalTime: 22 Jun 2006 19:38:08.0573 (UTC) FILETIME=[63A27ED0:01C69633] X-Spam-Score: -2.8 (--) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A domain in the RFC3325 sense, that is a "trust domain", is somewhat = strictly defined in RFC3324 Section 2.3. Without that definition, which = Mr. Watson produced in the face of my increasing skepticism about the = nebulous manner in which domain boundaries were being discussed, there = would be no RFC3325. Perhaps that definition would be of service here. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Tuesday, June 20, 2006 4:49 PM > To: Paul Kyzivat > Cc: IETF SIP List > Subject: Re: [Sip] New draft on coexistence of SIP identity and > P-Asserted-ID >=20 >=20 > I view a domain, in the SIP context, as a set of proxies under single=20 > administrative control. This is also somewhat loosely defined, I = admit.=20 > The main idea is that, since a single administrative entity manages = the=20 > proxies (configuring them, operating them, etc.), it has complete=20 > confidence that it knows the precise and absolute conditions under = which=20 > P-Asserted-ID was inserted into the request. >=20 > There is trust inter-domain, but knowledge about the configuration of=20 > the proxy that resulted in insertion of P-Asserted-ID isn't known=20 > directly - its known indirectly by trusting that the peer domain did = its=20 > job. I think thats different. >=20 > -Jonathan R. >=20 > Paul Kyzivat wrote: >=20 > >=20 > >=20 > > Jonathan Rosenberg wrote: > >=20 > >>> - While it is clear that you are trying to tighten up the=20 > security of=20 > >>> identity from what it is in 3325, I'm not convinced that=20 > requiring=20 > >>> the removal of P-Asserted-Identity when receiving a request from=20 > >>> another domain actually achieves anything. Suppose it=20 > were left in?=20 > >>> That means that if some server along the path was bad or=20 > inept the=20 > >>> assertion might be a lie. But a bad or inept server in the=20 > >>> originating network, before signing, can also result in=20 > an assertion=20 > >>> that is a lie, and then result in a signature for that=20 > lie, and then=20 > >>> to that being trusted in the terminating network. > >> > >> > >> The main point is that I am trying to change the scope of=20 > >> P-Asserted-ID to intra-domain, and thus by definition any value=20 > >> received from outside the domain is meaningless. > >=20 > >=20 > > I think this begs the question of what it means for a message flow=20 > > between a sender and a receiver to be "in the domain" vs=20 > "outside the=20 > > domain". When sip:edge1.atlanta.com sends a message to=20 > > sip:home3.atlanta.com, how do they decide they are in the=20 > same domain,=20 > > and that it is the atlanta.com domain? > >=20 > > Isn't that itself all a matter of trust? Or is there some formal=20 > > definition of it? If it is all a matter of trust, then why=20 > is it ok for=20 > > sip:home3.atlanta.com to trust sip:edge1.atlanta.com but=20 > not ok to trust=20 > > sip:edge5.biloxi.com? > >=20 > > Are all the atlanta.com servers supposed to be using TLS=20 > with mutual=20 > > authentication and certs that say they are in atlanta.com?=20 > But then how=20 > > do they prove they are the specific server they claim? > >=20 > > Even in this case, why is it ok to trust the proxies in=20 > your own domain=20 > > but not ok to trust those in another domain. Some providers are=20 > > federations of semi-autonomous divisions, but want to=20 > appear to be a=20 > > single domain. But that doesn't make them all equally=20 > competent. The=20 > > trust of one division by another may not be as great as its=20 > trust in=20 > > some other domain. > >=20 > > Paul > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use 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 Jun 22 15:52:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtVBq-0005xP-K1; Thu, 22 Jun 2006 15:50:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtVBj-0005rq-Dn; Thu, 22 Jun 2006 15:50:03 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtVBi-0004MM-5J; Thu, 22 Jun 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5MJo1WR027170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FtVBh-000693-TQ; Thu, 22 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 22 Jun 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-gruu-09.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sip-gruu-09.txt Pages : 38 Date : 2006-6-22 Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI that can be used by anyone on the Internet to route a call to that specific UA instance. A URI that routes to a specific UA instance is called a Globally Routable UA URI (GRUU). This document describes an extension to SIP for obtaining a GRUU from a server and for communicating a GRUU to a peer within a dialog. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-gruu-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-gruu-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-22100040.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-gruu-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-gruu-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-22100040.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Thu Jun 22 15:52:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtVCZ-0007eD-TQ; Thu, 22 Jun 2006 15:50:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtVBl-0005uQ-Nd; Thu, 22 Jun 2006 15:50:05 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtVBl-0004N4-LT; Thu, 22 Jun 2006 15:50:05 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=oak.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtVBi-0002DW-SV; Thu, 22 Jun 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5MJo2WR027184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FtVBi-0006AJ-EQ; Thu, 22 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 22 Jun 2006 15:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-acr-code-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: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Rejecting Anonymous Requests in the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sip-acr-code-01.txt Pages : 8 Date : 2006-1-17 The Session Initiation Protocol (SIP) allows for users to make anonymous calls. However, users receiving such calls have the right to reject them because they are anonymous. SIP has no way to indicate to the caller that the reason for call rejection was that the call was anonymous. Such an indication is useful to allow the call to be retried without anonymity. This specification defines a new SIP response code for this purpose. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-acr-code-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-acr-code-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-acr-code-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-22120040.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-acr-code-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-acr-code-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-22120040.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Thu Jun 22 16:37:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtVuF-0000AJ-IS; Thu, 22 Jun 2006 16:36:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtVuD-0008IO-A2 for sip@ietf.org; Thu, 22 Jun 2006 16:36:01 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtVuB-0001aC-Ox for sip@ietf.org; Thu, 22 Jun 2006 16:36:01 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5MKZvsW007998; Thu, 22 Jun 2006 23:35:57 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 23:35:56 +0300 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 23:35:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Additional uses of INFO Date: Thu, 22 Jun 2006 23:35:56 +0300 Message-ID: In-Reply-To: <6A371E14-EAB1-46A6-A253-60BA8EC3AA39@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Additional uses of INFO Thread-Index: AcaWL5FxxcM6Cn/lQaCosYDxzb74fAACQrBA From: To: , X-OriginalArrivalTime: 22 Jun 2006 20:35:57.0193 (UTC) FILETIME=[7717E790:01C6963B] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Also, the perception of the time it takes in the IETF to standardize = different things is different. Most people who just want to do something = with SIP become horrified if a SIP usage/extension policy expert says = that what they are doing is fine, but that it requires a new method in = SIP. New headers are not quite as bad, and new content types for = existing methods seem to be the least painful route. Although people = become quite puzzled when you tell them that INFO is not supposed to be = used and MESSAGE can't exceed 1300 Bytes. Another thing is that based on my practical experience, many deployed = SIP networks indeed block the methods they do not know or care about, = even such things like SUBSCRIBEs. (And these are not even IMS based.) = So, reuse of the old methods may be preferred in those cases. One thing that bothers me a bit in SIP that we don't have anything that = could serve as a generic transport between two SIP endpoints. XMPP, for = instance, is more flexible in this sense. Of course you can setup = whatever as a media in a SIP session and run things on top of that, but = even in that case there could be something standardized that people = could easily use. (MSRP was not done based on that kind of requirement, = but it is perhaps the closest there is.) So, I think the average SIP users (meaning developers who want to do = something with SIP) have quite a different view on this than the IETF. Regards, Markus ------------------------------- Markus Isom=E4ki markus.isomaki@nokia.com ------------------------------- =20 >-----Original Message----- >From: ext Dean Willis [mailto:dean.willis@softarmor.com]=20 >Sent: 22 June, 2006 22:09 >To: Jonathan Rosenberg >Cc: sip@ietf.org >Subject: Re: [Sip] Additional uses of INFO > > >On Jun 22, 2006, at 12:44 PM, Jonathan Rosenberg wrote: > >> This whole argument is based on the model that a new method=20 >is somehow=20 >> a big change in SIP, whereas a new body is a small one. >> Why is that? >> > >because it is true? > >The bodies are normally processed in code external to the SIP=20 >stack, whereas methods are processed in the SIP stack itself. > >Again, I'd like to resort to "HTTP as a model". It's not=20 >incredibly clean, but it has had some successes. > >Even with Netscape Navigator version 1.0, we could define=20 >"helper applications" for different body types. Using this=20 >technique, a browser could deliver content with any arbitrary=20 >MIME type to the right application without changing the=20 >browser code in any way. > >The content doesn't change the function of HTTP, which is=20 >still doing the same old "get" and "put" and "post" operations. > >This doesn't mean the the content is unimportant to the=20 >HTTP-using application. For example, someone might decide they=20 >like the image displayed next to a link and therefore click=20 >the link. This doesn't make the "attractiveness of that image"=20 >a part of the HTTP protocol. =20 >In fact, HTTP doesn't even know that the blob was an image --=20 >it just sees it as an arbitrary stream of bytes associated=20 >with a content- type tag. > >SIP applications could benefit from the same sort of layering.=20 >SIP should do its INVITE, SUBSCRIBE, REGISTER, NOTIFY, and=20 >INFO operations completely independently of the bodies being=20 >carried by the SIP messages. > >The SIP design pattern of using a new request-type for every=20 >"data purpose" is analogous to trying to encode HTML mark-up=20 >into the HTTP protocol itself. > >Imagine a bizarro-world variation on HTTP, where one issued a=20 >"GET- TEXT" request to get the plain text on a page, then a=20 >"GET-LINK" =20 >request for each link, a "GET-IMAGE" request for each image on=20 >the page, "GET-SOUND" for embedded sound (and so on) and used=20 >some sort of XPATH variation to knit everything back into an=20 >HTML document that could be rendered. Then try and do this in=20 >real-time, and you'd get something very much like where the=20 >current SIP pattern is taking us. > >-- >dean > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use=20 >sip-implementors@cs.columbia.edu for questions on current sip=20 >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 22 18:15:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtXQj-0003Kg-3G; Thu, 22 Jun 2006 18:13:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtXQh-0003Kb-U7 for sip@ietf.org; Thu, 22 Jun 2006 18:13:39 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtXQf-0002rm-Jt for sip@ietf.org; Thu, 22 Jun 2006 18:13:39 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 22 Jun 2006 15:13:37 -0700 X-IronPort-AV: i="4.06,166,1149490800"; d="scan'208"; a="1830957831:sNHT42224852" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k5MMDbHd010797; Thu, 22 Jun 2006 15:13:37 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5MMDake001834; Thu, 22 Jun 2006 15:13:36 -0700 (PDT) Received: from [216.102.208.13] (sjc-vpn4-700.cisco.com [10.21.82.188]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k5MM8qQq020508; Thu, 22 Jun 2006 15:08:53 -0700 Message-ID: <449B1610.8080602@cisco.com> Date: Thu, 22 Jun 2006 15:13:36 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Additional uses of INFO References: <20060621212403.47032.qmail@web36406.mail.mud.yahoo.com> <449AD6FB.4030402@cisco.com> <6A371E14-EAB1-46A6-A253-60BA8EC3AA39@softarmor.com> In-Reply-To: <6A371E14-EAB1-46A6-A253-60BA8EC3AA39@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-2.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=2072; t=1151014417; x=1151878417; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:Michael=20Thomas=20 |Subject:Re=3A=20[Sip]=20Additional=20uses=20of=20INFO; X=v=3Dcisco.com=3B=20h=3D5C+69rT4Y6yb+3OZ0fv45l2eR3Q=3D; b=ZCJnC5AEHZ2xVSsEzKc1afa61lUD0yo+ZIU5SDd4OpSZcQ9c7nG2NmDZupVB9+Q18xvs4J6M mChy2U9dJhmKT/8m3dunSo3Fm/W5gp+uwJH2ACJYteWC2YGyTY1qQoQD; X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On Jun 22, 2006, at 12:44 PM, Jonathan Rosenberg wrote: > >> This whole argument is based on the model that a new method is >> somehow a big change in SIP, whereas a new body is a small one. Why >> is that? >> > > because it is true? > > The bodies are normally processed in code external to the SIP stack, > whereas methods are processed in the SIP stack itself. > > Again, I'd like to resort to "HTTP as a model". It's not incredibly > clean, but it has had some successes. So it's your position that you'd like SIP to be a generic transport protocol which is what HTTP has become (from the expected to the grotesque)? Versus being a redezvous protocol which leads to the transport with some other protocol like, oh say, HTTP? I guess what I find weird about SIP's collapse into a transport protocol for anything and everything is that it's got all of this heavy proxy machinery, forking and all kinds of other stuff for its primary job which leaves it pretty suboptimal for a whole variety of reasons, not the least of which is the inherent security issues of content through 3rd parties whose intentions are dubious. That and SIP's complexity has long since spiralled out of control. It seems to me that HTTP gets by pretty well because it doesn't attempt to be the last word on signaling protocols. But SIP signals a lot of different things for a lot of different purposes, and instead of getting relatively light weight signaling with heavy weight content (HTTP), going where you're suggesting would get you heavy weight signaling with heavy weight content -- and the inherent combinatorics. Last parting shot: I once asked Cullen whether anybody had ever implemented all of the SIP RFC's into a single stack. As I recall, he just laughed. Let's suppose that somebody were so inclined to do so, would it have any prayer of being passably self-consistent? Or dare I say work, FSVO work? What does this say, especially in light of your position? 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 Jun 22 19:25:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtYWr-0003Ty-OG; Thu, 22 Jun 2006 19:24:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtYWq-0003Ta-Fp for sip@ietf.org; Thu, 22 Jun 2006 19:24:04 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtYWo-0000II-6D for sip@ietf.org; Thu, 22 Jun 2006 19:24:04 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 22 Jun 2006 16:24:02 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,166,1149490800"; d="scan'208"; a="30295942:sNHT23013364" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5MNO1no023316; Thu, 22 Jun 2006 19:24:01 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Jun 2006 19:24:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Additional uses of INFO Date: Thu, 22 Jun 2006 19:24:00 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3019E9B37@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Additional uses of INFO Thread-Index: AcaWSTF307dqeFh9RrygQidZh29CXQACX54g From: "Michael Hammer \(mhammer\)" To: "Michael Thomas" , "Dean Willis" X-OriginalArrivalTime: 22 Jun 2006 23:24:01.0573 (UTC) FILETIME=[F1DA2D50:01C69652] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Mike, Has anyone ever put all the keying mechanisms for TLS or IPSEC into any security protocol stack? You know all that combinatoric stuff? :) Mike H > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com]=20 > Sent: Thursday, June 22, 2006 6:14 PM > To: Dean Willis > Cc: sip@ietf.org > Subject: Re: [Sip] Additional uses of INFO >=20 > Dean Willis wrote: >=20 > > > > On Jun 22, 2006, at 12:44 PM, Jonathan Rosenberg wrote: > > > >> This whole argument is based on the model that a new method is=20 > >> somehow a big change in SIP, whereas a new body is a=20 > small one. Why=20 > >> is that? > >> > > > > because it is true? > > > > The bodies are normally processed in code external to the=20 > SIP stack,=20 > > whereas methods are processed in the SIP stack itself. > > > > Again, I'd like to resort to "HTTP as a model". It's not incredibly=20 > > clean, but it has had some successes. >=20 > So it's your position that you'd like SIP to be a generic=20 > transport protocol which is what HTTP has become (from the=20 > expected to the grotesque)? Versus being a redezvous protocol=20 > which leads to the transport with some other protocol like,=20 > oh say, HTTP? >=20 > I guess what I find weird about SIP's collapse into a=20 > transport protocol for anything and everything is that it's=20 > got all of this heavy proxy machinery, forking and all kinds=20 > of other stuff for its primary job which leaves it pretty=20 > suboptimal for a whole variety of reasons, not the least of=20 > which is the inherent security issues of content through 3rd=20 > parties whose intentions are dubious. >=20 > That and SIP's complexity has long since spiralled out of=20 > control. It seems to me that HTTP gets by pretty well because=20 > it doesn't attempt to be the last word on signaling=20 > protocols. But SIP signals a lot of different things for a=20 > lot of different purposes, and instead of getting relatively=20 > light weight signaling with heavy weight content (HTTP),=20 > going where you're suggesting would get you heavy weight=20 > signaling with heavy weight content -- and the inherent combinatorics. >=20 > Last parting shot: I once asked Cullen whether anybody had=20 > ever implemented all of the SIP RFC's into a single stack. As=20 > I recall, he just laughed. Let's suppose that somebody were=20 > so inclined to do so, would it have any prayer of being=20 > passably self-consistent? Or dare I say work, FSVO work? What=20 > does this say, especially in light of your position? >=20 > Mike >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 22 19:40:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtYkj-00021R-Ie; Thu, 22 Jun 2006 19:38:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtYki-000213-1u for sip@ietf.org; Thu, 22 Jun 2006 19:38:24 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtYkg-0001K8-PE for sip@ietf.org; Thu, 22 Jun 2006 19:38:24 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id F2CC31E8C1C; Thu, 22 Jun 2006 16:38:21 -0700 (PDT) To: "Michael Hammer \(mhammer\)" Subject: Re: [Sip] Additional uses of INFO References: <072C5B76F7CEAB488172C6F64B30B5E3019E9B37@xmb-rtp-20b.amer.cisco.com> From: Eric Rescorla Date: Thu, 22 Jun 2006 16:38:21 -0700 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3019E9B37@xmb-rtp-20b.amer.cisco.com> (Michael Hammer's message of "Thu, 22 Jun 2006 19:24:00 -0400") Message-ID: <867j3892xe.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: sip@ietf.org, Michael Thomas , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org "Michael Hammer \(mhammer\)" writes: > Has anyone ever put all the keying mechanisms for TLS or IPSEC into any > security protocol stack? > > You know all that combinatoric stuff? :) Actually, I believe that all of the standardized keying mechanisms for TLS have been implemented in OpenSSL. -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 22 20:42:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtZiZ-0003sR-IA; Thu, 22 Jun 2006 20:40:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtZiX-0003rZ-5K for sip@ietf.org; Thu, 22 Jun 2006 20:40:13 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtZiX-0006oY-3B for sip@ietf.org; Thu, 22 Jun 2006 20:40:13 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtZec-0004M6-Qe for sip@ietf.org; Thu, 22 Jun 2006 20:36:13 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 22 Jun 2006 17:36:10 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,167,1149490800"; d="scan'208"; a="30299032:sNHT23719368" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5N0aAYL027387; Thu, 22 Jun 2006 20:36:10 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Jun 2006 20:36:09 -0400 Received: from [161.44.79.149] ([161.44.79.149]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Jun 2006 20:36:09 -0400 Message-ID: <449B3779.8010108@cisco.com> Date: Thu, 22 Jun 2006 20:36:09 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Peterson, Jon" Subject: Re: [Sip] New draft on coexistence of SIP identity and P-Asserted-ID References: <24EAE5D4448B9D4592C6D234CBEBD597054F449B@stntexch03.cis.neustar.com> In-Reply-To: <24EAE5D4448B9D4592C6D234CBEBD597054F449B@stntexch03.cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jun 2006 00:36:09.0538 (UTC) FILETIME=[05853A20:01C6965D] X-Spam-Score: -2.3 (--) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Peterson, Jon wrote: > A domain in the RFC3325 sense, that is a "trust domain", is somewhat strictly defined in RFC3324 Section 2.3. Without that definition, which Mr. Watson produced in the face of my increasing skepticism about the nebulous manner in which domain boundaries were being discussed, there would be no RFC3325. Perhaps that definition would be of service here. Yep, I think it would. And, since the issue at hand is about the use of P-Asserted-Identity, which is defined by 3325, and 3325 already references 3324. However, for some reason it only references it informatively. So for purposes here it may eventually need to become a normative reference. Paul P.S. Jon - if you insisted on 3324 as a prerequisite for 3325, then why did you let them get away without a normative reference? > Jon Peterson > NeuStar, Inc. > >> -----Original Message----- >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >> Sent: Tuesday, June 20, 2006 4:49 PM >> To: Paul Kyzivat >> Cc: IETF SIP List >> Subject: Re: [Sip] New draft on coexistence of SIP identity and >> P-Asserted-ID >> >> >> I view a domain, in the SIP context, as a set of proxies under single >> administrative control. This is also somewhat loosely defined, I admit. >> The main idea is that, since a single administrative entity manages the >> proxies (configuring them, operating them, etc.), it has complete >> confidence that it knows the precise and absolute conditions under which >> P-Asserted-ID was inserted into the request. >> >> There is trust inter-domain, but knowledge about the configuration of >> the proxy that resulted in insertion of P-Asserted-ID isn't known >> directly - its known indirectly by trusting that the peer domain did its >> job. I think thats different. >> >> -Jonathan R. >> >> Paul Kyzivat wrote: >> >>> >>> Jonathan Rosenberg wrote: >>> >>>>> - While it is clear that you are trying to tighten up the >> security of >>>>> identity from what it is in 3325, I'm not convinced that >> requiring >>>>> the removal of P-Asserted-Identity when receiving a request from >>>>> another domain actually achieves anything. Suppose it >> were left in? >>>>> That means that if some server along the path was bad or >> inept the >>>>> assertion might be a lie. But a bad or inept server in the >>>>> originating network, before signing, can also result in >> an assertion >>>>> that is a lie, and then result in a signature for that >> lie, and then >>>>> to that being trusted in the terminating network. >>>> >>>> The main point is that I am trying to change the scope of >>>> P-Asserted-ID to intra-domain, and thus by definition any value >>>> received from outside the domain is meaningless. >>> >>> I think this begs the question of what it means for a message flow >>> between a sender and a receiver to be "in the domain" vs >> "outside the >>> domain". When sip:edge1.atlanta.com sends a message to >>> sip:home3.atlanta.com, how do they decide they are in the >> same domain, >>> and that it is the atlanta.com domain? >>> >>> Isn't that itself all a matter of trust? Or is there some formal >>> definition of it? If it is all a matter of trust, then why >> is it ok for >>> sip:home3.atlanta.com to trust sip:edge1.atlanta.com but >> not ok to trust >>> sip:edge5.biloxi.com? >>> >>> Are all the atlanta.com servers supposed to be using TLS >> with mutual >>> authentication and certs that say they are in atlanta.com? >> But then how >>> do they prove they are the specific server they claim? >>> >>> Even in this case, why is it ok to trust the proxies in >> your own domain >>> but not ok to trust those in another domain. Some providers are >>> federations of semi-autonomous divisions, but want to >> appear to be a >>> single domain. But that doesn't make them all equally >> competent. The >>> trust of one division by another may not be as great as its >> trust in >>> some other domain. >>> >>> Paul >>> >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Cisco Fellow Parsippany, NJ >> 07054-2711 >> Cisco Systems >> jdrosen@cisco.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.com >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 23 02:47:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtfPY-0007YB-Cr; Fri, 23 Jun 2006 02:45:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtfPV-0007Y4-Ut for sip@ietf.org; Fri, 23 Jun 2006 02:44:57 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtdZk-0003Ql-7y for sip@ietf.org; Fri, 23 Jun 2006 00:47:24 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtdSS-0000V4-Mf for sip@ietf.org; Fri, 23 Jun 2006 00:39:53 -0400 Received: from [192.168.1.7] (65-65-155-30.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5N4fNBN004460 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 22 Jun 2006 23:41:25 -0500 In-Reply-To: <449B1610.8080602@cisco.com> References: <20060621212403.47032.qmail@web36406.mail.mud.yahoo.com> <449AD6FB.4030402@cisco.com> <6A371E14-EAB1-46A6-A253-60BA8EC3AA39@softarmor.com> <449B1610.8080602@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Additional uses of INFO Date: Thu, 22 Jun 2006 23:39:46 -0500 To: Michael Thomas X-Mailer: Apple Mail (2.750) X-Spam-Score: -2.6 (--) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 22, 2006, at 5:13 PM, Michael Thomas wrote: > Dean Willis wrote: > >> >> On Jun 22, 2006, at 12:44 PM, Jonathan Rosenberg wrote: >> >>> This whole argument is based on the model that a new method is >>> somehow a big change in SIP, whereas a new body is a small one. >>> Why is that? >>> >> >> because it is true? >> >> The bodies are normally processed in code external to the SIP >> stack, whereas methods are processed in the SIP stack itself. >> >> Again, I'd like to resort to "HTTP as a model". It's not >> incredibly clean, but it has had some successes. > > So it's your position that you'd like SIP to be a generic transport > protocol which is > what HTTP has become (from the expected to the grotesque)? Versus > being a > redezvous protocol which leads to the transport with some other > protocol like, oh say, > HTTP? well, it IS a generic transport protocol. Every time somebody comes up with a new application that sounds reasonable, we make a new extension to accommodate them. This is where a lot of our complexity has come from. > > I guess what I find weird about SIP's collapse into a transport > protocol for anything > and everything is that it's got all of this heavy proxy machinery, > forking and all kinds > of other stuff for its primary job which leaves it pretty > suboptimal for a whole variety > of reasons, not the least of which is the inherent security issues > of content through > 3rd parties whose intentions are dubious. Some of this stuff I'll admit I'd like to rip out. But from another perspective, it is some of these capabilities that are driving interest in SIP as a transport protocol for new applications. > Last parting shot: I once asked Cullen whether anybody had ever > implemented all of > the SIP RFC's into a single stack. As I recall, he just laughed. > Let's suppose that somebody > were so inclined to do so, would it have any prayer of being > passably self-consistent? Or > dare I say work, FSVO work? What does this say, especially in light > of your position? No doubt. I'd actually like to make a much narrower cut at "core SIP". A lot of the things that people seem to think need RFCs -- for example, request-URI parameters, I think need only FCFS or possibly "spec required" IANA process. The same is probably true for body types. -- 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 Jun 23 06:59:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtjLw-00062J-QI; Fri, 23 Jun 2006 06:57:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtjLu-00062A-JG; Fri, 23 Jun 2006 06:57:30 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtjLt-0002lT-8c; Fri, 23 Jun 2006 06:57:30 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k5NAvRYC018054; Fri, 23 Jun 2006 05:57:27 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 23 Jun 2006 11:57:23 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C29092C@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'sip@ietf.org'" Date: Fri, 23 Jun 2006 11:57:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C696B3.CDC9BAA0" X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: "'sip-chairs@ietf.org'" Subject: [Sip] draft-ietf-sip-gruu-09.txt ready for IESG? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This 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_01C696B3.CDC9BAA0 Content-Type: text/plain; charset="iso-8859-1" (As WG chair) The SIP WG chairs and the author all think this document is ready for sending to the IESG. We have had WGLC announced 5th July 2004 to complete 17th July 2004. We had a further last round of WG review requested 26th October 2005 to complete 6th November 2005. We have had significant discussion on the lists since then of this draft, and discussion in SIP WG sessions, and all comments have been resolved. If you believe this document IS NOT ready to send to IESG, can you please indicate this to the list and the WG chairs by 12:00 midday UK time (7:00 am US Eastern Time) on 30th June 2006, giving technical justification for your objection. Please limit this thread to answering the question above. If you have other discussion relating to GRUU generally, then please use a different thread. regards Keith -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: 22 June 2006 20:50 To: i-d-announce@ietf.org Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-gruu-09.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 : Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sip-gruu-09.txt Pages : 38 Date : 2006-6-22 Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI that can be used by anyone on the Internet to route a call to that specific UA instance. A URI that routes to a specific UA instance is called a Globally Routable UA URI (GRUU). This document describes an extension to SIP for obtaining a GRUU from a server and for communicating a GRUU to a peer within a dialog. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-gruu-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-gruu-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01C696B3.CDC9BAA0 Content-Type: message/rfc822 To: Subject: Date: Fri, 23 Jun 2006 11:57:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C696B3.CDC9BAA0" ------_=_NextPart_002_01C696B3.CDC9BAA0 Content-Type: text/plain ------_=_NextPart_002_01C696B3.CDC9BAA0 Content-Type: application/octet-stream; name="ATT46619" Content-Disposition: attachment; filename="ATT46619" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-22100040.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-gruu-09.txt ------_=_NextPart_002_01C696B3.CDC9BAA0 Content-Type: message/external-body; site="internet-drafts"; dir="draft-ietf-sip-gruu-09.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C696B3.CDC9BAA0-- ------_=_NextPart_000_01C696B3.CDC9BAA0 Content-Type: text/plain; name="ATT466197.txt" Content-Disposition: attachment; filename="ATT466197.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_01C696B3.CDC9BAA0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_000_01C696B3.CDC9BAA0-- From sip-bounces@ietf.org Fri Jun 23 09:19:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtlX8-00019Z-OC; Fri, 23 Jun 2006 09:17:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtlX7-00019T-9T for sip@ietf.org; Fri, 23 Jun 2006 09:17:13 -0400 Received: from mail.cedarpointcom.com ([67.151.79.70] helo=exchange.cedarpointcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtlX5-0004mS-NM for sip@ietf.org; Fri, 23 Jun 2006 09:17:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 23 Jun 2006 09:17:10 -0400 Message-ID: <9CDE330E7358724EA30D93598D24DE4A01FC5926@exchange.cedarpointcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: INVITE request after 302 response Thread-Index: AcaVIhX7lnegU44wTkuzyv8ysMm3hQBKtCQAAB6XFCA= From: "Sumit Garg" To: "Sumit Garg" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 9b281509fec590bb711c36d4c3ba4f74 Cc: Subject: [Sip] Re: INVITE request after 302 response X-BeenThere: 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="===============2143146458==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2143146458== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C696C7.6041249B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C696C7.6041249B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You could Use the histInfo RFC4244 (Standards Track). =20 -Sumit =20 "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw =20 ________________________________ From: Nataraju A B [mailto:bnataraju@kodiaknetworks.com]=20 Sent: Tuesday, June 20, 2006 1:07 AM To: 'Lei Weimin'; 'Rayees Khan' Cc: sip@ietf.org; sumit.dhar@flextronicssoftware.com Subject: RE: [Sip] Re: INVITE request after 302 response This is very similar to REFER/Referred-BY scenarios. But this redirected INVITE (from 3xx) does not have any header similar to Referred-BY header.=20 =20 If we really need we can extend with referred-by, but this is again a workaround for the problem. But we can make it workable...=20 =20 Thanks & Regards, Nataraju A.B. -----Original Message----- From: Lei Weimin [mailto:leiwm@sict.ac.cn]=20 Sent: Tuesday, June 20, 2006 5:53 AM To: Rayees Khan Cc: bnataraju@kodiaknetworks.com; Zhang Wei; Lei Weimin; sip@ietf.org; sumit.dhar@flextronicssoftware.com Subject: Re: [Sip] Re: INVITE request after 302 response =20 =20 Thanks for your kind response. Just as Rayees said, I also think these is NO general solution to the problem at present. =20 We have to find a specific solution to keep accounts for the "302 Invite" =20 Thanks a lot. =20 =20 Lei Weimin leiwm@sict.ac.cn =20 http://www.sipsys.com =20 =20 =20 =20 =20 From: Rayees Khan =20 To: rathi.kartheek@wipro.com=20 Cc: bnataraju@kodiaknetworks.com ; zhangwei@sict.ac.cn ; Sumit Dhar ; leiwm@sict.ac.cn=20 Sent: Monday, June 19, 2006 11:35 PM Subject: RE: [Sip] Re: INVITE request after 302 response =20 =09 There is no general solution to the problem at the moment. Any solution would be implementation specific. =09 Since the only thing that is common in the first INVITE and re-directed INVITE is From header and the URI in re-directed INVITE is same as contact in 302. Something needs to be worked out form that. =09 regards Rayees =09 =09 =09 ----- wrote: ----- To: Rayees Khan/HSS@HSS From: Date: 06/19/2006 02:54PM cc: , , Sumit Dhar/BLR/HSS@HSS, Subject: RE: [Sip] Re: INVITE request after 302 response Hi Rayees,=20 If CC-Diversion Header is not followed,=20 what alternative do u have to indicate the info of UA2 to UA3=20 when the call gets forwarded ?=20 Regards,=20 Rathi=20 =20 ------_=_NextPart_001_01C696C7.6041249B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
You could Use the histInfo RFC4244 = (Standards=20 Track).
 
-Sumit
 
"The reasonable man adapts himself to the world; the=20 unreasonable one persists in trying to adapt the world to himself. = Therefore all=20 progress depends on the unreasonable man."
-- George Bernard = Shaw
 

From: Nataraju A B=20 [mailto:bnataraju@kodiaknetworks.com]
Sent: Tuesday, June 20, = 2006=20 1:07 AM
To: 'Lei Weimin'; 'Rayees Khan'
Cc: = sip@ietf.org;=20 sumit.dhar@flextronicssoftware.com
Subject: RE: [Sip] Re: = INVITE=20 request after 302 response

This is very similar to = REFER/Referred-BY=20 scenarios. But this redirected INVITE (from 3xx) does not have any = header=20 similar to Referred-BY header.

 

If we really need we can extend = with=20 referred-by, but this is again a workaround for the problem. But we can = make it=20 workable…

 

Thanks &=20 Regards,

Nataraju=20 A.B.

-----Original=20 Message-----
From:=20 Lei=20 Weimin = [mailto:leiwm@sict.ac.cn]
Sent: Tuesday, June 20, 2006 5:53=20 AM
To:=20 Rayees=20 Khan
Cc:=20 bnataraju@kodiaknetworks.com; Zhang Wei;=20 Lei=20 Weimin;=20 sip@ietf.org;=20 sumit.dhar@flextronicssoftware.com
Subject: Re: [Sip] Re: INVITE = request after=20 302 response

 

 

Thanks for your kind=20 response.

Just as Rayees said, I = also think=20 these is NO general solution to the problem at=20 present.

 

We have to find a specific = solution=20 to keep accounts for the "302 Invite"

 

Thanks a=20 lot.

 

 

Lei=20 Weimin

leiwm@sict.ac.cn

http://www.sipsys.com =20

 

 

 

 

From: Rayees Khan=20

To: rathi.kartheek@wipro.com=20

Cc: bnataraju@kodiaknetworks.com= ;=20 zhangwei@sict.ac.cn ; Sumit Dhar ; leiwm@sict.ac.cn=20

Sent: Monday,=20 June 19, 2006 11:35 PM

Subject: RE:=20 [Sip] Re: INVITE request after 302 = response

 


There is no general = solution to the=20 problem at the moment. Any solution would be implementation=20 specific.

Since the only thing that is common in the first = INVITE and=20 re-directed INVITE is From header and the URI in re-directed INVITE is = same as=20 contact in 302. Something needs to be worked out form=20 that.

regards
Rayees

-----<rathi.kartheek@wipro.com>= wrote:=20 -----

To: Rayees Khan/HSS@HSS
From: <rathi.kartheek@wipro.com>=
Date:=20 06/19/2006 02:54PM
cc: <bnataraju@kodiaknetworks.com= >,=20 <zhangwei@sict.ac.cn>, Sumit = Dhar/BLR/HSS@HSS, <leiwm@sict.ac.cn>
Subject: = RE: [Sip]=20 Re: INVITE request after 302 response

Hi Rayees,=20

If = CC-Diversion=20 Header is not followed,

what = alternative do u=20 have to indicate the info of UA2 to UA3 =

when the = call gets=20 forwarded ?=20 = =

Regards, =

Rathi=20

 
------_=_NextPart_001_01C696C7.6041249B-- --===============2143146458== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2143146458==-- From sip-bounces@ietf.org Fri Jun 23 09:37:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftlp8-0003h8-Qv; Fri, 23 Jun 2006 09:35:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftlp7-0003gT-4u for sip@ietf.org; Fri, 23 Jun 2006 09:35:49 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftlp5-0005gf-Qo for sip@ietf.org; Fri, 23 Jun 2006 09:35:49 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 23 Jun 2006 06:35:47 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k5NDZlkq008707; Fri, 23 Jun 2006 06:35:47 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5NDZkCU020472; Fri, 23 Jun 2006 06:35:46 -0700 (PDT) Received: from [216.102.208.13] (sjc-vpn4-700.cisco.com [10.21.82.188]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k5NDV0Jn008252; Fri, 23 Jun 2006 06:31:00 -0700 Message-ID: <449BEE32.1090400@cisco.com> Date: Fri, 23 Jun 2006 06:35:46 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Additional uses of INFO References: <20060621212403.47032.qmail@web36406.mail.mud.yahoo.com> <449AD6FB.4030402@cisco.com> <6A371E14-EAB1-46A6-A253-60BA8EC3AA39@softarmor.com> <449B1610.8080602@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-3.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=3174; t=1151069747; x=1151933747; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:Michael=20Thomas=20 |Subject:Re=3A=20[Sip]=20Additional=20uses=20of=20INFO; X=v=3Dcisco.com=3B=20h=3D5C+69rT4Y6yb+3OZ0fv45l2eR3Q=3D; b=QkuAL1IcbHYVTOpgU7dHvLTwAOZUc7sdKalH5zl6J0bK061b1WmZHL3Pt4qn8/Q7lUqISNnb GP1Wfwx7+KtOUysP1FQtwuB+cOqOJvDfqTBGxkaEeFSoS/4BMeWgWI5y; X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On Jun 22, 2006, at 5:13 PM, Michael Thomas wrote: > >> Dean Willis wrote: >> >> So it's your position that you'd like SIP to be a generic transport >> protocol which is >> what HTTP has become (from the expected to the grotesque)? Versus >> being a >> redezvous protocol which leads to the transport with some other >> protocol like, oh say, >> HTTP? > > > well, it IS a generic transport protocol. Every time somebody comes > up with a new application that sounds reasonable, we make a new > extension to accommodate them. This is where a lot of our complexity > has come from. I know that, but the question to ask is whether it's a very _good_ transport protocol for the jobs it's being asked to do. SIP carries a lot of baggage given its original purpose in life, and you start running into the combinatorics of all of these cross-purposes, and most especially from us dumb dilitante programmer types who don't know the ground rules via years of working group osmosis. And even for somebody like me whose main SIP dilitantism is reading this list, I sure see an awful lot of stump-the-expert kinds of questions, and many seem to fall into either the base complexity, or the "what does this feature meant for this purpose mean in the context of that feature meant for that purpose". If you then combine this with the complexity of addition of unlimited body complexity ala http, will any of this still work? And then all of the security mechanisms layered on? What about their cross purposes? I've been dealing a lot of with email security lately, and it's hard enough to keep that for what approximates straight in my mind, and email is dead simple in comparison to SIP, IMO. >> Last parting shot: I once asked Cullen whether anybody had ever >> implemented all of >> the SIP RFC's into a single stack. As I recall, he just laughed. >> Let's suppose that somebody >> were so inclined to do so, would it have any prayer of being >> passably self-consistent? Or >> dare I say work, FSVO work? What does this say, especially in light >> of your position? > > > No doubt. I'd actually like to make a much narrower cut at "core > SIP". A lot of the things that people seem to think need RFCs -- for > example, request-URI parameters, I think need only FCFS or possibly > "spec required" IANA process. The same is probably true for body types. Maybe part of the problem here is that SIP is more constrained than the analogous HTTP in that there really doesn't need to be anything more than a defacto standard to serve up new content types, unlike the intricacies of the control plane. But you took a pass on my question about why you don't just use SIP to do what it's good for: find things and establish sessions, and let other protocols do the work in their own domain. Is there an existence proof beyond SDP/RTP these days? It seems if SIP were originally made to set up sessions for hair cutting appointments, somebody today would have the great idea of putting RTP over SIP, and who could say they were wrong? Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 23 10:40:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtmnW-0000NO-2b; Fri, 23 Jun 2006 10:38:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtRXv-0000Kj-HK for sip@ietf.org; Thu, 22 Jun 2006 11:56:43 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtRXu-0005tg-7i for sip@ietf.org; Thu, 22 Jun 2006 11:56:43 -0400 Received: from [192.168.1.7] (65-65-155-30.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5MFw4l5001272 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 22 Jun 2006 10:58:06 -0500 In-Reply-To: <95F811A2-E35C-4078-B78D-48D950CBEBA0@cisco.com> References: <5EB80D22825EEE42872083AD5BFFB594017F1165@esealmw113.eemea.ericsson.se> <95F811A2-E35C-4078-B78D-48D950CBEBA0@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Outbound: keep-alive, outbound and 3489bis Date: Thu, 22 Jun 2006 10:56:28 -0500 To: Cullen Jennings X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-Mailman-Approved-At: Fri, 23 Jun 2006 10:38:12 -0400 Cc: "JO/LMF , sip@ietf.org, Francois Audet " X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 21, 2006, at 12:12 PM, Cullen Jennings wrote: > > On Jun 21, 2006, at 9:57 AM, Christer Holmberg ((JO/LMF)) wrote: > >> There must also be a way for the edge proxy to indicate to the >> client that it supports the STUN keep-alive usage. Because, if the >> other outbound features aren't supported/requested, there will be >> no "outbound" in the Supported header of the registration response. > > this is done with the keepalive=stun parameter in the URI for the > edge proxy > > _ I have to admit, I'm a little queasy about this. In the model of the world I hold in my head, a URI is much like a "function call". The parameters in a URI are information being provided to the function, i.e., to the target of the URI. Encoding things ABOUT the behavior of the called function that need to be known to the caller in those parameters just seems very backwards. That's like asking a C programmer to know that a given function will return the cube of the first parameter because the second parameter is "cubed", when that second parameter has no impact whatsoever on the execution of the function and is there only to inform the user of the function about what the function does. So what happens when a client that is constructing a proxy-URI decides to tack on a keepalive=stun parameter, and the proxy doesn't support keepalive via stun? Does the proxy reject a REGISTER request that contains this parameter if it doesn't support it? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 23 10:40:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtmoD-0000j9-Gt; Fri, 23 Jun 2006 10:38:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtdnC-0004BU-Eo for sip@ietf.org; Fri, 23 Jun 2006 01:01:18 -0400 Received: from web8404.mail.in.yahoo.com ([202.43.219.152]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FtdnA-00041B-MV for sip@ietf.org; Fri, 23 Jun 2006 01:01:18 -0400 Received: (qmail 90335 invoked by uid 60001); 23 Jun 2006 04:54:34 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=N/Go14LJbL8JVEnSCUM7E0ixvPaL9EZmZpGKmn6+ix4N53U53E6PK/lBuyNe1pRrsRmFqDLZRs3AANK19DEvZ35IkwerF9v8RhQdpY+7TR/IZCZFbN0B2xhV7yt/TvcGtFKgU3o0eoK3P1vZmeedmsjlXnCKWVWMTHuzjTfuHlc= ; Message-ID: <20060623045434.90333.qmail@web8404.mail.in.yahoo.com> Received: from [137.71.23.54] by web8404.mail.in.yahoo.com via HTTP; Fri, 23 Jun 2006 05:54:33 BST Date: Fri, 23 Jun 2006 05:54:33 +0100 (BST) From: kiran kumar To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-Mailman-Approved-At: Fri, 23 Jun 2006 10:38:56 -0400 Subject: [Sip] query on sip user name X-BeenThere: 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="===============2031216571==" Errors-To: sip-bounces@ietf.org --===============2031216571== Content-Type: multipart/alternative; boundary="0-991726535-1151038473=:89414" Content-Transfer-Encoding: 8bit --0-991726535-1151038473=:89414 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi , I need information on sip user name, i.e " -1 " is user name or not. Thanks& Regards Kirankumar Naidu K --------------------------------- Yahoo! India Answers: Share what you know. Learn something new Click here Catch all the FIFA World Cup 2006 action on Yahoo! India Click here --0-991726535-1151038473=:89414 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi ,
I need information on sip user name, i.e " -1 " is user name or not.
 
 
Thanks& Regards
Kirankumar Naidu K

Yahoo! India Answers: Share what you know. Learn something new Click here
Catch all the FIFA World Cup 2006 action on Yahoo! India Click here --0-991726535-1151038473=:89414-- --===============2031216571== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2031216571==-- From sip-bounces@ietf.org Fri Jun 23 10:41:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftmoo-00014i-6B; Fri, 23 Jun 2006 10:39:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtEhF-0007en-5k for sip@ietf.org; Wed, 21 Jun 2006 22:13:29 -0400 Received: from rwcrmhc14.comcast.net ([204.127.192.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtEhD-0001Vv-UN for sip@ietf.org; Wed, 21 Jun 2006 22:13:29 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc14) with ESMTP id <20060622021326m14000f88oe>; Thu, 22 Jun 2006 02:13:26 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k5M2DP5n011832 for ; Wed, 21 Jun 2006 22:13:25 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k5M2DP3q011828; Wed, 21 Jun 2006 22:13:25 -0400 Date: Wed, 21 Jun 2006 22:13:25 -0400 Message-Id: <200606220213.k5M2DP3q011828@dragon.ariadne.com> From: worley@dworley.hsd1.ma.comcast.net (Dale R. Worley) To: sip@ietf.org In-reply-to: <20060621212403.47032.qmail@web36406.mail.mud.yahoo.com> (alan.bergmin@yahoo.com) Subject: Re: [Sip] Additional uses of INFO References: <20060621212403.47032.qmail@web36406.mail.mud.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Fri, 23 Jun 2006 10:39:32 -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: , Errors-To: sip-bounces@ietf.org I may have missed the discussion, as I've had to rejigger my e-mail, but given the highly non-standardized use of INFO, how do implementations determine whether they can understand an INFO that they receive? It strikes me that it might be possible to allow the different uses of INFO to be distinguished (via x-* Content-Types, probably), without having to commit ourselves to any further standardization. This would significantly avoid interoperability problems, I think. That's not as comprehensible a solution as Jonathan's proposal, but it is something that can be done by current implementations to get rid of the worst problems. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 23 10:41:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftmpc-0001VV-Tg; Fri, 23 Jun 2006 10:40:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtWga-0007Ya-Sg for sip@ietf.org; Thu, 22 Jun 2006 17:26:00 -0400 Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtWgZ-0005ck-KT for sip@ietf.org; Thu, 22 Jun 2006 17:26:00 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc12) with ESMTP id <20060622212558m120092u5se>; Thu, 22 Jun 2006 21:25:58 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k5MLPv5n006850 for ; Thu, 22 Jun 2006 17:25:57 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k5MLPuLk006846; Thu, 22 Jun 2006 17:25:57 -0400 Date: Thu, 22 Jun 2006 17:25:57 -0400 Message-Id: <200606222125.k5MLPuLk006846@dragon.ariadne.com> From: worley@dworley.hsd1.ma.comcast.net (Dale R. Worley) To: sip@ietf.org In-reply-to: <007b01c690a0$4b0b59c0$31713b51@BEMBUSTER> (jbemmel@zonnet.nl) Subject: Re: [Sip] updated GRUU spec References: <4490BF1C.4050304@cisco.com> <007b01c690a0$4b0b59c0$31713b51@BEMBUSTER> X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-Mailman-Approved-At: Fri, 23 Jun 2006 10:40:23 -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: , Errors-To: sip-bounces@ietf.org From: "Jeroen van Bemmel" 1) The protocol bits that trigger issueing of a GRUU are "Supported: gruu" and a sip.instance id in the Contact header. If "supported" then "MUST issue GRUU". If you compare this with e.g. 100rel it seems a bit odd, Supported: 100rel does not force the server to use it. How about Supported -> SHOULD, Require -> MUST ? (could a domain have reasons not to honor the request for GRUUs?) Actually, what triggers *constructing* a GRUU is (1) Registrar implements GRUU, and (2) Contact contains +sip.instance. What triggers adding the gruu header-parameter in the response is (1) and (2) along with (3) "Supported: gruu" in the request (so the Registrar knows that the UAC can cope with it). (As I was reading the I-D, I wondered why the UAC could send +sip.instance without first discerning that the Registrar supported it, but the Registrar could not send gruu without first discerning that the UAC supported it. But I think that's because +sip.instance is identifiable as a caller preference, and there is a defined way for UASs to deal with a caller preference it does not understand.) So if a UA wants to get a GRUU when it can, but not get its registration rejected if it cannot, it uses Supported: gruu and +sip.instance. If the Registrar implements gruu, it MUST send a gruu in response. But if a UA wants to make sure it gets a GRUU (and gets its REGISTER rejected with 420 if it cannot), it uses Supported: gruu, Require: gruu, and +sip.instance. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 23 11:07:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtnDe-0004AU-8z; Fri, 23 Jun 2006 11:05:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtnDc-0004AB-Lm for sip@ietf.org; Fri, 23 Jun 2006 11:05:12 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtnDb-0001DA-9S for sip@ietf.org; Fri, 23 Jun 2006 11:05:12 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k5NF599t007682; Fri, 23 Jun 2006 10:05:09 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 23 Jun 2006 16:05:08 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C290936@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Paul Kyzivat'" , "Peterson, Jon" Subject: RE: [Sip] New draft on coexistence of SIP identity and P-Asserted -ID Date: Fri, 23 Jun 2006 16:05:07 +0100 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: 963faf56c3a5b6715f0b71b66181e01a Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org My understanding is that the requirement to complete Spec(T) in RFC 3325 is the implementation of the RFC 3324 requirement that you identify. Therefore RFC 3324 never needed to be a normative reference from RFC 3325. >From RFC 3325: "A key requirement of [5] is that the behavior of all nodes within a given Trust Domain 'T' is known to comply to a certain set of specifications known as 'Spec(T)'. Spec(T) MUST specify behavior for the following: 1. The manner in which users are authenticated 2. The mechanisms used to secure the communication among nodes within the Trust Domain 3. The mechanisms used to secure the communication between UAs and nodes within the Trust Domain 4. The manner used to determine which hosts are part of the Trust Domain 5. The default privacy handling when no Privacy header field is present 6. That nodes in the Trust Domain are compliant to SIP [1] 7. That nodes in the Trust Domain are compliant to this document 8. Privacy handling for identity as described in Section 7. An example of a suitable Spec(T) is shown in Section 11." regards Keith > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 23 June 2006 01:36 > To: Peterson, Jon > Cc: IETF SIP List > Subject: Re: [Sip] New draft on coexistence of SIP identity and > P-Asserted-ID > > > > > Peterson, Jon wrote: > > A domain in the RFC3325 sense, that is a "trust domain", is > somewhat strictly defined in RFC3324 Section 2.3. Without > that definition, which Mr. Watson produced in the face of my > increasing skepticism about the nebulous manner in which > domain boundaries were being discussed, there would be no > RFC3325. Perhaps that definition would be of service here. > > Yep, I think it would. > > And, since the issue at hand is about the use of P-Asserted-Identity, > which is defined by 3325, and 3325 already references 3324. > However, for > some reason it only references it informatively. So for > purposes here it > may eventually need to become a normative reference. > > Paul > > P.S. Jon - if you insisted on 3324 as a prerequisite for > 3325, then why > did you let them get away without a normative reference? > > > Jon Peterson > > NeuStar, Inc. > > > >> -----Original Message----- > >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > >> Sent: Tuesday, June 20, 2006 4:49 PM > >> To: Paul Kyzivat > >> Cc: IETF SIP List > >> Subject: Re: [Sip] New draft on coexistence of SIP identity and > >> P-Asserted-ID > >> > >> > >> I view a domain, in the SIP context, as a set of proxies > under single > >> administrative control. This is also somewhat loosely > defined, I admit. > >> The main idea is that, since a single administrative > entity manages the > >> proxies (configuring them, operating them, etc.), it has complete > >> confidence that it knows the precise and absolute > conditions under which > >> P-Asserted-ID was inserted into the request. > >> > >> There is trust inter-domain, but knowledge about the > configuration of > >> the proxy that resulted in insertion of P-Asserted-ID isn't known > >> directly - its known indirectly by trusting that the peer > domain did its > >> job. I think thats different. > >> > >> -Jonathan R. > >> > >> Paul Kyzivat wrote: > >> > >>> > >>> Jonathan Rosenberg wrote: > >>> > >>>>> - While it is clear that you are trying to tighten up the > >> security of > >>>>> identity from what it is in 3325, I'm not convinced that > >> requiring > >>>>> the removal of P-Asserted-Identity when receiving a > request from > >>>>> another domain actually achieves anything. Suppose it > >> were left in? > >>>>> That means that if some server along the path was bad or > >> inept the > >>>>> assertion might be a lie. But a bad or inept server in the > >>>>> originating network, before signing, can also result in > >> an assertion > >>>>> that is a lie, and then result in a signature for that > >> lie, and then > >>>>> to that being trusted in the terminating network. > >>>> > >>>> The main point is that I am trying to change the scope of > >>>> P-Asserted-ID to intra-domain, and thus by definition any value > >>>> received from outside the domain is meaningless. > >>> > >>> I think this begs the question of what it means for a > message flow > >>> between a sender and a receiver to be "in the domain" vs > >> "outside the > >>> domain". When sip:edge1.atlanta.com sends a message to > >>> sip:home3.atlanta.com, how do they decide they are in the > >> same domain, > >>> and that it is the atlanta.com domain? > >>> > >>> Isn't that itself all a matter of trust? Or is there some formal > >>> definition of it? If it is all a matter of trust, then why > >> is it ok for > >>> sip:home3.atlanta.com to trust sip:edge1.atlanta.com but > >> not ok to trust > >>> sip:edge5.biloxi.com? > >>> > >>> Are all the atlanta.com servers supposed to be using TLS > >> with mutual > >>> authentication and certs that say they are in atlanta.com? > >> But then how > >>> do they prove they are the specific server they claim? > >>> > >>> Even in this case, why is it ok to trust the proxies in > >> your own domain > >>> but not ok to trust those in another domain. Some providers are > >>> federations of semi-autonomous divisions, but want to > >> appear to be a > >>> single domain. But that doesn't make them all equally > >> competent. The > >>> trust of one division by another may not be as great as its > >> trust in > >>> some other domain. > >>> > >>> Paul > >>> > >> -- > >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >> Cisco Fellow Parsippany, NJ > >> 07054-2711 > >> Cisco Systems > >> jdrosen@cisco.com FAX: > (973) 952-5050 > >> http://www.jdrosen.net PHONE: > (973) 952-5000 > >> http://www.cisco.com > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > >> > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 23 11:26:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtnWM-0002On-9t; Fri, 23 Jun 2006 11:24:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtnWJ-0002Dz-T1 for sip@ietf.org; Fri, 23 Jun 2006 11:24:31 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtnWH-0004VW-Hg for sip@ietf.org; Fri, 23 Jun 2006 11:24:31 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 23 Jun 2006 08:24:29 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,169,1149490800"; d="scan'208"; a="30336911:sNHT24146692" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5NFOSno000412; Fri, 23 Jun 2006 11:24:28 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Jun 2006 11:24:28 -0400 Received: from [192.168.1.101] ([10.86.240.32]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Jun 2006 11:24:27 -0400 Message-ID: <449C07AB.8000309@cisco.com> Date: Fri, 23 Jun 2006 11:24:27 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Dale R. Worley" Subject: Re: [Sip] updated GRUU spec References: <4490BF1C.4050304@cisco.com> <007b01c690a0$4b0b59c0$31713b51@BEMBUSTER> <200606222125.k5MLPuLk006846@dragon.ariadne.com> In-Reply-To: <200606222125.k5MLPuLk006846@dragon.ariadne.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jun 2006 15:24:27.0875 (UTC) FILETIME=[1DCE0B30:01C696D9] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Dale R. Worley wrote: > From: "Jeroen van Bemmel" > > 1) The protocol bits that trigger issueing of a GRUU are "Supported: gruu" > and a sip.instance id in the Contact header. If "supported" then "MUST issue > GRUU". If you compare this with e.g. 100rel it seems a bit odd, Supported: > 100rel does not force the server to use it. How about Supported -> SHOULD, > Require -> MUST ? (could a domain have reasons not to honor the request for > GRUUs?) > > Actually, what triggers *constructing* a GRUU is (1) Registrar > implements GRUU, and (2) Contact contains +sip.instance. Exactly. > What > triggers adding the gruu header-parameter in the response is (1) and > (2) along with (3) "Supported: gruu" in the request (so the Registrar > knows that the UAC can cope with it). Exactly. > > (As I was reading the I-D, I wondered why the UAC could send > +sip.instance without first discerning that the Registrar supported > it, but the Registrar could not send gruu without first discerning > that the UAC supported it. But I think that's because +sip.instance > is identifiable as a caller preference, and there is a defined way for > UASs to deal with a caller preference it does not understand.) There is no need for the client to discover registrar support for gruu prior to registration, because there is no harm in including +sip.instance even if the registrar doesnt support it. Indeed, if ALL the registrar/proxy supports is rfc3841, then +sip.instance is still usable with that (though not terribly valuable). > > So if a UA wants to get a GRUU when it can, but not get its > registration rejected if it cannot, it uses Supported: gruu and > +sip.instance. Right, and this is what it normally ought to do. > If the Registrar implements gruu, it MUST send a gruu > in response. But if a UA wants to make sure it gets a GRUU (and gets > its REGISTER rejected with 420 if it cannot), it uses Supported: gruu, > Require: gruu, and +sip.instance. Only caveat is that require just makes sure the registrar supports gruu; it doesn't FORCE the proxy to hand you out a gruu. Policy may, for some reason, still tell it not to hand you a gruu since you've been a bad boy this year. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 23 12:32:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtoYd-0002ye-3l; Fri, 23 Jun 2006 12:30:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtoYb-0002vy-B1 for sip@ietf.org; Fri, 23 Jun 2006 12:30:57 -0400 Received: from web52708.mail.yahoo.com ([206.190.48.231]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FtoYZ-0007xV-Tx for sip@ietf.org; Fri, 23 Jun 2006 12:30:57 -0400 Received: (qmail 40194 invoked by uid 60001); 23 Jun 2006 16:24:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=rlhMLech2gf0MQilFU/Ncir6gFQES7LA0ekOspuWbG5qo1FORw9fa46bC2YbbsE7S7AOaVGmc0X+Bs2b2DytzcT7OLi9ErKD5HitHjA4SE5PgMb+Ivh8iyCqqjIHGEn7SULNBhd0DNOOgNhtLY5jxBPVNzsfZMLGIVJGSUQExtk= ; Message-ID: <20060623162415.40192.qmail@web52708.mail.yahoo.com> Received: from [192.219.76.114] by web52708.mail.yahoo.com via HTTP; Fri, 23 Jun 2006 09:24:15 PDT Date: Fri, 23 Jun 2006 09:24:15 -0700 (PDT) From: neeraj gupta To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [Sip] timer after 200 OK sent in response to BYE X-BeenThere: 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="===============1383689755==" Errors-To: sip-bounces@ietf.org --===============1383689755== Content-Type: multipart/alternative; boundary="0-1512763084-1151079855=:29141" Content-Transfer-Encoding: 8bit --0-1512763084-1151079855=:29141 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello all I have a question about the timers in the following situation Client Server --------------------------> INVITE ------------------------------> <------------------------ 100 Trying <------------------------------ <------------------------ 180 ringing <------------------------------- --------------------------> Cancel/Bye --------------------------------> <------------------------- 200 OK <------------------------------- After sending the 200 OK, does the server start a timer (Timer J). If yes, why is that so. What is the server waiting for ? I see this behaviour in a user agent. Thanks Neeraj --0-1512763084-1151079855=:29141 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello all

I have a question about the timers in the following situation

Client                                                                   Server
-------------------------->     INVITE                      ------------------------------>
<------------------------       100 Trying                 <------------------------------
<------------------------       180 ringing                <-------------------------------
-------------------------->     Cancel/Bye               -------------------------------->
<-------------------------      200 OK                     <-------------------------------

After sending the 200 OK, does the server start a timer (Timer J).  If yes, why is that so.  What is the server waiting for ?  I see this behaviour in a user agent.

Thanks

Neeraj --0-1512763084-1151079855=:29141-- --===============1383689755== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1383689755==-- From sip-bounces@ietf.org Fri Jun 23 12:57:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftowa-0002uM-Tm; Fri, 23 Jun 2006 12:55:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtowZ-0002uH-BY for sip@ietf.org; Fri, 23 Jun 2006 12:55:43 -0400 Received: from server100.appriver.com ([207.97.227.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtowY-0003Qw-29 for sip@ietf.org; Fri, 23 Jun 2006 12:55:43 -0400 Received: by server100.appriver.com (CommuniGate Pro PIPE 5.0.9) with PIPE id 56841178; Fri, 23 Jun 2006 12:55:43 -0400 Received: from [216.168.161.154] (HELO BUR-SR7-QDL580-1.ivanet.net) by server100.appriver.com (CommuniGate Pro SMTP 5.0.9) with SMTP id 56841154; Fri, 23 Jun 2006 12:55:40 -0400 Received: from server507.ibasis.net ([216.168.160.47]) by BUR-SR7-QDL580-1.ivanet.net (SMSSMTP 4.0.0.59) with SMTP id M2006062312424907225 ; Fri, 23 Jun 2006 12:42:49 -0400 Received: by server507.bur.ibasis.net with Internet Mail Service (5.5.2657.72) id ; Fri, 23 Jun 2006 12:51:38 -0400 Message-ID: <6E9C6C7D27E3714190801A551BE3761002BAB6DC@server507.bur.ibasis.net> From: Manpreet Singh To: neeraj gupta , sip@ietf.org Subject: RE: [Sip] timer after 200 OK sent in response to BYE Date: Fri, 23 Jun 2006 12:51:36 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Policy: GLOBAL X-Policy: GLOBAL X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: msingh@ibasis.net ALLOWED X-Note: Spam Tests Failed: X-Country-Path: UNITED STATES->UNITED STATES->destination X-Note-Sending-IP: 216.168.161.154 X-Note-Reverse-DNS: BUR-SR7-QDL580-1.ivanet.net X-Note-WHTLIST: msingh@ibasis.net X-Note: User Rule Hits: X-Note: Mail Class: ALLOWEDSENDER X-Spam-Score: 0.1 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0360791390==" Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0360791390== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C696E5.4A0039A6" 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_01C696E5.4A0039A6 Content-Type: text/plain Neeraj Based on your call flow below, BYE would never come in an early dialog. So are you asking for 200OK for CANCEL or 200OK for BYE? Few more messages are missing between BYE and 180 below. ( 200OK and ACK) Thanks M. _____ From: neeraj gupta [mailto:ngupta94@yahoo.com] Sent: Friday, June 23, 2006 12:24 PM To: sip@ietf.org Subject: [Sip] timer after 200 OK sent in response to BYE Hello all I have a question about the timers in the following situation Client Server --------------------------> INVITE ------------------------------> <------------------------ 100 Trying <------------------------------ <------------------------ 180 ringing <------------------------------- --------------------------> Cancel/Bye --------------------------------> <------------------------- 200 OK <------------------------------- After sending the 200 OK, does the server start a timer (Timer J). If yes, why is that so. What is the server waiting for ? I see this behaviour in a user agent. Thanks Neeraj ------_=_NextPart_001_01C696E5.4A0039A6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Neeraj
 
Based on your call flow below, BYE would never = come in an=20 early dialog. So are you asking for 200OK for CANCEL or 200OK for BYE? = Few more=20 messages are missing between BYE and 180 below. ( 200OK and=20 ACK)
 
Thanks
M.

From: neeraj gupta = [mailto:ngupta94@yahoo.com]=20
Sent: Friday, June 23, 2006 12:24 PM
To:=20 sip@ietf.org
Subject: [Sip] timer after 200 OK sent in = response to=20 BYE

Hello all

I have a question about the timers in the = following=20 situation

Client        &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp;         =20 Server
-------------------------->    =20 INVITE           =           =20 ------------------------------>
<------------------------ =      =20 100=20 Trying           =      =20 <------------------------------
<------------------------ =      =20 180=20 ringing           = ;    =20 <-------------------------------
-------------------------->&nb= sp;   =20 Cancel/Bye          &n= bsp;   =20 -------------------------------->
<-------------------------&nb= sp;    =20 200=20 OK           &nbs= p;        =20 <-------------------------------

After sending the 200 OK, = does the=20 server start a timer (Timer J).  If yes, why is that so.  = What is the=20 server waiting for ?  I see this behaviour in a user = agent.

Thanks=20

Neeraj ------_=_NextPart_001_01C696E5.4A0039A6-- --===============0360791390== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0360791390==-- From sip-bounces@ietf.org Fri Jun 23 13:56:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftpre-0005Qu-Tu; Fri, 23 Jun 2006 13:54:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftprd-0005Qp-0C for sip@ietf.org; Fri, 23 Jun 2006 13:54:41 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftprc-0000EM-H0 for sip@ietf.org; Fri, 23 Jun 2006 13:54:40 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k5NHsaq03183; Fri, 23 Jun 2006 13:54:36 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] The SIPSEC URI I-D Date: Fri, 23 Jun 2006 12:54:33 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60CDC39FB@zrc2hxm2.corp.nortel.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3019E992E@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The SIPSEC URI I-D Thread-Index: AcaWD6rqzb3ZkurBRDCBJAeCT7COZQACmCpwADSrWzA= From: "Samir Srivastava" To: "Michael Hammer \(mhammer\)" , "Paul Kyzivat \(pkyzivat\)" , "Elwell, John" X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Cc: IETF SIP List , "Vijay K. Gurbani" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Instead of focusing on PSTN security issue. If we can deliver guranteed level of security=20 in IP only network quickly, where I can talk my SSN. Then cool features like telepresence and others Coupled with the security will force the providers to move to IP much more quickly then media gateway vendors have thought of. I don't want to predict here the time... How many on the list agree on this..=20 What is happening on SAML. There was group hum, and then people were saying that we don't have problem. What is the current status on that..=20 SIPS and SIP over TLS is classical example of Running Code thread. Henry must be smiling. Thx Samir =20 -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: Thursday, June 22, 2006 9:52 AM To: Paul Kyzivat (pkyzivat); Elwell, John Cc: IETF SIP List; Vijay K. Gurbani Subject: RE: [Sip] The SIPSEC URI I-D But, if there were such thing as a PSTN-SECURITY defined for IP, then PSTNs would then require that as part of connecting to the legacy PSTN. These sort of arguments can be self-fulfilling prophecies. Mike > -----Original Message----- > From: Paul Kyzivat (pkyzivat) > Sent: Thursday, June 22, 2006 11:22 AM > To: Elwell, John > Cc: IETF SIP List; Vijay K. Gurbani > Subject: Re: [Sip] The SIPSEC URI I-D >=20 >=20 >=20 > Elwell, John wrote: > > Paul, > >=20 > > Ironically, it is on calls to/from the PSTN where it will be most=20 > > difficult (probably impossible) to assert PSTN-SECURITY. We might=20 > > determine this for the local SIP hop from the caller/callee to the=20 > > PSTN gateway. We have no idea what happens beyond the PSTN, > where there could be an unsecured IP hop. >=20 > Well, I don't know much (if anything) about the details of the PSTN=20 > network. My impression is that, often, it provides better security=20 > than IP over the internet, that is provided by transitive trust over=20 > parties that must be vetted in some way to be connected. >=20 > One hole in that (I suppose there are many) is that the PSTN currently > does allow PSTN interconnect with VoIP systems that may have no=20 > security at all. >=20 > So maybe the security of the PSTN is in fact the same as INSECURE. If=20 > so, there may still be a place for a transitive trust level of=20 > security that has some legal teeth behind it. >=20 > Paul >=20 > > John > >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: 21 June 2006 00:35 > >> To: Vijay K. Gurbani > >> Cc: IETF SIP List > >> Subject: Re: [Sip] The SIPSEC URI I-D > >> > >> > >> > >> Vijay K. Gurbani wrote: > >>> Paul Kyzivat wrote: > >>>> Vijay, > >>>> > >>>> Thanks for taking the first step! > >>> Paul: Thanks for a reading of the draft! > >>> > >>>> My first comment is that I question whether the > >> requirements you have > >>>> proposed are the right ones. While they might be > >> sufficient, I suspect > >>>> that in many environments a solution meeting those > >> requirements will > >>>> be unacceptable.=20 > >>> I can't say you are wrong; but other environments (P2P?) may find=20 > >>> the requirements a bit more attractive. > >>> > >>>> Specifically, a guarantee that depends on hop-by-hop > trust may be > >>>> quite acceptable if it at least guarantees: > >>>> - nobody but the endpoints and intermediaries on the > signaling path > >>>> can see the signaling > >>>> - nobody but the endpoints and intermediaries on the > signaling path > >>>> have the keys to the media > >>>> (Both assuming you trust the intermediaries) > >>> I thought that trusting the intermediaries was the basic problem,=20 > >>> since nothing short of an end-to-end cert exchange would suffice. > >>> As the draft now states, the intermediaries are used to > rendezvous, > >>> but then they become conduits to opaque information > flowing between > >>> the endpoints. > >> Well, in retrospect, its obvious we can't talk about whether these=20 > >> requirements are correct or not. There may be different sets of=20 > >> correct requirements. > >> > >> Your requirements are stronger than what I was suggesting. In a=20 > >> perfect world I would rather have a system built to your=20 > >> requirements. > >> > >> The current status quo is considerably worse than relying > on trusted > >> intermediaries. I would rather have have a lesser set of > requirements > >> that actually get implemented on the systems that people > use. E.g. I > >> would like something that gets implemented on Vonage and > its cousins, > >> and IMS and its cousins. Anything that gets implemented as a=20 > >> replacement for "regular phone service". If it is "as good as" the=20 > >> security of "regular phone service" then it is a big > improvement over > >> what we have now. > >> > >> After I responded the other day I was thinking that one > thing we lack > >> is some concrete use cases to measure this against. Here are some=20 > >> initial thoughts on that: > >> > >> - There exist a set (one or more) copywrited/branded icons=20 > >> corresponding > >> to various levels of security. Each has a thorough > specification of > >> what guarantees that particular icon denotes. > >> > >> - devices / software loads for devices are certified for > the right to > >> display one of these icons. To achieve certification the device=20 > >> must > >> have been verified that it follows the appropriate > specifications. > >> > >> - when a user originates or terminates a call, the device displays > >> a security icon iff the call conforms to the corresponding spec. > >> > >> - some devices may be configurable to accept a call only > if the call > >> will conform to particular security specifications. > >> > >> - some devices may be configurable to only complete a call it > >> originates if the call will conform to a particular > security spec. > >> (Ideally the call will only be offered to those that > can conform.) > >> > >> That is all very generic. Based on a framework like that > we can then > >> discuss what particular security specifications make > sense, and how > >> many of them it makes sense for there to be for general use. I am=20 > >> having difficulty imagining more than three levels being > useful, and > >> even three is a stretch: > >> > >> - SECURE > >> > >> You know for certain the identity you are connected to > >> (though it might not be who you thought you were calling.) > >> Not even the NSA can tap your call. > >> > >> - PSTN-SECURITY > >> > >> You are assured that your device, in conjunction with > >> others, performed due diligence (documented) in determining > >> the identity displayed (if any) for the connected party. > >> Your provider and its trusted peers, most likely including > >> legal authorities, may intervene and tap. They are legally > >> bound regarding what they will do. > >> There is assurance that others cannot intervene tap your call. > >> > >> - INSECURITY > >> > >> You can count on no security at all. > >> (This is what a lot of SIP calls provide today.) > >> > >> If PSTN-SECURITY began to be offered, people would likely start to=20 > >> ask why a system doesn't always offer something at least > that good.=20 > >> The only answers that would hold much water are: > >> - not our fault. we can do better if the other end can. > >> - this is cheap (i.e. free) and you get what you pay for > >> > >> I expect PSTN-SECURITY would become the low bar, at least for any=20 > >> paid service. And as long as many calls have one end in the PSTN,=20 > >> there will be many that can't do better than that, so it is an=20 > >> important level of security to offer. SECURE then can become a=20 > >> premium service. > >> > >> Paul > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >> > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 23 14:05:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftq0a-0007Kq-VT; Fri, 23 Jun 2006 14:03:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftq0Z-0007Dd-F2 for sip@ietf.org; Fri, 23 Jun 2006 14:03:55 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftq0X-0000kN-55 for sip@ietf.org; Fri, 23 Jun 2006 14:03:55 -0400 Received: from [192.168.1.2] (65-65-155-30.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5NI5Qnv007885 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 23 Jun 2006 13:05:27 -0500 In-Reply-To: <449BEE32.1090400@cisco.com> References: <20060621212403.47032.qmail@web36406.mail.mud.yahoo.com> <449AD6FB.4030402@cisco.com> <6A371E14-EAB1-46A6-A253-60BA8EC3AA39@softarmor.com> <449B1610.8080602@cisco.com> <449BEE32.1090400@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <327E8A68-4826-48CE-B160-6F49A613A7C4@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Additional uses of INFO Date: Fri, 23 Jun 2006 13:03:47 -0500 To: Michael Thomas X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 23, 2006, at 8:35 AM, Michael Thomas wrote: > > > But you took a pass on my question about why you don't just use SIP > to do what > it's good for: find things and establish sessions, and let other > protocols do the work > in their own domain. Is there an existence proof beyond SDP/RTP > these days? It > seems if SIP were originally made to set up sessions for hair > cutting appointments, > somebody today would have the great idea of putting RTP over SIP, > and who > could say they were wrong? > > Pretty simple, really. The security and firewall-traversal and correspondent discovery mechanisms make it extremely useful as a transport protocol, especially when it is transporting "stuff" that is ancillary to a real-time communications session. Sure, we could set up an additional parallel session to transport the "stuff", but since all the fundamental mechanisms are already there in SIP, why bother? MSRP does define a use case where that "why bother" is answered such that we have agreement to do a parallel session, but I've personally never been incredibly comfortable with that agreement. There are lots of telephony applications of SIP where the "Stuff" being transported is signaling data that's only meaningful in the telephony world and it just needs to get across the IP net to to another GSTN UA on the other side. That should provide an "existence proof", and is the currently agreed use-case for INFO. Another "existence proof' is instant messaging using MESSAGE requests, as implemented in at least one popular client and lots of specifications. Success here is why I'm not so sure about the need for MSRP. Message waiting indicator, even in the crippled implementation (no SUBSCRIBE) of today's Linksys, provides us yet another proof-point, and a glimpse of the massive versatility of the SIP event framework. -- 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 Jun 23 14:10:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftq59-0001Qg-9B; Fri, 23 Jun 2006 14:08:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftq57-0001Qb-Uf for sip@ietf.org; Fri, 23 Jun 2006 14:08:37 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftq56-0000uL-Kr for sip@ietf.org; Fri, 23 Jun 2006 14:08:37 -0400 Received: from [192.168.1.2] (65-65-155-30.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5NIA9XB007901 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 23 Jun 2006 13:10:10 -0500 In-Reply-To: <200606220213.k5M2DP3q011828@dragon.ariadne.com> References: <20060621212403.47032.qmail@web36406.mail.mud.yahoo.com> <200606220213.k5M2DP3q011828@dragon.ariadne.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <74E6B44E-684D-4814-8278-C71069C976D0@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Additional uses of INFO Date: Fri, 23 Jun 2006 13:08:31 -0500 To: "Dale R. Worley" X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 21, 2006, at 9:13 PM, Dale R. Worley wrote: > I may have missed the discussion, as I've had to rejigger my e-mail, > but given the highly non-standardized use of INFO, how do > implementations determine whether they can understand an INFO that > they receive? > Ah. You have there the tip of the INFO problem. We don't have a mechanism to answer this question, and if we were going to do anything BUT GTSN using INFO, we'd need to develop such a mechanism. Thus, two choices -- 1) block all further use of INFO, and 2) add a usage-negotiation mechanism to INFO, just as we did for SIP Events. > It strikes me that it might be possible to allow the different uses of > INFO to be distinguished (via x-* Content-Types, probably), without > having to commit ourselves to any further standardization. This would > significantly avoid interoperability problems, I think. Content-type tells about what the content is. Content-disposition tells about what one is supposed to do with the content, and might be a better candidate for this sort of usage. Or perhaps a combination of the two. If I send you an image/jpeg during a call, what do you do with it? Display it? Add it to your phone book next to my name? Run a steganographic search on it to look for a hidden message? > That's not as comprehensible a solution as Jonathan's proposal, but it > is something that can be done by current implementations to get rid of > the worst problems. There may be a middle ground option somewhere here. -- dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 23 14:38:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtqW6-0006iF-7I; Fri, 23 Jun 2006 14:36:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtqW4-0006iA-94 for sip@ietf.org; Fri, 23 Jun 2006 14:36:28 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtqW1-0002OJ-Rp for sip@ietf.org; Fri, 23 Jun 2006 14:36:28 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 23 Jun 2006 11:36:25 -0700 X-IronPort-AV: i="4.06,169,1149490800"; d="scan'208"; a="300087178:sNHT31671426" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k5NIaPSD008608; Fri, 23 Jun 2006 11:36:25 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5NIaPCU000909; Fri, 23 Jun 2006 11:36:25 -0700 (PDT) Received: from [192.168.0.102] (sjc-vpn-hwcore-390.cisco.com [10.21.153.134]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k5NIVb5k014783; Fri, 23 Jun 2006 11:31:37 -0700 Message-ID: <449C34A8.30701@cisco.com> Date: Fri, 23 Jun 2006 11:36:24 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Additional uses of INFO References: <20060621212403.47032.qmail@web36406.mail.mud.yahoo.com> <449AD6FB.4030402@cisco.com> <6A371E14-EAB1-46A6-A253-60BA8EC3AA39@softarmor.com> <449B1610.8080602@cisco.com> <449BEE32.1090400@cisco.com> <327E8A68-4826-48CE-B160-6F49A613A7C4@softarmor.com> In-Reply-To: <327E8A68-4826-48CE-B160-6F49A613A7C4@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-2.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=3895; t=1151087785; x=1151951785; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:Michael=20Thomas=20 |Subject:Re=3A=20[Sip]=20Additional=20uses=20of=20INFO; X=v=3Dcisco.com=3B=20h=3D5C+69rT4Y6yb+3OZ0fv45l2eR3Q=3D; b=NXZLw5/Zim9ITBgVOmqR5HNF4qcO/klySsNH6hIuubsorOIvoaEbCuFzEemauRQQCf//He4F YCmcOhy9OABGf1Fu3YVBWXVnHr3g7i57VDuoMHu/6BIGdHt3f1BqC36Z; X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On Jun 23, 2006, at 8:35 AM, Michael Thomas wrote: > >> >> >> But you took a pass on my question about why you don't just use SIP >> to do what >> it's good for: find things and establish sessions, and let other >> protocols do the work >> in their own domain. Is there an existence proof beyond SDP/RTP >> these days? It >> seems if SIP were originally made to set up sessions for hair >> cutting appointments, >> somebody today would have the great idea of putting RTP over SIP, >> and who >> could say they were wrong? >> >> > > Pretty simple, really. The security and firewall-traversal and > correspondent discovery mechanisms make it extremely useful as a > transport protocol, especially when it is transporting "stuff" that > is ancillary to a real-time communications session. > > Sure, we could set up an additional parallel session to transport the > "stuff", but since all the fundamental mechanisms are already there > in SIP, why bother? MSRP does define a use case where that "why > bother" is answered such that we have agreement to do a parallel > session, but I've personally never been incredibly comfortable with > that agreement. Well, one reason to bother is complexity, and especially complexity that is at least partially borne out of needing to work around the additions of complexity for other mostly unrelated purposes. Take for example, oh say, sip-identity or S/MIME. Has anybody really gone through all of the use cases of SIP in its full glory to see if is even relevant let alone useful? And if it's not relevant, does that mean that a need is going unmet but we just don't know it yet? And if that's the case, will that unmet (future) need be met by shoe-horning, say, sip-identity (which is in the SIP universe and therefore more malleable) in potentially grotesque ways never envisioned, and probably mostly inappropriate? Or do we invent a new mechanism which is more appropriate for the task, but then get to wonder what happens if they interact with the other SIP mechanisms? At some point, all you're really doing is tunnelling new "stuff" over port 5060. The same can, of course, be said of HTTP, but my sense is that HTTP is still quite a bit leaner at the signalling layer which mitigates the creep to some degree. But SIP is very complicated at the signaling layer and getting moreso every passing year. I understand the expediency of reusing an existing channel, but suppose that we were having this same argument about shipping telephony signaling, etc, over an HTTP substrate. They can djinn up new methods too, after all. Would this be a wise thing for HTTP to take on? Or would you -- IMO properly -- say "go get your own port to play with"? > There are lots of telephony applications of SIP where the "Stuff" > being transported is signaling data that's only meaningful in the > telephony world and it just needs to get across the IP net to to > another GSTN UA on the other side. That should provide an "existence > proof", and is the currently agreed use-case for INFO. > > Another "existence proof' is instant messaging using MESSAGE > requests, as implemented in at least one popular client and lots of > specifications. Success here is why I'm not so sure about the need > for MSRP. > > Message waiting indicator, even in the crippled implementation (no > SUBSCRIBE) of today's Linksys, provides us yet another proof-point, > and a glimpse of the massive versatility of the SIP event framework. Sorry if I'm being dense here, but aren't these all sessions that run over SIP itself? I was curious if there was anything else that was establishing sessions via SIP like SDP/RTP -- ie, where SIP, um, initiated it but otherwise mostly gets out of the way. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 23 14:50:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtqiM-0002tN-TH; Fri, 23 Jun 2006 14:49:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtqiL-0002tD-F1 for sip@ietf.org; Fri, 23 Jun 2006 14:49:09 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtqiJ-0002j0-0J for sip@ietf.org; Fri, 23 Jun 2006 14:49:09 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k5NIn4Rl028442; Fri, 23 Jun 2006 13:49:04 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 23 Jun 2006 19:49:03 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C290948@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Samir Srivastava'" , "Michael Hammer (mhammer)" , "Paul Kyzivat (pkyzivat)" , "Elwell, John" Subject: RE: [Sip] The SIPSEC URI I-D Date: Fri, 23 Jun 2006 19:48:59 +0100 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: 8d89ee9312a95de8ee48d1c94511f1bb Cc: IETF SIP List , "Vijay K. Gurbani" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (as chair) WG document has been issued as http://www.ietf.org/internet-drafts/draft-ietf-sip-saml-00.txt We are currently updating the charter with new dates, which look like they should be the end of 2007, given the significant amount of work to be done. regards Keith > -----Original Message----- > From: Samir Srivastava [mailto:samirsr@nortel.com] > Sent: 23 June 2006 18:55 > To: Michael Hammer (mhammer); Paul Kyzivat (pkyzivat); Elwell, John > Cc: IETF SIP List; Vijay K. Gurbani > Subject: RE: [Sip] The SIPSEC URI I-D > > > What is happening on SAML. There was group hum, and then people were > saying that we don't have problem. What is the current status > on that.. > > > Thx > Samir > > > > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Thursday, June 22, 2006 9:52 AM > To: Paul Kyzivat (pkyzivat); Elwell, John > Cc: IETF SIP List; Vijay K. Gurbani > Subject: RE: [Sip] The SIPSEC URI I-D > > But, if there were such thing as a PSTN-SECURITY defined for IP, then > PSTNs would then require that as part of connecting to the > legacy PSTN. > > These sort of arguments can be self-fulfilling prophecies. > > Mike > > > > -----Original Message----- > > From: Paul Kyzivat (pkyzivat) > > Sent: Thursday, June 22, 2006 11:22 AM > > To: Elwell, John > > Cc: IETF SIP List; Vijay K. Gurbani > > Subject: Re: [Sip] The SIPSEC URI I-D > > > > > > > > Elwell, John wrote: > > > Paul, > > > > > > Ironically, it is on calls to/from the PSTN where it will be most > > > difficult (probably impossible) to assert PSTN-SECURITY. We might > > > determine this for the local SIP hop from the > caller/callee to the > > > PSTN gateway. We have no idea what happens beyond the PSTN, > > where there could be an unsecured IP hop. > > > > Well, I don't know much (if anything) about the details of the PSTN > > network. My impression is that, often, it provides better security > > than IP over the internet, that is provided by transitive > trust over > > parties that must be vetted in some way to be connected. > > > > One hole in that (I suppose there are many) is that the > PSTN currently > > > does allow PSTN interconnect with VoIP systems that may have no > > security at all. > > > > So maybe the security of the PSTN is in fact the same as > INSECURE. If > > so, there may still be a place for a transitive trust level of > > security that has some legal teeth behind it. > > > > Paul > > > > > John > > > > > >> -----Original Message----- > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > >> Sent: 21 June 2006 00:35 > > >> To: Vijay K. Gurbani > > >> Cc: IETF SIP List > > >> Subject: Re: [Sip] The SIPSEC URI I-D > > >> > > >> > > >> > > >> Vijay K. Gurbani wrote: > > >>> Paul Kyzivat wrote: > > >>>> Vijay, > > >>>> > > >>>> Thanks for taking the first step! > > >>> Paul: Thanks for a reading of the draft! > > >>> > > >>>> My first comment is that I question whether the > > >> requirements you have > > >>>> proposed are the right ones. While they might be > > >> sufficient, I suspect > > >>>> that in many environments a solution meeting those > > >> requirements will > > >>>> be unacceptable. > > >>> I can't say you are wrong; but other environments > (P2P?) may find > > >>> the requirements a bit more attractive. > > >>> > > >>>> Specifically, a guarantee that depends on hop-by-hop > > trust may be > > >>>> quite acceptable if it at least guarantees: > > >>>> - nobody but the endpoints and intermediaries on the > > signaling path > > >>>> can see the signaling > > >>>> - nobody but the endpoints and intermediaries on the > > signaling path > > >>>> have the keys to the media > > >>>> (Both assuming you trust the intermediaries) > > >>> I thought that trusting the intermediaries was the > basic problem, > > >>> since nothing short of an end-to-end cert exchange > would suffice. > > >>> As the draft now states, the intermediaries are used to > > rendezvous, > > >>> but then they become conduits to opaque information > > flowing between > > >>> the endpoints. > > >> Well, in retrospect, its obvious we can't talk about > whether these > > >> requirements are correct or not. There may be different sets of > > >> correct requirements. > > >> > > >> Your requirements are stronger than what I was suggesting. In a > > >> perfect world I would rather have a system built to your > > >> requirements. > > >> > > >> The current status quo is considerably worse than relying > > on trusted > > >> intermediaries. I would rather have have a lesser set of > > requirements > > >> that actually get implemented on the systems that people > > use. E.g. I > > >> would like something that gets implemented on Vonage and > > its cousins, > > >> and IMS and its cousins. Anything that gets implemented as a > > >> replacement for "regular phone service". If it is "as > good as" the > > >> security of "regular phone service" then it is a big > > improvement over > > >> what we have now. > > >> > > >> After I responded the other day I was thinking that one > > thing we lack > > >> is some concrete use cases to measure this against. Here > are some > > >> initial thoughts on that: > > >> > > >> - There exist a set (one or more) copywrited/branded icons > > >> corresponding > > >> to various levels of security. Each has a thorough > > specification of > > >> what guarantees that particular icon denotes. > > >> > > >> - devices / software loads for devices are certified for > > the right to > > >> display one of these icons. To achieve certification > the device > > >> must > > >> have been verified that it follows the appropriate > > specifications. > > >> > > >> - when a user originates or terminates a call, the > device displays > > >> a security icon iff the call conforms to the > corresponding spec. > > >> > > >> - some devices may be configurable to accept a call only > > if the call > > >> will conform to particular security specifications. > > >> > > >> - some devices may be configurable to only complete a call it > > >> originates if the call will conform to a particular > > security spec. > > >> (Ideally the call will only be offered to those that > > can conform.) > > >> > > >> That is all very generic. Based on a framework like that > > we can then > > >> discuss what particular security specifications make > > sense, and how > > >> many of them it makes sense for there to be for general > use. I am > > >> having difficulty imagining more than three levels being > > useful, and > > >> even three is a stretch: > > >> > > >> - SECURE > > >> > > >> You know for certain the identity you are connected to > > >> (though it might not be who you thought you were calling.) > > >> Not even the NSA can tap your call. > > >> > > >> - PSTN-SECURITY > > >> > > >> You are assured that your device, in conjunction with > > >> others, performed due diligence (documented) in determining > > >> the identity displayed (if any) for the connected party. > > >> Your provider and its trusted peers, most likely including > > >> legal authorities, may intervene and tap. They are legally > > >> bound regarding what they will do. > > >> There is assurance that others cannot intervene tap your call. > > >> > > >> - INSECURITY > > >> > > >> You can count on no security at all. > > >> (This is what a lot of SIP calls provide today.) > > >> > > >> If PSTN-SECURITY began to be offered, people would > likely start to > > >> ask why a system doesn't always offer something at least > > that good. > > >> The only answers that would hold much water are: > > >> - not our fault. we can do better if the other end can. > > >> - this is cheap (i.e. free) and you get what you pay for > > >> > > >> I expect PSTN-SECURITY would become the low bar, at > least for any > > >> paid service. And as long as many calls have one end in > the PSTN, > > >> there will be many that can't do better than that, so it is an > > >> important level of security to offer. SECURE then can become a > > >> premium service. > > >> > > >> 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 > > >> > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sipping@ietf.org for new developments on the application of sip > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 23 16:05:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtrsR-0007HS-Of; Fri, 23 Jun 2006 16:03:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtrsQ-0007H9-2g for sip@ietf.org; Fri, 23 Jun 2006 16:03:38 -0400 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtrsN-0007pA-S8 for sip@ietf.org; Fri, 23 Jun 2006 16:03:38 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc11) with ESMTP id <2006062320033501100eokhue>; Fri, 23 Jun 2006 20:03:35 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k5NK3Z5n006007 for ; Fri, 23 Jun 2006 16:03:35 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k5NK3ZJt006003; Fri, 23 Jun 2006 16:03:35 -0400 Date: Fri, 23 Jun 2006 16:03:35 -0400 Message-Id: <200606232003.k5NK3ZJt006003@dragon.ariadne.com> From: Dale.Worley@comcast.net To: sip@ietf.org In-reply-to: <74E6B44E-684D-4814-8278-C71069C976D0@softarmor.com> (dean.willis@softarmor.com) Subject: Re: [Sip] Additional uses of INFO References: <20060621212403.47032.qmail@web36406.mail.mud.yahoo.com> <200606220213.k5M2DP3q011828@dragon.ariadne.com> <74E6B44E-684D-4814-8278-C71069C976D0@softarmor.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org [Let's see if I've finally started using e-mail addresses right here.] Now that I think about it a little more, it seems to me that we're getting over-wrought about things. If an implementation wants a private mechanism, that is, one that only interoperates with a handful of other implementations, there are a number of avenues of extensibility, all of which will be treated by other implementations in a standardized (or at least conventionalized) way: Information Technique Default interpretation new method X-* method 405 response new header X-* header ignored new session type new x-* Content-Type 415 response in INVITE new data lump new x-* Content-Type 415 response transport in INFO new extension new x-* option-tag 420 response identifier (And there are a number of others.) In every case, as long as the implementation that understands the extension is prepared to recognize the default interpretation as a situation where the extension cannot operate, there should be no serious interoperability problems. Of course, if someone wants an extension with wide interoperability, they're stuck going through the whole WG process, or something very similar in another forum, just because that's the only way to get a wide range of implementors to agree on how to do something. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 23 16:18:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fts5W-000319-08; Fri, 23 Jun 2006 16:17:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fts5U-0002xQ-3d for sip@ietf.org; Fri, 23 Jun 2006 16:17:08 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fts5S-0000YR-R6 for sip@ietf.org; Fri, 23 Jun 2006 16:17:08 -0400 X-IronPort-AV: i="4.06,170,1149480000"; d="scan'208"; a="34556010:sNHT44547768" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Mismatch in registry policy requirements of RFC 3969 Date: Fri, 23 Jun 2006 16:18:35 -0400 Message-ID: <330A23D8336C0346B5C1A5BB196666470317AB28@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Mismatch in registry policy requirements of RFC 3969 Thread-Index: AcaC7qcz6xMCErp2RkixesMmN/2ptATvAZaQ From: "Burger, Eric" To: "Aki Niemi" , "ext Gonzalo Camarillo" X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I agree we need something "in the middle." I would offer that very tight control on URI parameters will land us in the same place as too tight control on headers. That is, we end up with a ton of X-mumble with no documentation. Worse yet, we end up with P-mumble with little review. The problem is sometimes X-mumble actually does useful stuff. For example, the RFC 2822 message I'm responding to right now has 33 non-routing (Received:) headers. Of those 33 headers, 15, or almost half, are X-mumble. A good bit of those are put in by the IETF list server, so don't whine about people using proprietary e-mail systems. I would much rather have an easy-to-publish/document method for whacky URI parameters than to force the drug users underground :) -----Original Message----- From: Aki Niemi [mailto:aki.niemi@nokia.com]=20 Sent: Monday, May 29, 2006 3:06 AM To: ext Gonzalo Camarillo Cc: Cullen Jennings; SIP IETF; Dean Willis Subject: Re: [Sip] Mismatch in registry policy requirements of RFC 3969 ext Gonzalo Camarillo wrote: > Hi, >=20 > the conclusion was the IETF wanted to have tighter control on SIP URI > parameters than on header field parameters. Therefore, one would need a > standards-track RFC in order to create new SIP URI parameters... that > was the intent. Believing this gives the WG tighter control is a delusion. Similarly, one could set the speedlimit on highways to 2 miles or 5 kilometers an hour, and sit and watch everyone breaking it. I think all this does is it makes people who need URI parameters go underground. And that makes interop worse, not better. It also all but guarantees the SIP* working groups will be flooded with trivial specifications of extension parameters, over which we will be able to have many entertaining but utterly useless debates. I'll also note that in the end, the only people who will even attempt to abide by these types of policies are other SDOs because they sort of have to; everyone else in the industry won't pay any attention. I was of the opinion way back when this was discussed the last time, but remember being in the minority. Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 23 16:35:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtsLV-0004pG-8T; Fri, 23 Jun 2006 16:33:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtsLU-0004mz-Ba for sip@ietf.org; Fri, 23 Jun 2006 16:33:40 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtsLT-00021G-2j for sip@ietf.org; Fri, 23 Jun 2006 16:33:40 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 23 Jun 2006 13:33:38 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,170,1149490800"; d="scan'208"; a="30363336:sNHT22576688" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5NKXcYL014268; Fri, 23 Jun 2006 16:33:38 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Jun 2006 16:33:38 -0400 Received: from [192.168.1.101] ([10.86.240.43]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Jun 2006 16:33:37 -0400 Message-ID: <449C5020.3060904@cisco.com> Date: Fri, 23 Jun 2006 16:33:36 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Additional uses of INFO References: <20060621212403.47032.qmail@web36406.mail.mud.yahoo.com> <449AD6FB.4030402@cisco.com> <6A371E14-EAB1-46A6-A253-60BA8EC3AA39@softarmor.com> In-Reply-To: <6A371E14-EAB1-46A6-A253-60BA8EC3AA39@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jun 2006 20:33:37.0576 (UTC) FILETIME=[4E49CA80:01C69704] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On Jun 22, 2006, at 12:44 PM, Jonathan Rosenberg wrote: > >> This whole argument is based on the model that a new method is >> somehow a big change in SIP, whereas a new body is a small one. Why >> is that? >> > > because it is true? > > The bodies are normally processed in code external to the SIP stack, > whereas methods are processed in the SIP stack itself. > > Again, I'd like to resort to "HTTP as a model". It's not incredibly > clean, but it has had some successes. > > Even with Netscape Navigator version 1.0, we could define "helper > applications" for different body types. Using this technique, a browser > could deliver content with any arbitrary MIME type to the right > application without changing the browser code in any way. > > The content doesn't change the function of HTTP, which is still doing > the same old "get" and "put" and "post" operations. This is because HTTP has a much cleaner separation between HTTP and the application that sits ontop of it. HTTP merely passes content, and the thing ontop 'renders' it. SIP doesn't have such a clean notion of an 'application' that sits ontop of SIP. Data that, for one implementation, looks like 'applciation data', might be processed by the 'core sip stack' on the other end. Thats because SIP is meant to address a specific application itself - interactive communications. Markus Isomaki wrote: > Another thing is that based on my practical experience, many deployed SIP networks indeed block the methods they do not know or care about, even such things like SUBSCRIBEs. (And these are not even IMS based.) So, reuse of the old methods may be preferred in those cases. well, nothing in the specs say you should do that. In fact, they say quite the opposite. So who is to say that, once we define INFO usages, those same networks just won't block everything except for the SIP-T ISUP porting usage we have today, for the same reason they block new methods? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 23 17:10:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftstn-0007s5-HE; Fri, 23 Jun 2006 17:09:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftstl-0007qL-Vc for sip@ietf.org; Fri, 23 Jun 2006 17:09:05 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftstk-00050U-Lj for sip@ietf.org; Fri, 23 Jun 2006 17:09:05 -0400 Received: from [192.168.1.2] (65-65-155-30.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5NLAZlR008597 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 23 Jun 2006 16:10:36 -0500 Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Fri, 23 Jun 2006 16:08:58 -0500 To: IETF SIP List X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Rohan Mahy , Keith Drage Subject: [Sip] Anybody feeling a connection with "connect 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: , Errors-To: sip-bounces@ietf.org We've been following the connection reuse draft, currently draft-ietf- sip-connect-reuse-05.txt, for a long long time. We've slipped the charter delivery date several times. Are we ever going to finish this work? Do we need to finish this work? Is this something that we could just not do? Otherwise said: "Does the SIP working group still have a consensus to expend working group effort on connection reuse?" If you have an opinion, for or against, please let it be known on this list. Thanks, -- Dean, as chairmonkey _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 23 17:14:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftsxf-0000n8-Qv; Fri, 23 Jun 2006 17:13:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftsxe-0000n3-Fm for sip@ietf.org; Fri, 23 Jun 2006 17:13:06 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftsxd-0005K3-5W for sip@ietf.org; Fri, 23 Jun 2006 17:13:06 -0400 Received: from [192.168.1.2] (65-65-155-30.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5NLEd5d008627 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 23 Jun 2006 16:14:39 -0500 In-Reply-To: <449C34A8.30701@cisco.com> References: <20060621212403.47032.qmail@web36406.mail.mud.yahoo.com> <449AD6FB.4030402@cisco.com> <6A371E14-EAB1-46A6-A253-60BA8EC3AA39@softarmor.com> <449B1610.8080602@cisco.com> <449BEE32.1090400@cisco.com> <327E8A68-4826-48CE-B160-6F49A613A7C4@softarmor.com> <449C34A8.30701@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Additional uses of INFO Date: Fri, 23 Jun 2006 16:13:02 -0500 To: Michael Thomas X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 23, 2006, at 1:36 PM, Michael Thomas wrote: > > Sorry if I'm being dense here, but aren't these all sessions that > run over SIP itself? > I was curious if there was anything else that was establishing > sessions via SIP like > SDP/RTP -- ie, where SIP, um, initiated it but otherwise mostly > gets out of the way. Well, MRSP is sort of like "SDP/MRSP" -- it's the text-conferencing protocol, used for texting much like rtp is used for speech (although there's anotehr thing, real-time-text over rtp, that sometimes pops up). So SIP is used to establish correspondence and media agreement to set up a media session where that media session is sent in MSRP. There's also some work ongoing with SIP/RTSP, primarily around IPTV but also for surveillance. -- 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 Jun 23 17:15:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtsyJ-0001t2-Pe; Fri, 23 Jun 2006 17:13:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtsyI-0001ng-5W for sip@ietf.org; Fri, 23 Jun 2006 17:13:46 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtsyG-0005OA-RJ for sip@ietf.org; Fri, 23 Jun 2006 17:13:46 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k5NLDfq11535; Fri, 23 Jun 2006 17:13:41 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Anybody feeling a connection with "connect reuse"? Date: Fri, 23 Jun 2006 16:13:39 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60CDC3DA6@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Anybody feeling a connection with "connect reuse"? Thread-Index: AcaXCZNF4kUb+biESFu+ju155vllAgAACJkA From: "Samir Srivastava" To: "Dean Willis" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Rohan Mahy , Keith Drage X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org As per my earlier postings regarding security, we need connect-reuse think of TLS e2e and cost of TLS setup. Samir=20 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Friday, June 23, 2006 2:09 PM To: IETF SIP List Cc: Rohan Mahy; Keith Drage Subject: [Sip] Anybody feeling a connection with "connect reuse"? We've been following the connection reuse draft, currently draft-ietf- sip-connect-reuse-05.txt, for a long long time. We've slipped the charter delivery date several times. Are we ever going to finish this work? Do we need to finish this work? Is this something that we could just not do? Otherwise said: "Does the SIP working group still have a consensus to expend working group effort on connection reuse?" If you have an opinion, for or against, please let it be known on this list. Thanks, -- Dean, as chairmonkey _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 23 17:35:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FttHy-0001Sy-DL; Fri, 23 Jun 2006 17:34:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FttGA-0000VA-Ms for sip@ietf.org; Fri, 23 Jun 2006 17:32:14 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FttEK-0002ZU-Q4 for sip@ietf.org; Fri, 23 Jun 2006 17:30:20 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FttEH-0002Ne-27 for sip@ietf.org; Fri, 23 Jun 2006 17:30:20 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.6/IER-o) with ESMTP id k5NLUCqe019972; Fri, 23 Jun 2006 16:30:12 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k5NLU8T26909; Fri, 23 Jun 2006 16:30:08 -0500 (CDT) Message-ID: <449C5D60.1060108@lucent.com> Date: Fri, 23 Jun 2006 16:30:08 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Anybody feeling a connection with "connect reuse"? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: IETF SIP List , Rohan Mahy , Keith Drage X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > We've been following the connection reuse draft, currently draft-ietf- > sip-connect-reuse-05.txt, for a long long time. > > We've slipped the charter delivery date several times. > > Are we ever going to finish this work? Do we need to finish this work? > > Is this something that we could just not do? > > Otherwise said: "Does the SIP working group still have a consensus to > expend working group effort on connection reuse?" > > If you have an opinion, for or against, please let it be known on this > list. Dean: I was about to get the chairs connected in after the -0N date, but here goes ... Current status: blocked on some text on how to handle certs and virtual SIP/TLS servers. There are some open issues on virtual hosting (see http://www3.ietf.org/proceedings/06mar/slides/sip-6.pdf). I am gathering some thoughts on the contents of certificates for virtual SIP servers in gurbani-sip-domain-certs draft (which is furiously being updated for the Monday deadline). Pending some discussion on this, the connect-reuse draft will be rev'd. Who cares: 1) well ... at least the authors of the draft care, having spent considerable cycles in it. 2) And it seems that others care as well -- at the last SIPit (April 2006), there were six implementations. Can you please be so kind as to grant it a reprieve? Thanks. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 23 17:44:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FttQP-0005rq-Vi; Fri, 23 Jun 2006 17:42:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FttQO-0005rk-Q8 for sip@ietf.org; Fri, 23 Jun 2006 17:42:48 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FttQN-0006t8-DM for sip@ietf.org; Fri, 23 Jun 2006 17:42:48 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k5NLggrw028260; Fri, 23 Jun 2006 15:42:42 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Anybody feeling a connection with "connect reuse"? Date: Fri, 23 Jun 2006 15:42:42 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Anybody feeling a connection with "connect reuse"? Thread-Index: AcaXDMeDs/tMpAQ7T1a4ytXbYD9p7AAAPrdA From: "Steve Dotson" To: "Vijay K. Gurbani" , "Dean Willis" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: IETF SIP List , Rohan Mahy , Keith Drage X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean/Vijay, CableLabs would like to see this work continued/finished. Thanks. Steve.=20 -----Original Message----- From: Vijay K. Gurbani [mailto:vkg@lucent.com]=20 Sent: Friday, June 23, 2006 3:30 PM To: Dean Willis Cc: IETF SIP List; Rohan Mahy; Keith Drage Subject: Re: [Sip] Anybody feeling a connection with "connect reuse"? Dean Willis wrote: >=20 > We've been following the connection reuse draft, currently draft-ietf- > sip-connect-reuse-05.txt, for a long long time. >=20 > We've slipped the charter delivery date several times. >=20 > Are we ever going to finish this work? Do we need to finish this work? >=20 > Is this something that we could just not do? >=20 > Otherwise said: "Does the SIP working group still have a consensus to=20 > expend working group effort on connection reuse?" >=20 > If you have an opinion, for or against, please let it be known on =20 > this list. Dean: I was about to get the chairs connected in after the -0N date, but here goes ... Current status: blocked on some text on how to handle certs and virtual SIP/TLS servers. There are some open issues on virtual hosting (see http://www3.ietf.org/proceedings/06mar/slides/sip-6.pdf). I am gathering some thoughts on the contents of certificates for virtual SIP servers in gurbani-sip-domain-certs draft (which is furiously being updated for the Monday deadline). Pending some discussion on this, the connect-reuse draft will be rev'd. Who cares: 1) well ... at least the authors of the draft care, having spent considerable cycles in it. 2) And it seems that others care as well -- at the last SIPit (April 2006), there were six implementations. Can you please be so kind as to grant it a reprieve? Thanks. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 23 22:02:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtxSC-0002gV-4G; Fri, 23 Jun 2006 22:00:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtxSA-0002g5-Ex for sip@ietf.org; Fri, 23 Jun 2006 22:00:54 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtxS9-0008My-5a for sip@ietf.org; Fri, 23 Jun 2006 22:00:54 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k5O1tPX08339; Fri, 23 Jun 2006 21:55:25 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Anybody feeling a connection with "connect reuse"? Date: Fri, 23 Jun 2006 21:00:47 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0ADD39C6@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Anybody feeling a connection with "connect reuse"? Thread-Index: AcaXCVUkSGjLsPCoTl2TEcHgCEYMWgAKHllA From: "Francois Audet" To: "Dean Willis" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Rohan Mahy , Keith Drage X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Personally, I think it should just be folded back into the SIP outbound draft. (Not necessarily the whole content, but the technical content that makes sense to use with SIP outbound). > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Friday, June 23, 2006 14:09 > To: IETF SIP List > Cc: Rohan Mahy; Keith Drage > Subject: [Sip] Anybody feeling a connection with "connect reuse"? >=20 >=20 >=20 > We've been following the connection reuse draft, currently=20 > draft-ietf-=20 > sip-connect-reuse-05.txt, for a long long time. >=20 > We've slipped the charter delivery date several times. >=20 > Are we ever going to finish this work? Do we need to finish this work? >=20 > Is this something that we could just not do? >=20 >=20 > Otherwise said: "Does the SIP working group still have a=20 > consensus to =20 > expend working group effort on connection reuse?" >=20 > If you have an opinion, for or against, please let it be known on =20 > this list. >=20 > Thanks, >=20 > -- > Dean, as chairmonkey >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sipping@ietf.org for new developments on the=20 > application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jun 24 04:27:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu3SP-0000h2-Ps; Sat, 24 Jun 2006 04:25:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu3SO-0000bK-II for sip@ietf.org; Sat, 24 Jun 2006 04:25:32 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fu3SB-0001iT-Qg for sip@ietf.org; Sat, 24 Jun 2006 04:25:32 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1C00HGEVF9J5@szxga01-in.huawei.com> for sip@ietf.org; Sat, 24 Jun 2006 16:25:57 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1C00FG2VF80P@szxga01-in.huawei.com> for sip@ietf.org; Sat, 24 Jun 2006 16:25:57 +0800 (CST) Received: from z13645a ([10.70.145.105]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1C002R4VF3L6@szxml03-in.huawei.com> for sip@ietf.org; Sat, 24 Jun 2006 16:25:55 +0800 (CST) Date: Sat, 24 Jun 2006 16:24:05 +0800 From: Lavis Zhou To: 'IETF SIP List' Message-id: <004701c69767$90981730$6991460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcaXZ45xIuYjArnAQEGxON2ox8130Q== X-Spam-Score: 0.0 (/) X-Scan-Signature: 1c0c3d540ad9f95212b1c2a9a2cc2595 Cc: ruixing@huawei.com, hellen@huawei.com Subject: [Sip] provide a hint to update the From header to Caller (draft-ietf-sip-connected-identity-00.txt) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1214878722==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1214878722== Content-type: multipart/alternative; boundary="Boundary_(ID_8DJpbCCh2Yto3/CvB2FC7w)" This is a multi-part message in MIME format. --Boundary_(ID_8DJpbCCh2Yto3/CvB2FC7w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Is it better to provide a hint to caller that the callee had changed the >From header of UPDATE by putting a Require: id-change in UPDATE message? So it will be easy for caller to handle this UPDATE other than it have to check the From header if it had been changed for every request? I am not sure it had been discussed, but in my going through of the mailing list, it had not. Rgds, Lavis **************************************************************************** *********** This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! **************************************************************************** *********** --Boundary_(ID_8DJpbCCh2Yto3/CvB2FC7w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

Is it better to provide a hint to caller that the callee had changed the From header of UPDATE by putting a Require: id-change in UPDATE message? So it will be easy for caller to handle this UPDATE other than it have to check the From header if it had been changed for every request?

 

I am not sure it had been discussed, but in my going through of the mailing list, it had not.

Rgds,

Lavis

 

***************************************************************************************
This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
***************************************************************************************

 

--Boundary_(ID_8DJpbCCh2Yto3/CvB2FC7w)-- --===============1214878722== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1214878722==-- From sip-bounces@ietf.org Sat Jun 24 13:00:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuBSs-0000Cv-Fz; Sat, 24 Jun 2006 12:58:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuBSq-0000BA-U1 for sip@ietf.org; Sat, 24 Jun 2006 12:58:32 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuBSp-0008J4-K5 for sip@ietf.org; Sat, 24 Jun 2006 12:58:32 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0J1D00F01J5U9S@siemenscomms.co.uk> for sip@ietf.org; Sat, 24 Jun 2006 17:58:42 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J1D00A80J5U9V@siemenscomms.co.uk>; Sat, 24 Jun 2006 17:58:42 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Sat, 24 Jun 2006 17:58:16 +0100 Content-return: allowed Date: Sat, 24 Jun 2006 17:57:59 +0100 From: "Elwell, John" Subject: RE: [Sip] Anybody feeling a connection with "connect reuse"? To: Dean Willis , IETF SIP List Message-id: <50B1CBA96870A34799A506B2313F2667093AD1C8@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Rohan Mahy , Keith Drage X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yep, I would like to see it completed. John > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 23 June 2006 22:09 > To: IETF SIP List > Cc: Rohan Mahy; Keith Drage > Subject: [Sip] Anybody feeling a connection with "connect reuse"? > > > We've been following the connection reuse draft, currently > draft-ietf- > sip-connect-reuse-05.txt, for a long long time. > > We've slipped the charter delivery date several times. > > Are we ever going to finish this work? Do we need to finish this work? > > Is this something that we could just not do? > > > Otherwise said: "Does the SIP working group still have a > consensus to > expend working group effort on connection reuse?" > > If you have an opinion, for or against, please let it be known on > this list. > > Thanks, > > -- > Dean, as chairmonkey > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 24 13:18:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuBk0-0004Ot-21; Sat, 24 Jun 2006 13:16:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuBjy-0004Oo-QI for sip@ietf.org; Sat, 24 Jun 2006 13:16:14 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuBjy-0001nS-6r for sip@ietf.org; Sat, 24 Jun 2006 13:16:14 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0J1D00J01JZPFM@siemenscomms.co.uk> for sip@ietf.org; Sat, 24 Jun 2006 18:16:37 +0100 (BST) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J1D00G18JMXNZ@siemenscomms.co.uk>; Sat, 24 Jun 2006 18:08:57 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Sat, 24 Jun 2006 18:08:32 +0100 Content-return: allowed Date: Sat, 24 Jun 2006 18:07:46 +0100 From: "Elwell, John" Subject: RE: [Sip] provide a hint to update the From header to Caller (dra ft-ietf-sip-connected-identity-00.txt) To: Lavis Zhou , 'IETF SIP List' Message-id: <50B1CBA96870A34799A506B2313F2667093AD1C9@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad Cc: ruixing@huawei.com, hellen@huawei.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="===============1834884223==" Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1834884223== Content-return: allowed Content-type: multipart/alternative; boundary="Boundary_(ID_BV8Gl23IKzPVMo7CJwArbw)" 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. --Boundary_(ID_BV8Gl23IKzPVMo7CJwArbw) Content-type: text/plain Content-transfer-encoding: 7BIT Lavis, An UPDATE request with a changed From header field URI will be sent only if the peer UA has already indicated id-change in a Supported header field, so inclusion of a Require header field would appear to be redundant (from the point of view of the normal meaning of Require). Your proposal seems to give a different semantic to Require, i.e., a hint to the peer UA as to what is significant about this particular UPDATE request. I don't think it is a good idea to modify the semantics of Require in this way. The identity change can easily be detected anyway by comparing the new and previous URIs. John _____ From: Lavis Zhou [mailto:lavis@huawei.com] Sent: 24 June 2006 09:24 To: 'IETF SIP List' Cc: ruixing@huawei.com; hellen@huawei.com Subject: [Sip] provide a hint to update the From header to Caller (draft-ietf-sip-connected-identity-00.txt) Hi, Is it better to provide a hint to caller that the callee had changed the >From header of UPDATE by putting a Require: id-change in UPDATE message? So it will be easy for caller to handle this UPDATE other than it have to check the From header if it had been changed for every request? I am not sure it had been discussed, but in my going through of the mailing list, it had not. Rgds, Lavis **************************************************************************** *********** This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! **************************************************************************** *********** --Boundary_(ID_BV8Gl23IKzPVMo7CJwArbw) Content-type: text/html Content-transfer-encoding: 7BIT
Lavis,
 
An UPDATE request with a changed From header field URI will be sent only if the peer UA has already indicated id-change in a Supported header field, so inclusion of a Require header field would appear to be redundant (from the point of view of the normal meaning of Require). Your proposal seems to give a different semantic to Require, i.e., a hint to the peer UA as to what is significant about this particular UPDATE request. I don't think it is a good idea to modify the semantics of Require in this way. The identity change can easily be detected anyway by comparing the new and previous URIs.
 
John

From: Lavis Zhou [mailto:lavis@huawei.com]
Sent: 24 June 2006 09:24
To: 'IETF SIP List'
Cc: ruixing@huawei.com; hellen@huawei.com
Subject: [Sip] provide a hint to update the From header to Caller (draft-ietf-sip-connected-identity-00.txt)

Hi,

Is it better to provide a hint to caller that the callee had changed the From header of UPDATE by putting a Require: id-change in UPDATE message? So it will be easy for caller to handle this UPDATE other than it have to check the From header if it had been changed for every request?

 

I am not sure it had been discussed, but in my going through of the mailing list, it had not.

Rgds,

Lavis

 

***************************************************************************************
This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
***************************************************************************************

 

--Boundary_(ID_BV8Gl23IKzPVMo7CJwArbw)-- --===============1834884223== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1834884223==-- From sip-bounces@ietf.org Sat Jun 24 13:51:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuCGT-0003MW-4F; Sat, 24 Jun 2006 13:49:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuCGQ-0003Is-Vf for sip@ietf.org; Sat, 24 Jun 2006 13:49:46 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuCGP-0004Bi-J5 for sip@ietf.org; Sat, 24 Jun 2006 13:49:46 -0400 Received: from [131.161.248.86] (open-131-161-248-86.cliq.com [131.161.248.86]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k5OHnfF21397; Sat, 24 Jun 2006 10:49:42 -0700 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0ADD39C6@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF0ADD39C6@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0acb5fddf07b3fd9c3abf4a33801888c@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Anybody feeling a connection with "connect reuse"? Date: Sat, 24 Jun 2006 10:49:47 -0700 To: "Francois Audet" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: IETF SIP List , Rohan Mahy , Keith Drage , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On behalf of Cullen and I (the current editors of outbound), please do not make us do that. thanks, -rohan On Jun 23, 2006, at 19:00, Francois Audet wrote: > Personally, I think it should just be folded back into the SIP outbound > draft. > > (Not necessarily the whole content, but the technical content that > makes > sense > to use with SIP outbound). > > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Friday, June 23, 2006 14:09 >> To: IETF SIP List >> Cc: Rohan Mahy; Keith Drage >> Subject: [Sip] Anybody feeling a connection with "connect reuse"? >> >> >> >> We've been following the connection reuse draft, currently >> draft-ietf- >> sip-connect-reuse-05.txt, for a long long time. >> >> We've slipped the charter delivery date several times. >> >> Are we ever going to finish this work? Do we need to finish this work? >> >> Is this something that we could just not do? >> >> >> Otherwise said: "Does the SIP working group still have a >> consensus to >> expend working group effort on connection reuse?" >> >> If you have an opinion, for or against, please let it be known on >> this list. >> >> Thanks, >> >> -- >> Dean, as chairmonkey >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current >> sip Use sipping@ietf.org for new developments on the >> application of sip >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 24 17:31:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuFgn-00017i-3l; Sat, 24 Jun 2006 17:29:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuFgk-00017d-Ln for sip@ietf.org; Sat, 24 Jun 2006 17:29:10 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuFgj-0006vK-GV for sip@ietf.org; Sat, 24 Jun 2006 17:29:10 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5OLT8Rw022387; Sat, 24 Jun 2006 21:29:08 GMT Received: from stntexch03.cis.neustar.com ([10.31.13.45]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Jun 2006 17:29:07 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Sip] New draft on coexistence of SIP identity and P-Asserted-ID Date: Sat, 24 Jun 2006 17:29:07 -0400 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD597054F44A0@stntexch03.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New draft on coexistence of SIP identity and P-Asserted-ID Thread-Index: AcaWXQapJ3aogzntTYelmnLQOja5tAArOzDA From: "Peterson, Jon" To: "Paul Kyzivat" X-OriginalArrivalTime: 24 Jun 2006 21:29:08.0056 (UTC) FILETIME=[39D27580:01C697D5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > P.S. Jon - if you insisted on 3324 as a prerequisite for 3325, then = why=20 > did you let them get away without a normative reference? RFC3324 is an Informational that doesn't contain any 2119 language. Back = then, we wouldn't have thought that RFC3324 could have been a normative = reference. Given the language in Section 1 of 3325 (especially the 2nd = paragraph), we would certainly cast it as a normative reference today. = The distinction between normative and informative references has never = been crystal-clear, and was even murkier a few years ago. 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 Sat Jun 24 18:20:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuGSk-0001y1-GS; Sat, 24 Jun 2006 18:18:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuGSj-0001v8-QT for sip@ietf.org; Sat, 24 Jun 2006 18:18:45 -0400 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuGKh-0002zp-SA for sip@ietf.org; Sat, 24 Jun 2006 18:10:29 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc14) with ESMTP id <2006062422102501400ar1i2e>; Sat, 24 Jun 2006 22:10:25 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k5OMAO5n011134 for ; Sat, 24 Jun 2006 18:10:24 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k5OMAOm6011130; Sat, 24 Jun 2006 18:10:24 -0400 Date: Sat, 24 Jun 2006 18:10:24 -0400 Message-Id: <200606242210.k5OMAOm6011130@dragon.ariadne.com> From: Dale.Worley@comcast.net To: sip@ietf.org In-reply-to: <20060623045434.90333.qmail@web8404.mail.in.yahoo.com> (kurupati11@yahoo.co.in) Subject: Re: [Sip] query on sip user name References: <20060623045434.90333.qmail@web8404.mail.in.yahoo.com> X-Spam-Score: 0.6 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: kiran kumar I need information on sip user name, i.e " -1 " is user name or not. The syntax for SIP user names is the production "user" in section 25.1 of RFC 3261. Assuming you mean the two-character sequence Hyphen- One, then that is a valid SIP user name, as you can easily see for yourself. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jun 24 18:22:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuGUa-0003fm-Ei; Sat, 24 Jun 2006 18:20:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuGSl-0001y0-2i for sip@ietf.org; Sat, 24 Jun 2006 18:18:47 -0400 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuGHp-0002w8-8u for sip@ietf.org; Sat, 24 Jun 2006 18:07:30 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc15) with ESMTP id <200606242207280150094vpme>; Sat, 24 Jun 2006 22:07:28 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k5OM7S5n011023 for ; Sat, 24 Jun 2006 18:07:28 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k5OM7SoU011019; Sat, 24 Jun 2006 18:07:28 -0400 Date: Sat, 24 Jun 2006 18:07:28 -0400 Message-Id: <200606242207.k5OM7SoU011019@dragon.ariadne.com> From: Dale.Worley@comcast.net To: sip@ietf.org In-reply-to: <74E6B44E-684D-4814-8278-C71069C976D0@softarmor.com> (dean.willis@softarmor.com) Subject: Re: [Sip] Additional uses of INFO References: <20060621212403.47032.qmail@web36406.mail.mud.yahoo.com> <200606220213.k5M2DP3q011828@dragon.ariadne.com> <74E6B44E-684D-4814-8278-C71069C976D0@softarmor.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Dean Willis Ah. You have there the tip of the INFO problem. We don't have a mechanism to answer this question, and if we were going to do anything BUT GTSN using INFO, we'd need to develop such a mechanism. Thus, two choices -- 1) block all further use of INFO, and 2) add a usage-negotiation mechanism to INFO, just as we did for SIP Events. OK, I'm starting to grasp your point: The question is not "Are there ways that one can implement a private extension that will be properly rejected/ignored by peers that do not implement the extension?" but rather, "What are guidelines for implementing private extensions so that they will be properly rejected/ignored by peers that do not implement the extension?" Which is not difficult to answer, *once people remember to ask it when defining an extension* -- see the mechanisms I enumerated in my previous message. But the IETF is very good at defining protocols that are astonishingly robust against extension... I don't foresee trouble if people lard all sorts of garbage into SIP, as long as they're reasonably careful. Content-type tells about what the content is. Content-disposition tells about what one is supposed to do with the content, and might be a better candidate for this sort of usage. Or perhaps a combination of the two. If I send you an image/jpeg during a call, what do you do with it? Display it? Add it to your phone book next to my name? Run a steganographic search on it to look for a hidden message? Ah, yes. But I note that you can define x-* Content-Dispositions as well. (RFC 2045 via RFC 2183 via RFC 3261!) For that matter, we should start getting people used to defining Content-Dispositions to describe the roles of message bodies. Might I suggest draft-ietf-sip-hop-limit-diagnostics-03, "Diagnostic Responses for Session Initiation Protocol Hop Limit Errors", as a good place to start? It proposes a message/sipfrag body to the 483 response that gives the contents of the failed request. There ought to be a Content-Disposition to explain the significance of that body. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jun 24 20:39:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuId1-0004jc-BM; Sat, 24 Jun 2006 20:37:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuIcz-0004jX-Ov for sip@ietf.org; Sat, 24 Jun 2006 20:37:29 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuIcy-0004rG-HR for sip@ietf.org; Sat, 24 Jun 2006 20:37:29 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 24 Jun 2006 17:37:28 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,172,1149490800"; d="scan'208"; a="30415977:sNHT30257844" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5P0bSYL027048; Sat, 24 Jun 2006 20:37:28 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 24 Jun 2006 20:37:27 -0400 Received: from [10.82.224.187] ([10.82.224.187]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 24 Jun 2006 20:37:27 -0400 Message-ID: <449DDAC6.7030408@cisco.com> Date: Sat, 24 Jun 2006 20:37:26 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [Sip] Additional uses of INFO References: <20060621212403.47032.qmail@web36406.mail.mud.yahoo.com> <200606220213.k5M2DP3q011828@dragon.ariadne.com> <74E6B44E-684D-4814-8278-C71069C976D0@softarmor.com> <200606242207.k5OM7SoU011019@dragon.ariadne.com> In-Reply-To: <200606242207.k5OM7SoU011019@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2006 00:37:27.0403 (UTC) FILETIME=[88C1FBB0:01C697EF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dale.Worley@comcast.net wrote: > Content-type tells about what the content is. Content-disposition > tells about what one is supposed to do with the content, and might be > a better candidate for this sort of usage. Or perhaps a combination > of the two. > > If I send you an image/jpeg during a call, what do you do with it? > Display it? Add it to your phone book next to my name? Run a > steganographic search on it to look for a hidden message? > > Ah, yes. But I note that you can define x-* Content-Dispositions as > well. (RFC 2045 via RFC 2183 via RFC 3261!) > > For that matter, we should start getting people used to defining > Content-Dispositions to describe the roles of message bodies. Might I > suggest draft-ietf-sip-hop-limit-diagnostics-03, "Diagnostic Responses > for Session Initiation Protocol Hop Limit Errors", as a good place to > start? It proposes a message/sipfrag body to the 483 response that > gives the contents of the failed request. There ought to be a > Content-Disposition to explain the significance of that body. I agree there is a lot of potential in Content-Disposition. But it suffers from a lack of clear specification about how it is to be used. I have a strong suspicion that most UAs totally ignore Content-Disposition. Question: If you send an INVITE containing an SDP body with Content-Disposition:render, how many will think it is an offer? It would be a good thing to start using this for more in order to motivate support. But it will take awhile before it starts working widely. Starting by using it in something like INFO (rathere than INVITE) is probably a good baby step in that direction. 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 Sun Jun 25 07:53:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuT92-0001mr-Rw; Sun, 25 Jun 2006 07:51:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuT91-0001mk-0y for sip@ietf.org; Sun, 25 Jun 2006 07:51:15 -0400 Received: from smtpout09-04.prod.mesa1.secureserver.net ([64.202.165.17]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FuT8y-0005c5-Iv for sip@ietf.org; Sun, 25 Jun 2006 07:51:15 -0400 Received: (qmail 20161 invoked from network); 25 Jun 2006 11:51:11 -0000 Received: from unknown (69.173.130.247) by smtpout09-04.prod.mesa1.secureserver.net (64.202.165.17) with ESMTP; 25 Jun 2006 11:51:10 -0000 From: "Rajnish Jain" To: "'Dean Willis'" , "'IETF SIP List'" Subject: RE: [Sip] Anybody feeling a connection with "connect reuse"? Date: Sun, 25 Jun 2006 07:51:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaXCYR+Fl5faPcyTZKgf+Ue2tbxgABQ/67A X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: 'Rohan Mahy' , 'Keith Drage' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Message-Id: I'd like to see this work completed. Thanks, Rajnish -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Friday, June 23, 2006 5:09 PM To: IETF SIP List Cc: Rohan Mahy; Keith Drage Subject: [Sip] Anybody feeling a connection with "connect reuse"? We've been following the connection reuse draft, currently draft-ietf- sip-connect-reuse-05.txt, for a long long time. We've slipped the charter delivery date several times. Are we ever going to finish this work? Do we need to finish this work? Is this something that we could just not do? Otherwise said: "Does the SIP working group still have a consensus to expend working group effort on connection reuse?" If you have an opinion, for or against, please let it be known on this list. Thanks, -- Dean, as chairmonkey _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 25 08:44:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuTxF-00021I-Q9; Sun, 25 Jun 2006 08:43:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuTxE-00021D-FA for sip@ietf.org; Sun, 25 Jun 2006 08:43:08 -0400 Received: from jaguar.hughesbpo.net ([61.246.186.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuTwx-0000Hb-Ho for sip@ietf.org; Sun, 25 Jun 2006 08:43:08 -0400 Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by jaguar.hughesbpo.net (8.13.6/8.13.6) with ESMTP id k5PCgoEC004419 for ; Sun, 25 Jun 2006 18:12:50 +0530 Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id k5PChfA20704; Sun, 25 Jun 2006 18:13:42 +0530 (IST) Importance: Normal X-Priority: 3 (Normal) Subject: Re: [Sip] timer after 200 OK sent in response to BYE MIME-Version: 1.0 From: Rayees Khan To: neeraj gupta Date: Sun, 25 Jun 2006 18:12:39 +0530 Message-ID: X-MIMETrack: Serialize by Notes Server on Zarf/HSS(Release 6.5.1|January 21, 2004) at 06/25/2006 06:12:39 PM, Serialize complete at 06/25/2006 06:12:39 PM, Itemize by Notes Server on Zarf/HSS(Release 6.5.1|January 21, 2004) at 06/25/2006 06:12:39 PM, Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 25/06/2006 06:12:40 PM, Serialize complete at 25/06/2006 06:12:40 PM MIME-Version: 1.0 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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="===============2069478043==" Errors-To: sip-bounces@ietf.org --===============2069478043== Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Hi Neeraj,

The description is not clear. Is the 200 for CAN= CEL or INVITE?
Since UAC has not recieved final response a BYE cannont b= e generated and UAS has to generate a final response for INVITE transaction= as well.


regards
Rayees


-----neeraj gupta <ngupta94@yahoo.com> wrote: -----

To: sip@ietf= .org
From: neeraj gupta <ngupta94@yahoo.com>
Date: 06/23/2006 0= 5:24PM
Subject: [Sip] timer after 200 OK sent in response to BYE

= Hello all

I have a question about the timers in the following si= tuation

Client        &nb= sp;            =             &nb= sp;            =             &nb= sp;        Server
------------------= -------->     INVITE     &n= bsp;            = ;    ------------------------------>
<------------= ------------       100 Trying  &nbs= p;            &= nbsp; <------------------------------
<------------------------&n= bsp;      180 ringing     = ;           <---------= ----------------------
-------------------------->   =   Cancel/Bye         &nbs= p;     -------------------------------->
<---= ----------------------      200 OK  &nbs= p;            &= nbsp;     <-------------------------------

= After sending the 200 OK, does the server start a timer (Timer J).  = If yes, why is that so.  What is the server waiting for ?  I see = this behaviour in a user agent.

Thanks

Neeraj =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F
Sip mailing list  https://www1.ietf.org/mailman/listinfo/si= p
This list is for NEW development of the core SIP Protocol
Use s= ip-implementors@cs.columbia.edu for questions on current sip
Use sipping= @ietf.org for new developments on the application of sip

*****FSS-Private *****" DISCLAIMER: This message is proprietary to= Flextronics Software Systems Limited (FSS) and is intended solely for the = use of the individual to whom it is addressed. It may contain privileged o= r confidential information and should not be circulated or used for any pur= pose other than for what it is intended. If you have received this message = in error, please notify the originator immediately. If you are not the = intended recipient, you are notified that you are strictly prohibited f= rom using, copying, altering, or disclosing the contents of thi= s message. FSS accepts no responsibility for loss or damage arising from th= e use of the information transmitted by this email including damage from vi= rus."
= --===============2069478043== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2069478043==-- From sip-bounces@ietf.org Sun Jun 25 10:47:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuVsD-00015b-1w; Sun, 25 Jun 2006 10:46:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuVsB-000146-GS for sip@ietf.org; Sun, 25 Jun 2006 10:46:03 -0400 Received: from [2001:5c0:8fff:fffe::4c49] (helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuVs9-00021F-RL for sip@ietf.org; Sun, 25 Jun 2006 10:46:03 -0400 Received: from [192.168.1.102] (cpe-66-25-19-139.houston.res.rr.com [66.25.19.139]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k5PEjv2w007067 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 25 Jun 2006 09:45:59 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2909C853-8604-4A69-A21A-A9D8D6098BC1@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Sun, 25 Jun 2006 10:45:56 -0400 To: IETF SIP List X-Mailer: Apple Mail (2.750) Received-SPF: pass (nostrum.com: 66.25.19.139 is authenticated by a trusted mechanism) X-Spam-Score: 1.8 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Cullen Jennings , "Vijay K. Gurbani" Subject: [Sip] sec-flows-01 submitted X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org An update to the security flows document has been submitted. Until it appears in the repository, you can find it at http://www.nostrum.com/~rjsparks/draft-ietf-sip-sec-flows-01.txt Here's a copy of the change log: -00 to -01 * Incorporated the Test cases from Vijay Gurbani's and Alan Jeffrey's Use of TLS in SIP draft * Began to capture the folklore around where identities are carried in certificates for use with SIP * Removed the message dump archive pending verification (will return in -02) In particular, please read and comment on the section capturing current folklore. I am well on the way to automating the creation of the message signatures and dumps in this draft, but there are a few wrinkles to iron out still, so I have not made the changes to, for example, the Accept header fields in the example messages yet. 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 Sun Jun 25 10:53:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuVxv-0005x7-SM; Sun, 25 Jun 2006 10:51:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuVxu-0005x1-Bj for sip@ietf.org; Sun, 25 Jun 2006 10:51:58 -0400 Received: from [2001:5c0:8fff:fffe::4c49] (helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuVxr-0002qZ-UH for sip@ietf.org; Sun, 25 Jun 2006 10:51:58 -0400 Received: from [192.168.1.102] (cpe-66-25-19-139.houston.res.rr.com [66.25.19.139]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k5PEprDY007585 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Sun, 25 Jun 2006 09:51:54 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF SIP List From: Robert Sparks Date: Sun, 25 Jun 2006 10:51:52 -0400 X-Mailer: Apple Mail (2.750) Received-SPF: pass (nostrum.com: 66.25.19.139 is authenticated by a trusted mechanism) X-Spam-Score: 1.8 (+) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Sip] Update to fork-loop-fix submitted X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Until it appears in the repository, see: http://www.nostrum.com/~rjsparks/draft-ietf-sip-fork-loop-fix-02.txt This was a moderately heavy touch - based on list feedback, I've moved and updated the sections covering the loopdetection algorithm in from 3261. In the process of writing the clarifying text, I discovered several places that need clarification. They are listed as Open Issues in the draft. Basically there are fields that I can't recall or reconstruct how they would be useful in the part of the hash used for loop-detection or spiral differentiation. If anyone can remember why they need to be included, send a note to the list and we'll capture that in the draft. Please review the updated loop-detection text very carefully. Here's the changelog from the draft: Integrated several editorial fixes suggested by Jonathan Rosenberg Noted that the reduction of the attack to a single registration against a single URI as documented in previous versions, is, in fact, going to be effective against implementations conforming to the standards before this repair. Re-incorporated motivation from the original maxforwards-problem draft into the security considerations section based on feedback from Cullen Jennings Introduced replacement text for the loop detection algorithm description in RFC 3261, fixing the bug 648 (the topmost Via value must not be included in the second part) and clarifying the algorithm. Removed several other fields suggested by 3261 and placed open issues around their presence. Added a Notes to Implementors section capturing the "common way" text and pointing to the interoperability issues that have been observed with loop detection at previous SIPits 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 Sun Jun 25 11:00:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuW4R-0005qi-Ay; Sun, 25 Jun 2006 10:58:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuW4P-0005qd-8p for sip@ietf.org; Sun, 25 Jun 2006 10:58:41 -0400 Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuW4N-0003YD-V4 for sip@ietf.org; Sun, 25 Jun 2006 10:58:41 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 58EF91FB3AB for ; Sun, 25 Jun 2006 16:58:39 +0200 (CEST) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 17942-01-21 for ; Sun, 25 Jun 2006 16:58:39 +0200 (CEST) Received: from [192.168.1.2] (155-54-253-72.adsl.um.es [155.54.253.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.um.es (Postfix) with ESMTP id 15C081FB388 for ; Sun, 25 Jun 2006 16:58:39 +0200 (CEST) Message-ID: <449EA4A4.2050300@dif.um.es> Date: Sun, 25 Jun 2006 16:58:44 +0200 From: =?ISO-8859-1?Q?=22Antonio_F=2E_G=F3mez_Skarmeta=22?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: es-es, es MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Sip] (sin asunto) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org unsubscribe erfoxe address=3Dskarmeta@dif.um.es --=20 ------------------------------------------------------------ Antonio F. G=F3mez Skarmeta Dept. Ingenier=EDa de la Informaci=F3n y las Comunicaciones Facultad de Inform=E1tica Universidad de Murcia Apartado 4021 30001 Murcia Telf: +34-968-364607 fax: +34-968-364151 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 25 11:04:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuW8O-0000sH-Lc; Sun, 25 Jun 2006 11:02:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuW8M-0000sC-VG for sip@ietf.org; Sun, 25 Jun 2006 11:02:46 -0400 Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuW8L-0003ks-LC for sip@ietf.org; Sun, 25 Jun 2006 11:02:46 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 0F0B423DE23 for ; Sun, 25 Jun 2006 17:02:45 +0200 (CEST) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 26256-01-65 for ; Sun, 25 Jun 2006 17:02:44 +0200 (CEST) Received: from [192.168.1.2] (155-54-253-72.adsl.um.es [155.54.253.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.um.es (Postfix) with ESMTP id ADCA723DE16 for ; Sun, 25 Jun 2006 17:02:44 +0200 (CEST) Message-ID: <449EA59A.30708@dif.um.es> Date: Sun, 25 Jun 2006 17:02:50 +0200 From: =?ISO-8859-1?Q?=22Antonio_F=2E_G=F3mez_Skarmeta=22?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: es-es, es MIME-Version: 1.0 To: sip@ietf.org Subject: Re: [Sip] (sin asunto) References: <449EA4A4.2050300@dif.um.es> In-Reply-To: <449EA4A4.2050300@dif.um.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Antonio F. G=F3mez Skarmeta escribi=F3: =20 Sorry for the "digital" error :-( --=20 ------------------------------------------------------------ Antonio F. G=F3mez Skarmeta Dept. Ingenier=EDa de la Informaci=F3n y las Comunicaciones Facultad de Inform=E1tica Universidad de Murcia Apartado 4021 30001 Murcia Telf: +34-968-364607 fax: +34-968-364151 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 25 12:04:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuX3v-0006dJ-8E; Sun, 25 Jun 2006 12:02:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuX3u-0006dE-FL for sip@ietf.org; Sun, 25 Jun 2006 12:02:14 -0400 Received: from sccrmhc12.comcast.net ([204.127.200.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuX3t-00012f-9E for sip@ietf.org; Sun, 25 Jun 2006 12:02:14 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc12) with ESMTP id <2006062516021201200ke4fpe>; Sun, 25 Jun 2006 16:02:12 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k5PG2C5n014310 for ; Sun, 25 Jun 2006 12:02:12 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k5PG2C3h014306; Sun, 25 Jun 2006 12:02:12 -0400 Date: Sun, 25 Jun 2006 12:02:12 -0400 Message-Id: <200606251602.k5PG2C3h014306@dragon.ariadne.com> From: Dale.Worley@comcast.net To: sip@ietf.org In-reply-to: <20060621162705419.00000000656@jrogde-se> (jan.rogde@oracle.com) Subject: Re: [Sip] outbound i-d update? References: <20060621162705419.00000000656@jrogde-se> X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: =?iso-8859-1?B?IkphbiBS9mdkZSI=?= Yes, but the idea is to handle a fail-over scenario. If it record-route with its own IP-address, in-dialog requests will fail if that proxy goes down. If it record-route with a domain-name as in the example, in-dialog requests could end up at any working proxy and then UA would need a connection to ALL the proxies for the domain-name. But on the list you all seem to agree that a fixed number (min 2 connections) is enough. Without sip-outbound, the best practice seems to be for the proxy to use for the record-route a domain name that routes preferentially to the proxy, and secondarily to its clones. So as long as that proxy is available, requests will go through it, but if it fails, requests can go through any clone proxy. It seems that for the best effect, we want a rule that if RFC 3263 turns up a set of destinations with equal desirability, the agent should prefer any with which it already has established flows. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 25 12:40:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuXcy-0003ew-70; Sun, 25 Jun 2006 12:38:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuXcw-0003er-OS for sip@ietf.org; Sun, 25 Jun 2006 12:38:26 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuXcv-0002SM-AB for sip@ietf.org; Sun, 25 Jun 2006 12:38:26 -0400 Received: (qmail 25988 invoked by uid 0); 25 Jun 2006 16:38:23 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 25 Jun 2006 16:38:23 -0000 Message-ID: <003901c69875$c2400950$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: , References: <20060621162705419.00000000656@jrogde-se> <200606251602.k5PG2C3h014306@dragon.ariadne.com> Subject: Re: [Sip] outbound i-d update? Date: Sun, 25 Jun 2006 18:38:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org What I miss in these discussions is a distinction in fail-over scenarios: 1) reboot of some proxy 2) reboot of the registrar In particular the latter case (2) is where outbound with 2 flows would help, especially when edge proxies are used. Currently, for a direct connection with the registrar a UAC could detect a reboot by keeping a TCP connection up. When using an edge proxy, the UAC would not detect that its registration was lost. A second backup registration would keep the UAC reachable; when receiving a request over the second flow, the UAC should probably verify if the first flow is still up (end-to-end, not only the connection to the edge proxy) For this to work, it must be guaranteed that the two REGISTERs end up at 2 distinct registrar machines - I still miss how that is to be achieved, in particular when edge proxies are in between For case (1), in-dialog requests for dialogs which the proxy record-routed using its IP address need not fail, as long as any state the proxy needs is stored in a way that survives reboots Regards, Jeroen ----- Original Message ----- From: To: Sent: Sunday, June 25, 2006 6:02 PM Subject: Re: [Sip] outbound i-d update? > From: =?iso-8859-1?B?IkphbiBS9mdkZSI=?= > > Yes, but the idea is to handle a fail-over scenario. > > If it record-route with its own IP-address, in-dialog requests will > fail if that proxy goes down. If it record-route with a domain-name > as in the example, in-dialog requests could end up at any working > proxy and then UA would need a connection to ALL the proxies for > the domain-name. But on the list you all seem to agree that a fixed > number (min 2 connections) is enough. > > Without sip-outbound, the best practice seems to be for the proxy to > use for the record-route a domain name that routes preferentially to > the proxy, and secondarily to its clones. So as long as that proxy is > available, requests will go through it, but if it fails, requests can > go through any clone proxy. It seems that for the best effect, we > want a rule that if RFC 3263 turns up a set of destinations with equal > desirability, the agent should prefer any with which it already has > established flows. > > Dale > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 25 15:56:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuah2-0000w3-GY; Sun, 25 Jun 2006 15:54:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuah0-0000t2-Ev for sip@ietf.org; Sun, 25 Jun 2006 15:54:50 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuagz-0000Dt-1X for sip@ietf.org; Sun, 25 Jun 2006 15:54:50 -0400 Received: (qmail 15838 invoked by uid 0); 25 Jun 2006 19:54:42 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 25 Jun 2006 19:54:42 -0000 Message-ID: <008001c69891$3628ef10$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "IETF SIP List" , "Robert Sparks" References: Subject: Re: [Sip] Update to fork-loop-fix submitted Date: Sun, 25 Jun 2006 21:54:43 +0200 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.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > In the process of writing the clarifying text, I discovered > several places that need clarification. They are listed as Open Issues > in the draft. Basically there are fields that I can't recall or > reconstruct > how they would be useful in the part of the hash used for loop-detection > or spiral differentiation. If anyone can remember why they need to be > included, send a note to the list and we'll capture that in the draft. > Open issue 1: Route headers Consider a UA that forwards to proxy P1 using Route: P1; proxy P1 that forwards to P2 (using Route: P2), and then P2 using Route: P1, P3 This is not a loop; I think the rule should be 'all Route headers, excluding the ones pointing to the element itself' Open issue 2: Call-ID, To-tag, and From-tag and CSeq I think these can be safely excluded, as there are no valid scenarios in which some proxy would change them. However, in the rare case that a particular request causes a hash clash, a UAC should perhaps be enabled to retry the request using, say, CSeq+1. To enable this, CSeq number should be included (the UAC could not change any of the others for in-dialog requests) Open issue 3 : Proxy-Require and Proxy-Authorization Both of these can only be removed by proxies downstream, never added. If a request is first received with P-R and then without, in theory the routing decision could be different (but I don't know any existing extensions for which this would matter) For P-A, when it is removed it could be that a 407 response would be more appropriate than a 482. My proposal would be to move step 4 in RFC3261 section 16.3 to after current step 6. So: Proxy-Require check, then Proxy-Authorization check, then Loop Check. If this is done, then I think P-R and P-A can safely be excluded from the loop hash As I have remarked before: since a forking proxy is required to be transaction stateful, the loop check could include a lookup for a previous transaction using the branch of the Via that is found matching. Regards, Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 26 00:19:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuiXr-0003I4-KX; Mon, 26 Jun 2006 00:17:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuiXq-0003Fz-2d for sip@ietf.org; Mon, 26 Jun 2006 00:17:54 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuiXo-0004Zs-QM for sip@ietf.org; Mon, 26 Jun 2006 00:17:54 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail3.lucent.com (8.13.6/IER-o) with ESMTP id k5Q4Hq28017373; Sun, 25 Jun 2006 23:17:52 -0500 (CDT) Received: from [135.244.32.190] (tthach.lra2.lucent.com [135.244.32.190] (may be forged)) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k5Q4HoM22244; Sun, 25 Jun 2006 23:17:51 -0500 (CDT) Message-ID: <449F5FE8.30207@lucent.com> Date: Sun, 25 Jun 2006 23:17:44 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] Anybody feeling a connection with "connect reuse"? References: <1ECE0EB50388174790F9694F77522CCF0ADD39C6@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0ADD39C6@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois Audet wrote: > Personally, I think it should just be folded back into the SIP > outbound draft. > > (Not necessarily the whole content, but the technical content that > makes sense to use with SIP outbound). Francois: When the draft was rev'd from -04 to -05, we went through the expedient exercise of excising all outbound related content of connect-reuse to outbound (see http://www1.ietf.org/mail-archive/web/sip/current/msg12373.html) At this point in time, what remains in connect-reuse is text that is germane to connect-reuse and not outbound. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 26 01:06:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FujH8-0004XV-VE; Mon, 26 Jun 2006 01:04:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FujH7-0004XQ-Mm for sip@ietf.org; Mon, 26 Jun 2006 01:04:41 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FujH3-0006Nd-41 for sip@ietf.org; Mon, 26 Jun 2006 01:04:41 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1G0033WBSWFP@szxga03-in.huawei.com> for sip@ietf.org; Mon, 26 Jun 2006 13:12:32 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1G0054WBSV7U@szxga03-in.huawei.com> for sip@ietf.org; Mon, 26 Jun 2006 13:12:32 +0800 (CST) Received: from RahulSrivastava ([10.18.8.74]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1G00JL8BG4FB@szxml03-in.huawei.com> for sip@ietf.org; Mon, 26 Jun 2006 13:04:56 +0800 (CST) Date: Mon, 26 Jun 2006 10:33:07 +0530 From: Rahul In-reply-to: To: sip@ietf.org Message-id: <001501c698dd$d0961950$4a08120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Subject: [Sip] RE: timer after 200 OK sent in response to BYE X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rahuls@huawei.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Manpreet, Bye can come in early dialog only from the caller's side and not from callee's side. Therefore the scenario as given by Neeraj is correct. RFC 3261 Section 15: " When a BYE is received on a dialog, any session associated with that dialog SHOULD terminate. A UA MUST NOT send a BYE outside of a dialog. The caller's UA MAY send a BYE for either confirmed or early dialogs, and the callee's UA MAY send a BYE on confirmed dialogs, but MUST NOT send a BYE on early dialogs." Neeraj, For any non-Invite response being sent the UAS starts this timer as value for retransmission mechanism for non-reliable transport protocols (e.g. UDP) for TCP its value is 0. Regards, Rahul Message: 1 Date: Fri, 23 Jun 2006 09:24:15 -0700 (PDT) From: neeraj gupta Subject: [Sip] timer after 200 OK sent in response to BYE To: sip@ietf.org Message-ID: <20060623162415.40192.qmail@web52708.mail.yahoo.com> Content-Type: text/plain; charset="iso-8859-1" Hello all I have a question about the timers in the following situation Client Server --------------------------> INVITE ------------------------------> <------------------------ 100 Trying <------------------------------ <------------------------ 180 ringing <------------------------------- --------------------------> Cancel/Bye --------------------------------> <------------------------- 200 OK <------------------------------- After sending the 200 OK, does the server start a timer (Timer J). If yes, why is that so. What is the server waiting for ? I see this behaviour in a user agent. Thanks Neeraj -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www1.ietf.org/pipermail/sip/attachments/20060623/5fd7d4d0/attachm ent.html ------------------------------ Message: 2 Date: Fri, 23 Jun 2006 12:51:36 -0400 From: Manpreet Singh Subject: RE: [Sip] timer after 200 OK sent in response to BYE To: neeraj gupta , sip@ietf.org Message-ID: <6E9C6C7D27E3714190801A551BE3761002BAB6DC@server507.bur.ibasis.net> Content-Type: text/plain; charset="us-ascii" Neeraj Based on your call flow below, BYE would never come in an early dialog. So are you asking for 200OK for CANCEL or 200OK for BYE? Few more messages are missing between BYE and 180 below. ( 200OK and ACK) Thanks M. _____ From: neeraj gupta [mailto:ngupta94@yahoo.com] Sent: Friday, June 23, 2006 12:24 PM To: sip@ietf.org Subject: [Sip] timer after 200 OK sent in response to BYE Hello all I have a question about the timers in the following situation Client Server --------------------------> INVITE ------------------------------> <------------------------ 100 Trying <------------------------------ <------------------------ 180 ringing <------------------------------- --------------------------> Cancel/Bye --------------------------------> <------------------------- 200 OK <------------------------------- After sending the 200 OK, does the server start a timer (Timer J). If yes, why is that so. What is the server waiting for ? I see this behaviour in a user agent. Thanks Neeraj _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 26 03:58:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuly0-00050Y-41; Mon, 26 Jun 2006 03:57:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fulxy-00050S-2x for sip@ietf.org; Mon, 26 Jun 2006 03:57:06 -0400 Received: from rat01037.dc-ratingen.de ([195.233.129.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fulxw-0006Ja-Es for sip@ietf.org; Mon, 26 Jun 2006 03:57:06 -0400 Received: from heinz.vodafone-is.de (heinz_e0 [195.233.128.26]) by rat01037.dc-ratingen.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id k5Q7uxpI009200; Mon, 26 Jun 2006 09:56:59 +0200 (MEST) Received: from devis-wimx01.vf-de.internal.vodafone.com ([139.7.95.113]) by heinz.vodafone-is.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id k5Q7uUs3004931; Mon, 26 Jun 2006 09:56:58 +0200 (MEST) Received: from dedus-wimx01.vf-de.internal.vodafone.com ([10.128.148.118]) by devis-wimx01.vf-de.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 26 Jun 2006 09:56:51 +0200 Received: from DEDUS-WICL01M01.vf-de.internal.vodafone.com ([10.128.148.123]) by dedus-wimx01.vf-de.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Jun 2006 09:56:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Sip] updated GRUU spec Date: Mon, 26 Jun 2006 09:56:50 +0200 Message-ID: <3A6671F8B360D34FAAC98771AD4D9990029D9BF3@DEDUS-WICL01M01.vf-de.internal.vodafone.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] updated GRUU spec Thread-Index: AcaW2TQp1RnH48EFSfyHicsZx7dG3QCHIR2g From: "Lu, Yang, VF-DE" To: "Jonathan Rosenberg" , "Dale R. Worley" X-OriginalArrivalTime: 26 Jun 2006 07:56:48.0345 (UTC) FILETIME=[13844490:01C698F6] 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: , Errors-To: sip-bounces@ietf.org Is it a correct understanding that when a UA applies gruu extension to = any requests including the REGISTER request, it DOES NOT need to use the = Proxy-Require header field to insist that any proxies that are traversed = understand gruu?=20 Best Regards Yang @ Vodafone =20 =20 -----Urspr=FCngliche Nachricht----- Von: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 Gesendet: Freitag, 23. Juni 2006 17:24 An: Dale R. Worley Cc: sip@ietf.org Betreff: Re: [Sip] updated GRUU spec inline. Dale R. Worley wrote: > From: "Jeroen van Bemmel" >=20 > 1) The protocol bits that trigger issueing of a GRUU are = "Supported: gruu"=20 > and a sip.instance id in the Contact header. If "supported" then = "MUST issue=20 > GRUU". If you compare this with e.g. 100rel it seems a bit odd, = Supported:=20 > 100rel does not force the server to use it. How about Supported -> = SHOULD,=20 > Require -> MUST ? (could a domain have reasons not to honor the = request for=20 > GRUUs?) >=20 > Actually, what triggers *constructing* a GRUU is (1) Registrar=20 > implements GRUU, and (2) Contact contains +sip.instance. Exactly. > What > triggers adding the gruu header-parameter in the response is (1) and > (2) along with (3) "Supported: gruu" in the request (so the Registrar=20 > knows that the UAC can cope with it). Exactly. >=20 > (As I was reading the I-D, I wondered why the UAC could send > +sip.instance without first discerning that the Registrar supported > it, but the Registrar could not send gruu without first discerning=20 > that the UAC supported it. But I think that's because +sip.instance=20 > is identifiable as a caller preference, and there is a defined way for = > UASs to deal with a caller preference it does not understand.) There is no need for the client to discover registrar support for gruu = prior to registration, because there is no harm in including=20 +sip.instance even if the registrar doesnt support it. Indeed, if ALL the registrar/proxy supports is rfc3841, then +sip.instance is still = usable with that (though not terribly valuable). >=20 > So if a UA wants to get a GRUU when it can, but not get its=20 > registration rejected if it cannot, it uses Supported: gruu and > +sip.instance. Right, and this is what it normally ought to do. > If the Registrar implements gruu, it MUST send a gruu in response. =20 > But if a UA wants to make sure it gets a GRUU (and gets its REGISTER=20 > rejected with 420 if it cannot), it uses Supported: gruu, > Require: gruu, and +sip.instance. Only caveat is that require just makes sure the registrar supports gruu; = it doesn't FORCE the proxy to hand you out a gruu. Policy may, for some = reason, still tell it not to hand you a gruu since you've been a bad boy = this year. -Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use = sip-implementors@cs.columbia.edu for questions on current sip Use = sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 26 04:18:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FumHR-0003zc-C7; Mon, 26 Jun 2006 04:17:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FumHP-0003zX-QX for sip@ietf.org; Mon, 26 Jun 2006 04:17:11 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FumHO-00085H-2j for sip@ietf.org; Mon, 26 Jun 2006 04:17:11 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 01329500002; Mon, 26 Jun 2006 10:16:30 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 10:16:29 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 10:16:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound: keep-alive, outbound and 3489bis Date: Mon, 26 Jun 2006 10:16:28 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F118D@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: keep-alive, outbound and 3489bis Thread-Index: AcaX4qCxt5NZbqlQQ+WRvc6t16prnABFFzbw From: "Christer Holmberg \(JO/LMF\)" To: "Cullen Jennings" , "Dean Willis" X-OriginalArrivalTime: 26 Jun 2006 08:16:29.0511 (UTC) FILETIME=[D38BE570:01C698F8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sip@ietf.org, Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, >>So what happens when a client that is constructing a proxy-URI =20 >>decides to tack on a keepalive=3Dstun parameter, and the proxy =20 >>doesn't support keepalive via stun? Does the proxy reject a =20 >>REGISTER request that contains this parameter if it doesn't support =20 >>it? > >same thing that happens if the client decide to recode the URI in =20 >ebcdic - it probably won't work. Of course any self respecting proxy =20 >should not have problems if some random non sip message get sent to =20 >it be that message a STUN message or just a random network scan probe. [CHH] The problem is that, eventhough the NAT keep-alive would work, the client would not be able to use the detect-if-the-NAT-has-rebooted functionality, since it won't get any STUN responses back. The client will of course detect that, since it doesn't get any STUN resposnes back, but there should be a "nicer" way to be informed about that fact that something isn't supported. One problem is that the client may not have the edge proxy (I guess we can still call it that, even if we ONLY talk about STUN for NAT keep-alive, and not the rest of outbound) address information in "URI format". It may use some other edge proxy discovery mechanism, which only provides the IP address/port (no URI parameters etc) of the proxy to the client. In that case the client will have to assume that the edge proxy supports STUN, and insert the parameter in the URI created based on the IP address of the proxy. But, as Cullen said, the problem is that there may not be any other good ways. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 26 04:33:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FumV3-0000CH-Ak; Mon, 26 Jun 2006 04:31:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FumV1-0000Bz-F6 for sip@ietf.org; Mon, 26 Jun 2006 04:31:15 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FumV0-0000aw-Me for sip@ietf.org; Mon, 26 Jun 2006 04:31:15 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 891533BE2D; Mon, 26 Jun 2006 10:31:13 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 26255-01-6; Mon, 26 Jun 2006 10:31:12 +0200 (CEST) Received: from [192.168.123.15] (c-0cfbe055.1161-1-64736c11.cust.bredbandsbolaget.se [85.224.251.12]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 7747D3BFA0; Mon, 26 Jun 2006 10:31:11 +0200 (CEST) From: Fredrik Thulin To: sip@ietf.org Subject: Re: [Sip] Comments on draft-ietf-sip-identity-06 Date: Mon, 26 Jun 2006 10:29:41 +0200 User-Agent: KMail/1.9.1 References: <24EAE5D4448B9D4592C6D234CBEBD597054F4499@stntexch03.cis.neustar.com> In-Reply-To: <24EAE5D4448B9D4592C6D234CBEBD597054F4499@stntexch03.cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606261029.41235.ft@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.543 tagged_above=-99 required=7 tests=[AWL=0.122, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: "Drage, Keith \(Keith\)" , "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: , Errors-To: sip-bounces@ietf.org My excuses for not being able to trim the response more, the different paragraphs seems connected to each other and the context necessary. We definately seem to talk about two different things. Perhaps I have totally misunderstood the use of the Call-ID to prevent cut-and-paste attacks - let's hope so. After you read this message, I believe you will be able to tell if this is the case, in which case I would be very thankful if you could explain it to me. Thanks. On Thursday 22 June 2006 19:43, Peterson, Jon wrote: > Regarding the Call-ID issue raised by Lakshminath, we did address > this in a response to GEN-ART during the approval process of > sip-identity. Unfortunately, that mail thread wasn't captured > publicly anywhere. Ok. > The properties that the authors believe we derive from the Call-ID > are described in sip-identity 13.1. The Call-ID is given in the hash > in order to provide a nonce, of sorts, that helps verifiers to > identify cut-and-paste attacks. The ability of an attacker to predict > this nonce does not degrade the security of the mechanism in any way. > The Call-ID alone, of course, would be insufficient to prevent a > cut-and-paste attack; it is used in concert with the Date header > especially to allow verifiers to record received Call-IDs during a > Date interval in order to identify replays. > > To your specific points: > > 1) This applies to _all_ the verifiers in a domain. If the > > verification is done by a domains SIP servers (not the callee's > > user agent) then they will have to use a distributed database or a > > single point of failure database to remember the Call-Ids seen by > > _any_ of the verifiers. > > I agree that instantiating the verifier role on an intermediary can > be onerus for a number of reasons. It is of course preferable for the > Identity header to be verified directly by the UAS. Do note that that > draft only requires Call-IDs to be remembered for the duration of the > Date interval. I imagine that if multiple verifiers acted on a > message, each might have its own repository for storing Call-IDs it > has seen. Annoying, though, for intermediaries. > > > 2) If the verification is done by the callee's end user agents, I > > beleive it would be possible for an attacker to capture a request > > (say a MESSAGE) sent from sip:bob@biloxi to sip:alice@atlanta, and > > then send an identical MESSAGE with From: sip:bob@biloxi, To: > > sip:alice@atlanta but Request-URI sip:carol@atlanta. > > So, you mean basically forwarding a message to a third party. Yes, > you can do that in any messaging system with any sort of message, > signed or not, whether you are the intended recipient of the message > or an eavesdropper. Only confidentiality properties, which > sip-identity does not provide, can help you with this sort of thing. > Most messaging systems, including SIP, have some concept that > messages can be forwarded by intermediaries, and that the original > target address may differ from the destination identified by > intermediaries. This is in a nutshell the difference between the To > and Request-URI fields. > > > I'm not sure there will ever be a value for any attacker in doing > > this, but it seems possible since Alice and Carol's user agents are > > very unlikely to share information about previously seen Call-Ids. > > Even if it seems to be a meaningless attack, it is still an attack, > > or have I missed something making this impossible? > > In what sense is forwarding a message an attack? Carol will be able > to ascertain that the message was sent To: Alice, and her UA could > apply automated policies to messages exhibiting this property. Or > Carol the human could react to it if it were merely rendered by her > UI. If messages to Alice mean nothing to Carol, they'll be discarded, > either way. My problem isn't with the possibility to duplicate a message sent from sip:bob@biloxi to sip:alice@atlanta to a third party (like sip:carol@atlanta, with To: still being sip:alice@atlanta) - I understand that this is how things work in SIP when there are forwarding intermediaries. My problem is with sip-identity seemingly saying that if you do sip-identity verification, this can be avoided since you remember Call-ID's. The proposed cut-and-paste prevention mechanism with the Call-ID would indeed work if there was a central verification service for the destination domain, but not if the verification was done independently by Alice's and then Carol's UA's (because they would not likely share Call-ID's-seen state). ... > In any event, the relevance of this to the Call-ID is questionable. > You seem to be arguing that the presence of the Call-ID in the hash > was intended to prevent forwarding, and that it isn't working. That > certainly was not the stated motivation for the inclusion of the > Call-ID in the sip-identity draft. Even if you believe this sort of > forwarding does constitute an attack, no properties of the Call-ID > especially prevent or enable "attacks" of this sort. When you say 'hash' I presume you are talking about the signature created and put in the Identity header, right? If so, then no - that's not at all what I am talking about. My problem with the Call-ID is the _other_ use for it, described in sip-identity, namely the verifier remembering it for about an hour to detect cut-and-paste attacks. The part of the draft that I interpret as saying this is the following from section 13.1 : Implementations MUST also record Call-IDs received in valid requests containing an Identity header, and MUST remember those Call-IDs for at least the duration of a single Date interval (i.e., commonly 3600 seconds). Because a SIP-compliant UA never generates the same Call-ID twice, verifiers can use the Call-ID to recognize cut-and-paste attacks; the Call-ID serves as a nonce. The result of this is that if an Identity header is replayed within the Date interval, verifiers will recognize that it is invalid because of a Call-ID duplication; > > 3) This IS a problem if the Call-Ids generated by a UA is > > predictable, although unique. I beleive RFC3261 doesn't say that > > Call-Ids must not be predictable, even though it says they must be > > unique. For example, say that Alice has a UA that produces > > sequential Call-Ids with the IP address as 'what makes these > > unique'. Alice calls me, so I get her UAs current Call-Id. She > > tells me that she is going to call > > sip:someone@example.org right after our call. I want to prevent her > > from doing that. > > > > During our call, I send requests to example.org with > > the Call-Id's I predict Alices UA will use. Alices call to > > sip:someone@example.org will get rejected > > So, the idea is that you send a seemingly valid, signed request with > the predicted Call-ID to sip:someone before Alice can send her > request, so that sip:someone will reject Alice's request when it > shows up because it has previously accepted a request with the same > Call-ID from the same source. Yes. > Well, your primary problem with launching an attack like this would > be controlling Alice's authentication service. You would have to, in > order to be able to send a request with an Identity header posing as > her. Guessing her Call-ID doesn't do you any good unless you can > somehow construct the signed Identity header that her authentication > service would generate for that Call-ID. I don't see why I would have to control Alice's authentication service. As I understand the part of 13.1 about remembering Call-ID's to prevent cut-and-paste attacks, you are _only_ looking at the Call-ID, not sender+Call-ID. I could therefor let my own authentication service sign requests with the Call-ID I predict Alice's UA will use from me to sip:someone, and send them to sip:someone. sip:someone's verification service will verify my signature as valid, and remember the Call-ID as previously used for about an hour. When Alice's request reaches the validation service of sip:someone it will be rejected because of Call-ID duplication, as I read the part of 13.1 that I quoted above ("Implementations MUST also record Call-IDs..."). > If you're considering requests sent without an Identity header, well, > sip-identity can't help you with those. > > > Also, what makes subsequent requests in the same dialog as the > > first one not get rejected? They will have the same Call-Id. > > The CSeq, which is also included in the Identity hash. The same way > that SIP differentiates individual transactions associated with a > dialog. In the hash, yes (if you mean the signature put in the Identity header), but not as a component in the algorithm to detect cut-and-paste attacks. /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 26 12:02:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FutWG-0006Gv-JR; Mon, 26 Jun 2006 12:01:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FutWE-0006Ft-OD for sip@ietf.org; Mon, 26 Jun 2006 12:00:58 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FutWD-0003jw-G5 for sip@ietf.org; Mon, 26 Jun 2006 12:00:58 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 26 Jun 2006 09:00:56 -0700 X-IronPort-AV: i="4.06,176,1149490800"; d="scan'208"; a="1832685834:sNHT189428856" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k5QG0upL008428; Mon, 26 Jun 2006 09:00:56 -0700 Received: from [192.168.1.2] (sjc-vpn6-344.cisco.com [10.21.121.88]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5QG0tCU018528; Mon, 26 Jun 2006 09:00:55 -0700 (PDT) In-Reply-To: <1150495197.10237.51.camel@sukothai.pingtel.com> References: <1150495197.10237.51.camel@sukothai.pingtel.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] draft-ietf-sip-hop-limit-diagnostics-03 Date: Mon, 26 Jun 2006 09:00:50 -0700 To: Scott Lawrence X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=218; t=1151337656; x=1152201656; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20draft-ietf-sip-hop-limit-diagnostics-03; X=v=3Dcisco.com=3B=20h=3D0FJyW9HIjHsgYBk3YGwwY6dorOk=3D; b=oR6apiYezVVmQdLanvakncnY4eaw9Y9TKvEms+ZiH+nrah6vy38rJAHBJpBusW62mXdhMwtW vECesqeH/yqxdO/jDt5l9PyYOvW7NxvdrUEdXHvXEtL6pYg9dE19Hvek; Authentication-Results: sj-dkim-2.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: SIP WG List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 16, 2006, at 2:59 PM, Scott Lawrence wrote: > > There are, I think, two issues remaining for discussion: I disagree - I don't think the draft of the discussion has addressed the issue I brought up. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 26 12:53:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuuJC-0001zu-1p; Mon, 26 Jun 2006 12:51:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuuJA-0001zk-Nh for sip@ietf.org; Mon, 26 Jun 2006 12:51:32 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuuJA-00019I-91 for sip@ietf.org; Mon, 26 Jun 2006 12:51:32 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 26 Jun 2006 09:51:31 -0700 X-IronPort-AV: i="4.06,176,1149490800"; d="scan'208"; a="1832724382:sNHT51463470" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k5QGpUZH022884; Mon, 26 Jun 2006 09:51:31 -0700 Received: from [192.168.1.2] (sjc-vpn6-344.cisco.com [10.21.121.88]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5QGpUCU027401; Mon, 26 Jun 2006 09:51:30 -0700 (PDT) In-Reply-To: <002f01c694ad$3c5479a0$31713b51@BEMBUSTER> References: <002401c693c8$aab13400$31713b51@BEMBUSTER> <4497EAE7.9090700@cisco.com> <44985514.4010107@cisco.com> <002f01c694ad$3c5479a0$31713b51@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <669459C0-169D-42AF-B59A-0F81AB5C2339@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] draft-ietf-sip-certs-00, communicating private keys and self-signed certificates Date: Mon, 26 Jun 2006 09:51:27 -0700 To: Jeroen van Bemmel X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=4190; t=1151340691; x=1152204691; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20draft-ietf-sip-certs-00, =20communicating=20private=20key s=20and=20self-signed=20certificates; X=v=3Dcisco.com=3B=20h=3DhCD5BI5kwhAPIIA4abrX4qxTYLA=3D; b=ADulfjy+TNaf5XCs4rhxjB/aJc3woDEJlWctyOWN0IeGzqq/+defCpqroQkR8SO0yHaH3mqh 05u7ZfJVkZiddjNdZxe4YxPatJ+xqi01D57zdgYur0wZJY8ysBacb0PL; Authentication-Results: sj-dkim-4.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: sip@ietf.org, Paul Kyzivat , Michael Thomas X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Some (not all deployments) will have multiple devices registered to one AOR. The original draft had each device have it's own asymmetric key pair and if someone wanted to encrypt a message for the AOR, the message was encrypted with a symmetric key then the symmetric key was included in the message and encrypted with asymmetric keys for *every* device on that AOR. The WG decided this was not feasible and it would be better to have the devices share the asymmetric key so there was only one to deal with. The draft in no way mandates that a deployment move around private keys over the network - deployments and users are allowed to do it any way they want including: 1) just say no and do one device 2) just say no and use some other way (like a crypto smart card) to move the private key around 3) use some other sacred framework to move the private key around 4) use the certs approach to store the private key on a server but the private key would be encrypted such that the severer could never decrypt it and only the clients would have the passphrase to decrypt 5) user the certs approach where the server knows the private key 6) user the certs approach where the server generates the private key (and knows it) so clients don't These are listed in what is probably close to order of what is most secure (i.e. 1 is most secure, 6 least) although the later ones may be more convenient. Cullen On Jun 20, 2006, at 2:05 PM, Jeroen van Bemmel wrote: > > ----- Original Message ----- From: "Michael Thomas" > To: "Paul Kyzivat" > Cc: "Jeroen van Bemmel" ; > Sent: Tuesday, June 20, 2006 10:05 PM > Subject: Re: [Sip] draft-ietf-sip-certs-00, communicating private > keys and self-signed certificates > > >> Paul Kyzivat wrote: >> >>> >>> >>> Jeroen van Bemmel wrote: >>> >>>> If a dog barks at a tree and no-one hears it, did the dog make a >>>> sound? >>>> >>>> OK, leaving aside the dogs and the trees for the moment, a short >>>> question about the contents: >>>> The draft states "The certificates discussed in this draft are >>>> generally self signed". It then talks about how the credential >>>> service can be used to obtain the credentials using an >>>> authenticated SUBSCRIBE/NOTIFY sequence. >>>> >>>> What puzzles me: why would a UA use the credential service to >>>> obtain a previously submitted self-signed certificate, instead >>>> of simply generating a new one by itself? >>> >>> >>> Because several UAs share the same AOR and they all want to use a >>> common cert? >> >> Let us keep in mind that a certificate is nothing more than a key >> to identity >> binding. There is absolutely nothing wrong with having multiple >> keys being >> able to assert a given binding. Private keys should be thought of >> as roach motels: >> they check in, but they don't check out. >> > > My thinking was that for some use cases (perhaps not all, e.g. not > for the example in section 9.1) a user could obtain a list of > certificates (or perhaps only their fingerprints) from the > credential service. The UAC would then setup a TLS connection, and > verify that the certificate presented by the other side is in the > list. > > In this way, perhaps one could avoid sending private credentials > across the network altogether. > > Small question on the Security considerations: it says 200 > responses are omitted because "they do not have much to do with the > overall security" - what about mutual authentication, using > Authentication-Info? Should mutual authentication be RECOMMENDED, > or would that be overkill (given that the TLS server cert is also > verified)? > > Regards, > > jeroen > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 26 14:55:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuwD4-0004QZ-Tq; Mon, 26 Jun 2006 14:53:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuwD4-0004QJ-0o for sip@ietf.org; Mon, 26 Jun 2006 14:53:22 -0400 Received: from rwcrmhc14.comcast.net ([204.127.192.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuwD2-0001cn-PR for sip@ietf.org; Mon, 26 Jun 2006 14:53:21 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc14) with ESMTP id <20060626185319m1400nvb9te>; Mon, 26 Jun 2006 18:53:19 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k5QIrI5n020081 for ; Mon, 26 Jun 2006 14:53:18 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k5QIrI7S020077; Mon, 26 Jun 2006 14:53:18 -0400 Date: Mon, 26 Jun 2006 14:53:18 -0400 Message-Id: <200606261853.k5QIrI7S020077@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <3A6671F8B360D34FAAC98771AD4D9990029D9BF3@DEDUS-WICL01M01.vf-de.internal.vodafone.com> (yang.lu@vodafone.com) Subject: Re: AW: [Sip] updated GRUU spec References: <3A6671F8B360D34FAAC98771AD4D9990029D9BF3@DEDUS-WICL01M01.vf-de.internal.vodafone.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Lu, Yang, VF-DE" Is it a correct understanding that when a UA applies gruu extension to any requests including the REGISTER request, it DOES NOT need to use the Proxy-Require header field to insist that any proxies that are traversed understand gruu? Yes, that is correct. Only the Registrar (the UAC of the REGISTER request) needs to understand the gruu extension. Of course, any proxy that is allowed to translate the GRUU URI to its contact URI must understand the special rules for doing so, but the fact that the corresponding Registrar issues GRUUs is evidence that the proxy can do so. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 26 15:03:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuwLJ-0004O6-Lg; Mon, 26 Jun 2006 15:01:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuwLI-0004O1-RG for sip@ietf.org; Mon, 26 Jun 2006 15:01:52 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuwLI-0002Cu-Br for sip@ietf.org; Mon, 26 Jun 2006 15:01:52 -0400 Received: from [192.168.1.4] (65-65-155-30.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5QJ3E5s018599 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 26 Jun 2006 14:03:23 -0500 In-Reply-To: <04B39538-2384-4B5B-81EE-F07703A66744@cisco.com> References: <475FF955A05DD411980D00508B6D5FB00C29092C@en0033exch001u.uk.lucent.com> <04B39538-2384-4B5B-81EE-F07703A66744@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <712F326A-E8D9-48A0-8CE6-C47C0886D9A6@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] draft-ietf-sip-gruu-09.txt ready for IESG? Date: Mon, 26 Jun 2006 14:01:39 -0500 To: Cullen Jennings X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: IETF SIP List , Keith Drage X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The way I look at it is the draft is still in WGLC, and has been since last year. We never terminated its WGLC state, although the document was revised three times during WGLC. Now, if you think that we need more detailed review of specific new material in this version draft before we complete WGLC, that's fine and probably very reasonable, and should be done as part of the ongoing WGLC. That's what Keith was asking -- if you don't think it's ready (and you don't) please let us know. So, I'll log this as a request to do a structured review of the latest GRUU draft before completing WGLC and sending the doc to the IESG. -- Dean On Jun 26, 2006, at 11:32 AM, Cullen Jennings wrote: > > (This email sent purely with my individual contributor hat on) > > This draft has had substantial changes since it was last WGLC > (which was an apreviated WGLC at that). We are not talking about > some typos were fixed - an extra 20 pages of text got added. The > discution got very detailed and many people decided to wait and > review all the changes it once it was done. Technically I doubt the > WG needs to ever WGLC any document but the RAI WGs have had a long > tradition of using WGLC and I think people have come to expect > them. I also beilve that they improve document quality and also > help judge if their is consensus on work. I suspect that people > would typically expect 2 weeks for something like this unless it > corssed over a time like a IETF meeting or major holiday where they > migth expect to add another week to account for that. > > The specific technical details that I think are worth of review are > attached. I suspect I will have no problems with any of them but > these are things I think we should review. > > > > > > > > On Jun 23, 2006, at 3:57 AM, Drage, Keith (Keith) wrote: > >> (As WG chair) >> >> The SIP WG chairs and the author all think this document is ready >> for sending to the IESG. >> >> We have had WGLC announced 5th July 2004 to complete 17th July 2004. >> We had a further last round of WG review requested 26th October >> 2005 to complete 6th November 2005. >> We have had significant discussion on the lists since then of this >> draft, and discussion in SIP WG sessions, and all comments have >> been resolved. >> >> If you believe this document IS NOT ready to send to IESG, can you >> please indicate this to the list and the WG chairs by 12:00 midday >> UK time (7:00 am US Eastern Time) on 30th June 2006, giving >> technical justification for your objection. >> >> Please limit this thread to answering the question above. If you >> have other discussion relating to GRUU generally, then please use >> a different thread. >> >> regards >> >> Keith >> >> -----Original Message----- >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >> Sent: 22 June 2006 20:50 >> To: i-d-announce@ietf.org >> Cc: sip@ietf.org >> Subject: [Sip] I-D ACTION:draft-ietf-sip-gruu-09.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 : Obtaining and Using Globally Routable User Agent (UA) >> URIs (GRUU) in the Session Initiation Protocol (SIP) >> Author(s) : J. Rosenberg >> Filename : draft-ietf-sip-gruu-09.txt >> Pages : 38 >> Date : 2006-6-22 >> >> Several applications of the Session Initiation Protocol (SIP) require >> a user agent (UA) to construct and distribute a URI that can be used >> by anyone on the Internet to route a call to that specific UA >> instance. A URI that routes to a specific UA instance is called a >> Globally Routable UA URI (GRUU). This document describes an >> extension to SIP for obtaining a GRUU from a server and for >> communicating a GRUU to a peer within a dialog. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-09.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the >> body of the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- >> announce >> to change your subscription settings. >> >> >> Internet-Drafts are also available by anonymous FTP. Login with >> the username >> "anonymous" and a password of your e-mail address. After logging in, >> type "cd internet-drafts" and then >> "get draft-ietf-sip-gruu-09.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-sip-gruu-09.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> Date: June 23, 2006 3:57:23 AM PDT >> >> >> >> >> >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 26 15:51:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fux5x-00007u-R3; Mon, 26 Jun 2006 15:50:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fux5u-0008MC-2H; Mon, 26 Jun 2006 15:50:02 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fux5t-0008Gy-P9; Mon, 26 Jun 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5QJo1WR001927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fux5t-00059z-Fr; Mon, 26 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 26 Jun 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-e2m-sec-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : End-to-middle Security in the Session Initiation Protocol (SIP) Author(s) : K. Ono, S. Tachimoto Filename : draft-ietf-sip-e2m-sec-02.txt Pages : 26 Date : 2006-6-26 Some services provided by intermediaries depend on their ability to inspect a message body in the Session Initiation Protocol (SIP). When sensitive information is included in the message body, a SIP User Agent (UA) needs to protect it from other intermediaries than those that the UA agreed to disclose it to. This document proposes a mechanism for securing information passed between an end user and intermediaries using S/MIME. It also proposes mechanisms for a UA to discover intermediaries which need to inspect an S/MIME-secured message body, or to receive the message body with data integrity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-e2m-sec-02.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-e2m-sec-02.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-e2m-sec-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-26135415.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-e2m-sec-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-e2m-sec-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-26135415.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Mon Jun 26 16:02:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuxFo-0000y7-Pr; Mon, 26 Jun 2006 16:00:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuxFo-0000y0-2n for sip@ietf.org; Mon, 26 Jun 2006 16:00:16 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuxFm-0001lw-Fa for sip@ietf.org; Mon, 26 Jun 2006 16:00:16 -0400 Received: (qmail 29322 invoked by uid 0); 26 Jun 2006 19:59:57 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 26 Jun 2006 19:59:57 -0000 Message-ID: <002501c6995b$1c3002e0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Cullen Jennings" References: <002401c693c8$aab13400$31713b51@BEMBUSTER> <4497EAE7.9090700@cisco.com> <44985514.4010107@cisco.com> <002f01c694ad$3c5479a0$31713b51@BEMBUSTER> <669459C0-169D-42AF-B59A-0F81AB5C2339@cisco.com> Subject: Re: [Sip] draft-ietf-sip-certs-00, communicating private keys and self-signed certificates Date: Mon, 26 Jun 2006 22:00:01 +0200 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.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: sip@ietf.org, Paul Kyzivat , Michael Thomas X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen, > > Some (not all deployments) will have multiple devices registered to one > AOR. The original draft had each device have it's own asymmetric key pair > and if someone wanted to encrypt a message for the AOR, the message was > encrypted with a symmetric key then the symmetric key was included in the > message and encrypted with asymmetric keys for *every* device on that > AOR. The WG decided this was not feasible and it would be better to have > the devices share the asymmetric key so there was only one to deal with. > I agree that this would not be feasible. I was thinking that for a multi-device scenario where encryption (and not TLS) is required, the "caller" could discover GRUUs for all currently registered devices (eg using presence), select one (perhaps guided in some way by preferences of the callee, say q-value ordering), and then encrypt specifically for that device Slightly less flexible than having one cert per user, but better than encrypting a symmetric key for each potential device as you sketch above > The draft in no way mandates that a deployment move around private keys > over the network - deployments and users are allowed to do it any way > they want including: > > 1) just say no and do one device > 2) just say no and use some other way (like a crypto smart card) to move > the private key around > 3) use some other sacred framework to move the private key around > 4) use the certs approach to store the private key on a server but the > private key would be encrypted such that the severer could never decrypt > it and only the clients would have the passphrase to decrypt > 5) user the certs approach where the server knows the private key > 6) user the certs approach where the server generates the private key > (and knows it) so clients don't > > These are listed in what is probably close to order of what is most > secure (i.e. 1 is most secure, 6 least) although the later ones may be > more convenient. > To me, some text like the above would be good to put in the draft Regards, Jeroen > Cullen > > > > On Jun 20, 2006, at 2:05 PM, Jeroen van Bemmel wrote: > >> >> ----- Original Message ----- From: "Michael Thomas" >> To: "Paul Kyzivat" >> Cc: "Jeroen van Bemmel" ; >> Sent: Tuesday, June 20, 2006 10:05 PM >> Subject: Re: [Sip] draft-ietf-sip-certs-00, communicating private keys >> and self-signed certificates >> >> >>> Paul Kyzivat wrote: >>> >>>> >>>> >>>> Jeroen van Bemmel wrote: >>>> >>>>> If a dog barks at a tree and no-one hears it, did the dog make a >>>>> sound? >>>>> >>>>> OK, leaving aside the dogs and the trees for the moment, a short >>>>> question about the contents: >>>>> The draft states "The certificates discussed in this draft are >>>>> generally self signed". It then talks about how the credential >>>>> service can be used to obtain the credentials using an authenticated >>>>> SUBSCRIBE/NOTIFY sequence. >>>>> >>>>> What puzzles me: why would a UA use the credential service to obtain >>>>> a previously submitted self-signed certificate, instead of simply >>>>> generating a new one by itself? >>>> >>>> >>>> Because several UAs share the same AOR and they all want to use a >>>> common cert? >>> >>> Let us keep in mind that a certificate is nothing more than a key to >>> identity >>> binding. There is absolutely nothing wrong with having multiple keys >>> being >>> able to assert a given binding. Private keys should be thought of as >>> roach motels: >>> they check in, but they don't check out. >>> >> >> My thinking was that for some use cases (perhaps not all, e.g. not for >> the example in section 9.1) a user could obtain a list of certificates >> (or perhaps only their fingerprints) from the credential service. The >> UAC would then setup a TLS connection, and verify that the certificate >> presented by the other side is in the list. >> >> In this way, perhaps one could avoid sending private credentials across >> the network altogether. >> >> Small question on the Security considerations: it says 200 responses are >> omitted because "they do not have much to do with the overall >> security" - what about mutual authentication, using Authentication-Info? >> Should mutual authentication be RECOMMENDED, or would that be overkill >> (given that the TLS server cert is also verified)? >> >> Regards, >> >> jeroen >> >> >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 26 17:34:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuyhA-0002ql-Fo; Mon, 26 Jun 2006 17:32:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuyh8-0002qg-Tk for sip@ietf.org; Mon, 26 Jun 2006 17:32:34 -0400 Received: from rwcrmhc15.comcast.net ([204.127.192.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuyh7-0008FH-J2 for sip@ietf.org; Mon, 26 Jun 2006 17:32:34 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc15) with ESMTP id <20060626213232m1500dhaupe>; Mon, 26 Jun 2006 21:32:32 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k5QLWV5n023993 for ; Mon, 26 Jun 2006 17:32:31 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k5QLWVZQ023989; Mon, 26 Jun 2006 17:32:31 -0400 Date: Mon, 26 Jun 2006 17:32:31 -0400 Message-Id: <200606262132.k5QLWVZQ023989@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net X-Spam-Score: 0.2 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Subject: [Sip] draft-ietf-sip-gruu-09 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I've gone over draft-ietf-sip-gruu-09, and it's a fine piece of work, I must say. As far as I can tell, every doubt I've had about the GRUU machinery has been resolved (except for the "edge router" problem, which has been dealt with via sip-outbound). I've written up some editorial changes to the I-D. I don't think that any of these change the protocol, but this is such an important I-D that it ought to be described as rigorously as possible. ---------------------------------------------------------------------- There seems to be disagreement as to what the plural of GRUU is -- GRUU or GRUUs. E.g., section 13, page 31 uses both "Furthermore, GRUUs do not address" and "These GRUU will be passed". There is a similar inconsistency regarding the plural of AOR. Section 3, page 5: "the following is true" should be "the following three properties are true", in order to ensure there is no ambiguity about the definition. Section 4.3, page 7: "Each tuple also has" s.b. "Each tuple has", as there is no preceding discussion of anything that "each tuple has". (This actually caused me some confusion the first time I read it!) Section 5, page 9: ", and to easily recognize that the URI has the GRUU property" s.b. omitted, as it is the "gruu" parameter that does that, not the "opaque" parameter. Section 5, page 9: "that results from stripping out the "opaque" URI parameter" s.b. "that results from stripping out the "opaque" and "gruu" URI parameters". But that isn't really the statement we want either, since URI "equivalence" is not affected by a URI parameter present in one URI and not in the other. See RFC 3261, section 19.1.4. That is, sip:carol@chicago.com sip:carol@chicago.com;opaque="dRfHgbHjGhImBv";gruu are equivalent already. But unfortunately so are: sip:carol@chicago.com sip:carol@chicago.com;opaque="dRfHgbHjGhImBv";gruu;hop-sip-and-jump and we want to rule out the latter pair. Section 7.1.1.1, page 13: "characteristic [8]. The instance ID MUST identify the UA that is performing the registration." s.b. "characteristic [8], whose value MUST be the instance ID that identifies the UA being registered." This is needed to explicitly state what the value of the feature tag is, as well as to be correct for third-party registrations. Section 8.1.1, page 18: "the grammar for the parameter" s.b. "the grammar for the parameter given in section 10". Section 8.1.1, page 18: "(which is the case for administratively constructed GRUUs)" s.b. omitted -- as far as I can tell, this isn't always true. Section 8.2.2, page 21: "location service for that user" s.b. "location service for that AOR", since "user" is not used elsewhere in that paragraph. Section 10, page 23: "The grammar for string-value is obtained from [8]." s.b. omitted, since "string-value" is not mentioned elsewhere. Section 10, page 23: ""gruu" EQUAL LDQUOT (SIP-URI / SIPS-URI) RDQUOT" is not what we want, I think. I think the semantics we are looking for is ""gruu" EQUAL quoted-string, where the value represented by the quoted-string is a SIP-URI or SIPS-URI". (That latter could be represented in BNF, but that would make it less clear.) Due to the details of the grammar, the new formulation differs from the original only in some unusual cases, such as allowing: Contact: <...>;gruu="sip:gruu\~123456789@example.com;gruu" (The GRUU is .) But it seems to me that it is non-orthogonal (and inviting trouble) to have the grammar for c-p-gruu forbid backslash-escapes of characters that do not require them, when the grammar for generic-param allows them. Section 12, page 29: Messages 13, 14, 15, and 16 (from figure 2, page 26) are not shown. This may be intentional, but probably should be noted explicitly, as the other requests seem to be shown. ---------------------------------------------------------------------- Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 26 18:00:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuz5y-0006f6-SV; Mon, 26 Jun 2006 17:58:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuz5w-0006f1-P6 for sip@ietf.org; Mon, 26 Jun 2006 17:58:12 -0400 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuz5v-0003Xv-G6 for sip@ietf.org; Mon, 26 Jun 2006 17:58:12 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc11) with ESMTP id <20060626215810m1100aumrre>; Mon, 26 Jun 2006 21:58:10 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k5QLw95n024609 for ; Mon, 26 Jun 2006 17:58:09 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k5QLw8wq024605; Mon, 26 Jun 2006 17:58:08 -0400 Date: Mon, 26 Jun 2006 17:58:08 -0400 Message-Id: <200606262158.k5QLw8wq024605@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net X-Spam-Score: 0.2 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [Sip] GRUU record-routing X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I fear that I'm rushing in angels fear to tread, and I admit that I've been busy and not paying close attention to the discussions for the last six months, but I've saved and reviewed a lot of the discussion, and I think that I've not seen a full discussion of the solution to the "edge router" problem given in section 8.2.2 of draft-ietf-sip-gruu-09.txt: 8.2.2. Record-Routing The proxy that accesses the location service (called the home proxy here) MUST record-route under two circumstances. Firstly, if the home proxy receives a dialog forming request from a UA in its own domain (an originating request) whose Contact header field contains a GRUU (indicated by the presence of the "gruu" URI parameter), the proxy MUST record-route. Secondly, if the home proxy receives a dialog-forming request targeted to an AOR or GRUU within the domain of the home proxy (a terminating request), and it translates the Request URI into a contact that is associated with an instance ID to which a GRUU has been assigned, the proxy MUST record-route. The URI placed into the record-route MUST cause the request to be routed to a proxy that can access the location service for that user. A couple of questions come to mind: - It seems to me that the home proxy could avoid record-routing a terminating request if it knows that no further proxy to the ultimate UA will record-route. Similarly, a home proxy could avoid record-routing an originating request if there are no preceding record-routes on the request. (In either case, the request would be processed in the same way as is now prescribed by 8.2.2/8.2.3.) So these requirements don't *have* to be MUST-strength. - For 8.2.2 to have the desired effect for originating requests, it seems we must require that if any previous proxy record-routes itself, then the request must go through a home proxy for record-routing before going on to the greater Internet. (That is necessary, but not implied by the other SIP rules, in some weird cases. E.g., if the home proxy and the Internet-side interface of the edge router are globally addressable, but the UA-side interface of the edge router is not globally addressable.) So I think an additional MUST is needed here. Maybe this has already been explicated. But even if it has, it might help the reader to put in a few sentences of explanation. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 26 18:43:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuzlY-0003pp-Q3; Mon, 26 Jun 2006 18:41:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuzlX-0003pW-69 for sip@ietf.org; Mon, 26 Jun 2006 18:41:11 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuzlU-0006vT-Td for sip@ietf.org; Mon, 26 Jun 2006 18:41:11 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail3.lucent.com (8.13.6/IER-o) with ESMTP id k5QMf8m6011080 for ; Mon, 26 Jun 2006 17:41:08 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k5QMf8r17638; Mon, 26 Jun 2006 17:41:08 -0500 (CDT) Message-ID: <44A06283.9000504@lucent.com> Date: Mon, 26 Jun 2006 17:41:07 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Sip] -01 version of Domain Certificates (domain-certs-01) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Folks: Based on the WG list discussion of April and consensus reached on those discussions, a rev'd version of the domain-certs draft has been released. Please take a look at this version and provide comments. Most of the discussion in April structured around identities in the certificate. There were other sections that went unexplored, specifically certificate contents and server farms, and certificates for virtual SIP servers. Discussion on these will be helpful. Until a version is available in the IETF archives, you can get a copy from http://www.iit.edu/~gurbvij/I-D/draft-gurbani-sip-domain-certs-01.txt http://www.iit.edu/~gurbvij/I-D/draft-gurbani-sip-domain-certs-01.html Thanks. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 26 20:46:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv1hA-0000qh-B2; Mon, 26 Jun 2006 20:44:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv1h8-0000qc-TZ for sip@ietf.org; Mon, 26 Jun 2006 20:44:46 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv1h7-00042z-EW for sip@ietf.org; Mon, 26 Jun 2006 20:44:46 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 26 Jun 2006 17:44:45 -0700 X-IronPort-AV: i="4.06,178,1149490800"; d="scan'208"; a="1833039806:sNHT33149326" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k5R0iiih013165; Mon, 26 Jun 2006 17:44:44 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5R0iOko001744; Mon, 26 Jun 2006 17:44:44 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Jun 2006 20:44:35 -0400 Received: from [192.168.1.100] ([10.86.240.77]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Jun 2006 20:44:35 -0400 Message-ID: <44A07F72.7050902@cisco.com> Date: Mon, 26 Jun 2006 20:44:34 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [Sip] GRUU record-routing References: <200606262158.k5QLw8wq024605@dragon.ariadne.com> In-Reply-To: <200606262158.k5QLw8wq024605@dragon.ariadne.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jun 2006 00:44:35.0721 (UTC) FILETIME=[DCE19F90:01C69982] DKIM-Signature: a=rsa-sha1; q=dns; l=4236; t=1151369084; x=1152233084; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Sip]=20GRUU=20record-routing; X=v=3Dcisco.com=3B=20h=3DEPvhPtw/b/o0Js+T8gdbsqZ80dE=3D; b=p9YyX3On+on/GAs92aWzKjGFaOpVWIwepx/WorxFLXNUy2wNTZGkJLE32dpuT6jE1Gki86Gv PdMFHy+UM9CdoqCvUQxE0eu1eqIytGJWCTX1VU24NASXf/0xVbiZvzTh; Authentication-Results: sj-dkim-4.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Dale.Worley@comcast.net wrote: > I fear that I'm rushing in angels fear to tread, and I admit that I've > been busy and not paying close attention to the discussions for the > last six months, but I've saved and reviewed a lot of the discussion, > and I think that I've not seen a full discussion of the solution to > the "edge router" problem given in section 8.2.2 of > draft-ietf-sip-gruu-09.txt: > > 8.2.2. Record-Routing > > The proxy that accesses the location service (called the home proxy > here) MUST record-route under two circumstances. Firstly, if the > home proxy receives a dialog forming request from a UA in its own > domain (an originating request) whose Contact header field contains a > GRUU (indicated by the presence of the "gruu" URI parameter), the > proxy MUST record-route. Secondly, if the home proxy receives a > dialog-forming request targeted to an AOR or GRUU within the domain > of the home proxy (a terminating request), and it translates the > Request URI into a contact that is associated with an instance ID to > which a GRUU has been assigned, the proxy MUST record-route. The URI > placed into the record-route MUST cause the request to be routed to a > proxy that can access the location service for that user. > > A couple of questions come to mind: > > - It seems to me that the home proxy could avoid record-routing a > terminating request if it knows that no further proxy to the > ultimate UA will record-route. Similarly, a home proxy could avoid > record-routing an originating request if there are no preceding > record-routes on the request. (In either case, the request would be > processed in the same way as is now prescribed by 8.2.2/8.2.3.) So > these requirements don't *have* to be MUST-strength. The trick is the little oracle function which requires the proxy to know two things, (1) that no downstream proxy is going to record-route, and that (2) the UA is going to insert a gruu into the contact. The last one in particular has been troubling to gaurantee. Since, when there is a gruu, the request is GOING to hit the home proxy anyway, it makes sense to have it always record-route. > > - For 8.2.2 to have the desired effect for originating requests, it > seems we must require that if any previous proxy record-routes > itself, then the request must go through a home proxy for > record-routing before going on to the greater Internet. (That is > necessary, but not implied by the other SIP rules, in some weird > cases. E.g., if the home proxy and the Internet-side interface of > the edge router are globally addressable, but the UA-side interface > of the edge router is not globally addressable.) So I think an > additional MUST is needed here. That is a good point; the spec is assuming originating requests will go through the home proxy. Things work fine if any of the proxies on the record-routing chain in the outbound direction are capable of translating the GRUU. I put these words into section 8.2.2: The proxy that accesses the location service (called the home proxy here) MUST record-route under two circumstances. Firstly, if the home proxy receives a dialog forming request from a UA in its own domain (an originating request) whose Contact header field contains a GRUU (indicated by the presence of the "gruu" URI parameter), the proxy MUST record-route. This, of course, assumes that the home proxy is in the request path for such originating requests. If it is not, some other proxy on the request path MUST generate a record-route which will route to the home proxy. A home proxy can use mechanisms such as Service-Route or UA configuration to ensure that it is on the outgoing request path. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 26 20:49:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv1k7-00023U-Gi; Mon, 26 Jun 2006 20:47:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv1k6-00023P-BU for sip@ietf.org; Mon, 26 Jun 2006 20:47:50 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv1k5-00048i-0P for sip@ietf.org; Mon, 26 Jun 2006 20:47:50 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 26 Jun 2006 17:47:48 -0700 X-IronPort-AV: i="4.06,178,1149490800"; d="scan'208"; a="301362435:sNHT31515412" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k5R0lmTl003442; Mon, 26 Jun 2006 17:47:48 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5R0llcL007866; Mon, 26 Jun 2006 17:47:48 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Jun 2006 20:47:47 -0400 Received: from [192.168.1.100] ([10.86.240.77]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Jun 2006 20:47:47 -0400 Message-ID: <44A08032.6040108@cisco.com> Date: Mon, 26 Jun 2006 20:47:46 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: AW: [Sip] updated GRUU spec References: <3A6671F8B360D34FAAC98771AD4D9990029D9BF3@DEDUS-WICL01M01.vf-de.internal.vodafone.com> <200606261853.k5QIrI7S020077@dragon.ariadne.com> In-Reply-To: <200606261853.k5QIrI7S020077@dragon.ariadne.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jun 2006 00:47:47.0452 (UTC) FILETIME=[4F2973C0:01C69983] DKIM-Signature: a=rsa-sha1; q=dns; l=1479; t=1151369268; x=1152233268; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20AW=3A=20[Sip]=20updated=20GRUU=20spec; X=v=3Dcisco.com=3B=20h=3DcN1Z87nH19kyfpb2ky1su4AHHMc=3D; b=um0fgiRVH23G6bmktdVOKxSYAQs+xzMfhgmAQ7EwlgFe8ftisy1fMjq1puoZkzBnL3iIXmhC ZrXA6jYf5cYkPaDgVp09IPlsz4OAcvIIG8PErTveI8XRWH5zs5agle8X; Authentication-Results: sj-dkim-5.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dale is, of course, correct here. Proxy-Require is not needed with GRUU. Thanks, Jonathan R. Dale.Worley@comcast.net wrote: > From: "Lu, Yang, VF-DE" > > Is it a correct understanding that when a UA applies gruu extension > to any requests including the REGISTER request, it DOES NOT need to > use the Proxy-Require header field to insist that any proxies that > are traversed understand gruu? > > Yes, that is correct. Only the Registrar (the UAC of the REGISTER > request) needs to understand the gruu extension. > > Of course, any proxy that is allowed to translate the GRUU URI to its > contact URI must understand the special rules for doing so, but the > fact that the corresponding Registrar issues GRUUs is evidence that > the proxy can do so. > > Dale > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 27 00:25:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv577-0004l1-7x; Tue, 27 Jun 2006 00:23:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv575-0004kw-Qy for sip@ietf.org; Tue, 27 Jun 2006 00:23:47 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv574-0005iK-7B for sip@ietf.org; Tue, 27 Jun 2006 00:23:47 -0400 Received: from [192.168.1.4] (65-65-155-30.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5R4PK4o021353 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 26 Jun 2006 23:25:22 -0500 Mime-Version: 1.0 (Apple Message framework v750) To: IETF SIP List Message-Id: <126E316F-0AB2-4927-9B68-4F7189FE5B40@softarmor.com> From: Dean Willis Date: Mon, 26 Jun 2006 23:23:40 -0500 X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e Subject: [Sip] Revised Agenda, SIP at IETF 66 X-BeenThere: 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="===============1440084301==" Errors-To: sip-bounces@ietf.org --===============1440084301== Content-Type: multipart/alternative; boundary=Apple-Mail-1--871154567 --Apple-Mail-1--871154567 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed New draft agenda for SIP. Note that the days have changed and we now have room numbers. Draft Agenda for SIP at IETF 66 Session 1, Monday 1300-1500 Room 520DEF Time Topic Discussion Leaders Reading List 1300 Agenda Bash, Announcements and Status Chairs This Doc 1305 Outbound Cullen Jennings draft-ietf-sip-outbound-04 1320 Outbound Discovery Migurl Garcia for Erkki Koivusalo draft-koivusalo-sip-outbound-discovery-01 1335 Outbound Midcall Issues Kevin Johns draft-johns-sip-outbound- middialog-draft-00 1340 Connection Reuse Vijay Gurbani Rohan Mahy draft-ietf-sip-connect-reuse-05 1400 Location Conveyance James Polk draft-ietf-sip-location- conveyance-03 1415 SAML for SIP James Polk Hannes Tschofenig draft-ietf-sip-saml-00 1430 Certificates. Arboreal Rodents Or Fruitless Canine Vocalization? Jason Fischl draft-ietf-sip- certs-01 1445 Hop Limit Diagnostics Is my bunny sick? Scott Lawrence draft-ietf-sip-hop-limit- diagnostics-03.txt Session 2, Wednesday 1300-1500 Room 520ABC Time Topic Discussion Leaders Reading List 1300 Agenda Bash Chairs This Doc 1305 Connected Identity John Elwell draft-ietf-sip-connected- identity-00 1330 Identity Co-Existence Jonathan rosenberg draft-rosenberg-sip- identity-coexistence-00 1340 Security Flows Robert Sparks draft-ietf-sip-sec-flows-01 1350 Fork loop fix Robert Sparks draft-ietf-sip-fork-loop-fix-02 1400 Feature list for advance specification Robert Sparks TBD 1410 Hitchhiker's Guide Jonathan Rosenberg draft-ietf-sip- hitchhikers-guide-00 1425 SIPS: Guidelines Francois Audet draft-audet-sip-sips- guidelines-02 1445 Improved TLS Requirements Vijay Gurbani draft-gurbani-sip- sipsec-00 --Apple-Mail-1--871154567 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

New draft agenda for SIP. = Note that the days have changed and we now have room = numbers.


Draft Agenda for SIP at = IETF 66

Session 1, Monday 1300-1500 Room = 520DEF

Time Topic Discussion Leaders Reading = List

1300 Agenda Bash, Announcements and Status Chairs This Doc
1305 Outbound Cullen Jennings draft-ietf-sip-outbound-04
1320 Outbound Discovery Migurl Garcia = for
Erkki Koivusalo draft-koivusalo-sip-outbound-discovery-01
<= DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px; ">1335 Outbound Midcall Issues Kevin Johns draft-johns-sip-outbound-middialog-draft-00
1340 Connection Reuse Vijay Gurbani
Rohan = Mahy = draft-ietf-sip-connect-reuse-05
1400 Location Conveyance James Polk draft-ietf-sip-location-conveyance-03
1415 SAML for SIP James Polk
Hannes = Tschofenig draft-ietf-sip-saml-00
1430 Certificates. Arboreal Rodents
Or=A0 Fruitless Canine = Vocalization? Jason Fischl draft-ietf-sip-certs-01
1445 Hop Limit Diagnostics
Is my bunny sick? Scott Lawrence = = draft-ietf-sip-hop-limit-diagnostics-03.txt

Session 2, Wednesday 1300-1500 Room = 520ABC

Time Topic Discussion Leaders Reading = List

1300 Agenda Bash Chairs This Doc
1305 Connected Identity = = John Elwell = = draft-ietf-sip-connected-identity-00
1330 Identity Co-Existence Jonathan rosenberg = = draft-rosenberg-sip-identity-coexistence-00
1340 Security Flows Robert Sparks draft-ietf-sip-sec-flows-01
1350 Fork loop fix Robert Sparks draft-ietf-sip-fork-loop-fix-02
1400 Feature list for advance specification Robert Sparks TBD
1410 Hitchhiker's Guide Jonathan Rosenberg = = draft-ietf-sip-hitchhikers-guide-00
1425 SIPS: Guidelines Francois Audet draft-audet-sip-sips-guidelines-02
1445 Improved TLS Requirements Vijay Gurbani draft-gurbani-sip-sipsec-00
= --Apple-Mail-1--871154567-- --===============1440084301== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1440084301==-- From sip-bounces@ietf.org Tue Jun 27 00:25:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv57L-00054M-4t; Tue, 27 Jun 2006 00:24:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv57K-00051i-Ex for sip@ietf.org; Tue, 27 Jun 2006 00:24:02 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv57I-0005iS-Rf for sip@ietf.org; Tue, 27 Jun 2006 00:24:02 -0400 Received: (qmail 16883 invoked by uid 0); 27 Jun 2006 04:21:33 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 27 Jun 2006 04:21:33 -0000 Message-ID: <001e01c699a1$2bc8c480$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Cullen Jennings" Subject: Re: [Sip] draft-ietf-sip-certs-00, communicating private keys and self-signed certificates Date: Tue, 27 Jun 2006 06:21:32 +0200 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.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: sip@ietf.org, Paul Kyzivat , Michael Thomas X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org And in addition: when generating self-signed certificates, have the UA include the GRUU in the certificate Jeroen > Cullen, > > >> >> Some (not all deployments) will have multiple devices registered to one >> AOR. The original draft had each device have it's own asymmetric key >> pair and if someone wanted to encrypt a message for the AOR, the message >> was encrypted with a symmetric key then the symmetric key was included >> in the message and encrypted with asymmetric keys for *every* device on >> that AOR. The WG decided this was not feasible and it would be better to >> have the devices share the asymmetric key so there was only one to deal >> with. >> > > I agree that this would not be feasible. I was thinking that for a > multi-device scenario where encryption (and not TLS) is required, the > "caller" could discover GRUUs for all currently registered devices (eg > using presence), select one (perhaps guided in some way by preferences of > the callee, say q-value ordering), and then encrypt specifically for that > device > > Slightly less flexible than having one cert per user, but better than > encrypting a symmetric key for each potential device as you sketch above > >> The draft in no way mandates that a deployment move around private keys >> over the network - deployments and users are allowed to do it any way >> they want including: >> >> 1) just say no and do one device >> 2) just say no and use some other way (like a crypto smart card) to move >> the private key around >> 3) use some other sacred framework to move the private key around >> 4) use the certs approach to store the private key on a server but the >> private key would be encrypted such that the severer could never decrypt >> it and only the clients would have the passphrase to decrypt >> 5) user the certs approach where the server knows the private key >> 6) user the certs approach where the server generates the private key >> (and knows it) so clients don't >> >> These are listed in what is probably close to order of what is most >> secure (i.e. 1 is most secure, 6 least) although the later ones may be >> more convenient. >> > > To me, some text like the above would be good to put in the draft > > Regards, > > Jeroen > >> Cullen >> >> >> >> On Jun 20, 2006, at 2:05 PM, Jeroen van Bemmel wrote: >> >>> >>> ----- Original Message ----- From: "Michael Thomas" >>> To: "Paul Kyzivat" >>> Cc: "Jeroen van Bemmel" ; >>> Sent: Tuesday, June 20, 2006 10:05 PM >>> Subject: Re: [Sip] draft-ietf-sip-certs-00, communicating private keys >>> and self-signed certificates >>> >>> >>>> Paul Kyzivat wrote: >>>> >>>>> >>>>> >>>>> Jeroen van Bemmel wrote: >>>>> >>>>>> If a dog barks at a tree and no-one hears it, did the dog make a >>>>>> sound? >>>>>> >>>>>> OK, leaving aside the dogs and the trees for the moment, a short >>>>>> question about the contents: >>>>>> The draft states "The certificates discussed in this draft are >>>>>> generally self signed". It then talks about how the credential >>>>>> service can be used to obtain the credentials using an authenticated >>>>>> SUBSCRIBE/NOTIFY sequence. >>>>>> >>>>>> What puzzles me: why would a UA use the credential service to obtain >>>>>> a previously submitted self-signed certificate, instead of simply >>>>>> generating a new one by itself? >>>>> >>>>> >>>>> Because several UAs share the same AOR and they all want to use a >>>>> common cert? >>>> >>>> Let us keep in mind that a certificate is nothing more than a key to >>>> identity >>>> binding. There is absolutely nothing wrong with having multiple keys >>>> being >>>> able to assert a given binding. Private keys should be thought of as >>>> roach motels: >>>> they check in, but they don't check out. >>>> >>> >>> My thinking was that for some use cases (perhaps not all, e.g. not for >>> the example in section 9.1) a user could obtain a list of certificates >>> (or perhaps only their fingerprints) from the credential service. The >>> UAC would then setup a TLS connection, and verify that the certificate >>> presented by the other side is in the list. >>> >>> In this way, perhaps one could avoid sending private credentials across >>> the network altogether. >>> >>> Small question on the Security considerations: it says 200 responses >>> are omitted because "they do not have much to do with the overall >>> security" - what about mutual authentication, using >>> Authentication-Info? Should mutual authentication be RECOMMENDED, or >>> would that be overkill (given that the TLS server cert is also >>> verified)? >>> >>> Regards, >>> >>> jeroen >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 27 09:31:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvDdH-0000XM-KA; Tue, 27 Jun 2006 09:29:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvDdG-0000XH-2b for sip@ietf.org; Tue, 27 Jun 2006 09:29:34 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvDdE-0007IJ-Ps for sip@ietf.org; Tue, 27 Jun 2006 09:29:34 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 27 Jun 2006 06:29:33 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,180,1149490800"; d="scan'208"; a="30563845:sNHT21686066" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5RDTWnq003038; Tue, 27 Jun 2006 09:29:32 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Jun 2006 09:29:32 -0400 Received: from [161.44.79.149] ([161.44.79.149]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Jun 2006 09:29:31 -0400 Message-ID: <44A132BB.8050009@cisco.com> Date: Tue, 27 Jun 2006 09:29:31 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] draft-ietf-sip-certs-00, communicating private keys and self-signed certificates References: <001e01c699a1$2bc8c480$31713b51@BEMBUSTER> In-Reply-To: <001e01c699a1$2bc8c480$31713b51@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jun 2006 13:29:31.0810 (UTC) FILETIME=[B9150820:01C699ED] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Cullen Jennings , sip@ietf.org, Michael Thomas X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel wrote: > And in addition: when generating self-signed certificates, have the UA > include the GRUU in the certificate [snip] >> I agree that this would not be feasible. I was thinking that for a >> multi-device scenario where encryption (and not TLS) is required, the >> "caller" could discover GRUUs for all currently registered devices (eg >> using presence), select one (perhaps guided in some way by preferences >> of the callee, say q-value ordering), and then encrypt specifically >> for that device >> >> Slightly less flexible than having one cert per user, but better than >> encrypting a symmetric key for each potential device as you sketch above This would limit secure communication to cases when the callee has presence and enough of a relationship with the caller to provide this much presence information to the caller. Disclosing the existence of particular devices, and how to reach them is not something that most people would do for arbitrary callers. 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 Tue Jun 27 09:39:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvDky-0006ab-3L; Tue, 27 Jun 2006 09:37:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvDkw-0006aW-CO for sip@ietf.org; Tue, 27 Jun 2006 09:37:30 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvDku-0007qp-QB for sip@ietf.org; Tue, 27 Jun 2006 09:37:30 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 27 Jun 2006 06:37:28 -0700 X-IronPort-AV: i="4.06,180,1149490800"; d="scan'208"; a="1833356282:sNHT35166940" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k5RDbSf6009585; Tue, 27 Jun 2006 06:37:28 -0700 Received: from [192.168.1.2] (sjc-vpn4-575.cisco.com [10.21.82.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5RDb4CV000318; Tue, 27 Jun 2006 06:37:27 -0700 (PDT) In-Reply-To: <712F326A-E8D9-48A0-8CE6-C47C0886D9A6@softarmor.com> References: <475FF955A05DD411980D00508B6D5FB00C29092C@en0033exch001u.uk.lucent.com> <04B39538-2384-4B5B-81EE-F07703A66744@cisco.com> <712F326A-E8D9-48A0-8CE6-C47C0886D9A6@softarmor.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] draft-ietf-sip-gruu-09.txt ready for IESG? Date: Tue, 27 Jun 2006 06:37:29 -0700 To: Dean Willis X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=7348; t=1151415448; x=1152279448; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20draft-ietf-sip-gruu-09.txt=20ready=20for=20IESG?; X=v=3Dcisco.com=3B=20h=3D3Voi9Y8hSsQQL9aCaBYdTQZXOfw=3D; b=gflSWnZml/ldwRJ66xzcIjp3ZQDlb2L3wnNJ9bqmctxGnqtA3y7wS6A3ZRBeepa9lqHBnWtK xMDUZF4r5ic+7T221DngXjaYc5/aXPNV6Ua+rjrCCyTseoe+t973QLlT; Authentication-Results: sj-dkim-2.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: IETF SIP List , Keith Drage X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The last WGLC ended July 17th, July 2004. I have no opinion on if the document is ready for WGLC - I have not reviewed it. But if you guys think it is, or Jonathan thinks it is, then I would totally be willing to believe it is ready for another WGLC. I have no problem with folks saying this document is ready to go - I'm downright ecstatic about that. My personal opinion is that it does need another WGLC with a reasonable amount of time tat takes into account that it is a very important, very large, very complicated document that has had many controversial changes. From a formal process point of view, I believe it is the Chairs decision when or if a document gets WGLC and they can choose not to if they want. If people had fixed some typos and added an example since the last WGLC, I would not care about review of it but I think this has had substantial changes. On Jun 26, 2006, at 12:01 PM, Dean Willis wrote: > > The way I look at it is the draft is still in WGLC, and has been > since last year. We never terminated its WGLC state, although the > document was revised three times during WGLC. > > Now, if you think that we need more detailed review of specific new > material in this version draft before we complete WGLC, that's fine > and probably very reasonable, and should be done as part of the > ongoing WGLC. That's what Keith was asking -- if you don't think > it's ready (and you don't) please let us know. > > So, I'll log this as a request to do a structured review of the > latest GRUU draft before completing WGLC and sending the doc to the > IESG. > > -- > Dean > > > On Jun 26, 2006, at 11:32 AM, Cullen Jennings wrote: > >> >> (This email sent purely with my individual contributor hat on) >> >> This draft has had substantial changes since it was last WGLC >> (which was an apreviated WGLC at that). We are not talking about >> some typos were fixed - an extra 20 pages of text got added. The >> discution got very detailed and many people decided to wait and >> review all the changes it once it was done. Technically I doubt >> the WG needs to ever WGLC any document but the RAI WGs have had a >> long tradition of using WGLC and I think people have come to >> expect them. I also beilve that they improve document quality and >> also help judge if their is consensus on work. I suspect that >> people would typically expect 2 weeks for something like this >> unless it corssed over a time like a IETF meeting or major holiday >> where they migth expect to add another week to account for that. >> >> The specific technical details that I think are worth of review >> are attached. I suspect I will have no problems with any of them >> but these are things I think we should review. >> >> >> >> >> >> >> >> On Jun 23, 2006, at 3:57 AM, Drage, Keith (Keith) wrote: >> >>> (As WG chair) >>> >>> The SIP WG chairs and the author all think this document is ready >>> for sending to the IESG. >>> >>> We have had WGLC announced 5th July 2004 to complete 17th July 2004. >>> We had a further last round of WG review requested 26th October >>> 2005 to complete 6th November 2005. >>> We have had significant discussion on the lists since then of >>> this draft, and discussion in SIP WG sessions, and all comments >>> have been resolved. >>> >>> If you believe this document IS NOT ready to send to IESG, can >>> you please indicate this to the list and the WG chairs by 12:00 >>> midday UK time (7:00 am US Eastern Time) on 30th June 2006, >>> giving technical justification for your objection. >>> >>> Please limit this thread to answering the question above. If you >>> have other discussion relating to GRUU generally, then please use >>> a different thread. >>> >>> regards >>> >>> Keith >>> >>> -----Original Message----- >>> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>> Sent: 22 June 2006 20:50 >>> To: i-d-announce@ietf.org >>> Cc: sip@ietf.org >>> Subject: [Sip] I-D ACTION:draft-ietf-sip-gruu-09.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 : Obtaining and Using Globally Routable User Agent (UA) >>> URIs (GRUU) in the Session Initiation Protocol (SIP) >>> Author(s) : J. Rosenberg >>> Filename : draft-ietf-sip-gruu-09.txt >>> Pages : 38 >>> Date : 2006-6-22 >>> >>> Several applications of the Session Initiation Protocol (SIP) >>> require >>> a user agent (UA) to construct and distribute a URI that can be used >>> by anyone on the Internet to route a call to that specific UA >>> instance. A URI that routes to a specific UA instance is called a >>> Globally Routable UA URI (GRUU). This document describes an >>> extension to SIP for obtaining a GRUU from a server and for >>> communicating a GRUU to a peer within a dialog. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-09.txt >>> >>> To remove yourself from the I-D Announcement list, send a message to >>> i-d-announce-request@ietf.org with the word unsubscribe in the >>> body of the message. >>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- >>> announce >>> to change your subscription settings. >>> >>> >>> Internet-Drafts are also available by anonymous FTP. Login with >>> the username >>> "anonymous" and a password of your e-mail address. After logging in, >>> type "cd internet-drafts" and then >>> "get draft-ietf-sip-gruu-09.txt". >>> >>> A list of Internet-Drafts directories can be found in >>> http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> >>> Internet-Drafts can also be obtained by e-mail. >>> >>> Send a message to: >>> mailserv@ietf.org. >>> In the body type: >>> "FILE /internet-drafts/draft-ietf-sip-gruu-09.txt". >>> >>> NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant mail >>> readers >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >>> >>> Date: June 23, 2006 3:57:23 AM PDT >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 27 10:04:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvE9R-000696-8K; Tue, 27 Jun 2006 10:02:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvE9P-00068z-NL; Tue, 27 Jun 2006 10:02:47 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvE9P-0000Ie-Bq; Tue, 27 Jun 2006 10:02:47 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k5RE2gI8026945; Tue, 27 Jun 2006 09:02:45 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 27 Jun 2006 15:02:42 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0134D1E61@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'sip@ietf.org'" Subject: RE: [Sip] draft-ietf-sip-gruu-09.txt ready for IESG? Date: Tue, 27 Jun 2006 15:02:41 +0100 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: 1676547e4f33b5e63227e9c02bd359e3 Cc: "'sip-chairs@ietf.org'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) I'm afraid I am going to have to ask you to be much more proactive on this question, as the IESG need something a little more positive from the WG. So... i) If you have thoroughly reviewed this, and as a result believe it is ready, and I know there are at least some of you out there who have torn GRUU to pieces, throughly digested it and put it back together again, then send Dean and myself an email to that effect at sip-chairs@ietf.org. ii) If you are intending to review this but want more time before responding, then also please say. Remember this document is still in the WGLC state. We trying to get it into the next state of IESG review. That means WG consensus that it is ready. Please try to respond by my original deadline of 30th June (although we may give a couple of extra days grace here). regards Keith > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: 23 June 2006 11:57 > To: 'sip@ietf.org' > Cc: 'sip-chairs@ietf.org' > Subject: [Sip] draft-ietf-sip-gruu-09.txt ready for IESG? > > > (As WG chair) > > The SIP WG chairs and the author all think this document is > ready for sending to the IESG. > > We have had WGLC announced 5th July 2004 to complete 17th July 2004. > We had a further last round of WG review requested 26th > October 2005 to complete 6th November 2005. > We have had significant discussion on the lists since then of > this draft, and discussion in SIP WG sessions, and all > comments have been resolved. > > If you believe this document IS NOT ready to send to IESG, > can you please indicate this to the list and the WG chairs by > 12:00 midday UK time (7:00 am US Eastern Time) on 30th June > 2006, giving technical justification for your objection. > > Please limit this thread to answering the question above. If > you have other discussion relating to GRUU generally, then > please use a different thread. > > regards > > Keith > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: 22 June 2006 20:50 > To: i-d-announce@ietf.org > Cc: sip@ietf.org > Subject: [Sip] I-D ACTION:draft-ietf-sip-gruu-09.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 : Obtaining and Using Globally Routable > User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP) > Author(s) : J. Rosenberg > Filename : draft-ietf-sip-gruu-09.txt > Pages : 38 > Date : 2006-6-22 > > Several applications of the Session Initiation Protocol (SIP) require > a user agent (UA) to construct and distribute a URI that can be used > by anyone on the Internet to route a call to that specific UA > instance. A URI that routes to a specific UA instance is called a > Globally Routable UA URI (GRUU). This document describes an > extension to SIP for obtaining a GRUU from a server and for > communicating a GRUU to a peer within a dialog. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-09.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in > the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-gruu-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-gruu-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 27 10:56:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvExK-0008U0-Ss; Tue, 27 Jun 2006 10:54:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvExJ-0008Hw-AM for sip@ietf.org; Tue, 27 Jun 2006 10:54:21 -0400 Received: from endor.rfc3261.net ([212.112.227.208]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvExH-0003WI-OY for sip@ietf.org; Tue, 27 Jun 2006 10:54:21 -0400 Received: from localhost (localhost [127.0.0.1]) by endor.rfc3261.net (Postfix) with ESMTP id A1BF1260233; Tue, 27 Jun 2006 16:54:18 +0200 (CEST) Received: from endor.rfc3261.net ([127.0.0.1]) by localhost (endor [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 27414-07; Tue, 27 Jun 2006 16:54:16 +0200 (CEST) Received: from hoth.office.iptelorg.de (unknown [217.9.54.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by endor.rfc3261.net (Postfix) with ESMTP id 2B5A6260232; Tue, 27 Jun 2006 16:54:16 +0200 (CEST) From: Nils Ohlmeier To: sip@ietf.org Subject: Re: [Sip] Anybody feeling a connection with "connect reuse"? Date: Tue, 27 Jun 2006 16:54:12 +0200 User-Agent: KMail/1.9.3 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606271654.12268.lists@ohlmeier.org> X-Virus-Scanned: by amavisd-new (Debian) at endor.rfc3261.net X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Rohan Mahy , Keith Drage , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Friday 23 June 2006 23:08, Dean Willis wrote: > We've been following the connection reuse draft, currently draft-ietf- > sip-connect-reuse-05.txt, for a long long time. > > We've slipped the charter delivery date several times. > > Are we ever going to finish this work? Do we need to finish this work? > > Is this something that we could just not do? > > > Otherwise said: "Does the SIP working group still have a consensus to > expend working group effort on connection reuse?" > > If you have an opinion, for or against, please let it be known on > this list. I think their are two options left: - either push it out as "TLS-connection-reuse-between-proxies" (if nobody comes up with any issue any more) - or drop it because the real world usage is too limited I have little preference for the first alternative, but wouldn't mind to go for the second option. Regards Nils _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 27 12:32:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvGSu-00035X-VO; Tue, 27 Jun 2006 12:31:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvGSt-000354-25 for sip@ietf.org; Tue, 27 Jun 2006 12:31:03 -0400 Received: from endor.rfc3261.net ([212.112.227.208]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvGSr-0005iY-PG for sip@ietf.org; Tue, 27 Jun 2006 12:31:03 -0400 Received: from localhost (localhost [127.0.0.1]) by endor.rfc3261.net (Postfix) with ESMTP id 32C32260233; Tue, 27 Jun 2006 18:31:01 +0200 (CEST) Received: from endor.rfc3261.net ([127.0.0.1]) by localhost (endor [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16040-03; Tue, 27 Jun 2006 18:30:56 +0200 (CEST) Received: from hoth.office.iptelorg.de (unknown [217.9.54.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by endor.rfc3261.net (Postfix) with ESMTP id 60515260232; Tue, 27 Jun 2006 18:30:56 +0200 (CEST) From: Nils Ohlmeier To: IETF SIP List , jon.peterson@neustar.biz Date: Tue, 27 Jun 2006 18:30:50 +0200 User-Agent: KMail/1.9.3 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200606271830.51055.lists@ohlmeier.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (Debian) at endor.rfc3261.net X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [Sip] Privacy in multi domain setups X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hello, does anybody have an idea or opinion what is best solution to get privacy according to RFC3323 working in a multi-domain setup? Scenario: I have a SIP proxy running which serves multiple domains (on one IP). If an INVITE (or any other request) comes in with anonymous@anonymous.invalid in the From header I currently see no way how I can determine if the caller is from one of my local domains or from a foreign domain. Or to say it in another way: as the request contains no information to which domain the caller belongs I can not challenge him (because I can not determine the correct realm). But if I do not challenge INVITEs from anonymous@anonymous.invalid then this is the perfect gate for SPIT. Do I overlook here something? Or does someone has a solution for this scenario? Thanks Nils Ohlmeier _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 27 14:19:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvI7a-0005hq-Kg; Tue, 27 Jun 2006 14:17:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvI7Z-0005gt-M4 for sip@ietf.org; Tue, 27 Jun 2006 14:17:09 -0400 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvI7X-0007pN-Fo for sip@ietf.org; Tue, 27 Jun 2006 14:17:09 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc11) with ESMTP id <20060627181706011006ad06e>; Tue, 27 Jun 2006 18:17:07 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k5RIH65n021771 for ; Tue, 27 Jun 2006 14:17:06 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k5RIH6VT021767; Tue, 27 Jun 2006 14:17:06 -0400 Date: Tue, 27 Jun 2006 14:17:06 -0400 Message-Id: <200606271817.k5RIH6VT021767@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <200606271830.51055.lists@ohlmeier.org> Subject: Re: [Sip] Privacy in multi domain setups References: <200606271830.51055.lists@ohlmeier.org> X-Spam-Score: 0.2 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Nils Ohlmeier Or to say it in another way: as the request contains no information to which domain the caller belongs I can not challenge him (because I can not determine the correct realm). But if I do not challenge INVITEs from anonymous@anonymous.invalid then this is the perfect gate for SPIT. I take it you have too many realms to just include a Proxy-Authenticate for each one of them? Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 27 14:42:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvIU9-0005Vc-Na; Tue, 27 Jun 2006 14:40:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvIU7-0005VW-Mo for sip@ietf.org; Tue, 27 Jun 2006 14:40:27 -0400 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvIU6-0001Yh-Fb for sip@ietf.org; Tue, 27 Jun 2006 14:40:27 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc13) with ESMTP id <2006062718402401300b1pmre>; Tue, 27 Jun 2006 18:40:24 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k5RIeN5n022349 for ; Tue, 27 Jun 2006 14:40:23 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k5RIeNB4022345; Tue, 27 Jun 2006 14:40:23 -0400 Date: Tue, 27 Jun 2006 14:40:23 -0400 Message-Id: <200606271840.k5RIeNB4022345@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <44A07F72.7050902@cisco.com> (jdrosen@cisco.com) Subject: Re: [Sip] GRUU record-routing References: <200606262158.k5QLw8wq024605@dragon.ariadne.com> <44A07F72.7050902@cisco.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Jonathan Rosenberg > - It seems to me that the home proxy could avoid record-routing a > terminating request if it knows that no further proxy to the > ultimate UA will record-route. Similarly, a home proxy could avoid > record-routing an originating request if there are no preceding > record-routes on the request. (In either case, the request would be > processed in the same way as is now prescribed by 8.2.2/8.2.3.) So > these requirements don't *have* to be MUST-strength. The trick is the little oracle function which requires the proxy to know two things, (1) that no downstream proxy is going to record-route, and that (2) the UA is going to insert a gruu into the contact. The last one in particular has been troubling to gaurantee. You're looking at solving routing problems even when the UAS isn't using a GRUU as its Contact value. I hadn't thought of that. For instance, the proxy might know that the UA's registered contact is globally routable. Since, when there is a gruu, the request is GOING to hit the home proxy anyway, it makes sense to have it always record-route. I see your point -- avoiding record-routing in the circumstances where it isn't strictly necessary isn't likely to save much work. > - For 8.2.2 to have the desired effect for originating requests, it > seems we must require that if any previous proxy record-routes > itself, then the request must go through a home proxy for > record-routing before going on to the greater Internet. (That is > necessary, but not implied by the other SIP rules, in some weird > cases. E.g., if the home proxy and the Internet-side interface of > the edge router are globally addressable, but the UA-side interface > of the edge router is not globally addressable.) So I think an > additional MUST is needed here. That is a good point; the spec is assuming originating requests will go through the home proxy. Things work fine if any of the proxies on the record-routing chain in the outbound direction are capable of translating the GRUU. What gives me pause is that this is a requirement on the UAs, that they use an "outbound proxy", but we haven't stated it explicitly as such. A home proxy can use mechanisms such as Service-Route or UA configuration to ensure that it is on the outgoing request path. Should we require that proxies/UAs implement RFC 3608? If the proxy does not provide a Service-Route, should we require that the UA send the request to the service address for the domain in the GRUU it is using as its Contact? Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 27 14:51:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvIdJ-0004us-1P; Tue, 27 Jun 2006 14:49:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvIdI-0004uf-0X for sip@ietf.org; Tue, 27 Jun 2006 14:49:56 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvIdG-0002lq-JQ for sip@ietf.org; Tue, 27 Jun 2006 14:49:55 -0400 Received: (qmail 426 invoked by uid 0); 27 Jun 2006 18:49:47 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 27 Jun 2006 18:49:47 -0000 Message-ID: <001401c69a1a$78c52110$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Paul Kyzivat" References: <001e01c699a1$2bc8c480$31713b51@BEMBUSTER> <44A132BB.8050009@cisco.com> Subject: Re: [Sip] draft-ietf-sip-certs-00, communicating private keys and self-signed certificates Date: Tue, 27 Jun 2006 20:49:50 +0200 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.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Cullen Jennings , sip@ietf.org, Michael Thomas X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul, I wasn't suggesting it as a one-size-fits-all approach. No need to make it mandatory, but it would be nice if we could *enable* it (adding a 7th point to Cullen's list of possible uses) For example (not exhaustive): - Section 7.5: NOTIFY bodies - Suggestion to allow MIME/multipart or perhaps some other format to allow a list of certificates to be returned for a user - Section 10.6 : "The subjectAltName must have a URI type that is set to the SIP URL corresponding to the user AOR." Suggestion is to allow a GRUU here too With a GRUU in the subjectAltName it would work even without Presence. And if you're worried about disclosing that... well, then we could use the magic of TRUUs... Regards, Jeroen > > > Jeroen van Bemmel wrote: >> And in addition: when generating self-signed certificates, have the UA >> include the GRUU in the certificate > [snip] >>> I agree that this would not be feasible. I was thinking that for a >>> multi-device scenario where encryption (and not TLS) is required, the >>> "caller" could discover GRUUs for all currently registered devices (eg >>> using presence), select one (perhaps guided in some way by preferences >>> of the callee, say q-value ordering), and then encrypt specifically for >>> that device >>> >>> Slightly less flexible than having one cert per user, but better than >>> encrypting a symmetric key for each potential device as you sketch above > > This would limit secure communication to cases when the callee has > presence and enough of a relationship with the caller to provide this much > presence information to the caller. Disclosing the existence of particular > devices, and how to reach them is not something that most people would do > for arbitrary callers. > > 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 Tue Jun 27 16:23:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvJax-0000yI-86; Tue, 27 Jun 2006 15:51:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvJZY-00063A-Dw; Tue, 27 Jun 2006 15:50:08 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvJZU-0001OK-7X; Tue, 27 Jun 2006 15:50:08 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5RJo2UA002947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Jun 2006 19:50:03 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvJZS-0005Hr-I1; Tue, 27 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 27 Jun 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-fork-loop-fix-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies Author(s) : R. Sparks, et al. Filename : draft-ietf-sip-fork-loop-fix-02.txt Pages : 13 Date : 2006-6-27 This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address a security vulnerability identified in SIP proxy behavior. This vulnerability enables an attack against SIP networks where a small number of legitimate, even authorized, SIP requests can stimulate massive amounts of proxy-to-proxy traffic. This document strengthens loop-detection requirements on SIP proxies when they fork requests (that is, forward a request to more than one destination). It also corrects and clarifies the description of the loop-detection algorithm such proxies are required to implement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-fork-loop-fix-02.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-fork-loop-fix-02.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-fork-loop-fix-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-27132112.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-fork-loop-fix-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-fork-loop-fix-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-27132112.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Tue Jun 27 16:32:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvJlD-0005Ix-91; Tue, 27 Jun 2006 16:02:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvJiW-0001xF-RT for sip@ietf.org; Tue, 27 Jun 2006 15:59:24 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvJiU-0003lc-UZ for sip@ietf.org; Tue, 27 Jun 2006 15:59:24 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 27 Jun 2006 12:58:22 -0700 X-IronPort-AV: i="4.06,183,1149490800"; d="scan'208"; a="301885930:sNHT32650816" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k5RJwMv7030294; Tue, 27 Jun 2006 12:58:22 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5RJwKCY009322; Tue, 27 Jun 2006 12:58:21 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Jun 2006 15:58:21 -0400 Received: from [161.44.79.149] ([161.44.79.149]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Jun 2006 15:58:20 -0400 Message-ID: <44A18DDC.1060206@cisco.com> Date: Tue, 27 Jun 2006 15:58:20 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] draft-ietf-sip-certs-00, communicating private keys and self-signed certificates References: <001e01c699a1$2bc8c480$31713b51@BEMBUSTER> <44A132BB.8050009@cisco.com> <001401c69a1a$78c52110$31713b51@BEMBUSTER> In-Reply-To: <001401c69a1a$78c52110$31713b51@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jun 2006 19:58:20.0728 (UTC) FILETIME=[0A336B80:01C69A24] DKIM-Signature: a=rsa-sha1; q=dns; l=2302; t=1151438302; x=1152302302; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20draft-ietf-sip-certs-00, =09communicating=20private=20key s=20and=0A=20self-signed=20certificates; X=v=3Dcisco.com=3B=20h=3DJX3H7HQv8xU2yHo0OOpBNlNA/pw=3D; b=FoOYIskZe/BKESAENm1/ZoipNPxz6KUFWQ4KzRERIxgoVdxLqzSY0WfY+6ZocevtgIjZYUwA HKqWmhIxeC0GY/lLLuotUe9JX0bJxhLWcy0nEFDn4n/WmMVN8eqKExhn; Authentication-Results: sj-dkim-1.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Cullen Jennings , sip@ietf.org, Michael Thomas X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel wrote: > Paul, > > I wasn't suggesting it as a one-size-fits-all approach. No need to make > it mandatory, but it would be nice if we could *enable* it (adding a 7th > point to Cullen's list of possible uses) As just another option I guess this is ok. Paul > For example (not exhaustive): > - Section 7.5: NOTIFY bodies - Suggestion to allow MIME/multipart or > perhaps some other format to allow a list of certificates to be returned > for a user > - Section 10.6 : "The subjectAltName must have a URI type that is set to > the SIP URL corresponding to the user AOR." > Suggestion is to allow a GRUU here too > > With a GRUU in the subjectAltName it would work even without Presence. > And if you're worried about disclosing that... well, then we could use > the magic of TRUUs... > > Regards, > > Jeroen > > >> >> >> Jeroen van Bemmel wrote: >>> And in addition: when generating self-signed certificates, have the >>> UA include the GRUU in the certificate >> [snip] >>>> I agree that this would not be feasible. I was thinking that for a >>>> multi-device scenario where encryption (and not TLS) is required, >>>> the "caller" could discover GRUUs for all currently registered >>>> devices (eg using presence), select one (perhaps guided in some way >>>> by preferences of the callee, say q-value ordering), and then >>>> encrypt specifically for that device >>>> >>>> Slightly less flexible than having one cert per user, but better >>>> than encrypting a symmetric key for each potential device as you >>>> sketch above >> >> This would limit secure communication to cases when the callee has >> presence and enough of a relationship with the caller to provide this >> much presence information to the caller. Disclosing the existence of >> particular devices, and how to reach them is not something that most >> people would do for arbitrary callers. >> >> 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 27 16:33:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKDi-0001AG-Ea; Tue, 27 Jun 2006 16:31:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKDg-00019X-Ju for sip@ietf.org; Tue, 27 Jun 2006 16:31:36 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvKDf-0006Rx-95 for sip@ietf.org; Tue, 27 Jun 2006 16:31:36 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k5RKVW002378 for ; Tue, 27 Jun 2006 16:31:33 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 27 Jun 2006 15:31:07 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60CEF2161@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Any interest of cipher-suite / security Level Thread-Index: AcaaKJ5Uvh9OwM+MSxKElaMJnjXJhQ== From: "Samir Srivastava" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: [Sip] Any interest of cipher-suite / security Level X-BeenThere: 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="===============0660066516==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0660066516== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69A28.9F4EF42C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69A28.9F4EF42C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I submitted an ID for cipher -suite issues. http://www.ietf.org/internet-drafts/draft-srivastava-sip-e2e-ciphersuite s-00.txt=20 This ID fixes the issues from retargeting of SIPS to SIP, SIP over TLS etc issues cleanly with the clear definition of security. Is there working group interest on progressing this work or not ? Thx Samir ------_=_NextPart_001_01C69A28.9F4EF42C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Any interest of cipher-suite / security Level

Hi,

   I submitted an ID for = cipher -suite issues.

http://www.ietf.org/internet-drafts/draft-srivastava-sip-e= 2e-ciphersuites-00.txt =

   This ID fixes the issues = from retargeting of SIPS to SIP, SIP over TLS  etc issues cleanly = with the clear definition of security.

   Is there working group = interest on progressing this work or not ?

Thx
Samir

------_=_NextPart_001_01C69A28.9F4EF42C-- --===============0660066516== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0660066516==-- From sip-bounces@ietf.org Tue Jun 27 16:44:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKOK-000585-QO; Tue, 27 Jun 2006 16:42:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKOI-00052V-O9; Tue, 27 Jun 2006 16:42:34 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvJwV-0005RX-7S; Tue, 27 Jun 2006 16:13:51 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=willow.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvJZT-0003U5-2Y; Tue, 27 Jun 2006 15:50:12 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5RJo29F012483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvJZS-0005Hu-IX; Tue, 27 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 27 Jun 2006 15:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-sec-flows-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: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Example call flows using Session Initiation Protocol (SIP) security mechanisms Author(s) : C. Jennings, et al. Filename : draft-ietf-sip-sec-flows-01.txt Pages : 45 Date : 2006-6-27 This document shows example call flows demonstrating the use of Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail Extensions (S/MIME) in Session Initiation Protocol (SIP). It also provides information that helps implementers build interoperable SIP software. To help facilitate interoperability testing, it includes certificates used in the example call flows and processes to create certificates for testing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-sec-flows-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-sec-flows-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-sec-flows-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-27132650.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-sec-flows-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-sec-flows-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-27132650.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Tue Jun 27 17:50:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvLQ5-0001ia-0I; Tue, 27 Jun 2006 17:48:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvLQ3-0001i4-VE for sip@ietf.org; Tue, 27 Jun 2006 17:48:27 -0400 Received: from py-out-1112.google.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvLQ2-0000Ha-NM for sip@ietf.org; Tue, 27 Jun 2006 17:48:27 -0400 Received: by py-out-1112.google.com with SMTP id d42so2088171pyd for ; Tue, 27 Jun 2006 14:48:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PMDBnK8uipf+raa+4KwqPMaMFYy5MDFgX3TADgr98Sf0Owi3ibkU5gqhxGbCHNBcHNuS/O+HCNhLpEucVmAHpMylO57GOX8aXuf9432VgU3H996hvWfp3SiHCh5iHnUQLhjtUhzHfLIQJGorQjO5STvyejahxn+7IJSDXK6CYFk= Received: by 10.35.83.6 with SMTP id k6mr80602pyl; Tue, 27 Jun 2006 14:48:26 -0700 (PDT) Received: by 10.35.81.17 with HTTP; Tue, 27 Jun 2006 14:48:26 -0700 (PDT) Message-ID: <953beacc0606271448o69dad2e8ibafc83300e835f46@mail.gmail.com> Date: Tue, 27 Jun 2006 14:48:26 -0700 From: "Rohan Mahy" To: "Jeroen van Bemmel" Subject: Re: [Sip] draft-ietf-sip-certs-00, communicating private keys and self-signed certificates In-Reply-To: <002401c693c8$aab13400$31713b51@BEMBUSTER> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <002401c693c8$aab13400$31713b51@BEMBUSTER> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jeroen, Paul K got the right answer here but didn't explain why they want a common cert: >Because several UAs share the same AOR and they >all want to use a common cert? The reason they want a common cert is so a peer can encrypt messages for their AOR that can be read ANY of the those several UA instances. thanks, -rohan On 6/19/06, Jeroen van Bemmel wrote: > > > If a dog barks at a tree and no-one hears it, did the dog make a sound? > > OK, leaving aside the dogs and the trees for the moment, a short question > about the contents: > The draft states "The certificates discussed in this draft are generally > self signed". It then talks about how the credential service can be used to > obtain the credentials using an authenticated SUBSCRIBE/NOTIFY sequence. > > What puzzles me: why would a UA use the credential service to obtain a > previously submitted self-signed certificate, instead of simply generating a > new one by itself? > > Regards, > > Jeroen > > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on > current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 27 18:24:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvLwv-0003NA-TO; Tue, 27 Jun 2006 18:22:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvLwv-0003Jh-3L for sip@ietf.org; Tue, 27 Jun 2006 18:22:25 -0400 Received: from rwcrmhc13.comcast.net ([216.148.227.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvLwt-0003O8-S1 for sip@ietf.org; Tue, 27 Jun 2006 18:22:25 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc13) with ESMTP id <20060627222222m13006mb9ke>; Tue, 27 Jun 2006 22:22:22 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k5RMML5n027575 for ; Tue, 27 Jun 2006 18:22:21 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k5RMMLak027571; Tue, 27 Jun 2006 18:22:21 -0400 Date: Tue, 27 Jun 2006 18:22:21 -0400 Message-Id: <200606272222.k5RMMLak027571@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <953beacc0606271456y1d93f822w13d482679b22a627@mail.gmail.com> (rohan.mahy@gmail.com) Subject: Re: [Sip] GRUU record-routing References: <200606262158.k5QLw8wq024605@dragon.ariadne.com> <44A07F72.7050902@cisco.com> <200606271840.k5RIeNB4022345@dragon.ariadne.com> <953beacc0606271456y1d93f822w13d482679b22a627@mail.gmail.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Rohan Mahy" While I hope that eventually they willl start using the SIP configuration framework to get this kind of information, I am fine with them continuing to user service-route. Isn't the configuration framework less standardized than Service-Route? Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 27 18:40:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvMD4-0005o1-8O; Tue, 27 Jun 2006 18:39:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvMD2-0005n3-Lx for sip@ietf.org; Tue, 27 Jun 2006 18:39:04 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvLpl-0002er-Os for sip@ietf.org; Tue, 27 Jun 2006 18:15:01 -0400 Received: from py-out-1112.google.com ([64.233.166.180]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvLXg-0003Um-4f for sip@ietf.org; Tue, 27 Jun 2006 17:56:23 -0400 Received: by py-out-1112.google.com with SMTP id d42so2090457pyd for ; Tue, 27 Jun 2006 14:56:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sudSQqlPYJJizJQCD0ibDuzLRz5T3VtnyyIwCd0wol1qjtTEa3CGjsZuzbziwGF7jUYjWyF+1xri9uk46ylN2SgYj23h7NKLe16Q7iMiAAodl3/sCI4jLoDqATbDB5ap60j5JVM9Q3CMRopuMIPJK7xR8pMXi1ytXG/UsFeItvc= Received: by 10.35.83.6 with SMTP id k6mr61625pyl; Tue, 27 Jun 2006 14:56:17 -0700 (PDT) Received: by 10.35.81.17 with HTTP; Tue, 27 Jun 2006 14:56:17 -0700 (PDT) Message-ID: <953beacc0606271456y1d93f822w13d482679b22a627@mail.gmail.com> Date: Tue, 27 Jun 2006 14:56:17 -0700 From: "Rohan Mahy" To: "Dale.Worley@comcast.net" Subject: Re: [Sip] GRUU record-routing In-Reply-To: <200606271840.k5RIeNB4022345@dragon.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200606262158.k5QLw8wq024605@dragon.ariadne.com> <44A07F72.7050902@cisco.com> <200606271840.k5RIeNB4022345@dragon.ariadne.com> X-Spam-Score: -2.4 (--) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 6/27/06, Dale.Worley@comcast.net wrote: > A home proxy can use mechanisms such as Service-Route target="RFC3608"/> or UA configuration to ensure that it is on the > outgoing request path. > > Should we require that proxies/UAs implement RFC 3608? > > If the proxy does not provide a Service-Route, should we require that > the UA send the request to the service address for the domain in the > GRUU it is using as its Contact? Hi, I think requiring RFC 3608 is a terrible idea. There is a community that is using service-route today. While I hope that eventually they willl start using the SIP configuration framework to get this kind of information, I am fine with them continuing to user service-route. I don't want service-route leaking out into the rest of the Internet however. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 27 19:02:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvMXZ-0005ys-MN; Tue, 27 Jun 2006 19:00:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvMXX-0005xI-NQ for sip@ietf.org; Tue, 27 Jun 2006 19:00:15 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvLpb-0002er-4G for sip@ietf.org; Tue, 27 Jun 2006 18:14:51 -0400 Received: from py-out-1112.google.com ([64.233.166.181]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvLfu-0003bM-Dc for sip@ietf.org; Tue, 27 Jun 2006 18:04:52 -0400 Received: by py-out-1112.google.com with SMTP id d42so2092704pyd for ; Tue, 27 Jun 2006 15:04:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=I65ps5lkOyV3/rvrNeZ25cOTk/88yu5QsxnhD2nqhgGGu3y3ghLq9KwcFiamQjBHDN8et30lMQUtMl2bsDeudmHxtY4G94QILiVPtjmMIElVcK8ohCC+Dm2bJ3PhSzITsIHHqRlx9Z5NSaY331K3Xjp8pcBkZHnWOLU+J8Y78Uc= Received: by 10.35.82.15 with SMTP id j15mr75444pyl; Tue, 27 Jun 2006 15:04:49 -0700 (PDT) Received: by 10.35.81.17 with HTTP; Tue, 27 Jun 2006 15:04:49 -0700 (PDT) Message-ID: <953beacc0606271504g3fc14377k385d47cb237b6374@mail.gmail.com> Date: Tue, 27 Jun 2006 15:04:49 -0700 From: "Rohan Mahy" To: "Dean Willis" Subject: Re: [Sip] Revised Agenda, SIP at IETF 66 In-Reply-To: <126E316F-0AB2-4927-9B68-4F7189FE5B40@softarmor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <126E316F-0AB2-4927-9B68-4F7189FE5B40@softarmor.com> X-Spam-Score: -2.5 (--) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: IETF SIP List , fluffy@cisco.com, "Vijay K. Gurbani" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Dean, I'll be on the hook for any outbound-related issues, but AFAIK there are no open issues. The draft has incorporated all the comments we received. I am not presenting anything on connection reuse. You may want to ping Vijay about that. I look forward to Jason's presentation on flying squirrels. thanks, -rohan On 6/26/06, Dean Willis wrote: > > > New draft agenda for SIP. Note that the days have changed and we now have > room numbers. > > > Draft Agenda for SIP at IETF 66 > > Session 1, Monday 1300-1500 Room 520DEF > > Time Topic Discussion Leaders Reading List > > 1300 Agenda Bash, Announcements and Status Chairs This Doc > 1305 Outbound Cullen Jennings draft-ietf-sip-outbound-04 > 1320 Outbound Discovery Migurl Garcia for > Erkki Koivusalo draft-koivusalo-sip-outbound-discovery-01 > 1335 Outbound Midcall Issues Kevin Johns > draft-johns-sip-outbound-middialog-draft-00 > 1340 Connection Reuse Vijay Gurbani > Rohan Mahy draft-ietf-sip-connect-reuse-05 > 1400 Location Conveyance James Polk > draft-ietf-sip-location-conveyance-03 > 1415 SAML for SIP James Polk > Hannes Tschofenig draft-ietf-sip-saml-00 > 1430 Certificates. Arboreal Rodents > Or Fruitless Canine Vocalization? Jason Fischl draft-ietf-sip-certs-01 > 1445 Hop Limit Diagnostics > Is my bunny sick? Scott Lawrence > draft-ietf-sip-hop-limit-diagnostics-03.txt > > Session 2, Wednesday 1300-1500 Room 520ABC > > Time Topic Discussion Leaders Reading List > > 1300 Agenda Bash Chairs This Doc > 1305 Connected Identity John Elwell > draft-ietf-sip-connected-identity-00 > 1330 Identity Co-Existence Jonathan rosenberg > draft-rosenberg-sip-identity-coexistence-00 > 1340 Security Flows Robert Sparks draft-ietf-sip-sec-flows-01 > 1350 Fork loop fix Robert Sparks draft-ietf-sip-fork-loop-fix-02 > 1400 Feature list for advance specification Robert Sparks TBD > 1410 Hitchhiker's Guide Jonathan Rosenberg > draft-ietf-sip-hitchhikers-guide-00 > 1425 SIPS: Guidelines Francois Audet > draft-audet-sip-sips-guidelines-02 > 1445 Improved TLS Requirements Vijay Gurbani draft-gurbani-sip-sipsec-00 > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on > current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 27 19:04:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvMaJ-0000J5-CL; Tue, 27 Jun 2006 19:03:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvMaI-0000Iz-AN for sip@ietf.org; Tue, 27 Jun 2006 19:03:06 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvMaF-0007Zz-07 for sip@ietf.org; Tue, 27 Jun 2006 19:03:06 -0400 Received: from [192.168.1.4] (65-65-155-30.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5RN4Ukc026406 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 27 Jun 2006 18:04:35 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <8F3CFCB3-ED75-4747-AD8E-0A43DC6D8BAA@softarmor.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF SIP List , Rohan Mahy , Cullen Jennings From: Dean Willis Date: Tue, 27 Jun 2006 18:02:47 -0500 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Sip] Ready for WGLC on Outbound? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Rohan said: > I'll be on the hook for any outbound-related issues, but AFAIK there > are no open issues. The draft has incorporated all the comments we > received. So if there are no open issues, are we ready for working group last call? -- 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 Jun 27 19:47:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvNFk-0004OH-CM; Tue, 27 Jun 2006 19:45:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvNFi-0004MC-VE; Tue, 27 Jun 2006 19:45:54 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvMWY-0006PR-3Q; Tue, 27 Jun 2006 18:59:14 -0400 Received: from pine.neustar.com ([209.173.57.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvMNe-0007KU-Hk; Tue, 27 Jun 2006 18:50:05 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5RMo1UA006439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Jun 2006 22:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvMNd-0005rh-Lj; Tue, 27 Jun 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 27 Jun 2006 18:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-outbound-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: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Managing Client Initiated Connections in the Session Initiation Protocol (SIP) Author(s) : C. Jennings, R. Mahy Filename : draft-ietf-sip-outbound-04.txt Pages : 34 Date : 2006-6-27 The Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections and send asynchronous UDP datagrams to User Agents in order to deliver requests. However, many practical considerations, such as the existence of firewalls and Network Address Translators (NATs), prevent servers from connecting to User Agents in this way. This specification defines behaviors for User Agents, registrars and proxy servers that allow requests to be delivered on existing connections established by the User Agent. It also defines keep alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-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-outbound-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-outbound-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: <2006-6-27154319.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-outbound-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-outbound-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-27154319.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Tue Jun 27 19:49:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvNI0-00005Y-4c; Tue, 27 Jun 2006 19:48:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvNHy-0008TW-17; Tue, 27 Jun 2006 19:48:14 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvMWX-0006PR-VP; Tue, 27 Jun 2006 18:59:14 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=willow.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvMNe-0007KX-VS; Tue, 27 Jun 2006 18:50:07 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5RMo19F020789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Jun 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvMNd-0005rz-PT; Tue, 27 Jun 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 27 Jun 2006 18:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-certs-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: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Certificate Management Service for The Session Initiation Protocol (SIP) Author(s) : C. Jennings, et al. Filename : draft-ietf-sip-certs-01.txt Pages : 29 Date : 2006-6-27 This draft defines a Credential Service that allows Session initiation Protocol (SIP) User Agents (UAs) to use a SIP package to discover the certificates of other users. This mechanism allows user agents that want to contact a given Address-of-Record (AOR) to retrieve that AOR's certificate by subscribing to the Credential Service, which returns an authenticated response containing that certificate. The Credential Service also allows users to store and retrieve their own certificates and private keys. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-certs-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-certs-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-certs-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-27155500.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-certs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-certs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-27155500.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Tue Jun 27 20:36:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvO0b-0008B4-Fp; Tue, 27 Jun 2006 20:34:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvO0Z-0008Ah-FR for sip@ietf.org; Tue, 27 Jun 2006 20:34:19 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvNb6-0001D7-0O for sip@ietf.org; Tue, 27 Jun 2006 20:08:00 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvNTp-0001qp-QL for sip@ietf.org; Tue, 27 Jun 2006 20:00:31 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 27 Jun 2006 17:00:29 -0700 X-IronPort-AV: i="4.06,184,1149490800"; d="scan'208"; a="301975817:sNHT29288940" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k5S00TiI025200; Tue, 27 Jun 2006 17:00:29 -0700 Received: from [172.17.99.213] (sjc-vpn2-550.cisco.com [10.21.114.38]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5S00NCX028105; Tue, 27 Jun 2006 17:00:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: <6D6008A4-E715-4BA4-BDF1-31CD5C946AF9@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF SIP List , Kevin Johns From: Cullen Jennings Date: Tue, 27 Jun 2006 19:00:27 -0500 X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=430; t=1151452829; x=1152316829; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Comments=20on=20johns-sip-outbound-middialog; X=v=3Dcisco.com=3B=20h=3DUnX6LrotQWTLVWqH4m+GMMablfk=3D; b=J5JcsFH0uywixId87gwjdVei0qXBUyFVyTklr3Sv4Z+N1tlhyuRydyaRTd5hLFMIVtCHdf8e jhslhVrXZa3f31Sf5QJDFyjkbLN/ZSCOVvvEz5lNq2rY+fwksM01yAJN; Authentication-Results: sj-dkim-3.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Sip] Comments on johns-sip-outbound-middialog X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Kevin thanks for writing this down and getting the discussion going again. I like this draft and think it is going the right direction. I am trying to dig up all the old conversations about approaches to this problem. One thing you might want to consider with this draft is want would happen if the endpoint was using a GRUU. Seems like might end up with the extra spiral through the edge proxy. Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 27 22:02:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvPLs-00088k-U4; Tue, 27 Jun 2006 22:00:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvPLq-00088f-K5 for sip@ietf.org; Tue, 27 Jun 2006 22:00:22 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvPLk-0003ow-Tc for sip@ietf.org; Tue, 27 Jun 2006 22:00:22 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1J00I3GSA22W@szxga01-in.huawei.com> for sip@ietf.org; Wed, 28 Jun 2006 10:01:14 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1J00H2USA1FF@szxga01-in.huawei.com> for sip@ietf.org; Wed, 28 Jun 2006 10:01:13 +0800 (CST) Received: from z53160 ([10.164.5.15]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1J00ABYS9Y9D@szxml03-in.huawei.com> for sip@ietf.org; Wed, 28 Jun 2006 10:01:14 +0800 (CST) Date: Wed, 28 Jun 2006 09:59:21 +0800 From: Harrison Zhou To: Dean Willis , rohan@ekabal.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcaaVnij1NowR3SCRkeL6kL/byA65g== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Sip Subject: [Sip] Give me a example about Outbound? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I've read the outbound-3. the examples in this draft are all assumed that the registrar and proxy are integrative. Who can give me a example that the registrar and proxy are separate. Thanks, Hong _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 28 03:02:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvU2u-0007Di-EZ; Wed, 28 Jun 2006 03:01:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvU2s-0007Dc-Oz for sip@ietf.org; Wed, 28 Jun 2006 03:01:06 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvU2p-0004xT-SB for sip@ietf.org; Wed, 28 Jun 2006 03:01:06 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BF977520001; Wed, 28 Jun 2006 09:01:02 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 09:01:02 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 09:01:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ready for WGLC on Outbound? Date: Wed, 28 Jun 2006 09:01:01 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F11C4@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ready for WGLC on Outbound? Thread-Index: AcaaPdzSkeYBqyQ/T2emKmclEjptIAAPOBOQ From: "Christer Holmberg \(JO/LMF\)" To: "Dean Willis" , "IETF SIP List" , "Rohan Mahy" , "Cullen Jennings" , "Jonathan Rosenberg" X-OriginalArrivalTime: 28 Jun 2006 07:01:02.0188 (UTC) FILETIME=[9DE0BAC0:01C69A80] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Unfortunately, I don't think all issues have been addressed yet. There = are a number of issues we've been discussing on e-mail, and on some I = think we have even reached agreements. FIRST, the issue I raised in the "Outbound: keep-alive, outbound and = 3489bis" thread has not been issued. STUN NAT keep-alive is nowadays a = "core" STUN usage - not something specific to the outbound mechanism. We = need to separate them, because it should be possible to use STUN for = keep-alive without using the rest of outbound (instance-id, flow etc = etc). Chapter 4.2 says: "The UAC MAY examine successful registrations for the presence of an = 'outbound' option-tag in a Supported header field value. Presence of = this option-tag indicates that the registrar is compliant with this = specification. Again, that is not true if I only support STUN for NAT keep-alive, but = not the rest of outbound. Now, one COULD of course claim that the generic SIP usage of STUN for = NAT keep-alive shall be described in a SEPARATE document, and that the = outbound spec ONLY describes the STUN keep-alive when used TOGETHER with = outbound. BUT, if that is the case the "keepalive" URI parameter should = not be defined in the outbound draft - it should be defined in that = generic SIP STUN keep-alive usage draft (I ASSUME that we would use the = "keepalive" parameter also when we use STUN keep-alive without = outbound". Also, the text on STUN processing etc should also be = described in the generic draft in that case, because it's not outbound = specific. Also, since STUN keep-alive is now a core STUN usage, I wonder if we can = remove the note in chapter 3.5. Because, again, this draft shall not = define the keep-alive mechanism - it is already defined in 3489bis. SECOND, the draft talks about the outbound proxy URIs configured in the = client. I think we agreed that configured URIs are ok as "default", but = I think we should say that the client may also retreive the proxy = address using other mechanisms (e.g. something similar to the P-CSCF = discovery mechanism in IMS). I don't think we need to talk about = "additional mechanisms" that may be defined in the future (chapter 4.2): = we simply say that other mechanisms are outside of the scope of this = document. THIRD, I think we agreed that there may be other ways of providing a = reliable system=20 Chapter 3.3 says:=20 "There are various ways to deploy SIP to build a reliable and scalable = system. This section discusses one such design that is possible with = the mechanisms in this specification. Other designs are also possible." To make it more clear I think it should say: "Other designs, where multiple registrations/flows are not required, are = also possible." FOURTH, related to the second and third issue, chapter 4.2 says: "For each outbound proxy URI in the set, the UA MUST send a REGISTER in = the normal way using this URI as the default outbound proxy."=20 Again, there may be other ways to provide reliability. And, shall it really be mandatory to register to ALL URIs? In issue = seven I talk about the "max-flow" indicator we've been discussing on the = list. =20 FIFTH, related to the second, third and fourth issues, we discussed that = that the network should be able to provide a "max-flow" number to the = client. SIXTH, one issue we've recently been discussing is what an edge proxy = does if it receives "keepalive=3Dstun", but it doesn't support STUN. I = think we need to say something. I don't think we should just call it an = error case, and therefor it is "an implementation issue" how to handle = it. SEVENTH, related to the first issue, chapter 4.2 says: "Forming the route set for the request is outside the scope of this = document, but typically results in sending the REGISTER such that the = topmost Route header field contains a loose route to the outbound proxy = URI. Other issues related to outbound route construction are = discussed..." Maybe I just missunderstand that text, but IF we use an URI parameter to = indicate STUN NAT keep-alive I think there MUST be a Route header to the = outbound proxy URI. Regards, Christer=20 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: 28. kes=E4kuuta 2006 2:03 To: IETF SIP List; Rohan Mahy; Cullen Jennings Subject: [Sip] Ready for WGLC on Outbound? Rohan said: > I'll be on the hook for any outbound-related issues, but AFAIK there=20 > are no open issues. The draft has incorporated all the comments we=20 > received. So if there are no open issues, are we ready for working group last = call? -- 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 Wed Jun 28 04:37:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvVWY-0003Zt-C4; Wed, 28 Jun 2006 04:35:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvVWW-0003Zi-Ks for sip@ietf.org; Wed, 28 Jun 2006 04:35:48 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvV6m-0000Wv-Lf for sip@ietf.org; Wed, 28 Jun 2006 04:09:12 -0400 Received: from smtp3.su.se ([130.237.93.228]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvUTo-0000E8-CC for sip@ietf.org; Wed, 28 Jun 2006 03:28:57 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id F3D113BFF7; Wed, 28 Jun 2006 09:28:46 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 08924-01-16; Wed, 28 Jun 2006 09:28:46 +0200 (CEST) Received: from dhcp-wavelan-vo-57.publik.su.se (dhcp-wavelan-vo-57.publik.su.se [193.11.30.57]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 1D6433BEEF; Wed, 28 Jun 2006 09:28:45 +0200 (CEST) From: Fredrik Thulin To: sip@ietf.org Subject: Re: [Sip] Give me a example about Outbound? Date: Wed, 28 Jun 2006 09:28:13 +0200 User-Agent: KMail/1.9.1 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606280928.13277.ft@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.642 tagged_above=-99 required=7 tests=[AWL=0.023, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: -2.6 (--) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: rohan@ekabal.com, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Wednesday 28 June 2006 03:59, Harrison Zhou wrote: > Hi, > > I've read the outbound-3. the examples in this draft are all assumed > that the registrar and proxy are integrative. Who can give me a > example that the registrar and proxy are separate. Hi What do you mean? I implemented Outbound support in the YXA project (open source) which has a separate outbound proxy application and registrar application from draft-ietf-sip-outbound-03. /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 28 07:17:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvY1a-0002F0-Kv; Wed, 28 Jun 2006 07:16:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvY1Z-0002Ev-FC for sip@ietf.org; Wed, 28 Jun 2006 07:16:01 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvY1Y-00044a-4t for sip@ietf.org; Wed, 28 Jun 2006 07:16:01 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 0B3A53C036; Wed, 28 Jun 2006 13:15:59 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 28754-01-64; Wed, 28 Jun 2006 13:15:58 +0200 (CEST) Received: from dhcp-wavelan-vo-57.publik.su.se (dhcp-wavelan-vo-57.publik.su.se [193.11.30.57]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 518413BE65; Wed, 28 Jun 2006 13:15:50 +0200 (CEST) From: Fredrik Thulin To: sip@ietf.org Subject: Re: [Sip] Ready for WGLC on Outbound? Date: Wed, 28 Jun 2006 13:15:22 +0200 User-Agent: KMail/1.9.1 References: <8F3CFCB3-ED75-4747-AD8E-0A43DC6D8BAA@softarmor.com> In-Reply-To: <8F3CFCB3-ED75-4747-AD8E-0A43DC6D8BAA@softarmor.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606281315.22640.ft@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.643 tagged_above=-99 required=7 tests=[AWL=0.022, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Cullen Jennings , Rohan Mahy , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Wednesday 28 June 2006 01:02, Dean Willis wrote: > Rohan said: > > I'll be on the hook for any outbound-related issues, but AFAIK > > there are no open issues. The draft has incorporated all the > > comments we received. > > So if there are no open issues, are we ready for working group last > call? Hi I don't consider the question I raised in http://www1.ietf.org/mail-archive/web/sip/current/msg13861.html to have been answered. I talked briefly with Rohan about this at the last SIPit, but the brief explanation he provided me with then didn't convince me =), and I think the issue needs to be talked about on the list. Also, is there consensus to use the 410 response code even though RFC3261 says that it is to be considered a permanent condition? Adam Roach brought this up in http://www1.ietf.org/mail-archive/web/sip/current/msg13530.html /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 28 09:40:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvaFU-0001rm-35; Wed, 28 Jun 2006 09:38:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvaFS-0001pq-Ck for sip@ietf.org; Wed, 28 Jun 2006 09:38:30 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvaFP-0008O8-Kx for sip@ietf.org; Wed, 28 Jun 2006 09:38:30 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E538D4F0071; Wed, 28 Jun 2006 15:38:26 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 15:38:26 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 15:38:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound: keep-alive, outbound and 3489bis Date: Wed, 28 Jun 2006 15:38:24 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F11F2@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: keep-alive, outbound and 3489bis Thread-Index: AcaX4qCxt5NZbqlQQ+WRvc6t16prnAC1TeOw From: "Christer Holmberg \(JO/LMF\)" To: "Cullen Jennings" , "Dean Willis" X-OriginalArrivalTime: 28 Jun 2006 13:38:25.0570 (UTC) FILETIME=[21A41820:01C69AB8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: sip@ietf.org, Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I may have missed it, but is there a reason why the edge proxy itself = couldn't, if it supports STUN NAT keep-alive, insert the keepalive = parameter in the Path header URI? The client, when receving the registration response, will then see = whether the edge proxy supports it or not. That would also work then the client does not have a full URI of the = edge proxy (it may only have an IP address or FQDN, which is uses to = build a URI). Regards, Christer=20 -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com]=20 Sent: 25. kes=E4kuuta 2006 2:05 To: Dean Willis Cc: Christer Holmberg (JO/LMF); sip@ietf.org; Francois Audet Subject: Re: [Sip] Outbound: keep-alive, outbound and 3489bis I understand people are uneasy about this - originally I proposed = something else and got very strong feedback to do it exactly the way = sigcomp does it. I don't see this problem in anyway different that = sigcomp. We may have done sigcomp wrong but so far no one seems to come = up with a concrete problem. It's pretty late to be thinking about = starting to explore other ways that we might be able to do this. More = inline. On Jun 22, 2006, at 8:56 AM, Dean Willis wrote: > > On Jun 21, 2006, at 12:12 PM, Cullen Jennings wrote: > >> >> On Jun 21, 2006, at 9:57 AM, Christer Holmberg ((JO/LMF)) wrote: >> >>> There must also be a way for the edge proxy to indicate to the=20 >>> client that it supports the STUN keep-alive usage. Because, if the=20 >>> other outbound features aren't supported/requested, there will be no = >>> "outbound" in the Supported header of the registration response. >> >> this is done with the keepalive=3Dstun parameter in the URI for the=20 >> edge proxy >> >> _ > > I have to admit, I'm a little queasy about this. > > In the model of the world I hold in my head, a URI is much like a=20 > "function call". The parameters in a URI are information being=20 > provided to the function, i.e., to the target of the URI. > > Encoding things ABOUT the behavior of the called function that need to = > be known to the caller in those parameters just seems very backwards. Interesting model - but I think I would need to consider the sip: =20 part of the URI fits your model and neither does the ;lr > > That's like asking a C programmer to know that a given function will=20 > return the cube of the first parameter because the second parameter is = > "cubed", when that second parameter has no impact whatsoever on the=20 > execution of the function and is there only to inform the user of the=20 > function about what the function does. All the time we have functions return tokens that are passed back in on = a later call but I'm not sure i find the analogy all that compelling. > > So what happens when a client that is constructing a proxy-URI =20 > decides to tack on a keepalive=3Dstun parameter, and the proxy =20 > doesn't support keepalive via stun? Does the proxy reject a =20 > REGISTER request that contains this parameter if it doesn't support =20 > it? same thing that happens if the client decide to recode the URI in =20 ebcdic - it probably won't work. Of course any self respecting proxy =20 should not have problems if some random non sip message get sent to =20 it be that message a STUN message or just a random network scan probe. > > -- > 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 Jun 28 10:29:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvb1L-00050H-Pm; Wed, 28 Jun 2006 10:27:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvb1K-000509-Cc for sip@ietf.org; Wed, 28 Jun 2006 10:27:58 -0400 Received: from endor.rfc3261.net ([212.112.227.208]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvb1I-0005Vx-2x for sip@ietf.org; Wed, 28 Jun 2006 10:27:58 -0400 Received: from localhost (localhost [127.0.0.1]) by endor.rfc3261.net (Postfix) with ESMTP id 20012260233 for ; Wed, 28 Jun 2006 16:27:55 +0200 (CEST) Received: from endor.rfc3261.net ([127.0.0.1]) by localhost (endor [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 07472-03 for ; Wed, 28 Jun 2006 16:27:52 +0200 (CEST) Received: from hoth.office.iptelorg.de (unknown [217.9.54.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by endor.rfc3261.net (Postfix) with ESMTP id 9E474260232 for ; Wed, 28 Jun 2006 16:27:52 +0200 (CEST) From: Nils Ohlmeier To: sip@ietf.org Subject: Re: [Sip] Privacy in multi domain setups Date: Wed, 28 Jun 2006 16:27:48 +0200 User-Agent: KMail/1.9.3 References: <200606271830.51055.lists@ohlmeier.org> <200606271817.k5RIH6VT021767@dragon.ariadne.com> In-Reply-To: <200606271817.k5RIH6VT021767@dragon.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606281627.48473.lists@ohlmeier.org> X-Virus-Scanned: by amavisd-new (Debian) at endor.rfc3261.net X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Tuesday 27 June 2006 20:17, Dale.Worley@comcast.net wrote: > From: Nils Ohlmeier > > Or to say it in another way: as the request contains no information > to which domain the caller belongs I can not challenge him (because > I can not determine the correct realm). But if I do not challenge > INVITEs from anonymous@anonymous.invalid then this is the perfect > gate for SPIT. > > I take it you have too many realms to just include a > Proxy-Authenticate for each one of them? Ok, good point. But I think two reasons are spaeking against this solution: - reply might getting big - the UA would have to know which realm to choose. As the realm is suppose to be a free text displayed to the user I fear an automatic selection might fail (if the realm wasn't provisioned to the phone already which I guess is rarely the case). Thanks Nils Ohlmeier _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 28 11:14:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvbil-0001wM-LD; Wed, 28 Jun 2006 11:12:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvbiL-0001h5-FV for sip@ietf.org; Wed, 28 Jun 2006 11:12:25 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvbh6-0001a3-55 for sip@ietf.org; Wed, 28 Jun 2006 11:11:09 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 83CF013FFEB; Wed, 28 Jun 2006 18:11:03 +0300 (EEST) Received: from rautu (guanine59.gprs.dnafinland.fi [62.78.120.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id AEA2F13FFE2; Wed, 28 Jun 2006 18:10:53 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id BE2A8F03C1; Wed, 28 Jun 2006 11:30:31 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17570.15911.602096.876348@rautu.tutpro.com> Date: Wed, 28 Jun 2006 11:30:31 +0300 From: Juha Heinanen To: Dean Willis Subject: [Sip] Ready for WGLC on Outbound? In-Reply-To: <8F3CFCB3-ED75-4747-AD8E-0A43DC6D8BAA@softarmor.com> References: <8F3CFCB3-ED75-4747-AD8E-0A43DC6D8BAA@softarmor.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: IETF SIP List , Rohan Mahy , Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis writes: > > So if there are no open issues, are we ready for working group last > call? i sent text to remove the primary/backup stuff and have not seen that incorporated in any draft. also, the requirement that UA must be able to setup at least two flows is not included. -- 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 Jun 28 11:14:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvbip-0002CA-VX; Wed, 28 Jun 2006 11:12:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvbin-00021l-Lo for sip@ietf.org; Wed, 28 Jun 2006 11:12:53 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvbbH-0000ge-SB for sip@ietf.org; Wed, 28 Jun 2006 11:05:09 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 28 Jun 2006 08:05:07 -0700 X-IronPort-AV: i="4.06,189,1149490800"; d="scan'208,217"; a="302274497:sNHT51939076" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k5SF57tX003962 for ; Wed, 28 Jun 2006 08:05:07 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5SF4xl0013322 for ; Wed, 28 Jun 2006 08:05:06 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 28 Jun 2006 11:05:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [Sip] Comments on draft-audet-sip-sips-guidelines Date: Wed, 28 Jun 2006 11:05:04 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301A5A3DE@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comments on draft-audet-sip-sips-guidelines Thread-Index: AcaaxDyWHTYlRTVSQt2DeLPXjdsaLA== From: "Michael Hammer \(mhammer\)" To: X-OriginalArrivalTime: 28 Jun 2006 15:05:05.0886 (UTC) FILETIME=[3D4557E0:01C69AC4] DKIM-Signature: a=rsa-sha1; q=dns; l=5021; t=1151507107; x=1152371107; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:[Sip]=20Comments=20on=20draft-audet-sip-sips-guidelines; X=v=3Dcisco.com=3B=20h=3Dz7S4Kpe5+ZlSKVg370UK40tJV+s=3D; b=nnt+DbC6S5LzZViwPhYJzCH0Ms6tjiQy5oT35ZzmRsffQeUJA5/E629xmF+F6ftwPTbm6v51 hhiacHMNsQLEQGlJucMTMDPST6PgWDk14LpiFZQtfz52yqjHER3YXl3u; Authentication-Results: sj-dkim-4.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f X-BeenThere: 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="===============0966774126==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0966774126== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69AC4.3D13293B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69AC4.3D13293B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Samir, Read through the draft and had a few nits and comments. Nits:=20 Sec 3, 2) "need to use" -> MUST use?=20 page 4, top: "renegotiate" Will need UAC, Proxy, UAS sections in future draft. Comments: Option tag: e2e-ciphersuite: Include description of semantic for Supported header as well. When text is expanded these could be separate sub-sections. Suggestion: q-value should order the suites both by strength of algorithm/key size (first) and then by preference (second). Reason is to see degree of downgrade. Via header should describe action that a proxy node MUST verify that the Via header added by the previous hop is valid, i.e. that it did in fact use the cipher named in the Via for the incoming link. May want to send a report directly back to the UAC Contact notifying of the compromise. Not sure error code sent back would help. Not sure how this would work with IPSEC. The applications may not have as much control of the host or communication with it (cross-layer indicators). I could see the IPSEC cipher listed as a substitute. But, then the application needs to have a means to know if it is equivalent, unless it names those up front in the new header. For fairly well known systems (e.g. follows the ANSI Generic Security standard), this might be a managable list. Does IANA already have a registry of the exact string names used for each ciphersuite? Last half of second paragraph above Sec 4 should be in Sec 5 security considerations. Should also point out that this may not prevent a proxy from dropping out Security-Level header. Thought, should the cipher also be included in the Record-Route header? The UAC should approve the route set for continuing the call? The draft is a good start. Thanks for taking the ball and running with it. Mike ------_=_NextPart_001_01C69AC4.3D13293B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Samir,

Read through = the draft and=20 had a few nits and comments.

Nits:

Sec 3, 2) "need to use" -> MUST use? =

page 4, top: "renegotiate"

Will need UAC, Proxy, UAS sections in future=20 draft.

Comments:

Option tag: e2e-ciphersuite: Include description = of=20 semantic for Supported header as well. When text is expanded these could = be=20 separate sub-sections.

Suggestion: q-value=20 should order the suites both by strength of algorithm/key size (first) = and then=20 by preference (second). Reason is to see degree of downgrade.

Via header should describe action that a proxy = node MUST=20 verify that the Via header added by the previous hop is valid, i.e. that = it did=20 in fact use the cipher named in the Via for the incoming link. May want = to send=20 a report directly back to the UAC Contact notifying of the=20 compromise.

Not sure error code sent back would = help.

Not sure how this would work with IPSEC. The = applications=20 may not have as much control of the host or communication with it = (cross-layer=20 indicators). I could see the IPSEC cipher listed as a substitute. But, = then the=20 application needs to have a means to know if it is equivalent, unless it = names=20 those up front in the new header. For fairly well known systems (e.g. = follows=20 the ANSI Generic Security standard), this might be a managable = list.

Does IANA already have a registry of the exact = string=20 names used for each ciphersuite?

Last half of second paragraph above Sec 4 should = be in Sec=20 5 security considerations. Should also point out that this may not = prevent a=20 proxy from dropping out Security-Level header. Thought, should the = cipher also=20 be included in the Record-Route header? The UAC should approve the route = set for=20 continuing the call?

The draft is a good start. Thanks for taking the = ball and=20 running with it.

Mike

------_=_NextPart_001_01C69AC4.3D13293B-- --===============0966774126== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0966774126==-- From sip-bounces@ietf.org Wed Jun 28 11:37:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvc4h-0001JN-RY; Wed, 28 Jun 2006 11:35:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvc4f-0001J3-8S for sip@ietf.org; Wed, 28 Jun 2006 11:35:29 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvc4d-00046v-Qp for sip@ietf.org; Wed, 28 Jun 2006 11:35:29 -0400 Received: from [131.161.248.86] (open-131-161-248-86.cliq.com [131.161.248.86]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k5SFZPF06576; Wed, 28 Jun 2006 08:35:25 -0700 In-Reply-To: <17570.15911.602096.876348@rautu.tutpro.com> References: <8F3CFCB3-ED75-4747-AD8E-0A43DC6D8BAA@softarmor.com> <17570.15911.602096.876348@rautu.tutpro.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Ready for WGLC on Outbound? Date: Wed, 28 Jun 2006 08:35:23 -0700 To: Juha Heinanen X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: IETF SIP List , Rohan Mahy , Cullen Jennings , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Juha, Primary/Secondary terminology was completely removed from the Section 4.2 of the -04 draft: > UAs obtain at configuration time one or more SIP URIs representing the > default outbound-proxy-set. This specification assumes the set is > determined via any of a number of configuration mechanisms and future > specifications may define additional mechanisms such as using DNS to > discover this set. How the UA is configured is outside the scope of > this specification. However, a UA MUST support sets with at least two > outbound proxy URIs and SHOULD support sets with up to four URIs. For > each outbound proxy URI in the set, the UA MUST send a REGISTER in the > normal way using this URI as the default outbound proxy. Forming the > route set for the request is outside the scope of this document, but > typically results in sending the REGISTER such that the topmost Route > header field contains a loose route to the outbound proxy URI. Other > issues related to outbound route construction are discussed in > [I-D.rosenberg-sip-route-construct]. The only remaining instances of primary/secondary terminology are non-normative explanations in one definition, in one scenario described in the Overview, and in the example in Section 8. from Section 2.1 Definitions > outbound-proxy-set > A set of SIP URIs (Uniform Resource Identifiers) that represents > each of the outbound proxies (often Edge Proxies) with which the UA > will attempt to maintain a direct flow. The first URI in the set is > often referred to as the primary outbound proxy and the second as the > secondary outbound proxy. There is no difference between any of the > URIs in this set, nor does the primary/secondary terminology imply > that one is preferred over the other. from Section 3.3 (part of the Overview): > In the example system below, the logical outbound proxy/registrar for > the domain is running on two hosts that share the appropriate state > and can both provide registrar and outbound proxy functionality for > the domain. The UA will form connections to two of the physical hosts > that can perform the outbound proxy/registrar function for the domain. > Reliability is achieved by having the UA form two TCP connections to > the domain. > > Scalability is achieved by using DNS SRV to load balance the primary > connection across a set of machines that can service the primary > connection and also using DNS SRV to load balance across a separate > set of machines that can service the secondary connection. The > deployment here requires that DNS is configured with one entry that > resolves to all the primary hosts and another entry that resolves to > all the secondary hosts. While this introduces additional DNS > configuration, the approach works and requires no addition SIP > extensions. > > Note: Approaches which select multiple connections from a single > DNS SRV set were also considered, but cannot prevent two connections > from accidentally resolving to the same host. The approach in this > document does not prevent future extensions, such as the SIP UA > configuration framework [I-D.ietf-sipping-config-framework], from > adding other ways for a User Agent to discover its outbound-proxy-set. thanks, -rohan On Jun 28, 2006, at 1:30, Juha Heinanen wrote: > Dean Willis writes: >> >> So if there are no open issues, are we ready for working group last >> call? > > i sent text to remove the primary/backup stuff and have not seen that > incorporated in any draft. also, the requirement that UA must be > able to setup at least two flows is not included. > > -- 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 Jun 28 11:45:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvcCe-0004vo-Ei; Wed, 28 Jun 2006 11:43:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvcCd-0004t3-Nn for sip@ietf.org; Wed, 28 Jun 2006 11:43:43 -0400 Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvcCc-0004yu-G1 for sip@ietf.org; Wed, 28 Jun 2006 11:43:43 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc12) with ESMTP id <20060628154341m12006oe7de>; Wed, 28 Jun 2006 15:43:41 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k5SFhe5n020207 for ; Wed, 28 Jun 2006 11:43:40 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k5SFheRG020203; Wed, 28 Jun 2006 11:43:40 -0400 Date: Wed, 28 Jun 2006 11:43:40 -0400 Message-Id: <200606281543.k5SFheRG020203@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <200606281627.48473.lists@ohlmeier.org> Subject: Re: [Sip] Privacy in multi domain setups References: <200606271830.51055.lists@ohlmeier.org> <200606271817.k5RIH6VT021767@dragon.ariadne.com> <200606281627.48473.lists@ohlmeier.org> X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Nils Ohlmeier But I think two reasons are spaeking against this solution: - reply might getting big I didn't expect it to be a workable solution. But you might have been lucky and known that there were only 2 (say) realms, maximum. - the UA would have to know which realm to choose. As the realm is suppose to be a free text displayed to the user I fear an automatic selection might fail (if the realm wasn't provisioned to the phone already which I guess is rarely the case). In the cases I've seen, the UA is configured with at most one realm, so it has no difficulty choosing. Actually, this problem is quite difficult in the general case -- the proxy accepts authentication for a large number of realms, and the UA can present authentication for several realms. How to negotiate which realm to use? Even worse if the UA must prompt the user before presenting authentication for a realm. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 28 12:11:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvcbc-000514-Kv; Wed, 28 Jun 2006 12:09:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvcbQ-0004iR-D3 for sip@ietf.org; Wed, 28 Jun 2006 12:09:20 -0400 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvcbP-0007Fi-1P for sip@ietf.org; Wed, 28 Jun 2006 12:09:20 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc13) with ESMTP id <2006062816091801300b1dj0e>; Wed, 28 Jun 2006 16:09:18 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k5SG9I5n020829 for ; Wed, 28 Jun 2006 12:09:18 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k5SG9I9j020825; Wed, 28 Jun 2006 12:09:18 -0400 Date: Wed, 28 Jun 2006 12:09:18 -0400 Message-Id: <200606281609.k5SG9I9j020825@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <475FF955A05DD411980D00508B6D5FB0132CB563@en0033exch001u.uk.lucent.com> (drage@lucent.com) Subject: Re: [Sip] Connected-identity and changing the To header field ina response References: <475FF955A05DD411980D00508B6D5FB0132CB563@en0033exch001u.uk.lucent.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Drage, Keith (Keith)" Note that the ISDN specifications do not explicitly say one of these is a billing identitifier or another is a dial-back number, this is just an example of the uses that these numbers may be appropriate for. Forgive me if this has been discussed before, but what *do* the ISDN specifications say about the identifiers? And do those specifications cover what PSTN operators really expect to be true about the identifiers? Since this work is largely in support of PSTN interoperation, a clear statement of what the PSTN expects would be a good start. And the discussion to this point doesn't seem to indicate that that has been made explicit. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 28 12:40:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvd3V-0007Mi-BI; Wed, 28 Jun 2006 12:38:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvd3T-0007B3-PL for sip@ietf.org; Wed, 28 Jun 2006 12:38:19 -0400 Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvd3R-0002F3-F2 for sip@ietf.org; Wed, 28 Jun 2006 12:38:19 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc12) with ESMTP id <20060628163816m12006petke>; Wed, 28 Jun 2006 16:38:16 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k5SGcF5n021503 for ; Wed, 28 Jun 2006 12:38:15 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k5SGcF0L021499; Wed, 28 Jun 2006 12:38:15 -0400 Date: Wed, 28 Jun 2006 12:38:15 -0400 Message-Id: <200606281638.k5SGcF0L021499@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net X-Spam-Score: 0.2 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [Sip] Guidelines for Implementing the Dialog Event Package in User Agents X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I've submitted draft-worley-sip-dialog-02, "Guidelines for Implementing the Dialog Event Package in User Agents". It doesn't change too much from the -01 version, other than updating the data on current implementations. (They're still not very good.) It can be gotten from https://scm.sipfoundry.org/rep/ietf-drafts/worley/draft-worley-sip-dialog-02.{txt,html,xml} as well as the I-D archives. Discussion of earlier versions has shown that there are still some undefined aspects of dialog event packages. Michael Proctor gives a good summary: I've been reading this document, and also Dale Worley's draft containing implementation guidelines (draft-worley-sip-dialog-00). One thing that has come up in the discussions I have had with Dale is the question of what is meant by the mandatory "entity" attribute in the dialog-info element. >From RFC4235 Section 4.1: o entity: This attribute contains a URI that identifies the user whose dialog information is reported in the remainder of the document. This user is referred to as the "observed user". There doesn't appear to be any further discussion of what the entity value should be, but all the examples in the RFC are apparently AORs. (Except for the example in 4.2, which is missing the element altogether!) It is also unclear what use the element is. I first thought it could be used to distinguish between responses to a forked SUBSCRIBE, but that doesn't make any sense if the entity is the AOR. Maybe the Contact (or better, GRUU) would be a more useful URI to use in those circumstances. Having the entity as the AOR does give the interesting side effect of allowing a GRUU to be mapped back to an AOR, simply by subscribing to the dialog package for the GRUU you are interested in. I remember this was a hot topic a couple of months ago - I don't recall what the result was. A problem with requiring the AOR to be present is that not all UAs know their AOR. There are various devices that are still statically registered and so don't necessarily know their AOR. There are probably other reasons why a UA might not know its AOR aswell. Under these circumstances, I suppose the request-URI might be the best thing to put in the field. So, it seems likely that the intention was that an AOR be used, but there appear to be good and not-so-good reasons to use a contact URI/GRUU instead. I would like to understand what the entity element is for (any use-cases?) and why it is mandatory. Any clarifications to the usage could be added to Dale's draft. In regard to "Who uses the 'entity' attribute?', I've seen client applications that use the entity value for storing dialog state information (because it has to process partial updates). It would also be desirable for "pseudo-presence" applications if there was a way that one could subscribe to all the dialog event state in a particular UA "instrument", rather than just for a particular "line". Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 29 01:05:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvogk-0005Z8-ST; Thu, 29 Jun 2006 01:03:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvogj-0005Z3-H5 for sip@ietf.org; Thu, 29 Jun 2006 01:03:37 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvogi-0007bX-Si for sip@ietf.org; Thu, 29 Jun 2006 01:03:37 -0400 Received: from [131.161.248.86] (open-131-161-248-86.cliq.com [131.161.248.86]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k5T53VF22642; Wed, 28 Jun 2006 22:03:31 -0700 In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F11C4@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB594017F11C4@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Rohan Mahy Subject: Re: [Sip] Ready for WGLC on Outbound? Date: Wed, 28 Jun 2006 22:03:30 -0700 To: "Christer Holmberg \(JO/LMF\)" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Cc: IETF SIP List , Cullen Jennings , Dean Willis , 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: , Errors-To: sip-bounces@ietf.org Hi Christer, On Jun 28, 2006, at 0:01, Christer Holmberg ((JO/LMF)) wrote: > Hi, > > Unfortunately, I don't think all issues have been addressed yet. There=20= > are a number of issues we've been discussing on e-mail, and on some I=20= > think we have even reached agreements. > > > FIRST, the issue I raised in the "Outbound: keep-alive, outbound and=20= > 3489bis" thread has not been issued. STUN NAT keep-alive is nowadays a=20= > "core" STUN usage - not something specific to the outbound mechanism.=20= > We need to separate them, because it should be possible to use STUN=20 > for keep-alive without using the rest of outbound (instance-id, flow=20= > etc etc). > > Chapter 4.2 says: > > "The UAC MAY examine successful registrations for the presence of an=20= > 'outbound' option-tag in a Supported header field value. Presence of=20= > this option-tag indicates that the registrar is compliant with this=20 > specification. > > Again, that is not true if I only support STUN for NAT keep-alive, but=20= > not the rest of outbound. No, if you indicate support for the option tag, you support all the=20 MUSTs in outbound. If you just want to support STUN muxed on the same=20= port as SIP, you can indicate that you do that by adding the=20 keepalive=3Dstun URI parameter. Outbound defines the semantics of = this. This is just like RFC 3265 which happens to define the 202 Accepted=20 response code. It doesn't mean I need to implement all of RFC 3265 to=20= implement 202 (It even referenced this way in MESSAGE). > Now, one COULD of course claim that the generic SIP usage of STUN for=20= > NAT keep-alive shall be described in a SEPARATE document, and that the=20= > outbound spec ONLY describes the STUN keep-alive when used TOGETHER=20 > with outbound. BUT, if that is the case the "keepalive" URI parameter=20= > should not be defined in the outbound draft - it should be defined in=20= > that generic SIP STUN keep-alive usage draft (I ASSUME that we would=20= > use the "keepalive" parameter also when we use STUN keep-alive without=20= > outbound". Also, the text on STUN processing etc should also be=20 > described in the generic draft in that case, because it's not outbound=20= > specific. there is no milestone for a spec for STUN keepalives, and no=20 groundswell of support for a separate draft. We have consensus to go=20 forward with STUN keepalives described in outbound because outbound=20 needs it. If you happen to want a little piece of outbound, you can=20 still implement it. You just don't have a separate shiny RFC number to=20= tell people you've implemented. You can still reference the=20 description of the parameter in the IANA registry (which will have a=20 description of the semantics once outbound is published). > Also, since STUN keep-alive is now a core STUN usage, I wonder if we=20= > can remove the note in chapter 3.5. Because, again, this draft shall=20= > not define the keep-alive mechanism - it is already defined in=20 > 3489bis. outbound defines what a STUN client is supposed to do when the=20 keepalives fail, how fast to backoff, and what to do if the binding=20 response XOR-MAPPED-ADDRESS is different from the address the client=20 had previously. There is a lot of behavior here that is not and should=20= not be in 3489bis. > SECOND, the draft talks about the outbound proxy URIs configured in=20 > the client. I think we agreed that configured URIs are ok as=20 > "default", but I think we should say that the client may also retreive=20= > the proxy address using other mechanisms (e.g. something similar to=20 > the P-CSCF discovery mechanism in IMS). I don't think we need to talk=20= > about "additional mechanisms" that may be defined in the future=20 > (chapter 4.2): we simply say that other mechanisms are outside of the=20= > scope of this document. =46rom Section 4.2: > UAs obtain at configuration time one or more SIP URIs representing the=20= > default outbound-proxy-set. This specification assumes the set is=20 > determined via any of a number of configuration mechanisms and future=20= > specifications may define additional mechanisms such as using DNS to=20= > discover this set. How the UA is configured is outside the scope of=20 > this specification. Everything you mentioned is covered by the previous two sentences. A=20 P-CSCF discovery mechanism is already allowed. > THIRD, I think we agreed that there may be other ways of providing a=20= > reliable system > > Chapter 3.3 says: > > "There are various ways to deploy SIP to build a reliable and scalable=20= > system. This section discusses one such design that is possible with=20= > the mechanisms in this specification. Other designs are also=20 > possible." > > To make it more clear I think it should say: > > "Other designs, where multiple registrations/flows are not required,=20= > are also possible." The existing text is *an* example and fully acknowledges you can build=20= other reliable systems. I also think the existing text is much clearer that your proposed text. > FOURTH, related to the second and third issue, chapter 4.2 says: > > "For each outbound proxy URI in the set, the UA MUST send a REGISTER=20= > in the normal way using this URI as the default outbound proxy." > > Again, there may be other ways to provide reliability. > > And, shall it really be mandatory to register to ALL URIs? In issue=20 > seven I talk about the "max-flow" indicator we've been discussing on=20= > the list. If you don't want to register ALL the URIs you can think of, only=20 configure (by the definition above) the UAC with the URIs you want=20 registered. > FIFTH, related to the second, third and fourth issues, we discussed=20 > that that the network should be able to provide a "max-flow" number to=20= > the client. the maximum number of flows is the number of outbound-proxy-set URIs. =20= If you want to come up with another piece of configuration data (by the=20= very broad definition of configuration we are using) that is a set of=20 candidate URIs for the outbound-proxy-set which are chosen at random up=20= to some maximum to form the outbound-proxy-set, you are free to do so. > SIXTH, one issue we've recently been discussing is what an edge proxy=20= > does if it receives "keepalive=3Dstun", but it doesn't support STUN. I=20= > think we need to say something. I don't think we should just call it=20= > an error case, and therefor it is "an implementation issue" how to=20 > handle it. We can't define rules in an extension for proxies that don't support=20 that extension. The proxy will do whatever it does during this=20 misconfigured case, consistent with RFC3261. > SEVENTH, related to the first issue, chapter 4.2 says: > > "Forming the route set for the request is outside the scope of this=20 > document, but typically results in sending the REGISTER such that the=20= > topmost Route header field contains a loose route to the outbound=20 > proxy URI. Other issues related to outbound route construction are=20 > discussed..." > > Maybe I just missunderstand that text, but IF we use an URI parameter=20= > to indicate STUN NAT keep-alive I think there MUST be a Route header=20= > to the outbound proxy URI. No, you are missing the semantics of keepalive=3Dstun. It is a token=20 which is used by the UAC/STUN client to know that it can mux STUN and=20 SIP traffic. The STUN server/UAS or proxy does nothing with this=20 parameter. The server knows that the the client support STUN if it=20 sends a STUN request. thanks, -rohan > Regards, > > Christer > > > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 28. kes=E4kuuta 2006 2:03 > To: IETF SIP List; Rohan Mahy; Cullen Jennings > Subject: [Sip] Ready for WGLC on Outbound? > > > Rohan said: > >> I'll be on the hook for any outbound-related issues, but AFAIK there >> are no open issues. The draft has incorporated all the comments we >> received. > > So if there are no open issues, are we ready for working group last=20 > call? > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 29 01:47:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvpKy-0005A0-1k; Thu, 29 Jun 2006 01:45:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvpKw-00051M-7Y for sip@ietf.org; Thu, 29 Jun 2006 01:45:10 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvpKu-0001RL-Ob for sip@ietf.org; Thu, 29 Jun 2006 01:45:10 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5T5iwxo027183; Thu, 29 Jun 2006 08:44:59 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 08:44:10 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 08:44:10 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ready for WGLC on Outbound? Date: Thu, 29 Jun 2006 08:44:08 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0279ABD0@esebe103.NOE.Nokia.com> In-Reply-To: <17570.15911.602096.876348@rautu.tutpro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ready for WGLC on Outbound? Thread-Index: Acaaxbkn5mtof+TLR5i0RRtpSJm9lQAd12vw From: To: , X-OriginalArrivalTime: 29 Jun 2006 05:44:10.0087 (UTC) FILETIME=[0B43B770:01C69B3F] X-Spam-Score: 0.2 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: sip@ietf.org, rohan@ekabal.com, fluffy@cisco.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Juha, =20 >also, the requirement that UA must be >able to setup at least two flows is not included. In my understanding it is there, however perhaps not so explicit as you would like it to be mentioned. This is what the latest draft says: UAs obtain at configuration time one or more SIP URIs representing the default outbound-proxy-set ... However, a UA MUST support sets with at least two outbound proxy URIs and SHOULD support sets with up to four URIs. For each outbound proxy URI in the set, the UA MUST send a REGISTER in the normal way using this URI as the default outbound proxy. In other words UA MUST support a set of 2-4 proxies and set up flows to as many proxies as ultimately configured or discovered i.e. 1-4. This means there can not be a compliant UA which only supports one single flow ever. Regards, Erkki >-----Original Message----- >From: ext Juha Heinanen [mailto:jh@tutpro.com]=20 >Sent: 28.June.2006 11:31 >To: Dean Willis >Cc: IETF SIP List; Rohan Mahy; Cullen Jennings >Subject: [Sip] Ready for WGLC on Outbound? > >Dean Willis writes: > >=20 > > So if there are no open issues, are we ready for working=20 >group last =20 > > call? > >i sent text to remove the primary/backup stuff and have not seen that >incorporated in any draft. also, the requirement that UA must be >able to setup at least two flows is not included. > >-- 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 Jun 29 01:59:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvpXC-0003QW-CV; Thu, 29 Jun 2006 01:57:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvpXA-0003QR-Vy for sip@ietf.org; Thu, 29 Jun 2006 01:57:48 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvpX6-0001eD-Vt for sip@ietf.org; Thu, 29 Jun 2006 01:57:48 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DA1788D0; Thu, 29 Jun 2006 07:57:43 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 07:57:43 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 07:57:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ready for WGLC on Outbound? Date: Thu, 29 Jun 2006 07:57:42 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F1204@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ready for WGLC on Outbound? Thread-Index: AcabOW7bdcb6KW99SwSrZyKCCI1pFwAAno6w From: "Christer Holmberg \(JO/LMF\)" To: "Rohan Mahy" X-OriginalArrivalTime: 29 Jun 2006 05:57:43.0293 (UTC) FILETIME=[EFF91AD0:01C69B40] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Cc: IETF SIP List , Cullen Jennings , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Rohan, Thanks for your reply! Comments inline.=20 > Unfortunately, I don't think all issues have been addressed yet. There > are a number of issues we've been discussing on e-mail, and on some I=20 > think we have even reached agreements. > > > FIRST, the issue I raised in the "Outbound: keep-alive, outbound and=20 > 3489bis" thread has not been issued. STUN NAT keep-alive is nowadays a > "core" STUN usage - not something specific to the outbound mechanism. > We need to separate them, because it should be possible to use STUN=20 > for keep-alive without using the rest of outbound (instance-id, flow=20 > etc etc). > > Chapter 4.2 says: > > "The UAC MAY examine successful registrations for the presence of an=20 > 'outbound' option-tag in a Supported header field value. Presence of=20 > this option-tag indicates that the registrar is compliant with this=20 > specification. > > Again, that is not true if I only support STUN for NAT keep-alive, but > not the rest of outbound. >No, if you indicate support for the option tag, you support all the MUSTs in outbound. If you just want to support STUN=20 >muxed on the same port as SIP, you can indicate that you do that by adding the=20 >keepalive=3Dstun URI parameter. Outbound defines the semantics of = this. [CHH] Perhaps, but I don't think it's clearly indicated that the STUN NAT keep-alive can be used as a "stand alone" feature. I don't think much text is needed for that. I also think that the scope of the document clearly shall say that the document defines how to use the STUN keep-alive (and also, as I mention futher down, the connectivity check) usage, as defined in 3489bis, for SIP. [/CHH] >This is just like RFC 3265 which happens to define the 202 Accepted response code. It doesn't mean I need to implement=20 >all of RFC 3265 to implement 202 (It even referenced this way in MESSAGE). > >Now, one COULD of course claim that the generic SIP usage of STUN for=20 >NAT keep-alive shall be described in a SEPARATE document, and that the=20 >outbound spec ONLY describes the STUN keep-alive when used TOGETHER=20 >with outbound. BUT, if that is the case the "keepalive" URI parameter=20 >should not be defined in the outbound draft - it should be defined in=20 >that generic SIP STUN keep-alive usage draft (I ASSUME that we would=20 >use the "keepalive" parameter also when we use STUN keep-alive without=20 >outbound". Also, the text on STUN processing etc should also be=20 >described in the generic draft in that case, because it's not outbound=20 >specific. > >there is no milestone for a spec for STUN keepalives, and no groundswell of support for a separate draft. We have=20 >consensus to go forward with STUN keepalives described in outbound because outbound needs it. If you happen to want a=20 >little piece of outbound, you can still implement it. You just don't have a separate shiny RFC number to tell people=20 >you've implemented. You can still reference the description of the parameter in the IANA registry (which will have a=20 >description of the semantics once outbound is published). [CHH] I have no problem with keeping the STUN keep-alive stuff in the outbound draft. Again, what I am asking for is to more clearly separate it, as a stand alone feature, from the rest of the outbound stuff. Of course we can say that the support of outbound requires the support of STUN keep-alive. [/CHH] >Also, since STUN keep-alive is now a core STUN usage, I wonder if we=20 >can remove the note in chapter 3.5. Because, again, this draft shall=20 >not define the keep-alive mechanism - it is already defined in=20 >3489bis. > >outbound defines what a STUN client is supposed to do when the keepalives fail, how fast to backoff, and what to do if=20 >the binding response XOR-MAPPED-ADDRESS is different from the address the client had previously. There is a lot of=20 >behavior here that is not and should not be in 3489bis. [CHH] I totally agree with you. 3489bis defiens the STUN keep-alive usage, and the outbound draft describes how to "adopt" it with SIP. And, that is what I think should be more clear in the spec. The outbound draft does not define the usage of STUN for keep-alive as such, only how to use it for SIP. The outbound draft DOES refer to 3489bis, but it does not mention the USAGE defined ni 3489bis. Related to that, chapter 7.1 says: "This document defines a new STUN usage for connectivity checks." Again, this usage is already defined in 3489bis (chapter 12.3), so we only need to adopt it to SIP. [/CHH] >>SECOND, the draft talks about the outbound proxy URIs configured in=20 >>the client. I think we agreed that configured URIs are ok as=20 >>"default", but I think we should say that the client may also retreive >>the proxy address using other mechanisms (e.g. something similar to=20 >>the P-CSCF discovery mechanism in IMS). I don't think we need to talk=20 >>about "additional mechanisms" that may be defined in the future=20 >>(chapter 4.2): we simply say that other mechanisms are outside of the=20 >>scope of this document. >> >>From Section 4.2: >>UAs obtain at configuration time one or more SIP URIs representing the >>default outbound-proxy-set. This specification assumes the set is=20 >>determined via any of a number of configuration mechanisms and future=20 >>specifications may define additional mechanisms such as using DNS to=20 >>discover this set. How the UA is configured is outside the scope of=20 >>this specification. > >Everything you mentioned is covered by the previous two sentences. A P-CSCF discovery mechanism is already allowed. [CHH] I still don't understand why normative text should talk about the future...=20 Also, the issue is that what may be configured (no matter how you configure it) may not be a URI. It may simply be an IP address/FQDN, which is then used to build a SIP-URI. I think we shall allow that, and make it more clear in the spec. [/CHH] >>THIRD, I think we agreed that there may be other ways of providing a=20 >>reliable system >> >>Chapter 3.3 says: >> >>"There are various ways to deploy SIP to build a reliable and scalable >>system. This section discusses one such design that is possible with=20 >>the mechanisms in this specification. Other designs are also=20 >>possible." > >>To make it more clear I think it should say: > >>"Other designs, where multiple registrations/flows are not required,=20 >>are also possible." > >The existing text is *an* example and fully acknowledges you can build other reliable systems. >I also think the existing text is much clearer that your proposed text. [CHH] So, what text do you think clearly says that there may be scenarios where only a single flow can be used? Just saying that one chapter describes *an* example doesn't make that clear. Also, "Other designs" sounds to me like using mechanisms that are not defined "in this specification", which is not correct. Even if you only register a single flow you would use the mechanism "in this specification". [/CHH] >>FOURTH, related to the second and third issue, chapter 4.2 says: >> >>"For each outbound proxy URI in the set, the UA MUST send a REGISTER=20 >>in the normal way using this URI as the default outbound proxy." >> >>Again, there may be other ways to provide reliability. >> >>And, shall it really be mandatory to register to ALL URIs? In issue=20 >>seven I talk about the "max-flow" indicator we've been discussing on=20 >>the list. > >If you don't want to register ALL the URIs you can think of, only configure (by the definition above) the UAC with the=20 >URIs you want registered. [CHH] Again, you may not always configure the edge proxies "manually". You may use a separate discovery mechanism. And, that discovery mechanism may, for different reasons, provide a list of edge proxies, but that doesn't mean that you always want to register to all of them at the same time. [/CHH] >>FIFTH, related to the second, third and fourth issues, we discussed=20 >>that that the network should be able to provide a "max-flow" number to >>the client. >> >the maximum number of flows is the number of outbound-proxy-set URIs. =20 >If you want to come up with another piece of configuration data (by the very broad definition of configuration we are=20 >using) that is a set of candidate URIs for the outbound-proxy-set which are chosen at random up to some maximum to form=20 >the outbound-proxy-set, you are free to do so. [CHH] I am not talking about new configuration data, but a value that could be returned (in the registration response) by the network to the client, indicating how many flows to configure. The client then does not need to try to register more flows, if the network isn't going to accept them anyway. [/CHH]=20 >>SIXTH, one issue we've recently been discussing is what an edge proxy=20 >>does if it receives "keepalive=3Dstun", but it doesn't support STUN. I = >>think we need to say something. I don't think we should just call it=20 >>an error case, and therefor it is "an implementation issue" how to=20 >>handle it. > >We can't define rules in an extension for proxies that don't support that extension. The proxy will do whatever it does=20 >during this misconfigured case, consistent with RFC3261. > >>SEVENTH, related to the first issue, chapter 4.2 says: >> >>"Forming the route set for the request is outside the scope of this=20 >>document, but typically results in sending the REGISTER such that the=20 >>topmost Route header field contains a loose route to the outbound=20 >>proxy URI. Other issues related to outbound route construction are=20 >>discussed..." >> >>Maybe I just missunderstand that text, but IF we use an URI parameter=20 >>to indicate STUN NAT keep-alive I think there MUST be a Route header=20 >>to the outbound proxy URI. >> >No, you are missing the semantics of keepalive=3Dstun. It is a token which is used by the UAC/STUN client to know that it=20 >can mux STUN and SIP traffic. The STUN server/UAS or proxy does nothing with this parameter. The server knows that the=20 >the client support STUN if it sends a STUN request. [CHH] If that is true, what is wrong with the client using the Supported header (Supported: keepalive) to indicate that?=20 Also, as I asked in another mail: would it be possible for the STUN server, by inserting the keepalive parameter in the Path URI, to indicate that IT supports STUN?=20 I see no harm in allowing the server to indicate whether it supports STUN or not, BEFORE the client starts sending STUN requests and figures it out itself... [/CHH] Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 29 02:23:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvpub-0003zS-KG; Thu, 29 Jun 2006 02:22:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvpuZ-0003zN-Ds for sip@ietf.org; Thu, 29 Jun 2006 02:21:59 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvpuU-0004qU-Oe for sip@ietf.org; Thu, 29 Jun 2006 02:21:59 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5T6LiWw025832; Thu, 29 Jun 2006 09:21:46 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 09:21:01 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 09:21:00 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [Sip] A mismatch between outbound-04 vs. outbound-discovery-02 Date: Thu, 29 Jun 2006 09:20:59 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0279AC1C@esebe103.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A mismatch between outbound-04 vs. outbound-discovery-02 Thread-Index: AcaayJatcy5pVTwfQXa2kpwAzUlxQQAeF3kA From: To: , X-OriginalArrivalTime: 29 Jun 2006 06:21:00.0612 (UTC) FILETIME=[30D71040:01C69B44] X-Spam-Score: 1.3 (+) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: sip@ietf.org, fluffy@cisco.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 As Outbound (-04) has now been changed to specify that all the proxies and flows between those proxies and UAs are handled=20 in the equal way, there is a mismatch with it and my latest draft-koivusalo-sip-outbound-discovery-02. In this comment: http://www1.ietf.org/mail-archive/web/sip/current/msg14172.html I was instructed for outbound-discovery keep two options open: 1. all proxies using the flows actively and balancing the load between them 2. have a separate set of idle backup proxies which would be=20 used for routing other SIP requests than REGISTER only in=20 the case when the primary flows will fail draft-koivusalo-sip-outbound-discovery-02 defines a mechanism which allows DNS SRV RRs to be configured to ask the UA to use=20 the proxies in either of the two ways. However Outbound -04 seems to make this second scheme impossible. Even if the UA would prefer the primary proxies for sending requests, the network would still route requests towards the UA over=20 whichever flow any proxy has open for that UA. This seems to prohibit building configurations where N proxies would be protected with 1 redundant proxy. To me such a scheme would look potentially useful, but would it make outbound itself too complicated and not worth the effort ? In my understanding one of the drafts needs an update for alignment. Easiest solution would be to drop this second option from draft-koivusalo-sip-outbound-discovery, but is the WG happy with such a resolution ? Regards, Erkki >-----Original Message----- >From: ext Rohan Mahy [mailto:rohan@ekabal.com]=20 >Sent: 28.June.2006 18:35 >To: Juha Heinanen >Cc: IETF SIP List; Rohan Mahy; Cullen Jennings; Dean Willis >Subject: Re: [Sip] Ready for WGLC on Outbound? > >Hi Juha, > >Primary/Secondary terminology was completely removed from the Section=20 >4.2 of the -04 draft: >> UAs obtain at configuration time one or more SIP URIs=20 >representing the=20 >> default outbound-proxy-set. This specification assumes the set is=20 >> determined via any of a number of configuration mechanisms=20 >and future=20 >> specifications may define additional mechanisms such as using DNS to=20 >> discover this set. How the UA is configured is outside the scope of=20 >> this specification. However, a UA MUST support sets with at=20 >least two=20 >> outbound proxy URIs and SHOULD support sets with up to four=20 >URIs. For=20 >> each outbound proxy URI in the set, the UA MUST send a=20 >REGISTER in the=20 >> normal way using this URI as the default outbound proxy. Forming the=20 >> route set for the request is outside the scope of this document, but=20 >> typically results in sending the REGISTER such that the=20 >topmost Route=20 >> header field contains a loose route to the outbound proxy URI. Other=20 >> issues related to outbound route construction are discussed in=20 >> [I-D.rosenberg-sip-route-construct]. > >The only remaining instances of primary/secondary terminology are=20 >non-normative explanations in one definition, in one scenario=20 >described=20 >in the Overview, and in the example in Section 8. > >from Section 2.1 Definitions >> outbound-proxy-set >> A set of SIP URIs (Uniform Resource Identifiers) that represents=20 >> each of the outbound proxies (often Edge Proxies) with which the UA=20 >> will attempt to maintain a direct flow. The first URI in the set is=20 >> often referred to as the primary outbound proxy and the=20 >second as the=20 >> secondary outbound proxy. There is no difference between any of the=20 >> URIs in this set, nor does the primary/secondary terminology imply=20 >> that one is preferred over the other. > > >from Section 3.3 (part of the Overview): >> In the example system below, the logical outbound=20 >proxy/registrar for=20 >> the domain is running on two hosts that share the appropriate state=20 >> and can both provide registrar and outbound proxy functionality for=20 >> the domain. The UA will form connections to two of the=20 >physical hosts=20 >> that can perform the outbound proxy/registrar function for=20 >the domain.=20 >> Reliability is achieved by having the UA form two TCP connections to=20 >> the domain. >> >> Scalability is achieved by using DNS SRV to load balance the primary=20 >> connection across a set of machines that can service the primary=20 >> connection and also using DNS SRV to load balance across a separate=20 >> set of machines that can service the secondary connection. The=20 >> deployment here requires that DNS is configured with one entry that=20 >> resolves to all the primary hosts and another entry that resolves to=20 >> all the secondary hosts. While this introduces additional DNS=20 >> configuration, the approach works and requires no addition SIP=20 >> extensions. >> >> Note: Approaches which select multiple connections from a single=20 >> DNS SRV set were also considered, but cannot prevent two connections=20 >> from accidentally resolving to the same host. The approach in this=20 >> document does not prevent future extensions, such as the SIP UA=20 >> configuration framework [I-D.ietf-sipping-config-framework], from=20 >> adding other ways for a User Agent to discover its=20 >outbound-proxy-set. > >thanks, >-rohan > > >On Jun 28, 2006, at 1:30, Juha Heinanen wrote: >> Dean Willis writes: >>> >>> So if there are no open issues, are we ready for working group last >>> call? >> >> i sent text to remove the primary/backup stuff and have not seen that >> incorporated in any draft. also, the requirement that UA must be >> able to setup at least two flows is not included. >> >> -- 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 Jun 29 03:20:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvqnS-00073W-8U; Thu, 29 Jun 2006 03:18:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvqnQ-00073M-Lx for sip@ietf.org; Thu, 29 Jun 2006 03:18:40 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvqnM-0001fB-0g for sip@ietf.org; Thu, 29 Jun 2006 03:18:40 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4ACDE6E0001; Thu, 29 Jun 2006 09:18:35 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 09:18:35 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 09:18:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound-04 and "max-flow" in 200 OK for REGISTER Date: Thu, 29 Jun 2006 09:18:33 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F1207@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound-04 and "max-flow" in 200 OK for REGISTER Thread-Index: AcabOZKCoWq4oidDToWeMTDiITTNNAABwOIwAAKx0jA= From: "Christer Holmberg \(JO/LMF\)" To: , X-OriginalArrivalTime: 29 Jun 2006 07:18:34.0546 (UTC) FILETIME=[3B8B9120:01C69B4C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: sip@ietf.org, fluffy@cisco.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I agree with Erkki. Regards, Christer -----Original Message----- From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com]=20 Sent: 29. kes=E4kuuta 2006 10:04 To: rohan@ekabal.com; Christer Holmberg (JO/LMF) Cc: sip@ietf.org; fluffy@cisco.com; dean.willis@softarmor.com Subject: [Sip] Outbound-04 and "max-flow" in 200 OK for REGISTER Hi, >> FIFTH, related to the second, third and fourth issues, we discussed=20 >> that that the network should be able to provide a "max-flow" number=20 >> to the client. > >the maximum number of flows is the number of outbound-proxy-set URIs. =20 >If you want to come up with another piece of configuration data (by the = >very broad definition of configuration we are using) that is a set of=20 >candidate URIs for the outbound-proxy-set which are chosen at random up = >to some maximum to form the outbound-proxy-set, >you are free to do so. I would like to point out two emails in the thread where this "max-flow" = issue was discussed: http://www1.ietf.org/mail-archive/web/sip/current/msg14745.html http://www1.ietf.org/mail-archive/web/sip/current/msg14753.html In that thread a solution was outlined as follows: "Network must provide max-flows in Register response. Client must not exceed max-flows when establishing flows. Client should attempt to equal max-flows if terminal capabilities = allows." To me this sounds a good idea due to the following facts: - Instead of explicit configuration the UA might find the proxies supporting outbound e.g. from DNS - The number of proxies configured in DNS does not necessarily equal to the number of flows the UA should set up. For instance the service provider might have there many proxies to do load balancing but targets to have reliability on other means than the UAs maintaining multiple flows. Thus I was also expecting the proposed a solution to appear in outbound-04 (or later version). In sip-outbound-discovery-02 there is = text like this: Whether the UA actually sets up one single flow or two redundant flows, is determined in the following ways: o When the network responds to the primary REGISTER with 200 OK, the response may contain an indication telling the maximum number of flows the network expects the UA to use. The UA SHOULD create two flows if the indicated value is at least two or if the network does not give the indication at all. [[OPEN: the details of this indication are still to be defined but are not in scope of this spec]] I have not seen any serious comments given why this could not be = specified like proposed and would thus vote for adding it to outbound = -05. Regards, Erkki ____________________________________ Erkki Koivusalo Nokia Mobile Software tel:+358 40 7571197 mailto:erkki.koivusalo@nokia.com ____________________________________=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 29 03:38:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvr4f-00066d-Sl; Thu, 29 Jun 2006 03:36:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvr4d-00066Y-KQ for sip@ietf.org; Thu, 29 Jun 2006 03:36:27 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvr4Z-0002hZ-3p for sip@ietf.org; Thu, 29 Jun 2006 03:36:27 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5T7aEYk018027; Thu, 29 Jun 2006 10:36:15 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 10:36:15 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 10:36:14 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [Sip] Outbound-04 and proxy indicating support for STUN keepalives Date: Thu, 29 Jun 2006 10:36:13 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0279ACF8@esebe103.NOE.Nokia.com> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F1204@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound-04 and proxy indicating support for STUN keepalives Thread-Index: AcabOW7bdcb6KW99SwSrZyKCCI1pFwAAno6wAAOVZWA= From: To: , X-OriginalArrivalTime: 29 Jun 2006 07:36:14.0798 (UTC) FILETIME=[B3812EE0:01C69B4E] X-Spam-Score: 0.2 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: sip@ietf.org, fluffy@cisco.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, >>No, you are missing the semantics of keepalive=3Dstun. It is a token=20 >>which is used by the UAC/STUN client to know that it can mux STUN and=20 >>SIP traffic. The STUN server/UAS or proxy does nothing with this=20 >>parameter. The server knows that the the client support STUN if it=20 >>sends a STUN request.=20 >Also, as I asked in another mail: would it be possible for the STUN >server, by inserting the keepalive parameter in the Path URI, to >indicate that IT supports STUN?=20 > >I see no harm in allowing the server to indicate whether it supports >STUN or not, BEFORE the client starts sending STUN requests and figures >it out itself... [/CHH] The following email in my opinion describes very well the reasons why outbound would need a way within SIP signalling to indicate if the contacted proxy actually supports STUN keepalives or not: http://www1.ietf.org/mail-archive/web/sip/current/msg13802.html Another reason for the indication is that the UA might derive the outbound-proxy-set from a URI got from DHCP or AOR of the user. In those cases is is not possible to get any keepalive=3Dstun token along with the URI. It seems that outbound-04 does not provide a solution for this issue and would call for a related update.=20 The thread from end of March with name RE: [Sip] How to indicate during=20 proxy discovery that a proxysupports"outbound" contains an extensive discussion of the subject. In the end Jeroen van Bemmel outlined the possible solution like this: >> "Proxy-Require: outbound" would mean that the proxy must support STUN >> (i.e. expect it and send replies), Path and the generation/mapping of >> flow identifiers. >> "Require: outbound" would mean that the registrar must support STUN and=20 >> the mapping of flow identifiers >> >> I personally don't see any ambiguity here. So in my mind the UAC would=20 >> send >> >> REGISTER >> Require: outbound >> Proxy-Require: outbound >> Supported: path >> .... >> >> and if there is an edge proxy, it would remove only the Proxy-Require >> header. The registrar would even be able to detect whether it should=20 >> expect STUN requests (if there is still a Proxy-Require, it would be a=20 >> direct connection). However, I don't see why it would need to know this. Regards, Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 29 03:57:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvrMm-0001C6-Pi; Thu, 29 Jun 2006 03:55:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvrMl-0001Bq-Ah; Thu, 29 Jun 2006 03:55:11 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvqoD-0001fy-Uf; Thu, 29 Jun 2006 03:19:29 -0400 Received: from pine.neustar.com ([209.173.57.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvqLi-0002Hy-8b; Thu, 29 Jun 2006 02:50:06 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5T6o1UA009278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Jun 2006 06:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvqLh-00006w-PH; Thu, 29 Jun 2006 02:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 29 Jun 2006 02:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-location-conveyance-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: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Session Initiation Protocol Location Conveyance Author(s) : J. Polk, B. Rosen Filename : draft-ietf-sip-location-conveyance-03.txt Pages : 29 Date : 2006-6-28 This document defines how the Session Initiation Protocol (SIP) conveys, or pushes, geographic location information from one SIP entity to another SIP entity. SIP Location Conveyance is always end to end, but sometimes the embedded location information can be acted upon by SIP Servers to direct where the message goes, based on where the user agent client is. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-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-location-conveyance-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-location-conveyance-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: <2006-6-28202058.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-location-conveyance-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-location-conveyance-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-28202058.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Thu Jun 29 04:13:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvrcu-0002qd-Oh; Thu, 29 Jun 2006 04:11:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvrct-0002qQ-NJ for sip@ietf.org; Thu, 29 Jun 2006 04:11:51 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvrcp-0004Oc-1l for sip@ietf.org; Thu, 29 Jun 2006 04:11:51 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6B18766B; Thu, 29 Jun 2006 10:11:46 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 10:11:46 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 10:11:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound-04 and proxy indicating support for STUN keepalives Date: Thu, 29 Jun 2006 10:11:45 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F120C@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound-04 and proxy indicating support for STUN keepalives Thread-Index: AcabOW7bdcb6KW99SwSrZyKCCI1pFwAAno6wAAOVZWAAAkAYwA== From: "Christer Holmberg \(JO/LMF\)" To: , X-OriginalArrivalTime: 29 Jun 2006 08:11:46.0001 (UTC) FILETIME=[A9CCF410:01C69B53] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: sip@ietf.org, fluffy@cisco.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Erkki, The problem with Proxy-Require (Proxy-Require: keepalive) is that it = would require ALL proxies in the path to support STUN, and I don't think = we want that. Regards, Christer =20 -----Original Message----- From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com]=20 Sent: 29. kes=E4kuuta 2006 10:36 To: Christer Holmberg (JO/LMF); rohan@ekabal.com Cc: sip@ietf.org; fluffy@cisco.com; dean.willis@softarmor.com Subject: [Sip] Outbound-04 and proxy indicating support for STUN = keepalives Hi, >>No, you are missing the semantics of keepalive=3Dstun. It is a token=20 >>which is used by the UAC/STUN client to know that it can mux STUN and=20 >>SIP traffic. The STUN server/UAS or proxy does nothing with this=20 >>parameter. The server knows that the the client support STUN if it=20 >>sends a STUN request. >Also, as I asked in another mail: would it be possible for the STUN=20 >server, by inserting the keepalive parameter in the Path URI, to=20 >indicate that IT supports STUN? > >I see no harm in allowing the server to indicate whether it supports=20 >STUN or not, BEFORE the client starts sending STUN requests and figures = >it out itself... [/CHH] The following email in my opinion describes very well the reasons why = outbound would need a way within SIP signalling to indicate if the = contacted proxy actually supports STUN keepalives or not: http://www1.ietf.org/mail-archive/web/sip/current/msg13802.html Another reason for the indication is that the UA might derive the = outbound-proxy-set from a URI got from DHCP or AOR of the user. In those = cases is is not possible to get any keepalive=3Dstun token along with = the URI. It seems that outbound-04 does not provide a solution for this issue and = would call for a related update.=20 The thread from end of March with name RE: [Sip] How to indicate during = proxy discovery that a proxysupports"outbound" contains an extensive = discussion of the subject. In the end Jeroen van Bemmel outlined the = possible solution like this: >> "Proxy-Require: outbound" would mean that the proxy must support STUN >> (i.e. expect it and send replies), Path and the generation/mapping of >> flow identifiers. >> "Require: outbound" would mean that the registrar must support STUN and=20 >> the mapping of flow identifiers >> >> I personally don't see any ambiguity here. So in my mind the UAC would=20 >> send >> >> REGISTER >> Require: outbound >> Proxy-Require: outbound >> Supported: path >> .... >> >> and if there is an edge proxy, it would remove only the Proxy-Require >> header. The registrar would even be able to detect whether it should=20 >> expect STUN requests (if there is still a Proxy-Require, it would be a=20 >> direct connection). However, I don't see why it would need to know this. Regards, Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 29 04:17:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvrh6-0002C4-Oh; Thu, 29 Jun 2006 04:16:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvrh6-0002Bz-09 for sip@ietf.org; Thu, 29 Jun 2006 04:16:12 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvrh0-0004fg-Au for sip@ietf.org; Thu, 29 Jun 2006 04:16:11 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 873446E0001; Thu, 29 Jun 2006 10:16:05 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 10:16:04 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 10:16:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound-04 and proxy indicating support for STUN keepalives Date: Thu, 29 Jun 2006 10:16:03 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F120D@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound-04 and proxy indicating support for STUN keepalives Thread-Index: AcabOW7bdcb6KW99SwSrZyKCCI1pFwAAno6wAAOVZWAAAkAYwAAANFsA From: "Christer Holmberg \(JO/LMF\)" To: , X-OriginalArrivalTime: 29 Jun 2006 08:16:04.0589 (UTC) FILETIME=[43EE59D0:01C69B54] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: sip@ietf.org, fluffy@cisco.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi again Erkki, I think we are talking about separate things. You talk about being able = to make sure proxies support outbound, while I am talking about a way = for a proxy to indicate that it supports STUN NAT keep-alive :) Regards, Christer =20 -----Original Message----- From: Christer Holmberg (JO/LMF)=20 Sent: 29. kes=E4kuuta 2006 11:12 To: 'Erkki.Koivusalo@nokia.com'; rohan@ekabal.com Cc: sip@ietf.org; fluffy@cisco.com; dean.willis@softarmor.com Subject: RE: [Sip] Outbound-04 and proxy indicating support for STUN = keepalives Hi Erkki, The problem with Proxy-Require (Proxy-Require: keepalive) is that it = would require ALL proxies in the path to support STUN, and I don't think = we want that. Regards, Christer =20 -----Original Message----- From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com] Sent: 29. kes=E4kuuta 2006 10:36 To: Christer Holmberg (JO/LMF); rohan@ekabal.com Cc: sip@ietf.org; fluffy@cisco.com; dean.willis@softarmor.com Subject: [Sip] Outbound-04 and proxy indicating support for STUN = keepalives Hi, >>No, you are missing the semantics of keepalive=3Dstun. It is a token=20 >>which is used by the UAC/STUN client to know that it can mux STUN and=20 >>SIP traffic. The STUN server/UAS or proxy does nothing with this=20 >>parameter. The server knows that the the client support STUN if it=20 >>sends a STUN request. >Also, as I asked in another mail: would it be possible for the STUN=20 >server, by inserting the keepalive parameter in the Path URI, to=20 >indicate that IT supports STUN? > >I see no harm in allowing the server to indicate whether it supports=20 >STUN or not, BEFORE the client starts sending STUN requests and figures = >it out itself... [/CHH] The following email in my opinion describes very well the reasons why = outbound would need a way within SIP signalling to indicate if the = contacted proxy actually supports STUN keepalives or not: http://www1.ietf.org/mail-archive/web/sip/current/msg13802.html Another reason for the indication is that the UA might derive the = outbound-proxy-set from a URI got from DHCP or AOR of the user. In those = cases is is not possible to get any keepalive=3Dstun token along with = the URI. It seems that outbound-04 does not provide a solution for this issue and = would call for a related update.=20 The thread from end of March with name RE: [Sip] How to indicate during = proxy discovery that a proxysupports"outbound" contains an extensive = discussion of the subject. In the end Jeroen van Bemmel outlined the = possible solution like this: >> "Proxy-Require: outbound" would mean that the proxy must support STUN >> (i.e. expect it and send replies), Path and the generation/mapping of >> flow identifiers. >> "Require: outbound" would mean that the registrar must support STUN and=20 >> the mapping of flow identifiers >> >> I personally don't see any ambiguity here. So in my mind the UAC would=20 >> send >> >> REGISTER >> Require: outbound >> Proxy-Require: outbound >> Supported: path >> .... >> >> and if there is an edge proxy, it would remove only the Proxy-Require >> header. The registrar would even be able to detect whether it should=20 >> expect STUN requests (if there is still a Proxy-Require, it would be a=20 >> direct connection). However, I don't see why it would need to know this. Regards, Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 29 05:43:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvt1U-0004uy-TU; Thu, 29 Jun 2006 05:41:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvt1T-0004uq-KG for sip@ietf.org; Thu, 29 Jun 2006 05:41:19 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvs8u-00077A-2y for sip@ietf.org; Thu, 29 Jun 2006 04:44:56 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvrtL-0005ON-Ks for sip@ietf.org; Thu, 29 Jun 2006 04:28:55 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5T8Smus029942; Thu, 29 Jun 2006 11:28:48 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 11:27:49 +0300 Received: from [172.21.35.72] ([172.21.35.72]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 29 Jun 2006 11:27:48 +0300 Message-ID: <44A38F02.6050604@nokia.com> Date: Thu, 29 Jun 2006 11:27:46 +0300 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: ext Jonathan Rosenberg Subject: Re: [Sip] Additional uses of INFO References: <20060621212403.47032.qmail@web36406.mail.mud.yahoo.com> <449AD6FB.4030402@cisco.com> <6A371E14-EAB1-46A6-A253-60BA8EC3AA39@softarmor.com> <449C5020.3060904@cisco.com> In-Reply-To: <449C5020.3060904@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jun 2006 08:27:48.0769 (UTC) FILETIME=[E7A7B110:01C69B55] X-Spam-Score: -2.6 (--) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sip@ietf.org, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Inline. ext Jonathan Rosenberg wrote: > This is because HTTP has a much cleaner separation between HTTP and the > application that sits ontop of it. HTTP merely passes content, and the > thing ontop 'renders' it. This may ring true for INVITE, but surely not for MESSAGE, which is exactly the same pass'n'render concept. > SIP doesn't have such a clean notion of an 'application' that sits ontop > of SIP. Data that, for one implementation, looks like 'applciation > data', might be processed by the 'core sip stack' on the other end. > Thats because SIP is meant to address a specific application itself - > interactive communications. I'm not sure I agree -- what do you mean by 'core sip stack'? I've rarely seen a SIP stack that parses or interprets anything but SIP; after all it's its primary purpose in life. It really should let others handle 'application data'. But for me as an application developer, I don't really care whether I have to write: if (strcmp(sip->method, "X-FOOBAR") == 0) { or: if (strcmp(sip->method, "INFO") == 0 && strcasecmp(sip->content_type, "application/x-foobar") == 0) { Why I reckon people are preferring the latter is because the former is strictly not allowed. Proprietary methods are considered bad design in SIP, and a lot of people have been saying for years you're not supposed to use them. This is worrying, because developers clearly want vehicles to carry stuff like RPC; yet, SIP has not defined such a vehicle properly, and instead seems to be saying to developers: "Go somewhere else, we don't do that here." Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 29 05:46:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvt4U-0006Uh-Cs; Thu, 29 Jun 2006 05:44:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvt4S-0006Uc-Vx for sip@ietf.org; Thu, 29 Jun 2006 05:44:24 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvqng-0001fy-El for sip@ietf.org; Thu, 29 Jun 2006 03:18:56 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvqaK-0002l9-7t for sip@ietf.org; Thu, 29 Jun 2006 03:05:12 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5T74tw8001932; Thu, 29 Jun 2006 10:04:59 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 10:04:13 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 10:04:12 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [Sip] Outbound-04 and "max-flow" in 200 OK for REGISTER Date: Thu, 29 Jun 2006 10:04:10 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0279ACAF@esebe103.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound-04 and "max-flow" in 200 OK for REGISTER Thread-Index: AcabOZKCoWq4oidDToWeMTDiITTNNAABwOIw From: To: , X-OriginalArrivalTime: 29 Jun 2006 07:04:12.0535 (UTC) FILETIME=[39BF2070:01C69B4A] X-Spam-Score: -2.4 (--) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: sip@ietf.org, fluffy@cisco.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, >> FIFTH, related to the second, third and fourth issues, we =20 >> discussed that that the network should be able to provide =20 >> a "max-flow" number to the client. > >the maximum number of flows is the number of outbound-proxy-set=20 >URIs. If you want to come up with another piece of configuration=20 >data (by the very broad definition of configuration we are using)=20 >that is a set of candidate URIs for the outbound-proxy-set which=20 >are chosen at random up to some maximum to form the outbound-proxy-set, >you are free to do so. I would like to point out two emails in the thread where this "max-flow" issue was discussed: http://www1.ietf.org/mail-archive/web/sip/current/msg14745.html http://www1.ietf.org/mail-archive/web/sip/current/msg14753.html In that thread a solution was outlined as follows: "Network must provide max-flows in Register response. Client must not exceed max-flows when establishing flows. Client should attempt to equal max-flows if terminal capabilities allows." To me this sounds a good idea due to the following facts: - Instead of explicit configuration the UA might find the proxies supporting outbound e.g. from DNS - The number of proxies configured in DNS does not necessarily equal to the number of flows the UA should set up. For instance the service provider might have there many proxies to do load balancing but targets to have reliability on other means than the UAs maintaining multiple flows. Thus I was also expecting the proposed a solution to appear in outbound-04 (or later version). In sip-outbound-discovery-02 there is text like this: Whether the UA actually sets up one single flow or two redundant flows, is determined in the following ways: o When the network responds to the primary REGISTER with 200 OK, the response may contain an indication telling the maximum number of flows the network expects the UA to use. The UA SHOULD create two flows if the indicated value is at least two or if the network does not give the indication at all. [[OPEN: the details of this indication are still to be defined but are not in scope of this spec]] I have not seen any serious comments given why this could not be specified like proposed and would thus vote for=20 adding it to outbound -05. Regards, Erkki ____________________________________ Erkki Koivusalo Nokia Mobile Software tel:+358 40 7571197 mailto:erkki.koivusalo@nokia.com ____________________________________=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 29 05:46:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvt4m-0006W9-Dc; Thu, 29 Jun 2006 05:44:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvt4k-0006Vu-V1 for sip@ietf.org; Thu, 29 Jun 2006 05:44:42 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvt4g-00042S-DK for sip@ietf.org; Thu, 29 Jun 2006 05:44:42 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5T9iRhQ014284; Thu, 29 Jun 2006 12:44:30 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 12:44:29 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 12:44:28 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound-04 and proxy indicating support for STUN keepalives Date: Thu, 29 Jun 2006 12:44:27 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F027D09E1@esebe103.NOE.Nokia.com> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F120C@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound-04 and proxy indicating support for STUN keepalives Thread-Index: AcabOW7bdcb6KW99SwSrZyKCCI1pFwAAno6wAAOVZWAAAkAYwAADI6nQ From: To: , X-OriginalArrivalTime: 29 Jun 2006 09:44:28.0575 (UTC) FILETIME=[9D5A62F0:01C69B60] X-Spam-Score: 0.2 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: sip@ietf.org, fluffy@cisco.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Christer,=20 >The problem with Proxy-Require (Proxy-Require: keepalive) is=20 >that it would require ALL proxies in the path to support STUN,=20 >and I don't think we want that. Not quite if it is done like Jeroen suggested: >>> and if there is an edge proxy, it would remove only the=20 >>> Proxy-Require header. I.e. just like Sec-Agree works. >I think we are talking about separate things. You talk about=20 >being able to make sure proxies support outbound, while I am=20 >talking about a way for a proxy to indicate that it supports=20 >STUN NAT keep-alive :) Right. Indicating support for outbound also covers support for STUN but if you have to indicate ONLY the STUN support you would need something else than Proxy-Require: outbound. Regards, Erkki >-----Original Message----- >From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com]=20 >Sent: 29. kes=E4kuuta 2006 10:36 >To: Christer Holmberg (JO/LMF); rohan@ekabal.com >Cc: sip@ietf.org; fluffy@cisco.com; dean.willis@softarmor.com >Subject: [Sip] Outbound-04 and proxy indicating support for=20 >STUN keepalives > > >Hi, > >>>No, you are missing the semantics of keepalive=3Dstun. It is a token = >>>which is used by the UAC/STUN client to know that it can mux=20 >STUN and=20 >>>SIP traffic. The STUN server/UAS or proxy does nothing with this=20 >>>parameter. The server knows that the the client support STUN if it=20 >>>sends a STUN request. > >>Also, as I asked in another mail: would it be possible for the STUN=20 >>server, by inserting the keepalive parameter in the Path URI, to=20 >>indicate that IT supports STUN? >> >>I see no harm in allowing the server to indicate whether it supports=20 >>STUN or not, BEFORE the client starts sending STUN requests=20 >and figures=20 >>it out itself... [/CHH] > >The following email in my opinion describes very well the=20 >reasons why outbound would need a way within SIP signalling to=20 >indicate if the contacted proxy actually supports STUN=20 >keepalives or not: >http://www1.ietf.org/mail-archive/web/sip/current/msg13802.html > >Another reason for the indication is that the UA might derive=20 >the outbound-proxy-set from a URI got from DHCP or AOR of the=20 >user. In those cases is is not possible to get any=20 >keepalive=3Dstun token along with the URI. > >It seems that outbound-04 does not provide a solution for this=20 >issue and would call for a related update.=20 > >The thread from end of March with name RE: [Sip] How to=20 >indicate during proxy discovery that a proxysupports"outbound"=20 >contains an extensive discussion of the subject. In the end=20 >Jeroen van Bemmel outlined the possible solution like this: > >>> "Proxy-Require: outbound" would mean that the proxy must=20 >support STUN > >>> (i.e. expect it and send replies), Path and the=20 >generation/mapping of > >>> flow identifiers. >>> "Require: outbound" would mean that the registrar must support STUN >and=20 >>> the mapping of flow identifiers >>> >>> I personally don't see any ambiguity here. So in my mind the UAC >would=20 >>> send >>> >>> REGISTER >>> Require: outbound >>> Proxy-Require: outbound >>> Supported: path >>> .... >>> >>> and if there is an edge proxy, it would remove only the=20 >Proxy-Require > >>> header. The registrar would even be able to detect whether=20 >it should=20 >>> expect STUN requests (if there is still a Proxy-Require, it would be >a=20 >>> direct connection). However, I don't see why it would need to know >this. > >Regards, > >Erkki > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 29 06:31:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvtm1-00052h-8B; Thu, 29 Jun 2006 06:29:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvtlz-0004zN-1Y for sip@ietf.org; Thu, 29 Jun 2006 06:29:23 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvtlu-0003e9-Dn for sip@ietf.org; Thu, 29 Jun 2006 06:29:23 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CF1A4F69; Thu, 29 Jun 2006 12:29:17 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 12:29:17 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 12:29:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound-04 and proxy indicating support for STUN keepalives Date: Thu, 29 Jun 2006 12:29:16 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F1213@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound-04 and proxy indicating support for STUN keepalives Thread-Index: AcabOW7bdcb6KW99SwSrZyKCCI1pFwAAno6wAAOVZWAAAkAYwAADI6nQAAGDJbA= From: "Christer Holmberg \(JO/LMF\)" To: , X-OriginalArrivalTime: 29 Jun 2006 10:29:17.0467 (UTC) FILETIME=[E00EBEB0:01C69B66] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: sip@ietf.org, fluffy@cisco.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Erikki,=20 >>The problem with Proxy-Require (Proxy-Require: keepalive) is that it=20 >>would require ALL proxies in the path to support STUN, and I don't=20 >>think we want that. >Not quite if it is done like Jeroen suggested: >>> and if there is an edge proxy, it would remove only the=20 >>> Proxy-Require header. >I.e. just like Sec-Agree works. [CHH] Ok, if you require the proxy closest to client to understand = outbound I guess it would work, because it could then remove the = option-tag from the Proxy-Require header. I guess it would also work for = STUN keep-alive, IF the client requires the proxy closest to it to = support STUN keep-alive. However, if the client simply wants to know whether the proxy supports = STUN or not, and continue no matter what, I guess we would need another = solution. We can not use the Supported header, because it could be = inserted by any proxy in the path, and if the proxy closest to the = client does not support STUN it won't remove the option-tag from the = Supported header. >>I think we are talking about separate things. You talk about being = able=20 >>to make sure proxies support outbound, while I am talking about a way=20 >>for a proxy to indicate that it supports STUN NAT keep-alive :) > >Right. Indicating support for outbound also covers support for STUN but = if you have to indicate ONLY the STUN support you=20 >would need something else than Proxy-Require: outbound. [CHH] As I said, we COULD use Proxy-Require: stun-keepalive... or = something like that. But, I also proposed that one way for a proxy to indicate that it = supports STUN keepalive would be that the proxy itself inserts the URI = parameter in the Path URI - assuming it supports Path, of course. Regards, Christer >-----Original Message----- >From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com] >Sent: 29. kes=E4kuuta 2006 10:36 >To: Christer Holmberg (JO/LMF); rohan@ekabal.com >Cc: sip@ietf.org; fluffy@cisco.com; dean.willis@softarmor.com >Subject: [Sip] Outbound-04 and proxy indicating support for STUN=20 >keepalives > > >Hi, > >>>No, you are missing the semantics of keepalive=3Dstun. It is a token = >>>which is used by the UAC/STUN client to know that it can mux >STUN and >>>SIP traffic. The STUN server/UAS or proxy does nothing with this=20 >>>parameter. The server knows that the the client support STUN if it=20 >>>sends a STUN request. > >>Also, as I asked in another mail: would it be possible for the STUN=20 >>server, by inserting the keepalive parameter in the Path URI, to=20 >>indicate that IT supports STUN? >> >>I see no harm in allowing the server to indicate whether it supports=20 >>STUN or not, BEFORE the client starts sending STUN requests >and figures >>it out itself... [/CHH] > >The following email in my opinion describes very well the reasons why=20 >outbound would need a way within SIP signalling to indicate if the=20 >contacted proxy actually supports STUN keepalives or not: >http://www1.ietf.org/mail-archive/web/sip/current/msg13802.html > >Another reason for the indication is that the UA might derive the=20 >outbound-proxy-set from a URI got from DHCP or AOR of the user. In=20 >those cases is is not possible to get any keepalive=3Dstun token along=20 >with the URI. > >It seems that outbound-04 does not provide a solution for this issue=20 >and would call for a related update. > >The thread from end of March with name RE: [Sip] How to indicate during = >proxy discovery that a proxysupports"outbound" >contains an extensive discussion of the subject. In the end Jeroen van=20 >Bemmel outlined the possible solution like this: > >>> "Proxy-Require: outbound" would mean that the proxy must >support STUN > >>> (i.e. expect it and send replies), Path and the >generation/mapping of > >>> flow identifiers. >>> "Require: outbound" would mean that the registrar must support STUN >and >>> the mapping of flow identifiers >>> >>> I personally don't see any ambiguity here. So in my mind the UAC >would >>> send >>> >>> REGISTER >>> Require: outbound >>> Proxy-Require: outbound >>> Supported: path >>> .... >>> >>> and if there is an edge proxy, it would remove only the >Proxy-Require > >>> header. The registrar would even be able to detect whether >it should >>> expect STUN requests (if there is still a Proxy-Require, it would be >a >>> direct connection). However, I don't see why it would need to know >this. > >Regards, > >Erkki > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 29 09:58:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvx11-00016m-Q1; Thu, 29 Jun 2006 09:57:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvx0z-00010V-GB for sip@ietf.org; Thu, 29 Jun 2006 09:57:05 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvx0y-0000k0-1n for sip@ietf.org; Thu, 29 Jun 2006 09:57:05 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 29 Jun 2006 09:57:04 -0400 X-IronPort-AV: i="4.06,192,1149480000"; d="scan'208"; a="91287708:sNHT32736892" Received: from [172.17.99.213] (rcdn-vpn-cluster-2-132.cisco.com [10.89.20.132]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5TDv1YM001959; Thu, 29 Jun 2006 09:57:03 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: <68618EA4-7CA4-4E3E-A306-1BA3902C3476@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Jonathan Rosenberg , IETF SIP List From: Cullen Jennings Date: Thu, 29 Jun 2006 06:56:59 -0700 X-Mailer: Apple Mail (2.750) X-Spam-Score: 1.1 (+) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: Subject: [Sip] Comments on rosenberg-sip-identity-coexistence X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I really glad to see this draft on how to migrate from where we are today to using Identity. I have some small complaints about parts and some suggestions on the B2BUA part but overall really like it. The most important part of this email is the B2BUA section near the end. Section 1: I think one of the major reason for creating PAI was to provide malicious call trace for anonymous calls. I don't think it was for dealing with spoofing the From header. If that was the goal, we could have solved it just by having device that ends up inserting the PAI just reject any request that has spoofed From headers. Small nit but ... I think identity was designed such that the UAS domain proxy could do everything on behalf of the UAS as a migration step. Clearly that is the point of the draft but the "called party must be upgraded to support it" part I don't quite agree with. My last small nit .... I've sent several posts about why I think B2BUA work with Identity in a large percentage of the cases. I think this draft seems like a great place to explain all this - both what works and what does not. I don't buy into the statement that Identity breaks B2BUAs. Section 2. One of the design choices we need to make in the originating domain is if the ingress or egress proxy inserts the Identity signature. My preference is to explain the pro's and cons of this and allow either. I see the pros/cons of the egress doing it be that since not all calls will require the PKI computation to insert the signature and the cons that now the egress proxy has to authenticate the UA which in may deployments will involved a re-challenge to UA which like inserts another round trip of signaling both to the UA and to the AAA server. I see the pros/cons of the ingress doing it that a) all calls have it even inside the domain b) we provide integrity protection for calls in the domain c) devices receiving the call inside the domain can treat the Identity header the same was as call outside the domain. I'm sure others millage may vary but my mucking around makes me think the ingress proxy doing it will turn out to be best for most deployments. It certainly has better security properties and depending on your mix of inter/intra domain calls, the trade off of the PKI on ingress is offset by extra messaging on egress. I'm big fan of Terminating domain checking Identity signature and if it is OK, then inserting PAI for that. I like this. I think this is right. I think this is critical for migration to Identity. If I can be any more positive about this idea let me know how :-) I don't see why we would need the id-coexists options tags. It seems like they never get used. Section 3.3 I don't think that having the PAI override a broken identity will really fly from a security point of view. This takes this back to something that is only deployable in fully trusted networks. What I mean by this is that if anyone can insert a PAI header, they can totally break the integrity mechanism that identity provides. I realize that you are trying to solve the B2BUA issue here - more on that later - I agree we need to work with B2BUA but I think we can. I like to consider having rules in this order 1) if there is an invalid identity header, reject call 2) if there is a valid identity header, use AOR in From 3) if three is no identity, look for PAI and use that AOR if exists 4) if no PAI, use AOR in From Take the AOR and lookup in local address book and if found, display the user name associated with that entry in address book otherwise display the AOR and if Display Name is used clearly mark it as not being secure 2nd para - I might be confused on what you are suggesting here - In this section you talk about the UAS knowing if the UAC supports Identity or not. I don't know how to do this in a secure way - I think it is pretty hard - the approach of using DNS to look it up might work but has lots of issues too. 4.1 - I think whichever proxy first authenticates the UAS should insert the Identity signature 4.3 - I might be missing some of the stuff you are thinking about with the anonymous URI. However, it seems like for anonymous calls between domains that have an acceptable RFC 3325 Spec T, they will still want to pass the PAI for malicious call trace reasons. Section 5 Ok, I think that having PAI override PAI would break Identity in a way that we would never have strong identity in SIP - so I think we need a better way to work with B2BUA. I think the camarillo-sipping- sbc-funcs draft on the where B2BUA gets used and why might be helpful for working through the cases. Let me look at some starting cases here First let me separate telephone numbers from email style AOR. In all cases telephone numbers are easy as what you generally want is the B2BUA to decide it trusts the number it received, based on Identity or other information, then resign with it's credentials. This is because the E.164 namespace is not delegated to any of the devices doing the signatures. If DNSsec was available, and ENUM was widely deployed, more interesting solutions might be available. Probably worth thinking about. So for the case with email style AORs case 1) an egress B2BUA on originating domain - this one is actually trivial to deal with. This B2BUA can have the credentials to correctly re-sign the message case 2) ingress B2B on terminating domain - this is fairly easy too. This B2BUA resigns the incoming request. To do this it uses a cert that has a wildcard for all domain - the UAS need to be configured to have this cert in it root trust list. What the UAS is doing here is delegating that it trust any name that the B2BUA trusts. This is the sort of trust delegation one wants to be able to make. case 3) a B2BUA in a transit provider between the originating and terminating domain. There are two very different cases here - one is where the transit provider is an intermediate in providing PSTN termination services and using E.164 addresses. For example some company, contracts its PSTN termination from say MCI who for numbers in Australia perhaps uses Telstra. The company wants to see the phone number asserted by MCI, not Telstra - it is MCI they trust and can make an authorization decision based on. They have no idea who Telstra is so whatever telstra wants to claim is useless for the company. The point is, whatever things Telstra might assert to MCI, the company wants MCI to make an assertion that the company can use for it authorization decision. In these cases the transit B2BUA needs to resign things. The next sub case is where the transit provider provides an anonymization service - here you clearly need to resign things. The second sub case is not a PSTN termination service but a "trust broker" between a bunch of companies. An example of this case, a bunch of companies join some consortium and the consortium make sure that they can all talk to each other and no bad people are allowed to talk them because only good people are in the consortium. (I'm always a little confused on the value of all this but many people have suggested it might be useful - there is some groups like this something to do with drug dealers of america or something that people always bring up as an example). Here the consortium has two choices, it can provide new names for all the users and remap them or it can be allowed to sign on behalf of the organizations that are in it. For example, alice@example.com might become alice.example.consortium.com or aliace%example@consortium.com or even just alice@consortium.com. Or alternatively, the UA that trust consortium.com might allow the consortium to have a root cert such that it could sign things alice@example.com. There are many options here and I find it hard to pick one as I don't really understand why this type of service would exist in the first place. However, as we work out the requirements for this type of service, I suspect a soltuion is possible. As a last note, I do think there are workable solutions for the B2BUA case. Having UA accept message with a bad Identity header but that have a PAI seriously breaks Identify. One of the key things that Identity provides is a close to end to end integrity for the bodies. This breaks this and we have no other good way to provide this. What I am suggesting above provides a way to keep this integrity property so that no device can tamper with the integrity other than devices that the UAS or UAC explicitly trusts to tamper with the integrity. I think this is a fairly important property and achievable. Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 29 09:58:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvx11-00016D-3z; Thu, 29 Jun 2006 09:57:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvx0z-000103-4R for sip@ietf.org; Thu, 29 Jun 2006 09:57:05 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvx0x-0000jz-H0 for sip@ietf.org; Thu, 29 Jun 2006 09:57:05 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 29 Jun 2006 06:57:03 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,192,1149490800"; d="scan'208"; a="30751838:sNHT24372616" Received: from [172.17.99.213] (rcdn-vpn-cluster-2-132.cisco.com [10.89.20.132]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5TDv1YL001959; Thu, 29 Jun 2006 09:57:01 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: <89DADC41-B196-4C12-B738-6B044E0E05C4@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Jonathan Rosenberg , IETF SIP List From: Cullen Jennings Date: Thu, 29 Jun 2006 06:56:58 -0700 X-Mailer: Apple Mail (2.750) X-Spam-Score: 1.1 (+) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: Subject: [Sip] Comments on rosenberg-sip-identity-coexistence X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I really glad to see this draft on how to migrate from where we are today to using Identity. I have some small complaints about parts and some suggestions on the B2BUA part but overall really like it. The most important part of this email is the B2BUA section near the end. Section 1: I think one of the major reason for creating PAI was to provide malicious call trace for anonymous calls. I don't think it was for dealing with spoofing the From header. If that was the goal, we could have solved it just by having device that ends up inserting the PAI just reject any request that has spoofed From headers. Small nit but ... I think identity was designed such that the UAS domain proxy could do everything on behalf of the UAS as a migration step. Clearly that is the point of the draft but the "called party must be upgraded to support it" part I don't quite agree with. My last small nit .... I've sent several posts about why I think B2BUA work with Identity in a large percentage of the cases. I think this draft seems like a great place to explain all this - both what works and what does not. I don't buy into the statement that Identity breaks B2BUAs. Section 2. One of the design choices we need to make in the originating domain is if the ingress or egress proxy inserts the Identity signature. My preference is to explain the pro's and cons of this and allow either. I see the pros/cons of the egress doing it be that since not all calls will require the PKI computation to insert the signature and the cons that now the egress proxy has to authenticate the UA which in may deployments will involved a re-challenge to UA which like inserts another round trip of signaling both to the UA and to the AAA server. I see the pros/cons of the ingress doing it that a) all calls have it even inside the domain b) we provide integrity protection for calls in the domain c) devices receiving the call inside the domain can treat the Identity header the same was as call outside the domain. I'm sure others millage may vary but my mucking around makes me think the ingress proxy doing it will turn out to be best for most deployments. It certainly has better security properties and depending on your mix of inter/intra domain calls, the trade off of the PKI on ingress is offset by extra messaging on egress. I'm big fan of Terminating domain checking Identity signature and if it is OK, then inserting PAI for that. I like this. I think this is right. I think this is critical for migration to Identity. If I can be any more positive about this idea let me know how :-) I don't see why we would need the id-coexists options tags. It seems like they never get used. Section 3.3 I don't think that having the PAI override a broken identity will really fly from a security point of view. This takes this back to something that is only deployable in fully trusted networks. What I mean by this is that if anyone can insert a PAI header, they can totally break the integrity mechanism that identity provides. I realize that you are trying to solve the B2BUA issue here - more on that later - I agree we need to work with B2BUA but I think we can. I like to consider having rules in this oFrom sip-bounces@ietf.org Thu Jun 29 09:58:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvx11-00016m-Q1; Thu, 29 Jun 2006 09:57:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvx0z-00010V-GB for sip@ietf.org; Thu, 29 Jun 2006 09:57:05 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvx0y-0000k0-1n for sip@ietf.org; Thu, 29 Jun 2006 09:57:05 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 29 Jun 2006 09:57:04 -0400 X-IronPort-AV: i="4.06,192,1149480000"; d="scan'208"; a="91287708:sNHT32736892" Received: from [172.17.99.213] (rcdn-vpn-cluster-2-132.cisco.com [10.89.20.132]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5TDv1YM001959; Thu, 29 Jun 2006 09:57:03 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: <68618EA4-7CA4-4E3E-A306-1BA3902C3476@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Jonathan Rosenberg , IETF SIP List From: Cullen Jennings Date: Thu, 29 Jun 2006 06:56:59 -0700 X-Mailer: Apple Mail (2.750) X-Spam-Score: 1.1 (+) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: Subject: [Sip] Comments on rosenberg-sip-identity-coexistence X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I really glad to see this draft on how to migrate from where we are today to using Identity. I have some small complaints about parts and some suggestions on the B2BUA part but overall really like it. The most important part of this email is the B2BUA section near the end. Section 1: I think one of the major reason for creating PAI was to provide malicious call trace for anonymous calls. I don't think it was for dealing with spoofing the From header. If that was the goal, we could have solved it just by having device that ends up inserting the PAI just reject any request that has spoofed From headers. Small nit but ... I think identity was designed such that the UAS domain proxy could do everything on behalf of the UAS as a migration step. Clearly that is the point of the draft but the "called party must be upgraded to support it" part I don't quite agree with. My last small nit .... I've sent several posts about why I think B2BUA work with Identity in a large percentage of the cases. I think this draft seems like a great place to explain all this - both what works and what does not. I don't buy into the statement that Identity breaks B2BUAs. Section 2. One of the design choices we need to make in the originating domain is if the ingress or egress proxy inserts the Identity signature. My preference is to explain the pro's and cons of this and allow either. I see the pros/cons of the egress doing it be that since not all calls will require the PKI computation to insert the signature and the cons that now the egress proxy has to authenticate the UA which in may deployments will involved a re-challenge to UA which like inserts another round trip of signaling both to the UA and to the AAA server. I see the pros/cons of the ingress doing it that a) all calls have it even inside the domain b) we provide integrity protection for calls in the domain c) devices receiving the call inside the domain can treat the Identity header the same was as call outside the domain. I'm sure others millage may vary but my mucking around makes me think the ingress proxy doing irder 1) if there is an invalid identity header, reject call 2) if there is a valid identity header, use AOR in From 3) if three is no identity, look for PAI and use that AOR if exists 4) if no PAI, use AOR in From Take the AOR and lookup in local address book and if found, display the user name associated with that entry in address book otherwise display the AOR and if Display Name is used clearly mark it as not being secure 2nd para - I might be confused on what you are suggesting here - In this section you talk about the UAS knowing if the UAC supports Identity or not. I don't know how to do this in a secure way - I think it is pretty hard - the approach of using DNS to look it up might work but has lots of issues too. 4.1 - I think whichever proxy first authenticates the UAS should insert the Identity signature 4.3 - I might be missing some of the stuff you are thinking about with the anonymous URI. However, it seems like for anonymous calls between domains that have an acceptable RFC 3325 Spec T, they will still want to pass the PAI for malicious call trace reasons. Section 5 Ok, I think that having PAI override PAI would break Identity in a way that we would never have strong identity in SIP - so I think we need a better way to work with B2BUA. I think the camarillo-sipping- sbc-funcs draft on the where B2BUA gets used and why might be helpful for working through the cases. Let me look at some starting cases here First let me separate telephone numbers from email style AOR. In all cases telephone numbers are easy as what you generally want is the B2BUA to decide it trusts the number it received, based on Identity or other information, then resign with it's credentials. This is because the E.164 namespace is not delegated to any of the devices doing the signatures. If DNSsec was available, and ENUM was widely deployed, more interesting solutions might be available. Probably worth thinking about. So for the case with email style AORs case 1) an egress B2BUA on originating domain - this one is actually trivial to deal with. This B2BUA can have the credentials to correctly re-sign the message case 2) ingress B2B on terminating domain - this is fairly easy too. This B2BUA resigns the incoming request. To do this it uses a cert that has a wildcard for all domain - the UAS need to be configured to have this cert in it root trust list. What the UAS is doing here is delegating that it trust any name that the B2BUA trusts. This is the sort of trust delegation one wants to be able to make. case 3) a B2BUA in a transit provider between the originating and terminating domain. There are two very different cases here - one is where the transit provider is an intermediate in providing PSTN termination services and using E.164 addresses. For example some company, contracts its PSTN termination from say MCI who for numbers in Australia perhaps uses Telstra. The company wants to see the phone number asserted by MCI, not Telstra - it is MCI they trust and can make an authorization decision based on. They have no idea who Telstra is so whatever telstra wants to claim is useless for the company. The point is, whatever things Telstra might assert to MCI, the company wants MCI to make an assertion that the company can use for it authorization decision. In these cases the transit B2BUA needs to resign things. The next sub case is where the transit provider provides an anonymization service - here you clearly need to resign things. The second sub case is not a PSTN termination service but a "trust broker" between a bunch of companies. An example of this case, a bunch of companies join some consortium and the consortium make sure that they can all talk to each other and no bad people are allowed to talk them because only good people are in the consortium. (I'm always a little confused on the value of all this but many people have suggested it might be useful - there is some groups like this something to do with drug dealers of amert will turn out to be best for most deployments. It certainly has better security properties and depending on your mix of inter/intra domain calls, the trade off of the PKI on ingress is offset by extra messaging on egress. I'm big fan of Terminating domain checking Identity signature and if it is OK, then inserting PAI for that. I like this. I think this is right. I think this is critical for migration to Identity. If I can be any more positive about this idea let me know how :-) I don't see why we would need the id-coexists options tags. It seems like they never get used. Section 3.3 I don't think that having the PAI override a broken identity will really fly from a security point of view. This takes this back to something that is only deployable in fully trusted networks. What I mean by this is that if anyone can insert a PAI header, they can totally break the integrity mechanism that identity provides. I realize that you are trying to solve the B2BUA issue here - more on that later - I agree we need to work with B2BUA but I think we can. I like to consider having rules in this order 1) if there is an invalid identity header, reject call 2) if there is a valid identity header, use AOR in From 3) if three is no identity, look for PAI and use that AOR if exists 4) if no PAI, use AOR in From Take the AOR and lookup in local address book and if found, display the user name associated with that entry in address book otherwise display the AOR and if Display Name is used clearly mark it as not being secure 2nd para - I might be confused on what you are suggesting here - In this section you talk about the UAS knowing if the UAC supports Identity or not. I don't know how to do this in a secure way - I think it is pretty hard - the approach of using DNS to look it up might work but has lots of issues too. 4.1 - I think whichever proxy first authenticates the UAS should insert the Identity signature 4.3 - I might be missing some of the stuff you are thinking about with the anonymous URI. However, it seems like for anonymous calls between domains that have an acceptable RFC 3325 Spec T, they will still want to pass the PAI for malicious call trace reasons. Section 5 Ok, I think that having PAI override PAI would break Identity in a way that we would never have strong identity in SIP - so I think we need a better way to work with B2BUA. I think the camarillo-sipping- sbc-funcs draft on the where B2BUA gets used and why might be helpful for working through the cases. Let me look at some starting cases here First let me separate telephone numbers from email style AOR. In all cases telephone numbers are easy as what you generally want is the B2BUA to decide it trusts the number it received, based on Identity or other information, then resign with it's credentials. This is because the E.164 namespace is not delegated to any of the devices doing the signatures. If DNSsec was available, and ENUM was widely deployed, more interesting solutions might be available. Probably worth thinking about. So for the case with email style AORs case 1) an egress B2BUA on originating domain - this one is actually trivial to deal with. This B2BUA can have the credentials to correctly re-sign the message case 2) ingress B2B on terminating domain - this is fairly easy too. This B2BUA resigns the incoming request. To do this it uses a cert that has a wildcard for all domain - the UAS need to be configured to have this cert in it root trust list. What the UAS is doing here is delegating that it trust any name that the B2BUA trusts. This is the sort of trust delegation one wants to be able to make. case 3) a B2BUA in a transit provider between the originating and terminating domain. There are two very different cases here - one is where the transit provider is an intermediate in providing PSTN termination services and using E.164 addresses. For example some company, contracts its PSTN termination from say MCI who for numbers in Australia perhapica or something that people always bring up as an example). Here the consortium has two choices, it can provide new names for all the users and remap them or it can be allowed to sign on behalf of the organizations that are in it. For example, alice@example.com might become alice.example.consortium.com or aliace%example@consortium.com or even just alice@consortium.com. Or alternatively, the UA that trust consortium.com might allow the consortium to have a root cert such that it could sign things alice@example.com. There are many options here and I find it hard to pick one as I don't really understand why this type of service would exist in the first place. However, as we work out the requirements for this type of service, I suspect a soltuion is possible. As a last note, I do think there are workable solutions for the B2BUA case. Having UA accept message with a bad Identity header but that have a PAI seriously breaks Identify. One of the key things that Identity provides is a close to end to end integrity for the bodies. This breaks this and we have no other good way to provide this. What I am suggesting above provides a way to keep this integrity property so that no device can tamper with the integrity other than devices that the UAS or UAC explicitly trusts to tamper with the integrity. I think this is a fairly important property and achievable. Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip s uses Telstra. The company wants to see the phone number asserted by MCI, not Telstra - it is MCI they trust and can make an authorization decision based on. They have no idea who Telstra is so whatever telstra wants to claim is useless for the company. The point is, whatever things Telstra might assert to MCI, the company wants MCI to make an assertion that the company can use for it authorization decision. In these cases the transit B2BUA needs to resign things. The next sub case is where the transit provider provides an anonymization service - here you clearly need to resign things. The second sub case is not a PSTN termination service but a "trust broker" between a bunch of companies. An example of this case, a bunch of companies join some consortium and the consortium make sure that they can all talk to each other and no bad people are allowed to talk them because only good people are in the consortium. (I'm always a little confused on the value of all this but many people have suggested it might be useful - there is some groups like this something to do with drug dealers of america or something that people always bring up as an example). Here the consortium has two choices, it can provide new names for all the users and remap them or it can be allowed to sign on behalf of the organizations that are in it. For example, alice@example.com might become alice.example.consortium.com or aliace%example@consortium.com or even just alice@consortium.com. Or alternatively, the UA that trust consortium.com might allow the consortium to have a root cert such that it could sign things alice@example.com. There are many options here and I find it hard to pick one as I don't really understand why this type of service would exist in the first place. However, as we work out the requirements for this type of service, I suspect a soltuion is possible. As a last note, I do think there are workable solutions for the B2BUA case. Having UA accept message with a bad Identity header but that have a PAI seriously breaks Identify. One of the key things that Identity provides is a close to end to end integrity for the bodies. This breaks this and we have no other good way to provide this. What I am suggesting above provides a way to keep this integrity property so that no device can tamper with the integrity other than devices that the UAS or UAC explicitly trusts to tamper with the integrity. I think this is a fairly important property and achievable. Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 29 09:58:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvx11-00016D-3z; Thu, 29 Jun 2006 09:57:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvx0z-000103-4R for sip@ietf.org; Thu, 29 Jun 2006 09:57:05 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvx0x-0000jz-H0 for sip@ietf.org; Thu, 29 Jun 2006 09:57:05 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 29 Jun 2006 06:57:03 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,192,1149490800"; d="scan'208"; a="30751838:sNHT24372616" Received: from [172.17.99.213] (rcdn-vpn-cluster-2-132.cisco.com [10.89.20.132]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5TDv1YL001959; Thu, 29 Jun 2006 09:57:01 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: <89DADC41-B196-4C12-B738-6B044E0E05C4@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Jonathan Rosenberg , IETF SIP List From: Cullen Jennings Date: Thu, 29 Jun 2006 06:56:58 -0700 X-Mailer: Apple Mail (2.750) X-Spam-Score: 1.1 (+) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: Subject: [Sip] Comments on rosenberg-sip-identity-coexistence X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I really glad to see this draft on how to migrate from where we are today to using Identity. I have some small complaints about parts and some suggestions on the B2BUA part but overall really like it. The most important part of this email is the B2BUA section near the end. Section 1: I think one of the major reason for creating PAI was to provide malicious call trace for anonymous calls. I don't think it was for dealing with spoofing the From header. If that was the goal, we could have solved it just by having device that ends up inserting the PAI just reject any request that has spoofed From headers. Small nit but ... I think identity was designed such that the UAS domain proxy could do everything on behalf of the UAS as a migration step. Clearly that is the point of the draft but the "called party must be upgraded to support it" part I don't quite agree with. My last small nit .... I've sent several posts about why I think B2BUA work with Identity in a large percentage of the cases. I think this draft seems like a great place to explain all this - both what works and what does not. I don't buy into the statement that Identity breaks B2BUAs. Section 2. One of the design choices we need to make in the originating domain is if the ingress or egress proxy inserts the Identity signature. My preference is to explain the pro's and cons of this and allow either. I see the pros/cons of the egress doing it be that since not all calls will require the PKI computation to insert the signature and the cons that now the egress proxy has to authenticate the UA which in may deployments will involved a re-challenge to UA which like inserts another round trip of signaling both to the UA and to the AAA server. I see the pros/cons of the ingress doing it that a) all calls have it even inside the domain b) we provide integrity protection for calls in the domain c) devices receiving the call inside the domain can treat the Identity header the same was as call outside the domain. I'm sure others millage may vary but my mucking around makes me think the ingress proxy doing it will turn out to be best for most deployments. It certainly has better security properties and depending on your mix of inter/intra domain calls, the trade off of the PKI on ingress is offset by extra messaging on egress. I'm big fan of Terminating domain checking Identity signature and if it is OK, then inserting PAI for that. I like this. I think this is right. I think this is critical for migration to Identity. If I can be any more positive about this idea let me know how :-) I don't see why we would need the id-coexists options tags. It seems like they never get used. Section 3.3 I don't think that having the PAI override a broken identity will really fly from a security point of view. This takes this back to something that is only deployable in fully trusted networks. What I mean by this is that if anyone can insert a PAI header, they can totally break the integrity mechanism that identity provides. I realize that you are trying to solve the B2BUA issue here - more on that later - I agree we need to work with B2BUA but I think we can. I like to consider having rules in this order 1) if there is an invalid identity header, reject call 2) if there is a valid identity header, use AOR in From 3) if three is no identity, look for PAI and use that AOR if exists 4) if no PAI, use AOR in From Take the AOR and lookup in local address book and if found, display the user name associated with that entry in address book otherwise display the AOR and if Display Name is used clearly mark it as not being secure 2nd para - I might be confused on what you are suggesting here - In this section you talk about the UAS knowing if the UAC supports Identity or not. I don't know how to do this in a secure way - I think it is pretty hard - the approach of using DNS to look it up might work but has lots of issues too. 4.1 - I think whichever proxy first authenticates the UAS should insert the Identity signature 4.3 - I might be missing some of the stuff you are thinking about with the anonymous URI. However, it seems like for anonymous calls between domains that have an acceptable RFC 3325 Spec T, they will still want to pass the PAI for malicious call trace reasons. Section 5 Ok, I think that having PAI override PAI would break Identity in a way that we would never have strong identity in SIP - so I think we need a better way to work with B2BUA. I think the camarillo-sipping- sbc-funcs draft on the where B2BUA gets used and why might be helpful for working through the cases. Let me look at some starting cases here First let me separate telephone numbers from email style AOR. In all cases telephone numbers are easy as what you generally want is the B2BUA to decide it trusts the number it received, based on Identity or other information, then resign with it's credentials. This is because the E.164 namespace is not delegated to any of the devices doing the signatures. If DNSsec was available, and ENUM was widely deployed, more interesting solutions might be available. Probably worth thinking about. So for the case with email style AORs case 1) an egress B2BUA on originating domain - this one is actually trivial to deal with. This B2BUA can have the credentials to correctly re-sign the message case 2) ingress B2B on terminating domain - this is fairly easy too. This B2BUA resigns the incoming request. To do this it uses a cert that has a wildcard for all domain - the UAS need to be configured to have this cert in it root trust list. What the UAS is doing here is delegating that it trust any name that the B2BUA trusts. This is the sort of trust delegation one wants to be able to make. case 3) a B2BUA in a transit provider between the originating and terminating domain. There are two very different cases here - one is where the transit provider is an intermediate in providing PSTN termination services and using E.164 addresses. For example some company, contracts its PSTN termination from say MCI who for numbers in Australia perhaps uses Telstra. The company wants to see the phone number asserted by MCI, not Telstra - it is MCI they trust and can make an authorization decision based on. They have no idea who Telstra is so whatever telstra wants to claim is useless for the company. The point is, whatever things Telstra might assert to MCI, the company wants MCI to make an assertion that the company can use for it authorization decision. In these cases the transit B2BUA needs to resign things. The next sub case is where the transit provider provides an anonymization service - here you clearly need to resign things. The second sub case is not a PSTN termination service but a "trust broker" between a bunch of companies. An example of this case, a bunch of companies join some consortium and the consortium make sure that they can all talk to each other and no bad people are allowed to talk them because only good people are in the consortium. (I'm always a little confused on the value of all this but many people have suggested it might be useful - there is some groups like this something to do with drug dealers of america or something that people always bring up as an example). Here the consortium has two choices, it can provide new names for all the users and remap them or it can be allowed to sign on behalf of the organizations that are in it. For example, alice@example.com might become alice.example.consortium.com or aliace%example@consortium.com or even just alice@consortium.com. Or alternatively, the UA that trust consortium.com might allow the consortium to have a root cert such that it could sign things alice@example.com. There are many options here and I find it hard to pick one as I don't really understand why this type of service would exist in the first place. However, as we work out the requirements for this type of service, I suspect a soltuion is possible. As a last note, I do think there are workable solutions for the B2BUA case. Having UA accept message with a bad Identity header but that have a PAI seriously breaks Identify. One of the key things that Identity provides is a close to end to end integrity for the bodies. This breaks this and we have no other good way to provide this. What I am suggesting above provides a way to keep this integrity property so that no device can tamper with the integrity other than devices that the UAS or UAC explicitly trusts to tamper with the integrity. I think this is a fairly important property and achievable. Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 29 12:46:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvzcs-0003vE-Go; Thu, 29 Jun 2006 12:44:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvzcr-0003pp-CU for sip@ietf.org; Thu, 29 Jun 2006 12:44:21 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvzcq-0007vR-4y for sip@ietf.org; Thu, 29 Jun 2006 12:44:21 -0400 Received: from [131.161.248.86] (open-131-161-248-86.cliq.com [131.161.248.86]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k5TGiGF32472; Thu, 29 Jun 2006 09:44:17 -0700 In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F1204@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB594017F1204@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1af2fea9ff9985f9c6473947e7fe3817@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Ready for WGLC on Outbound? Date: Thu, 29 Jun 2006 09:44:14 -0700 To: "Christer Holmberg \(JO/LMF\)" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae Cc: IETF SIP List , Cullen Jennings , Dean Willis , 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: , Errors-To: sip-bounces@ietf.org Hi, On Jun 28, 2006, at 22:57, Christer Holmberg ((JO/LMF)) wrote: > > Hi Rohan, > > Thanks for your reply! Comments inline. > >> Unfortunately, I don't think all issues have been addressed yet. There > >> are a number of issues we've been discussing on e-mail, and on some I >> think we have even reached agreements. >> >> >> FIRST, the issue I raised in the "Outbound: keep-alive, outbound and >> 3489bis" thread has not been issued. STUN NAT keep-alive is nowadays a > >> "core" STUN usage - not something specific to the outbound mechanism. >> We need to separate them, because it should be possible to use STUN >> for keep-alive without using the rest of outbound (instance-id, flow >> etc etc). >> >> Chapter 4.2 says: >> >> "The UAC MAY examine successful registrations for the presence of an >> 'outbound' option-tag in a Supported header field value. Presence of >> this option-tag indicates that the registrar is compliant with this >> specification. >> >> Again, that is not true if I only support STUN for NAT keep-alive, but > >> not the rest of outbound. > >> No, if you indicate support for the option tag, you support all the > MUSTs in outbound. If you just want to support STUN >> muxed on the same port as SIP, you can indicate that you do that by > adding the >> keepalive=stun URI parameter. Outbound defines the semantics of >> this. > > [CHH] Perhaps, but I don't think it's clearly indicated that the STUN > NAT keep-alive can be used as a "stand alone" feature. I don't think > much text is needed for that. I also think that the scope of the > document clearly shall say that the document defines how to use the > STUN > keep-alive (and also, as I mention futher down, the connectivity check) > usage, as defined in 3489bis, for SIP. [/CHH] > > >> This is just like RFC 3265 which happens to define the 202 Accepted > response code. It doesn't mean I need to implement >> all of RFC 3265 to implement 202 (It even referenced this way in > MESSAGE). >> >> Now, one COULD of course claim that the generic SIP usage of STUN for >> NAT keep-alive shall be described in a SEPARATE document, and that the >> outbound spec ONLY describes the STUN keep-alive when used TOGETHER >> with outbound. BUT, if that is the case the "keepalive" URI parameter >> should not be defined in the outbound draft - it should be defined in >> that generic SIP STUN keep-alive usage draft (I ASSUME that we would >> use the "keepalive" parameter also when we use STUN keep-alive without >> outbound". Also, the text on STUN processing etc should also be >> described in the generic draft in that case, because it's not outbound >> specific. >> >> there is no milestone for a spec for STUN keepalives, and no > groundswell of support for a separate draft. We have >> consensus to go forward with STUN keepalives described in outbound > because outbound needs it. If you happen to want a >> little piece of outbound, you can still implement it. You just don't > have a separate shiny RFC number to tell people >> you've implemented. You can still reference the description of the > parameter in the IANA registry (which will have a >> description of the semantics once outbound is published). > > [CHH] I have no problem with keeping the STUN keep-alive stuff in the > outbound draft. Again, what I am asking for is to more clearly separate > it, as a stand alone feature, from the rest of the outbound stuff. Of > course we can say that the support of outbound requires the support of > STUN keep-alive. [/CHH] I don't see why you need a separate section in the draft when you can point at the IANA registry. Besides, defining a standalone description of STUN keepalives was never a requirement motivating this work. >> Also, since STUN keep-alive is now a core STUN usage, I wonder if we >> can remove the note in chapter 3.5. Because, again, this draft shall >> not define the keep-alive mechanism - it is already defined in >> 3489bis. >> >> outbound defines what a STUN client is supposed to do when the > keepalives fail, how fast to backoff, and what to do if >> the binding response XOR-MAPPED-ADDRESS is different from the address > the client had previously. There is a lot of >> behavior here that is not and should not be in 3489bis. > > [CHH] I totally agree with you. 3489bis defiens the STUN keep-alive > usage, and the outbound draft describes how to "adopt" it with SIP. > And, > that is what I think should be more clear in the spec. The outbound > draft does not define the usage of STUN for keep-alive as such, only > how > to use it for SIP. The outbound draft DOES refer to 3489bis, but it > does > not mention the USAGE defined ni 3489bis. > > Related to that, chapter 7.1 says: "This document defines a new STUN > usage for connectivity checks." Again, this usage is already defined in > 3489bis (chapter 12.3), so we only need to adopt it to SIP. [/CHH] OK, I will change this to something like: "This document uses the STUN connectivity check usage [ref] for connectivity checks over the SIP flow." >>> SECOND, the draft talks about the outbound proxy URIs configured in >>> the client. I think we agreed that configured URIs are ok as >>> "default", but I think we should say that the client may also >>> retreive > >>> the proxy address using other mechanisms (e.g. something similar to >>> the P-CSCF discovery mechanism in IMS). I don't think we need to talk >>> about "additional mechanisms" that may be defined in the future >>> (chapter 4.2): we simply say that other mechanisms are outside of the >>> scope of this document. >>> >>> From Section 4.2: >>> UAs obtain at configuration time one or more SIP URIs representing >>> the > >>> default outbound-proxy-set. This specification assumes the set is >>> determined via any of a number of configuration mechanisms and future >>> specifications may define additional mechanisms such as using DNS to >>> discover this set. How the UA is configured is outside the scope of >>> this specification. >> >> Everything you mentioned is covered by the previous two sentences. A > P-CSCF discovery mechanism is already allowed. > > [CHH] I still don't understand why normative text should talk about the > future... > > Also, the issue is that what may be configured (no matter how you > configure it) may not be a URI. It may simply be an IP address/FQDN, > which is then used to build a SIP-URI. I think we shall allow that, and > make it more clear in the spec. [/CHH] the outbound spec defines a piece of configurable data (the 'outbound-proxy-set'), which is a list of URIs. This list of URIs may never have a one-to-one correspondence to a user or administrator manually configurable field. That piece of configurable data may be derived from several fields, manually configurable, discovered via DHCP, DNS, the config package, P-Whatchamacallit headers, HTTP download, or via a random character generator seeded by the phase of the moon. The outbound-proxy-set was defined as a list of URIs because the UA acts on each item in the list, because each URI is expected to be places in a Route header, and because each URI is expected to typically have a keepalive URI parameter in it. What you want is already allowed, but the most straightforward, logical thing for a UA designer to do is to make the outbound-proxy-set manually and automatically configurable. It would be a disservice to the community to clog up the draft with text describing things you are already allowed to do, unless we have strong motivations, use-cases, and requirements. We have none of these, but if you feel strongly enough to write an informative draft that reminds implementors of all the things they are allowed to do in this context and provides motivations and requirements, go for it. But that would be a future draft. >>> THIRD, I think we agreed that there may be other ways of providing a >>> reliable system >>> >>> Chapter 3.3 says: >>> >>> "There are various ways to deploy SIP to build a reliable and >>> scalable > >>> system. This section discusses one such design that is possible with >>> the mechanisms in this specification. Other designs are also >>> possible." >> >>> To make it more clear I think it should say: >> >>> "Other designs, where multiple registrations/flows are not required, >>> are also possible." >> >> The existing text is *an* example and fully acknowledges you can build > other reliable systems. >> I also think the existing text is much clearer that your proposed >> text. > > [CHH] So, what text do you think clearly says that there may be > scenarios where only a single flow can be used? Just saying that one > chapter describes *an* example doesn't make that clear. > > Also, "Other designs" sounds to me like using mechanisms that are not > defined "in this specification", which is not correct. Even if you only > register a single flow you would use the mechanism "in this > specification". [/CHH] Christer, the IETF model of specifications is that you can do anything you like as long as you implement the normative parts of the specification. If you want to implement a reliable system that just use one flow, just go and implement it. If you want to describe a reliable system that uses one flow, write a draft to describe it. Micro-editing non-normative language to more explicitly allow for reliability (or other) schemes that have not been discussed and have no requirements is contrary to the charter of this WG. >>> FOURTH, related to the second and third issue, chapter 4.2 says: >>> >>> "For each outbound proxy URI in the set, the UA MUST send a REGISTER >>> in the normal way using this URI as the default outbound proxy." >>> >>> Again, there may be other ways to provide reliability. >>> >>> And, shall it really be mandatory to register to ALL URIs? In issue >>> seven I talk about the "max-flow" indicator we've been discussing on >>> the list. >> >> If you don't want to register ALL the URIs you can think of, only > configure (by the definition above) the UAC with the >> URIs you want registered. > > [CHH] Again, you may not always configure the edge proxies "manually". > You may use a separate discovery mechanism. And, that discovery > mechanism may, for different reasons, provide a list of edge proxies, > but that doesn't mean that you always want to register to all of them > at > the same time. [/CHH] Christer, you seem to be missing the definition of configure. As a lay definition, lets use the following: Configure means to cause a piece of non-per-call, non-per-dialog state to be set. Manual configuration is only one mechanism of configuration. This is consistent with the SIP configuration framework (draft-ietf-sipping-config-framework) which explicitly includes DHCP, DNS, downloaded files, and manual configuration. In other words, the discovery mechanism you mention is already a configuration mechanism and always has been. The text does not need to change, because the text is consistent with the definitions used in a SIPPING WG document. We came to a consensus on this definition both there and in the SIP WG. >>> FIFTH, related to the second, third and fourth issues, we discussed >>> that that the network should be able to provide a "max-flow" number >>> to > >>> the client. >>> >> the maximum number of flows is the number of outbound-proxy-set URIs. >> If you want to come up with another piece of configuration data (by >> the > very broad definition of configuration we are >> using) that is a set of candidate URIs for the outbound-proxy-set >> which > are chosen at random up to some maximum to form >> the outbound-proxy-set, you are free to do so. > > [CHH] I am not talking about new configuration data, but a value that > could be returned (in the registration response) by the network to the > client, indicating how many flows to configure. The client then does > not > need to try to register more flows, if the network isn't going to > accept > them anyway. [/CHH] You are talking about something new. If you want to define this new thing, please write a draft. >>> SIXTH, one issue we've recently been discussing is what an edge proxy >>> does if it receives "keepalive=stun", but it doesn't support STUN. I >>> think we need to say something. I don't think we should just call it >>> an error case, and therefor it is "an implementation issue" how to >>> handle it. >> >> We can't define rules in an extension for proxies that don't support > that extension. The proxy will do whatever it does >> during this misconfigured case, consistent with RFC3261. >> >>> SEVENTH, related to the first issue, chapter 4.2 says: >>> >>> "Forming the route set for the request is outside the scope of this >>> document, but typically results in sending the REGISTER such that the >>> topmost Route header field contains a loose route to the outbound >>> proxy URI. Other issues related to outbound route construction are >>> discussed..." >>> >>> Maybe I just missunderstand that text, but IF we use an URI parameter >>> to indicate STUN NAT keep-alive I think there MUST be a Route header >>> to the outbound proxy URI. >>> >> No, you are missing the semantics of keepalive=stun. It is a token > which is used by the UAC/STUN client to know that it >> can mux STUN and SIP traffic. The STUN server/UAS or proxy does >> nothing > with this parameter. The server knows that the >> the client support STUN if it sends a STUN request. > > [CHH] If that is true, what is wrong with the client using the > Supported > header (Supported: keepalive) to indicate that? The Supported header is really irrelevant since the proxy or UAS could receive either a STUN request or a SIP message in any order. Since the proxy or UAS needs to receive a STUN request before it ever receives a SIP request, the SIP Supported header would just bloat the SIP message. The SIP message will also often be carried to several other SIP nodes before arriving at the UAS. Only the first hop cared. > Also, as I asked in another mail: would it be possible for the STUN > server, by inserting the keepalive parameter in the Path URI, to > indicate that IT supports STUN? > I see no harm in allowing the server to indicate whether it supports > STUN or not, BEFORE the client starts sending STUN requests and figures > it out itself... [/CHH] This isn't necessary to implement the draft now. The mechanism you describe is sufficiently complicated in the details that I would recommend writing a draft about it. I actually like this idea, but it could be complex and there is a slight chance that it won't work. Nothing in outbound will prevent what you've described. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 29 13:06:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvzwy-0004SA-52; Thu, 29 Jun 2006 13:05:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvzww-0004MQ-4H for sip@ietf.org; Thu, 29 Jun 2006 13:05:06 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvzwu-0002OA-LZ for sip@ietf.org; Thu, 29 Jun 2006 13:05:06 -0400 Received: from [131.161.248.86] (open-131-161-248-86.cliq.com [131.161.248.86]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k5TH4nF00715; Thu, 29 Jun 2006 10:04:49 -0700 In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F0279ACAF@esebe103.NOE.Nokia.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F0279ACAF@esebe103.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <31f2afa6728c84c0dcd3eb36cb6679e5@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Outbound-04 and "max-flow" in 200 OK for REGISTER Date: Thu, 29 Jun 2006 10:04:46 -0700 To: X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: fluffy@cisco.com, Rohan Mahy , sip@ietf.org, christer.holmberg@ericsson.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Erkki, I can think of a number of ways to make this work where the intended semantics are entirely embedded in DNS. Alternatively you can discover *candidate* outbound-proxy-URIs via DNS and use a max-flows value configured/discovered elsewhere to decide how to derive/self-configure the actually outbound-proxy-set. As a scope issue, the chairs (previous and current) and the ADs (at the time still Allison and Jon) directed the editors to make outbound separate from gruu, initial proxy discovery/configuration, and specification of record-routing behavior for high reliability and per-call state cookies. We then had WG consensus on this approach. I think that was a wise choice, and I fear that adding new parameters now will only unwind that consensus. thanks, -rohan On Jun 29, 2006, at 0:04, wrote: > Hi, > >>> FIFTH, related to the second, third and fourth issues, we >>> discussed that that the network should be able to provide >>> a "max-flow" number to the client. >> >> the maximum number of flows is the number of outbound-proxy-set >> URIs. If you want to come up with another piece of configuration >> data (by the very broad definition of configuration we are using) >> that is a set of candidate URIs for the outbound-proxy-set which >> are chosen at random up to some maximum to form the >> outbound-proxy-set, > >> you are free to do so. > > I would like to point out two emails in the thread where this > "max-flow" issue was discussed: > > http://www1.ietf.org/mail-archive/web/sip/current/msg14745.html > http://www1.ietf.org/mail-archive/web/sip/current/msg14753.html > > In that thread a solution was outlined as follows: > > "Network must provide max-flows in Register response. > Client must not exceed max-flows when establishing flows. > Client should attempt to equal max-flows if terminal capabilities > allows." > > To me this sounds a good idea due to the following facts: > > - Instead of explicit configuration the UA might find the > proxies supporting outbound e.g. from DNS > > - The number of proxies configured in DNS does not necessarily > equal to the number of flows the UA should set up. For instance > the service provider might have there many proxies to do load > balancing but targets to have reliability on other means than > the UAs maintaining multiple flows. > > Thus I was also expecting the proposed a solution to appear in > outbound-04 (or later version). In sip-outbound-discovery-02 > there is text like this: > > Whether the UA actually sets up one single flow or two redundant > flows, is determined in the following ways: > > o When the network responds to the primary REGISTER with 200 OK, > the > response may contain an indication telling the maximum number of > flows the network expects the UA to use. The UA SHOULD create > two > flows if the indicated value is at least two or if the network > does not give the indication at all. [[OPEN: the details of this > indication are still to be defined but are not in scope of this > spec]] > > I have not seen any serious comments given why this could > not be specified like proposed and would thus vote for > adding it to outbound -05. > > Regards, > > Erkki > ____________________________________ > > Erkki Koivusalo > Nokia Mobile Software > tel:+358 40 7571197 > mailto:erkki.koivusalo@nokia.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 Jun 29 16:47:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw3OQ-0004OW-Db; Thu, 29 Jun 2006 16:45:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw2yr-0001eZ-18 for sip@ietf.org; Thu, 29 Jun 2006 16:19:17 -0400 Received: from mx0.aculab.com ([213.249.233.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw2uQ-00056a-2y for sip@ietf.org; Thu, 29 Jun 2006 16:14:44 -0400 Received: from localhost (localhost [127.0.0.1]) by mx0.aculab.com (Postfix) with ESMTP id 2A9B087397 for ; Thu, 29 Jun 2006 21:14:41 +0100 (BST) Received: from mx0.aculab.com ([127.0.0.1]) by localhost (mx0.aculab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06620-02 for ; Thu, 29 Jun 2006 21:14:29 +0100 (BST) Received: from saturn2.Aculab.com (saturn [10.202.163.6]) by mx0.aculab.com (Postfix) with ESMTP id F18A987385 for ; Thu, 29 Jun 2006 21:14:29 +0100 (BST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 Jun 2006 21:14:29 +0100 Message-ID: <00D42150952F70458C66072322F7FE250B0A22@saturn2.Aculab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-sip-connect-reuse-05 Thread-Index: AcabuJ/JDkPHRkAsR7y1w1D/SUVwKQ== From: "Matthew Gardiner" To: X-Aculab-Com-Scanned: by amavisd-new-20030616-p10 (Debian) at aculab.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Subject: [Sip] draft-ietf-sip-connect-reuse-05 X-BeenThere: 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="===============0379521115==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0379521115== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69BB8.A0777FB7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69BB8.A0777FB7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have been reading the above document with some interest, as any = recommendation which attempts to reduce the burden due to latency of = repeated TLS handshakes seems to be worth following. However, I am now unsure as to how "shared connections" may be = implemented without introducing the chance of race conditions between = remote closes and request sends. It is section 8 which worries me. Despite the statement: "When a server receives a request whose topmost Via header contains an = "alias" parameter, it signifies that the upstream client will leave the = connection open beyond the transaction and dialog lifetime, and that = subsequent transactions and dialogs that are destined to a resolved = address that matches the identifiers in the advertised address in the = topmost Via header can reuse this connection." in 8.2 Server Behaviour, both the client and server behaviour sections = also add that client/server must be prepared to open new connections in = the, albeit unlikely, circumstance of the remote peer closing their end = of the connection. My question is, at any instant time, how does the = peer ready to send a new request know whether or not the remote end has = called close()?=20 Consider the following sequence of events, listed chronologically: 1. local end checks for read/write on socket. socket is writeable. 2. remote end closes. 3. local end calls send. send will not report an error initially. Am I missing something obvious as to how the remote close can be always = detected, prior to the attempt to send? thanks, Matthew Gardiner Software Enginneer Aculab ------_=_NextPart_001_01C69BB8.A0777FB7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-ietf-sip-connect-reuse-05

Hi,

I have been reading the above document = with some interest, as any recommendation which attempts to reduce the = burden due to latency of repeated TLS handshakes seems to be worth = following.

However, I am now unsure as to how = "shared connections" may be implemented without introducing = the chance of race conditions between remote closes and request = sends.

It is section 8 which worries me. = Despite the statement:

"When a server receives a request = whose topmost Via header contains an "alias" parameter, it = signifies that the upstream client will leave the connection open beyond = the transaction and dialog lifetime, and that subsequent transactions = and dialogs that are destined to a resolved address that matches the = identifiers in the advertised address in the topmost Via header can = reuse this connection."

in 8.2 Server Behaviour, both the = client and server behaviour sections also add that client/server must be = prepared to open new connections in the, albeit unlikely, circumstance = of the remote peer closing their end of the connection. My question is, = at any instant time, how does the peer ready to send a new request know = whether or not the remote end has called close()?

Consider the following sequence of = events, listed chronologically:

1. local end checks for read/write on = socket. socket is writeable.
2. remote end closes.
3. local end calls send. send will not = report an error initially.

Am I missing something obvious as to = how the remote close can be always detected, prior to the attempt to = send?

thanks,

Matthew Gardiner
Software Enginneer
Aculab

------_=_NextPart_001_01C69BB8.A0777FB7-- --===============0379521115== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0379521115==-- From sip-bounces@ietf.org Thu Jun 29 17:05:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw3fj-0003lB-V8; Thu, 29 Jun 2006 17:03:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw3fi-0003ir-UC for sip@ietf.org; Thu, 29 Jun 2006 17:03:34 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fw3fg-0004AQ-Fo for sip@ietf.org; Thu, 29 Jun 2006 17:03:34 -0400 Received: (qmail invoked by alias); 29 Jun 2006 21:03:31 -0000 Received: from p54987C0F.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.124.15] by mail.gmx.net (mp019) with SMTP; 29 Jun 2006 23:03:31 +0200 X-Authenticated: #29516787 Message-ID: <44A4401F.2050102@gmx.net> Date: Thu, 29 Jun 2006 23:03:27 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: SIP , geopriv@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: Subject: [Sip] draft-ietf-sip-location-conveyance-03.txt Comments X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Brian, Hi James I have a few questions concerning the latest SIP location conveyance document. * Usage Cases I think we need to consider the following scenarios: (a) Location transport per-value (a1) and per-reference (a2) (b) Location transport in the header (b1) and in the body (b2) (a) and (b) has to be combined to produce a reasonable combination. Let me go through the individual cases: - If SIP UA Alice wants to convey location information to SIP UA Bob then it should put the PIDF-LO into the body (and apply S/MIME to it). (Case a1+b2) - If a proxy wants to add location information to a SIP message then it creates the PIDF-LO and a reference to it. The reference is placed into the SIP header. (Case a2+b1) Would the proxy use M2M/M2E security? - If SIP UA Alice has to perform location-based routing (e.g., as used in emergency scenarios) then it has to place something into the SIP header since the proxy is not supposed to inspect the body (particularly since it can be encrypted). What is SIP UA Alice supposed todo? I think it is not realistic to assume that the SIP UA creates a reference and makes it available by running a webserver on the end host. It cannot add location information to the SIP header (as a base64 encoded PIDF-LO) since this functionality is not provided by the draft. This would be case a1+b1. - What happens if the SIP UA Alice only has a location reference and she wants to send it to SIP UA Bob (where intermediaries must not process the location information)? Is she able to place the reference into the body of the message? I don't think you cover this option in your draft. This would be case a2+b2. - What happens if you want to perform location-based routing (i.e., processing of the PIDF-LO by intermediaries) and conveyance to the other end point? Do you include the information only in the header and not in the body or in the header and the body? * I think that the following text is already covered in the PIDF-LO profile draft: " More than one location representation or format MAY be included in the same message body part, but all MUST point at the same position on the earth (altitude not withstanding), as this would confuse the recipient by pointing at more than one position within the same message body part. There MAY be a case in which part or parts of one location format and part or parts of another format exist in the same message body part. These complementary pieces of information MUST point at the same position on the earth, yet are incomplete within their own format. For example, there maybe be a latitude and longitude in coordinate format and a civic altitude value to complete a 3-dimensional position of a thing (i.e. which floor of a building the UA is on in a building at a particular lat/long coordinates pair). " * PIDF-LO in SIP Header You write: " The amount of information that is necessary to appropriately transmit location information in a format that is understandable is larger than a SIP header could realistically include. " What is the upper limit? * Scenario Description In the introduction you list three scenarios (actually four). I assume that Scenario #1 refers to the scenario in Figure 2 of Section 4 where the end point performs location-based routing. Correct? Thinking about the service URN draft one could get the impression that a solution scenario according to Scenario #3B could also be designed to accomplish the goal of Scenario #1. I might be good to combine the scenario description of Section 1 with the text and the figures in Section 4. Ciao Hannes _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 29 17:11:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw3lK-0007u9-UJ; Thu, 29 Jun 2006 17:09:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw3lJ-0007tw-UX for sip@ietf.org; Thu, 29 Jun 2006 17:09:21 -0400 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw3lJ-0004ak-GO for sip@ietf.org; Thu, 29 Jun 2006 17:09:21 -0400 Received: by py-out-1112.google.com with SMTP id d42so431041pyd for ; Thu, 29 Jun 2006 14:09:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DgUNltBjk+WxdNwpsvWkps/I9/0Xd7wibtqQyLTVB3qvRrkyzhRUWWznDLA0QCDZvBD77l2lDnxIr/ETueBh0tb0tX9sub8TQVdN3VBmTRsCP/lyZjXSvIu8NNupFx5zFKuU7vz2X0JbTOTq2epCHHum2TgZWbQpBlOQpLG0uTI= Received: by 10.35.78.13 with SMTP id f13mr1761807pyl; Thu, 29 Jun 2006 14:09:21 -0700 (PDT) Received: by 10.35.81.17 with HTTP; Thu, 29 Jun 2006 14:09:21 -0700 (PDT) Message-ID: <953beacc0606291409t3b20889eifcc4a515850e658a@mail.gmail.com> Date: Thu, 29 Jun 2006 14:09:21 -0700 From: "Rohan Mahy" To: "sip-chairs@ietf.org" Subject: Re: [Sip] draft-ietf-sip-gruu-09.txt ready for IESG? In-Reply-To: <475FF955A05DD411980D00508B6D5FB0134D1E61@en0033exch001u.uk.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <475FF955A05DD411980D00508B6D5FB0134D1E61@en0033exch001u.uk.lucent.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Keith, Dean, i) I just re-read gruu -09 and I am happy with its contents. Other than a few NITS that I will send privately, I see nothing wrong with the mechanism. thanks, -rohan On 6/27/06, Drage, Keith (Keith) wrote: > (As WG chair) > > I'm afraid I am going to have to ask you to be much more proactive on this question, as the IESG need something a little more positive from the WG. So... > > i) If you have thoroughly reviewed this, and as a result believe it is ready, and I know there are at least some of you out there who have torn GRUU to pieces, throughly digested it and put it back together again, then send Dean and myself an email to that effect at sip-chairs@ietf.org. > > ii) If you are intending to review this but want more time before responding, then also please say. > > Remember this document is still in the WGLC state. We trying to get it into the next state of IESG review. That means WG consensus that it is ready. > > Please try to respond by my original deadline of 30th June (although we may give a couple of extra days grace here). > > regards > > Keith > > > -----Original Message----- > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > Sent: 23 June 2006 11:57 > > To: 'sip@ietf.org' > > Cc: 'sip-chairs@ietf.org' > > Subject: [Sip] draft-ietf-sip-gruu-09.txt ready for IESG? > > > > > > (As WG chair) > > > > The SIP WG chairs and the author all think this document is > > ready for sending to the IESG. > > > > We have had WGLC announced 5th July 2004 to complete 17th July 2004. > > We had a further last round of WG review requested 26th > > October 2005 to complete 6th November 2005. > > We have had significant discussion on the lists since then of > > this draft, and discussion in SIP WG sessions, and all > > comments have been resolved. > > > > If you believe this document IS NOT ready to send to IESG, > > can you please indicate this to the list and the WG chairs by > > 12:00 midday UK time (7:00 am US Eastern Time) on 30th June > > 2006, giving technical justification for your objection. > > > > Please limit this thread to answering the question above. If > > you have other discussion relating to GRUU generally, then > > please use a different thread. > > > > regards > > > > Keith > > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: 22 June 2006 20:50 > > To: i-d-announce@ietf.org > > Cc: sip@ietf.org > > Subject: [Sip] I-D ACTION:draft-ietf-sip-gruu-09.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 : Obtaining and Using Globally Routable > > User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP) > > Author(s) : J. Rosenberg > > Filename : draft-ietf-sip-gruu-09.txt > > Pages : 38 > > Date : 2006-6-22 > > > > Several applications of the Session Initiation Protocol (SIP) require > > a user agent (UA) to construct and distribute a URI that can be used > > by anyone on the Internet to route a call to that specific UA > > instance. A URI that routes to a specific UA instance is called a > > Globally Routable UA URI (GRUU). This document describes an > > extension to SIP for obtaining a GRUU from a server and for > > communicating a GRUU to a peer within a dialog. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-09.txt > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in > > the body of the message. > > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sip-gruu-09.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sip-gruu-09.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 29 17:34:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw47i-0004wr-7n; Thu, 29 Jun 2006 17:32:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw47h-0004wl-3b for sip@ietf.org; Thu, 29 Jun 2006 17:32:29 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw47g-0005Vv-Gm for sip@ietf.org; Thu, 29 Jun 2006 17:32:29 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 29 Jun 2006 14:32:28 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k5TLWRk0031800; Thu, 29 Jun 2006 14:32:27 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5TLWQCW017600; Thu, 29 Jun 2006 14:32:27 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Jun 2006 14:32:27 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.96.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Jun 2006 14:32:26 -0700 Message-Id: <4.3.2.7.2.20060629161426.035ff008@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 Jun 2006 16:32:25 -0500 To: Hannes Tschofenig , SIP From: "James M. Polk" In-Reply-To: <44A4401F.2050102@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 29 Jun 2006 21:32:26.0450 (UTC) FILETIME=[8423BB20:01C69BC3] DKIM-Signature: a=rsa-sha1; q=dns; l=6105; t=1151616747; x=1152480747; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Geopriv]=20draft-ietf-sip-location-conveyance-03.txt=0A=20=20Co mments; X=v=3Dcisco.com=3B=20h=3DOeRs85a8BNAXi2BPn7cBFju7fiA=3D; b=uuof9EmS55/MzEISMWHoWUkghDGu3XGeSssJbr8gxLyx4/XsYW0s9rJ8IKlpqclGvukoLXNV HYrJzGjnP51/FlrK3rt52CYq4KeAM5a+YzwR7C9MJVs8BLRkLLs+y2bn; Authentication-Results: sj-dkim-3.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: Subject: [Sip] Re: [Geopriv] draft-ietf-sip-location-conveyance-03.txt Comments X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 11:03 PM 6/29/2006 +0200, Hannes Tschofenig wrote: >Hi Brian, >Hi James > >I have a few questions concerning the latest SIP location conveyance document. I moved this discussion to the SIP list, as that's the home of this ID. >* Usage Cases > >I think we need to consider the following scenarios: > >(a) Location transport per-value (a1) and per-reference (a2) > >(b) Location transport in the header (b1) and in the body (b2) > >(a) and (b) has to be combined to produce a reasonable combination. > >Let me go through the individual cases: > >- If SIP UA Alice wants to convey location information to SIP UA Bob then >it should put the PIDF-LO into the body (and apply S/MIME to it). (Case a1+b2) this is covered >- If a proxy wants to add location information to a SIP message then it >creates the PIDF-LO and a reference to it. The reference is placed into >the SIP header. (Case a2+b1) this is covered >Would the proxy use M2M/M2E security? this is orthogonal >- If SIP UA Alice has to perform location-based routing (e.g., as used in >emergency scenarios) then it has to place something into the SIP header >since the proxy is not supposed to inspect the body (particularly since it >can be encrypted). not true Nothing in SIP prevents a proxy from inspecting a body. A proxy just cannot add or modify a body. >What is SIP UA Alice supposed todo? Alice can include location by-value or by-reference. >I think it is not realistic to assume that the SIP UA creates a reference >and makes it available by running a webserver on the end host. I tend to agree, therefore I believe Alice includes location by-value if she has it >It what is "it" in this context? >cannot add location information to the SIP header (as a base64 encoded >PIDF-LO) since this functionality is not provided by the draft. I think you're operating under the impression that proxies cannot read bodies, which they can. Any B2BUA or SBC can modify bodies, or add bodies - but we cannot assume there will be one in the message path. >This would be case a1+b1. > >- What happens if the SIP UA Alice only has a location reference and she >wants to send it to SIP UA Bob (where intermediaries must not process the >location information)? Is she able to place the reference into the body of >the message? I don't think you cover this option in your draft. SIP Headers can be placed in a message body already. Do you want that specified here too? >This would be case a2+b2. > >- What happens if you want to perform location-based routing (i.e., >processing of the PIDF-LO by intermediaries) and conveyance to the other >end point? by-value covers this I believe >Do you include the information only in the header and not in the body or >in the header and the body? either a header or body The proxies can read and route based on the body, and Bob can dereference a header if that's all that's in the message. >* I think that the following text is already covered in the PIDF-LO >profile draft: > >" > More than one location representation or format MAY be included in > the same message body part, but all MUST point at the same position > on the earth (altitude not withstanding), as this would confuse the > recipient by pointing at more than one position within the same > message body part. There MAY be a case in which part or parts of > one location format and part or parts of another format exist in the > same message body part. These complementary pieces of information > MUST point at the same position on the earth, yet are incomplete > within their own format. For example, there maybe be a latitude and > longitude in coordinate format and a civic altitude value to > complete a 3-dimensional position of a thing (i.e. which floor of a > building the UA is on in a building at a particular lat/long > coordinates pair). >" This needs to be in the "Using Protocol's" document too IMO. I do not believe this is inconsistent with the PIDF-LO profile doc. >* PIDF-LO in SIP Header > >You write: >" > The amount > of information that is necessary to appropriately transmit location > information in a format that is understandable is larger than a SIP > header could realistically include. >" > >What is the upper limit? I do not know, but I do not believe it is 27 CATypes as separate fields in a Location header. I think Henning worked out a 500 byte element, and while that's allowable I believe, I think it's hard to read. >* Scenario Description > >In the introduction you list three scenarios (actually four). > >I assume that Scenario #1 refers to the scenario in Figure 2 of Section 4 >where the end point performs location-based routing. Correct? agreed >Thinking about the service URN draft one could get the impression that a >solution scenario according to Scenario #3B could also be designed to >accomplish the goal of Scenario #1. yes, but I choose to call them out separately to have a reader understand the different scenarios >I might be good to combine the scenario description of Section 1 with the >text and the figures in Section 4. I was told explicitly to reduce my figures in section 4. Therefore, I have a basic request/response transaction (figure 1), a request/response transaction involving an intermediary performing routing based on the location contents of the request (figure 2) and then articulate how Location can be conveyed in a specific SIP Request type (INVITE here). I have been told by the WG chairs in SIP to not have more than this. This doesn't prevent a user-cases ID from being generated giving these examples. I think that would be appropriate once this ID reaches RFC status. >Ciao >Hannes > > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 29 17:34:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw48S-00058S-6r; Thu, 29 Jun 2006 17:33:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw48R-00058N-26 for sip@ietf.org; Thu, 29 Jun 2006 17:33:15 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw48O-0005Xn-DS for sip@ietf.org; Thu, 29 Jun 2006 17:33:15 -0400 Received: from [192.168.1.4] (65-65-155-30.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5TLYgqa005848 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 29 Jun 2006 16:34:46 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) To: IETF SIP List Message-Id: From: Dean Willis Date: Thu, 29 Jun 2006 16:32:56 -0500 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.5 (/) X-Scan-Signature: be922d419820e291bde1362184dc32fd Cc: Cullen Jennings Subject: [Sip] re-revised SIP agenda X-BeenThere: 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="===============1196630556==" Errors-To: sip-bounces@ietf.org --===============1196630556== Content-Type: multipart/alternative; boundary=Apple-Mail-1--636598335 --Apple-Mail-1--636598335 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I added the elwell-tispan-identity draft into the segment on discussion of identity on day 2. This squeezed out Vijay's sipsec draft. I'm still hoping we can get an ad-hoc on SIP security, but I just don't know. Draft Agenda for SIP at IETF 66 Session 1, Monday 1300-1500 Room 520DEF Time Topic Discussion Leaders Reading List 1300 Agenda Bash, Announcements and Status Chairs This Doc 1305 Outbound Cullen Jennings draft-ietf-sip-outbound-04 1320 Outbound Discovery Miguel Garcia for Erkki Koivusalo draft-koivusalo-sip-outbound-discovery-01 1335 Outbound Midcall Issues Kevin Johns draft-johns-sip-outbound- middialog-draft-00 1340 Connection Reuse Vijay Gurbani Rohan Mahy draft-ietf-sip-connect-reuse-05 1400 Location Conveyance James Polk draft-ietf-sip-location- conveyance-03 1415 SAML for SIP James Polk Hannes Tschofenig draft-ietf-sip-saml-00 1430 Certificates. Arboreal Rodents Or Fruitless Canine Vocalization? Jason Fischl draft-ietf-sip-certs-01 1445 Hop Limit Diagnostics Is my bunny sick? Scott Lawrence draft-ietf-sip-hop-limit- diagnostics-03.txt Session 2, Wednesday 1300-1500 Room 520ABC Time Topic Discussion Leaders Reading List 1300 Agenda Bash Chairs This Doc 1305 Connected Identity John Elwell draft-ietf-sip-connected-identity-00 1330 Connected Identity for TISPAN John Elwell draft-elwell-sip- tispan-connected-identity-01 1345 Identity Co-Existence Jonathan rosenberg draft-rosenberg-sip- identity-coexistence-00 1400 Security Flows Robert Sparks draft-ietf-sip-sec-flows-01 1410 Fork loop fix Robert Sparks draft-ietf-sip-fork-loop-fix-02 1420 Feature list for advance specification Robert Sparks TBD 1430 Hitchhiker's Guide Jonathan Rosenberg draft-ietf-sip-hitchhikers- guide-00 1445 SIPS: Guidelines Francois Audet draft-audet-sip-sips-guidelines-02 TBD Improved TLS Requirements Vijay Gurbani draft-gurbani-sip-sipsec-00 --Apple-Mail-1--636598335 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII

I added the elwell-tispan-identity draft = into the segment on discussion of identity on day 2. This squeezed out = Vijay's sipsec draft. I'm still hoping we can get an ad-hoc on SIP = security, but I just don't know.


Draft Agenda for SIP at IETF 66

Session 1, Monday 1300-1500 Room = 520DEF

Outbound Discovery= Location Conveyance<= TR style=3D"border-spacing: 2px 2px; ">SAML for SIPCertificates. Arboreal Rodents
Or Fruitless Canine Vocalization?Hop Limit Diagnostics
Is my bunny sick?=
TimeTopicDiscussion LeadersReading List
1300Agenda Bash, Announcements and StatusChairsThis = Doc
1305OutboundCullen Jenningsdraft-ietf-sip-outbound-04
1320Miguel Garcia = for
Erkki = Koivusalo		draft-koivusalo-sip-outbound-discovery-01
1335Outbound Midcall = IssuesKevin Johnsdraft-johns-sip-outbound-middialog-draft-00
1340Connection = ReuseVijay Gurbani
Rohan Mahy		draft-ietf-sip-connect-reuse-05
1400James = Polkdraft-ietf-sip-location-conveyance-03
1415James Polk
Hannes Tschofenig		draft-ietf-sip-saml-00
1430Jason Fischl<= FONT class=3D"Apple-style-span" = face=3D"Times">draft-ietf-sip-certs-01
1445Scott = Lawrencedraft-ietf-sip-hop-limit-diagnostics-03.txt

Session 2, Wednesday 1300-1500 Room = 520ABC

Connected Identity for TISPAN= Fork loop fixFeature list for advance specification1430SIPS: Guidelines= --Apple-Mail-1--636598335-- --===============1196630556== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1196630556==-- From sip-bounces@ietf.org Thu Jun 29 17:36:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw4AG-00060u-T7; Thu, 29 Jun 2006 17:35:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw4AE-0005yI-T4 for sip@ietf.org; Thu, 29 Jun 2006 17:35:06 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw3FT-0007Co-J1 for sip@ietf.org; Thu, 29 Jun 2006 16:36:27 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fw2XH-0001yK-1T for sip@ietf.org; Thu, 29 Jun 2006 15:50:49 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 29 Jun 2006 12:50:46 -0700 X-IronPort-AV: i="4.06,193,1149490800"; d="scan'208"; a="326449092:sNHT63984148" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k5TJokkE019731 for ; Thu, 29 Jun 2006 12:50:46 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5TJokCU028467 for ; Thu, 29 Jun 2006 12:50:46 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Jun 2006 12:50:46 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.96.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Jun 2006 12:50:45 -0700 Message-Id: <4.3.2.7.2.20060629144551.036567f0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 Jun 2006 14:50:44 -0500 To: sip@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 29 Jun 2006 19:50:45.0864 (UTC) FILETIME=[4FE82E80:01C69BB5] DKIM-Signature: a=rsa-sha1; q=dns; l=1765; t=1151610646; x=1152474646; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:SIP=20Location=20Conveyance=20-03=20submitted; X=v=3Dcisco.com=3B=20h=3D6h/pu6K51uDgq0u9cNl4mnfGp6w=3D; b=fuypZQ7d9eRUqGmvYp8OE6Jcq/FFvdCB02Nh1TH/kLYFqqTvJZoVz0rIW77CRAhBHcymZdky 4Ieh/y+1WXea0/DZgAP/DszsWa+kF2cI625rp6lQ7uUkVgMuucmkjw1O; Authentication-Results: sj-dkim-4.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -1.5 (-) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Sip] SIP Location Conveyance -03 submitted X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I've submitted -03 of the SIP Location Conveyance ID for review and comments. http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-03.txt This is a list of the changes that have been made from the SIP WG version -02 to this version -03: - general clean-up of some of the sections - removed the message examples from the UPDATE, MESSAGE and REGISTER sections, as these seemed to be making the doc less readable, and not more readable - removed the "unknown" option tag, as it was not needed with a certain combination of the Supported and Location headers - clarified the location option tag usage in Supported, Require, Unsupported, and that it shouldn't be used in Proxy-Require, and why not. - Added a basic message flow to the basic operation section (Section 4) to aid in understanding of this SIP extension. - Added a message routing flow, which is based on the location of the requestor to show how a SIP server can make a routing decision to a destination based on where the UAC is. - Articulated how a UAS concludes a UAC understands this extension, yet does not know its location to provide to the UAS. This is helpful in those times where an intermediary will act differently based on whether or not a UAC understands this extension, and whether or not the UAC includes its location in the request. - Corrected the erroneous text regarding an Unsupported header being in a 424 response. It belongs in a 420 response. (Section 5.1) - Corrected the BNF (I hope) - Corrected some text in Section 5 that read like this document was an update to RFC 3261. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 29 17:44:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw4Hp-0003OT-F5; Thu, 29 Jun 2006 17:42:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw4Ho-0003OO-5E for sip@ietf.org; Thu, 29 Jun 2006 17:42:56 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw4Hm-0007Eh-SE for sip@ietf.org; Thu, 29 Jun 2006 17:42:56 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k5TLgpew027872; Thu, 29 Jun 2006 16:42:52 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k5TLgp901634; Thu, 29 Jun 2006 16:42:51 -0500 (CDT) Message-ID: <44A4495B.1080204@lucent.com> Date: Thu, 29 Jun 2006 16:42:51 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Gardiner Subject: Re: [Sip] draft-ietf-sip-connect-reuse-05 References: <00D42150952F70458C66072322F7FE250B0A22@saturn2.Aculab.com> In-Reply-To: <00D42150952F70458C66072322F7FE250B0A22@saturn2.Aculab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Matthew Gardiner wrote: > Consider the following sequence of events, listed chronologically: > > 1. local end checks for read/write on socket. socket is writeable. > 2. remote end closes. > 3. local end calls send. send will not report an error initially. > > Am I missing something obvious as to how the remote close can be always > detected, prior to the attempt to send? Matthew: A socket that is being monitored for events using select() or poll() is considered ready for reading when the read half of the connection is closed. When the sequence of events you write above happens, the send will succeed, but as a result of the remote end closing the socket, the local end will get a FIN, making the local descriptor readable. A read operation will then return EOF and you can conclude that all transactions in progress that are tied to that socket need to be closed appropriately. Depending on the TLS libraries you are using, your application could also get notified when the local end receives a close_notify TLS message. The close_notify will be followed by a FIN. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 29 17:56:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw4Sq-0003K4-BL; Thu, 29 Jun 2006 17:54:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw4So-0003Jy-RP for sip@ietf.org; Thu, 29 Jun 2006 17:54:18 -0400 Received: from py-out-1112.google.com ([64.233.166.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw4Sn-0000XK-Jv for sip@ietf.org; Thu, 29 Jun 2006 17:54:18 -0400 Received: by py-out-1112.google.com with SMTP id x31so1473pye for ; Thu, 29 Jun 2006 14:54:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ouSyjiI3C3lsnNpk+L3hU3uAHyy7HbbMDxmPotew6mZPBIG+caEk6JCKJXNtNRUggycPsyggCkEhMCYEoMtBU6FS9MJ8XRebwBgUtUg8b1gGcV6F4dUnObenQBTe2sPr9JhrU3WKP1FGB03LIDT3SfFbDH4A7SN+3/cEhMn+zB0= Received: by 10.35.111.14 with SMTP id o14mr1805200pym; Thu, 29 Jun 2006 14:54:17 -0700 (PDT) Received: by 10.35.81.17 with HTTP; Thu, 29 Jun 2006 14:54:17 -0700 (PDT) Message-ID: <953beacc0606291454i2d8c9cf0ibf16437c0090b936@mail.gmail.com> Date: Thu, 29 Jun 2006 14:54:17 -0700 From: "Rohan Mahy" To: "Dale.Worley@comcast.net" Subject: Re: [Sip] GRUU record-routing In-Reply-To: <200606272222.k5RMMLak027571@dragon.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200606262158.k5QLw8wq024605@dragon.ariadne.com> <44A07F72.7050902@cisco.com> <200606271840.k5RIeNB4022345@dragon.ariadne.com> <953beacc0606271456y1d93f822w13d482679b22a627@mail.gmail.com> <200606272222.k5RMMLak027571@dragon.ariadne.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yes, but the configuration framework is more flexible and more generally useful. The configuration framework can become more standardized, but the Service-Route can't get any more useful. ;-) thanks, -rohan On 6/27/06, Dale.Worley@comcast.net wrote: > From: "Rohan Mahy" > > While I hope that eventually they willl start using the SIP > configuration framework to get this kind of information, I am fine > with them continuing to user service-route. > > Isn't the configuration framework less standardized than > Service-Route? > > Dale > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 29 18:30:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw4zx-000658-MZ; Thu, 29 Jun 2006 18:28:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw4zw-00064j-Be for sip@ietf.org; Thu, 29 Jun 2006 18:28:32 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw4zt-0005ST-N7 for sip@ietf.org; Thu, 29 Jun 2006 18:28:32 -0400 Received: (qmail 21425 invoked by uid 0); 29 Jun 2006 22:28:27 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 29 Jun 2006 22:28:27 -0000 Message-ID: <00e201c69bcb$555b9710$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: References: Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-04.txt Date: Fri, 30 Jun 2006 00:28:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org We've had some VERY long and extensive discussions on this (starting with http://www1.ietf.org/mail-archive/web/sip/current/msg13677.html) but the draft is still not addressing some of the issues that were raised 1) The UAC needs a positive indication that the selected proxy can indeed handle STUN packets without choking on them. It is not sufficient if the URI it is configured with says 'keepalive=stun', that's a wish but no guarantee. A simple way to do this is to have the edge proxy that receives a REGISTER with its own address and 'keepalive=stun' in the topmost Route header mirror that parameter in the Path header it MUST insert (according to 5.1). There could be an issue in case systems exist that simply copy verbatim what is in the Route header URI into their Path header URI. To avoid this scenario, perhaps a header parameter (instead of an URI parameter) would be an idea. The text should then say "the UAC MUST wait for a 200 OK to REGISTER before it starts sending STUN packets. If the last Path header of the 200 OK does not contain keepalive=stun, the UAC MUST NOT use STUN towards this URI. If there are no Path headers and no "Supported: outbound", the UAC also MUST NOT use STUN towards the registrar.". It could still use TCP keepalive if it supports that 2) Section 5.3: the Edge Proxy MUST Record-Route dialog forming INVITE requests that it forwards over the flow towards the UA (reverse direction is not strictly necessary, but probably common too). If it does not do this, an ACK for 2xx cannot arrive. For incoming SUBSCRIBE it might work without (the NOTIFY could create a direct flow towards the target or some other proxy, using the local socket as a Contact), but then there would be an issue with keeping that flow alive (the STUN question). Probably safer to say that (in addition to MUST for INVITE) "the Edge Proxy SHOULD Record-Route all dialog-forming requests it forwards to the UA" 3) The Proxy-Require mechanism we have discussed could be useful to UACs that want to ensure that a selected edge proxy supports outbound, aborting if not. 4) (minor remark) Perhaps some words could be added that the UAC SHOULD perform keepalives when configured to do so, even if it detects that there is no NAT. There could be a transparent firewall device that needs to be kept open. Regards, Jeroen ----- Original Message ----- From: To: Cc: Sent: Wednesday, June 28, 2006 12:50 AM Subject: [Sip] I-D ACTION:draft-ietf-sip-outbound-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 : Managing Client Initiated Connections in the > Session Initiation Protocol (SIP) > Author(s) : C. Jennings, R. Mahy > Filename : draft-ietf-sip-outbound-04.txt > Pages : 34 > Date : 2006-6-27 > > The Session Initiation Protocol (SIP) allows proxy servers to > initiate TCP connections and send asynchronous UDP datagrams to User > Agents in order to deliver requests. However, many practical > considerations, such as the existence of firewalls and Network > Address Translators (NATs), prevent servers from connecting to User > Agents in this way. This specification defines behaviors for User > Agents, registrars and proxy servers that allow requests to be > delivered on existing connections established by the User Agent. It > also defines keep alive behaviors needed to keep NAT bindings open > and specifies the usage of multiple connections. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-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-outbound-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-outbound-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. > -------------------------------------------------------------------------------- > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 29 22:04:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw8LS-0005oS-Kv; Thu, 29 Jun 2006 22:02:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw8LR-0005nm-JY for sip@ietf.org; Thu, 29 Jun 2006 22:02:57 -0400 Received: from rwcrmhc15.comcast.net ([204.127.192.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw8LQ-0008SH-BS for sip@ietf.org; Thu, 29 Jun 2006 22:02:57 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc15) with ESMTP id <20060630020255m1500dk3m2e>; Fri, 30 Jun 2006 02:02:55 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id k5U22s0A013771 for ; Thu, 29 Jun 2006 22:02:54 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k5U22s70013767; Thu, 29 Jun 2006 22:02:54 -0400 Date: Thu, 29 Jun 2006 22:02:54 -0400 Message-Id: <200606300202.k5U22s70013767@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <953beacc0606291454i2d8c9cf0ibf16437c0090b936@mail.gmail.com> (rohan.mahy@gmail.com) Subject: Re: [Sip] GRUU record-routing References: <200606262158.k5QLw8wq024605@dragon.ariadne.com> <44A07F72.7050902@cisco.com> <200606271840.k5RIeNB4022345@dragon.ariadne.com> <953beacc0606271456y1d93f822w13d482679b22a627@mail.gmail.com> <200606272222.k5RMMLak027571@dragon.ariadne.com> <953beacc0606291454i2d8c9cf0ibf16437c0090b936@mail.gmail.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Rohan Mahy" Yes, but the configuration framework is more flexible and more generally useful. The configuration framework can become more standardized, but the Service-Route can't get any more useful. ;-) Too true. But I see the choice as a fig leaf that is *sufficient* from a whole wardrobe that is currently incompletely specified. What's itching me is that draft-ietf-sip-gruu-09 requires "outbound proxy" behavior. Currently that behavior is (IMO) not directly specified. One way to specify it would be to require that UAs implement Service-Route and that registrars deliver appropriate Service-Routes. That provides the needed behavior and specifies the interaction between the UA and the registrar in an interoperable way. The alternative is to leave the method by which the outbound proxy is communicated to the UA outside SIP (since the *content* of the configuration framework data objects is not specified), but that seems to make it impossible to make a UA that can in practice implement GRUU without proprietary knowledge of how it is going to determine the outbound proxy. Of course, I may be overlooking something here. In any case, I think the resolution of this matter should be spelled out in adequate detail in the I-D. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 30 01:57:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwByy-0003IA-Rf; Fri, 30 Jun 2006 01:56:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwByx-0003Ez-5h for sip@ietf.org; Fri, 30 Jun 2006 01:55:59 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwByw-0003GD-JS for sip@ietf.org; Fri, 30 Jun 2006 01:55:59 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5U5tkNG008242; Fri, 30 Jun 2006 08:55:50 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 08:55:02 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 08:55:01 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound-04 and "max-flow" in 200 OK for REGISTER Date: Fri, 30 Jun 2006 08:55:01 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F027D0DEB@esebe103.NOE.Nokia.com> In-Reply-To: <31f2afa6728c84c0dcd3eb36cb6679e5@ekabal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound-04 and "max-flow" in 200 OK for REGISTER Thread-Index: AcabnjKZWV6c0QPiQ6KcnUkXNKYpTQAatBWw From: To: X-OriginalArrivalTime: 30 Jun 2006 05:55:01.0940 (UTC) FILETIME=[BA365740:01C69C09] X-Spam-Score: 0.2 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: fluffy@cisco.com, sip@ietf.org, christer.holmberg@ericsson.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Rohan, >Alternatively you can discover=20 >*candidate* outbound-proxy-URIs via DNS and use a max-flows value=20 >configured elsewhere to decide how to derive/self-configure=20 >the actually outbound-proxy-set. Max-flows manually configured to the UA is what I already=20 have in sip-outbound-discovery. There were just some suggestions that it would be useful to be able to autoconfigure this parameter, too. >I can think of a number of ways to make this work where=20 >the intended semantics are entirely embedded in DNS.=20 If you have any ideas like that, could you please pass them to me since I am working on a related I-D where no such ideas have been introduced. I would be happy to receive those to be able to check if they work with the rest of the DNS scheme currently proposed. If yes, I could take them into my draft. Thanks, Erkki=20 >-----Original Message----- >From: ext Rohan Mahy [mailto:rohan@ekabal.com]=20 >Sent: 29.June.2006 20:05 >To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki) >Cc: dean.willis@softarmor.com; fluffy@cisco.com;=20 >christer.holmberg@ericsson.com; Rohan Mahy; sip@ietf.org >Subject: Re: [Sip] Outbound-04 and "max-flow" in 200 OK for REGISTER > >Erkki, > >I can think of a number of ways to make this work where the intended=20 >semantics are entirely embedded in DNS. Alternatively you can=20 >discover=20 >*candidate* outbound-proxy-URIs via DNS and use a max-flows value=20 >configured/discovered elsewhere to decide how to derive/self-configure=20 >the actually outbound-proxy-set. > >As a scope issue, the chairs (previous and current) and the=20 >ADs (at the=20 >time still Allison and Jon) directed the editors to make outbound=20 >separate from gruu, initial proxy discovery/configuration, and=20 >specification of record-routing behavior for high reliability and=20 >per-call state cookies. We then had WG consensus on this approach. I=20 >think that was a wise choice, and I fear that adding new=20 >parameters now=20 >will only unwind that consensus. > >thanks, >-rohan > > > >On Jun 29, 2006, at 0:04, wrote: >> Hi, >> >>>> FIFTH, related to the second, third and fourth issues, we >>>> discussed that that the network should be able to provide >>>> a "max-flow" number to the client. >>> >>> the maximum number of flows is the number of outbound-proxy-set >>> URIs. If you want to come up with another piece of configuration >>> data (by the very broad definition of configuration we are using) >>> that is a set of candidate URIs for the outbound-proxy-set which >>> are chosen at random up to some maximum to form the=20 >>> outbound-proxy-set, >> >>> you are free to do so. >> >> I would like to point out two emails in the thread where this >> "max-flow" issue was discussed: >> >> http://www1.ietf.org/mail-archive/web/sip/current/msg14745.html >> http://www1.ietf.org/mail-archive/web/sip/current/msg14753.html >> >> In that thread a solution was outlined as follows: >> >> "Network must provide max-flows in Register response. >> Client must not exceed max-flows when establishing flows. >> Client should attempt to equal max-flows if terminal capabilities >> allows." >> >> To me this sounds a good idea due to the following facts: >> >> - Instead of explicit configuration the UA might find the >> proxies supporting outbound e.g. from DNS >> >> - The number of proxies configured in DNS does not necessarily >> equal to the number of flows the UA should set up. For instance >> the service provider might have there many proxies to do load >> balancing but targets to have reliability on other means than >> the UAs maintaining multiple flows. >> >> Thus I was also expecting the proposed a solution to appear in >> outbound-04 (or later version). In sip-outbound-discovery-02 >> there is text like this: >> >> Whether the UA actually sets up one single flow or two redundant >> flows, is determined in the following ways: >> >> o When the network responds to the primary REGISTER with 200 OK,=20 >> the >> response may contain an indication telling the maximum=20 >number of >> flows the network expects the UA to use. The UA SHOULD create=20 >> two >> flows if the indicated value is at least two or if the network >> does not give the indication at all. [[OPEN: the=20 >details of this >> indication are still to be defined but are not in scope of this >> spec]] >> >> I have not seen any serious comments given why this could >> not be specified like proposed and would thus vote for >> adding it to outbound -05. >> >> Regards, >> >> Erkki >> ____________________________________ >> >> Erkki Koivusalo >> Nokia Mobile Software >> tel:+358 40 7571197 >> mailto:erkki.koivusalo@nokia.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 Jun 30 02:13:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwCDl-0002yD-Pt; Fri, 30 Jun 2006 02:11:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwCDk-0002y8-Mr for sip@ietf.org; Fri, 30 Jun 2006 02:11:16 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwCDj-0003dW-3o for sip@ietf.org; Fri, 30 Jun 2006 02:11:16 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5U6B4bs015213; Fri, 30 Jun 2006 09:11:05 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 09:10:52 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 09:10:52 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ready for WGLC on Outbound? Date: Fri, 30 Jun 2006 09:10:51 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F027D0E28@esebe103.NOE.Nokia.com> In-Reply-To: <1af2fea9ff9985f9c6473947e7fe3817@ekabal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ready for WGLC on Outbound? Thread-Index: Acabm2Bxc+E2kBKlQK+rjyBT7RExyQAbvWvA From: To: , X-OriginalArrivalTime: 30 Jun 2006 06:10:52.0254 (UTC) FILETIME=[F0A4BFE0:01C69C0B] X-Spam-Score: 0.2 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: sip@ietf.org, fluffy@cisco.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Rohan, >> Also, the issue is that what may be configured (no matter how you >> configure it) may not be a URI. It may simply be an IP address/FQDN, >> which is then used to build a SIP-URI. I think we shall=20 >> allow that, and make it more clear in the spec. [/CHH] > >the outbound spec defines a piece of configurable data (the=20 >'outbound-proxy-set'), which is a list of URIs. This list of URIs may=20 >never have a one-to-one correspondence to a user or administrator=20 >manually configurable field. That piece of configurable data may be=20 >derived from several fields, manually configurable, discovered via=20 >DHCP, DNS, the config package, P-Whatchamacallit headers, HTTP=20 >download, or via a random character generator seeded by the phase of=20 >the moon. > >The outbound-proxy-set was defined as a list of URIs because the UA=20 >acts on each item in the list, because each URI is expected to be=20 >places in a Route header, and because each URI is expected to=20 >typically have a keepalive URI parameter in it. Like mentioned in other recent emails the problem is that if the UA derives the proxy URI(s) from DHCP SIP server option or e.g. the AOR of the user, in those cases the derived URI will NOT contain the keepalive URI parameter in it. DHCP just returns IP addresses or domain names instead of URIs with parameters. Thus in those cases it would be critical for the UA to be able to ensure in REGISTER - 200 OK sequence that the contacted proxy supports Outbound and can handle STUN requests sent to its SIP port (not to cause any damage to an uncompliant proxy). I fully agree with this proposal from Jeroen: -- The text should then say "the UAC MUST wait for a 200 OK to REGISTER before=20 it starts sending STUN packets. If the last Path header of the 200 OK does=20 not contain keepalive=3Dstun, the UAC MUST NOT use STUN towards this = URI. If=20 there are no Path headers and no "Supported: outbound", the UAC also MUST=20 NOT use STUN towards the registrar.". It could still use TCP keepalive if it=20 supports that -- Please excuse me if I am just repeating myself and what e.g. Jeroen has said but I believe the importance of this issue justifies some redundancy :-) Regards, Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 30 03:11:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwD8d-0001DZ-Nm; Fri, 30 Jun 2006 03:10:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwD8c-0001DU-Mg for sip@ietf.org; Fri, 30 Jun 2006 03:10:02 -0400 Received: from mx0.aculab.com ([213.249.233.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwD8b-0008AX-9d for sip@ietf.org; Fri, 30 Jun 2006 03:10:02 -0400 Received: from localhost (localhost [127.0.0.1]) by mx0.aculab.com (Postfix) with ESMTP id 0BB8C87385 for ; Fri, 30 Jun 2006 08:10:00 +0100 (BST) Received: from mx0.aculab.com ([127.0.0.1]) by localhost (mx0.aculab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19851-03 for ; Fri, 30 Jun 2006 08:09:48 +0100 (BST) Received: from saturn2.Aculab.com (saturn [10.202.163.6]) by mx0.aculab.com (Postfix) with ESMTP id 3E1EE8738E for ; Fri, 30 Jun 2006 08:09:48 +0100 (BST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-ietf-sip-connect-reuse-05 Date: Fri, 30 Jun 2006 08:09:47 +0100 Message-ID: <00D42150952F70458C66072322F7FE250B0A23@saturn2.Aculab.com> In-Reply-To: <44A4495B.1080204@lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-connect-reuse-05 Thread-Index: AcabxQHBAtQCdV+gSgmXTKMLzeiFWwASEiFA From: "Matthew Gardiner" To: "Vijay K. Gurbani" X-Aculab-Com-Scanned: by amavisd-new-20030616-p10 (Debian) at aculab.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks Vijay, I think you have allayed my fears regarding the race possibility. = However, I think that to implement this connect-reuse scheme correctly = would require some fairly major changes to our, and perhaps other = peoples', SIP stacks. As connection-oriented sockets are based on a = stream of bytes, rather than necessarily discrete packets, it makes them = somewhat difficult to associate with SIP transactions, particularly in = programming environments where socket processing, transaction management = and dialog management are delegated to individual worker threads. In addition to the requirement of maintaining a per-socket list of = associated transactions, there is also the need to not only close these = transactions in the event of socket EOF but furthermore then to restart = the transactions to cater for this possibility. thanks, Matthew Gardiner Software Engineer Aculab -----Original Message----- From: Vijay K. Gurbani [mailto:vkg@lucent.com] Sent: 29 June 2006 22:43 To: Matthew Gardiner Cc: IETF SIP List Subject: Re: [Sip] draft-ietf-sip-connect-reuse-05 Matthew Gardiner wrote: > Consider the following sequence of events, listed chronologically: >=20 > 1. local end checks for read/write on socket. socket is writeable. > 2. remote end closes. > 3. local end calls send. send will not report an error initially. >=20 > Am I missing something obvious as to how the remote close can be = always=20 > detected, prior to the attempt to send? Matthew: A socket that is being monitored for events using select() or poll() is considered ready for reading when the read half of the connection is closed. When the sequence of events you write above happens, the send will succeed, but as a result of the remote end closing the socket, the local end will get a FIN, making the local descriptor readable. A read operation will then return EOF and you can conclude that all transactions in progress that are tied to that socket need to be closed appropriately. Depending on the TLS libraries you are using, your application could also get notified when the local end receives a close_notify TLS message. The close_notify will be followed by a FIN. Thanks, - vijay --=20 Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 30 03:36:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwDW4-0002PX-3S; Fri, 30 Jun 2006 03:34:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwDW2-0002PS-Oq for sip@ietf.org; Fri, 30 Jun 2006 03:34:14 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FwDW0-0001B1-2y for sip@ietf.org; Fri, 30 Jun 2006 03:34:14 -0400 Received: (qmail invoked by alias); 30 Jun 2006 07:34:10 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp042) with SMTP; 30 Jun 2006 09:34:10 +0200 X-Authenticated: #29516787 Message-ID: <44A4D3F0.7080109@gmx.net> Date: Fri, 30 Jun 2006 09:34:08 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" References: <4.3.2.7.2.20060629161426.035ff008@email.cisco.com> In-Reply-To: <4.3.2.7.2.20060629161426.035ff008@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b Cc: SIP Subject: [Sip] Re: [Geopriv] draft-ietf-sip-location-conveyance-03.txt Comments X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi James thanks for your quick response and your clarifications. Please find my response below: James M. Polk wrote: > At 11:03 PM 6/29/2006 +0200, Hannes Tschofenig wrote: > >> Hi Brian, >> Hi James >> >> I have a few questions concerning the latest SIP location conveyance >> document. > > > I moved this discussion to the SIP list, as that's the home of this ID. > >> * Usage Cases >> >> I think we need to consider the following scenarios: >> >> (a) Location transport per-value (a1) and per-reference (a2) >> >> (b) Location transport in the header (b1) and in the body (b2) >> >> (a) and (b) has to be combined to produce a reasonable combination. >> >> Let me go through the individual cases: >> >> - If SIP UA Alice wants to convey location information to SIP UA Bob >> then it should put the PIDF-LO into the body (and apply S/MIME to it). >> (Case a1+b2) > > > this is covered > > >> - If a proxy wants to add location information to a SIP message then >> it creates the PIDF-LO and a reference to it. The reference is placed >> into the SIP header. (Case a2+b1) > > > this is covered > >> Would the proxy use M2M/M2E security? > > > this is orthogonal I thought that this issue is important and would deserve a discussion in the document. I could only find discussions about S/MIME usage for end-to-end security. > > >> - If SIP UA Alice has to perform location-based routing (e.g., as used >> in emergency scenarios) then it has to place something into the SIP >> header since the proxy is not supposed to inspect the body >> (particularly since it can be encrypted). > > > not true > > Nothing in SIP prevents a proxy from inspecting a body. A proxy just > cannot add or modify a body. > >> What is SIP UA Alice supposed todo? > > > Alice can include location by-value or by-reference. > >> I think it is not realistic to assume that the SIP UA creates a >> reference and makes it available by running a webserver on the end host. > > > I tend to agree, therefore I believe Alice includes location by-value if > she has it > >> It > > > what is "it" in this context? > >> cannot add location information to the SIP header (as a base64 encoded >> PIDF-LO) since this functionality is not provided by the draft. It=the SIP proxy The SIP proxy cannot add location information to the SIP header (as a base64 encoded PIDF-LO) since this functionality is not provided by the draft. > > > I think you're operating under the impression that proxies cannot read > bodies, which they can. Any B2BUA or SBC can modify bodies, or add > bodies - but we cannot assume there will be one in the message path. The SIP proxy cannot read the body if it is encrypted. > > >> This would be case a1+b1. >> >> - What happens if the SIP UA Alice only has a location reference and >> she wants to send it to SIP UA Bob (where intermediaries must not >> process the location information)? Is she able to place the reference >> into the body of the message? I don't think you cover this option in >> your draft. > > > SIP Headers can be placed in a message body already. Do you want that > specified here too? Ok. That's fine. > > >> This would be case a2+b2. >> >> - What happens if you want to perform location-based routing (i.e., >> processing of the PIDF-LO by intermediaries) and conveyance to the >> other end point? > > > by-value covers this I believe I suspect that you want to put the location header into the message to let the proxy know where to find the PIDF-LO and that it actually has to look for one. If you don't want intermediaries to process it then you want to apply S/MIME and if not available (=quite likely) then you wouldn't put the location header into the message. Right? > >> Do you include the information only in the header and not in the body >> or in the header and the body? > > > either a header or body > > The proxies can read and route based on the body, and > > Bob can dereference a header if that's all that's in the message. > > > > >> * I think that the following text is already covered in the PIDF-LO >> profile draft: >> >> " >> More than one location representation or format MAY be included in >> the same message body part, but all MUST point at the same position >> on the earth (altitude not withstanding), as this would confuse the >> recipient by pointing at more than one position within the same >> message body part. There MAY be a case in which part or parts of >> one location format and part or parts of another format exist in the >> same message body part. These complementary pieces of information >> MUST point at the same position on the earth, yet are incomplete >> within their own format. For example, there maybe be a latitude and >> longitude in coordinate format and a civic altitude value to >> complete a 3-dimensional position of a thing (i.e. which floor of a >> building the UA is on in a building at a particular lat/long >> coordinates pair). >> " > > > This needs to be in the "Using Protocol's" document too IMO. I do not > believe this is inconsistent with the PIDF-LO profile doc. > I think the PIDF-LO profile document is more precise on these issues and repeating it does not add value. > > > >> * PIDF-LO in SIP Header >> >> You write: >> " >> The amount >> of information that is necessary to appropriately transmit location >> information in a format that is understandable is larger than a SIP >> header could realistically include. >> " >> >> What is the upper limit? > > > I do not know, but I do not believe it is 27 CATypes as separate fields > in a Location header. I think Henning worked out a 500 byte > element, and while that's allowable I believe, I think > it's hard to read. Why is it a problem if you assume that the SIP proxies will inspect the body? He has to read the same XML document. > > >> * Scenario Description >> >> In the introduction you list three scenarios (actually four). >> >> I assume that Scenario #1 refers to the scenario in Figure 2 of >> Section 4 where the end point performs location-based routing. Correct? > > > agreed > > >> Thinking about the service URN draft one could get the impression that >> a solution scenario according to Scenario #3B could also be designed >> to accomplish the goal of Scenario #1. > > > yes, but I choose to call them out separately to have a reader > understand the different scenarios Ok. That's fine. > > >> I might be good to combine the scenario description of Section 1 with >> the text and the figures in Section 4. > > > I was told explicitly to reduce my figures in section 4. Therefore, I > have a basic request/response transaction (figure 1), a request/response > transaction involving an intermediary performing routing based on the > location contents of the request (figure 2) and then articulate how > Location can be conveyed in a specific SIP Request type (INVITE here). > I have been told by the WG chairs in SIP to not have more than this. > This doesn't prevent a user-cases ID from being generated giving these > examples. I think that would be appropriate once this ID reaches RFC > status. I am fine with the number of message flows but Section 1 talks about scenarios without figures and later you talk again about scenarios with figure and there is no link between them. Ciao Hannes > > > >> Ciao >> Hannes >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 30 05:02:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwErl-0001Ut-GI; Fri, 30 Jun 2006 05:00:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwErk-0001Uo-1l for sip@ietf.org; Fri, 30 Jun 2006 05:00:44 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwErj-0000ti-2B for sip@ietf.org; Fri, 30 Jun 2006 05:00:44 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 72CF26E0003; Fri, 30 Jun 2006 11:00:42 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 11:00:42 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 11:00:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-outbound-04.txt Date: Fri, 30 Jun 2006 11:00:41 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F122A@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-outbound-04.txt Thread-Index: Acaby2I+I5IyBoDYRYKQcGv1juFdCQAVosDQ From: "Christer Holmberg \(JO/LMF\)" To: "Jeroen van Bemmel" , X-OriginalArrivalTime: 30 Jun 2006 09:00:41.0831 (UTC) FILETIME=[AA1ACF70:01C69C23] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jeroen, I agree with most of what you say. Also, I agree that by inserting keepalive=3Dstun in the Path header the = edge proxy can indicate that it supports STUN (I proposed that also = myself), and the client can find out about the support by looking at the = Path header. BUT, you then propose text talking about sending STUN "towards this = URI". Now, I think it is important to remember that the client is not = going to use the Path header(s) to route anything - at least not SIP = requests. The Path is used by the REGISTRAR for routing requests towards = the client - not the other way around. Or, am I wrong? So, yes, the client can look at the Path header to find out whether the = edge proxy supports STUN, but the Path header is not used for routing = SIP requests towards the edge proxy (eventhough the URI value of the = pre-inserted Route pointing towards the edge proxy, and the URI inserted = in the Path by the edge proxy itself, may of course be the same). If we were using the Service-Route header the situation would be a = little different. Regards, Christer =20 -----Original Message----- From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 Sent: 30. kes=E4kuuta 2006 1:28 To: sip@ietf.org Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-04.txt=20 We've had some VERY long and extensive discussions on this (starting = with http://www1.ietf.org/mail-archive/web/sip/current/msg13677.html) but the = draft is still not addressing some of the issues that were raised 1) The UAC needs a positive indication that the selected proxy can = indeed handle STUN packets without choking on them. It is not sufficient = if the URI it is configured with says 'keepalive=3Dstun', that's a wish = but no guarantee. A simple way to do this is to have the edge proxy that receives a = REGISTER with its own address and 'keepalive=3Dstun' in the topmost = Route header mirror that parameter in the Path header it MUST insert = (according to 5.1). There could be an issue in case systems exist that simply copy verbatim = what is in the Route header URI into their Path header URI. To avoid = this scenario, perhaps a header parameter (instead of an URI parameter) = would be an idea. The text should then say "the UAC MUST wait for a 200 OK to REGISTER = before it starts sending STUN packets. If the last Path header of the = 200 OK does not contain keepalive=3Dstun, the UAC MUST NOT use STUN = towards this URI. If there are no Path headers and no "Supported: = outbound", the UAC also MUST NOT use STUN towards the registrar.". It = could still use TCP keepalive if it supports that 2) Section 5.3: the Edge Proxy MUST Record-Route dialog forming INVITE = requests that it forwards over the flow towards the UA (reverse = direction is not strictly necessary, but probably common too). If it = does not do this, an ACK for 2xx cannot arrive. For incoming SUBSCRIBE = it might work without (the NOTIFY could create a direct flow towards the = target or some other proxy, using the local socket as a Contact), but = then there would be an issue with keeping that flow alive (the STUN = question). Probably safer to say that (in addition to MUST for INVITE) = "the Edge Proxy SHOULD Record-Route all dialog-forming requests it = forwards to the UA" 3) The Proxy-Require mechanism we have discussed could be useful to UACs = that want to ensure that a selected edge proxy supports outbound, = aborting if not. 4) (minor remark) Perhaps some words could be added that the UAC SHOULD = perform keepalives when configured to do so, even if it detects that = there is no NAT. There could be a transparent firewall device that needs = to be kept open. Regards, Jeroen ----- Original Message ----- From: To: Cc: Sent: Wednesday, June 28, 2006 12:50 AM Subject: [Sip] I-D ACTION:draft-ietf-sip-outbound-04.txt >A New Internet-Draft is available from the on-line Internet-Drafts=20 >directories. > This draft is a work item of the Session Initiation Protocol Working = Group=20 > of the IETF. > > Title : Managing Client Initiated Connections in the > Session Initiation Protocol (SIP) > Author(s) : C. Jennings, R. Mahy > Filename : draft-ietf-sip-outbound-04.txt > Pages : 34 > Date : 2006-6-27 > > The Session Initiation Protocol (SIP) allows proxy servers to > initiate TCP connections and send asynchronous UDP datagrams to User > Agents in order to deliver requests. However, many practical > considerations, such as the existence of firewalls and Network > Address Translators (NATs), prevent servers from connecting to User > Agents in this way. This specification defines behaviors for User > Agents, registrars and proxy servers that allow requests to be > delivered on existing connections established by the User Agent. It > also defines keep alive behaviors needed to keep NAT bindings open > and specifies the usage of multiple connections. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-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=20 > 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=20 > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sip-outbound-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-outbound-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. > -------------------------------------------------------------------------= ------- > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Jun 30 05:47:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwFZX-00058B-Bb; Fri, 30 Jun 2006 05:45:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwFZW-000586-Ay for sip@ietf.org; Fri, 30 Jun 2006 05:45:58 -0400 Received: from jes-fe2.zx.nl ([194.187.76.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwFZT-0004up-Ng for sip@ietf.org; Fri, 30 Jun 2006 05:45:58 -0400 Received: from Inbox ([89.205.151.75]) by jes-fe2.zx.nl (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0J1O006GS62RQG50@jes-fe2.zx.nl> for sip@ietf.org; Fri, 30 Jun 2006 11:50:12 +0100 (WEST) Date: Fri, 30 Jun 2006 11:45:19 +0200 From: Jeroen Van Bemmel Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-outbound-04.txt To: "Christer Holmberg (JO/LMF)" Message-id: <0J1O006GT62SQG50@jes-fe2.zx.nl> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal X-Priority: 3 X-Spam-Score: 1.2 (+) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Christer, Yes, 'this URI' should be interpreted as the URI that the UAC used in its R= oute header, and not the URI in the Path header Regards, jeroen=20 -----Oorspronkelijk bericht ----- Van: "Christer Holmberg (JO/LMF)" Aan: "Jeroen van Bemmel" ; sip@ietf.org Verzonden: 30-6-06 11:00 Onderwerp: RE: [Sip] I-D ACTION:draft-ietf-sip-outbound-04.txt=20 Hi Jeroen, I agree with most of what you say. Also, I agree that by inserting keepalive=3Dstun in the Path header the edg= e proxy can indicate that it supports STUN (I proposed that also myself), a= nd the client can find out about the support by looking at the Path header. BUT, you then propose text talking about sending STUN "towards this URI". N= ow, I think it is important to remember that the client is not going to use= the Path header(s) to route anything - at least not SIP requests. The Path= is used by the REGISTRAR for routing requests towards the client - not the= other way around. Or, am I wrong? So, yes, the client can look at the Path header to find out whether the edg= e proxy supports STUN, but the Path header is not used for routing SIP requ= ests towards the edge proxy (eventhough the URI value of the pre-inserted R= oute pointing towards the edge proxy, and the URI inserted in the Path by t= he edge proxy itself, may of course be the same). If we were using the Service-Route header the situation would be a little d= ifferent. Regards, Christer =20 -----Original Message----- From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 Sent: 30. kes=E4kuuta 2006 1:28 To: sip@ietf.org Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-04.txt=20 We've had some VERY long and extensive discussions on this (starting with http://www1.ietf.org/mail-archive/web/sip/current/msg13677.html) but the dr= aft is still not addressing some of the issues that were raised 1) The UAC needs a positive indication that the selected proxy can indeed h= andle STUN packets without choking on them. It is not sufficient if the URI= it is configured with says 'keepalive=3Dstun', that's a wish but no guaran= tee. A simple way to do this is to have the edge proxy that receives a REGISTER = with its own address and 'keepalive=3Dstun' in the topmost Route header mir= ror that parameter in the Path header it MUST insert (according to 5.1). There could be an issue in case systems exist that simply copy verbatim wha= t is in the Route header URI into their Path header URI. To avoid this scen= ario, perhaps a header parameter (instead of an URI parameter) would be an = idea. The text should then say "the UAC MUST wait for a 200 OK to REGISTER before= it starts sending STUN packets. If the last Path header of the 200 OK does= not contain keepalive=3Dstun, the UAC MUST NOT use STUN towards this URI. = If there are no Path headers and no "Supported: outbound", the UAC also MUS= T NOT use STUN towards the registrar.". It could still use TCP keepalive if= it supports that 2) Section 5.3: the Edge Proxy MUST Record-Route dialog forming INVITE requ= ests that it forwards over the flow towards the UA (reverse direction is no= t strictly necessary, but probably common too). If it does not do this, an = ACK for 2xx cannot arrive. For incoming SUBSCRIBE it might work without (th= e NOTIFY could create a direct flow towards the target or some other proxy,= using the local socket as a Contact), but then there would be an issue wit= h keeping that flow alive (the STUN question). Probably safer to say that (= in addition to MUST for INVITE) "the Edge Proxy SHOULD Record-Route all dia= log-forming requests it forwards to the UA" 3) The Proxy-Require mechanism we have discussed could be useful to UACs th= at want to ensure that a selected edge proxy supports outbound, aborting if= not. 4) (minor remark) Perhaps some words could be added that the UAC SHOULD per= form keepalives when configured to do so, even if it detects that there is = no NAT. There could be a transparent firewall device that needs to be kept = open. Regards, Jeroen ----- Original Message ----- From: To: Cc: Sent: Wednesday, June 28, 2006 12:50 AM Subject: [Sip] I-D ACTION:draft-ietf-sip-outbound-04.txt >A New Internet-Draft is available from the on-line Internet-Drafts=20 >directories. > This draft is a work item of the Session Initiation Protocol Working Grou= p=20 > of the IETF. > > Title : Managing Client Initiated Connections in the > Session Initiation Protocol (SIP) > Author(s) : C. Jennings, R. Mahy > Filename : draft-ietf-sip-outbound-04.txt > Pages : 34 > Date : 2006-6-27 > > The Session Initiation Protocol (SIP) allows proxy servers to > initiate TCP connections and send asynchronous UDP datagrams to User > Agents in order to deliver requests. However, many practical > considerations, such as the existence of firewalls and Network > Address Translators (NATs), prevent servers from connecting to User > Agents in this way. This specification defines behaviors for User > Agents, registrars and proxy servers that allow requests to be > delivered on existing connections established by the User Agent. It > also defines keep alive behaviors needed to keep NAT bindings open > and specifies the usage of multiple connections. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-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 th= e=20 > 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=20 > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sip-outbound-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-outbound-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. > ---------------------------------------------------------------------------= ----- > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Jun 30 06:27:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwGC3-0002aJ-Nq; Fri, 30 Jun 2006 06:25:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwGC2-0002aE-86 for sip@ietf.org; Fri, 30 Jun 2006 06:25:46 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwGC0-0007X0-5Z for sip@ietf.org; Fri, 30 Jun 2006 06:25:46 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5F04BE31; Fri, 30 Jun 2006 12:25:43 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 12:25:43 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 12:25:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ready for WGLC on Outbound? Date: Fri, 30 Jun 2006 12:25:42 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F122E@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ready for WGLC on Outbound? Thread-Index: Acabm08HlROlkMHiRguCfvlpP9BopgAi4Kug From: "Christer Holmberg \(JO/LMF\)" To: "Rohan Mahy" X-OriginalArrivalTime: 30 Jun 2006 10:25:43.0014 (UTC) FILETIME=[8AA59060:01C69C2F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Cc: IETF SIP List , Cullen Jennings , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Rohan,=20 >>[CHH] I have no problem with keeping the STUN keep-alive stuff in the=20 >>outbound draft. Again, what I am asking for is to more clearly=20 >>separate it, as a stand alone feature, from the rest of the outbound=20 >>stuff. Of course we can say that the support of outbound requires the=20 >>support of STUN keep-alive. [/CHH] >I don't see why you need a separate section in the draft when you can point at the IANA registry. Besides, defining a standalone description of STUN=20 >keepalives was never a requirement motivating this work. [CHH] Again, RFC3489bis defines a STUN keepalive usage, and we shall describe how it's implemented in SIP. I see no reason why outbound should define a mechanism for using STUN for keepalive with outbound, and then we may later define how to use STUN for keepalive with some other extension. We should have one generic mechanism, and I should be able to use STUN for keepalive without having to use the rest of the outbound stuff. As part of the "[Sip]Outbound:keep-alive,outbound and 3489bis" thread Jonathan also said: "I think we should allow the STUN keepalives without the rest of the stuff. Its a handy tool for inter-server keepalives in cases where there are no NAT or firewalls. -Jonathan R." [/CHH] >>[CHH] I totally agree with you. 3489bis defiens the STUN keep-alive usage, and the outbound draft describes how to "adopt" it with SIP. >>And, that is what I think should be more clear in the spec. The outbound draft does not define the usage of STUN for keep-alive as such, only=20 >>how to use it for SIP. The outbound draft DOES refer to 3489bis, but it does not mention the USAGE defined ni 3489bis. >> >>Related to that, chapter 7.1 says: "This document defines a new STUN=20 >>usage for connectivity checks." Again, this usage is already defined=20 >>in 3489bis (chapter 12.3), so we only need to adopt it to SIP. [/CHH] >OK, I will change this to something like: "This document uses the STUN connectivity check usage [ref] for connectivity checks over the SIP flow." [CHH] "...and defines how to use/implement the STUN NAT keepalive usage [ref] with SIP". [/CHH] >>Also, the issue is that what may be configured (no matter how you=20 >>configure it) may not be a URI. It may simply be an IP address/FQDN,=20 >>which is then used to build a SIP-URI. I think we shall allow that,=20 >>and make it more clear in the spec. [/CHH] >> >the outbound spec defines a piece of configurable data (the 'outbound-proxy-set'), which is a list of URIs. This list of URIs may never have a one-to- >one correspondence to a user or administrator manually configurable field. That piece of configurable data may be derived from several fields, manually=20 >configurable, discovered via DHCP, DNS, the config package, P-Whatchamacallit headers, HTTP download, or via a random character generator seeded by the=20 >phase of the moon. [CHH] The issue is that you talk about "configured URIs". No matter HOW the configuration is done, to me this sounds like the URI is provided to the client somehow (manually or automatically). BUT, what may be configured is only an IP address. The client can then use that information to GENERATE a SIP-URI, but that generated SIP-URI is not necessairly what was "configured", or given as "input" to the client. So, I do think we are talking about the same thing. I am just saying that the "configured URI" wording is a little unclear. [/CHH] >The outbound-proxy-set was defined as a list of URIs because the UA acts on each item in the list, because each URI is expected to be places in a Route=20 >header, and because each URI is expected to typically have a keepalive URI parameter in it. [CHH] The SIP stack in the client acts on each SIP-URI, which it has generated based on configured information (which very well be that SIP-URI, but also maybe just a domain name, or IP address...)=20 We don't necessarily need to replace the current wording - I am just asking for clarification text. [/CHH] >What you want is already allowed, but the most straightforward, logical thing for a UA designer to do is to make the outbound-proxy-set manually and=20 >automatically configurable. [CHH] Well, that's your opinion - I am sure there are people having other opinions :) In any case, that is an implementation issue, so we don't need to argue about that. AND, earlier I HAVE proposed that manual configuration of a SIP-URI would be the "default" mechanism, which one must implement, unless there is another mechanism. [/CHH] >It would be a disservice to the community to clog up the draft with text describing things you are already allowed to do, unless we have strong=20 >motivations, use-cases, and requirements. We have none of these, but if you feel strongly enough to write an informative draft that reminds implementors=20 >of all the things they are allowed to do in this context and provides motivations and requirements, go for it. But that would be a future draft. [CHH] I am not really sure I understand... All I am asking is for a clarification saying that the SIP-URI may not be what is "provided" (manually or automatically) to the client as part of the "configuration". The SIP-URI is what the client generates from whatever configuration input it gets (e.g. using the P-CSCF discovery mechanism in 3GPP), and uses it for generating Route headers etc. I don't see anything strange or controversial in that...=20 Chapter 4.2 says: "UAs obtain at configuration time one or more SIP URIs representing the default outbound-proxy-set." Maybe it's my english, but to me this sounds like the SIP-URI is actually what is given, from whatever external source, as input to the client. [/CHH] >>[CHH] So, what text do you think clearly says that there may be=20 >>scenarios where only a single flow can be used? Just saying that one=20 >>chapter describes *an* example doesn't make that clear. >> >>Also, "Other designs" sounds to me like using mechanisms that are not=20 >>defined "in this specification", which is not correct. Even if you=20 >>only register a single flow you would use the mechanism "in this=20 >>specification". [/CHH] > >Christer, the IETF model of specifications is that you can do anything you like as long as you implement the normative parts of the specification. If=20 >you want to implement a reliable system that just use one flow, just go and implement it. If you want to describe a reliable system that uses one flow,=20 >write a draft to describe it. [CHH] All I want is an indication saying that the OUTBOUND MECHANISM can be used with systems where a single flow is enough to provide reliability. I do NOT want to define a new "outbound" mechanism for those systems, and I see no reason why I should have to write a draft to describe such systems... [/CHH] >Micro-editing non-normative language to more explicitly allow for reliability (or other) schemes that have not been discussed and have no requirements is=20 >contrary to the charter of this WG. [CHH] It has been discussed...=20 I have also said that, unless the client KNOWS (that is one of the reasons why the "max-flow" indicator would be useful) it is communicating with such system, it SHALL register at least 2 (or whatever the number is at the moment) flows. So, again, I am NOT trying to change the basic ideas behind outbound, of which one is to provide reliability. I am simply saying that there may be systems where a single flow is enough to provide that reliability.=20 You say the draft does not forbid the usage in such systems - I am saying that the draft doesn't indicate that clear enough :) [/CHH] >>[CHH] Again, you may not always configure the edge proxies "manually". >>You may use a separate discovery mechanism. And, that discovery=20 >>mechanism may, for different reasons, provide a list of edge proxies,=20 >>but that doesn't mean that you always want to register to all of them=20 >>at the same time. [/CHH] >> >Christer, you seem to be missing the definition of configure. As a lay definition, lets use the following: Configure means to cause a piece of non-per- >call, non-per-dialog state to be set. Manual configuration is only one mechanism of configuration. This is consistent with the SIP configuration=20 >framework (draft-ietf-sipping-config-framework) which explicitly includes DHCP, DNS, downloaded files, and manual configuration. > >In other words, the discovery mechanism you mention is already a configuration mechanism and always has been. > >The text does not need to change, because the text is consistent with the definitions used in a SIPPING WG document. We came to a consensus on this=20 >definition both there and in the SIP WG. [CHH] Like I said earlier, it seems like we agree on the technical issue, i.e. you are allowed to have a system where e.g. only the IP address of the ege proxy is provided (using whatever mechanism) to the client - do we agree on that? [/CHH] >>>>FIFTH, related to the second, third and fourth issues, we discussed=20 >>>>that that the network should be able to provide a "max-flow" number=20 >>>>to the client. >>>> >>>the maximum number of flows is the number of outbound-proxy-set URIs. >>>If you want to come up with another piece of configuration data (by=20 >>>the very broad definition of configuration we are >>>using) that is a set of candidate URIs for the outbound-proxy-set=20 >>>which are chosen at random up to some maximum to form >>>the outbound-proxy-set, you are free to do so. >> >>[CHH] I am not talking about new configuration data, but a value that=20 >>could be returned (in the registration response) by the network to the >>client, indicating how many flows to configure. The client then does=20 >>not need to try to register more flows, if the network isn't going to=20 >>accept them anyway. [/CHH] >You are talking about something new. If you want to define this new thing, please write a draft. [CHH] What is "new" and what is "old"??? Since we are working on the draft, aren't we allowed to add stuff to it??? Also, when this was discussed (see Erikki's mail) I think it was considered that this would be a useful addition - at least there were no objections. [/CHH] Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 30 07:27:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwH7k-0008EG-PY; Fri, 30 Jun 2006 07:25:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwH7i-0008EA-Uu for sip@ietf.org; Fri, 30 Jun 2006 07:25:22 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwH7h-0003xa-NZ for sip@ietf.org; Fri, 30 Jun 2006 07:25:22 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 30 Jun 2006 07:25:21 -0400 X-IronPort-AV: i="4.06,196,1149480000"; d="scan'208,217"; a="91383555:sNHT43151048" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5UBPLno024502 for ; Fri, 30 Jun 2006 07:25:21 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 30 Jun 2006 07:25:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 30 Jun 2006 07:25:21 -0400 Message-ID: <0DEB933345E95A4083C4403CD2E7980C01001A15@xmb-rtp-211.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [WARNING: VIRUS REMOVED] Fw: Sexy Thread-Index: AcacN99YG+PTdbXvSbek238py+b8twAAAAIG From: "Kevin Lingle \(klingle\)" To: "sip" X-OriginalArrivalTime: 30 Jun 2006 11:25:21.0270 (UTC) FILETIME=[DF741960:01C69C37] X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Sip] Out of Office AutoReply: [WARNING: VIRUS REMOVED] Fw: Sexy X-BeenThere: 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="===============0850012970==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0850012970== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69C37.DF6207F4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69C37.DF6207F4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Out of the office 6/26-7/4. Returning to work 7/5/2006. I will read = and respond to your email when I return. For urgent matters, contact = my manager: Denise Caballero-McCann (dcmccann@cisco.com). ------_=_NextPart_001_01C69C37.DF6207F4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Out of Office AutoReply: [WARNING: VIRUS REMOVED] Fw: = Sexy

Out of the office 6/26-7/4.  Returning to work = 7/5/2006.   I will read and respond to your email when I = return.   For urgent matters, contact my manager: Denise = Caballero-McCann (dcmccann@cisco.com).

------_=_NextPart_001_01C69C37.DF6207F4-- --===============0850012970== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0850012970==-- From sip-bounces@ietf.org Fri Jun 30 07:29:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwH9r-00007M-36; Fri, 30 Jun 2006 07:27:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwH9p-00007D-9R for sip@ietf.org; Fri, 30 Jun 2006 07:27:33 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwH9o-0004Ff-MZ for sip@ietf.org; Fri, 30 Jun 2006 07:27:33 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5UBRNst004001; Fri, 30 Jun 2006 14:27:25 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 14:26:57 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 14:26:57 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [Sip] Outbound-04 and routing of requests to be sent Date: Fri, 30 Jun 2006 14:27:03 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F027D122B@esebe103.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound-04 and routing of requests to be sent Thread-Index: AcaaQ9zhlnjbEgT3S92QVFYtRRfyFgB8AbxQ From: To: X-OriginalArrivalTime: 30 Jun 2006 11:26:57.0190 (UTC) FILETIME=[18A05460:01C69C38] X-Spam-Score: 0.2 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Rohan, Even if this issue was discussed earlier between me and Cullen: http://www1.ietf.org/mail-archive/web/sip/current/msg14560.html=20 ... I still feel uncomfortable with how chapter 4.3. Sending Requests is formulated in latest outbound-04: When a UA is about to send a request, it first performs normal processing to select the next hop URI. The UA can use a variety of techniques to compute the route set and accordingly the next hop URI. Discussion of these techniques is outside the scope of this document but could include mechanisms specified in RFC 3608 [RFC3608] (Service Route) and [I-D.rosenberg-sip-route-construct]. The UA performs normal DNS resolution on the next hop URI (as described in RFC 3263 [RFC3263]) to find a protocol, IP address, and port. For non-TLS protocols, if the UA has an existing flow to this IP address, and port with the correct protocol, then the UA MUST use the existing connection. For TLS protocols, there must also be a match between the host production in the next hop and one of the URIs contained in the subjectAltName in the peer certificate. If the UA cannot use one of the existing flows, then it SHOULD form a new flow by sending a datagram or opening a new connection to the next hop, as appropriate for the transport protocol. The draft is still very explicit that "the UA performs normal DNS resolution=20 on the next hop URI (as described in RFC 3263 [RFC3263]) to find a protocol,=20 IP address, and port." Like I mentioned earlier those RFC 3263 procedures might cause the UA=20 to select a proxy towards which it does not have a flow open. However what should happen in the following use cases is not very clear from the current text and is left as "a trivial excercise for the reader": 1. UA sends an INVITE=20 My earlier question was: Is the UA expected to keep this new flow alive ?=20 Cullen answered: "No - if it is important for this flow to stay alive,=20 it will use a GRUU in the contact which will end up with routing over=20 one of the flows that is alive. This is out of the scope of outbound." If that is the case the current text is a bit ambiguous in the sense=20 that it requests the UA to "form a new flow towards the next hop". When the I-D uses the word "flow" it nearly always refers to a flow that the UA is required to keep alive - except this specific case. So if the meaning is that the UA should not keep this new connection persistently alive I could suggest rewording the text like this: If the UA cannot use one of the existing flows, then it SHOULD=20 send a datagram or open a new connection to the next hop, as appropriate for the transport protocol. Note: By using GRUU in Contact header the UA can ensure that the possibly resulting dialog will be routed over an existing flow towards the UA. 2. UA sends a REGISTER refresh My earlier question was: I believe that draft-ietf-sip-outbound=20 is written with the assumption that when the UA refreshes a=20 registration binding the REGISTER message would be sent over=20 the same flow over which the binding was created, right ? Cullen answered: "I think Robert has or working on a draft with=20 fixes this. It's not clear this is what 3263 says should happen. Clearly we want to send things in the same dialog on an existing=20 connection if we have one. One of the things we got wrong in much=20 earlier version of outbound was trying to fix every routing problem=20 in sip in one document including high availability and stateless=20 server design. We are definitely trying to push things that are=20 orthogonal to be solved separately." However outbound-04 still explicitely tells the UA to use RFC3263 processing, so I do not find how the UA is allowed to use the existing flow (or use any mechanism defined in a draft by Robert). I hope you could explicitely specify in outbound-05 one of the following procedures: 1. UA to send registration refreshes over the same flow which was set up when sending the corresponding initial registration (instead of resolving the URI with RFC 3263 procedures). OR 2. Mention that the UA is allowed to swap a persisten flow from one proxy to another when performing a registration refresh. I would prefer the first one since the second alternative is expected to cause some nasty race conditions when performing=20 the switch. Regards, Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 30 08:46:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwIMn-0004vE-La; Fri, 30 Jun 2006 08:45:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwIMm-0004v8-3c for sip@ietf.org; Fri, 30 Jun 2006 08:45:00 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwIMk-00021Q-Qg for sip@ietf.org; Fri, 30 Jun 2006 08:45:00 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 30 Jun 2006 05:44:58 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k5UCiwDQ016899; Fri, 30 Jun 2006 05:44:58 -0700 Received: from [192.168.1.2] (sjc-vpn2-416.cisco.com [10.21.113.160]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5UCihCf019607; Fri, 30 Jun 2006 05:44:57 -0700 (PDT) In-Reply-To: <200606281315.22640.ft@it.su.se> References: <8F3CFCB3-ED75-4747-AD8E-0A43DC6D8BAA@softarmor.com> <200606281315.22640.ft@it.su.se> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Ready for WGLC on Outbound? Date: Thu, 29 Jun 2006 16:12:26 -0700 To: Fredrik Thulin X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=362; t=1151671498; x=1152535498; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Ready=20for=20WGLC=20on=20Outbound?; X=v=3Dcisco.com=3B=20h=3D3vqpxUPzaqXx+Ii0wo1jJmC/3Vo=3D; b=APbvsbuNVZQ1eMVxLDl5eJQJYGviPKH71bSsOaJjjBk7b30ARN39ivJq15NsE18Qw/WPQKKX Fk1k8E00GbTnER7JmNxMfpptYYFWi0At6TyFQTtOCSJmUAbJkbdKvnRy; Authentication-Results: sj-dkim-2.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: sip@ietf.org, Rohan Mahy , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Sorry - I messed up and missed that one. On Jun 28, 2006, at 4:15 AM, Fredrik Thulin wrote: > > Also, is there consensus to use the 410 response code even though > RFC3261 says that it is to be considered a permanent condition? > > Adam Roach brought this up in > > http://www1.ietf.org/mail-archive/web/sip/current/msg13530.html > > /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 30 09:21:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwIuC-0004Ye-2L; Fri, 30 Jun 2006 09:19:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwIuA-0004Y7-H3 for sip@ietf.org; Fri, 30 Jun 2006 09:19:30 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwIu9-0004F6-6k for sip@ietf.org; Fri, 30 Jun 2006 09:19:30 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 30 Jun 2006 06:19:28 -0700 X-IronPort-AV: i="4.06,197,1149490800"; d="scan'208"; a="432261369:sNHT2480922664" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k5UDJRhq015644; Fri, 30 Jun 2006 06:19:27 -0700 Received: from [192.168.1.2] (sjc-vpn2-416.cisco.com [10.21.113.160]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5UDJE9t025852; Fri, 30 Jun 2006 06:19:27 -0700 (PDT) In-Reply-To: <002501c6995b$1c3002e0$31713b51@BEMBUSTER> References: <002401c693c8$aab13400$31713b51@BEMBUSTER> <4497EAE7.9090700@cisco.com> <44985514.4010107@cisco.com> <002f01c694ad$3c5479a0$31713b51@BEMBUSTER> <669459C0-169D-42AF-B59A-0F81AB5C2339@cisco.com> <002501c6995b$1c3002e0$31713b51@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] draft-ietf-sip-certs-00, communicating private keys and self-signed certificates Date: Fri, 30 Jun 2006 06:19:30 -0700 To: Jeroen van Bemmel X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=1678; t=1151673567; x=1152537567; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20draft-ietf-sip-certs-00, =20communicating=20private=20key s=20and=20self-signed=20certificates; X=v=3Dcisco.com=3B=20h=3DDlckREHIHof3L3K2GphZoDvnBpI=3D; b=pWnwILgVk8SYd+ZrKFiR4z04HylBpsY7NhShdFdGiQ3ydjsyUt94zGC5luM9uLQI1hZkBIQR g/XfHpQfaY7B6J2XDyLLdEG26zkzTpetqk0lAspHQugjne9FVQyYvUnn; Authentication-Results: sj-dkim-1.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: IETF SIP List , Paul H Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 26, 2006, at 1:00 PM, Jeroen van Bemmel wrote: > Cullen, > > >> >> Some (not all deployments) will have multiple devices registered >> to one AOR. The original draft had each device have it's own >> asymmetric key pair and if someone wanted to encrypt a message >> for the AOR, the message was encrypted with a symmetric key then >> the symmetric key was included in the message and encrypted with >> asymmetric keys for *every* device on that AOR. The WG decided >> this was not feasible and it would be better to have the devices >> share the asymmetric key so there was only one to deal with. >> > > I agree that this would not be feasible. I was thinking that for a > multi-device scenario where encryption (and not TLS) is required, > the "caller" could discover GRUUs for all currently registered > devices (eg using presence), select one (perhaps guided in some way > by preferences of the callee, say q-value ordering), and then > encrypt specifically for that device > > Slightly less flexible than having one cert per user, but better > than encrypting a symmetric key for each potential device as you > sketch above There had been some discussions of that, and I imagine this would work with the current draft as well. I think one of the problems with this is it involves revealing all my devices and if they are on line or not but I agree it sounds like another possible way to use this. On the using a GRUU in a cert, would need to consider that any time my GRUU changes I need to generate a new cert - if this meant a new private/public key pair, this might be expensive. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 30 09:57:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwJSv-0007iN-Qp; Fri, 30 Jun 2006 09:55:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwJSu-0007iI-CX for sip@ietf.org; Fri, 30 Jun 2006 09:55:24 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwJSt-00010q-3d for sip@ietf.org; Fri, 30 Jun 2006 09:55:24 -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 k5UDtJqH025602; Fri, 30 Jun 2006 08:55:19 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k5UDtG705529; Fri, 30 Jun 2006 08:55:19 -0500 (CDT) Message-ID: <44A52D44.5000400@lucent.com> Date: Fri, 30 Jun 2006 08:55:16 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Gardiner Subject: Re: [Sip] draft-ietf-sip-connect-reuse-05 References: <00D42150952F70458C66072322F7FE250B0A23@saturn2.Aculab.com> In-Reply-To: <00D42150952F70458C66072322F7FE250B0A23@saturn2.Aculab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org [... I will CC the SIP list, but I think any responses to this thread should migrate to sip-implementors, since the discussion is now heading towards implementation stratgies and not changes in the protocol itself ...] Matthew Gardiner wrote: > Thanks Vijay, > > I think you have allayed my fears regarding the race possibility. OK; thanks. > However, I think that to implement this connect-reuse scheme > correctly would require some fairly major changes to our, and perhaps > other peoples', SIP stacks. Maybe; however, a standard cannot dictate how a software implementation is constructed. All it can do is to ensure that those entities that do not support the feature being developed are not adversely affected. And connect-reuse does that. > As connection-oriented sockets are based on a stream of bytes, rather > than necessarily discrete packets, it makes them somewhat difficult > to associate with SIP transactions, particularly in programming > environments where socket processing, transaction management and > dialog management are delegated to individual worker threads. There are many ways to skin and de-bone this particular feline. You do not necessarily need to tie sockets to transaction processing if you do not want to. For instance, if a send of an INVITE succeeds, but the TLS thread detects that the socket has been closed, it could act dumb and do nothing. After T1*64s, for an INVITE transaction Timer B will fire. And you can do appropriate processing since you never received a final response to the INVITE. And so on... There is enough information in the transaction state machines to allow recovery even when TLS threads are decoupled from worker threads. Distilling this information into a specific software implementation will, of course, be a function of how the software is architected. Thanks. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 30 10:25:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwJuR-0003dt-UB; Fri, 30 Jun 2006 10:23:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwJuQ-0003dj-Nk for sip@ietf.org; Fri, 30 Jun 2006 10:23:50 -0400 Received: from mx0.aculab.com ([213.249.233.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwJuO-0001n5-9G for sip@ietf.org; Fri, 30 Jun 2006 10:23:50 -0400 Received: from localhost (localhost [127.0.0.1]) by mx0.aculab.com (Postfix) with ESMTP id 71A2A873A8 for ; Fri, 30 Jun 2006 15:23:47 +0100 (BST) Received: from mx0.aculab.com ([127.0.0.1]) by localhost (mx0.aculab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08138-05 for ; Fri, 30 Jun 2006 15:23:36 +0100 (BST) Received: from saturn2.Aculab.com (saturn [10.202.163.6]) by mx0.aculab.com (Postfix) with ESMTP id 2B90B8739C for ; Fri, 30 Jun 2006 15:23:36 +0100 (BST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-ietf-sip-connect-reuse-05 Date: Fri, 30 Jun 2006 15:23:34 +0100 Message-ID: <00D42150952F70458C66072322F7FE250B0A24@saturn2.Aculab.com> In-Reply-To: <44A52D44.5000400@lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-connect-reuse-05 Thread-Index: AcacTNxqUIdWcrYgQYKz7ICUvDpIigAAM0Gg From: "Matthew Gardiner" To: "Vijay K. Gurbani" X-Aculab-Com-Scanned: by amavisd-new-20030616-p10 (Debian) at aculab.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks Vijay, [ > but I think any responses to this thread should migrate to = sip-implementors Yes, maybe at some stage, I'll re-post to there, but as I started off = the posting here...] > a standard cannot dictate how a software implementation is = constructed. Yes, I agree, I just wanted to get clear whether the proposed standard = is actually realistic/feasible before undertaking the implementation. > You do not necessarily need to tie sockets to transaction processing = if you do not want to. I'm not sure that there is a practical alternative. See below... > After T1*64s, for an INVITE transaction Timer B will fire. And you = can do appropriate processing ... Yes, fair enough. However, this suggestion is unworkable, for instance = in a situation where the remote end dropped it's connection on a timer, = and is perfectly willing to accept to a new connection. If the = transaction was a reINVITE for hold, for example, the caller would be = left waiting for 32 seconds minimum, before the local stack fires Timer = B and decides it must initiate a new connection in order to place the = hold. As an implementator I'd want a better technique than this. thanks Matthew Gardiner=20 -----Original Message----- From: Vijay K. Gurbani [mailto:vkg@lucent.com] Sent: 30 June 2006 14:55 To: Matthew Gardiner Cc: IETF SIP List Subject: Re: [Sip] draft-ietf-sip-connect-reuse-05 [... I will CC the SIP list, but I think any responses to this thread should migrate to sip-implementors, since the discussion is now heading towards implementation stratgies and not changes in the protocol itself ...] Matthew Gardiner wrote: > Thanks Vijay, >=20 > I think you have allayed my fears regarding the race possibility. OK; thanks. > However, I think that to implement this connect-reuse scheme=20 > correctly would require some fairly major changes to our, and perhaps > other peoples', SIP stacks. Maybe; however, a standard cannot dictate how a software implementation is constructed. All it can do is to ensure that those entities that do not support the feature being developed are not adversely affected. And connect-reuse does that. > As connection-oriented sockets are based on a stream of bytes, rather > than necessarily discrete packets, it makes them somewhat difficult > to associate with SIP transactions, particularly in programming > environments where socket processing, transaction management and > dialog management are delegated to individual worker threads. There are many ways to skin and de-bone this particular feline. You do not necessarily need to tie sockets to transaction processing if you do not want to. For instance, if a send of an INVITE succeeds, but the TLS thread detects that the socket has been closed, it could act dumb and do nothing. After T1*64s, for an INVITE transaction Timer B will fire. And you can do appropriate processing since you never received a final response to the INVITE. And so on... There is enough information in the transaction state machines to allow recovery even when TLS threads are decoupled from worker threads. Distilling this information into a specific software implementation will, of course, be a function of how the software is architected. Thanks. - vijay --=20 Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 30 10:38:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwK7G-0006PF-Kg; Fri, 30 Jun 2006 10:37:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwK7E-0006OF-Hd for sip@ietf.org; Fri, 30 Jun 2006 10:37:04 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwK7D-0002KD-6z for sip@ietf.org; Fri, 30 Jun 2006 10:37:04 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 1BCF513F8AC; Fri, 30 Jun 2006 17:36:59 +0300 (EEST) Received: from rautu (guanine11.gprs.dnafinland.fi [62.78.120.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id B6B3F13F8A6; Fri, 30 Jun 2006 17:36:48 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id F2C34F03C1; Fri, 30 Jun 2006 17:37:00 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17573.14092.934500.154727@rautu.tutpro.com> Date: Fri, 30 Jun 2006 17:37:00 +0300 From: Juha Heinanen To: Rohan Mahy Subject: Re: [Sip] Ready for WGLC on Outbound? In-Reply-To: References: <8F3CFCB3-ED75-4747-AD8E-0A43DC6D8BAA@softarmor.com> <17570.15911.602096.876348@rautu.tutpro.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: IETF SIP List , Cullen Jennings , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Rohan Mahy writes: > Primary/Secondary terminology was completely removed from the Section > 4.2 of the -04 draft: yes, i received WGLC message before -04 message. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 30 10:39:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwK8M-00077I-DA; Fri, 30 Jun 2006 10:38:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwK8K-000773-Uq for sip@ietf.org; Fri, 30 Jun 2006 10:38:12 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwK8J-0002PH-MK for sip@ietf.org; Fri, 30 Jun 2006 10:38:12 -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 k5UEc4QF009409; Fri, 30 Jun 2006 09:38:04 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k5UEc4716424; Fri, 30 Jun 2006 09:38:04 -0500 (CDT) Message-ID: <44A5374C.7080102@lucent.com> Date: Fri, 30 Jun 2006 09:38:04 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Gardiner Subject: Re: [Sip] draft-ietf-sip-connect-reuse-05 References: <00D42150952F70458C66072322F7FE250B0A24@saturn2.Aculab.com> In-Reply-To: <00D42150952F70458C66072322F7FE250B0A24@saturn2.Aculab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Matthew Gardiner wrote: >> a standard cannot dictate how a software implementation is >> constructed. > > Yes, I agree, I just wanted to get clear whether the proposed > standard is actually realistic/feasible before undertaking the > implementation. There are implementations in the wild out there. I have implemented it, and at the last SIPit, there were 6 implementations reported. Plus some more that I am aware of through IETF hallway conversations and private emails. > Yes, fair enough. However, this suggestion is unworkable, for > instance in a situation where the remote end dropped it's connection > on a timer, and is perfectly willing to accept to a new connection. > If the transaction was a reINVITE for hold, for example, the caller > would be left waiting for 32 seconds minimum, before the local stack > fires Timer B and decides it must initiate a new connection in order > to place the hold. As an implementator I'd want a better technique > than this. True. I will answer this on a separate email CC'd to the sip-implementors list. Thanks. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 30 11:40:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwL4h-0004bR-UI; Fri, 30 Jun 2006 11:38:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwL4g-0004bM-LP for sip@ietf.org; Fri, 30 Jun 2006 11:38:30 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwL4f-0006Vd-6t for sip@ietf.org; Fri, 30 Jun 2006 11:38:30 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k5UFWvd11827; Fri, 30 Jun 2006 11:32:57 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Comments on draft-srivastava-sip-e2e-ciphersuites-00 || was RE: [Sip] Comments on draft-audet-sip-sips-guidelines Date: Fri, 30 Jun 2006 10:38:22 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60CFD9F1D@zrc2hxm2.corp.nortel.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301A5A3DE@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-srivastava-sip-e2e-ciphersuites-00 || was RE: [Sip] Comments on draft-audet-sip-sips-guidelines Thread-Index: AcaaxDyWHTYlRTVSQt2DeLPXjdsaLABlH1Pg From: "Samir Srivastava" To: "Michael Hammer \(mhammer\)" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1233728273==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1233728273== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69C5B.39AFEFE0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69C5B.39AFEFE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mike, =20 My answers below. IMHO, it's an important piece of work. Now we have much cleaner solution with Proxy-Require instead of mess of SIPS etc.=20 =20 I remember in wacky thread Paul Kyzivat mentioning that if SIPS etc so bad, why not we define a new clean solution. I request his comments on this approach. Hoping that Dave Oran who raised the question and Paul listening. =20 Thx Samir ________________________________ From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: Wednesday, June 28, 2006 8:05 AM To: sip@ietf.org Subject: [Sip] Comments on draft-audet-sip-sips-guidelines Samir, Read through the draft and had a few nits and comments. Nits:=20 Sec 3, 2) "need to use" -> MUST use?=20 page 4, top: "renegotiate" Will need UAC, Proxy, UAS sections in future draft. Comments: Option tag: e2e-ciphersuite: Include description of semantic for Supported header as well. When text is expanded these could be separate sub-sections. Suggestion: q-value should order the suites both by strength of algorithm/key size (first) and then by preference (second). Reason is to see degree of downgrade.=20 SS>> Will fix in the next version.=20 Via header should describe action that a proxy node MUST verify that the Via header added by the previous hop is valid, i.e. that it did in fact use the cipher named in the Via for the incoming link. May want to send a report directly back to the UAC Contact notifying of the compromise.=20 SS>> Will fix in the next version.=20 Not sure error code sent back would help. Not sure how this would work with IPSEC. The applications may not have as much control of the host or communication with it (cross-layer indicators). I could see the IPSEC cipher listed as a substitute. But, then the application needs to have a means to know if it is equivalent, unless it names those up front in the new header. For fairly well known systems (e.g. follows the ANSI Generic Security standard), this might be a managable list.=20 SS>> It's still an OPEN ISSUE. I need to consult IPSEC experts, on how difficult it is for application to get the info/control ?=20 Does IANA already have a registry of the exact string names used for each ciphersuite?=20 SS>> Will have more details on this, in the next version. Last half of second paragraph above Sec 4 should be in Sec 5 security considerations. Should also point out that this may not prevent a proxy from dropping out Security-Level header. Thought, should the cipher also be included in the Record-Route header? The UAC should approve the route set for continuing the call?=20 SS>> Good Catch. Will have discussions on this in the next version. The draft is a good start. Thanks for taking the ball and running with it. Mike ------_=_NextPart_001_01C69C5B.39AFEFE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Mike,
 
     My answers below. = IMHO, it's an=20 important piece of work. Now we have much cleaner solution with = Proxy-Require=20 instead of
mess of SIPS etc.
 
I remember in wacky thread  Paul Kyzivat = mentioning=20 that if SIPS etc so bad, why not we define a new = clean
solution. I request his comments on this = approach. Hoping=20 that Dave Oran who raised the question and Paul = listening.
 
Thx
Samir

From: Michael Hammer (mhammer)=20 [mailto:mhammer@cisco.com]
Sent: Wednesday, June 28, 2006 = 8:05=20 AM
To: sip@ietf.org
Subject: [Sip] Comments on=20 draft-audet-sip-sips-guidelines

Samir,

Read through = the draft and=20 had a few nits and comments.

Nits:

Sec 3, 2) "need to use" -> MUST use? =

page 4, top: "renegotiate"

Will need UAC, Proxy, UAS sections in future=20 draft.

Comments:

Option tag: e2e-ciphersuite: Include description = of=20 semantic for Supported header as well. When text is expanded these could = be=20 separate sub-sections.

Suggestion: q-value=20 should order the suites both by strength of algorithm/key size (first) = and then=20 by preference (second). Reason is to see degree of downgrade. 

SS>> Will=20 fix in the next version. 

Via header should describe action that a proxy = node MUST=20 verify that the Via header added by the previous hop is valid, i.e. that = it did=20 in fact use the cipher named in the Via for the incoming link. May want = to send=20 a report directly back to the UAC Contact notifying of the=20 compromise. 

SS>> Will fix in the next=20 version. 

Not sure error code sent back would = help.

Not sure how this would work with IPSEC. The = applications=20 may not have as much control of the host or communication with it = (cross-layer=20 indicators). I could see the IPSEC cipher listed as a substitute. But, = then the=20 application needs to have a means to know if it is equivalent, unless it = names=20 those up front in the new header. For fairly well known systems (e.g. = follows=20 the ANSI Generic Security standard), this might be a managable = list. 

SS>> It's = still an=20 OPEN ISSUE. I need to consult IPSEC experts, on how difficult = it is=20 for application to get the info/control ? 

Does IANA already have a registry of the exact = string=20 names used for each ciphersuite? 

SS>> Will have more = details on=20 this, in the next version.

Last half of second paragraph above Sec 4 should = be in Sec=20 5 security considerations. Should also point out that this may not = prevent a=20 proxy from dropping out Security-Level header. Thought, should the = cipher also=20 be included in the Record-Route header? The UAC should approve the route = set for=20 continuing the call? 

SS>> Good Catch. Will have = discussions on=20 this in the next version.

The draft is a good start. Thanks for taking the = ball and=20 running with it.

Mike

------_=_NextPart_001_01C69C5B.39AFEFE0-- --===============1233728273== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1233728273==-- From sip-bounces@ietf.org Fri Jun 30 13:01:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwMKt-0000rC-3T; Fri, 30 Jun 2006 12:59:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwMKs-0000r7-DS for sip@ietf.org; Fri, 30 Jun 2006 12:59:18 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwMKr-0005jh-4v for sip@ietf.org; Fri, 30 Jun 2006 12:59:18 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 30 Jun 2006 09:59:17 -0700 X-IronPort-AV: i="4.06,197,1149490800"; d="scan'208"; a="326796588:sNHT30755280" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k5UGxGFj031628; Fri, 30 Jun 2006 09:59:16 -0700 Received: from [192.168.1.2] (sjc-vpn2-416.cisco.com [10.21.113.160]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5UGxG9s004654; Fri, 30 Jun 2006 09:59:16 -0700 (PDT) In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F122E@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB594017F122E@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1C2968B0-0DFF-44D8-9312-44917A5AB0F0@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Ready for WGLC on Outbound? Date: Fri, 30 Jun 2006 09:59:14 -0700 To: Christer Holmberg ((JO/LMF)) X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=447; t=1151686756; x=1152550756; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Ready=20for=20WGLC=20on=20Outbound?; X=v=3Dcisco.com=3B=20h=3DBNXaX6KAw+VLAU+cTvGFj6l+5Xk=3D; b=CHicLzxP6d2mVWOxgXWCqp2bRxl0Ca2GlS2z5xessyrISfqFgVPrfohjoSAW2l9iTyR32ddn XNE5uaV8rvNE8tlhIlq3pkgsZUytV9TMrlHAnzzUeTtf9oKasHDa7g/d; Authentication-Results: sj-dkim-3.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: IETF SIP List , Rohan Mahy , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 30, 2006, at 3:25 AM, Christer Holmberg ((JO/LMF)) wrote: > "I think we should allow the STUN keepalives without the rest of the > stuff. Its a handy tool for inter-server keepalives in cases where > there > are no NAT or firewalls. I agree with this too. The question is how to get to easily get to this. If the answer is a separate document, by all means nothing in outbound stops a separate document from doing this. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 30 15:59:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwP76-00042b-Aq; Fri, 30 Jun 2006 15:57:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwP74-0003yk-4W for sip@ietf.org; Fri, 30 Jun 2006 15:57:14 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwP71-0002rK-EZ for sip@ietf.org; Fri, 30 Jun 2006 15:57:14 -0400 Received: from [192.168.1.4] (65-65-155-30.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5UJwptk011527 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 30 Jun 2006 14:58:52 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <4F4AE1C7-32F2-40FA-8E73-26015B7BB384@softarmor.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF SIP List From: Dean Willis Date: Fri, 30 Jun 2006 14:57:08 -0500 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Sip] Yet another revised agenda for SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Draft Agenda for SIP at IETF 66 Session 1, Monday 1300-1500 Room 520DEF Time Topic Discussion Leaders Reading List 1300 Agenda Bash, Announcements and Status Chairs This Doc 1305 Outbound Cullen Jennings draft-ietf-sip-outbound-04 1320 Outbound Discovery Miguel Garcia for Erkki Koivusalo draft-koivusalo-sip-outbound-discovery-02 1335 Outbound Midcall Issues Kevin Johns draft-johns-sip-outbound- middialog-draft-00 1340 Connection Reuse Vijay Gurbani Rohan Mahy draft-ietf-sip-connect-reuse-05 draft-gurbani-sip-domain-certs-01 1400 Location Conveyance James Polk draft-ietf-sip-location- conveyance-03 1415 SAML for SIP James Polk Hannes Tschofenig draft-ietf-sip-saml-00 1430 Certificates. Arboreal Rodents Or Fruitless Canine Vocalization? Jason Fischl draft-ietf-sip-certs-01 1445 Hop Limit Diagnostics Is my bunny sick? Scott Lawrence draft-ietf-sip-hop-limit- diagnostics-03.txt Session 2, Wednesday 1300-1500 Room 520ABC Time Topic Discussion Leaders Reading List 1300 Agenda Bash Chairs This Doc 1305 Connected Identity John Elwell draft-ietf-sip-connected-identity-00 draft-elwell-sip-tispan-connected-identity-01 1345 Identity Co-Existence Jonathan rosenberg draft-rosenberg-sip- identity-coexistence-00 1400 Security Flows Robert Sparks draft-ietf-sip-sec-flows-01 1410 Fork loop fix Robert Sparks draft-ietf-sip-fork-loop-fix-02 1420 Feature list for advance specification Robert Sparks TBD 1430 Hitchhiker's Guide Jonathan Rosenberg draft-ietf-sip-hitchhikers- guide-00 1445 SIPS: Guidelines Francois Audet draft-audet-sip-sips-guidelines-02 TBD Improved TLS Requirements Vijay Gurbani draft-gurbani-sip-sipsec-00 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 30 15:59:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwP7a-0004EK-DL; Fri, 30 Jun 2006 15:57:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwP7Y-0004EF-Kb for sip@ietf.org; Fri, 30 Jun 2006 15:57:44 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwP7X-0002uL-BV for sip@ietf.org; Fri, 30 Jun 2006 15:57:44 -0400 Received: from hkaplan [10.0.200.167] by acmepacket.com with ESMTP (SMTPD-9.03) id A2360590; Fri, 30 Jun 2006 15:57:42 -0400 From: "Hadriel Kaplan" To: "'Cullen Jennings'" , "'IETF SIP List'" Subject: RE: [Sip] Comments on rosenberg-sip-identity-coexistence Date: Fri, 30 Jun 2006 15:57:42 -0400 Message-ID: <017101c69c7f$72d773e0$a7c8000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <89DADC41-B196-4C12-B738-6B044E0E05C4@cisco.com> Thread-Index: AcabhAGDGAtd7eVaRZ+LFcZamZNsKAA7nihw X-Spam-Score: 1.2 (+) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Cullen, You sent a looong email so I'm splitting up my response. Inline... > From: Cullen Jennings [mailto:fluffy@cisco.com] > > I think one of the major reason for creating PAI was to provide > malicious call trace for anonymous calls. I don't think it was for > dealing with spoofing the From header. If that was the goal, we could > have solved it just by having device that ends up inserting the PAI > just reject any request that has spoofed From headers. I agree with you, but it is used for detecting suspicious From headers even for non-anonymous calls. Obviously if the proxy inserting the PAI _knows_ a >From is spoofed, it could/should reject it. But if the proxy does _not_ know whether the From is spoofed or not, it just doesn't insert the PAI. For example, ingress proxy receives a request from another domain - if it trusts the domain it passes the PAI (or inserts one). If it does not trust the domain, it removes PAI, but doesn't want to reject the request (else it wouldn't accept requests from such untrusted domains to begin with). > Small nit but ... I think identity was designed such that the UAS > domain proxy could do everything on behalf of the UAS as a migration > step. Clearly that is the point of the draft but the "called party > must be upgraded to support it" part I don't quite agree with. Same here - I always assumed ingress proxies/b2buas could be the ones doing identity verification without needing the final UAS to support it. And I assumed the egress proxy/b2bua could be the one doing the signing. So I assumed that everything in this new draft was possible before this draft, except the modified behavior to the UAS. In fact, I'm not sure I understand why the UAS needs to change or why the registrar needs to insert the id-coexist tag. If the UAS supports identity it will verify the identity; if it does not support identity it will use the PAI. If the UAS supports identity and the verification _fails_ because a b2bua changed something, then sure it may need to know it can use the PAI; but in such a case the b2bua could have just removed the identity and inserted PAI - why bother keeping both PAI+ID in the request if the b2bua knows it has screwed up the identity check, but did verified it on its own? Well, I guess you'd need to, to get Identity-expecting UASs to accept a bad or missing one as ok if there's a PAI, but that seems a bad idea to me. (though I don't know why, just seems wrong) > My last small nit .... I've sent several posts about why I think > B2BUA work with Identity in a large percentage of the cases. I think > this draft seems like a great place to explain all this - both what > works and what does not. I don't buy into the statement that Identity > breaks B2BUAs. I haven't seen those emails. (I searched) Can you send me a link? (It's certainly not that Identity breaks b2buas, but b2buas may break Identity in some cases. ;) -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 30 16:27:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwPYn-0006Nr-Me; Fri, 30 Jun 2006 16:25:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwPYm-0006Nm-05 for sip@ietf.org; Fri, 30 Jun 2006 16:25:52 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwPYk-00053t-M4 for sip@ietf.org; Fri, 30 Jun 2006 16:25:51 -0400 Received: from [192.168.1.4] (65-65-155-30.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k5UKRU2V011663 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 30 Jun 2006 15:27:31 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <93946F5D-56E9-466E-B444-CE19BFFF2E49@softarmor.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF SIP List From: Dean Willis Date: Fri, 30 Jun 2006 15:25:48 -0500 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [Sip] Proposals for review process to conclude WGLCs X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org One of the questions we've struggled with is how to get sufficient review on a document under WGLC to make sure it's really done. SIPPING is following a new procedure with designated reviewers, doing review by email, and sending stuff back to the. Apparently this suffers from the expected issues, with designated reviewers sometimes not quite meeting their review commitments. Cisco made me take a peer-review refresher class the other day, so this started me thinking about some alternatives. In the model taught in this class, each peer review includes 1) a "moderator" or "reader" who frames the questions and keeps things on track, 2) a "recorder" who records conclusions and issues raised during the review, 3) the author(s), who neither presents no interprets the work, but does respond to specific questions about it, and 4) the reviewers, who hopefully have expertise and have committed time to the review. I'd like to propose a couple of alternative models to what SPPING has been doing and seeing if either resonates with our group. 1) Real-time review sessions via conference call: When we get ready to do a final review, the chairs assemble a review team. Presumably, this review team is assembled by polling the list for volunteers, and by pushing extra hard for stakeholders and other people with specific expertise. The moderator builds up a checklist and set of basic questions to consider, and distributes it to the review team. At a tiem agreed to by enough of the participants, we have a conference call, not to exceed two hours, and work through the checklist in a moderated fashion. At the conclusion of that two hours, we either reach a positive decision, a negative decision (with list of issues and actions), or decide we need more review. 2) Moderated email-review, using the entire list as the "review team". In this model, the chairs pick a moderator and recorder for the review. The moderator sets up a checklist and sends it to the list, along with an announcement of the review. The moderator then goes through the checklist item-by-item on list, polling for comments. The recorder records any issues or conclusions. Each item might take two or three days for primary comments, but could be revisited during the review process if needed. The author could answer specific questions about the draft, but not paraphrase or interpret. At the conclusion of the review, the moderator and reviewer would report to the chairs, who would decide whether we have issues, a conclusion, or need further review. What do y'all think? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 30 18:01:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwR1M-0004Qh-1q; Fri, 30 Jun 2006 17:59:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwR1K-0004Qc-Sx for sip@ietf.org; Fri, 30 Jun 2006 17:59:26 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwR1J-000339-EL for sip@ietf.org; Fri, 30 Jun 2006 17:59:26 -0400 Received: from hkaplan [10.0.200.167] by acmepacket.com with ESMTP (SMTPD-9.03) id AEBC019C; Fri, 30 Jun 2006 17:59:24 -0400 From: "Hadriel Kaplan" To: "'Cullen Jennings'" , "'Jonathan Rosenberg'" , "'IETF SIP List'" Subject: RE: [Sip] Comments on rosenberg-sip-identity-coexistence Date: Fri, 30 Jun 2006 17:59:24 -0400 Message-ID: <017c01c69c90$73269590$a7c8000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <89DADC41-B196-4C12-B738-6B044E0E05C4@cisco.com> Thread-Index: AcabhAGDGAtd7eVaRZ+LFcZamZNsKAA+3ROg X-Spam-Score: 1.2 (+) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org More inline... > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > > case 2) ingress B2B on terminating domain - this is fairly easy too. > This B2BUA resigns the incoming request. To do this it uses a cert > that has a wildcard for all domain - the UAS need to be configured to > have this cert in it root trust list. What the UAS is doing here is > delegating that it trust any name that the > B2BUA trusts. This is the sort of trust delegation one wants to be > able to make. I don't know how practical that is to do on the UASs. It seems to me like most UASs simply trust whatever their proxy tells them, and that should be ok if we can guarantee what their proxy tells them is true. (a big IF) If a b2bua before that proxy but in the same trust domain verified the identity, and can somehow tell the proxy it verified the identity, and even tell the UAS it did as well, why do more? That's what the PAI does. It may not be what it was supposed to do, but it's what it seems to now. > case 3) a B2BUA in a transit provider between the originating and > terminating domain. There are two very different cases here - one is > where the transit provider is an intermediate in providing PSTN > termination services and using E.164 addresses. For example some > company, contracts its PSTN termination from say MCI who for numbers > in Australia perhaps uses Telstra. The company wants to see the phone > number asserted by MCI, not Telstra - it is MCI they trust and can > make an authorization decision based on. They have no idea who > Telstra is so whatever telstra wants to claim is useless for the > company. The point is, whatever things Telstra might assert to MCI, > the company wants MCI to make an assertion that the company can use > for it authorization decision. In these cases the transit B2BUA needs > to resign things. And that's the rub. The real use/value of Identity, IMHO, is for the transit case - period. Within a domain or between just 2, and there are other ways to trust, except for the really paranoid. But the longer the trust chain of transits is, the greater the probability the chain is broken. When I looked at the original identity draft I thought ok - the b2bua/proxy egress can be the signer and the ingress b2bua/proxy can be the verifier. Of course then I immediately thought if the 2 domains are connected by just those 2 elements, why bother doing the signing/verifying for a single hop that is going to be TLS/IPSEC anyway?? Use the PAI you already have. But for transit cases: it requires the transit domain(s) to either (1) not muck with contact, call-id, and bodies, or (2) support identity, and to somehow re-sign with something that the verifier in the next domain(s) will accept, which goes back to hop-by-hop trust kinda. But changing (1) or (2) is out of the local (and final) domain's control to change - they need the transit domain(s) to change, and that's a much bigger hurdle. > As a last note, I do think there are workable solutions for the B2BUA > case. Having UA accept message with a bad Identity header but that > have a PAI seriously breaks Identify. One of the key things that > Identity provides is a close to end to end integrity for the bodies. Yes, it signed the body, and contact, but I consider that its fatal flaw. It should have stuck with the From (and Date and whatever else it thinks is needed for a reasonable nonce). The body I know is a hard one to not sign (it's so tempting!). But sign the contact? What does that have to do with identity? > This breaks this and we have no other good way to provide this. What > I am suggesting above provides a way to keep this integrity property > so that no device can tamper with the integrity other than devices > that the UAS or UAC explicitly trusts to tamper with the integrity. I > think this is a fairly important property and achievable. What about just splitting it into 2 Identity headers/signatures? One for the From and nonce-ish stuff, the other for the body and same nonce-ish stuff. If a middle-man wants to modify the body, he verifies and re-signs that second signature, or if the middle-man is unaware of identity then the next one can decide what to do with a bad signature for a body but good signature for From. So when the final UAS gets it (or its domain verifier) she says "hmmm... the >From was definitely signed by the URI domain company.com, but this body is signed by provider.com who I trust... ok, I can trust that", vs. "I see company.com signed the From but the body was broken... this is suspicious". This way a b2bua can change the body but doesn't have to have a certificate matching the From-uri domain to do so, and the UAS can decide if it's kosher for the b2bua-domain to change the body, while also verifying the From is of the right domain. I haven't thought it through, but it sounds ok. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 30 20:24:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwTFf-0007oL-PM; Fri, 30 Jun 2006 20:22:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwTFe-0007oG-9a for sip@ietf.org; Fri, 30 Jun 2006 20:22:22 -0400 Received: from py-out-1112.google.com ([64.233.166.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwTFd-0004w6-2n for sip@ietf.org; Fri, 30 Jun 2006 20:22:22 -0400 Received: by py-out-1112.google.com with SMTP id b36so823145pyb for ; Fri, 30 Jun 2006 17:22:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=q9vspR4wUv0pYVQgnRTW7JPtnR/7Wb8xbIxqLhIBvCA7MSasH+jP9/jGJtqoNgfes4DdUzJT4ZhaVYSk8joGuDABbXHyYRH/CiPFPN3CA3Wm6HgCHt2YbEhCvNc+EnEht+ajIOTPSQCfTlzC4xjnHqaxWw+0NxUyzBcVuUbXdwk= Received: by 10.35.134.12 with SMTP id l12mr993483pyn; Fri, 30 Jun 2006 17:22:20 -0700 (PDT) Received: by 10.35.100.4 with HTTP; Fri, 30 Jun 2006 17:22:20 -0700 (PDT) Message-ID: <9d6632e0606301722x527cf53y441dce63c35f2f26@mail.gmail.com> Date: Fri, 30 Jun 2006 19:22:20 -0500 From: Joe To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Sip] SIP Transport Selection Question X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0838820943==" Errors-To: sip-bounces@ietf.org --===============0838820943== Content-Type: multipart/alternative; boundary="----=_Part_38775_20215210.1151713340527" ------=_Part_38775_20215210.1151713340527 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Under the Clients section 3261 states: "If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914 congestion controlled transport protocol, such as TCP." Is this for "requests" (INVITE, etc.) only? What if an INVITE were sent as UDP but a response (200 OK) were to come back with extra headers which breached the MTU? Must the node sending the OK switch the transport to TCP? Is this optional? Regards, Joe ------=_Part_38775_20215210.1151713340527 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Under the Clients section 3261 states:

"If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914 congestion controlled transport protocol, such as TCP."

Is this for "requests" (INVITE, etc.) only? What if an INVITE were sent as UDP but a response (200 OK) were to come back with extra headers which breached the MTU? Must the node sending the OK switch the transport to TCP? Is this optional?

Regards,
Joe
------=_Part_38775_20215210.1151713340527-- --===============0838820943== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0838820943==--
TimeTopicDiscussion LeadersReading List
1300Agenda BashChairsThis = Doc
1305Connected = IdentityJohn Elwelldraft-ietf-sip-connected-identity-00
1330John Elwelldraft-elwell-sip-tispan-connected-identity-01
1345Identity = Co-ExistenceJonathan = rosenbergdraft-rosenberg-sip-identity-coexistence-00
1400Security = FlowsRobert Sparksdraft-ietf-sip-sec-flows-01
1410Robert = Sparksdraft-ietf-sip-fork-loop-fix-02
1420Robert SparksTBD
Hitchhiker's = GuideJonathan = Rosenbergdraft-ietf-sip-hitchhikers-guide-00
1445Francois = Audetdraft-audet-sip-sips-guidelines-02
TBDImproved TLS RequirementsVijay Gurbanidraft-gurbani-sip-sipsec-00