From sip-bounces@ietf.org Sat Apr 01 00:03:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPYFL-0008H8-Ai; Sat, 01 Apr 2006 00:01:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPYFJ-0008H3-Qx for sip@ietf.org; Sat, 01 Apr 2006 00:01:57 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPYFI-00030k-GP for sip@ietf.org; Sat, 01 Apr 2006 00:01:57 -0500 Received: from [192.168.0.105] ([71.240.162.175]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k3151tAZ019106 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 31 Mar 2006 23:01:55 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <475FF955A05DD411980D00508B6D5FB012748E5D@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB012748E5D@en0033exch001u.uk.lucent.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] draft-ietf-sip-fork-loop-fix Date: Fri, 31 Mar 2006 23:01:52 -0600 To: "Drage, Keith (Keith)" X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (nostrum.com: 71.240.162.175 is authenticated by a trusted mechanism) 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 draft-ietf-sip-fork-loop-fix-01 has been submitted to the repository. Until it shows up there, you can find it at: http://www.nostrum.com/~rjsparks/draft-ietf-sip-fork-loop-fix-01.txt Based on the discussions in the SIPPING meeting after Keith's note below was sent, I have NOT changed the strength of the requirement to use the algorithm in 3261 as indicated below. This new version of the draft leaves the requirement at SHOULD. I added text noting that branches to destinations created using outbound are known not to loop and thus will satisfy the "MUST ensure the request does not loop" requirement without performing additional loop detection. The wording is chosen to keep the new reference to outbound informative. I removed the reference to the alternate loop detection algorithm being discussed in SIPPING. I also corrected several spelling errors and changed "in the wild" to something hopefully easier to translate. This draft passes the idnits tool's checks. I believe it is ready for last call once it appears in the repository. Thanks, RjS On Mar 22, 2006, at 2:45 PM, Drage, Keith (Keith) wrote: > (as chair) > > The face-to-face sip session in ietf 65 identified that draft-ietf- > sip-fork-loop-fix is ready as follows. > > WGLC/Publish this draft at current scope (loop detection only) > Continue discussions on other potential improvements as separate > efforts > > Robert will update the draft for resubmission as -01 early next > week with the following changes (plus some nit fixes): > > change 1: SHOULD use 3261 loop detection will change to MAY > change 2: branches to connections created using the outbound mechanism > won't count towards requiring loop detection. That is, loop > detection will be MUST if retargetting to more than one > branch > that is not a connection established with outbound. > > If any members of the WG believe that this draft, with the > identified revisions, is not ready to move to WGLC, then please > identify this to the list, giving appropriate reasons for your > opinion. > > Additionally, if there are any NITS or other issues you have > noticed that need fixing, then please send them quickly to the list > or the authors as appropriate in order that the version going for > WGLC includes as many fixes as possible. > > regards > > Keith, Dean > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 01 03:29:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPbS8-000898-Jo; Sat, 01 Apr 2006 03:27:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPbS7-000893-1h for sip@ietf.org; Sat, 01 Apr 2006 03:27:23 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPbS5-0002b4-Mc for sip@ietf.org; Sat, 01 Apr 2006 03:27:23 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k318RCu11304; Sat, 1 Apr 2006 03:27:12 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-ietf-sip-fork-loop-fix Date: Sat, 1 Apr 2006 02:27:08 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60B3CA5E0@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-fork-loop-fix Thread-Index: AcZVSZV9E93HCROKQMis8g+HlBh0vwAGoTXg From: "Samir Srivastava" To: "Robert Sparks" , "Drage, Keith \(Keith\)" 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 These loops are caused by bad registrations at different proxies. Can we change our registration process to fix this ? At the Receipt of REGISTER, Registrar returns "202 Accepted" and then it runs loop-detect (with=20 Incrementing MAX-FORWARDS) and if there is loop caused or not, it uses the Register event package to tell the outcome of audit. The above audit is needed only when new registration are added, these audits are not needed for refresh and unregistration. The above is needed when Follow me kind of service is implemented with registration.=20 This will not require any stuff with node Id etc for each transaction including retransmissions etc. When routes are added Administratively, there also it can be applied. If they are using any regular expression etc, then Administrator should take care of loop with loop-detect tool to verify the routes. Thx Samir -----Original Message----- From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 Sent: Friday, March 31, 2006 9:02 PM To: Drage, Keith (Keith) Cc: sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-fork-loop-fix draft-ietf-sip-fork-loop-fix-01 has been submitted to the repository. Until it shows up there, you can find it at: http://www.nostrum.com/~rjsparks/draft-ietf-sip-fork-loop-fix-01.txt Based on the discussions in the SIPPING meeting after Keith's note below was sent, I have NOT changed the strength of the requirement to use the algorithm in 3261 as indicated below. This new version of the draft leaves the requirement at SHOULD. I added text noting that branches to destinations created using outbound are known not to loop and thus will satisfy the "MUST ensure the request does not loop" =20 requirement without performing additional loop detection. The wording is chosen to keep the new reference to outbound informative. I removed the reference to the alternate loop detection algorithm being discussed in SIPPING. I also corrected several spelling errors and changed "in the wild" to something hopefully easier to translate. This draft passes the idnits tool's checks. I believe it is ready for last call once it appears in the repository. Thanks, RjS On Mar 22, 2006, at 2:45 PM, Drage, Keith (Keith) wrote: > (as chair) > > The face-to-face sip session in ietf 65 identified that draft-ietf-=20 > sip-fork-loop-fix is ready as follows. > > WGLC/Publish this draft at current scope (loop detection only)=20 > Continue discussions on other potential improvements as separate=20 > efforts > > Robert will update the draft for resubmission as -01 early next week=20 > with the following changes (plus some nit fixes): > > change 1: SHOULD use 3261 loop detection will change to MAY change 2:=20 > branches to connections created using the outbound mechanism > won't count towards requiring loop detection. That is, loop > detection will be MUST if retargetting to more than one=20 > branch > that is not a connection established with outbound. > > If any members of the WG believe that this draft, with the identified=20 > revisions, is not ready to move to WGLC, then please identify this to=20 > the list, giving appropriate reasons for your opinion. > > Additionally, if there are any NITS or other issues you have noticed=20 > that need fixing, then please send them quickly to the list or the=20 > authors as appropriate in order that the version going for WGLC=20 > includes as many fixes as possible. > > regards > > Keith, Dean > > 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=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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 01 04:22:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPcH4-0002mO-2h; Sat, 01 Apr 2006 04:20:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPcH2-0002kE-Je for sip@ietf.org; Sat, 01 Apr 2006 04:20:00 -0500 Received: from smtp1.versatel.nl ([62.58.50.88] helo=smtp3.versatel.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPcH1-00066N-6f for sip@ietf.org; Sat, 01 Apr 2006 04:20:00 -0500 Received: (qmail 20713 invoked by uid 0); 1 Apr 2006 09:19:58 -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 < >; 1 Apr 2006 09:19:58 -0000 Message-ID: <002501c6556d$6f600dc0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Patrick Timmons" , "'Hadriel Kaplan'" , "'Cullen Jennings'" , "'Dean Willis'" , References: <00fb01c6552b$f0bef940$800101df@acmepacket.com> Subject: Re: [Sip] How to indicate during proxy discovery thataproxysupports"outbound" Date: Sat, 1 Apr 2006 11:19:53 +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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: '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 Patrick, > However -- in a general sense, the issue here is that the UA needs to know > specific features as they pertain to the topology of the network; i.e., > that > the *edge* supports 'outbound'. My sense is that it's perfectly > reasonable > to think that there will be requirements for UAs to know specific features > of proxies that sit topologically off of the edge (?-CSCF, for example). > In > this case, the Proxy-Require technique breaks down... and we're left with > supporting two different methods for achieving (essentially) the same > ends. True, but this also goes for OPTIONS. To send an OPTIONS to the second hop, the UAC must not only be aware of the topology, but also of the routing logic at the first hop (i.e. second hop for REGISTER might be different than INVITE). For IMS it would be impossible (due to e.g. topology hiding, the UAC wouldn't be able to learn the hostname / IP address of the S-CSCF for example) but also for non-IMS networks this would simply not work. And beyond the second hop, things would get "exponentially" more complicated. For first hop only, both OPTIONS and Proxy-Require seem reasonable to me, with a slight preference for the latter. As a more general solution I suggest feature tags in the Path / Record-Route headers (as header parameters - not URI parameters - to avoid clobbering each mid-dialog request with them). Given the time constraints for outbound (Keith's deadline was yesterday...), I propose to agree on a first-hop-only solution for outbound, and leave generalization for future work. 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 Apr 01 13:15:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPkb0-0001ek-NX; Sat, 01 Apr 2006 13:13:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPkax-0001ec-RY for sip@ietf.org; Sat, 01 Apr 2006 13:13:07 -0500 Received: from test-iport-3.cisco.com ([171.71.176.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPkaw-00025A-I0 for sip@ietf.org; Sat, 01 Apr 2006 13:13:07 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by test-iport-3.cisco.com with ESMTP; 01 Apr 2006 10:13:06 -0800 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k31ID51j010553; Sat, 1 Apr 2006 10:13:05 -0800 (PST) Received: from 10.21.97.234 ([10.21.97.234]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sat, 1 Apr 2006 18:13:05 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Sat, 01 Apr 2006 10:13:05 -0800 Subject: Re: [Sip] Update to RFC3329, aka Security Agreement From: Cullen Jennings To: Aki Niemi , "sip@ietf.org" Message-ID: Thread-Topic: [Sip] Update to RFC3329, aka Security Agreement Thread-Index: AcZVt+vLKknEncGrEdq8VQARJEEJ/A== In-Reply-To: <441F4836.5050107@nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 we should try and get these fixes available to implementers one way or another - I might be tempted to try and write it as errata and if it got too large, do a bis. I don't have any strong preferences other than, lets do something to help implementers get this right. My knee jerk reaction with very little thought is to prefer a backwards compatible solution to the computation of the digest-verify. (or at least something that is backwards compatible with the majority of implementation - it people did different things it may be impossible to be backwards compatible with everyone) Cullen On 3/20/06 6:26 PM, "Aki Niemi" wrote: > All, > > During the past couple of years, there have been a few reported issues > on RFC 3329, based on implementation experience. > > I've gathered the set of issues in an I-D: > http://www.ietf.org/internet-drafts/draft-niemi-rfc3329-issues-00.txt > > We've already talked about rfc3329bis among the authors, and we feel > this would be appropriate in order to straighten out the issues and > improve interop. Any comments are welcome. > > 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 Sat Apr 01 13:24:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPkjq-0005TJ-TQ; Sat, 01 Apr 2006 13:22:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPkjo-0005TD-KF for sip@ietf.org; Sat, 01 Apr 2006 13:22:16 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPkjn-0002R0-A8; Sat, 01 Apr 2006 13:22:16 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by test-iport-1.cisco.com with ESMTP; 01 Apr 2006 10:22:14 -0800 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k31IMEYg016413; Sat, 1 Apr 2006 10:22:14 -0800 (PST) Received: from 10.21.97.234 ([10.21.97.234]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Sat, 1 Apr 2006 18:22:14 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Sat, 01 Apr 2006 10:22:13 -0800 Subject: Re: [Sip] Latest draft for SDP extensions in SIP IM From: Cullen Jennings To: Anil Bollineni , , "sip@ietf.org" Message-ID: Thread-Topic: [Sip] Latest draft for SDP extensions in SIP IM Thread-Index: AcZIZi61fBe1U24QQja3ZB+QXfordQNUwO61 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 Have a look at draft-ietf-simple-message-sessions-14 On 3/15/06 11:25 AM, "Anil Bollineni" wrote: > Hi, > > I want to know what is latest draft/rfc for indicating SDP extensions in SIP > IM call flows. I foudn this draft draft-ietf-simple-im-sdp-00, but it is old. > > Thanks in Advance, > -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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 01 14:26:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPliM-0006IS-4H; Sat, 01 Apr 2006 14:24:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPliK-00066g-RG for sip@ietf.org; Sat, 01 Apr 2006 14:24:48 -0500 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPlZL-0004Bg-GD for sip@ietf.org; Sat, 01 Apr 2006 14:15:32 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 09A446C01C for ; Sat, 1 Apr 2006 14:15:30 -0500 (EST) Subject: RE: [Sip] draft-ietf-sip-fork-loop-fix From: "Dale R. Worley" To: Sip In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60B3CA5E0@zrc2hxm2.corp.nortel.com> References: <62B9B0847CC47543B6B3B5E26BD268E60B3CA5E0@zrc2hxm2.corp.nortel.com> Content-Type: text/plain Date: Sat, 01 Apr 2006 14:15:30 -0500 Message-Id: <1143918930.2733.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: 79899194edc4f33a41f49410777972f8 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Sat, 2006-04-01 at 02:27 -0600, Samir Srivastava wrote: > These loops are caused by bad registrations at different proxies. Can we > change our registration process to fix this ? > > At the Receipt of REGISTER, Registrar returns "202 Accepted" and then it > runs loop-detect (with > Incrementing MAX-FORWARDS) and if there is loop caused or not, it uses > the Register event package to tell the outcome of audit. It might be better to not reject the REGISTER, since later actions might cure the loop without altering *this* registration. (Also, since a rejected registration is not in the database, the next re-registration attempt also appears to be new, and triggers the loop test again.) But we could add an element to the register event package to report the outcome of a loop-detection audit. 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 Apr 01 15:52:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPn2w-0004kC-U8; Sat, 01 Apr 2006 15:50:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPn2u-0004iq-UM for sip@ietf.org; Sat, 01 Apr 2006 15:50:08 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPn2t-0007w5-Ku for sip@ietf.org; Sat, 01 Apr 2006 15:50:08 -0500 Received: from [206.176.144.210] (206-176-144-210.waymark.net [206.176.144.210]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k31KoeeO025400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Apr 2006 14:50:41 -0600 Message-ID: <442EE77A.7060402@softarmor.com> Date: Sat, 01 Apr 2006 14:50:02 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Penfield Subject: Re: [Sip] How to indicate during proxy discovery thataproxysupports"outbound" References: <008801c654fd$38866a30$800101df@acmepacket.com><003601c65501$cc44d870$31713b51@BEMBUSTER> <001b01c65518$f9222b60$800101df@acmepacket.com> In-Reply-To: <001b01c65518$f9222b60$800101df@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: 'Cullen Jennings' , sip@ietf.org, 'Juha Heinanen' , Patrick Timmons X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Bob Penfield wrote: > I had the same thought about proxies eating Proxy-Require values. But > then prompted by Jeroen's mention of RFC 3329, I took a look and found > this in Section 2.3.1 on page 8. > > .... and the server is a proxy, it MUST remove the > "sec-agree" value from both the Require and Proxy-Require header > fields, and then remove the header fields if no values remain. > > I seems reasonable to me that an extension that would use a > Proxy-Require tag might only apply to the first-hop proxy, as is the > case with Security Agreement and outbound (for the edge proxy behavior). > It also seems reasonable to me that if no other proxies along the path > need to understand the extension, that the proxy doing the extension > could remove the tag from the Proxy-Require header. > > Given the precedent set in RFC 3329, we should consider that option. For > outbound, we need two option tags. One which corresponds to the > first-hop edge proxy behavior (i.e. the STUN ping) that would be in a > Proxy-Require header, and one which corresponds to the registrar > behavior (sip-instance and reg-id's) that would be in the Require header. That's a good point, Bob. Thanks to you and Jeoen for the careful reading. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Apr 01 17:50:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPot8-0001q9-Vs; Sat, 01 Apr 2006 17:48:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPot6-0001ni-Dx for sip@ietf.org; Sat, 01 Apr 2006 17:48:08 -0500 Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56] helo=zrtps0kp.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPot4-00042b-3r for sip@ietf.org; Sat, 01 Apr 2006 17:48:08 -0500 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 k31Mm3q27820; Sat, 1 Apr 2006 17:48:03 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-ietf-sip-fork-loop-fix Date: Sat, 1 Apr 2006 16:47:58 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60B3CA638@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-fork-loop-fix Thread-Index: AcZVwiCS/BJ3F9fMSMqy4WKuzL51SAAGPqzQ From: "Samir Srivastava" To: "Dale R. Worley" , "Sip" X-Spam-Score: 0.1 (/) 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 Dale, See in line. Thx Samir -----Original Message----- From: Dale R. Worley [mailto:dworley@pingtel.com]=20 Sent: Saturday, April 01, 2006 11:16 AM To: Sip Subject: RE: [Sip] draft-ietf-sip-fork-loop-fix On Sat, 2006-04-01 at 02:27 -0600, Samir Srivastava wrote: > These loops are caused by bad registrations at different proxies. Can=20 > we change our registration process to fix this ? >=20 > At the Receipt of REGISTER, Registrar returns "202 Accepted" and then=20 > it runs loop-detect (with Incrementing MAX-FORWARDS) and if there is=20 > loop caused or not, it uses the Register event package to tell the=20 > outcome of audit. It might be better to not reject the REGISTER, since later actions might cure the loop without altering *this* registration. (Also, since a rejected registration is not in the database, the next re-registration attempt also appears to be new, and triggers the loop test again.) SS>> Only later *UnRegistration or expired contact* can break the loop. Proxy P1 is still going to forward Proxy P2, where looped contact is gone for now, and request is not going to fullfilled with proxy P1 contact. So it good to reject this registration. And let the Registering end point figure out where is the loop. If an endpoint keeps registering again and again with looped causing contacts, trigger this to IPS/IDS and take out the endpoint. This is very similar to how repeated 401/407 are handled. I re-iterate the problem is with bad registrations, so it should be fixed there instead of adding additional loop detection logic at each node, with node Id, breadth to contain damage etc. If there are third party registration allowed, then we don't need to run MAX-FORWARD logic. Proxy P1 can query proxy P2 for the contact in question. This brings a point, there are two properties in third party registration one querying (which we need here) and another adding/modifying registration. And unfortunately we have both clumbed together currently. But we could add an element to the register event package to report the outcome of a loop-detection audit. SS>> Okay. 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 Apr 02 11:03:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQ451-0000bH-2x; Sun, 02 Apr 2006 11:01:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQ450-0000bC-2s for sip@ietf.org; Sun, 02 Apr 2006 11:01:26 -0400 Received: from bzq-25-94-44.cust.bezeqint.net ([212.25.94.44] helo=isr-jlm-mail.Kayote.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQ44y-0002g2-N1 for sip@ietf.org; Sun, 02 Apr 2006 11:01:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-tschofenig-sip-saml-05.txt Date: Sun, 2 Apr 2006 18:01:22 +0300 Message-ID: <1DDB0D3CC4E7F14FAE946361C0A6065573B8D3@isr-jlm-mail.Kayote.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-tschofenig-sip-saml-05.txt Thread-Index: AcZQ8gzLeMD1xx1AT8SDWKaXhnom5QFbYECw From: "David Schwartz" To: "Drage, Keith \(Keith\)" , X-Spam-Score: 0.1 (/) 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 Hi Keith. I would like to hum on this being adopted as a baseline for the "Using = SAML for SIP" milestone. This work has been invaluable to me in my work on SPIT related = attributes. In addition, SIP SAML provides a framework that can be = leveraged in many higher-level end-to-end or peering scenarios. This = draft is instructive in proper application of SAML to the SIP = application space and in the definition of the appropriate SAML = profiles. In fact I believe that the application of SAML profiles such = as those described in this draft will be used in other peering WG's such = as SPEERMINT. Thanks David Schwartz -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 Sent: =E0 26 =EE=F8=F5 2006 18:25 To: sip@ietf.org Subject: [Sip] draft-tschofenig-sip-saml-05.txt (As chair) At the face-to-face meeting at IETF#65, we discussed = http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-05.txt as = a possible solution to the current milestone on "Using SAML for SIP = (PS)". We are seeking a list hum on whether this draft should be adopted as = baseline for this draft, or whether we should seek some other baseline = input. regards Keith Keith Drage drage@lucent.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 Sun Apr 02 15:08:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQ7u0-0008I0-0f; Sun, 02 Apr 2006 15:06:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQ7tz-0008Hv-Hg for sip@ietf.org; Sun, 02 Apr 2006 15:06:19 -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 1FQ7ty-00052a-5r for sip@ietf.org; Sun, 02 Apr 2006 15:06:19 -0400 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id A0A80284; Sun, 02 Apr 2006 15:06:16 -0400 From: "Hadriel Kaplan" To: Subject: RE: [Sip] How to indicate during proxy discovery thataproxysupports"outbound" Date: Sun, 2 Apr 2006 15:06:21 -0400 Message-ID: <029401c65688$87fcf200$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZVbXBEg+aBbD2FTi2+ROdp3zQ35ABEI5NQ In-Reply-To: <002501c6556d$6f600dc0$31713b51@BEMBUSTER> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) 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 I agree using Proxy-Require (and Require) is the best approach for this draft. Also, RFC 3323 Privacy does it: When the privacy service removes the entire Privacy header, if the message is a request, the privacy service MUST also remove any 'privacy' option-tag from the Proxy-Require header field of the request. Do we have consensus? I can write up some text if you wish. -hadriel > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: Saturday, April 01, 2006 4:20 AM > > Given the time constraints for outbound (Keith's deadline was > yesterday...), > I propose to agree on a first-hop-only solution for outbound, and leave > generalization for future work. > > 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 Sun Apr 02 18:48:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQBLL-0001qh-Uu; Sun, 02 Apr 2006 18:46:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQBLL-0001qb-5c for sip@ietf.org; Sun, 02 Apr 2006 18:46:47 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQBLI-0005wU-Ka for sip@ietf.org; Sun, 02 Apr 2006 18:46:47 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 198CD4F0001; Mon, 3 Apr 2006 00:46:44 +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, 3 Apr 2006 00:46:43 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 00:46: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] draft-ietf-sip-outbound Date: Mon, 3 Apr 2006 00:46:43 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1C4E@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-outbound Thread-Index: AcZU/Vf/giiA3jIhSd2B5e4lAgv9wgBe+TBg From: "Christer Holmberg \(JO/LMF\)" To: "Adam Roach" X-OriginalArrivalTime: 02 Apr 2006 22:46:43.0219 (UTC) FILETIME=[503AB630:01C656A7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 Why shall I put together a summary of what has been discussed at the meeting??? Isn't that what we ask for a volunteer (normally someone who actually physically participate at the meeting) to do??? Now, as Dean wrote, there weren't that much technical discussions about this at the meeting before the vote. A clear and simple answer. Regards, Christer -----Original Message----- From: Adam Roach [mailto:adam@estacado.net]=20 Sent: 31. maaliskuuta 2006 22:57 To: Christer Holmberg (JO/LMF) Cc: Drage, Keith (Keith); sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-outbound Christer Holmberg (JO/LMF) wrote: >I am not asking anyone to document the email exchange. I am simply asking to document what happened at the meeting. > >And, if the only thing that was said at the meeting was "You have seen the e-mail discussion, now let's vote" then please say so... > =20 > Christer: If you want to put together such a summary and post it to the mailing list for the sake of posterity, I'm fairly certain that no one would criticize you for it. Start here: http://videolab.uoregon.edu/events/ietf/ /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Apr 02 18:48:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQBLP-0001sR-N5; Sun, 02 Apr 2006 18:46:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQBLO-0001qx-K6 for sip@ietf.org; Sun, 02 Apr 2006 18:46:50 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQBLN-0005wo-UM for sip@ietf.org; Sun, 02 Apr 2006 18:46:50 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 55E651DA; Mon, 3 Apr 2006 00:46:49 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 00:46:48 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 00:46:48 +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] How to indicate during proxy discoverythataproxysupports"outbound" Date: Mon, 3 Apr 2006 00:46:48 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1C4F@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] How to indicate during proxy discoverythataproxysupports"outbound" Thread-Index: AcZVbbU1S7ccCmaLSqWgk/tQJ1mJiQBDsIcw From: "Christer Holmberg \(JO/LMF\)" To: "Jeroen van Bemmel" , "Patrick Timmons" , "Hadriel Kaplan" , "Cullen Jennings" , "Dean Willis" , X-OriginalArrivalTime: 02 Apr 2006 22:46:48.0469 (UTC) FILETIME=[535BCC50:01C656A7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: 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, I agree on the fact that the issue with OPTIONS is that it adds an extra round trip. However, if the OPTIONS request is addressed for the outbound proxy, why would we use the Proxy-Require? For this particular request the outbound proxy would be an UAS - not a proxy. So, we would use the Require header. And, in that case it wouldn't matter if there are other proxies between the UAC and the outbound proxy, because they don't care about the Require header. ...and, there is no need to set Max-Forwards to zero. Regards, Christer =20 -----Original Message----- From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 Sent: 1. huhtikuuta 2006 12:20 To: Patrick Timmons; 'Hadriel Kaplan'; 'Cullen Jennings'; 'Dean Willis'; sip@ietf.org Cc: 'Juha Heinanen' Subject: Re: [Sip] How to indicate during proxy discoverythataproxysupports"outbound" Patrick, > However -- in a general sense, the issue here is that the UA needs to=20 > know specific features as they pertain to the topology of the network; > i.e., that the *edge* supports 'outbound'. My sense is that it's=20 > perfectly reasonable to think that there will be requirements for UAs=20 > to know specific features of proxies that sit topologically off of the > edge (?-CSCF, for example). > In > this case, the Proxy-Require technique breaks down... and we're left=20 > with supporting two different methods for achieving (essentially) the=20 > same ends. True, but this also goes for OPTIONS. To send an OPTIONS to the second hop, the UAC must not only be aware of the topology, but also of the routing logic at the first hop (i.e. second hop for REGISTER might be different than INVITE). For IMS it would be impossible (due to e.g. topology hiding, the UAC wouldn't be able to learn the hostname / IP address of the S-CSCF for example) but also for non-IMS networks this would simply not work. And beyond the second hop, things would get "exponentially" more complicated. For first hop only, both OPTIONS and Proxy-Require seem reasonable to me, with a slight preference for the latter. As a more general solution I suggest feature tags in the Path / Record-Route headers (as header parameters - not URI parameters - to avoid clobbering each mid-dialog request with them). Given the time constraints for outbound (Keith's deadline was yesterday...), I propose to agree on a first-hop-only solution for outbound, and leave generalization for future work. Regards, jeroen=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 Apr 02 18:48:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQBLG-0001pM-6d; Sun, 02 Apr 2006 18:46:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQBLE-0001pH-B2 for sip@ietf.org; Sun, 02 Apr 2006 18:46:40 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQBLC-0005wB-HS for sip@ietf.org; Sun, 02 Apr 2006 18:46:40 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6CAC41DA; Mon, 3 Apr 2006 00:46:37 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 00:46:36 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 00:46:36 +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] draft-elwell-sip-connected-identity-01.txt Date: Mon, 3 Apr 2006 00:46:36 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1C4D@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-elwell-sip-connected-identity-01.txt Thread-Index: AcZU6SRzY38xoDMvTsiJXpdaDD3pRgBimmEg From: "Christer Holmberg \(JO/LMF\)" To: "Drage, Keith \(Keith\)" , X-OriginalArrivalTime: 02 Apr 2006 22:46:36.0597 (UTC) FILETIME=[4C484650:01C656A7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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 Keith, >The current decision is to see if http://www.ietf.org/internet-drafts/draft-elwell-sip-connected-identity- 01.txt forms=20 >the basis of progressing as a WG item to fulfil our charter item. > >As such, it is still discussable and reviewable, but contents have to abide by WG decision, rather than author=20 >preference. > >The face-to-face meeting said it was, and we are looking to confirm that decision using the list. > >Does your comment indicate merely something missing that can be added, or does it indicate that the document is entirely=20 >in the wrong direction and therefore you object to the face-to-face meeting decision. I think there are things missing, AND I think there are technical issues. 1. Proxy impacts: There are no words on how the chaning of the URI will impact intermediate proxies (see separate thread). Normally our documents contains a "proxy impacts", but not in this. And, there is no agreed solution, so I consider that issue both MISSING TEXT and TECHNICAL. 2. Interworking (e.g. with PSTN): As was mentioned by Roland, this causes problems with interworking, ie it is not "backward compatible" with the RFCs we have on interworking. Since we normally, when we define extension, try to consider existing extensions and drafts/RFCs I think we shall do it also in this case - even if some individuals (those thinking PSTN will be replaced by IP overnight) probably don't care. So, I also consider that part both MISSING TEXT and TECHNICAL. I also disagree on the face-to-face decission that race condition is not an issue. However, I realize that is maybe more an deployment/use-case issue whether you can expect the UAC to send an UPDATE/re-INVITE soon after it has received 200 OK for the initial INVITE.=20 Regards, Christer > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:christer.holmberg@ericsson.com] > Sent: 31 March 2006 13:08 > To: Drage, Keith (Keith); sip@ietf.org > Subject: RE: [Sip] draft-elwell-sip-connected-identity-01.txt >=20 >=20 >=20 > Hi Keith, >=20 > I sent a mail within the "comments on sip-connected-identity"=20 > thread. I > presented some issues with the current solution, but also pointed out=20 > that the draft currently does not talk about proxy impacts. >=20 > Regards, >=20 > Christer >=20 > =20 >=20 > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: 26. maaliskuuta 2006 19:25 > To: sip@ietf.org > Subject: [Sip] draft-elwell-sip-connected-identity-01.txt >=20 > (As chair) >=20 > At the face-to-face meeting at IETF 65 we agreed that=20 > http://www.ietf.org/internet-drafts/draft-elwell-sip-connected -identity- 01.txt formed the basis of part of our charter milestone to provide "Mechanism for Response Identity to IESG (PS). This mail is to confirm that decision using the list. If you have issues with this decision, please respond to this mail. Note: Please keep responses to this thread entirely separate to the thread on draft-cao-sip-response-identity regards Keith Keith Drage drage@lucent.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 Sun Apr 02 21:01:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQDPh-0007Sq-BK; Sun, 02 Apr 2006 20:59:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQDPf-0007Sl-MI for sip@ietf.org; Sun, 02 Apr 2006 20:59:23 -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 1FQDPf-0003eQ-Bj for sip@ietf.org; Sun, 02 Apr 2006 20:59:23 -0400 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id A3690294; Sun, 02 Apr 2006 20:59:21 -0400 From: "Hadriel Kaplan" To: "'Christer Holmberg \(JO/LMF\)'" , Subject: RE: [Sip] How to indicate during proxy discoverythataproxysupports"outbound" Date: Sun, 2 Apr 2006 20:59:26 -0400 Message-ID: <02b501c656b9$db4309a0$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZVbbU1S7ccCmaLSqWgk/tQJ1mJiQBDsIcwAA2yINA= In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1C4F@esealmw113.eemea.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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 The proxy-require idea is to put it in the Register. So an outbound proxy would remove the option-tag and forward the register on, resulting in no round trips on success. The Require: piece would be in case the UA is directly attached to the Registrar. -hadriel > -----Original Message----- > From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] > Sent: Sunday, April 02, 2006 6:47 PM > To: Jeroen van Bemmel; Patrick Timmons; Hadriel Kaplan; Cullen Jennings; > Dean Willis; sip@ietf.org > Cc: Juha Heinanen > Subject: RE: [Sip] How to indicate during proxy > discoverythataproxysupports"outbound" > > > Hi, > > I agree on the fact that the issue with OPTIONS is that it adds an extra > round trip. > > However, if the OPTIONS request is addressed for the outbound proxy, why > would we use the Proxy-Require? For this particular request the outbound > proxy would be an UAS - not a proxy. So, we would use the Require > header. And, in that case it wouldn't matter if there are other proxies > between the UAC and the outbound proxy, because they don't care about > the Require header. > > ...and, there is no need to set Max-Forwards to zero. > > Regards, > > Christer > > > > > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: 1. huhtikuuta 2006 12:20 > To: Patrick Timmons; 'Hadriel Kaplan'; 'Cullen Jennings'; 'Dean Willis'; > sip@ietf.org > Cc: 'Juha Heinanen' > Subject: Re: [Sip] How to indicate during proxy > discoverythataproxysupports"outbound" > > Patrick, > > > However -- in a general sense, the issue here is that the UA needs to > > know specific features as they pertain to the topology of the network; > > > i.e., that the *edge* supports 'outbound'. My sense is that it's > > perfectly reasonable to think that there will be requirements for UAs > > to know specific features of proxies that sit topologically off of the > > > edge (?-CSCF, for example). > > In > > this case, the Proxy-Require technique breaks down... and we're left > > with supporting two different methods for achieving (essentially) the > > same ends. > > True, but this also goes for OPTIONS. To send an OPTIONS to the second > hop, the UAC must not only be aware of the topology, but also of the > routing logic at the first hop (i.e. second hop for REGISTER might be > different than INVITE). For IMS it would be impossible (due to e.g. > topology hiding, the UAC wouldn't be able to learn the hostname / IP > address of the S-CSCF for > example) but also for non-IMS networks this would simply not work. And > beyond the second hop, things would get "exponentially" more > complicated. > > For first hop only, both OPTIONS and Proxy-Require seem reasonable to > me, with a slight preference for the latter. As a more general solution > I suggest feature tags in the Path / Record-Route headers (as header > parameters - not URI parameters - to avoid clobbering each mid-dialog > request with them). > > Given the time constraints for outbound (Keith's deadline was > yesterday...), I propose to agree on a first-hop-only solution for > outbound, and leave generalization for future work. > > 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 Apr 03 01:41:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQHlY-000395-NT; Mon, 03 Apr 2006 01:38:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQHlX-00038o-D2 for sip@ietf.org; Mon, 03 Apr 2006 01:38:15 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQHlU-0006Nx-Mc for sip@ietf.org; Mon, 03 Apr 2006 01:38:15 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B325CA36; Mon, 3 Apr 2006 07:38:03 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 07:38:03 +0200 Received: from [136.225.183.92] ([136.225.183.92]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 07:38:00 +0200 From: "Christer Holmberg" To: "Hadriel Kaplan" , sip@ietf.org Subject: RE: [Sip] How to indicate during proxy discoverythataproxysupports "outbound" Date: Mon, 3 Apr 2006 08:33:10 +0300 Message-ID: X-Mailer: EPOC Email Version 2.10 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 03 Apr 2006 05:38:03.0099 (UTC) FILETIME=[C6958AB0:01C656E0] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christer Holmberg List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Hadriel, My mail was rabout the OPTIONS alternative. And, you wouldn't even need = Require there, because the outbound proxy would simply reply what it = supports. In fact, no standardization is required for that, so should we = mention it as an option? And, if there are no issues (removal of options tags from the P-R/Require = header by proxy) with the REGISTER alternative I don't have any issues with = that solution - as long as we document the assumptions and = restriction. Regards, Christer Regards, Christr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 03 02:29:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQIWQ-0007Mb-5L; Mon, 03 Apr 2006 02:26:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQIW3-0006VW-Hj for sip@ietf.org; Mon, 03 Apr 2006 02:26:19 -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 1FQINC-00081I-Vd for sip@ietf.org; Mon, 03 Apr 2006 02:17:13 -0400 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id ADE40168; Mon, 03 Apr 2006 02:17:08 -0400 From: "Hadriel Kaplan" To: "'Christer Holmberg'" , Subject: RE: [Sip] How to indicate during proxy discoverythataproxysupports "outbound" Date: Mon, 3 Apr 2006 02:17:13 -0400 Message-ID: <02d701c656e6$3ff0cb90$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZW4MaGcgX1MvTYT8Wn2vRdj3pFrQAApchg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 Funny - those were similar words to what I asked someone I know about the Options idea a couple days ago. The act of checking, and how, still needs to be documented because it's simply not obvious to people. I've been told the support of Options, however, is unfortunately not as prevalent as one would hope on legacy proxies. (also because it was not obvious) Maybe the SIPit folks have more data on that. It's also not clear all registrars would accept an Options before registration. The proxy-require/require in a Register, on the other hand, works with any proxy/registrar we've seen and is the least burden for all nodes I think. -hadriel > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, April 03, 2006 1:33 AM > To: Hadriel Kaplan; sip@ietf.org > Subject: RE: [Sip] How to indicate during proxy > discoverythataproxysupports "outbound" > > Hi Hadriel, > > My mail was rabout the OPTIONS alternative. And, you wouldn't even need > Require there, because the outbound proxy would simply reply what it > supports. In fact, no standardization is required for that, so should we > mention it as an option? > > And, if there are no issues (removal of options tags from the P-R/Require > header by proxy) with the REGISTER alternative I don't have any issues > with that solution - as long as we document the assumptions and > restriction. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 03 02:31:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQIZ9-0002DS-12; Mon, 03 Apr 2006 02:29:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQIZ7-00027Z-2z for sip@ietf.org; Mon, 03 Apr 2006 02:29:29 -0400 Received: from smtp1.versatel.nl ([62.58.50.88] helo=smtp3.versatel.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQIZ1-0000El-FH for sip@ietf.org; Mon, 03 Apr 2006 02:29:28 -0400 Received: (qmail 31191 invoked by uid 0); 3 Apr 2006 06:29:22 -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 < >; 3 Apr 2006 06:29:22 -0000 Message-ID: <001401c656e7$ed64acf0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Christer Holmberg" , "Hadriel Kaplan" , References: Subject: Re: [Sip] How to indicate during proxy discoverythataproxysupports"outbound" Date: Mon, 3 Apr 2006 08:29:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 Christer, Besides detection for support, Proxy-Require is also useful for backwards compatibility Consider how the edge proxy decides whether or not it needs to perform outbound processing. Without Proxy-Require, it would have to either look for 'Require: outbound' or inspect the Contact headers, look for 'reg-id' and assume that means the UAC supports / wants to use outbound. From a protocol purist perspective, both of these alternatives are less preferred than Proxy-Require BTW, section 3.4 should have some text discussing this. It currently says "edge proxy should use Path" but the processing seems to depend on the fact that there is a 'reg-id'. What if there is none? Regards, Jeroen ----- Original Message ----- From: "Christer Holmberg" To: "Hadriel Kaplan" ; Sent: Monday, April 03, 2006 7:33 AM Subject: RE: [Sip] How to indicate during proxy discoverythataproxysupports"outbound" Hi Hadriel, My mail was rabout the OPTIONS alternative. And, you wouldn't even need Require there, because the outbound proxy would simply reply what it supports. In fact, no standardization is required for that, so should we mention it as an option? And, if there are no issues (removal of options tags from the P-R/Require header by proxy) with the REGISTER alternative I don't have any issues with that solution - as long as we document the assumptions and restriction. Regards, Christer Regards, Christr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 03 03:03:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQJ40-00082V-82; Mon, 03 Apr 2006 03:01:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQJ3y-000821-Nb for sip@ietf.org; Mon, 03 Apr 2006 03:01:22 -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 1FQJ3y-0001fc-M9 for sip@ietf.org; Mon, 03 Apr 2006 03:01:22 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FQIpA-0006qk-61 for sip@ietf.org; Mon, 03 Apr 2006 02:46:05 -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 k336jSLv006398; Mon, 3 Apr 2006 09:45:28 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 09:46:01 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 09:46: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: RE: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt Date: Mon, 3 Apr 2006 09:46:00 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0225E58C@esebe103.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt Thread-Index: AcZVFd0sG9YDgsEJEdqlkgARJEEJ/AB01mMg From: To: , X-OriginalArrivalTime: 03 Apr 2006 06:46:00.0809 (UTC) FILETIME=[4516B590:01C656EA] X-Spam-Score: -2.6 (--) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: sip@ietf.org, aki.niemi@nokia.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 made up two proposals based on DNS for the UA to find out proxies supporting outbound within the domain of SIP AOR of the user or the domain got from DHCP: 1. Define a few new NAPTR service types for Outbound,=20 something like: "SIPS-O+D2T" "SIP-O+D2T" "SIP-O+D2U" 2. If the service resolved is e.g. "SIP-O+D2U" then the UA could open a separate connection towards the preferred proxy at each priority level of the SRV records for the service. Later on I agreed that a separate I-D could be created: > Anyway since the proposed DNS procedures would impact the > contents of RFC 3263 (new service types) a separate draft > could be a reasonable approach.=20 I am now planning to put together an I-D for those proposals as an update to RFC 3263. It may take some time, but hopefully not too long. Please tell me if you have any serious comments for those proposals, that I should take into account. Regards, Erkki >-----Original Message----- >From: ext Cullen Jennings [mailto:fluffy@cisco.com]=20 >Sent: 01.April.2006 01:53 >To: Juha Heinanen >Cc: sip@ietf.org; Niemi Aki (Nokia-NRC/Helsinki); Dean Willis >Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-03.txt > >On 3/29/06 10:47 PM, "Juha Heinanen" wrote: > >> Cullen Jennings writes: >>=20 >>> As we agreed in the meeting, I would rather have these is separate >>> documents since we can move forward with the what you do=20 >with it now and >>> solve the many possible way beyond configuration how you=20 >might find it >>> later.=20 >>=20 >> it is fine to have a separate document describing how SIP UA finds >> outbound-proxy-set, but that separate document MUST be=20 >referenced in the >> outbound I-D in the same way as rfc3263 is referenced by=20 >rfc3261. there >> is no point to publish a document where the only standards=20 >based way to >> configure outbound-proxy-set is manually, because no regular user is >> able to do it correctly. > >I think you and I mean different things by the word=20 >"configuration". I was >not suggesting that end users would be typing several URIs into a phone >using a 9 digit key pad - I completely agree with you that=20 >this would never >happen in any scaleable way. > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 03 03:24:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQJNo-00054o-6I; Mon, 03 Apr 2006 03:21:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQJNm-00054P-8w for sip@ietf.org; Mon, 03 Apr 2006 03:21:50 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQJNh-0002Yu-GX for sip@ietf.org; Mon, 03 Apr 2006 03:21:50 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DC6CD4F0002; Mon, 3 Apr 2006 09:21:44 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 09:21:44 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 09:21: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] How to indicate during proxy discoverythataproxysupports"outbound" Date: Mon, 3 Apr 2006 09:21:43 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1C54@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] How to indicate during proxy discoverythataproxysupports"outbound" Thread-Index: AcZW5/V0q63fLn1rR760BQ22lEiuwwABwBxQ From: "Christer Holmberg \(JO/LMF\)" To: "Jeroen van Bemmel" , "Hadriel Kaplan" , X-OriginalArrivalTime: 03 Apr 2006 07:21:43.0936 (UTC) FILETIME=[427DF000:01C656EF] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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, In case the outbound proxy and the registrar are NOT the same, I assume that the outbound proxy would not only remove the option tag from the Proxy-Require header, but also from the Require header? Because, as far as I can see there is no reason to require the registrar to also support outbound. Regards, Christer =20 -----Original Message----- From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 Sent: 3. huhtikuuta 2006 9:29 To: Christer Holmberg (JO/LMF); Hadriel Kaplan; sip@ietf.org Subject: Re: [Sip] How to indicate during proxy discoverythataproxysupports"outbound" Christer, Besides detection for support, Proxy-Require is also useful for backwards compatibility Consider how the edge proxy decides whether or not it needs to perform outbound processing. Without Proxy-Require, it would have to either look for 'Require: outbound' or inspect the Contact headers, look for 'reg-id' and assume that means the UAC supports / wants to use outbound. From a protocol purist perspective, both of these alternatives are less preferred than Proxy-Require BTW, section 3.4 should have some text discussing this. It currently says "edge proxy should use Path" but the processing seems to depend on the fact that there is a 'reg-id'. What if there is none? Regards, Jeroen ----- Original Message ----- From: "Christer Holmberg" To: "Hadriel Kaplan" ; Sent: Monday, April 03, 2006 7:33 AM Subject: RE: [Sip] How to indicate during proxy discoverythataproxysupports"outbound" Hi Hadriel, My mail was rabout the OPTIONS alternative. And, you wouldn't even need Require there, because the outbound proxy would simply reply what it supports. In fact, no standardization is required for that, so should we mention it as an option? And, if there are no issues (removal of options tags from the P-R/Require header by proxy) with the REGISTER alternative I don't have any issues with that solution - as long as we document the assumptions and restriction. Regards, Christer Regards, Christr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Apr 03 03:27:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQJRb-0000mc-88; Mon, 03 Apr 2006 03:25:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQJRZ-0000lE-6H for sip@ietf.org; Mon, 03 Apr 2006 03:25:45 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQJRY-0002nK-JQ for sip@ietf.org; Mon, 03 Apr 2006 03:25:45 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E56BD4F0047; Mon, 3 Apr 2006 09:25:38 +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, 3 Apr 2006 09:25:38 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 09:25:37 +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] How to indicate during proxy discoverythataproxysupports "outbound" Date: Mon, 3 Apr 2006 09:25:37 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1C55@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] How to indicate during proxy discoverythataproxysupports "outbound" Thread-Index: AcZW4MaGcgX1MvTYT8Wn2vRdj3pFrQAApchgAAMBQJA= From: "Christer Holmberg \(JO/LMF\)" To: "Hadriel Kaplan" , X-OriginalArrivalTime: 03 Apr 2006 07:25:37.0783 (UTC) FILETIME=[CDE02870:01C656EF] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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, I can't speak for how obvious things are to people. But, I don't think we can make decissions based on such things. If something is unclear, it needs to be clarified. And, what is important in this specific case is that the outbound proxy supports OPTIONS, so I assume anyone implementing outbound would also make sure the proxy would be able to handle OPTIONS. Regards, Christer =20 -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 Sent: 3. huhtikuuta 2006 9:17 To: Christer Holmberg (JO/LMF); sip@ietf.org Subject: RE: [Sip] How to indicate during proxy discoverythataproxysupports "outbound" Funny - those were similar words to what I asked someone I know about the Options idea a couple days ago. The act of checking, and how, still needs to be documented because it's simply not obvious to people. I've been told the support of Options, however, is unfortunately not as prevalent as one would hope on legacy proxies. (also because it was not obvious) Maybe the SIPit folks have more data on that. It's also not clear all registrars would accept an Options before registration. The proxy-require/require in a Register, on the other hand, works with any proxy/registrar we've seen and is the least burden for all nodes I think. -hadriel > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, April 03, 2006 1:33 AM > To: Hadriel Kaplan; sip@ietf.org > Subject: RE: [Sip] How to indicate during proxy=20 > discoverythataproxysupports "outbound" >=20 > Hi Hadriel, >=20 > My mail was rabout the OPTIONS alternative. And, you wouldn't even=20 > need Require there, because the outbound proxy would simply reply what > it supports. In fact, no standardization is required for that, so=20 > should we mention it as an option? >=20 > And, if there are no issues (removal of options tags from the=20 > P-R/Require header by proxy) with the REGISTER alternative I don't=20 > have any issues with that solution - as long as we document the=20 > assumptions and restriction. >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Apr 03 04:30:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQKQ5-0001Ec-MT; Mon, 03 Apr 2006 04:28:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQKQ5-0001EX-2N for sip@ietf.org; Mon, 03 Apr 2006 04:28:17 -0400 Received: from fmmailgate04.web.de ([217.72.192.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQKQ3-00063M-Kq for sip@ietf.org; Mon, 03 Apr 2006 04:28:17 -0400 Received: by fmmailgate04.web.de (8.12.10/8.12.10/webde Linux 0.7) with SMTP id k338QjJc029155; Mon, 3 Apr 2006 10:28:04 +0200 Received: from [217.167.116.182] by freemailng0804.web.de with HTTP; Mon, 03 Apr 2006 10:28:03 +0200 Date: Mon, 03 Apr 2006 10:28:03 +0200 Message-Id: <596128656@web.de> MIME-Version: 1.0 From: Roland Jesske To: audet@nortel.com, brett@broadsoft.com, christer.holmberg@ericsson.com, fcao@cisco.com, jdrosen@cisco.com, john.elwell@siemens.com, sip@ietf.org Subject: [Sip] draft-elwell-sip-connected-identity-01.txt Precedence: fm-user Organization: http://freemail.web.de/ Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > Feng Chao worte: > The alternatives you brought up still need one mechanism to protect the integrity of the connected-id. UPDATE leverages the > identity work from Jon and Cullen. That is the reason that this connected-id issue can be easily covered by the identity work. > Why not just insert response identity into response? This is more generic and requires no additional response code ... Yes that would be one solution from my point of view that can be used. I'm open to solutions where we get the connected information within the response to the INVITE. And not using a second Request-Response cycle. Roland _______________________________________________________________ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 03 04:40:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQKZy-00019H-8Q; Mon, 03 Apr 2006 04:38:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQKZw-000186-PC for sip@ietf.org; Mon, 03 Apr 2006 04:38:28 -0400 Received: from fmmailgate04.web.de ([217.72.192.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQKZw-0006W7-BH for sip@ietf.org; Mon, 03 Apr 2006 04:38:28 -0400 Received: by fmmailgate04.web.de (8.12.10/8.12.10/webde Linux 0.7) with SMTP id k338bdJQ023542; Mon, 3 Apr 2006 10:38:26 +0200 Received: from [217.167.116.182] by freemailng0804.web.de with HTTP; Mon, 03 Apr 2006 10:38:25 +0200 Date: Mon, 03 Apr 2006 10:38:25 +0200 Message-Id: <596196939@web.de> MIME-Version: 1.0 From: Roland Jesske To: christer.holmberg@ericsson.com, sip@ietf.org Subject: [Sip] draft-elwell-sip-connected-identity-01.txt Precedence: fm-user Organization: http://freemail.web.de/ Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >Chriser wrote: >2. Interworking (e.g. with PSTN): As was mentioned by Roland, this >causes problems with interworking, ie it is not "backward compatible" >with the RFCs we have on interworking. Since we normally, when we define >extension, try to consider existing extensions and drafts/RFCs I think >we shall do it also in this case - even if some individuals (those >thinking PSTN will be replaced by IP overnight) probably don't care. So, >I also consider that part both MISSING TEXT and TECHNICAL. Yes and we have already implemented such interworkings so we have to change the complet interworking model to wait for a second Request - Response cycle. And there will the problem how the Interworking unit knows that a UPDATE will arrive after the final response for the INVITE was recived. Best Regards Roland _______________________________________________________________ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 03 06:10:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQLz3-00019E-IL; Mon, 03 Apr 2006 06:08:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQLz1-000196-Qc; Mon, 03 Apr 2006 06:08:27 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQLz1-0002pT-BN; Mon, 03 Apr 2006 06:08:27 -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 k33A0ulC028400; Mon, 3 Apr 2006 04:00:56 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Last Call: 'Management Information Base for the SessionInitiation Protocol (SIP)' to Proposed Standard Date: Mon, 3 Apr 2006 04:00:55 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Last Call: 'Management Information Base for the SessionInitiation Protocol (SIP)' to Proposed Standard Thread-Index: AcZOxX7Paqe914BiQ4WrxfWRZ79G3AF4BO6QAAo9/jAACZ368AB+wHrA From: "Jean-Francois Mule" To: "Samir Srivastava" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: sip@ietf.org, klingle@cisco.com, iesg@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 Samir, See more discussion inline.=20 Based on my understanding of your comments and your follow-up = response, it seems that the 3 comments are closed.=20 =20 To summarize: --- 1. re: logging of SIP mib notifications using RFC 3014 You wrote: > SS>> Shouldn't 3014 referred somewhere? In short, my preference would be to not reference it in the SIP mib. Note that your comment is applicable to any protocol MIB module that = defines SNMP notifications. For this reason, a reference to generic MIB = mechanisms could either be added to all MIBs (via the standard MIB = boilerplate), or, it should be added on a case by case basis based on = the scope of a given MIB module. It is not in the MIB boilerplate and = based on the scope of the SIP MIB and the limited notifications we = define in it, I would rather not recommend we add a new paragraph on how = to log SNMP notifications (even as an informative reference).=20 To me, if you open the broader requirement of how does a SIP = implementation deal with logging management events on a device, you have = to look at events that can be generated globally and the SIP = application, above and beyond SNMP, and be prepared to discuss things = that get logged via syslog, local file logs, etc. Finally, folks who develop on SNMP agent and look at SNMP = implementations are usually aware that they can use a bunch of other MIB = modules to complement a pure protocol MIB (host mib, notification log = and btw - all or some of the other mibs coming out of the disman wg, = etc.) --- 2. use of 'congested' Ok - we will stick with the name *and* definition of 'congested' as = defined in the Network Services MIB. --- 3. expanding the definition of 'congested' based on sipping overload = ID (draft-rosenberg-sipping-overload-reqs-00.txt) Thanks for elaborating on your comment.=20 My view on this comment is that=20 a) the SIP MIB as defined as capable of handling the RFC 3261 "very = basic support for overload" as dicussed in section 3 of = draft-rosenberg-sipping-overload-reqs-00.txt. ('congested' -> 503 or = 5xx) b) once the overload requirements are stable, and new semantics are = defined for handling overload, the MIB object sipServiceOperStatus could = well be extended to add new values that could reflect the new behaviors = an app can adopt under overload.=20 So, based on the above, I would recommend we wait until the requirements = in draft-rosenberg-sipping-overload-reqs-00.txt are stable, potential = new mechanisms for dealing with overload are defined and see how this = should be translated to reflect the operational status of a sip app = through mgmt. Is that ok? =20 Jean-Fran=E7ois > -----Original Message----- > From: Samir Srivastava [mailto:samirsr@nortel.com] > Sent: Friday, March 31, 2006 12:17 PM > To: Jean-Francois Mule > Cc: sip@ietf.org; iesg@ietf.org; klingle@cisco.com > Subject: RE: [Sip] Last Call: 'Management Information Base for the > SessionInitiation Protocol (SIP)' to Proposed Standard >=20 > Hi Jean-Francois, >=20 > See in line. >=20 > Thx > Samir >=20 > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: Friday, March 31, 2006 6:42 AM > To: Srivastava, Samir [SC100:8826:EXCH] > Cc: sip@ietf.org; iesg@ietf.org; klingle@cisco.com > Subject: RE: [Sip] Last Call: 'Management Information Base for the > SessionInitiation Protocol (SIP)' to Proposed Standard >=20 > Samir, >=20 > Thank you for your comments - see responses inline. >=20 > I removed the IETF-Announce recipient from the response to limit > spam; if it should be added back, feel free to forward or add it back. >=20 > Jean-Francois > --- > Jean-Fran=E7ois Mul=E9 > jfm@cablelabs.com >=20 >=20 > Samir Srivastava wrote: > > -----Original Message----- > > From: Samir Srivastava [mailto:samirsr@nortel.com] > > Sent: Friday, March 31, 2006 2:45 AM > > To: iesg@ietf.org; IETF-Announce > > Cc: sip@ietf.org > > Subject: RE: [Sip] Last Call: 'Management Information Base for the > > SessionInitiation Protocol (SIP)' to Proposed Standard > > > > Hi, > > > > 1. It defines Object sipNotifSequenceNumber. It is defined for > > Manager > > to find a missing / out of > > sequence NOTIFICATION. Why not NOTIFICATIONS are stored in a table ? > > If > > Manager looses a notification, it cannot find which one is lost. > > Manager > > might poll this sequence, if it finds something missing, it can > fetch > > from the table. If it is missing the latest Notification, then it is > > very important for the determining server health. Am I missing > > something ? > See the Notification Log MIB (RFC 3014) for a generic mechanism that > can be used for recording notification information. It can be used in > conjunction with the SIP MIB to store or log specific SIP MIB > notifications, hence addressing your question. >=20 > SS>> Shouldn't 3014 referred somewhere ? >=20 > > 2. It defines "congested" as one of the value for > > sipServiceOperStatus. > > IMHO, Congestion is network property. It should be "overloaded" . > > Overload is server CPU stuff. If SIP server is finding congestion > also > > based on retransmission etc, then shouldn't we have these two as > > distinct values. > See the I-D section on the relationship with other MIB modules and the > Network Services MIB (RFC 2788) in particular. > RFC 2788 defines an applOperStatus object for the operational status > of the network service application with a valid value of congested(4), > hence the re-use of congested in the SIP MIB module. >=20 >=20 > SS>> This I am leaving to working group to decide where it should be > fixed. For the future overload and congestion work, this looks to me > confusing and we should separate these two. >=20 > > 3. As of now we know binary representation of overload/congestion is > > problem ? Shouldn't we have variable with % of overload. This MIB > > might be addressing 3261, it is a new requirement developing. So I > am > > not that much concerned on this. >=20 > I am not sure I get the point of your third comment, or the actual > requirement behind the proposed "variable with % of overload". But if > you are not much concerned on this, given that this version of the MIB > has undergone numerous revisions to address wg comments, completed > WGLC, and passed mib doctor review, I would recommend we do not > increase the scope of this version of the MIB module at this time. >=20 > SS>> Refer the draft > http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-overload- > reqs-00.txt > Section 5, page 11, REQ 7. >=20 > And it was accepted widely and work needs to be continued on this. > Even if, we don't take this path, a separate object with % overload is > good enough. If we retain the binary nature, then it will be > 0 or 1 value. >=20 > > > > Thx > Thank you. The above responses should address your comments; if not, > please elaborate or explain. >=20 > > Samir > > > > > > > > -----Original Message----- > > From: The IESG [mailto:iesg-secretary@ietf.org] > > Sent: Thursday, March 23, 2006 12:59 PM > > To: IETF-Announce > > Cc: sip@ietf.org > > Subject: [Sip] Last Call: 'Management Information Base for the > Session > > Initiation Protocol (SIP)' to Proposed Standard > > > > The IESG has received a request from the Session Initiation Protocol > > WG to consider the following document: > > > > - 'Management Information Base for the Session Initiation Protocol > > (SIP) > > ' > > as a Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and > solicits > > final comments on this action. Please send any comments to the > > iesg@ietf.org or ietf@ietf.org mailing lists by 2006-04-06. > > > > The file can be obtained via > > http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-10.txt >=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 Mon Apr 03 06:36:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQMNx-0002ij-Vo; Mon, 03 Apr 2006 06:34:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQMNw-0002hi-OA; Mon, 03 Apr 2006 06:34:12 -0400 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQMNw-0003oW-9Q; Mon, 03 Apr 2006 06:34:12 -0400 Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k33AWKmv020030; Mon, 3 Apr 2006 06:32:20 -0400 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.8/Switch-3.1.0) with ESMTP id k33AV0Xw021214; Mon, 3 Apr 2006 06:31:01 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Last Call: 'Management Information Base for theSessionInitiation Protocol (SIP)' to Proposed Standard Date: Mon, 3 Apr 2006 12:34:09 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Last Call: 'Management Information Base for theSessionInitiation Protocol (SIP)' to Proposed Standard Thread-Index: AcZOxX7Paqe914BiQ4WrxfWRZ79G3AF4BO6QAAo9/jAACZ368AB+wHrAAAZjoUA= From: "Romascanu, Dan \(Dan\)" To: "Jean-Francois Mule" , "Samir Srivastava" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Cc: sip@ietf.org, klingle@cisco.com, iesg@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 (speaking as MIB advisor for this document) I believe that the resolution proposed by Jean-Francois to the three = comments from Samir is good. Dan =20 =20 > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 > Sent: Monday, April 03, 2006 1:01 PM > To: Samir Srivastava > Cc: sip@ietf.org; klingle@cisco.com; iesg@ietf.org > Subject: RE: [Sip] Last Call: 'Management Information Base=20 > for theSessionInitiation Protocol (SIP)' to Proposed Standard=20 >=20 > Samir, >=20 > See more discussion inline.=20 > Based on my understanding of your comments and your=20 > follow-up response, it seems that the 3 comments are closed.=20 > =20 > To summarize: > --- 1. re: logging of SIP mib notifications using RFC 3014 You wrote: > > SS>> Shouldn't 3014 referred somewhere? > In short, my preference would be to not reference it in the SIP mib. > Note that your comment is applicable to any protocol MIB=20 > module that defines SNMP notifications. For this reason, a=20 > reference to generic MIB mechanisms could either be added to=20 > all MIBs (via the standard MIB boilerplate), or, it should be=20 > added on a case by case basis based on the scope of a given=20 > MIB module. It is not in the MIB boilerplate and based on the=20 > scope of the SIP MIB and the limited notifications we define=20 > in it, I would rather not recommend we add a new paragraph on=20 > how to log SNMP notifications (even as an informative reference).=20 > To me, if you open the broader requirement of how does a SIP=20 > implementation deal with logging management events on a=20 > device, you have to look at events that can be generated=20 > globally and the SIP application, above and beyond SNMP, and=20 > be prepared to discuss things that get logged via syslog,=20 > local file logs, etc. > Finally, folks who develop on SNMP agent and look at SNMP=20 > implementations are usually aware that they can use a bunch=20 > of other MIB modules to complement a pure protocol MIB (host=20 > mib, notification log and btw - all or some of the other mibs=20 > coming out of the disman wg, etc.) >=20 >=20 > --- 2. use of 'congested' > Ok - we will stick with the name *and* definition of=20 > 'congested' as defined in the Network Services MIB. >=20 > --- 3. expanding the definition of 'congested' based on=20 > sipping overload ID (draft-rosenberg-sipping-overload-reqs-00.txt) > Thanks for elaborating on your comment.=20 > My view on this comment is that=20 > a) the SIP MIB as defined as capable of handling the=20 > RFC 3261 "very basic support for overload" as dicussed in=20 > section 3 of draft-rosenberg-sipping-overload-reqs-00.txt.=20 > ('congested' -> 503 or 5xx) > b) once the overload requirements are stable, and new=20 > semantics are defined for handling overload, the MIB object=20 > sipServiceOperStatus could well be extended to add new values=20 > that could reflect the new behaviors an app can adopt under overload.=20 > So, based on the above, I would recommend we wait until the=20 > requirements in draft-rosenberg-sipping-overload-reqs-00.txt=20 > are stable, potential new mechanisms for dealing with=20 > overload are defined and see how this should be translated to=20 > reflect the operational status of a sip app through mgmt. >=20 > Is that ok? =20 >=20 > Jean-Fran=E7ois >=20 >=20 > > -----Original Message----- > > From: Samir Srivastava [mailto:samirsr@nortel.com] > > Sent: Friday, March 31, 2006 12:17 PM > > To: Jean-Francois Mule > > Cc: sip@ietf.org; iesg@ietf.org; klingle@cisco.com > > Subject: RE: [Sip] Last Call: 'Management Information Base for the=20 > > SessionInitiation Protocol (SIP)' to Proposed Standard > >=20 > > Hi Jean-Francois, > >=20 > > See in line. > >=20 > > Thx > > Samir > >=20 > > -----Original Message----- > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > Sent: Friday, March 31, 2006 6:42 AM > > To: Srivastava, Samir [SC100:8826:EXCH] > > Cc: sip@ietf.org; iesg@ietf.org; klingle@cisco.com > > Subject: RE: [Sip] Last Call: 'Management Information Base for the=20 > > SessionInitiation Protocol (SIP)' to Proposed Standard > >=20 > > Samir, > >=20 > > Thank you for your comments - see responses inline. > >=20 > > I removed the IETF-Announce recipient from the response to limit=20 > > spam; if it should be added back, feel free to forward or=20 > add it back. > >=20 > > Jean-Francois > > --- > > Jean-Fran=E7ois Mul=E9 > > jfm@cablelabs.com > >=20 > >=20 > > Samir Srivastava wrote: > > > -----Original Message----- > > > From: Samir Srivastava [mailto:samirsr@nortel.com] > > > Sent: Friday, March 31, 2006 2:45 AM > > > To: iesg@ietf.org; IETF-Announce > > > Cc: sip@ietf.org > > > Subject: RE: [Sip] Last Call: 'Management Information=20 > Base for the=20 > > > SessionInitiation Protocol (SIP)' to Proposed Standard > > > > > > Hi, > > > > > > 1. It defines Object sipNotifSequenceNumber. It is defined for > > > Manager > > > to find a missing / out of > > > sequence NOTIFICATION. Why not NOTIFICATIONS are stored=20 > in a table ? > > > If > > > Manager looses a notification, it cannot find which one is lost. > > > Manager > > > might poll this sequence, if it finds something missing, it can > > fetch > > > from the table. If it is missing the latest Notification,=20 > then it is=20 > > > very important for the determining server health. Am I missing=20 > > > something ? > > See the Notification Log MIB (RFC 3014) for a generic=20 > mechanism that=20 > > can be used for recording notification information. It can=20 > be used in=20 > > conjunction with the SIP MIB to store or log specific SIP MIB=20 > > notifications, hence addressing your question. > >=20 > > SS>> Shouldn't 3014 referred somewhere ? > >=20 > > > 2. It defines "congested" as one of the value for=20 > > > sipServiceOperStatus. > > > IMHO, Congestion is network property. It should be "overloaded" . > > > Overload is server CPU stuff. If SIP server is finding congestion > > also > > > based on retransmission etc, then shouldn't we have these two as=20 > > > distinct values. > > See the I-D section on the relationship with other MIB=20 > modules and the=20 > > Network Services MIB (RFC 2788) in particular. > > RFC 2788 defines an applOperStatus object for the=20 > operational status=20 > > of the network service application with a valid value of=20 > congested(4),=20 > > hence the re-use of congested in the SIP MIB module. > >=20 > >=20 > > SS>> This I am leaving to working group to decide where it should be > > fixed. For the future overload and congestion work, this=20 > looks to me=20 > > confusing and we should separate these two. > >=20 > > > 3. As of now we know binary representation of=20 > overload/congestion is=20 > > > problem ? Shouldn't we have variable with % of overload. This MIB=20 > > > might be addressing 3261, it is a new requirement developing. So I > > am > > > not that much concerned on this. > >=20 > > I am not sure I get the point of your third comment, or the actual=20 > > requirement behind the proposed "variable with % of=20 > overload". But if=20 > > you are not much concerned on this, given that this version=20 > of the MIB=20 > > has undergone numerous revisions to address wg comments, completed=20 > > WGLC, and passed mib doctor review, I would recommend we do not=20 > > increase the scope of this version of the MIB module at this time. > >=20 > > SS>> Refer the draft > > =20 > http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-overload- > > reqs-00.txt > > Section 5, page 11, REQ 7. > >=20 > > And it was accepted widely and work needs to be continued on this. > > Even if, we don't take this path, a separate object with %=20 > overload is=20 > > good enough. If we retain the binary nature, then it will be 0 or 1=20 > > value. > >=20 > > > > > > Thx > > Thank you. The above responses should address your=20 > comments; if not,=20 > > please elaborate or explain. > >=20 > > > Samir > > > > > > > > > > > > -----Original Message----- > > > From: The IESG [mailto:iesg-secretary@ietf.org] > > > Sent: Thursday, March 23, 2006 12:59 PM > > > To: IETF-Announce > > > Cc: sip@ietf.org > > > Subject: [Sip] Last Call: 'Management Information Base for the > > Session > > > Initiation Protocol (SIP)' to Proposed Standard > > > > > > The IESG has received a request from the Session=20 > Initiation Protocol=20 > > > WG to consider the following document: > > > > > > - 'Management Information Base for the Session Initiation Protocol > > > (SIP) > > > ' > > > as a Proposed Standard > > > > > > The IESG plans to make a decision in the next few weeks, and > > solicits > > > final comments on this action. Please send any comments to the=20 > > > iesg@ietf.org or ietf@ietf.org mailing lists by 2006-04-06. > > > > > > The file can be obtained via > > > http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-10.txt > >=20 > >=20 > >=20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Apr 03 06:49:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQMaZ-0003X3-OT; Mon, 03 Apr 2006 06:47:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQMaY-0003VS-MC for sip@ietf.org; Mon, 03 Apr 2006 06:47:14 -0400 Received: from sedna.sxdesign.com ([193.71.196.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQMaX-0004GI-D7 for sip@ietf.org; Mon, 03 Apr 2006 06:47:14 -0400 Received: from 2.80-203-147.nextgentel.com ([80.203.147.2] helo=[10.47.0.2]) by sedna.sxdesign.com with esmtpa (Exim 4.50) id 1FQMaU-0002GB-0f for sip@ietf.org; Mon, 03 Apr 2006 12:47:10 +0200 Message-ID: <4430FD2D.5020004@owera.com> Date: Mon, 03 Apr 2006 12:47:09 +0200 From: Richard Aas Organization: SX Design User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Sip] A UAS cannot delete an INVITE transaction upon sending a 200 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 find the description in http://bugs.sipit.net/show_bug.cgi?id=769 somewhat unclear when it comes to how a fix should be implemented. How long should the server transaction continue to exist and in what state? Should received ACK's for 2xx responses affect the transaction timing/state (like ACKs for non-2xx do)? Which changes must be implemented in the UAS regarding 2xx retransmission etc? Regards, Richard _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 03 08:11:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQNsT-0004V5-Gr; Mon, 03 Apr 2006 08:09:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQNsS-0004V0-6o for sip@ietf.org; Mon, 03 Apr 2006 08:09:48 -0400 Received: from rat01038.dc-ratingen.de ([195.233.129.143]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQNsQ-0007By-QT for sip@ietf.org; Mon, 03 Apr 2006 08:09:48 -0400 Received: from heinz.vodafone-is.de (heinz_e0 [195.233.128.26]) by rat01038.dc-ratingen.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id k33C9iLY020573 for ; Mon, 3 Apr 2006 14:09:45 +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 k33C9eBb012221 for ; Mon, 3 Apr 2006 14:09:44 +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.211); Mon, 3 Apr 2006 14:09:44 +0200 Received: from DEDUS-WICL01M01.vf-de.internal.vodafone.com ([10.128.148.122]) by dedus-wimx01.vf-de.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Apr 2006 14:09:44 +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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Apr 2006 14:09:43 +0200 Message-ID: <3A6671F8B360D34FAAC98771AD4D9990029D9AD6@DEDUS-WICL01M01.vf-de.internal.vodafone.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on Service Route Discovery Procedure during Registration Thread-Index: AcZXF330L9oPxwg6RVGrMzXEE6Eh5Q== From: "Lu, Yang, VF-DE" To: X-OriginalArrivalTime: 03 Apr 2006 12:09:44.0731 (UTC) FILETIME=[7EA5FEB0:01C65717] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Sip] Question on Service Route Discovery Procedure during Registration X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dear All RFC 3261 Section 8.2.4 "Applying Extensions" says "A UAS that wishes to apply some extension when generating the response MUST NOT do so unless support for that extension is indicated in the Supported header field in the request". However, the Service Route discovery procedure during Registration described in RFC 3608 does not follow this as shown in the example in Section 6. Are there any reasons for that and for the fact that there is no need to define an Option Tag for Service Route? Regards Yang Lu Vodafone _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 03 09:57:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQPXH-0004m5-1M; Mon, 03 Apr 2006 09:56:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQPXG-0004lT-2j for sip@ietf.org; Mon, 03 Apr 2006 09:56:02 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQPXF-0003hq-Ki for sip@ietf.org; Mon, 03 Apr 2006 09:56:02 -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 k33DsuD2012573; Mon, 3 Apr 2006 08:54:57 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 3 Apr 2006 14:54:56 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB012967E06@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Patrick Timmons'" , "'Jeroen van Bemmel'" , "'Hadriel Kaplan'" , "'Cullen Jennings'" , "'Dean Willis'" , "'sip@ietf.org'" Subject: RE: [Sip] How to indicate during proxy discovery thataproxysuppor ts"outbound" Date: Mon, 3 Apr 2006 14:54:52 +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: 83e9494d829b08cc3f644ef6ac1b9bd4 Cc: '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 I seem to remember we had the list discussion on what RFC3329 did with Proxy-Require after RFC3329 was published. That discussion did not come up with better ways of dealing with the RFC 3329 issue, but I seem to remember at least one SIP guru disagreeing with that usage of Proxy-Require. regards Keith > -----Original Message----- > From: Patrick Timmons [mailto:ptimmons@acmepacket.com] > Sent: 01 April 2006 02:31 > To: 'Jeroen van Bemmel'; 'Hadriel Kaplan'; 'Cullen Jennings'; 'Dean > Willis'; sip@ietf.org > Cc: 'Juha Heinanen' > Subject: RE: [Sip] How to indicate during proxy discovery > thataproxysupports"outbound" > > > Jeroen - > > Ah, I wasn't aware that RFC3329 legitimized stripping > Proxy-Require headers > for edge proxies. Thanks for the reference. > > However -- in a general sense, the issue here is that the UA > needs to know > specific features as they pertain to the topology of the > network; i.e., that > the *edge* supports 'outbound'. My sense is that it's > perfectly reasonable > to think that there will be requirements for UAs to know > specific features > of proxies that sit topologically off of the edge (?-CSCF, > for example). In > this case, the Proxy-Require technique breaks down... and > we're left with > supporting two different methods for achieving (essentially) > the same ends. > > For features that are specific to the edge proxy like > sec-agree and outbound > this approach clearly works at least as efficiently as an additional > round-trip. I'm certainly not opposed to using the > technique, since RFC3329 > set the precedent that it is okay to do so. But it seems > that using OPTIONS > to query the options of a device is putting the protocol to > its intended > use; as to whether this virtue is worth the extra round-trip > is open for > debate I suppose. > > Maybe I'll go back and read the archives -- this must have > come up before > during the development of RFC3329, which was before my time. > > pt. > > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: Friday, March 31, 2006 3:29 PM > To: Patrick Timmons; 'Hadriel Kaplan'; 'Cullen Jennings'; > 'Dean Willis'; > sip@ietf.org > Cc: 'Juha Heinanen' > Subject: Re: [Sip] How to indicate during proxy discovery > thataproxysupports"outbound" > > Patrick, > > Benefit of that is that it's nice and simple, drawback is an extra > roundtrip. If you're willing to risk an extra roundtrip, you could do > slightly better by adding Proxy-Require: outbound to the request, and > specify proxy behavior similar to RFC3329. In particular, the > edge proxy > would be required to remove the Proxy-Require header if it supports > outbound, and then forward the request (although RFC3261 > table 2 does not > allow a proxy to remove a Proxy-Require header, that is what > is done). A > non-supporting proxy would respond with an error, and the > request could be > retried without outbound. > > This approach would only give an extra roundtrip in case the > edge proxy does > not support outbound > > Regards, > > Jeroen > > ----- Original Message ----- > From: "Patrick Timmons" > To: "'Hadriel Kaplan'" ; "'Jeroen van > Bemmel'" > ; "'Cullen Jennings'" ; > "'Dean Willis'" > > ; > Cc: "'Juha Heinanen'" > Sent: Friday, March 31, 2006 9:56 PM > Subject: RE: [Sip] How to indicate during proxy discovery that > aproxysupports"outbound" > > > > Why not require that the UA send an OPTIONS request to its outbound > > proxy with Max-Forwards: 0? This jibes with the > recommendations put > > forth in RFC > > 3261 (sec. 11) regarding querying capabilities of proxies: > > > > Alternatively, a server receiving an OPTIONS request with a Max- > > Forwards header field value of 0 MAY respond to the request > > regardless of the Request-URI. > > > > This behavior is common with HTTP/1.1. This behavior > can be used > > as a "traceroute" functionality to check the capabilities of > > individual hop servers by sending a series of OPTIONS requests > > with incremented Max-Forwards values. > > > > The edge proxy could reply to such a request with "Supported: > > outbound, keepalive-stun", or something along these lines. > > > > The registrar's support of sip-outbound could be queried > similarly. > > This could be done either prior to, or immediately after initial > registration. > > > > pt. > > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Thursday, March 30, 2006 4:31 AM > > To: 'Jeroen van Bemmel'; 'Cullen Jennings'; 'Dean Willis'; > > sip@ietf.org > > Cc: 'Juha Heinanen' > > Subject: RE: [Sip] How to indicate during proxy discovery that > > aproxysupports"outbound" > > > > Hi Jeroen, > > The whole point is actually to make it a MUST that the UA > perform a "safe" > > check, where "safe" means a sip-compliant check, before it does > > anything bad. It cannot be a choice of a sip-outbound > compliant UA to > > just do bad if it wishes. It's not actually the outbound > sip changes > > that are the big problem, it's really the binary/stun messages. > > > > I'm not overly worried about anyone sending new sip signaling - of > > course you can send that. Every new draft/RFC does that, and the > > beauty of SIP is to have that backwards-compatible flexibility. If > > the new sip-signaling needs to be understood by boxes that > didn't have > > to understand it before because they may create issues for > the legacy > > sip "network", well that's a problem from a SIP WG > perspective I would > > think. And that is also a problem right now, perhaps, if a > > sip-outbound UA assumes the edge proxy is a sip-outbound > proxy, when > > it is not. Right now the draft has no way to let the UA know the > > edge-proxy supports outbound. It has a way for it to know the > > registrar does, although even then it doesn't say that > knowledge must > > be used for anything. The results of that may lead to constant > > forking, which is probably not a good thing. > > > > But the REAL problem is the UA can send a binary message. I > > understand why we want to do that, and although I hated the idea at > > first, I am willing to accept the decision and it's growing on me. > > BUT, it's still a major issue if UAs can send it when they > like. They > > MUST safely check to make sure it's ok. > > > > It's not a major issue for my company - our products will > handle it fine. > > But I can't speak for others. And not everyone who makes a > > sip-compliant proxy/registrar/UAS follows this mailing list. And > > people have all kinds of old software out there, which may > be hard to > > upgrade. One only needs to look at the initial Protos test > results to > > get an idea of the potential. > > > > Do we really want CERT Advisories issued, and the root > cause being the > > IETF SIP Working Group??? Ironically, that would be good > for firewall > > and SBC vendors - but not good for SIP. We have to do as much as > > possible to prevent it. > > > > -Hadriel > > > > > >> -----Original Message----- > >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > >> Sent: Thursday, March 30, 2006 1:08 AM > >> To: Cullen Jennings; Dean Willis; sip@ietf.org > >> Cc: Juha Heinanen > >> Subject: Re: [Sip] How to indicate during proxy discovery that a > >> proxysupports"outbound" > >> > >> > On 3/25/06 1:53 PM, "Jeroen van Bemmel" > wrote: > >> > > >> >> Could you explain why it is needed that the UA knows > whether the > >> >> proxy supports outbound before sending its REGISTER request? > >> > > >> > So that we don't send things to the proxy that it does > not understand. > >> > Some > >> > people did not care about this - some felt strongly > about it. Some > >> pointed > >> > out that the proxy might black list a client that seemed to be > >> "attacking > >> > it" with bogus packets. > >> > >> The people that feel strongly about this could add > 'Require: outbound' > >> to their request. Implementations that would blacklist > such clients > >> would be considered broken. > >> > >> An alternative would perhaps be to depend on an > authentication challenge: > >> first send a normal REGISTER, challenge, respond to the > challenge and > >> if > >> Supported: outbound is there modify the request as needed. > Not common > >> practice though... > >> > >> 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 > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 03 10:58:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQQTr-000766-0I; Mon, 03 Apr 2006 10:56:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQQTo-000761-VG for sip@ietf.org; Mon, 03 Apr 2006 10:56:32 -0400 Received: from zproxy.gmail.com ([64.233.162.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQQTn-0005p8-Ny for sip@ietf.org; Mon, 03 Apr 2006 10:56:32 -0400 Received: by zproxy.gmail.com with SMTP id z3so913236nzf for ; Mon, 03 Apr 2006 07:56:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iDEuREKk7CsTSaAg6Da+a+9CLt41IQSziR/9w9UbqjdTiCefngBSgcxXO6W4NSSZEKXMGMg3uKfBmlsqzCvx0PlBhc+x4hlECQ6USz7/pe9LRaZjQwDbkS37y6qwJ2Sx9ZXadRVmHidqqLxTido6C+69NuGLyaQKWo6uhdJnxEU= Received: by 10.65.75.1 with SMTP id c1mr62734qbl; Mon, 03 Apr 2006 07:56:26 -0700 (PDT) Received: by 10.64.49.3 with HTTP; Mon, 3 Apr 2006 07:56:26 -0700 (PDT) Message-ID: Date: Mon, 3 Apr 2006 07:56:26 -0700 From: "Jason Fischl" To: "Drage, Keith (Keith)" Subject: Re: [Sip] draft-tschofenig-sip-saml-05.txt In-Reply-To: <475FF955A05DD411980D00508B6D5FB0127491C5@en0033exch001u.uk.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <475FF955A05DD411980D00508B6D5FB0127491C5@en0033exch001u.uk.lucent.com> 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 I would like to see this draft adopted as a baseline. There are a number of works in progress that depend on this including draft-jennings-sipping-pay-03.txt. Thanks Jason On 3/26/06, Drage, Keith (Keith) wrote: > (As chair) > > At the face-to-face meeting at IETF#65, we discussed http://www.ietf.org/= internet-drafts/draft-tschofenig-sip-saml-05.txt as a possible solution to = the current milestone on "Using SAML for SIP (PS)". > > We are seeking a list hum on whether this draft should be adopted as base= line for this draft, or whether we should seek some other baseline input. > > regards > > Keith > > Keith Drage > drage@lucent.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 Apr 03 11:26:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQQvP-0000WG-Hv; Mon, 03 Apr 2006 11:25:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQQvO-0000VO-TG for sip@ietf.org; Mon, 03 Apr 2006 11:25:02 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQQvN-00071N-KY for sip@ietf.org; Mon, 03 Apr 2006 11:25:02 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id C2D903BE36 for ; Mon, 3 Apr 2006 17:25:00 +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 07651-01-98 for ; Mon, 3 Apr 2006 17:25:00 +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 7DA7A3BE2A for ; Mon, 3 Apr 2006 17:25:00 +0200 (CEST) From: Fredrik Thulin To: sip@ietf.org Date: Mon, 3 Apr 2006 17:24:56 +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: <200604031724.56452.ft@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.499 tagged_above=-99 required=7 tests=[AWL=0.166, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Sip] Outbound: must Registrar also reuse flow? X-BeenThere: sip@ietf.org X-Mailman-Version: 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 the following setup, if the client does Outbound and send a REGISTER towards the Registrar via the edge-proxy EP, UA --|-- EP -- Registrar NAT does the Registrar have to reuse the exact same flow to EP when a new request arrives at Registrar, targeted for UA? The EP obviously has to do so, but does the Registrar also have to? Section 6.1 definately says the Registrar must do so "The registrar MUST store enough information to uniquely identify the network flow over which the request arrived. " but I can't see the point in mandating the exact same flow being used to send subsequent requests from Registrar to EP, if both of them are on the open Internet? /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 Apr 03 11:43:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQRBn-0000tp-Jx; Mon, 03 Apr 2006 11:41:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQRBm-0000tG-JW for sip@ietf.org; Mon, 03 Apr 2006 11:41:58 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQRBk-0007j3-VO for sip@ietf.org; Mon, 03 Apr 2006 11:41:58 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 00EB519445E for ; Mon, 3 Apr 2006 17:41:55 +0200 (CEST) Received: from [192.168.1.29] ([192.168.1.29]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 17:39:48 +0200 In-Reply-To: <200604031724.56452.ft@it.su.se> References: <200604031724.56452.ft@it.su.se> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0143443f83d6a70365e6369f27cbd8d1@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Outbound: must Registrar also reuse flow? Date: Mon, 3 Apr 2006 17:41:25 +0200 To: Fredrik Thulin X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 03 Apr 2006 15:39:48.0735 (UTC) FILETIME=[D73860F0:01C65734] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org There can be multiple EPs that connect to the registrar/proxy. So to ensure that an INVITE, for examples, arrives at the correct EP, you need the registrar/proxy to store such information. Regards, Hisham On Apr 3, 2006, at 5:24 PM, Fredrik Thulin wrote: > > Hi > > In the following setup, if the client does Outbound and send a REGISTER > towards the Registrar via the edge-proxy EP, > > UA --|-- EP -- Registrar > NAT > > does the Registrar have to reuse the exact same flow to EP when a new > request arrives at Registrar, targeted for UA? > > The EP obviously has to do so, but does the Registrar also have to? > > Section 6.1 definately says the Registrar must do so > > "The registrar MUST store enough information to uniquely identify the > network flow over which the request arrived. " > > but I can't see the point in mandating the exact same flow being used > to > send subsequent requests from Registrar to EP, if both of them are on > the open Internet? > > /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 Mon Apr 03 12:11:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQRc5-0007k1-0C; Mon, 03 Apr 2006 12:09:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQRc3-0007jg-UO for sip@ietf.org; Mon, 03 Apr 2006 12:09:07 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQRc2-0000SK-Lp for sip@ietf.org; Mon, 03 Apr 2006 12:09:07 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id C33033BE4A; Mon, 3 Apr 2006 18:09:05 +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 11688-01-51; Mon, 3 Apr 2006 18:09:05 +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 7FFC83BE2A; Mon, 3 Apr 2006 18:09:05 +0200 (CEST) From: Fredrik Thulin To: sip@ietf.org Subject: Re: [Sip] Outbound: must Registrar also reuse flow? Date: Mon, 3 Apr 2006 18:09:01 +0200 User-Agent: KMail/1.9.1 References: <200604031724.56452.ft@it.su.se> <0143443f83d6a70365e6369f27cbd8d1@telio.no> In-Reply-To: <0143443f83d6a70365e6369f27cbd8d1@telio.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200604031809.01991.ft@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.5 tagged_above=-99 required=7 tests=[AWL=0.165, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 On Monday 03 April 2006 17:41, Hisham Khartabil wrote: > There can be multiple EPs that connect to the registrar/proxy. So to > ensure that an INVITE, for examples, arrives at the correct EP, you > need the registrar/proxy to store such information. The registrar stores the RFC3327 Path, where the edge-proxys can put their unique hostnames instead of the common name for all the edge-proxys. The registrar then uses the Path information to send the subsequent requests to the right edge-proxy. /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 Apr 03 12:58:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQSLU-0007rP-TP; Mon, 03 Apr 2006 12:56:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQSLT-0007oz-Am for sip@ietf.org; Mon, 03 Apr 2006 12:56:03 -0400 Received: from smtp1.versatel.nl ([62.58.50.88] helo=smtp3.versatel.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQSLS-0002ps-SI for sip@ietf.org; Mon, 03 Apr 2006 12:56:03 -0400 Received: (qmail 17005 invoked by uid 0); 3 Apr 2006 16:55:58 -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 < >; 3 Apr 2006 16:55:58 -0000 Message-ID: <002c01c6573f$767086c0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Christer Holmberg \(JO/LMF\)" , "Hadriel Kaplan" , References: <5EB80D22825EEE42872083AD5BFFB5945D1C54@esealmw113.eemea.ericsson.se> Subject: Re: [Sip] How to indicate during proxy discoverythataproxysupports"outbound" Date: Mon, 3 Apr 2006 18:55:50 +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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.1 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e 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 Christer, No, I think the outbound proxy shouldn't be touching any Require headers, whether present or not It is up to the UAC to decide whether the request needs a Require header or not. If people have strong feelings against sending a REGISTER request with reg-id parameters etc, then perhaps the draft could say "UAC SHOULD add Require: outbound to the REGISTER request" Though in RFC3329 the proxy does remove the Require header, it seems that outbound is different from sec-agree in this case. Regards, Jeroen ----- Original Message ----- From: "Christer Holmberg (JO/LMF)" To: "Jeroen van Bemmel" ; "Hadriel Kaplan" ; Sent: Monday, April 03, 2006 9:21 AM Subject: RE: [Sip] How to indicate during proxy discoverythataproxysupports"outbound" Hi, In case the outbound proxy and the registrar are NOT the same, I assume that the outbound proxy would not only remove the option tag from the Proxy-Require header, but also from the Require header? Because, as far as I can see there is no reason to require the registrar to also support outbound. Regards, Christer -----Original Message----- From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] Sent: 3. huhtikuuta 2006 9:29 To: Christer Holmberg (JO/LMF); Hadriel Kaplan; sip@ietf.org Subject: Re: [Sip] How to indicate during proxy discoverythataproxysupports"outbound" Christer, Besides detection for support, Proxy-Require is also useful for backwards compatibility Consider how the edge proxy decides whether or not it needs to perform outbound processing. Without Proxy-Require, it would have to either look for 'Require: outbound' or inspect the Contact headers, look for 'reg-id' and assume that means the UAC supports / wants to use outbound. From a protocol purist perspective, both of these alternatives are less preferred than Proxy-Require BTW, section 3.4 should have some text discussing this. It currently says "edge proxy should use Path" but the processing seems to depend on the fact that there is a 'reg-id'. What if there is none? Regards, Jeroen ----- Original Message ----- From: "Christer Holmberg" To: "Hadriel Kaplan" ; Sent: Monday, April 03, 2006 7:33 AM Subject: RE: [Sip] How to indicate during proxy discoverythataproxysupports"outbound" Hi Hadriel, My mail was rabout the OPTIONS alternative. And, you wouldn't even need Require there, because the outbound proxy would simply reply what it supports. In fact, no standardization is required for that, so should we mention it as an option? And, if there are no issues (removal of options tags from the P-R/Require header by proxy) with the REGISTER alternative I don't have any issues with that solution - as long as we document the assumptions and restriction. Regards, Christer Regards, Christr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 03 13:04:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQSRU-00034D-3o; Mon, 03 Apr 2006 13:02:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQSRS-0002vE-5n for sip@ietf.org; Mon, 03 Apr 2006 13:02:14 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQSRR-00036m-BT for sip@ietf.org; Mon, 03 Apr 2006 13:02:14 -0400 Received: (qmail 4866 invoked by uid 0); 3 Apr 2006 17:02:08 -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 < >; 3 Apr 2006 17:02:08 -0000 Message-ID: <003901c65740$53169470$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Drage, Keith \(Keith\)" , "'Patrick Timmons'" , "'Hadriel Kaplan'" , "'Cullen Jennings'" , "'Dean Willis'" , References: <475FF955A05DD411980D00508B6D5FB012967E06@en0033exch001u.uk.lucent.com> Subject: Re: [Sip] How to indicate during proxy discovery thataproxysupports"outbound" Date: Mon, 3 Apr 2006 19:02:00 +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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a4bcf8f67063cac573319207fe3db35 Cc: '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 Keith, You are correct - see http://www1.ietf.org/mail-archive/web/sip/current/msg07871.html JR refers to RFC 3323 also doing this, and agrees that RFC3261 should be updated to allow this sort of behavior Regards, jeroen PS Note that also here it is discussed that the proxy shouldn't touch any Require headers ----- Original Message ----- From: "Drage, Keith (Keith)" To: "'Patrick Timmons'" ; "'Jeroen van Bemmel'" ; "'Hadriel Kaplan'" ; "'Cullen Jennings'" ; "'Dean Willis'" ; Cc: "'Juha Heinanen'" Sent: Monday, April 03, 2006 3:54 PM Subject: RE: [Sip] How to indicate during proxy discovery thataproxysupports"outbound" >I seem to remember we had the list discussion on what RFC3329 did with >Proxy-Require after RFC3329 was published. > > That discussion did not come up with better ways of dealing with the RFC > 3329 issue, but I seem to remember at least one SIP guru disagreeing with > that usage of Proxy-Require. > > regards > > Keith > >> -----Original Message----- >> From: Patrick Timmons [mailto:ptimmons@acmepacket.com] >> Sent: 01 April 2006 02:31 >> To: 'Jeroen van Bemmel'; 'Hadriel Kaplan'; 'Cullen Jennings'; 'Dean >> Willis'; sip@ietf.org >> Cc: 'Juha Heinanen' >> Subject: RE: [Sip] How to indicate during proxy discovery >> thataproxysupports"outbound" >> >> >> Jeroen - >> >> Ah, I wasn't aware that RFC3329 legitimized stripping >> Proxy-Require headers >> for edge proxies. Thanks for the reference. >> >> However -- in a general sense, the issue here is that the UA >> needs to know >> specific features as they pertain to the topology of the >> network; i.e., that >> the *edge* supports 'outbound'. My sense is that it's >> perfectly reasonable >> to think that there will be requirements for UAs to know >> specific features >> of proxies that sit topologically off of the edge (?-CSCF, >> for example). In >> this case, the Proxy-Require technique breaks down... and >> we're left with >> supporting two different methods for achieving (essentially) >> the same ends. >> >> For features that are specific to the edge proxy like >> sec-agree and outbound >> this approach clearly works at least as efficiently as an additional >> round-trip. I'm certainly not opposed to using the >> technique, since RFC3329 >> set the precedent that it is okay to do so. But it seems >> that using OPTIONS >> to query the options of a device is putting the protocol to >> its intended >> use; as to whether this virtue is worth the extra round-trip >> is open for >> debate I suppose. >> >> Maybe I'll go back and read the archives -- this must have >> come up before >> during the development of RFC3329, which was before my time. >> >> pt. >> >> -----Original Message----- >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >> Sent: Friday, March 31, 2006 3:29 PM >> To: Patrick Timmons; 'Hadriel Kaplan'; 'Cullen Jennings'; >> 'Dean Willis'; >> sip@ietf.org >> Cc: 'Juha Heinanen' >> Subject: Re: [Sip] How to indicate during proxy discovery >> thataproxysupports"outbound" >> >> Patrick, >> >> Benefit of that is that it's nice and simple, drawback is an extra >> roundtrip. If you're willing to risk an extra roundtrip, you could do >> slightly better by adding Proxy-Require: outbound to the request, and >> specify proxy behavior similar to RFC3329. In particular, the >> edge proxy >> would be required to remove the Proxy-Require header if it supports >> outbound, and then forward the request (although RFC3261 >> table 2 does not >> allow a proxy to remove a Proxy-Require header, that is what >> is done). A >> non-supporting proxy would respond with an error, and the >> request could be >> retried without outbound. >> >> This approach would only give an extra roundtrip in case the >> edge proxy does >> not support outbound >> >> Regards, >> >> Jeroen >> >> ----- Original Message ----- >> From: "Patrick Timmons" >> To: "'Hadriel Kaplan'" ; "'Jeroen van >> Bemmel'" >> ; "'Cullen Jennings'" ; >> "'Dean Willis'" >> >> ; >> Cc: "'Juha Heinanen'" >> Sent: Friday, March 31, 2006 9:56 PM >> Subject: RE: [Sip] How to indicate during proxy discovery that >> aproxysupports"outbound" >> >> >> > Why not require that the UA send an OPTIONS request to its outbound >> > proxy with Max-Forwards: 0? This jibes with the >> recommendations put >> > forth in RFC >> > 3261 (sec. 11) regarding querying capabilities of proxies: >> > >> > Alternatively, a server receiving an OPTIONS request with a Max- >> > Forwards header field value of 0 MAY respond to the request >> > regardless of the Request-URI. >> > >> > This behavior is common with HTTP/1.1. This behavior >> can be used >> > as a "traceroute" functionality to check the capabilities of >> > individual hop servers by sending a series of OPTIONS requests >> > with incremented Max-Forwards values. >> > >> > The edge proxy could reply to such a request with "Supported: >> > outbound, keepalive-stun", or something along these lines. >> > >> > The registrar's support of sip-outbound could be queried >> similarly. >> > This could be done either prior to, or immediately after initial >> registration. >> > >> > pt. >> > >> > -----Original Message----- >> > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >> > Sent: Thursday, March 30, 2006 4:31 AM >> > To: 'Jeroen van Bemmel'; 'Cullen Jennings'; 'Dean Willis'; >> > sip@ietf.org >> > Cc: 'Juha Heinanen' >> > Subject: RE: [Sip] How to indicate during proxy discovery that >> > aproxysupports"outbound" >> > >> > Hi Jeroen, >> > The whole point is actually to make it a MUST that the UA >> perform a "safe" >> > check, where "safe" means a sip-compliant check, before it does >> > anything bad. It cannot be a choice of a sip-outbound >> compliant UA to >> > just do bad if it wishes. It's not actually the outbound >> sip changes >> > that are the big problem, it's really the binary/stun messages. >> > >> > I'm not overly worried about anyone sending new sip signaling - of >> > course you can send that. Every new draft/RFC does that, and the >> > beauty of SIP is to have that backwards-compatible flexibility. If >> > the new sip-signaling needs to be understood by boxes that >> didn't have >> > to understand it before because they may create issues for >> the legacy >> > sip "network", well that's a problem from a SIP WG >> perspective I would >> > think. And that is also a problem right now, perhaps, if a >> > sip-outbound UA assumes the edge proxy is a sip-outbound >> proxy, when >> > it is not. Right now the draft has no way to let the UA know the >> > edge-proxy supports outbound. It has a way for it to know the >> > registrar does, although even then it doesn't say that >> knowledge must >> > be used for anything. The results of that may lead to constant >> > forking, which is probably not a good thing. >> > >> > But the REAL problem is the UA can send a binary message. I >> > understand why we want to do that, and although I hated the idea at >> > first, I am willing to accept the decision and it's growing on me. >> > BUT, it's still a major issue if UAs can send it when they >> like. They >> > MUST safely check to make sure it's ok. >> > >> > It's not a major issue for my company - our products will >> handle it fine. >> > But I can't speak for others. And not everyone who makes a >> > sip-compliant proxy/registrar/UAS follows this mailing list. And >> > people have all kinds of old software out there, which may >> be hard to >> > upgrade. One only needs to look at the initial Protos test >> results to >> > get an idea of the potential. >> > >> > Do we really want CERT Advisories issued, and the root >> cause being the >> > IETF SIP Working Group??? Ironically, that would be good >> for firewall >> > and SBC vendors - but not good for SIP. We have to do as much as >> > possible to prevent it. >> > >> > -Hadriel >> > >> > >> >> -----Original Message----- >> >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >> >> Sent: Thursday, March 30, 2006 1:08 AM >> >> To: Cullen Jennings; Dean Willis; sip@ietf.org >> >> Cc: Juha Heinanen >> >> Subject: Re: [Sip] How to indicate during proxy discovery that a >> >> proxysupports"outbound" >> >> >> >> > On 3/25/06 1:53 PM, "Jeroen van Bemmel" >> wrote: >> >> > >> >> >> Could you explain why it is needed that the UA knows >> whether the >> >> >> proxy supports outbound before sending its REGISTER request? >> >> > >> >> > So that we don't send things to the proxy that it does >> not understand. >> >> > Some >> >> > people did not care about this - some felt strongly >> about it. Some >> >> pointed >> >> > out that the proxy might black list a client that seemed to be >> >> "attacking >> >> > it" with bogus packets. >> >> >> >> The people that feel strongly about this could add >> 'Require: outbound' >> >> to their request. Implementations that would blacklist >> such clients >> >> would be considered broken. >> >> >> >> An alternative would perhaps be to depend on an >> authentication challenge: >> >> first send a normal REGISTER, challenge, respond to the >> challenge and >> >> if >> >> Supported: outbound is there modify the request as needed. >> Not common >> >> practice though... >> >> >> >> 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 >> > >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip Use >> sipping@ietf.org for new developments on the application of sip >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 03 13:23:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQSjj-0002ic-O7; Mon, 03 Apr 2006 13:21:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQSjh-0002bW-Po for sip@ietf.org; Mon, 03 Apr 2006 13:21:05 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQSjg-0003w4-J7 for sip@ietf.org; Mon, 03 Apr 2006 13:21:05 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 3DE2C6C01F for ; Mon, 3 Apr 2006 13:21:04 -0400 (EDT) Subject: RE: [Sip] draft-ietf-sip-fork-loop-fix From: "Dale R. Worley" To: Sip In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60B3CA638@zrc2hxm2.corp.nortel.com> References: <62B9B0847CC47543B6B3B5E26BD268E60B3CA638@zrc2hxm2.corp.nortel.com> Content-Type: text/plain Date: Mon, 03 Apr 2006 13:21:03 -0400 Message-Id: <1144084864.14420.28.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: 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 On Sat, 2006-04-01 at 16:47 -0600, Samir Srivastava wrote: > It might be better to not reject the REGISTER, since later actions might > cure the loop without altering *this* registration. (Also, since a > rejected registration is not in the database, the next re-registration > attempt also appears to be new, and triggers the loop test again.) > > SS>> Only later *UnRegistration or expired contact* can break the loop. > Proxy P1 is still going to forward Proxy P2, where looped contact is > gone for now, and request is not going to fullfilled with proxy P1 > contact. So it good to reject this registration. And let the > Registering end point figure out where is the loop. If an endpoint keeps > registering again and again with looped causing contacts, trigger this > to IPS/IDS and take out the endpoint. This is very similar to how > repeated 401/407 are handled. If a registration at P1 shows up a loop, the registration for P1 may well be correct, and the error being some configuration problem at P2. So it is helpful to *report* the problem, but I think it is excessive to reject the registration. 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 Apr 03 14:06:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQTPr-00084w-QI; Mon, 03 Apr 2006 14:04:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQTPp-00084r-Ih for sip@ietf.org; Mon, 03 Apr 2006 14:04:37 -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 1FQTPp-0005YR-6G for sip@ietf.org; Mon, 03 Apr 2006 14:04:37 -0400 Received: from BPenfield [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A3B20150; Mon, 03 Apr 2006 14:04:34 -0400 Message-ID: <003701c65749$118a1910$800101df@acmepacket.com> From: "Bob Penfield" To: "Jeroen van Bemmel" , "Christer Holmberg \(JO/LMF\)" , "Hadriel Kaplan" , References: <5EB80D22825EEE42872083AD5BFFB5945D1C54@esealmw113.eemea.ericsson.se> <002c01c6573f$767086c0$31713b51@BEMBUSTER> Subject: Re: [Sip] How to indicate during proxydiscoverythataproxysupports"outbound" Date: Mon, 3 Apr 2006 14:04:36 -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.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 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 inline. ----- Original Message ----- From: "Jeroen van Bemmel" > Christer, > > No, I think the outbound proxy shouldn't be touching any > Require headers, whether present or not > > It is up to the UAC to decide whether the request needs > a Require header or not. If people have strong feelings > against sending a REGISTER request with reg-id parameters > etc, then perhaps the draft could say "UAC SHOULD add > Require: outbound to the REGISTER request" > > Though in RFC3329 the proxy does remove the Require header, > it seems that outbound is different from sec-agree in > this case. > I'm afraid I disagree. I think that 'outbound' is the same as sec-agree in this case. For outbound we need two option tags to make things unambiguous: One for the reusable connection with keepalive behavior that the first hop must do (e.g 'outbound-stun'), and one for the registrar behavior of recognizing reg-id and sip-instance in the Contact (e.g. 'outbound-reg'). Unless the UA knows that the outbound proxy is not the registrar, its first REGISTER will have: Require: outbound-stun, outbound-reg Proxy-Require: outbound-stun outbound-reg is intended for the registrar, and outbound-stun is intended for the first hop. Remember, for REGISTER, the registrar is the UAS, not a proxy. If the first hop is the registrar, the Require header applies, and 'outbound-stun' needs to be there so the registrar does the reusable connection with keepalive. If the first hop is not the registrar, it must remove the 'outbound-stun' tag from both the Require and the Proxy-Require. This is because the 'outbound-stun' feature is applied completely by the first hop proxy. The registrar does not need to do any 'outbound-stun' behavior. It only needs to do 'outbound-reg' behavior. If the tag was left in the Require header, it would a) reject it if it does not support 'outbound-stun'; or b) do the wrong thing by applying 'outbound-stun' behavior. cheers, (-:bob > Regards, > > Jeroen > > ----- Original Message ----- > From: "Christer Holmberg (JO/LMF)" > To: "Jeroen van Bemmel" ; "Hadriel Kaplan" > ; > Sent: Monday, April 03, 2006 9:21 AM > Subject: RE: [Sip] How to indicate during proxy > discoverythataproxysupports"outbound" > > > > Hi, > > In case the outbound proxy and the registrar are NOT the same, I assume > that the outbound proxy would not only remove the option tag from the > Proxy-Require header, but also from the Require header? Because, as far > as I can see there is no reason to require the registrar to also support > outbound. > > Regards, > > Christer > > > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: 3. huhtikuuta 2006 9:29 > To: Christer Holmberg (JO/LMF); Hadriel Kaplan; sip@ietf.org > Subject: Re: [Sip] How to indicate during proxy > discoverythataproxysupports"outbound" > > Christer, > > Besides detection for support, Proxy-Require is also useful for > backwards compatibility > > Consider how the edge proxy decides whether or not it needs to perform > outbound processing. Without Proxy-Require, it would have to either look > for > 'Require: outbound' or inspect the Contact headers, look for 'reg-id' > and assume that means the UAC supports / wants to use outbound. From a > protocol purist perspective, both of these alternatives are less > preferred than Proxy-Require > > BTW, section 3.4 should have some text discussing this. It currently > says "edge proxy should use Path" but the processing seems to depend on > the fact that there is a 'reg-id'. What if there is none? > > Regards, > > Jeroen > > ----- Original Message ----- > From: "Christer Holmberg" > To: "Hadriel Kaplan" ; > Sent: Monday, April 03, 2006 7:33 AM > Subject: RE: [Sip] How to indicate during proxy > discoverythataproxysupports"outbound" > > > Hi Hadriel, > > My mail was rabout the OPTIONS alternative. And, you wouldn't even need > Require there, because the outbound proxy would simply reply what it > supports. In fact, no standardization is required for that, so should we > mention it as an option? > > And, if there are no issues (removal of options tags from the > P-R/Require header by proxy) with the REGISTER alternative I don't have > any issues with that solution - as long as we document the assumptions > and restriction. > > Regards, > > Christer > Regards, > > Christr > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 03 15:01:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQUH3-0007x9-Qf; Mon, 03 Apr 2006 14:59:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQUH2-0007x3-DR for sip@ietf.org; Mon, 03 Apr 2006 14:59:36 -0400 Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56] helo=zrtps0kp.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQUH1-0007Wi-2y for sip@ietf.org; Mon, 03 Apr 2006 14:59:36 -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 k33IxWU26943; Mon, 3 Apr 2006 14:59:32 -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] draft-ietf-sip-fork-loop-fix Date: Mon, 3 Apr 2006 13:59:26 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60B3CB089@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-fork-loop-fix Thread-Index: AcZXQ2NSY2pJ5O3GQSGah/g6/i+XSwAC1mhw From: "Samir Srivastava" To: "Dale R. Worley" , "Sip" X-Spam-Score: 0.1 (/) 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 Dale, Thx for response. See in line. Thx Samir -----Original Message----- From: Dale R. Worley [mailto:dworley@pingtel.com]=20 Sent: Monday, April 03, 2006 10:21 AM To: Sip Subject: RE: [Sip] draft-ietf-sip-fork-loop-fix On Sat, 2006-04-01 at 16:47 -0600, Samir Srivastava wrote: > It might be better to not reject the REGISTER, since later actions=20 > might cure the loop without altering *this* registration. (Also,=20 > since a rejected registration is not in the database, the next=20 > re-registration attempt also appears to be new, and triggers the loop=20 > test again.) >=20 > SS>> Only later *UnRegistration or expired contact* can break the loop. > Proxy P1 is still going to forward Proxy P2, where looped contact is=20 > gone for now, and request is not going to fullfilled with proxy P1=20 > contact. So it good to reject this registration. And let the=20 > Registering end point figure out where is the loop. If an endpoint=20 > keeps registering again and again with looped causing contacts,=20 > trigger this to IPS/IDS and take out the endpoint. This is very=20 > similar to how repeated 401/407 are handled. If a registration at P1 shows up a loop, the registration for P1 may well be correct, and the error being some configuration problem at P2. So it is helpful to *report* the problem, but I think it is excessive to reject the registration. SS>> This is dependent on the order of registration. If P1 got the registration first, then keeping P2 registration is of no value. Since it is looped contact, how one can decide which one to keep. Keeping looped registration alive in the hope of someone will correct them doesn't serve much purpose, if the guy is bad and he doesn't remove it. Time window with looped contacts is open for attackers. Here one can say, if looped contacts are detected, then further requests will not be catered, unless they are corrected i.e. Reject the further request with error code " Looped Contact correction in progress". My position is "Do not let the faults percolate, correct them at the root itself as soon as possible". =20 I am okay to finalize these minor details later, *if there is group consensus that we should take this path*. Group ?? 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 Mon Apr 03 15:05:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQUKv-0001C0-6t; Mon, 03 Apr 2006 15:03:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQUKu-0001Bv-Fk for sip@ietf.org; Mon, 03 Apr 2006 15:03:36 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQUKt-0007iY-QH for sip@ietf.org; Mon, 03 Apr 2006 15:03:36 -0400 Received: (qmail 11141 invoked by uid 0); 3 Apr 2006 19:03:31 -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 < >; 3 Apr 2006 19:03:31 -0000 Message-ID: <006e01c65751$47fba740$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Bob Penfield" , "Christer Holmberg \(JO/LMF\)" , "Hadriel Kaplan" , References: <5EB80D22825EEE42872083AD5BFFB5945D1C54@esealmw113.eemea.ericsson.se> <002c01c6573f$767086c0$31713b51@BEMBUSTER> <003701c65749$118a1910$800101df@acmepacket.com> Subject: Re: [Sip] How to indicate during proxydiscoverythataproxysupports"outbound" Date: Mon, 3 Apr 2006 21:03:20 +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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 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 Bob, Indeed, if a UAC would do as you describe, i.e. > Require: outbound-stun, outbound-reg > Proxy-Require: outbound-stun then the proxy would have to remove both outbound-stun option tags. Outbound is different from RFC3329 in that it still requires specific behavior from the server (registrar) even when one or more proxies are in between (i.e. mapping of incoming requests to the correct flow). In a deployment with one or more proxies, the registrar wouldn't be handling STUN. However, since the registrar must also work in deployments without proxies it needs to support STUN anyway. So in this sense, Supported: outbound-reg would imply Supported: outbound-stun It depends on whether one considers it acceptable for one option-tag to signify different behavior at proxies versus servers. In other words, are we talking about 1 or 2 features? Is there ambiguity? Lets see "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. Note that IMHO the UAC shouldn't try to "optimize" its REGISTER request by omitting the Proxy-Require if it knows that there is a direct connection with the registrar. So there would not be any "unless" rule here Regards, Jeroen ----- Original Message ----- From: "Bob Penfield" To: "Jeroen van Bemmel" ; "Christer Holmberg (JO/LMF)" ; "Hadriel Kaplan" ; Sent: Monday, April 03, 2006 8:04 PM Subject: Re: [Sip] How to indicate during proxydiscoverythataproxysupports"outbound" > inline. > ----- Original Message ----- > From: "Jeroen van Bemmel" > >> Christer, >> >> No, I think the outbound proxy shouldn't be touching any >> Require headers, whether present or not >> >> It is up to the UAC to decide whether the request needs >> a Require header or not. If people have strong feelings >> against sending a REGISTER request with reg-id parameters >> etc, then perhaps the draft could say "UAC SHOULD add >> Require: outbound to the REGISTER request" >> >> Though in RFC3329 the proxy does remove the Require header, >> it seems that outbound is different from sec-agree in >> this case. >> > > I'm afraid I disagree. I think that 'outbound' is the same as sec-agree in > this case. > > For outbound we need two option tags to make things unambiguous: One for > the reusable connection with keepalive behavior that the first hop must do > (e.g 'outbound-stun'), and one for the registrar behavior of recognizing > reg-id and sip-instance in the Contact (e.g. 'outbound-reg'). > > Unless the UA knows that the outbound proxy is not the registrar, its > first REGISTER will have: > > Require: outbound-stun, outbound-reg > Proxy-Require: outbound-stun > > outbound-reg is intended for the registrar, and outbound-stun is intended > for the first hop. > > Remember, for REGISTER, the registrar is the UAS, not a proxy. If the > first hop is the registrar, the Require header applies, and > 'outbound-stun' needs to be there so the registrar does the reusable > connection with keepalive. > > If the first hop is not the registrar, it must remove the 'outbound-stun' > tag from both the Require and the Proxy-Require. This is because the > 'outbound-stun' feature is applied completely by the first hop proxy. The > registrar does not need to do any 'outbound-stun' behavior. It only needs > to do 'outbound-reg' behavior. If the tag was left in the Require header, > it would a) reject it if it does not support 'outbound-stun'; or b) do the > wrong thing by applying 'outbound-stun' behavior. > > cheers, > (-:bob > >> Regards, >> >> Jeroen >> >> ----- Original Message ----- >> From: "Christer Holmberg (JO/LMF)" >> To: "Jeroen van Bemmel" ; "Hadriel Kaplan" >> ; >> Sent: Monday, April 03, 2006 9:21 AM >> Subject: RE: [Sip] How to indicate during proxy >> discoverythataproxysupports"outbound" >> >> >> >> Hi, >> >> In case the outbound proxy and the registrar are NOT the same, I assume >> that the outbound proxy would not only remove the option tag from the >> Proxy-Require header, but also from the Require header? Because, as far >> as I can see there is no reason to require the registrar to also support >> outbound. >> >> Regards, >> >> Christer >> >> >> -----Original Message----- >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >> Sent: 3. huhtikuuta 2006 9:29 >> To: Christer Holmberg (JO/LMF); Hadriel Kaplan; sip@ietf.org >> Subject: Re: [Sip] How to indicate during proxy >> discoverythataproxysupports"outbound" >> >> Christer, >> >> Besides detection for support, Proxy-Require is also useful for >> backwards compatibility >> >> Consider how the edge proxy decides whether or not it needs to perform >> outbound processing. Without Proxy-Require, it would have to either look >> for >> 'Require: outbound' or inspect the Contact headers, look for 'reg-id' >> and assume that means the UAC supports / wants to use outbound. From a >> protocol purist perspective, both of these alternatives are less >> preferred than Proxy-Require >> >> BTW, section 3.4 should have some text discussing this. It currently >> says "edge proxy should use Path" but the processing seems to depend on >> the fact that there is a 'reg-id'. What if there is none? >> >> Regards, >> >> Jeroen >> >> ----- Original Message ----- >> From: "Christer Holmberg" >> To: "Hadriel Kaplan" ; >> Sent: Monday, April 03, 2006 7:33 AM >> Subject: RE: [Sip] How to indicate during proxy >> discoverythataproxysupports"outbound" >> >> >> Hi Hadriel, >> >> My mail was rabout the OPTIONS alternative. And, you wouldn't even need >> Require there, because the outbound proxy would simply reply what it >> supports. In fact, no standardization is required for that, so should we >> mention it as an option? >> >> And, if there are no issues (removal of options tags from the >> P-R/Require header by proxy) with the REGISTER alternative I don't have >> any issues with that solution - as long as we document the assumptions >> and restriction. >> >> Regards, >> >> Christer >> Regards, >> >> Christr >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip Use >> sipping@ietf.org for new developments on the application of sip >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 03 15:51:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQV3U-00012s-S4; Mon, 03 Apr 2006 15:49:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQV3T-00012n-EC for sip@ietf.org; Mon, 03 Apr 2006 15:49:39 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQV3T-0001sC-37 for sip@ietf.org; Mon, 03 Apr 2006 15:49:39 -0400 Received: from [172.17.2.252] (vicuna.estacado.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k33Jnb0N041306 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 3 Apr 2006 14:49:38 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60B3CB089@zrc2hxm2.corp.nortel.com> References: <62B9B0847CC47543B6B3B5E26BD268E60B3CB089@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: verifying registration bindings (was [Sip] draft-ietf-sip-fork-loop-fix) Date: Mon, 3 Apr 2006 14:49:39 -0500 To: Samir Srivastava X-Mailer: Apple Mail (2.746.3) Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 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 Samir - We've talked about approaches similar to this in the past and there is interest in the concept of asking a registrant "Prove to me that I can reach this contact" before accepting a binding. There's been discussion (and even some draft work) around using the consent framework to do something similar (but with greater scope). What we have right now is an agreement to talk about the possible mechanisms, and general recognition that we need something more than what we have right now. We do not have any consensus (IMHO) around a particular mechanism yet. So the plan is to progress the fork-loop-fix draft as is and decouple work on these other potential mechanisms. One comment on the questions you've posted so far: It's unlikely we will be able to create a mechanism that allows us to reject the actual REGISTER request. That puts another operation in the path of a non-INVITE transaction, and we've learned that's a dangerous thing. I suspect we'll end up with a mechanism that puts bindings into an "unconfirmed" state. The registrar will then send something towards the contact asking for proof that it knows about the binding request. Once that proof is obtained, the contact would become confirmed and used by a location server. RjS On Apr 3, 2006, at 1:59 PM, Samir Srivastava wrote: > Hi Dale, > > Thx for response. See in line. > > Thx > Samir > > -----Original Message----- > From: Dale R. Worley [mailto:dworley@pingtel.com] > Sent: Monday, April 03, 2006 10:21 AM > To: Sip > Subject: RE: [Sip] draft-ietf-sip-fork-loop-fix > > On Sat, 2006-04-01 at 16:47 -0600, Samir Srivastava wrote: >> It might be better to not reject the REGISTER, since later actions >> might cure the loop without altering *this* registration. (Also, >> since a rejected registration is not in the database, the next >> re-registration attempt also appears to be new, and triggers the loop >> test again.) >> >> SS>> Only later *UnRegistration or expired contact* can break the > loop. >> Proxy P1 is still going to forward Proxy P2, where looped contact is >> gone for now, and request is not going to fullfilled with proxy P1 >> contact. So it good to reject this registration. And let the >> Registering end point figure out where is the loop. If an endpoint >> keeps registering again and again with looped causing contacts, >> trigger this to IPS/IDS and take out the endpoint. This is very >> similar to how repeated 401/407 are handled. > > If a registration at P1 shows up a loop, the registration for P1 may > well be correct, and the error being some configuration problem at P2. > So it is helpful to *report* the problem, but I think it is > excessive to > reject the registration. > > SS>> This is dependent on the order of registration. If P1 got the > registration first, then keeping > P2 registration is of no value. Since it is looped contact, how one > can > decide which one to keep. > Keeping looped registration alive in the hope of someone will correct > them doesn't serve much purpose, if the guy is bad and he doesn't > remove > it. Time window with looped contacts is open for attackers. Here > one can > say, if looped contacts are detected, then further requests will > not be > catered, unless they are corrected i.e. Reject the further request > with > error code " Looped Contact correction in progress". My position is > "Do > not let the faults percolate, correct them at the root itself as > soon as > possible". > > I am okay to finalize these minor details later, *if there is group > consensus that we should take this path*. Group ?? > > > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 03 15:59:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQVBV-0007M4-0K; Mon, 03 Apr 2006 15:57:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQVBU-0007Ka-3E for sip@ietf.org; Mon, 03 Apr 2006 15:57:56 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQVBT-0002JP-JQ for sip@ietf.org; Mon, 03 Apr 2006 15:57:56 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IX500N01WTE2Y@siemenscomms.co.uk> for sip@ietf.org; Mon, 03 Apr 2006 20:58:26 +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 <0IX500IAUWTEIE@siemenscomms.co.uk>; Mon, 03 Apr 2006 20:58:26 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 03 Apr 2006 20:57:54 +0100 Content-return: allowed Date: Mon, 03 Apr 2006 20:56:27 +0100 From: "Elwell, John" Subject: RE: [Sip] draft-elwell-sip-connected-identity-01.txt To: "Christer Holmberg (JO/LMF)" , "Drage, Keith (Keith)" , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670892FDF1@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: 21be852dc93f0971708678c18d38c096 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 Christer, In-line. John > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:christer.holmberg@ericsson.com] > Sent: 02 April 2006 23:47 > To: Drage, Keith (Keith); sip@ietf.org > Subject: RE: [Sip] draft-elwell-sip-connected-identity-01.txt > > > Hi Keith, > > >The current decision is to see if > http://www.ietf.org/internet-drafts/draft-elwell-sip-connected -identity- > 01.txt forms > >the basis of progressing as a WG item to fulfil our charter item. > > > >As such, it is still discussable and reviewable, but contents have to > abide by WG decision, rather than author > >preference. > > > >The face-to-face meeting said it was, and we are looking to confirm > that decision using the list. > > > >Does your comment indicate merely something missing that can > be added, > or does it indicate that the document is entirely > >in the wrong direction and therefore you object to the face-to-face > meeting decision. > > I think there are things missing, AND I think there are technical > issues. > > 1. Proxy impacts: There are no words on how the chaning of > the URI will > impact intermediate proxies (see separate thread). Normally our > documents contains a "proxy impacts", but not in this. And, > there is no > agreed solution, so I consider that issue both MISSING TEXT and > TECHNICAL. [JRE] Missing text can and will be added - I am already drafting it. The main technical issue (i.e., needing to accommodate change of URI mid-dialog, as anticipated in RFC3261) has been agreed since the face-to-face in Vancouver. I don't see any other technical issue for proxies (other than the impact on an authentication service, which is minor in that it just means the Authentication Service can operate in circumstances where previously it was unable to operate). > > 2. Interworking (e.g. with PSTN): As was mentioned by Roland, this > causes problems with interworking, ie it is not "backward compatible" > with the RFCs we have on interworking. Since we normally, > when we define > extension, try to consider existing extensions and drafts/RFCs I think > we shall do it also in this case - even if some individuals (those > thinking PSTN will be replaced by IP overnight) probably > don't care. So, > I also consider that part both MISSING TEXT and TECHNICAL. [JRE] I consider specifying interworking with PSTN to be outside the scope of this draft (an indeed outside the scope of all work items other than those specifically aimed at PSTN interworking). Introducing the ability to convey connected identity IMPROVES interworking with PSTN compared with the situation at present, because firstly connected identity can be conveyed on establishment of a call to PSTN, and secondly a change of connected identity can be conveyed mid-call. I admit that conveying connected identity during call establishment from PSTN to SIP is more difficult than in the opposite direction, but that does not make it worse than the present situation. I see no reason to block something that is useful just because it does not handle every situation when there is no proposed solution that is acceptable and solves all situations. Response identity, apart from not having a solution that finds favour with the broader community, is unsuitable for mid-dialog changes of identity. > > I also disagree on the face-to-face decission that race > condition is not > an issue. However, I realize that is maybe more an deployment/use-case > issue whether you can expect the UAC to send an UPDATE/re-INVITE soon > after it has received 200 OK for the initial INVITE. [JRE] I am sure we can work out the details of this as the work item progresses. I don't see this as a blocking point. > > Regards, > > Christer > > > > > > > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: 31 March 2006 13:08 > > To: Drage, Keith (Keith); sip@ietf.org > > Subject: RE: [Sip] draft-elwell-sip-connected-identity-01.txt > > > > > > > > Hi Keith, > > > > I sent a mail within the "comments on sip-connected-identity" > > thread. I > > presented some issues with the current solution, but also > pointed out > > that the draft currently does not talk about proxy impacts. > > > > Regards, > > > > Christer > > > > > > > > -----Original Message----- > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > Sent: 26. maaliskuuta 2006 19:25 > > To: sip@ietf.org > > Subject: [Sip] draft-elwell-sip-connected-identity-01.txt > > > > (As chair) > > > > At the face-to-face meeting at IETF 65 we agreed that > > http://www.ietf.org/internet-drafts/draft-elwell-sip-connected > -identity- > 01.txt formed the basis of part of our charter milestone to provide > "Mechanism for Response Identity to IESG (PS). > > This mail is to confirm that decision using the list. If you > have issues > with this decision, please respond to this mail. > > Note: Please keep responses to this thread entirely separate to the > thread on draft-cao-sip-response-identity > > regards > > Keith > > Keith Drage > drage@lucent.com > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Apr 03 16:02:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQVDi-0000go-G2; Mon, 03 Apr 2006 16:00:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQVDh-0000gO-Dt for sip@ietf.org; Mon, 03 Apr 2006 16:00:13 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQVDf-0002Nm-4J for sip@ietf.org; Mon, 03 Apr 2006 16:00:13 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IX500001WX5CO@siemenscomms.co.uk> for sip@ietf.org; Mon, 03 Apr 2006 21:00: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 <0IX50000DWX54D@siemenscomms.co.uk>; Mon, 03 Apr 2006 21:00:41 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 03 Apr 2006 21:00:09 +0100 Content-return: allowed Date: Mon, 03 Apr 2006 20:58:43 +0100 From: "Elwell, John" Subject: RE: [Sip] draft-elwell-sip-connected-identity-01.txt To: Roland Jesske , audet@nortel.com, brett@broadsoft.com, christer.holmberg@ericsson.com, fcao@cisco.com, jdrosen@cisco.com, sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670892FDF2@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: cab78e1e39c4b328567edb48482b6a69 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 Roland, See below. John > -----Original Message----- > From: Roland Jesske [mailto:roland.jesske@web.de] > Sent: 03 April 2006 09:28 > To: audet@nortel.com; brett@broadsoft.com; > christer.holmberg@ericsson.com; fcao@cisco.com; > jdrosen@cisco.com; Elwell, John; sip@ietf.org > Subject: [Sip] draft-elwell-sip-connected-identity-01.txt > > > Feng Chao worte: > > The alternatives you brought up still need one mechanism to > protect the integrity of the connected-id. UPDATE leverages > the > identity work from Jon and Cullen. That is the reason > that this connected-id issue can be easily covered by the > identity work. > > > Why not just insert response identity into response? This > is more generic and requires no additional response code ... > > Yes that would be one solution from my point of view that can > be used. I'm open to solutions where we get the connected > information within the response to the INVITE. And not using > a second Request-Response cycle. [JRE] I understand the benefit of this, and it would be simple to define a Response-Identity header that would do this. But we don't have a solution for authenticating it at present. Without authentication it is no better than P-Asserted-Identity, so within a trusted environment use that. Progress of the connected-identity draft need not prevent people continuing to search for a response identity solution, and indeed I would be happy if we could find a solution. But that would be complementary to the connected-identity solution. > > Roland > > > _______________________________________________________________ > SMS schreiben mit WEB.DE FreeMail - einfach, schnell und > kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 03 16:05:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQVGs-000440-HY; Mon, 03 Apr 2006 16:03:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQVGq-00043v-8O for sip@ietf.org; Mon, 03 Apr 2006 16:03:28 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQVGp-0002Yy-Kc for sip@ietf.org; Mon, 03 Apr 2006 16:03:28 -0400 Received: (qmail 17689 invoked by uid 0); 3 Apr 2006 20:03:23 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 3 Apr 2006 20:03:23 -0000 Message-ID: <000601c65759$a4deab80$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Robert Sparks" , "Samir Srivastava" References: <62B9B0847CC47543B6B3B5E26BD268E60B3CB089@zrc2hxm2.corp.nortel.com> Subject: Re: verifying registration bindings (was [Sip]draft-ietf-sip-fork-loop-fix) Date: Mon, 3 Apr 2006 22:03: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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 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 Robert, Also for the connection reuse draft it seems we will need a kind of "reverse challenge" mechanism to verify that a client requesting an alias actually owns / listens on the port that it is trying to shortcut (Via port instead of Contact, but similar). When you say "in the path of a non-INVITE transaction", you mean the following would be bad? UAC UAS | nit | |----------->| | 100 | // or some other 1xx meaning "challenging..." |<-----------| | challenge | |<-----------| | answer | |----------->| | | | ok nit | |<-----------| Regards, Jeroen ----- Original Message ----- From: "Robert Sparks" To: "Samir Srivastava" Cc: "Sip" Sent: Monday, April 03, 2006 9:49 PM Subject: verifying registration bindings (was [Sip]draft-ietf-sip-fork-loop-fix) > Samir - > > We've talked about approaches similar to this in the past and there is > interest in > the concept of asking a registrant "Prove to me that I can reach this > contact" before > accepting a binding. There's been discussion (and even some draft work) > around > using the consent framework to do something similar (but with greater > scope). > > What we have right now is an agreement to talk about the possible > mechanisms, > and general recognition that we need something more than what we have > right now. > > We do not have any consensus (IMHO) around a particular mechanism yet. So > the > plan is to progress the fork-loop-fix draft as is and decouple work on > these other > potential mechanisms. > > One comment on the questions you've posted so far: It's unlikely we will > be able > to create a mechanism that allows us to reject the actual REGISTER > request. That > puts another operation in the path of a non-INVITE transaction, and we've > learned > that's a dangerous thing. I suspect we'll end up with a mechanism that > puts bindings > into an "unconfirmed" state. The registrar will then send something > towards the contact > asking for proof that it knows about the binding request. Once that proof > is obtained, > the contact would become confirmed and used by a location server. > > RjS > > On Apr 3, 2006, at 1:59 PM, Samir Srivastava wrote: > >> Hi Dale, >> >> Thx for response. See in line. >> >> Thx >> Samir >> >> -----Original Message----- >> From: Dale R. Worley [mailto:dworley@pingtel.com] >> Sent: Monday, April 03, 2006 10:21 AM >> To: Sip >> Subject: RE: [Sip] draft-ietf-sip-fork-loop-fix >> >> On Sat, 2006-04-01 at 16:47 -0600, Samir Srivastava wrote: >>> It might be better to not reject the REGISTER, since later actions >>> might cure the loop without altering *this* registration. (Also, >>> since a rejected registration is not in the database, the next >>> re-registration attempt also appears to be new, and triggers the loop >>> test again.) >>> >>> SS>> Only later *UnRegistration or expired contact* can break the >> loop. >>> Proxy P1 is still going to forward Proxy P2, where looped contact is >>> gone for now, and request is not going to fullfilled with proxy P1 >>> contact. So it good to reject this registration. And let the >>> Registering end point figure out where is the loop. If an endpoint >>> keeps registering again and again with looped causing contacts, >>> trigger this to IPS/IDS and take out the endpoint. This is very >>> similar to how repeated 401/407 are handled. >> >> If a registration at P1 shows up a loop, the registration for P1 may >> well be correct, and the error being some configuration problem at P2. >> So it is helpful to *report* the problem, but I think it is excessive to >> reject the registration. >> >> SS>> This is dependent on the order of registration. If P1 got the >> registration first, then keeping >> P2 registration is of no value. Since it is looped contact, how one can >> decide which one to keep. >> Keeping looped registration alive in the hope of someone will correct >> them doesn't serve much purpose, if the guy is bad and he doesn't remove >> it. Time window with looped contacts is open for attackers. Here one can >> say, if looped contacts are detected, then further requests will not be >> catered, unless they are corrected i.e. Reject the further request with >> error code " Looped Contact correction in progress". My position is "Do >> not let the faults percolate, correct them at the root itself as soon as >> possible". >> >> I am okay to finalize these minor details later, *if there is group >> consensus that we should take this path*. Group ?? >> >> >> >> 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 > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 03 16:12:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQVNh-0008GH-9V; Mon, 03 Apr 2006 16:10:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQVNg-0008G4-8v for sip@ietf.org; Mon, 03 Apr 2006 16:10:32 -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 1FQVNe-0002n9-Lo for sip@ietf.org; Mon, 03 Apr 2006 16:10:32 -0400 Received: from BPenfield [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A133026C; Mon, 03 Apr 2006 16:10:27 -0400 Message-ID: <001e01c6575a$a7856c10$800101df@acmepacket.com> From: "Bob Penfield" To: "Jeroen van Bemmel" , "Christer Holmberg \(JO/LMF\)" , "Hadriel Kaplan" , References: <5EB80D22825EEE42872083AD5BFFB5945D1C54@esealmw113.eemea.ericsson.se> <002c01c6573f$767086c0$31713b51@BEMBUSTER> <003701c65749$118a1910$800101df@acmepacket.com> <006e01c65751$47fba740$31713b51@BEMBUSTER> Subject: Re: [Sip] How to indicate during proxydiscoverythataproxysupports"outbound" Date: Mon, 3 Apr 2006 16:10:29 -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.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d 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 Jeroen, My point is that there are two sets of behaviors. The 'outbound-stun' can still be used by UAs that do not set up redundant connections (i.e. it will not include sip-instance or reg-id and will not include Require:outbound-reg). In that case, if there is an outbound proxy between the UA and the registrar, the registrar does not need to support 'outbound-stun'. The ambiguity comes into play at the registrar. If there was only one tag, and the registrar saw it in the Require header, would that mean that it should expect STUN keepalive's from the edge proxy? Or just look for reg-id and sip-instance in the Contacts? or both? cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 bpenfield@acmepacket.com ----- Original Message ----- From: "Jeroen van Bemmel" To: "Bob Penfield" ; "Christer Holmberg (JO/LMF)" ; "Hadriel Kaplan" ; Sent: Monday, April 03, 2006 3:03 PM Subject: Re: [Sip] How to indicate during proxydiscoverythataproxysupports"outbound" > Bob, > > Indeed, if a UAC would do as you describe, i.e. > >> Require: outbound-stun, outbound-reg >> Proxy-Require: outbound-stun > > then the proxy would have to remove both outbound-stun option tags. > > Outbound is different from RFC3329 in that it still requires specific > behavior from the server (registrar) even when one or more proxies are in > between (i.e. mapping of incoming requests to the correct flow). In a > deployment with one or more proxies, the registrar wouldn't be handling > STUN. However, since the registrar must also work in deployments without > proxies it needs to support STUN anyway. So in this sense, Supported: > outbound-reg would imply Supported: outbound-stun > > It depends on whether one considers it acceptable for one option-tag to > signify different behavior at proxies versus servers. In other words, are > we talking about 1 or 2 features? Is there ambiguity? Lets see > > "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. > > Note that IMHO the UAC shouldn't try to "optimize" its REGISTER request by > omitting the Proxy-Require if it knows that there is a direct connection > with the registrar. So there would not be any "unless" rule here > > Regards, > > Jeroen > > ----- Original Message ----- > From: "Bob Penfield" > To: "Jeroen van Bemmel" ; "Christer Holmberg (JO/LMF)" > ; "Hadriel Kaplan" > ; > Sent: Monday, April 03, 2006 8:04 PM > Subject: Re: [Sip] How to indicate during > proxydiscoverythataproxysupports"outbound" > > >> inline. >> ----- Original Message ----- >> From: "Jeroen van Bemmel" >> >>> Christer, >>> >>> No, I think the outbound proxy shouldn't be touching any >>> Require headers, whether present or not >>> >>> It is up to the UAC to decide whether the request needs >>> a Require header or not. If people have strong feelings >>> against sending a REGISTER request with reg-id parameters >>> etc, then perhaps the draft could say "UAC SHOULD add >>> Require: outbound to the REGISTER request" >>> >>> Though in RFC3329 the proxy does remove the Require header, >>> it seems that outbound is different from sec-agree in >>> this case. >>> >> >> I'm afraid I disagree. I think that 'outbound' is the same as sec-agree >> in this case. >> >> For outbound we need two option tags to make things unambiguous: One for >> the reusable connection with keepalive behavior that the first hop must >> do (e.g 'outbound-stun'), and one for the registrar behavior of >> recognizing reg-id and sip-instance in the Contact (e.g. 'outbound-reg'). >> >> Unless the UA knows that the outbound proxy is not the registrar, its >> first REGISTER will have: >> >> Require: outbound-stun, outbound-reg >> Proxy-Require: outbound-stun >> >> outbound-reg is intended for the registrar, and outbound-stun is intended >> for the first hop. >> >> Remember, for REGISTER, the registrar is the UAS, not a proxy. If the >> first hop is the registrar, the Require header applies, and >> 'outbound-stun' needs to be there so the registrar does the reusable >> connection with keepalive. >> >> If the first hop is not the registrar, it must remove the 'outbound-stun' >> tag from both the Require and the Proxy-Require. This is because the >> 'outbound-stun' feature is applied completely by the first hop proxy. The >> registrar does not need to do any 'outbound-stun' behavior. It only needs >> to do 'outbound-reg' behavior. If the tag was left in the Require header, >> it would a) reject it if it does not support 'outbound-stun'; or b) do >> the wrong thing by applying 'outbound-stun' behavior. >> >> cheers, >> (-:bob >> >>> Regards, >>> >>> Jeroen >>> >>> ----- Original Message ----- >>> From: "Christer Holmberg (JO/LMF)" >>> To: "Jeroen van Bemmel" ; "Hadriel Kaplan" >>> ; >>> Sent: Monday, April 03, 2006 9:21 AM >>> Subject: RE: [Sip] How to indicate during proxy >>> discoverythataproxysupports"outbound" >>> >>> >>> >>> Hi, >>> >>> In case the outbound proxy and the registrar are NOT the same, I assume >>> that the outbound proxy would not only remove the option tag from the >>> Proxy-Require header, but also from the Require header? Because, as far >>> as I can see there is no reason to require the registrar to also support >>> outbound. >>> >>> Regards, >>> >>> Christer >>> >>> >>> -----Original Message----- >>> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >>> Sent: 3. huhtikuuta 2006 9:29 >>> To: Christer Holmberg (JO/LMF); Hadriel Kaplan; sip@ietf.org >>> Subject: Re: [Sip] How to indicate during proxy >>> discoverythataproxysupports"outbound" >>> >>> Christer, >>> >>> Besides detection for support, Proxy-Require is also useful for >>> backwards compatibility >>> >>> Consider how the edge proxy decides whether or not it needs to perform >>> outbound processing. Without Proxy-Require, it would have to either look >>> for >>> 'Require: outbound' or inspect the Contact headers, look for 'reg-id' >>> and assume that means the UAC supports / wants to use outbound. From a >>> protocol purist perspective, both of these alternatives are less >>> preferred than Proxy-Require >>> >>> BTW, section 3.4 should have some text discussing this. It currently >>> says "edge proxy should use Path" but the processing seems to depend on >>> the fact that there is a 'reg-id'. What if there is none? >>> >>> Regards, >>> >>> Jeroen >>> >>> ----- Original Message ----- >>> From: "Christer Holmberg" >>> To: "Hadriel Kaplan" ; >>> Sent: Monday, April 03, 2006 7:33 AM >>> Subject: RE: [Sip] How to indicate during proxy >>> discoverythataproxysupports"outbound" >>> >>> >>> Hi Hadriel, >>> >>> My mail was rabout the OPTIONS alternative. And, you wouldn't even need >>> Require there, because the outbound proxy would simply reply what it >>> supports. In fact, no standardization is required for that, so should we >>> mention it as an option? >>> >>> And, if there are no issues (removal of options tags from the >>> P-R/Require header by proxy) with the REGISTER alternative I don't have >>> any issues with that solution - as long as we document the assumptions >>> and restriction. >>> >>> Regards, >>> >>> Christer >>> Regards, >>> >>> Christr >>> >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sipping@ietf.org for new developments on the application of sip >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >> > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 03 16:44:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQVsN-0003Vc-Ud; Mon, 03 Apr 2006 16:42:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQVsM-0003VX-Oj for sip@ietf.org; Mon, 03 Apr 2006 16:42:14 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQVsL-0004oy-K3 for sip@ietf.org; Mon, 03 Apr 2006 16:42:14 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A61A73B7; Mon, 3 Apr 2006 22:42:12 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 22:42:12 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 22:42: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="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-elwell-sip-connected-identity-01.txt Date: Mon, 3 Apr 2006 22:42:11 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1C73@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-elwell-sip-connected-identity-01.txt Thread-Index: AcZXWOsHx2SEuFutQyCmzxkbjBcmQAABDl+Q From: "Christer Holmberg \(JO/LMF\)" To: "Elwell, John" , "Drage, Keith \(Keith\)" , X-OriginalArrivalTime: 03 Apr 2006 20:42:12.0140 (UTC) FILETIME=[158846C0:01C6575F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a 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 John, Inline.=20 >1. Proxy impacts: There are no words on how the chaning of the URI=20 >will impact intermediate proxies (see separate thread). Normally our=20 >documents contains a "proxy impacts", but not in this. And, there is=20 >no agreed solution, so I consider that issue both MISSING TEXT and=20 >TECHNICAL. [JRE] Missing text can and will be added - I am already drafting it. The main technical issue (i.e., needing to accommodate change of URI mid-dialog, as anticipated in RFC3261) has been agreed since the face-to-face in Vancouver. I don't see any other technical issue for proxies (other than the impact on an authentication service, which is minor in that it just means the Authentication Service can operate in circumstances where previously it was unable to operate). [CHH] The impact is that a RFC2543 uses, as far as I know, the whole To header (not only the tag) to identify a dialog. So, if you send an UPDATE with a new To header URI, such proxy will not recognize the dialog. Now, if you are saying that we don't need to take backward compability into consideration I don't agree with the statement that chaning the To header URI in a response would break any transaction rules. Because, as I said earlier, the To header URI is not used for transaction identification in RFC3261. [/CHH] >2. Interworking (e.g. with PSTN): As was mentioned by Roland, this=20 >causes problems with interworking, ie it is not "backward compatible" >with the RFCs we have on interworking. Since we normally, when we=20 >define extension, try to consider existing extensions and drafts/RFCs=20 >I think we shall do it also in this case - even if some individuals=20 >(those thinking PSTN will be replaced by IP overnight) probably don't=20 >care. So, I also consider that part both MISSING TEXT and TECHNICAL. [JRE] I consider specifying interworking with PSTN to be outside the scope of this draft (an indeed outside the scope of all work items other than those specifically aimed at PSTN interworking). [CHH] I am not asking you to document PSTN interworking in the draft. I am saying that draft won't work with our current PSTN interworking specifications. Has there been a decission that we don't need to care about that? [/CHH] >Introducing the ability to convey connected identity IMPROVES interworking with PSTN compared with the situation at=20 >present, because firstly connected identity can be conveyed on establishment of a call to PSTN, and secondly a change of=20 >connected identity can be conveyed mid-call. [CHH] Ok, so if you think it improves interworking, how are you going to signal the mid-call change in PSTN, after you've sent CON/ANM (which the 200 OK triggers)? [/CHH] >I admit that conveying connected identity during call establishment from PSTN to SIP is more difficult than in the=20 >opposite direction, but that does not make it worse than the present situation. I see no reason to block something that=20 >is useful just because it does not handle every situation when there is no proposed solution that is acceptable and=20 >solves all situations. [CHH] Personally I think that a solution that does not handle the interworking situation makes the solution pretty much unusable - especially in networks where interworking occurs. Someone may say the number of those networks is so small that we don't have to take that use-case into consideration, but personally I disagree. [/CHH] >Response identity, apart from not having a solution that finds favour with the broader community, is unsuitable for mid- >dialog changes of identity. [CHH] I am not saying that we shall disallow using UPDATE to change the identity mid-call, as currently defined (you wouldn't need to interwork that into PSTN, I believe). I am asking for the possibility to also change it in responses, in order to make it useful also with PSTN interworking. [/CHH] >I also disagree on the face-to-face decission that race condition is=20 >not an issue. However, I realize that is maybe more an=20 >deployment/use-case issue whether you can expect the UAC to send an=20 >UPDATE/re-INVITE soon after it has received 200 OK for the initial=20 >INVITE. [JRE] I am sure we can work out the details of this as the work item progresses. I don't see this as a blocking point. [CHH] My intention is not to block. I was asked about what my issues are, and I listed them :) Regards, Christer >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: 31 March 2006 13:08 > > To: Drage, Keith (Keith); sip@ietf.org > > Subject: RE: [Sip] draft-elwell-sip-connected-identity-01.txt > >=20 > >=20 > >=20 > > Hi Keith, > >=20 > > I sent a mail within the "comments on sip-connected-identity"=20 > > thread. I > > presented some issues with the current solution, but also > pointed out > > that the draft currently does not talk about proxy impacts. > >=20 > > Regards, > >=20 > > Christer > >=20 > > =20 > >=20 > > -----Original Message----- > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > Sent: 26. maaliskuuta 2006 19:25 > > To: sip@ietf.org > > Subject: [Sip] draft-elwell-sip-connected-identity-01.txt > >=20 > > (As chair) > >=20 > > At the face-to-face meeting at IETF 65 we agreed that=20 > > http://www.ietf.org/internet-drafts/draft-elwell-sip-connected > -identity- > 01.txt formed the basis of part of our charter milestone to provide=20 > "Mechanism for Response Identity to IESG (PS). >=20 > This mail is to confirm that decision using the list. If you have=20 > issues with this decision, please respond to this mail. >=20 > Note: Please keep responses to this thread entirely separate to the=20 > thread on draft-cao-sip-response-identity >=20 > regards >=20 > Keith >=20 > Keith Drage > drage@lucent.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=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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 03 16:45:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQVtL-0004AS-Qm; Mon, 03 Apr 2006 16:43:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQVtK-0004AH-JI for sip@ietf.org; Mon, 03 Apr 2006 16:43:14 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQVtJ-0004qh-Pr for sip@ietf.org; Mon, 03 Apr 2006 16:43:14 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0BA35B2E; Mon, 3 Apr 2006 22:43:13 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 22:43:12 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 22:43: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="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] How to indicate duringproxydiscoverythataproxysupports"outbound" Date: Mon, 3 Apr 2006 22:43:12 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1C74@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] How to indicate duringproxydiscoverythataproxysupports"outbound" Thread-Index: AcZXSR6UGFTdyfqpQIuVUKr6K/jpKQAEwzHg From: "Christer Holmberg \(JO/LMF\)" To: "Bob Penfield" , "Jeroen van Bemmel" , "Hadriel Kaplan" , X-OriginalArrivalTime: 03 Apr 2006 20:43:12.0673 (UTC) FILETIME=[399CE110:01C6575F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb 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, I agree with Bob. I don't think the registrar should be required to support something it absolutely doesn't have to care about... I would just cause unecessary roundtrips. Regards, Christer=20 -----Original Message----- From: Bob Penfield [mailto:BPenfield@acmepacket.com]=20 Sent: 3. huhtikuuta 2006 21:05 To: Jeroen van Bemmel; Christer Holmberg (JO/LMF); Hadriel Kaplan; sip@ietf.org Subject: Re: [Sip] How to indicate duringproxydiscoverythataproxysupports"outbound" inline. ----- Original Message ----- From: "Jeroen van Bemmel" > Christer, > > No, I think the outbound proxy shouldn't be touching any Require=20 > headers, whether present or not > > It is up to the UAC to decide whether the request needs a Require=20 > header or not. If people have strong feelings against sending a=20 > REGISTER request with reg-id parameters etc, then perhaps the draft=20 > could say "UAC SHOULD add > Require: outbound to the REGISTER request" > > Though in RFC3329 the proxy does remove the Require header, it seems=20 > that outbound is different from sec-agree in this case. > I'm afraid I disagree. I think that 'outbound' is the same as sec-agree in=20 this case. For outbound we need two option tags to make things unambiguous: One for the=20 reusable connection with keepalive behavior that the first hop must do (e.g=20 'outbound-stun'), and one for the registrar behavior of recognizing reg-id=20 and sip-instance in the Contact (e.g. 'outbound-reg'). Unless the UA knows that the outbound proxy is not the registrar, its first=20 REGISTER will have: Require: outbound-stun, outbound-reg Proxy-Require: outbound-stun outbound-reg is intended for the registrar, and outbound-stun is intended=20 for the first hop. Remember, for REGISTER, the registrar is the UAS, not a proxy. If the first=20 hop is the registrar, the Require header applies, and 'outbound-stun' needs=20 to be there so the registrar does the reusable connection with keepalive. If the first hop is not the registrar, it must remove the 'outbound-stun'=20 tag from both the Require and the Proxy-Require. This is because the=20 'outbound-stun' feature is applied completely by the first hop proxy. The=20 registrar does not need to do any 'outbound-stun' behavior. It only needs to=20 do 'outbound-reg' behavior. If the tag was left in the Require header, it=20 would a) reject it if it does not support 'outbound-stun'; or b) do the=20 wrong thing by applying 'outbound-stun' behavior. cheers, (-:bob > Regards, > > Jeroen > > ----- Original Message -----=20 > From: "Christer Holmberg (JO/LMF)" > To: "Jeroen van Bemmel" ; "Hadriel Kaplan"=20 > ; > Sent: Monday, April 03, 2006 9:21 AM > Subject: RE: [Sip] How to indicate during proxy=20 > discoverythataproxysupports"outbound" > > > > Hi, > > In case the outbound proxy and the registrar are NOT the same, I assume > that the outbound proxy would not only remove the option tag from the > Proxy-Require header, but also from the Require header? Because, as far > as I can see there is no reason to require the registrar to also support > outbound. > > Regards, > > Christer > > > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: 3. huhtikuuta 2006 9:29 > To: Christer Holmberg (JO/LMF); Hadriel Kaplan; sip@ietf.org > Subject: Re: [Sip] How to indicate during proxy > discoverythataproxysupports"outbound" > > Christer, > > Besides detection for support, Proxy-Require is also useful for > backwards compatibility > > Consider how the edge proxy decides whether or not it needs to perform > outbound processing. Without Proxy-Require, it would have to either look > for > 'Require: outbound' or inspect the Contact headers, look for 'reg-id' > and assume that means the UAC supports / wants to use outbound. From a > protocol purist perspective, both of these alternatives are less > preferred than Proxy-Require > > BTW, section 3.4 should have some text discussing this. It currently > says "edge proxy should use Path" but the processing seems to depend on > the fact that there is a 'reg-id'. What if there is none? > > Regards, > > Jeroen > > ----- Original Message ----- > From: "Christer Holmberg" > To: "Hadriel Kaplan" ; > Sent: Monday, April 03, 2006 7:33 AM > Subject: RE: [Sip] How to indicate during proxy > discoverythataproxysupports"outbound" > > > Hi Hadriel, > > My mail was rabout the OPTIONS alternative. And, you wouldn't even need > Require there, because the outbound proxy would simply reply what it > supports. In fact, no standardization is required for that, so should we > mention it as an option? > > And, if there are no issues (removal of options tags from the > P-R/Require header by proxy) with the REGISTER alternative I don't have > any issues with that solution - as long as we document the assumptions > and restriction. > > Regards, > > Christer > Regards, > > Christr > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Mon Apr 03 16:47:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQVvC-000500-2l; Mon, 03 Apr 2006 16:45:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQVvA-0004w0-3I for sip@ietf.org; Mon, 03 Apr 2006 16:45:08 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQVv9-0004tq-9s for sip@ietf.org; Mon, 03 Apr 2006 16:45:08 -0400 Received: (qmail 14762 invoked by uid 0); 3 Apr 2006 20:45:05 -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 < >; 3 Apr 2006 20:45:05 -0000 Message-ID: <001901c6575f$785d5510$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Bob Penfield" , "Christer Holmberg \(JO/LMF\)" , "Hadriel Kaplan" , References: <5EB80D22825EEE42872083AD5BFFB5945D1C54@esealmw113.eemea.ericsson.se> <002c01c6573f$767086c0$31713b51@BEMBUSTER> <003701c65749$118a1910$800101df@acmepacket.com> <006e01c65751$47fba740$31713b51@BEMBUSTER> <001e01c6575a$a7856c10$800101df@acmepacket.com> Subject: Re: [Sip] How to indicate during proxydiscoverythataproxysupports"outbound" Date: Mon, 3 Apr 2006 22:44:57 +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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 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 Bob, see inline rgrds, jerone ----- Original Message ----- From: "Bob Penfield" To: "Jeroen van Bemmel" ; "Christer Holmberg (JO/LMF)" ; "Hadriel Kaplan" ; Sent: Monday, April 03, 2006 10:10 PM Subject: Re: [Sip] How to indicate during proxydiscoverythataproxysupports"outbound" > Jeroen, > > My point is that there are two sets of behaviors. The 'outbound-stun' can > still be used by UAs that do not set up redundant connections (i.e. it > will not include sip-instance or reg-id and will not include > Require:outbound-reg). In that case, if there is an outbound proxy between > the UA and the registrar, the registrar does not need to support > 'outbound-stun'. > The above seems true only for UDP. Even for a single TCP connection, the UA would have to specify the flow identification components (i.e. sip-instance + reg-id, latter could be implied if absent). If not, what would be the point of keeping the flow alive? Inbound requests would not be routed via it (unless the connection reuse mechanism was used, but the scoping of these drafts was intentionally separated: for NAT traversal, only outbound is applicable) STUN for UDP only is currently already possible without any support from registrar or edge proxies. So what "outbound-stun" would do is direct STUN traffic to the outbound proxy instead of some global STUN server? > The ambiguity comes into play at the registrar. If there was only one tag, > and the registrar saw it in the Require header, would that mean that it > should expect STUN keepalive's from the edge proxy? Or just look for > reg-id and sip-instance in the Contacts? or both? > As far as I understood the edge proxy would never send STUN keepalive requests. If it would, additional processing rules are needed (e.g. not remove the Proxy-Require because next hop must support STUN too). So Require would always mean: look for reg-id + sip-instance, setup flow mapping > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 71 Third Avenue > Burlington, MA 01803 > bpenfield@acmepacket.com > > ----- Original Message ----- > From: "Jeroen van Bemmel" > To: "Bob Penfield" ; "Christer Holmberg > (JO/LMF)" ; "Hadriel Kaplan" > ; > Sent: Monday, April 03, 2006 3:03 PM > Subject: Re: [Sip] How to indicate during > proxydiscoverythataproxysupports"outbound" > > >> Bob, >> >> Indeed, if a UAC would do as you describe, i.e. >> >>> Require: outbound-stun, outbound-reg >>> Proxy-Require: outbound-stun >> >> then the proxy would have to remove both outbound-stun option tags. >> >> Outbound is different from RFC3329 in that it still requires specific >> behavior from the server (registrar) even when one or more proxies are in >> between (i.e. mapping of incoming requests to the correct flow). In a >> deployment with one or more proxies, the registrar wouldn't be handling >> STUN. However, since the registrar must also work in deployments without >> proxies it needs to support STUN anyway. So in this sense, Supported: >> outbound-reg would imply Supported: outbound-stun >> >> It depends on whether one considers it acceptable for one option-tag to >> signify different behavior at proxies versus servers. In other words, are >> we talking about 1 or 2 features? Is there ambiguity? Lets see >> >> "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. >> >> Note that IMHO the UAC shouldn't try to "optimize" its REGISTER request >> by omitting the Proxy-Require if it knows that there is a direct >> connection with the registrar. So there would not be any "unless" rule >> here >> >> Regards, >> >> Jeroen >> >> ----- Original Message ----- >> From: "Bob Penfield" >> To: "Jeroen van Bemmel" ; "Christer Holmberg (JO/LMF)" >> ; "Hadriel Kaplan" >> ; >> Sent: Monday, April 03, 2006 8:04 PM >> Subject: Re: [Sip] How to indicate during >> proxydiscoverythataproxysupports"outbound" >> >> >>> inline. >>> ----- Original Message ----- >>> From: "Jeroen van Bemmel" >>> >>>> Christer, >>>> >>>> No, I think the outbound proxy shouldn't be touching any >>>> Require headers, whether present or not >>>> >>>> It is up to the UAC to decide whether the request needs >>>> a Require header or not. If people have strong feelings >>>> against sending a REGISTER request with reg-id parameters >>>> etc, then perhaps the draft could say "UAC SHOULD add >>>> Require: outbound to the REGISTER request" >>>> >>>> Though in RFC3329 the proxy does remove the Require header, >>>> it seems that outbound is different from sec-agree in >>>> this case. >>>> >>> >>> I'm afraid I disagree. I think that 'outbound' is the same as sec-agree >>> in this case. >>> >>> For outbound we need two option tags to make things unambiguous: One for >>> the reusable connection with keepalive behavior that the first hop must >>> do (e.g 'outbound-stun'), and one for the registrar behavior of >>> recognizing reg-id and sip-instance in the Contact (e.g. >>> 'outbound-reg'). >>> >>> Unless the UA knows that the outbound proxy is not the registrar, its >>> first REGISTER will have: >>> >>> Require: outbound-stun, outbound-reg >>> Proxy-Require: outbound-stun >>> >>> outbound-reg is intended for the registrar, and outbound-stun is >>> intended for the first hop. >>> >>> Remember, for REGISTER, the registrar is the UAS, not a proxy. If the >>> first hop is the registrar, the Require header applies, and >>> 'outbound-stun' needs to be there so the registrar does the reusable >>> connection with keepalive. >>> >>> If the first hop is not the registrar, it must remove the >>> 'outbound-stun' tag from both the Require and the Proxy-Require. This is >>> because the 'outbound-stun' feature is applied completely by the first >>> hop proxy. The registrar does not need to do any 'outbound-stun' >>> behavior. It only needs to do 'outbound-reg' behavior. If the tag was >>> left in the Require header, it would a) reject it if it does not support >>> 'outbound-stun'; or b) do the wrong thing by applying 'outbound-stun' >>> behavior. >>> >>> cheers, >>> (-:bob >>> >>>> Regards, >>>> >>>> Jeroen >>>> >>>> ----- Original Message ----- >>>> From: "Christer Holmberg (JO/LMF)" >>>> To: "Jeroen van Bemmel" ; "Hadriel Kaplan" >>>> ; >>>> Sent: Monday, April 03, 2006 9:21 AM >>>> Subject: RE: [Sip] How to indicate during proxy >>>> discoverythataproxysupports"outbound" >>>> >>>> >>>> >>>> Hi, >>>> >>>> In case the outbound proxy and the registrar are NOT the same, I assume >>>> that the outbound proxy would not only remove the option tag from the >>>> Proxy-Require header, but also from the Require header? Because, as far >>>> as I can see there is no reason to require the registrar to also >>>> support >>>> outbound. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> -----Original Message----- >>>> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >>>> Sent: 3. huhtikuuta 2006 9:29 >>>> To: Christer Holmberg (JO/LMF); Hadriel Kaplan; sip@ietf.org >>>> Subject: Re: [Sip] How to indicate during proxy >>>> discoverythataproxysupports"outbound" >>>> >>>> Christer, >>>> >>>> Besides detection for support, Proxy-Require is also useful for >>>> backwards compatibility >>>> >>>> Consider how the edge proxy decides whether or not it needs to perform >>>> outbound processing. Without Proxy-Require, it would have to either >>>> look >>>> for >>>> 'Require: outbound' or inspect the Contact headers, look for 'reg-id' >>>> and assume that means the UAC supports / wants to use outbound. From a >>>> protocol purist perspective, both of these alternatives are less >>>> preferred than Proxy-Require >>>> >>>> BTW, section 3.4 should have some text discussing this. It currently >>>> says "edge proxy should use Path" but the processing seems to depend on >>>> the fact that there is a 'reg-id'. What if there is none? >>>> >>>> Regards, >>>> >>>> Jeroen >>>> >>>> ----- Original Message ----- >>>> From: "Christer Holmberg" >>>> To: "Hadriel Kaplan" ; >>>> Sent: Monday, April 03, 2006 7:33 AM >>>> Subject: RE: [Sip] How to indicate during proxy >>>> discoverythataproxysupports"outbound" >>>> >>>> >>>> Hi Hadriel, >>>> >>>> My mail was rabout the OPTIONS alternative. And, you wouldn't even need >>>> Require there, because the outbound proxy would simply reply what it >>>> supports. In fact, no standardization is required for that, so should >>>> we >>>> mention it as an option? >>>> >>>> And, if there are no issues (removal of options tags from the >>>> P-R/Require header by proxy) with the REGISTER alternative I don't have >>>> any issues with that solution - as long as we document the assumptions >>>> and restriction. >>>> >>>> Regards, >>>> >>>> Christer >>>> Regards, >>>> >>>> Christr >>>> >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol Use >>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>> sipping@ietf.org for new developments on the application of sip >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the application of sip >>>> >>> >> >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 03 16:56:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQW4O-0001gZ-9v; Mon, 03 Apr 2006 16:54:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQW4N-0001fz-J5 for sip@ietf.org; Mon, 03 Apr 2006 16:54:39 -0400 Received: from smtp1.versatel.nl ([62.58.50.88] helo=smtp3.versatel.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQW4M-0005AQ-VI for sip@ietf.org; Mon, 03 Apr 2006 16:54:39 -0400 Received: (qmail 11926 invoked by uid 0); 3 Apr 2006 20:54:37 -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 < >; 3 Apr 2006 20:54:37 -0000 Message-ID: <002001c65760$cd2c3060$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Christer Holmberg \(JO/LMF\)" , "Bob Penfield" , "Hadriel Kaplan" , References: <5EB80D22825EEE42872083AD5BFFB5945D1C74@esealmw113.eemea.ericsson.se> Subject: Re: [Sip] How to indicate duringproxydiscoverythataproxysupports"outbound" Date: Mon, 3 Apr 2006 22:54:29 +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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba 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 Christer, In other words, you're saying you want to be able to build a registrar that supports outbound-reg but not outbound-stun (to be used only in combination with edge proxies)? Regards, Jeroen ----- Original Message ----- From: "Christer Holmberg (JO/LMF)" To: "Bob Penfield" ; "Jeroen van Bemmel" ; "Hadriel Kaplan" ; Sent: Monday, April 03, 2006 10:43 PM Subject: RE: [Sip] How to indicate duringproxydiscoverythataproxysupports"outbound" Hi, I agree with Bob. I don't think the registrar should be required to support something it absolutely doesn't have to care about... I would just cause unecessary roundtrips. Regards, Christer -----Original Message----- From: Bob Penfield [mailto:BPenfield@acmepacket.com] Sent: 3. huhtikuuta 2006 21:05 To: Jeroen van Bemmel; Christer Holmberg (JO/LMF); Hadriel Kaplan; sip@ietf.org Subject: Re: [Sip] How to indicate duringproxydiscoverythataproxysupports"outbound" inline. ----- Original Message ----- From: "Jeroen van Bemmel" > Christer, > > No, I think the outbound proxy shouldn't be touching any Require > headers, whether present or not > > It is up to the UAC to decide whether the request needs a Require > header or not. If people have strong feelings against sending a > REGISTER request with reg-id parameters etc, then perhaps the draft > could say "UAC SHOULD add > Require: outbound to the REGISTER request" > > Though in RFC3329 the proxy does remove the Require header, it seems > that outbound is different from sec-agree in this case. > I'm afraid I disagree. I think that 'outbound' is the same as sec-agree in this case. For outbound we need two option tags to make things unambiguous: One for the reusable connection with keepalive behavior that the first hop must do (e.g 'outbound-stun'), and one for the registrar behavior of recognizing reg-id and sip-instance in the Contact (e.g. 'outbound-reg'). Unless the UA knows that the outbound proxy is not the registrar, its first REGISTER will have: Require: outbound-stun, outbound-reg Proxy-Require: outbound-stun outbound-reg is intended for the registrar, and outbound-stun is intended for the first hop. Remember, for REGISTER, the registrar is the UAS, not a proxy. If the first hop is the registrar, the Require header applies, and 'outbound-stun' needs to be there so the registrar does the reusable connection with keepalive. If the first hop is not the registrar, it must remove the 'outbound-stun' tag from both the Require and the Proxy-Require. This is because the 'outbound-stun' feature is applied completely by the first hop proxy. The registrar does not need to do any 'outbound-stun' behavior. It only needs to do 'outbound-reg' behavior. If the tag was left in the Require header, it would a) reject it if it does not support 'outbound-stun'; or b) do the wrong thing by applying 'outbound-stun' behavior. cheers, (-:bob > Regards, > > Jeroen > > ----- Original Message ----- > From: "Christer Holmberg (JO/LMF)" > To: "Jeroen van Bemmel" ; "Hadriel Kaplan" > ; > Sent: Monday, April 03, 2006 9:21 AM > Subject: RE: [Sip] How to indicate during proxy > discoverythataproxysupports"outbound" > > > > Hi, > > In case the outbound proxy and the registrar are NOT the same, I assume > that the outbound proxy would not only remove the option tag from the > Proxy-Require header, but also from the Require header? Because, as far > as I can see there is no reason to require the registrar to also support > outbound. > > Regards, > > Christer > > > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: 3. huhtikuuta 2006 9:29 > To: Christer Holmberg (JO/LMF); Hadriel Kaplan; sip@ietf.org > Subject: Re: [Sip] How to indicate during proxy > discoverythataproxysupports"outbound" > > Christer, > > Besides detection for support, Proxy-Require is also useful for > backwards compatibility > > Consider how the edge proxy decides whether or not it needs to perform > outbound processing. Without Proxy-Require, it would have to either look > for > 'Require: outbound' or inspect the Contact headers, look for 'reg-id' > and assume that means the UAC supports / wants to use outbound. From a > protocol purist perspective, both of these alternatives are less > preferred than Proxy-Require > > BTW, section 3.4 should have some text discussing this. It currently > says "edge proxy should use Path" but the processing seems to depend on > the fact that there is a 'reg-id'. What if there is none? > > Regards, > > Jeroen > > ----- Original Message ----- > From: "Christer Holmberg" > To: "Hadriel Kaplan" ; > Sent: Monday, April 03, 2006 7:33 AM > Subject: RE: [Sip] How to indicate during proxy > discoverythataproxysupports"outbound" > > > Hi Hadriel, > > My mail was rabout the OPTIONS alternative. And, you wouldn't even need > Require there, because the outbound proxy would simply reply what it > supports. In fact, no standardization is required for that, so should we > mention it as an option? > > And, if there are no issues (removal of options tags from the > P-R/Require header by proxy) with the REGISTER alternative I don't have > any issues with that solution - as long as we document the assumptions > and restriction. > > Regards, > > Christer > Regards, > > Christr > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 03 17:11:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQWIm-0001SU-Ma; Mon, 03 Apr 2006 17:09:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQWIk-00018V-J6 for sip@ietf.org; Mon, 03 Apr 2006 17:09:30 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55] helo=zrtps0kn.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQWIk-0005mC-60 for sip@ietf.org; Mon, 03 Apr 2006 17:09:30 -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 k33L9JD21344; Mon, 3 Apr 2006 17:09:19 -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: verifying registration bindings (was [Sip]draft-ietf-sip-fork-loop-fix) Date: Mon, 3 Apr 2006 16:09:16 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60B46D86B@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: verifying registration bindings (was [Sip]draft-ietf-sip-fork-loop-fix) Thread-Index: AcZXWa/dDMgE3ljfRsah1fS5b30pSgAB8PRg From: "Samir Srivastava" To: "Jeroen van Bemmel" , "Robert Sparks" X-Spam-Score: 0.1 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 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 Hi Robert, Thx for clarifying on either / or approach for the fix which I was thinking of. I was suggesting for REGISTER is similar to REFER UA Registrar Registrar/Proxy for Contact in REG | | | |---REG ------------>| | | | |=20 |<-- 202 Accepted----| | | |<----- Audit on Reg Contact --->| | | | |<-- NOTIFY (REG EV)-| | | | | |-- 200 OK (NOT)---->| | At the time Registrar/Proxy sends NOTIFY it has confirmed knowledge of goodness of contact at that point of time. Is this bad ? REFER works this way. Thx Samir -----Original Message----- From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 Sent: Monday, April 03, 2006 1:03 PM To: Robert Sparks; Srivastava, Samir [SC100:8826:EXCH] Cc: Sip Subject: Re: verifying registration bindings (was [Sip]draft-ietf-sip-fork-loop-fix) Robert, Also for the connection reuse draft it seems we will need a kind of "reverse challenge" mechanism to verify that a client requesting an alias actually owns / listens on the port that it is trying to shortcut (Via port instead of Contact, but similar). When you say "in the path of a non-INVITE transaction", you mean the following would be bad? UAC UAS | nit | |----------->| | 100 | // or some other 1xx meaning "challenging..." |<-----------| | challenge | |<-----------| | answer | |----------->| | | | ok nit | |<-----------| Regards, Jeroen ----- Original Message ----- From: "Robert Sparks" To: "Samir Srivastava" Cc: "Sip" Sent: Monday, April 03, 2006 9:49 PM Subject: verifying registration bindings (was [Sip]draft-ietf-sip-fork-loop-fix) > Samir - > > We've talked about approaches similar to this in the past and there =20 > is interest in the concept of asking a registrant "Prove to me that I=20 > can reach this contact" before accepting a binding. There's been=20 > discussion (and even some draft work) around using the consent=20 > framework to do something similar (but with greater scope). > > What we have right now is an agreement to talk about the possible=20 > mechanisms, and general recognition that we need something more than=20 > what we have right now. > > We do not have any consensus (IMHO) around a particular mechanism =20 > yet. So the plan is to progress the fork-loop-fix draft as is and=20 > decouple work on these other potential mechanisms. > > One comment on the questions you've posted so far: It's unlikely we =20 > will be able to create a mechanism that allows us to reject the actual > REGISTER request. That puts another operation in the path of a=20 > non-INVITE transaction, and we've learned that's a dangerous thing. I > suspect we'll end up with a mechanism that puts bindings into an=20 > "unconfirmed" state. The registrar will then send something towards=20 > the contact asking for proof that it knows about the binding request.=20 > Once that proof is obtained, the contact would become confirmed and=20 > used by a location server. > > RjS > > On Apr 3, 2006, at 1:59 PM, Samir Srivastava wrote: > >> Hi Dale, >> >> Thx for response. See in line. >> >> Thx >> Samir >> >> -----Original Message----- >> From: Dale R. Worley [mailto:dworley@pingtel.com] >> Sent: Monday, April 03, 2006 10:21 AM >> To: Sip >> Subject: RE: [Sip] draft-ietf-sip-fork-loop-fix >> >> On Sat, 2006-04-01 at 16:47 -0600, Samir Srivastava wrote: >>> It might be better to not reject the REGISTER, since later actions >>> might cure the loop without altering *this* registration. (Also, >>> since a rejected registration is not in the database, the next >>> re-registration attempt also appears to be new, and triggers the loop >>> test again.) >>> >>> SS>> Only later *UnRegistration or expired contact* can break the >> loop. >>> Proxy P1 is still going to forward Proxy P2, where looped contact is >>> gone for now, and request is not going to fullfilled with proxy P1 >>> contact. So it good to reject this registration. And let the >>> Registering end point figure out where is the loop. If an endpoint >>> keeps registering again and again with looped causing contacts, >>> trigger this to IPS/IDS and take out the endpoint. This is very >>> similar to how repeated 401/407 are handled. >> >> If a registration at P1 shows up a loop, the registration for P1 may >> well be correct, and the error being some configuration problem at P2. >> So it is helpful to *report* the problem, but I think it is excessive to >> reject the registration. >> >> SS>> This is dependent on the order of registration. If P1 got the >> registration first, then keeping >> P2 registration is of no value. Since it is looped contact, how one can >> decide which one to keep. >> Keeping looped registration alive in the hope of someone will correct >> them doesn't serve much purpose, if the guy is bad and he doesn't remove >> it. Time window with looped contacts is open for attackers. Here one can >> say, if looped contacts are detected, then further requests will not be >> catered, unless they are corrected i.e. Reject the further request with >> error code " Looped Contact correction in progress". My position is "Do >> not let the faults percolate, correct them at the root itself as soon as >> possible". >> >> I am okay to finalize these minor details later, *if there is group >> consensus that we should take this path*. Group ?? >> >> >> >> 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 > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Apr 03 17:21:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQWSr-0000hj-Sq; Mon, 03 Apr 2006 17:19:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQWSq-0000h3-SZ for sip@ietf.org; Mon, 03 Apr 2006 17:19:56 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQWSq-00064o-8f for sip@ietf.org; Mon, 03 Apr 2006 17:19:56 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IX600J010M3Y9@siemenscomms.co.uk> for sip@ietf.org; Mon, 03 Apr 2006 22:20: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 <0IX600H3I0M3FG@siemenscomms.co.uk>; Mon, 03 Apr 2006 22:20:27 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 03 Apr 2006 22:19:55 +0100 Content-return: allowed Date: Mon, 03 Apr 2006 22:19:49 +0100 From: "Elwell, John" Subject: RE: [Sip] draft-elwell-sip-connected-identity-01.txt To: "Christer Holmberg (JO/LMF)" , "Drage, Keith (Keith)" , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670892FE01@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: 325b777e1a3a618c889460b612a65510 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 Christer, See below. John > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:christer.holmberg@ericsson.com] > Sent: 03 April 2006 21:42 > To: Elwell, John; Drage, Keith (Keith); sip@ietf.org > Subject: RE: [Sip] draft-elwell-sip-connected-identity-01.txt > > > Hi John, > > Inline. > > >1. Proxy impacts: There are no words on how the chaning of the URI > >will impact intermediate proxies (see separate thread). Normally our > >documents contains a "proxy impacts", but not in this. And, there is > >no agreed solution, so I consider that issue both MISSING TEXT and > >TECHNICAL. > [JRE] Missing text can and will be added - I am already > drafting it. The > main technical issue (i.e., needing to accommodate change of URI > mid-dialog, as anticipated in RFC3261) has been agreed since the > face-to-face in Vancouver. I don't see any other technical issue for > proxies (other than the impact on an authentication service, which is > minor in that it just means the Authentication Service can operate in > circumstances where previously it was unable to operate). > > [CHH] The impact is that a RFC2543 uses, as far as I know, > the whole To > header (not only the tag) to identify a dialog. So, if you send an > UPDATE with a new To header URI, such proxy will not recognize the > dialog. > > Now, if you are saying that we don't need to take backward compability > into consideration [JRE] Yes, that was the decision in Vancouver. > I don't agree with the statement that > chaning the To > header URI in a response would break any transaction rules. > Because, as > I said earlier, the To header URI is not used for transaction > identification in RFC3261. [/CHH] [JRE] Yes, I stand corrected on that. I am willing to reconsider changes to the To header field URI in a response, but somebody indicated during the session in Dallas that there were dangers associated with that. I need to try to tease out the reasons for this on the mailing list. > > > >2. Interworking (e.g. with PSTN): As was mentioned by Roland, this > >causes problems with interworking, ie it is not "backward compatible" > >with the RFCs we have on interworking. Since we normally, when we > >define extension, try to consider existing extensions and > drafts/RFCs > >I think we shall do it also in this case - even if some individuals > >(those thinking PSTN will be replaced by IP overnight) > probably don't > >care. So, I also consider that part both MISSING TEXT and TECHNICAL. > [JRE] I consider specifying interworking with PSTN to be outside the > scope of this draft (an indeed outside the scope of all work > items other > than those specifically aimed at PSTN interworking). > > [CHH] I am not asking you to document PSTN interworking in > the draft. I > am saying that draft won't work with our current PSTN interworking > specifications. Has there been a decission that we don't need to care > about that? [/CHH] [JRE] No, there has not been such a decision. > > >Introducing the ability to convey connected identity IMPROVES > interworking with PSTN compared with the situation at > >present, because firstly connected identity can be conveyed on > establishment of a call to PSTN, and secondly a change of > >connected identity can be conveyed mid-call. > > [CHH] Ok, so if you think it improves interworking, how are > you going to > signal the mid-call change in PSTN, after you've sent CON/ANM > (which the > 200 OK triggers)? [/CHH] [JRE] You would send whatever you would send in PSTN to indicate a call transfer. > > >I admit that conveying connected identity during call establishment > from PSTN to SIP is more difficult than in the > >opposite direction, but that does not make it worse than the present > situation. I see no reason to block something that > >is useful just because it does not handle every situation > when there is > no proposed solution that is acceptable and > >solves all situations. > > [CHH] Personally I think that a solution that does not handle the > interworking situation makes the solution pretty much unusable - > especially in networks where interworking occurs. Someone may say the > number of those networks is so small that we don't have to take that > use-case into consideration, but personally I disagree. [/CHH] > > >Response identity, apart from not having a solution that finds favour > with the broader community, is unsuitable for mid- > >dialog changes of identity. > > [CHH] I am not saying that we shall disallow using UPDATE to > change the > identity mid-call, as currently defined (you wouldn't need to > interwork > that into PSTN, I believe). I am asking for the possibility to also > change it in responses, in order to make it useful also with PSTN > interworking. [/CHH] [JRE] I understand your requirement, but there are also requirements to change identity mid-call and we have a solution for that, so let's push ahead with it. The response identity problem is harder (some people think impossible?) to solve, so why delay solving the problems we can solve right now? > > > >I also disagree on the face-to-face decission that race condition is > >not an issue. However, I realize that is maybe more an > >deployment/use-case issue whether you can expect the UAC to send an > >UPDATE/re-INVITE soon after it has received 200 OK for the initial > >INVITE. > [JRE] I am sure we can work out the details of this as the work item > progresses. I don't see this as a blocking point. > > [CHH] My intention is not to block. I was asked about what my issues > are, and I listed them :) > > Regards, > > Christer > > > > > > > > > > > Regards, > > > > Christer > > > > > > > > > > > > > > > -----Original Message----- > > > From: Christer Holmberg (JO/LMF) > > > [mailto:christer.holmberg@ericsson.com] > > > Sent: 31 March 2006 13:08 > > > To: Drage, Keith (Keith); sip@ietf.org > > > Subject: RE: [Sip] draft-elwell-sip-connected-identity-01.txt > > > > > > > > > > > > Hi Keith, > > > > > > I sent a mail within the "comments on sip-connected-identity" > > > thread. I > > > presented some issues with the current solution, but also > > pointed out > > > that the draft currently does not talk about proxy impacts. > > > > > > Regards, > > > > > > Christer > > > > > > > > > > > > -----Original Message----- > > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > > Sent: 26. maaliskuuta 2006 19:25 > > > To: sip@ietf.org > > > Subject: [Sip] draft-elwell-sip-connected-identity-01.txt > > > > > > (As chair) > > > > > > At the face-to-face meeting at IETF 65 we agreed that > > > http://www.ietf.org/internet-drafts/draft-elwell-sip-connected > > -identity- > > 01.txt formed the basis of part of our charter milestone to provide > > "Mechanism for Response Identity to IESG (PS). > > > > This mail is to confirm that decision using the list. If you have > > issues with this decision, please respond to this mail. > > > > Note: Please keep responses to this thread entirely separate to the > > thread on draft-cao-sip-response-identity > > > > regards > > > > Keith > > > > Keith Drage > > drage@lucent.com > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Apr 03 17:26:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQWXU-0002t9-O0; Mon, 03 Apr 2006 17:24:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQWXS-0002t3-I1 for sip@ietf.org; Mon, 03 Apr 2006 17:24:42 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQWXR-0006Gs-7h for sip@ietf.org; Mon, 03 Apr 2006 17:24:42 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IX600K010U0X0@siemenscomms.co.uk> for sip@ietf.org; Mon, 03 Apr 2006 22:25: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 <0IX600H690U0FG@siemenscomms.co.uk>; Mon, 03 Apr 2006 22:25:12 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 03 Apr 2006 22:24:40 +0100 Content-return: allowed Date: Mon, 03 Apr 2006 22:23:18 +0100 From: "Elwell, John" Subject: RE: [Sip] draft-elwell-sip-connected-identity-01.txt To: Roland Jesske , christer.holmberg@ericsson.com, sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670892FE02@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: 538aad3a3c4f01d8b6a6477ca4248793 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 Roland, See below. John > -----Original Message----- > From: Roland Jesske [mailto:roland.jesske@web.de] > Sent: 03 April 2006 09:38 > To: christer.holmberg@ericsson.com; sip@ietf.org > Subject: [Sip] draft-elwell-sip-connected-identity-01.txt > > >Chriser wrote: > > >2. Interworking (e.g. with PSTN): As was mentioned by Roland, this > >causes problems with interworking, ie it is not "backward compatible" > >with the RFCs we have on interworking. Since we normally, > when we define > >extension, try to consider existing extensions and > drafts/RFCs I think > >we shall do it also in this case - even if some individuals (those > >thinking PSTN will be replaced by IP overnight) probably > don't care. So, > >I also consider that part both MISSING TEXT and TECHNICAL. > > Yes and we have already implemented such interworkings so we > have to change the complet interworking model to wait for a > second Request - Response cycle. > > And there will the problem how the Interworking unit knows > that a UPDATE will arrive after the final response for the > INVITE was recived. [JRE] In the next version I am preparing right now I mandate sending an UPDATE request in the opposite direction to the initial INVITE if the calling side has indicated support for this. So there can be a reasonable expectation that the UPDATE request will arrive. > > Best Regards > > Roland > > _______________________________________________________________ > SMS schreiben mit WEB.DE FreeMail - einfach, schnell und > kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 03 17:50:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQWuv-0001pA-Mx; Mon, 03 Apr 2006 17:48:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQWuu-0001ne-Ug for sip@ietf.org; Mon, 03 Apr 2006 17:48:56 -0400 Received: from smtp1.versatel.nl ([62.58.50.88] helo=smtp3.versatel.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQWuu-00071x-Gc for sip@ietf.org; Mon, 03 Apr 2006 17:48:56 -0400 Received: (qmail 1830 invoked by uid 0); 3 Apr 2006 21:48:55 -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 < >; 3 Apr 2006 21:48:55 -0000 Message-ID: <001001c65768$62fad9a0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Drage, Keith \(Keith\)" , References: <475FF955A05DD411980D00508B6D5FB012749189@en0033exch001u.uk.lucent.com> Date: Mon, 3 Apr 2006 23:48:47 +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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Subject: [Sip] draft-ietf-sip-outbound - transport issue X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Keith, There is another issue related to transports that IMO the outbound draft should have normative text for: UDP versus TCP flows RFC3261 section 18.2.1 requires that the UA (as a server) be reachable over TCP on the same port and interface as UDP. Wouldn't this imply that when the UA sets up a UDP flow using outbound, it MUST also setup a TCP flow (even though it would have to use a different, ephemereal port for that)? For proper SIP protocol operation, an incoming message must be received over TCP if it becomes too large. The UAC SHOULD probably use a single REGISTER with 2 Contacts for this purpose, 1 using UDP and 1 transport=tcp (with different reg-ids). The draft should also contain text on how "last contact registered" is to be interpreted when multiple contacts are received within 1 REGISTER (e.g. last one in message order?) Regards, jeroen ----- Original Message ----- From: "Drage, Keith (Keith)" To: Sent: Saturday, March 25, 2006 2:51 AM Subject: [Sip] draft-ietf-sip-outbound > (as chair) > > As a result of the face-to-face meeting held at IETF #65, we agreed in the > room on the keepalive mechanism: > > - 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. > > With these agreements the meeting also agreed that the document was ready > for WGLC. > > As a result of this Rohan has produced: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-03.txt > > Unfortunately one of the agreements was left out of this update, and a > number of NITS have also been identified. > > Required Actions: > > 1) Authors: Produce -04 version to take account of remaining issues where > consensus exists and any NITS. > > 2) Working group: Any dissent to the agreements listed above or do we have > rough consensus to proceed according to the agreements made in the meeting > > 3) Working group: Are we ready to move to WGLC. Please indicate if you > consider this document needs more work preceding WGLC. > > Pleaswe complete all these actions by 31st March 2006. > > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 03 18:12:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQXFm-00079U-Vn; Mon, 03 Apr 2006 18:10:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQXFl-00079P-6O for sip@ietf.org; Mon, 03 Apr 2006 18:10:29 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQXFk-00087e-69 for sip@ietf.org; Mon, 03 Apr 2006 18:10:29 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5416DFC6; Tue, 4 Apr 2006 00:10:27 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 00:10:26 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 00:10:26 +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] draft-elwell-sip-connected-identity-01.txt Date: Tue, 4 Apr 2006 00:10:25 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1C77@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-elwell-sip-connected-identity-01.txt Thread-Index: AcZXZF6hqtmLWRJNSgy8QzjXmCaoVQABZQbg From: "Christer Holmberg \(JO/LMF\)" To: "Elwell, John" , "Drage, Keith \(Keith\)" , X-OriginalArrivalTime: 03 Apr 2006 22:10:26.0556 (UTC) FILETIME=[69400BC0:01C6576B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e 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 John,=20 >>1. Proxy impacts: There are no words on how the chaning of the URI=20 >>will impact intermediate proxies (see separate thread). Normally our=20 >>documents contains a "proxy impacts", but not in this. And, there is=20 >>no agreed solution, so I consider that issue both MISSING TEXT and=20 >>TECHNICAL. >[JRE] Missing text can and will be added - I am already drafting it.=20 >The main technical issue (i.e., needing to accommodate change of URI=20 >mid-dialog, as anticipated in RFC3261) has been agreed since the=20 >face-to-face in Vancouver. I don't see any other technical issue for=20 >proxies (other than the impact on an authentication service, which is=20 >minor in that it just means the Authentication Service can operate in=20 >circumstances where previously it was unable to operate). >=20 >[CHH] The impact is that a RFC2543 uses, as far as I know, the whole=20 >To header (not only the tag) to identify a dialog. So, if you send an=20 >UPDATE with a new To header URI, such proxy will not recognize the=20 >dialog. >=20 >Now, if you are saying that we don't need to take backward compability=20 >into consideration [JRE] Yes, that was the decision in Vancouver. [CHH] Ok. Keith, just to clarify, is that now true for whatever extensions we are going to work with in future? >I don't agree with the statement that chaning the To header URI in a=20 >response would break any transaction rules. >Because, as I said earlier, the To header URI is not used for transaction=20 >identification in RFC3261. [/CHH] [JRE] Yes, I stand corrected on that. I am willing to reconsider changes to the To header field URI in a response, but somebody indicated during the session in Dallas that there were dangers associated with that. I need to try to tease out the reasons for this on the mailing list. [CHH] If there are dangers associated with the solution we should document them. >>2. Interworking (e.g. with PSTN): As was mentioned by Roland, this=20 >>causes problems with interworking, ie it is not "backward compatible" >>with the RFCs we have on interworking. Since we normally, when we=20 >>define extension, try to consider existing extensions and >>drafts/RFCs I think we shall do it also in this case - even if some individuals=20 >>(those thinking PSTN will be replaced by IP overnight) probably don't >>care. So, I also consider that part both MISSING TEXT and TECHNICAL. >[JRE] I consider specifying interworking with PSTN to be outside the=20 >scope of this draft (an indeed outside the scope of all work items=20 >other than those specifically aimed at PSTN interworking). >=20 >[CHH] I am not asking you to document PSTN interworking in the draft.=20 >I am saying that draft won't work with our current PSTN interworking=20 >specifications. Has there been a decission that we don't need to care=20 >about that? [/CHH] [JRE] No, there has not been such a decision.=20 >>Introducing the ability to convey connected identity IMPROVES interworking with PSTN compared with the situation at >>present, because firstly connected identity can be conveyed on establishment of a call to PSTN, and secondly a change of >>connected identity can be conveyed mid-call. >=20 >[CHH] Ok, so if you think it improves interworking, how are you going to signal the mid-call change in PSTN, after=20 >you've sent CON/ANM (which the 200 OK triggers)? [/CHH] [JRE] You would send whatever you would send in PSTN to indicate a call transfer. >>I admit that conveying connected identity during call establishment from PSTN to SIP is more difficult than in the >>opposite direction, but that does not make it worse than the present situation. I see no reason to block something that >>is useful just because it does not handle every situation when there is >>no proposed solution that is acceptable and solves all situations. >=20 >[CHH] Personally I think that a solution that does not handle the=20 >interworking situation makes the solution pretty much unusable -=20 >especially in networks where interworking occurs. Someone may say the=20 >number of those networks is so small that we don't have to take that=20 >use-case into consideration, but personally I disagree. [/CHH] >=20 >>Response identity, apart from not having a solution that finds favour with the broader community, is unsuitable for mid- >>dialog changes of identity. >=20 >[CHH] I am not saying that we shall disallow using UPDATE to change the identity mid-call, as currently defined (you=20 >wouldn't need to interwork that into PSTN, I believe). I am asking for the possibility to also change it in responses, in=20 >order to make it useful also with PSTN interworking. [/CHH] [JRE] I understand your requirement, but there are also requirements to change identity mid-call and we have a solution for that, so let's push ahead with it. The response identity problem is harder (some people think impossible?) to solve, so why delay solving the problems we can solve right now? [CHH] I haven't heard of any technical problems. As far as I understand, people have expressed some security concerns. Can't we just document those and move on? I really think the best way is to have a single document for this. Regards, Christer > >=20 > > > -----Original Message----- > > > From: Christer Holmberg (JO/LMF) > > > [mailto:christer.holmberg@ericsson.com] > > > Sent: 31 March 2006 13:08 > > > To: Drage, Keith (Keith); sip@ietf.org > > > Subject: RE: [Sip] draft-elwell-sip-connected-identity-01.txt > > >=20 > > >=20 > > >=20 > > > Hi Keith, > > >=20 > > > I sent a mail within the "comments on sip-connected-identity"=20 > > > thread. I > > > presented some issues with the current solution, but also > > pointed out > > > that the draft currently does not talk about proxy impacts. > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > > =20 > > >=20 > > > -----Original Message----- > > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > > Sent: 26. maaliskuuta 2006 19:25 > > > To: sip@ietf.org > > > Subject: [Sip] draft-elwell-sip-connected-identity-01.txt > > >=20 > > > (As chair) > > >=20 > > > At the face-to-face meeting at IETF 65 we agreed that=20 > > > http://www.ietf.org/internet-drafts/draft-elwell-sip-connected > > -identity- > > 01.txt formed the basis of part of our charter milestone to provide=20 > > "Mechanism for Response Identity to IESG (PS). > >=20 > > This mail is to confirm that decision using the list. If you have=20 > > issues with this decision, please respond to this mail. > >=20 > > Note: Please keep responses to this thread entirely separate to the=20 > > thread on draft-cao-sip-response-identity > >=20 > > regards > >=20 > > Keith > >=20 > > Keith Drage > > drage@lucent.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=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 >=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 Mon Apr 03 18:26:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQXSz-00043z-DG; Mon, 03 Apr 2006 18:24:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQXSy-00041U-91 for sip@ietf.org; Mon, 03 Apr 2006 18:24:08 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQXSx-0000lY-I1 for sip@ietf.org; Mon, 03 Apr 2006 18:24:08 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AACF7E60; Tue, 4 Apr 2006 00:24:06 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 00:24:05 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 00:24: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="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] How to indicate duringproxydiscoverythataproxysupports"outbound" Date: Tue, 4 Apr 2006 00:24:04 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1C78@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] How to indicate duringproxydiscoverythataproxysupports"outbound" Thread-Index: AcZXYNauxTw4QJdpQAyGIcKQsf+gIwAC6UIw From: "Christer Holmberg \(JO/LMF\)" To: "Jeroen van Bemmel" , "Bob Penfield" , "Hadriel Kaplan" , X-OriginalArrivalTime: 03 Apr 2006 22:24:05.0830 (UTC) FILETIME=[51935660:01C6576D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 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, >In other words, you're saying you want to be able to build a registrar that supports outbound-reg but not outbound-stun=20 >(to be used only in combination with edge proxies)? In implementation terms I could say that, yes :) I see no reason why the registrar, if a separate node than the edge-proxy, should need to support the keep-alive. Because, aren't outbound-reg and outbound-stun two separate things (eventhough we document both under the outbound "umbrella")? Regards, Christer ----- Original Message ----- From: "Christer Holmberg (JO/LMF)" To: "Bob Penfield" ; "Jeroen van Bemmel"=20 ; "Hadriel Kaplan" ; Sent: Monday, April 03, 2006 10:43 PM Subject: RE: [Sip] How to indicate duringproxydiscoverythataproxysupports"outbound" Hi, I agree with Bob. I don't think the registrar should be required to support something it absolutely doesn't have to care about... I would just cause unecessary roundtrips. Regards, Christer -----Original Message----- From: Bob Penfield [mailto:BPenfield@acmepacket.com] Sent: 3. huhtikuuta 2006 21:05 To: Jeroen van Bemmel; Christer Holmberg (JO/LMF); Hadriel Kaplan; sip@ietf.org Subject: Re: [Sip] How to indicate duringproxydiscoverythataproxysupports"outbound" inline. ----- Original Message ----- From: "Jeroen van Bemmel" > Christer, > > No, I think the outbound proxy shouldn't be touching any Require=20 > headers, whether present or not > > It is up to the UAC to decide whether the request needs a Require=20 > header or not. If people have strong feelings against sending a=20 > REGISTER request with reg-id parameters etc, then perhaps the draft=20 > could say "UAC SHOULD add > Require: outbound to the REGISTER request" > > Though in RFC3329 the proxy does remove the Require header, it seems=20 > that outbound is different from sec-agree in this case. > I'm afraid I disagree. I think that 'outbound' is the same as sec-agree in this case. For outbound we need two option tags to make things unambiguous: One for the reusable connection with keepalive behavior that the first hop must do (e.g 'outbound-stun'), and one for the registrar behavior of recognizing reg-id and sip-instance in the Contact (e.g. 'outbound-reg'). Unless the UA knows that the outbound proxy is not the registrar, its first REGISTER will have: Require: outbound-stun, outbound-reg Proxy-Require: outbound-stun outbound-reg is intended for the registrar, and outbound-stun is intended for the first hop. Remember, for REGISTER, the registrar is the UAS, not a proxy. If the first hop is the registrar, the Require header applies, and 'outbound-stun' needs to be there so the registrar does the reusable connection with keepalive. If the first hop is not the registrar, it must remove the 'outbound-stun' tag from both the Require and the Proxy-Require. This is because the 'outbound-stun' feature is applied completely by the first hop proxy. The registrar does not need to do any 'outbound-stun' behavior. It only needs to do 'outbound-reg' behavior. If the tag was left in the Require header, it would a) reject it if it does not support 'outbound-stun'; or b) do the wrong thing by applying 'outbound-stun' behavior. cheers, (-:bob > Regards, > > Jeroen > > ----- Original Message ----- > From: "Christer Holmberg (JO/LMF)" > To: "Jeroen van Bemmel" ; "Hadriel Kaplan" > ; > Sent: Monday, April 03, 2006 9:21 AM > Subject: RE: [Sip] How to indicate during proxy=20 > discoverythataproxysupports"outbound" > > > > Hi, > > In case the outbound proxy and the registrar are NOT the same, I assume > that the outbound proxy would not only remove the option tag from the=20 > Proxy-Require header, but also from the Require header? Because, as far > as I can see there is no reason to require the registrar to also support > outbound. > > Regards, > > Christer > > > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: 3. huhtikuuta 2006 9:29 > To: Christer Holmberg (JO/LMF); Hadriel Kaplan; sip@ietf.org > Subject: Re: [Sip] How to indicate during proxy=20 > discoverythataproxysupports"outbound" > > Christer, > > Besides detection for support, Proxy-Require is also useful for=20 > backwards compatibility > > Consider how the edge proxy decides whether or not it needs to perform > outbound processing. Without Proxy-Require, it would have to either look > for > 'Require: outbound' or inspect the Contact headers, look for 'reg-id' > and assume that means the UAC supports / wants to use outbound. From a > protocol purist perspective, both of these alternatives are less=20 > preferred than Proxy-Require > > BTW, section 3.4 should have some text discussing this. It currently=20 > says "edge proxy should use Path" but the processing seems to depend on > the fact that there is a 'reg-id'. What if there is none? > > Regards, > > Jeroen > > ----- Original Message ----- > From: "Christer Holmberg" > To: "Hadriel Kaplan" ; > Sent: Monday, April 03, 2006 7:33 AM > Subject: RE: [Sip] How to indicate during proxy=20 > discoverythataproxysupports"outbound" > > > Hi Hadriel, > > My mail was rabout the OPTIONS alternative. And, you wouldn't even need > Require there, because the outbound proxy would simply reply what it=20 > supports. In fact, no standardization is required for that, so should we > mention it as an option? > > And, if there are no issues (removal of options tags from the=20 > P-R/Require header by proxy) with the REGISTER alternative I don't have > any issues with that solution - as long as we document the assumptions > and restriction. > > Regards, > > Christer > Regards, > > Christr > > > > _______________________________________________ > 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Apr 03 18:27:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQXUg-0006Oi-4r; Mon, 03 Apr 2006 18:25:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQXUe-0006Od-G9 for sip@ietf.org; Mon, 03 Apr 2006 18:25:52 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQXUd-0000qu-TE for sip@ietf.org; Mon, 03 Apr 2006 18:25:52 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 493C04F0001; Tue, 4 Apr 2006 00:25:51 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 00:25:50 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 00:25:50 +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] draft-ietf-sip-outbound - transport issue Date: Tue, 4 Apr 2006 00:25:50 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1C79@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-outbound - transport issue Thread-Index: AcZXaHNTYLMtExqISRigljkdxAFLJAABOqRg From: "Christer Holmberg \(JO/LMF\)" To: "Jeroen van Bemmel" , "Drage, Keith \(Keith\)" , X-OriginalArrivalTime: 03 Apr 2006 22:25:50.0786 (UTC) FILETIME=[90225A20:01C6576D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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, Could you clarify how setting up two flows, with different source ports, is affecting the ability to be able to receive udp and tcp traffic on a single port? Regards, Christer=20 -----Original Message----- From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 Sent: 4. huhtikuuta 2006 0:49 To: Drage, Keith (Keith); sip@ietf.org Subject: [Sip] draft-ietf-sip-outbound - transport issue Keith, There is another issue related to transports that IMO the outbound draft should have normative text for: UDP versus TCP flows RFC3261 section 18.2.1 requires that the UA (as a server) be reachable over TCP on the same port and interface as UDP. Wouldn't this imply that when the UA sets up a UDP flow using outbound, it MUST also setup a TCP flow (even though it would have to use a different, ephemereal port for that)? For proper SIP protocol operation, an incoming message must be received over TCP if it becomes too large. The UAC SHOULD probably use a single REGISTER with 2 Contacts for this purpose, 1 using UDP and 1 transport=3Dtcp (with different reg-ids). The draft should also contain text on how "last contact registered" is to be interpreted when multiple contacts are received within 1 REGISTER (e.g. last one in message order?) Regards, jeroen ----- Original Message ----- From: "Drage, Keith (Keith)" To: Sent: Saturday, March 25, 2006 2:51 AM Subject: [Sip] draft-ietf-sip-outbound > (as chair) > > As a result of the face-to-face meeting held at IETF #65, we agreed in the=20 > room on the keepalive mechanism: > > - OS TCP KeepAlive should be used if the client supports it. > - Need something more because OS TCP KeepAlive is not supported in every=20 > client OS. > - Consensus to use STUN for UDP > - Consensus to use STUN for TCP, with use of OS TCP keep alive above. > > With these agreements the meeting also agreed that the document was ready=20 > for WGLC. > > As a result of this Rohan has produced: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-03.txt > > Unfortunately one of the agreements was left out of this update, and a > number of NITS have also been identified. > > Required Actions: > > 1) Authors: Produce -04 version to take account of remaining issues where=20 > consensus exists and any NITS. > > 2) Working group: Any dissent to the agreements listed above or do we have=20 > rough consensus to proceed according to the agreements made in the meeting > > 3) Working group: Are we ready to move to WGLC. Please indicate if you > consider this document needs more work preceding WGLC. > > Pleaswe complete all these actions by 31st March 2006. > > > 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=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 Tue Apr 04 01:56:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQeTn-0005jW-2H; Tue, 04 Apr 2006 01:53:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQeTg-0005X0-4Y for sip@ietf.org; Tue, 04 Apr 2006 01:53:20 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQeTZ-000325-Bo for sip@ietf.org; Tue, 04 Apr 2006 01:53:16 -0400 Received: (qmail 26179 invoked by uid 0); 4 Apr 2006 05:53:11 -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 < >; 4 Apr 2006 05:53:11 -0000 Message-ID: <001001c657ac$09f9e000$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Christer Holmberg \(JO/LMF\)" , "Drage, Keith \(Keith\)" , References: <5EB80D22825EEE42872083AD5BFFB5945D1C79@esealmw113.eemea.ericsson.se> Subject: Re: [Sip] draft-ietf-sip-outbound - transport issue Date: Tue, 4 Apr 2006 07:53:03 +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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c 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 Christer, The port resolution wouldn't be done until a request reaches the location service (e.g. co-located with the registrar). So as long as both types of transport are registered, I don't see a problem with the fact that they are at different ports Without this, e.g. a NOTIFY coming in over TCP (for example with a large body, quite common) could not be delivered if the UAC only registered a UDP Contact / flow Regards, Jeroen ----- Original Message ----- From: "Christer Holmberg (JO/LMF)" To: "Jeroen van Bemmel" ; "Drage, Keith (Keith)" ; Sent: Tuesday, April 04, 2006 12:25 AM Subject: RE: [Sip] draft-ietf-sip-outbound - transport issue Hi, Could you clarify how setting up two flows, with different source ports, is affecting the ability to be able to receive udp and tcp traffic on a single port? Regards, Christer -----Original Message----- From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] Sent: 4. huhtikuuta 2006 0:49 To: Drage, Keith (Keith); sip@ietf.org Subject: [Sip] draft-ietf-sip-outbound - transport issue Keith, There is another issue related to transports that IMO the outbound draft should have normative text for: UDP versus TCP flows RFC3261 section 18.2.1 requires that the UA (as a server) be reachable over TCP on the same port and interface as UDP. Wouldn't this imply that when the UA sets up a UDP flow using outbound, it MUST also setup a TCP flow (even though it would have to use a different, ephemereal port for that)? For proper SIP protocol operation, an incoming message must be received over TCP if it becomes too large. The UAC SHOULD probably use a single REGISTER with 2 Contacts for this purpose, 1 using UDP and 1 transport=tcp (with different reg-ids). The draft should also contain text on how "last contact registered" is to be interpreted when multiple contacts are received within 1 REGISTER (e.g. last one in message order?) Regards, jeroen ----- Original Message ----- From: "Drage, Keith (Keith)" To: Sent: Saturday, March 25, 2006 2:51 AM Subject: [Sip] draft-ietf-sip-outbound > (as chair) > > As a result of the face-to-face meeting held at IETF #65, we agreed in the > room on the keepalive mechanism: > > - 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. > > With these agreements the meeting also agreed that the document was ready > for WGLC. > > As a result of this Rohan has produced: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-03.txt > > Unfortunately one of the agreements was left out of this update, and a > number of NITS have also been identified. > > Required Actions: > > 1) Authors: Produce -04 version to take account of remaining issues where > consensus exists and any NITS. > > 2) Working group: Any dissent to the agreements listed above or do we have > rough consensus to proceed according to the agreements made in the meeting > > 3) Working group: Are we ready to move to WGLC. Please indicate if you > consider this document needs more work preceding WGLC. > > Pleaswe complete all these actions by 31st March 2006. > > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 04 02:17:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQeoZ-0007rt-46; Tue, 04 Apr 2006 02:14:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQenC-0007IW-Bx for sip@ietf.org; Tue, 04 Apr 2006 02:13:30 -0400 Received: from smtp1.versatel.nl ([62.58.50.88] helo=smtp3.versatel.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQecQ-0003bs-01 for sip@ietf.org; Tue, 04 Apr 2006 02:02:25 -0400 Received: (qmail 21338 invoked by uid 0); 4 Apr 2006 06:02:15 -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 < >; 4 Apr 2006 06:02:15 -0000 Message-ID: <001b01c657ad$4e1f7140$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Rohan Mahy" Date: Tue, 4 Apr 2006 08:02:07 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: sip@ietf.org Subject: [Sip] http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-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: , Content-Type: multipart/mixed; boundary="===============1561989927==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1561989927== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C657BE.118B9180" This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C657BE.118B9180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Rohan, Two things, 1 comment and a nit: 1. clarification on recent flows: There are several references to the = registrar using the most recent flow. There are two potential issues = with this: 1a q-value ordering - if the UAC first registers a flow with q=3D0.8 and = later with q=3D0.1, I think the former should be used (i.e. q-value = taking precedence over flow establishment time). Same goes for = scenario's with two different UACs registering for the same user, one = using outbound and another one not (with higher q-value) 1b multiple flows established with a single REGISTER - what is the most = recent one in this case? 2 - section 11 says "the proxy stores the value of the Path header = field", this should be "the registrar" Regards, Jeroen ------=_NextPart_000_0018_01C657BE.118B9180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Rohan,
 
Two things, 1 comment and a = nit:
 
1. clarification on recent flows: There = are several=20 references to the registrar using the most recent flow. There are two = potential=20 issues with this:
1a q-value ordering - if the UAC first = registers a=20 flow with q=3D0.8 and later with q=3D0.1, I think the former should be = used (i.e.=20 q-value taking precedence over flow establishment time). Same goes for=20 scenario's with two different UACs registering for the same user, one = using=20 outbound and another one not (with higher q-value)
1b multiple flows established with a = single=20 REGISTER - what is the most recent one in this case?
 
2 - section 11 says "the proxy stores = the value of=20 the Path header field", this should be "the registrar"
 
Regards,
 
Jeroen
------=_NextPart_000_0018_01C657BE.118B9180-- --===============1561989927== 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 --===============1561989927==-- From sip-bounces@ietf.org Tue Apr 04 02:52:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQfM6-0003RR-K3; Tue, 04 Apr 2006 02:49:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQfLS-0003HQ-N1 for sip@ietf.org; Tue, 04 Apr 2006 02:48:54 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQfIv-0005pS-0o for sip@ietf.org; Tue, 04 Apr 2006 02:46:18 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IX600H01QU0SO@siemenscomms.co.uk> for sip@ietf.org; Tue, 04 Apr 2006 07:46:48 +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 <0IX600DAAQU0NE@siemenscomms.co.uk> for sip@ietf.org; Tue, 04 Apr 2006 07:46:48 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 04 Apr 2006 07:46:15 +0100 Content-return: allowed Date: Tue, 04 Apr 2006 07:45:33 +0100 From: "Elwell, John" To: sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670892FE30@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.5 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [Sip] Connected-identity and changing the To header field in a 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="===============1431080380==" 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. --===============1431080380== Content-return: allowed Content-type: multipart/alternative; boundary="Boundary_(ID_j8GDlWrPq/hcKDr3wiyrWg)" 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_j8GDlWrPq/hcKDr3wiyrWg) Content-type: text/plain Content-transfer-encoding: 7BIT During discussion of draft-elwell-connected-identity in Dallas, somebody put forward the opinion that it would be dangerous to change the To header field URI in a response (i.e., make it different from the From header field URI in the request). My assumption at the time was that it would undermine the transaction concept in SIP, yet reading what RFC3261 has to say about transactions, the value of the To header field URI in a response does not appear to be involved in coupling a response to a request. Therefore I assume the person who indicated the danger (which was not challenged at the meeting) has other reasons in mind. I would greatly appreciate opinions on the wisdom or otherwise of allowing the To header field URI to change. It seems that from discussion of connected-identity there is a desire from some parts of the community to include an (unauthenticated) identity in a response. John --Boundary_(ID_j8GDlWrPq/hcKDr3wiyrWg) Content-type: text/html Content-transfer-encoding: 7BIT Connected-identity and changing the To header field in a response

During discussion of draft-elwell-connected-identity in Dallas, somebody put forward the opinion that it would be dangerous to change the To header field URI in a response (i.e., make it different from the From header field URI in the request). My assumption at the time was that it would undermine the transaction concept in SIP, yet reading what RFC3261 has to say about transactions, the value of the To header field URI in a response does not appear to be involved in coupling a response to a request. Therefore I assume the person who indicated the danger (which was not challenged at the meeting) has other reasons in mind. I would greatly appreciate opinions on the wisdom or otherwise of allowing the To header field URI to change. It seems that from discussion of connected-identity there is a desire from some parts of the community to include an (unauthenticated) identity in a response.

John

--Boundary_(ID_j8GDlWrPq/hcKDr3wiyrWg)-- --===============1431080380== 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 --===============1431080380==-- From sip-bounces@ietf.org Tue Apr 04 02:53:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQfNr-0003lP-6H; Tue, 04 Apr 2006 02:51:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQfLk-0003HQ-IH for sip@ietf.org; Tue, 04 Apr 2006 02:49:12 -0400 Received: from smtp1.versatel.nl ([62.58.50.88] helo=smtp3.versatel.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQfFN-0005ZV-IO for sip@ietf.org; Tue, 04 Apr 2006 02:42:39 -0400 Received: (qmail 13488 invoked by uid 0); 4 Apr 2006 06:42:25 -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 < >; 4 Apr 2006 06:42:25 -0000 Message-ID: <003801c657b2$ea340230$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Christer Holmberg \(JO/LMF\)" , "Drage, Keith \(Keith\)" , References: <5EB80D22825EEE42872083AD5BFFB5945D1C79@esealmw113.eemea.ericsson.se> <001001c657ac$09f9e000$31713b51@BEMBUSTER> Subject: Re: [Sip] draft-ietf-sip-outbound - transport issue Date: Tue, 4 Apr 2006 08:42:17 +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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.1 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 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: "Jeroen van Bemmel" To: "Christer Holmberg (JO/LMF)" ; "Drage, Keith (Keith)" ; Sent: Tuesday, April 04, 2006 7:53 AM Subject: Re: [Sip] draft-ietf-sip-outbound - transport issue > Christer, > > The port resolution wouldn't be done until a request reaches the location > service (e.g. co-located with the registrar). So as long as both types of > transport are registered, I don't see a problem with the fact that they > are at different ports > > Without this, e.g. a NOTIFY coming in over TCP (for example with a large > body, quite common) could not be delivered if the UAC only registered a > UDP Contact / flow > Note: the draft should also state that for requests sent via the edge proxy, the UAC SHOULD NOT use a Contact with a transport (or port?) that it does not have an active flow for (even though section 5.3 effectively causes the Contact - which appears in the request URI of mid-dialog requests - to be ignored by the edge proxy, this is still relevant because some UACs may refuse requests arriving with a request URI that does not match the transport it is received on). Also, the UAC should accept TCP requests coming in with a request URI containing a different port than on which it is received (it could place the ephemeral port of a registered flow in its Contact headers, but this would not work in case of multiple registered flows) Jeroen > Regards, > > Jeroen > > > ----- Original Message ----- > From: "Christer Holmberg (JO/LMF)" > To: "Jeroen van Bemmel" ; "Drage, Keith (Keith)" > ; > Sent: Tuesday, April 04, 2006 12:25 AM > Subject: RE: [Sip] draft-ietf-sip-outbound - transport issue > > > > Hi, > > Could you clarify how setting up two flows, with different source ports, > is affecting the ability to be able to receive udp and tcp traffic on a > single port? > > Regards, > > Christer > > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: 4. huhtikuuta 2006 0:49 > To: Drage, Keith (Keith); sip@ietf.org > Subject: [Sip] draft-ietf-sip-outbound - transport issue > > Keith, > > There is another issue related to transports that IMO the outbound > draft should have normative text for: UDP versus TCP flows > > RFC3261 section 18.2.1 requires that the UA (as a server) be reachable > over TCP on the same port and interface as UDP. Wouldn't this imply that > when the UA sets up a UDP flow using outbound, it MUST also setup a TCP > flow (even though it would have to use a different, ephemereal port for > that)? > > For proper SIP protocol operation, an incoming message must be received > over TCP if it becomes too large. The UAC SHOULD probably use a single > REGISTER with 2 Contacts for this purpose, 1 using UDP and 1 > transport=tcp (with different reg-ids). > > The draft should also contain text on how "last contact registered" is > to be interpreted when multiple contacts are received within 1 REGISTER > (e.g. last one in message order?) > > Regards, > > jeroen > > ----- Original Message ----- > From: "Drage, Keith (Keith)" > To: > Sent: Saturday, March 25, 2006 2:51 AM > Subject: [Sip] draft-ietf-sip-outbound > > >> (as chair) >> >> As a result of the face-to-face meeting held at IETF #65, we agreed in > the >> room on the keepalive mechanism: >> >> - 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. >> >> With these agreements the meeting also agreed that the document was > ready >> for WGLC. >> >> As a result of this Rohan has produced: >> >> http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-03.txt >> >> Unfortunately one of the agreements was left out of this update, and a > >> number of NITS have also been identified. >> >> Required Actions: >> >> 1) Authors: Produce -04 version to take account of remaining issues > where >> consensus exists and any NITS. >> >> 2) Working group: Any dissent to the agreements listed above or do we > have >> rough consensus to proceed according to the agreements made in the > meeting >> >> 3) Working group: Are we ready to move to WGLC. Please indicate if you > >> consider this document needs more work preceding WGLC. >> >> Pleaswe complete all these actions by 31st March 2006. >> >> >> 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 > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 04 03:47:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQgEf-0000pm-4o; Tue, 04 Apr 2006 03:45:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQgEd-0000pY-3y for sip@ietf.org; Tue, 04 Apr 2006 03:45:55 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQgEb-00009R-9k for sip@ietf.org; Tue, 04 Apr 2006 03:45:55 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 59AEE4F0001; Tue, 4 Apr 2006 09:43:59 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 09:43:58 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 09:43: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="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-ietf-sip-outbound - transport issue Date: Tue, 4 Apr 2006 09:43:57 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1C7D@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-outbound - transport issue Thread-Index: AcZXrBIZeV/5hm9bSoylkUgPTmUwTAAD0yiQ From: "Christer Holmberg \(JO/LMF\)" To: "Jeroen van Bemmel" , "Drage, Keith \(Keith\)" , X-OriginalArrivalTime: 04 Apr 2006 07:43:58.0610 (UTC) FILETIME=[886EC720:01C657BB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 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,=20 >The port resolution wouldn't be done until a request reaches the location service (e.g. co-located with the registrar).=20 >So as long as both types of transport are registered, I don't see a problem with the fact that they are at different=20 >ports No, but I thought you said you want to do something which allow the SAME port to be used for UDP and TCP. Or, did I missunderstand? Regards, Christer Without this, e.g. a NOTIFY coming in over TCP (for example with a large body, quite common) could not be delivered if the UAC only registered a UDP Contact / flow Regards, Jeroen ----- Original Message ----- From: "Christer Holmberg (JO/LMF)" To: "Jeroen van Bemmel" ; "Drage, Keith (Keith)"=20 ; Sent: Tuesday, April 04, 2006 12:25 AM Subject: RE: [Sip] draft-ietf-sip-outbound - transport issue Hi, Could you clarify how setting up two flows, with different source ports, is affecting the ability to be able to receive udp and tcp traffic on a single port? Regards, Christer -----Original Message----- From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] Sent: 4. huhtikuuta 2006 0:49 To: Drage, Keith (Keith); sip@ietf.org Subject: [Sip] draft-ietf-sip-outbound - transport issue Keith, There is another issue related to transports that IMO the outbound draft should have normative text for: UDP versus TCP flows RFC3261 section 18.2.1 requires that the UA (as a server) be reachable over TCP on the same port and interface as UDP. Wouldn't this imply that when the UA sets up a UDP flow using outbound, it MUST also setup a TCP flow (even though it would have to use a different, ephemereal port for that)? For proper SIP protocol operation, an incoming message must be received over TCP if it becomes too large. The UAC SHOULD probably use a single REGISTER with 2 Contacts for this purpose, 1 using UDP and 1 transport=3Dtcp (with different reg-ids). The draft should also contain text on how "last contact registered" is to be interpreted when multiple contacts are received within 1 REGISTER (e.g. last one in message order?) Regards, jeroen ----- Original Message ----- From: "Drage, Keith (Keith)" To: Sent: Saturday, March 25, 2006 2:51 AM Subject: [Sip] draft-ietf-sip-outbound > (as chair) > > As a result of the face-to-face meeting held at IETF #65, we agreed in the > room on the keepalive mechanism: > > - 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. > > With these agreements the meeting also agreed that the document was ready > for WGLC. > > As a result of this Rohan has produced: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-03.txt > > Unfortunately one of the agreements was left out of this update, and a > number of NITS have also been identified. > > Required Actions: > > 1) Authors: Produce -04 version to take account of remaining issues where > consensus exists and any NITS. > > 2) Working group: Any dissent to the agreements listed above or do we have > rough consensus to proceed according to the agreements made in the meeting > > 3) Working group: Are we ready to move to WGLC. Please indicate if you > consider this document needs more work preceding WGLC. > > Pleaswe complete all these actions by 31st March 2006. > > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Apr 04 07:10:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQjOS-0007NJ-In; Tue, 04 Apr 2006 07:08:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQjJW-0006eE-8a for sip@ietf.org; Tue, 04 Apr 2006 07:03:10 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQj4y-0007bL-71 for sip@ietf.org; Tue, 04 Apr 2006 06:48:09 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1538B4F0001 for ; Tue, 4 Apr 2006 12:47:58 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 12:47:57 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 12:47:57 +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 Date: Tue, 4 Apr 2006 12:47:56 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1C89@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Outbound: Questions on reg-id Thread-Index: AcZX1TuTnk5P6pwTTQWSq9kG/bhUBQ== From: "Christer Holmberg \(JO/LMF\)" To: X-OriginalArrivalTime: 04 Apr 2006 10:47:57.0413 (UTC) FILETIME=[3C127150:01C657D5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Sip] Outbound: Questions on reg-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 Hi, A few clarification questions on the reg-id parameter. The outbound draft (chapter 3.1) says that the reg-id can be used by the registrar to determine that a user has rebooted. Q1: In order to achieve that you would have to make sure the value is unique. Because, if you use value "1", then rebood, and then use value "1" again I don't see what it will bring. Q2: Doesn't the Call-ID, as defined by RFC3261 to be used with registrations, provide the same functionaltity? Chapter 10.2.4 of RFC3261 says: "A UA SHOULD use the same Call-ID for all registrations during a single boot cycle. Registration refreshes SHOULD be sent to the same network address as the original registration, unless redirected."=20 Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Apr 04 08:01:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQkAv-0003lm-2t; Tue, 04 Apr 2006 07:58:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQkAt-0003hj-9G for sip@ietf.org; Tue, 04 Apr 2006 07:58:19 -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 1FQkAs-0001hQ-0I for sip@ietf.org; Tue, 04 Apr 2006 07:58:19 -0400 Received: from BPenfield [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id AF580140; Tue, 04 Apr 2006 07:58:16 -0400 Message-ID: <004d01c657df$0f7076b0$800101df@acmepacket.com> From: "Bob Penfield" To: "Elwell, John" , References: <50B1CBA96870A34799A506B2313F26670892FE30@ntht201e.siemenscomms.co.uk> Subject: Re: [Sip] Connected-identity and changing the To header field in aresponse Date: Tue, 4 Apr 2006 07:58:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 The issue with changing the To in a response is backward compatibility with RFC 2543 which does use the To for transaction matching. RFC 2543 section 1.4.3 says: All responses to a request contain the same values in the Call-ID, CSeq, To, and From fields (with the possible addition of a tag in the To field (section 6.37)). This allows responses to be matched with requests. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 bpenfield@acmepacket.com ----- Original Message ----- From: "Elwell, John" To: Sent: Tuesday, April 04, 2006 2:45 AM Subject: [Sip] Connected-identity and changing the To header field in aresponse > During discussion of draft-elwell-connected-identity in Dallas, somebody > put > forward the opinion that it would be dangerous to change the To header > field > URI in a response (i.e., make it different from the From header field URI > in > the request). My assumption at the time was that it would undermine the > transaction concept in SIP, yet reading what RFC3261 has to say about > transactions, the value of the To header field URI in a response does not > appear to be involved in coupling a response to a request. Therefore I > assume the person who indicated the danger (which was not challenged at > the > meeting) has other reasons in mind. I would greatly appreciate opinions on > the wisdom or otherwise of allowing the To header field URI to change. It > seems that from discussion of connected-identity there is a desire from > some > parts of the community to include an (unauthenticated) identity in a > response. > > 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 Tue Apr 04 08:12:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQkMG-00028T-F0; Tue, 04 Apr 2006 08:10:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQkME-00027s-Fc for sip@ietf.org; Tue, 04 Apr 2006 08:10: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 1FQkME-000276-7r for sip@ietf.org; Tue, 04 Apr 2006 08:10:02 -0400 Received: from BPenfield [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A2180320; Tue, 04 Apr 2006 08:10:00 -0400 Message-ID: <005201c657e0$b32c17e0$800101df@acmepacket.com> From: "Bob Penfield" To: "Christer Holmberg \(JO/LMF\)" , References: <5EB80D22825EEE42872083AD5BFFB5945D1C89@esealmw113.eemea.ericsson.se> Subject: Re: [Sip] Outbound: Questions on reg-id Date: Tue, 4 Apr 2006 08:10:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 inline. ----- Original Message ----- >From: "Christer Holmberg (JO/LMF)" > >Hi, > >A few clarification questions on the reg-id parameter. > >The outbound draft (chapter 3.1) says that the reg-id can be >used by the registrar to determine that a user has rebooted. > >Q1: In order to achieve that you would have to make sure the >value is unique. Because, if you use value "1", then rebood, >and then use value"1" again I don't see what it will bring. > It may be a poor choice of words. What the registrar really needs to know is that a new "connection" or "flow" is the same as a previous "flow". The only things in the Contact guarateed to be the same after a UA reboots is the reg-id and sip-instance id. The UA might get a new IP Address from DHCP. The combination of reg-id & sip-instance identify the specific "flow" so the registar can locate existing binding. > >Q2: Doesn't the Call-ID, as defined by RFC3261 to be used with >registrations, provide the same functionaltity? > >Chapter 10.2.4 of RFC3261 says: > >"A UA SHOULD use the same Call-ID for all registrations during a >single boot cycle. Registration refreshes SHOULD be sent to the >same network address as the original registration, unless >redirected." > True, but the registrar still needs the sip-instance and reg-id to locate the specific flow. >Regards, > >Christer > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Apr 04 08:19:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQkSg-00069N-3w; Tue, 04 Apr 2006 08:16:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQkSe-000652-D6 for sip@ietf.org; Tue, 04 Apr 2006 08:16:40 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQkSd-0002Y1-Jv for sip@ietf.org; Tue, 04 Apr 2006 08:16:40 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 67C044F0002; Tue, 4 Apr 2006 14:13:41 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 14:13:40 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 14:13:40 +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] Connected-identity and changing the To header field inaresponse Date: Tue, 4 Apr 2006 14:13:40 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1C8E@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Connected-identity and changing the To header field inaresponse Thread-Index: AcZX4Kp34pO+t6fKQAGEAZF6FGg6yQAAEzzg From: "Christer Holmberg \(JO/LMF\)" To: "Bob Penfield" , "Elwell, John" , X-OriginalArrivalTime: 04 Apr 2006 12:13:40.0413 (UTC) FILETIME=[3589F6D0:01C657E1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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 Bob, I was told (see a few mails back) that it had been decided that backward compability with RFC 2543 does not need to be taken into account. Regards, Christer =20 -----Original Message----- From: Bob Penfield [mailto:BPenfield@acmepacket.com]=20 Sent: 4. huhtikuuta 2006 14:58 To: Elwell, John; sip@ietf.org Subject: Re: [Sip] Connected-identity and changing the To header field inaresponse The issue with changing the To in a response is backward compatibility with RFC 2543 which does use the To for transaction matching. RFC 2543 section 1.4.3 says: All responses to a request contain the same values in the Call-ID, CSeq, To, and From fields (with the possible addition of a tag in the To field (section 6.37)). This allows responses to be matched with requests. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 bpenfield@acmepacket.com ----- Original Message ----- From: "Elwell, John" To: Sent: Tuesday, April 04, 2006 2:45 AM Subject: [Sip] Connected-identity and changing the To header field in aresponse > During discussion of draft-elwell-connected-identity in Dallas,=20 > somebody put forward the opinion that it would be dangerous to change=20 > the To header field URI in a response (i.e., make it different from=20 > the From header field URI in the request). My assumption at the time=20 > was that it would undermine the transaction concept in SIP, yet=20 > reading what RFC3261 has to say about transactions, the value of the=20 > To header field URI in a response does not appear to be involved in=20 > coupling a response to a request. Therefore I assume the person who=20 > indicated the danger (which was not challenged at the > meeting) has other reasons in mind. I would greatly appreciate=20 > opinions on the wisdom or otherwise of allowing the To header field=20 > URI to change. It seems that from discussion of connected-identity=20 > there is a desire from some parts of the community to include an=20 > (unauthenticated) identity in a response. > > John > > ------------------------------------------------------------------------ -------- > _______________________________________________ > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 04 09:14:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQlIz-0000dL-Hl; Tue, 04 Apr 2006 09:10:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQlIx-0000co-VG for sip@ietf.org; Tue, 04 Apr 2006 09:10:43 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQlIx-0004hX-85 for sip@ietf.org; Tue, 04 Apr 2006 09:10:43 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A93CA4F0001; Tue, 4 Apr 2006 15:10:42 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 15:10:42 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 15:10: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="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound: Questions on reg-id Date: Tue, 4 Apr 2006 15:10:40 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1C90@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: Questions on reg-id Thread-Index: AcZX4Lqy9qNh8TPpR7mMRxOmzGql4QABnlDQ From: "Christer Holmberg \(JO/LMF\)" To: "Bob Penfield" , X-OriginalArrivalTime: 04 Apr 2006 13:10:41.0923 (UTC) FILETIME=[2CEAF530:01C657E9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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,=20 >A few clarification questions on the reg-id parameter. > >The outbound draft (chapter 3.1) says that the reg-id can be used by=20 >the registrar to determine that a user has rebooted. > >Q1: In order to achieve that you would have to make sure the value is=20 >unique. Because, if you use value "1", then rebood, and then use=20 >value"1" again I don't see what it will bring. > It may be a poor choice of words. What the registrar really needs to know is that a new "connection" or "flow" is the same as a previous "flow".=20 [CHH] Again, why can't you use Call-Id for that? >The only things in the Contact guarateed to be the same after a UA reboots is the reg-id and sip-instance id. [CHH] My understanding of the draft is NOT that the SAME req-id would be used. Where is that said? The draft says that when the UA registers multiple times, each registration gets a unique reg-id value. But, it does not say anything about re-usage the same reg-id values after a reboot. >The UA might get a new IP Address from DHCP. The combination of reg-id & sip-instance identify the specific "flow" so the=20 >registar can locate existing binding. > >Q2: Doesn't the Call-ID, as defined by RFC3261 to be used with=20 >registrations, provide the same functionaltity? > >Chapter 10.2.4 of RFC3261 says: > >"A UA SHOULD use the same Call-ID for all registrations during a single >boot cycle. Registration refreshes SHOULD be sent to the same network=20 >address as the original registration, unless redirected." > True, but the registrar still needs the sip-instance and reg-id to locate the specific flow. [CHH] I still don't see why we can't use Call-Id instead of reg-id. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Apr 04 09:15:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQlJe-0000o0-Bn; Tue, 04 Apr 2006 09:11:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQlJd-0000nr-5Q for sip@ietf.org; Tue, 04 Apr 2006 09:11:25 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQlJb-0004iu-Gg for sip@ietf.org; Tue, 04 Apr 2006 09:11:25 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DC474B77; Tue, 4 Apr 2006 15:11:22 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 15:11:22 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 15:11:22 +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] Connected-identity and changing the To header field inaresponse Date: Tue, 4 Apr 2006 15:11:21 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1C91@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Connected-identity and changing the To header field inaresponse Thread-Index: AcZX5mkwKudRKTE2TFuNVsMKeeDzywAACVBQ From: "Christer Holmberg \(JO/LMF\)" To: "Bob Penfield" , "Elwell, John" , X-OriginalArrivalTime: 04 Apr 2006 13:11:22.0391 (UTC) FILETIME=[4509E270:01C657E9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 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 Bob, The UAS would have to check EVERY Via branch, because the issue I raised was related to intermediate RFC2543 compliant stateful proxies.=20 Regards, Christer=20 -----Original Message----- From: Bob Penfield [mailto:BPenfield@acmepacket.com]=20 Sent: 4. huhtikuuta 2006 15:48 To: Christer Holmberg (JO/LMF); Elwell, John; sip@ietf.org Subject: Re: [Sip] Connected-identity and changing the To header field inaresponse I have not been following this thread that closely. However, if we were to allow the To to be changed in a response, we could still have backward compatibility by requiring the UAS check the bottom Via for the branch-id cookie to determine whether the UAC will use 3261 or 2543 transaction matching rules. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 bpenfield@acmepacket.com ----- Original Message ----- From: "Christer Holmberg (JO/LMF)" To: "Bob Penfield" ; "Elwell, John"=20 ; Sent: Tuesday, April 04, 2006 8:13 AM Subject: RE: [Sip] Connected-identity and changing the To header field inaresponse Hi Bob, I was told (see a few mails back) that it had been decided that backward compability with RFC 2543 does not need to be taken into account. Regards, Christer -----Original Message----- From: Bob Penfield [mailto:BPenfield@acmepacket.com] Sent: 4. huhtikuuta 2006 14:58 To: Elwell, John; sip@ietf.org Subject: Re: [Sip] Connected-identity and changing the To header field inaresponse The issue with changing the To in a response is backward compatibility with RFC 2543 which does use the To for transaction matching. RFC 2543 section 1.4.3 says: All responses to a request contain the same values in the Call-ID, CSeq, To, and From fields (with the possible addition of a tag in the To field (section 6.37)). This allows responses to be matched with requests. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 bpenfield@acmepacket.com ----- Original Message ----- From: "Elwell, John" To: Sent: Tuesday, April 04, 2006 2:45 AM Subject: [Sip] Connected-identity and changing the To header field in aresponse > During discussion of draft-elwell-connected-identity in Dallas,=20 > somebody put forward the opinion that it would be dangerous to change=20 > the To header field URI in a response (i.e., make it different from=20 > the From header field URI in the request). My assumption at the time=20 > was that it would undermine the transaction concept in SIP, yet=20 > reading what RFC3261 has to say about transactions, the value of the=20 > To header field URI in a response does not appear to be involved in=20 > coupling a response to a request. Therefore I assume the person who=20 > indicated the danger (which was not challenged at the > meeting) has other reasons in mind. I would greatly appreciate=20 > opinions on the wisdom or otherwise of allowing the To header field=20 > URI to change. It seems that from discussion of connected-identity=20 > there is a desire from some parts of the community to include an > (unauthenticated) identity in a response. > > John > > ------------------------------------------------------------------------ -------- > _______________________________________________ > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 04 09:29:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQlXZ-0000hm-6U; Tue, 04 Apr 2006 09:25:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQlXX-0000h1-Fu for sip@ietf.org; Tue, 04 Apr 2006 09:25:47 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQlXV-0005VW-Sx for sip@ietf.org; Tue, 04 Apr 2006 09:25:47 -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 k34DO3gj004990; Tue, 4 Apr 2006 16:24:05 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 16:25:41 +0300 Received: from esebe106.NOE.Nokia.com ([172.21.143.51]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 16:25:41 +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] Connected-identity and changing the To header fieldinaresponse Date: Tue, 4 Apr 2006 16:25:35 +0300 Message-ID: <6D39732D264EEB43B83B6CC08FBEB4CA01E38886@esebe106.NOE.Nokia.com> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1C8E@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Connected-identity and changing the To header fieldinaresponse Thread-Index: AcZX4Kp34pO+t6fKQAGEAZF6FGg6yQAAEzzgAAI9AxA= From: To: , , , X-OriginalArrivalTime: 04 Apr 2006 13:25:41.0471 (UTC) FILETIME=[451716F0:01C657EB] X-Spam-Score: 0.2 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c 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, I just wonder which principle we going to change next. I always liked ASN.1 encoding - maybe we can consider that for the April change to RFC 3261. I don't know who decided this in Vancouver, but I think a specification that was implemented by a quite bigger group of people than participants in IETF (ad hoc) meetings should be handled with great great care. Breaking compatibility with existing implementations is a horrible scenario and will not help the acceptance of SIP. Currently I see tendencies in IETF to change the basic specs (e.g. also PRACK). Please be aware that here we do not only talk about existing implementations but also other standards bodies (OMA, TISPAN, 3G, 3G2) that use RFCs as the base for their architectures. The reliablity of IETF specifications is a very important issue in these bodies and the amount of work it would cost, to align e.g. existing 3G specs to changes to very basic RFC 3261 principles, should be taken into account by IETF. I know that the more technical line of argumentation is favoured here, but I cannot help myself to get a little worried about the general attitude.=20 Best regards Georg -- Georg Mayer - Nokia http://www.nokia.com/openness http://www.imsbook.com =20 >-----Original Message----- >From: ext Christer Holmberg (JO/LMF)=20 >[mailto:christer.holmberg@ericsson.com]=20 >Sent: 04 April, 2006 15:14 >To: Bob Penfield; Elwell, John; sip@ietf.org >Subject: RE: [Sip] Connected-identity and changing the To=20 >header fieldinaresponse > > >Hi Bob, > >I was told (see a few mails back) that it had been decided=20 >that backward compability with RFC 2543 does not need to be=20 >taken into account. > >Regards, > >Christer > >=20 > >-----Original Message----- >From: Bob Penfield [mailto:BPenfield@acmepacket.com] >Sent: 4. huhtikuuta 2006 14:58 >To: Elwell, John; sip@ietf.org >Subject: Re: [Sip] Connected-identity and changing the To=20 >header field inaresponse > >The issue with changing the To in a response is backward=20 >compatibility with RFC 2543 which does use the To for=20 >transaction matching. RFC 2543 section >1.4.3 says: > > All responses to a request contain the same values in > the Call-ID, CSeq, To, and From fields (with the possible > addition of a tag in the To field (section 6.37)). > This allows responses to be matched with requests. > >cheers, >(-:bob > >Robert F. Penfield >Chief Software Architect >Acme Packet, Inc. >71 Third Avenue >Burlington, MA 01803 >bpenfield@acmepacket.com > >----- Original Message ----- >From: "Elwell, John" >To: >Sent: Tuesday, April 04, 2006 2:45 AM >Subject: [Sip] Connected-identity and changing the To header=20 >field in aresponse > > >> During discussion of draft-elwell-connected-identity in Dallas,=20 >> somebody put forward the opinion that it would be dangerous=20 >to change=20 >> the To header field URI in a response (i.e., make it different from=20 >> the From header field URI in the request). My assumption at the time=20 >> was that it would undermine the transaction concept in SIP, yet=20 >> reading what RFC3261 has to say about transactions, the value of the=20 >> To header field URI in a response does not appear to be involved in=20 >> coupling a response to a request. Therefore I assume the person who=20 >> indicated the danger (which was not challenged at the >> meeting) has other reasons in mind. I would greatly appreciate=20 >> opinions on the wisdom or otherwise of allowing the To header field=20 >> URI to change. It seems that from discussion of connected-identity=20 >> there is a desire from some parts of the community to include an >> (unauthenticated) identity in a response. >> >> John >> >> > > >--------------------------------------------------------------- >--------- >-------- > > >> _______________________________________________ >> 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=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=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 Tue Apr 04 09:36:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQle1-0004wH-Iz; Tue, 04 Apr 2006 09:32:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQldz-0004tz-NY for sip@ietf.org; Tue, 04 Apr 2006 09:32:27 -0400 Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQldy-0005iC-Ec for sip@ietf.org; Tue, 04 Apr 2006 09:32:27 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id 8D831740D8; Tue, 4 Apr 2006 15:32:25 +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 09924-01-27; Tue, 4 Apr 2006 15:32:25 +0200 (CEST) Received: from dhcp-wavelan-vo-35.publik.su.se (dhcp-wavelan-vo-35.publik.su.se [193.11.30.35]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id 3B1CF74011; Tue, 4 Apr 2006 15:32:25 +0200 (CEST) From: Fredrik Thulin To: sip@ietf.org Subject: Re: [Sip] Outbound: Questions on reg-id Date: Tue, 4 Apr 2006 15:32:14 +0200 User-Agent: KMail/1.9.1 References: <5EB80D22825EEE42872083AD5BFFB5945D1C90@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1C90@esealmw113.eemea.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200604041532.14532.ft@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.453 tagged_above=-99 required=7 tests=[AWL=0.212, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: "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 Tuesday 04 April 2006 15:10, Christer Holmberg (JO/LMF) wrote: ... > [CHH] My understanding of the draft is NOT that the SAME req-id would > be used. Where is that said? > > The draft says that when the UA registers multiple times, each > registration gets a unique reg-id value. But, it does not say > anything about re-usage the same reg-id values after a reboot. "The reg-id sequence does not have to be sequential but MUST be exactly the same reg-id sequence each time the device power cycles or reboots so that the reg-id values will collide with the previously used reg-id values. This is so the proxy can realize that the older registrations are probably not useful." /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Apr 04 09:37:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQlfd-0005TZ-2L; Tue, 04 Apr 2006 09:34:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQlfb-0005TJ-9N for sip@ietf.org; Tue, 04 Apr 2006 09:34:07 -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 1FQlfa-0005n3-0A for sip@ietf.org; Tue, 04 Apr 2006 09:34:07 -0400 Received: from BPenfield [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A5CC01F0; Tue, 04 Apr 2006 09:34:04 -0400 Message-ID: <001501c657ec$717eedc0$800101df@acmepacket.com> From: "Bob Penfield" To: "Christer Holmberg \(JO/LMF\)" , References: <5EB80D22825EEE42872083AD5BFFB5945D1C90@esealmw113.eemea.ericsson.se> Subject: Re: [Sip] Outbound: Questions on reg-id Date: Tue, 4 Apr 2006 09:34:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 section 4.2, it says: These ordinary registration requests MUST also add a distinct reg-id parameter to the Contact header field. Each one of these registrations will form a new flow from the UA to the proxy. The reg-id sequence does not have to be sequential but MUST be exactly the same reg-id sequence each time the device power cycles or reboots so that the reg-id values will collide with the previously used reg-id values. This is so the proxy can realize that the older registrations are probably not useful. If the reg-id changed, the registrar would have no way to know that the old binding was no good anymore. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 bpenfield@acmepacket.com ----- Original Message ----- From: "Christer Holmberg (JO/LMF)" To: "Bob Penfield" ; Sent: Tuesday, April 04, 2006 9:10 AM Subject: RE: [Sip] Outbound: Questions on reg-id Hi, >A few clarification questions on the reg-id parameter. > >The outbound draft (chapter 3.1) says that the reg-id can be used by >the registrar to determine that a user has rebooted. > >Q1: In order to achieve that you would have to make sure the value is >unique. Because, if you use value "1", then rebood, and then use >value"1" again I don't see what it will bring. > It may be a poor choice of words. What the registrar really needs to know is that a new "connection" or "flow" is the same as a previous "flow". [CHH] Again, why can't you use Call-Id for that? >The only things in the Contact guarateed to be the same after a UA reboots is the reg-id and sip-instance id. [CHH] My understanding of the draft is NOT that the SAME req-id would be used. Where is that said? The draft says that when the UA registers multiple times, each registration gets a unique reg-id value. But, it does not say anything about re-usage the same reg-id values after a reboot. >The UA might get a new IP Address from DHCP. The combination of reg-id & sip-instance identify the specific "flow" so the >registar can locate existing binding. > >Q2: Doesn't the Call-ID, as defined by RFC3261 to be used with >registrations, provide the same functionaltity? > >Chapter 10.2.4 of RFC3261 says: > >"A UA SHOULD use the same Call-ID for all registrations during a single >boot cycle. Registration refreshes SHOULD be sent to the same network >address as the original registration, unless redirected." > True, but the registrar still needs the sip-instance and reg-id to locate the specific flow. [CHH] I still don't see why we can't use Call-Id instead of reg-id. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Apr 04 09:51:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQltB-0002w1-DA; Tue, 04 Apr 2006 09:48:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQlt9-0002vu-LO for sip@ietf.org; Tue, 04 Apr 2006 09:48:07 -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 1FQlt9-0006F7-9P for sip@ietf.org; Tue, 04 Apr 2006 09:48:07 -0400 Received: from BPenfield [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A9150144; Tue, 04 Apr 2006 09:48:05 -0400 Message-ID: <001c01c657ee$66fae730$800101df@acmepacket.com> From: "Bob Penfield" To: "Christer Holmberg \(JO/LMF\)" , "Elwell, John" , References: <5EB80D22825EEE42872083AD5BFFB5945D1C91@esealmw113.eemea.ericsson.se> Subject: Re: [Sip] Connected-identity and changing the To header fieldinaresponse Date: Tue, 4 Apr 2006 09:48:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f 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 Yes, you are correct. It would have to check them all. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 bpenfield@acmepacket.com ----- Original Message ----- From: "Christer Holmberg (JO/LMF)" To: "Bob Penfield" ; "Elwell, John" ; Sent: Tuesday, April 04, 2006 9:11 AM Subject: RE: [Sip] Connected-identity and changing the To header fieldinaresponse Hi Bob, The UAS would have to check EVERY Via branch, because the issue I raised was related to intermediate RFC2543 compliant stateful proxies. Regards, Christer -----Original Message----- From: Bob Penfield [mailto:BPenfield@acmepacket.com] Sent: 4. huhtikuuta 2006 15:48 To: Christer Holmberg (JO/LMF); Elwell, John; sip@ietf.org Subject: Re: [Sip] Connected-identity and changing the To header field inaresponse I have not been following this thread that closely. However, if we were to allow the To to be changed in a response, we could still have backward compatibility by requiring the UAS check the bottom Via for the branch-id cookie to determine whether the UAC will use 3261 or 2543 transaction matching rules. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 bpenfield@acmepacket.com ----- Original Message ----- From: "Christer Holmberg (JO/LMF)" To: "Bob Penfield" ; "Elwell, John" ; Sent: Tuesday, April 04, 2006 8:13 AM Subject: RE: [Sip] Connected-identity and changing the To header field inaresponse Hi Bob, I was told (see a few mails back) that it had been decided that backward compability with RFC 2543 does not need to be taken into account. Regards, Christer -----Original Message----- From: Bob Penfield [mailto:BPenfield@acmepacket.com] Sent: 4. huhtikuuta 2006 14:58 To: Elwell, John; sip@ietf.org Subject: Re: [Sip] Connected-identity and changing the To header field inaresponse The issue with changing the To in a response is backward compatibility with RFC 2543 which does use the To for transaction matching. RFC 2543 section 1.4.3 says: All responses to a request contain the same values in the Call-ID, CSeq, To, and From fields (with the possible addition of a tag in the To field (section 6.37)). This allows responses to be matched with requests. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 bpenfield@acmepacket.com ----- Original Message ----- From: "Elwell, John" To: Sent: Tuesday, April 04, 2006 2:45 AM Subject: [Sip] Connected-identity and changing the To header field in aresponse > During discussion of draft-elwell-connected-identity in Dallas, > somebody put forward the opinion that it would be dangerous to change > the To header field URI in a response (i.e., make it different from > the From header field URI in the request). My assumption at the time > was that it would undermine the transaction concept in SIP, yet > reading what RFC3261 has to say about transactions, the value of the > To header field URI in a response does not appear to be involved in > coupling a response to a request. Therefore I assume the person who > indicated the danger (which was not challenged at the > meeting) has other reasons in mind. I would greatly appreciate > opinions on the wisdom or otherwise of allowing the To header field > URI to change. It seems that from discussion of connected-identity > there is a desire from some parts of the community to include an > (unauthenticated) identity in a response. > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 04 10:01:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQm2R-0001Ty-F0; Tue, 04 Apr 2006 09:57:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQm2Q-0001Pt-JO for sip@ietf.org; Tue, 04 Apr 2006 09:57:42 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQm2P-0006lY-9K for sip@ietf.org; Tue, 04 Apr 2006 09:57:42 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 6DC783BF0A; Tue, 4 Apr 2006 15:57:40 +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 11885-01-82; Tue, 4 Apr 2006 15:57:40 +0200 (CEST) Received: from dhcp-wavelan-vo-35.publik.su.se (dhcp-wavelan-vo-35.publik.su.se [193.11.30.35]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 2A4823BE65; Tue, 4 Apr 2006 15:57:40 +0200 (CEST) From: Fredrik Thulin To: "Christer Holmberg \(JO/LMF\)" Subject: Re: [Sip] Outbound: Questions on reg-id Date: Tue, 4 Apr 2006 15:57:27 +0200 User-Agent: KMail/1.9.1 References: <5EB80D22825EEE42872083AD5BFFB5945D1C92@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1C92@esealmw113.eemea.ericsson.se> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200604041557.27488.ft@it.su.se> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.473 tagged_above=-99 required=7 tests=[AWL=0.192, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) 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 On Tuesday 04 April 2006 15:48, Christer Holmberg (JO/LMF) wrote: > Hi, > > Ok, I missed that text. I appologize for that. > > But, then, if I send a REGISTER with reg-id=1, then I reboot, then I > send a REGISTER with reg-id=1 again, how will the registrar know I > have rebooted? I'd say it doesn't know that you rebooted, but it knows that you want to replace the entry in the location database from your first REGISTER with the one in your second. This means that you don't want to use the flow from your first REGISTER either. To better understand the benefit of this, picture the example with the first REGISTER going from IP tcp:192.0.2.11:1234 (source port 1234) with reg-id=1. Then a reboot and then your second REGISTER from tcp:192.0.2.11:1111 (new source port) but once again reg-id=1. Oh, and it's not really just saying that you "want" the registrar to stop using the old flow, you indicate to the registrar that it MUST stop using the old flow but may very well use the new flow you just initiated. /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Apr 04 10:02:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQm3q-00033E-MZ; Tue, 04 Apr 2006 09:59:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQm3o-000332-VP for sip@ietf.org; Tue, 04 Apr 2006 09:59: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 1FQlAQ-0004Ev-KO for sip@ietf.org; Tue, 04 Apr 2006 09:01:54 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FQkxC-0001NA-67 for sip@ietf.org; Tue, 04 Apr 2006 08:48:16 -0400 Received: from BPenfield [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id AB0C01CC; Tue, 04 Apr 2006 08:48:12 -0400 Message-ID: <002601c657e6$09223850$800101df@acmepacket.com> From: "Bob Penfield" To: "Christer Holmberg \(JO/LMF\)" , "Elwell, John" , References: <5EB80D22825EEE42872083AD5BFFB5945D1C8E@esealmw113.eemea.ericsson.se> Subject: Re: [Sip] Connected-identity and changing the To header field inaresponse Date: Tue, 4 Apr 2006 08:48:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: -2.6 (--) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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 have not been following this thread that closely. However, if we were to allow the To to be changed in a response, we could still have backward compatibility by requiring the UAS check the bottom Via for the branch-id cookie to determine whether the UAC will use 3261 or 2543 transaction matching rules. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 bpenfield@acmepacket.com ----- Original Message ----- From: "Christer Holmberg (JO/LMF)" To: "Bob Penfield" ; "Elwell, John" ; Sent: Tuesday, April 04, 2006 8:13 AM Subject: RE: [Sip] Connected-identity and changing the To header field inaresponse Hi Bob, I was told (see a few mails back) that it had been decided that backward compability with RFC 2543 does not need to be taken into account. Regards, Christer -----Original Message----- From: Bob Penfield [mailto:BPenfield@acmepacket.com] Sent: 4. huhtikuuta 2006 14:58 To: Elwell, John; sip@ietf.org Subject: Re: [Sip] Connected-identity and changing the To header field inaresponse The issue with changing the To in a response is backward compatibility with RFC 2543 which does use the To for transaction matching. RFC 2543 section 1.4.3 says: All responses to a request contain the same values in the Call-ID, CSeq, To, and From fields (with the possible addition of a tag in the To field (section 6.37)). This allows responses to be matched with requests. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 bpenfield@acmepacket.com ----- Original Message ----- From: "Elwell, John" To: Sent: Tuesday, April 04, 2006 2:45 AM Subject: [Sip] Connected-identity and changing the To header field in aresponse > During discussion of draft-elwell-connected-identity in Dallas, > somebody put forward the opinion that it would be dangerous to change > the To header field URI in a response (i.e., make it different from > the From header field URI in the request). My assumption at the time > was that it would undermine the transaction concept in SIP, yet > reading what RFC3261 has to say about transactions, the value of the > To header field URI in a response does not appear to be involved in > coupling a response to a request. Therefore I assume the person who > indicated the danger (which was not challenged at the > meeting) has other reasons in mind. I would greatly appreciate > opinions on the wisdom or otherwise of allowing the To header field > URI to change. It seems that from discussion of connected-identity > there is a desire from some parts of the community to include an > (unauthenticated) identity in a response. > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 04 10:04:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQm5f-0003mK-HW; Tue, 04 Apr 2006 10:01:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQm5e-0003lw-7i for sip@ietf.org; Tue, 04 Apr 2006 10:01:02 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQm5d-00072N-VQ for sip@ietf.org; Tue, 04 Apr 2006 10:01:02 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 04 Apr 2006 07:01:01 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,164,1141632000"; d="scan'208"; a="25132588:sNHT28069664" 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 k34E11Wc026993; Tue, 4 Apr 2006 10:01: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); Tue, 4 Apr 2006 10:00:45 -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] Connected-identity and changing the To header field inaresponse Date: Tue, 4 Apr 2006 10:00:41 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3014A3AD9@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Connected-identity and changing the To header field inaresponse Thread-Index: AcZX3x3HiYtRPOKJSh+FyJzvUZsXwgAEIo2w From: "Michael Hammer \(mhammer\)" To: "Bob Penfield" , "Elwell, John" , X-OriginalArrivalTime: 04 Apr 2006 14:00:45.0704 (UTC) FILETIME=[2B4F9080:01C657F0] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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 It has now been about 4 years since RFC-3261 was published. =20 Is it about time to declare RFC-2543 really obsolete and=20 end discussion of backwards compatibility with it? Mike =20 > -----Original Message----- > From: Bob Penfield [mailto:BPenfield@acmepacket.com]=20 > Sent: Tuesday, April 04, 2006 7:58 AM > To: Elwell, John; sip@ietf.org > Subject: Re: [Sip] Connected-identity and changing the To=20 > header field inaresponse >=20 > The issue with changing the To in a response is backward=20 > compatibility with RFC 2543 which does use the To for=20 > transaction matching. RFC 2543 section > 1.4.3 says: >=20 > All responses to a request contain the same values in > the Call-ID, CSeq, To, and From fields (with the possible > addition of a tag in the To field (section 6.37)). > This allows responses to be matched with requests. >=20 > cheers, > (-:bob >=20 > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 71 Third Avenue > Burlington, MA 01803 > bpenfield@acmepacket.com >=20 > ----- Original Message ----- > From: "Elwell, John" > To: > Sent: Tuesday, April 04, 2006 2:45 AM > Subject: [Sip] Connected-identity and changing the To header=20 > field in aresponse >=20 >=20 > > During discussion of draft-elwell-connected-identity in Dallas,=20 > > somebody put forward the opinion that it would be dangerous=20 > to change=20 > > the To header field URI in a response (i.e., make it different from=20 > > the From header field URI in the request). My assumption at=20 > the time=20 > > was that it would undermine the transaction concept in SIP, yet=20 > > reading what RFC3261 has to say about transactions, the=20 > value of the=20 > > To header field URI in a response does not appear to be involved in=20 > > coupling a response to a request. Therefore I assume the person who=20 > > indicated the danger (which was not challenged at the > > meeting) has other reasons in mind. I would greatly appreciate=20 > > opinions on the wisdom or otherwise of allowing the To header field=20 > > URI to change. It seems that from discussion of connected-identity=20 > > there is a desire from some parts of the community to include an=20 > > (unauthenticated) identity in a response. > > > > John > > > > >=20 >=20 > -------------------------------------------------------------- > ------------------ >=20 >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 >=20 > _______________________________________________ > 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 Apr 04 10:09:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQmC0-0000EK-Ca; Tue, 04 Apr 2006 10:07:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQmBy-0000EE-RR for sip@ietf.org; Tue, 04 Apr 2006 10:07:34 -0400 Received: from [66.155.254.250] (helo=isdmail1.inovsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQmBx-0007SR-LG for sip@ietf.org; Tue, 04 Apr 2006 10:07:34 -0400 Received: from greatwall ([12.181.128.3]) by isdmail1.inovsys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 4 Apr 2006 10:07:33 -0400 From: "Gary Gan" To: Subject: [Sip] draft-ietf-sipping-conference-package : MTU Date: Tue, 4 Apr 2006 10:07:40 -0400 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: <001c01c657ee$66fae730$800101df@acmepacket.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZX7vftjd94S3kBTKWI8PKEZgGLFAAAd8tw Message-ID: X-OriginalArrivalTime: 04 Apr 2006 14:07:33.0126 (UTC) FILETIME=[1E273A60:01C657F1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed X-BeenThere: sip@ietf.org X-Mailman-Version: 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 SIP conference info package could be very large depending on the size of the conference. How does it handle the MTU issue? Gary Gan Clique Communications, LLC _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 04 10:17:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQmJV-0005GE-KD; Tue, 04 Apr 2006 10:15:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQmJT-0005G6-S2 for sip@ietf.org; Tue, 04 Apr 2006 10:15:19 -0400 Received: from mail1.microsoft.com ([131.107.1.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQmJS-0007i7-G2 for sip@ietf.org; Tue, 04 Apr 2006 10:15:19 -0400 Received: from mailout6.microsoft.com ([157.54.69.150]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 07:15:17 -0700 Received: from tuk-hub-03.redmond.corp.microsoft.com ([157.54.70.29]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 07:15:17 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by tuk-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 07:15:16 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 07:15:16 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] draft-ietf-sipping-conference-package : MTU Date: Tue, 4 Apr 2006 07:14:19 -0700 Message-ID: <65F27F597EB1E44384BA802189D334C61506F2@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sipping-conference-package : MTU Thread-Index: AcZX7vftjd94S3kBTKWI8PKEZgGLFAAAd8twAABORXo= References: From: "Sean Olson" To: "Gary Gan" , X-OriginalArrivalTime: 04 Apr 2006 14:15:16.0719 (UTC) FILETIME=[3279E7F0:01C657F2] X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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="===============1156124189==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1156124189== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C657F2.2C12271E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C657F2.2C12271E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Partial notifications and/or compression -----Original Message----- From: Gary Gan [mailto:ggan@cliquecom.com] Sent: Tue 4/4/2006 7:07 AM To: sip@ietf.org Subject: [Sip] draft-ietf-sipping-conference-package : MTU =20 The SIP conference info package could be very large depending on the = size of the conference. How does it handle the MTU issue? Gary Gan Clique Communications, LLC _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_01C657F2.2C12271E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] draft-ietf-sipping-conference-package : MTU

Partial notifications and/or compression

-----Original Message-----
From: Gary Gan [mailto:ggan@cliquecom.com]
Sent: Tue 4/4/2006 7:07 AM
To: sip@ietf.org
Subject: [Sip] draft-ietf-sipping-conference-package : MTU

The SIP conference info package could be very large depending on the = size of
the conference. How does it handle the MTU issue?

Gary Gan
Clique Communications, LLC



_______________________________________________
Sip mailing list  https://www1.ietf.org= /mailman/listinfo/sip
This list is for NEW development of the core SIP 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_01C657F2.2C12271E-- --===============1156124189== 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 --===============1156124189==-- From sip-bounces@ietf.org Tue Apr 04 10:27:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQmTd-0006TF-9X; Tue, 04 Apr 2006 10:25:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQmTb-0006Se-2c; Tue, 04 Apr 2006 10:25:47 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQmTZ-0008Kx-Q1; Tue, 04 Apr 2006 10:25:47 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 04 Apr 2006 07:25:45 -0700 X-IronPort-AV: i="4.03,164,1141632000"; d="scan'208"; a="266455197:sNHT32398424" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k34EPjYg008733; Tue, 4 Apr 2006 07:25:45 -0700 (PDT) Received: from 10.21.123.29 ([10.21.123.29]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 4 Apr 2006 14:25:44 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Mon, 03 Apr 2006 14:45:53 -0700 Subject: Re: [Sip] Last Call: 'Management Information Base for theSessionInitiation Protocol (SIP)' to Proposed Standard From: Cullen Jennings To: "Romascanu, Dan (Dan)" , Jean-Francois Mule , Samir Srivastava Message-ID: Thread-Topic: [Sip] Last Call: 'Management Information Base for theSessionInitiation Protocol (SIP)' to Proposed Standard Thread-Index: AcZOxX7Paqe914BiQ4WrxfWRZ79G3AF4BO6QAAo9/jAACZ368AB+wHrAAAZjoUAAF5oHMw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: "sip@ietf.org" , klingle@cisco.com, iesg@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 4/3/06 3:34 AM, "Romascanu, Dan (Dan)" wrote: >> --- 2. use of 'congested' >> Ok - we will stick with the name *and* definition of >> 'congested' as defined in the Network Services MIB. >> >> --- 3. expanding the definition of 'congested' based on >> sipping overload ID (draft-rosenberg-sipping-overload-reqs-00.txt) >> Thanks for elaborating on your comment. >> My view on this comment is that >> a) the SIP MIB as defined as capable of handling the >> RFC 3261 "very basic support for overload" as dicussed in >> section 3 of draft-rosenberg-sipping-overload-reqs-00.txt. >> ('congested' -> 503 or 5xx) >> b) once the overload requirements are stable, and new >> semantics are defined for handling overload, the MIB object >> sipServiceOperStatus could well be extended to add new values >> that could reflect the new behaviors an app can adopt under overload. >> So, based on the above, I would recommend we wait until the >> requirements in draft-rosenberg-sipping-overload-reqs-00.txt >> are stable, potential new mechanisms for dealing with >> overload are defined and see how this should be translated to >> reflect the operational status of a sip app through mgmt. >> >> Is that ok? This sounds good to me. The overload draft has not yet been adopted as a WG draft and will likely end up being a significant chunk of work. I think the MIB can easily be completed before this work is done and if the overload work provides more things we need in the MIB, we can update the MIB then. 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 Apr 04 10:31:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQmX0-0002mH-CB; Tue, 04 Apr 2006 10:29:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQmWz-0002jD-62 for sip@ietf.org; Tue, 04 Apr 2006 10:29:17 -0400 Received: from [66.155.254.250] (helo=isdmail1.inovsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQmWx-00009d-S2 for sip@ietf.org; Tue, 04 Apr 2006 10:29:17 -0400 Received: from greatwall ([12.181.128.3]) by isdmail1.inovsys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 4 Apr 2006 10:29:15 -0400 From: "Gary Gan" To: "'Sean Olson'" , Subject: RE: [Sip] draft-ietf-sipping-conference-package : MTU Date: Tue, 4 Apr 2006 10:29:23 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <65F27F597EB1E44384BA802189D334C61506F2@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZX7vftjd94S3kBTKWI8PKEZgGLFAAAd8twAABORXoAAFFUcA== Message-ID: X-OriginalArrivalTime: 04 Apr 2006 14:29:15.0383 (UTC) FILETIME=[265BE070:01C657F4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 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="===============2022469710==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2022469710== Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01C657D2.A44BAF50" This is a multi-part message in MIME format. ------=_NextPart_000_001E_01C657D2.A44BAF50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit According to the draft, the initial SUBSCRIBE always generates a full state package. Then it receives changes in the partial notifications. Even partial notifications, we can not guarantee the size will not exceed the MTU. Is there a mechanism defined in the SUBSCRIBE/NOTIFY, which I don't see it in the RFC3265, or in this draft to handle MTU? Gary Gan Partial notifications and/or compression -----Original Message----- From: Gary Gan [mailto:ggan@cliquecom.com] Sent: Tue 4/4/2006 7:07 AM To: sip@ietf.org Subject: [Sip] draft-ietf-sipping-conference-package : MTU The SIP conference info package could be very large depending on the size of the conference. How does it handle the MTU issue? Gary Gan Clique Communications, LLC _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_001E_01C657D2.A44BAF50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Sip] draft-ietf-sipping-conference-package : MTU

According to the draft, the initial = SUBSCRIBE always generates a full state package. Then it receives changes in the = partial notifications. Even partial notifications, we can not guarantee the size will not = exceed the MTU. Is there a mechanism defined in the SUBSCRIBE/NOTIFY, which I = don’t see it in the RFC3265, or in this draft to handle = MTU?

 

Gary = Gan

Partial notifications and/or compression

-----Original Message-----
From: Gary Gan [mailto:ggan@cliquecom.com]
Sent: Tue 4/4/2006 7:07 AM
To: sip@ietf.org
Subject: [Sip] draft-ietf-sipping-conference-package : MTU

The SIP conference info package could be very large depending on the = size of
the conference. How does it handle the MTU issue?

Gary Gan
Clique Communications, LLC



_______________________________________________
Sip mailing list  https://www1.ietf.org= /mailman/listinfo/sip
This list is for NEW development of the core SIP 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_001E_01C657D2.A44BAF50-- --===============2022469710== 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 --===============2022469710==-- From sip-bounces@ietf.org Tue Apr 04 10:52:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQmrn-0000R8-Sf; Tue, 04 Apr 2006 10:50:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQmrm-0000R3-TE for sip@ietf.org; Tue, 04 Apr 2006 10:50:46 -0400 Received: from [66.155.254.250] (helo=isdmail1.inovsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQmrm-0001La-KI for sip@ietf.org; Tue, 04 Apr 2006 10:50:46 -0400 Received: from greatwall ([12.181.128.3]) by isdmail1.inovsys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 4 Apr 2006 10:50:46 -0400 From: "Gary Gan" To: Subject: [Sip] draft-ietf-sipping-conference-package - Media Mixing Date: Tue, 4 Apr 2006 10:50:54 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZX9ywu8jRxgqx4R/OzcBaRDlLmvg== Message-ID: X-OriginalArrivalTime: 04 Apr 2006 14:50:46.0328 (UTC) FILETIME=[27D27380:01C657F7] X-Spam-Score: 0.2 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 X-BeenThere: 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="===============2002274641==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2002274641== Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01C657D5.A5C109E0" This is a multi-part message in MIME format. ------=_NextPart_000_002E_01C657D5.A5C109E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In conference info package, it contains a lot of detailed information to share among participants. It should add more information to the tag to help conference media mixing. In the SIP conference, imagine the multi-unicast media mixing scenario. Each participant need to share the media listening IP+PORT to the others. Since the Focus knows everybody's rtp/rtcp/codec info, on the conference info package, it should share it in the tag. Also it need to a new attribute like type, to define the type of media mixing the participant should anticipate. Gary Gan Sr. Software Developer Clique Communications, LLC 205 Rockingham Row Princeton Forrestal Village Princeton, NJ 08540 Phone: 609-564-0206 ------=_NextPart_000_002E_01C657D5.A5C109E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In conference info package, it contains a lot of = detailed information to share among participants. It should add more information to the = <media> tag to help conference media mixing. In the SIP conference, imagine the = multi-unicast media mixing scenario. Each participant need to share the media = listening IP+PORT to the others.

 

Since the Focus knows everybody’s = rtp/rtcp/codec info, on the conference info package, it should share it in the <media> = tag. Also it need to a new attribute like <media-mixing> type, to define the = type of media mixing the participant should = anticipate.

Gary = Gan
Sr. Software Developer

Clique Communications, = LLC
205 Rockingham = Row
Princeton Forrestal Village
Princeton, NJ = 08540
Phone: 609-564-0206

 

------=_NextPart_000_002E_01C657D5.A5C109E0-- --===============2002274641== 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 --===============2002274641==-- From sip-bounces@ietf.org Tue Apr 04 11:10:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQn9V-0002OR-Sc; Tue, 04 Apr 2006 11:09:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQn9U-0002OH-AV for sip@ietf.org; Tue, 04 Apr 2006 11:09:04 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQn9S-0002BF-W4 for sip@ietf.org; Tue, 04 Apr 2006 11:09:04 -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 k34F91FO028587 for ; Tue, 4 Apr 2006 10:09:02 -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 k34F91529688; Tue, 4 Apr 2006 10:09:01 -0500 (CDT) Message-ID: <44328C0D.9020407@lucent.com> Date: Tue, 04 Apr 2006 10:09:01 -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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Subject: [Sip] SIP/TLS (1): Domain certificates 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: , Content-Type: multipart/mixed; boundary="===============0865724006==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0865724006== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030507030201080005040105" This is a cryptographically signed message in MIME format. --------------ms030507030201080005040105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks: The SIP TLS draft presented during the Dallas IETF had spawned discussions, the next step of which was to discuss the open issues on the list. Over the next week or so, I will open up discrete threads to track the issues, beginning with this email. A rather important open issue discussed during the meeting has been that of domain certificates in SIP and their contents. To jump start this particular discussion, I have submitted a draft on domain certificates in SIP. Until it becomes available in the archives, you can get a version from: http://www.iit.edu/~gurbvij/I-D/draft-gurbani-sip-domain-certs-00.txt http://www.iit.edu/~gurbvij/I-D/draft-gurbani-sip-domain-certs-00.html This draft contains some initial thoughts on the contents of a domain certificate. The intent is to start a discussion on whether this is a good approach or whether we should consider other alternatives. Comments and feedback would be most 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) --------------ms030507030201080005040105 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA0MDQxNTA5MDFaMCMGCSqGSIb3DQEJ BDEWBBRK0eHqsm5mVSdgKRRqaaS2BoWTvzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGAS6vd5qunPxaCOAlO7qshHhRWZf9krpIcok0+9r8KeQBhpI6OMNDp J+6z8FmtsHu51AMBm0c3pXSOG2BQYM5Pq4IkT3eq+/o228iyYMD1gV+JTiVm9Wjm3Epp4L3K jy5BVdvDVHMDTcHH7LHr1GRO2sUZl8yGg8Gl/KsYqMwc1KIAAAAAAAA= --------------ms030507030201080005040105-- --===============0865724006== 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 --===============0865724006==-- From sip-bounces@ietf.org Tue Apr 04 11:39:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQnah-0001w1-Lq; Tue, 04 Apr 2006 11:37:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQnaf-0001et-HD for sip@ietf.org; Tue, 04 Apr 2006 11:37:09 -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 1FQm8k-0007Br-OH for sip@ietf.org; Tue, 04 Apr 2006 10:04:14 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FQltg-0001jF-Dt for sip@ietf.org; Tue, 04 Apr 2006 09:48:42 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0FF55E08; Tue, 4 Apr 2006 15:48:39 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 15:48:38 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 15:48:38 +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: Questions on reg-id Date: Tue, 4 Apr 2006 15:48:37 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1C92@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: Questions on reg-id Thread-Index: AcZX7MP5wcymRsijQUuBtoWVfY8UpQAAX5Kw From: "Christer Holmberg \(JO/LMF\)" To: "Fredrik Thulin" , X-OriginalArrivalTime: 04 Apr 2006 13:48:38.0650 (UTC) FILETIME=[79F3EDA0:01C657EE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -2.6 (--) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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, Ok, I missed that text. I appologize for that. But, then, if I send a REGISTER with reg-id=3D1, then I reboot, then I send a REGISTER with reg-id=3D1 again, how will the registrar know I = have rebooted? Regards, Christer=20 -----Original Message----- From: Fredrik Thulin [mailto:ft@it.su.se]=20 Sent: 4. huhtikuuta 2006 16:32 To: sip@ietf.org Cc: Christer Holmberg (JO/LMF) Subject: Re: [Sip] Outbound: Questions on reg-id On Tuesday 04 April 2006 15:10, Christer Holmberg (JO/LMF) wrote: ... > [CHH] My understanding of the draft is NOT that the SAME req-id would=20 > be used. Where is that said? > > The draft says that when the UA registers multiple times, each=20 > registration gets a unique reg-id value. But, it does not say anything > about re-usage the same reg-id values after a reboot. "The reg-id sequence does not have to be sequential but MUST be exactly the same reg-id sequence each time the device power cycles or reboots so that the reg-id values will collide with the previously used reg-id values. This is so the proxy can realize that the older registrations are probably not useful." /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 Tue Apr 04 11:40:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQnbu-00032R-V8; Tue, 04 Apr 2006 11:38:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQnbs-00032J-SE for sip@ietf.org; Tue, 04 Apr 2006 11:38:24 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQnbr-0003w0-CP for sip@ietf.org; Tue, 04 Apr 2006 11:38:24 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 7DABD6C01F for ; Tue, 4 Apr 2006 11:38:22 -0400 (EDT) Subject: Re: [Sip] draft-ietf-sipping-conference-package : MTU From: "Dale R. Worley" To: Sip In-Reply-To: References: Content-Type: text/plain Date: Tue, 04 Apr 2006 11:38:22 -0400 Message-Id: <1144165102.26176.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: 79899194edc4f33a41f49410777972f8 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Tue, 2006-04-04 at 10:07 -0400, Gary Gan wrote: > The SIP conference info package could be very large depending on the size of > the conference. How does it handle the MTU issue? Such a NOTIFY would be sent using TCP. RFC 3261 section 18: All SIP elements MUST implement UDP and TCP. Section 18.1.1: 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 [43] congestion controlled transport protocol, such as TCP. 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 Apr 04 12:28:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQoMU-0005yE-Qc; Tue, 04 Apr 2006 12:26:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQoMT-0005y8-1t for sip@ietf.org; Tue, 04 Apr 2006 12:26:33 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQoMR-0005ro-M6 for sip@ietf.org; Tue, 04 Apr 2006 12:26:33 -0400 Received: from [131.161.248.84] (open-131-161-248-84.cliq.com [131.161.248.84]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k34GQQF00768; Tue, 4 Apr 2006 09:26:26 -0700 In-Reply-To: <001b01c657ad$4e1f7140$31713b51@BEMBUSTER> References: <001b01c657ad$4e1f7140$31713b51@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <724f0adb9bc60dd7c2470bafe1051049@ekabal.com> Content-Transfer-Encoding: quoted-printable From: Rohan Mahy Date: Tue, 4 Apr 2006 09:26:35 -0700 To: "Jeroen van Bemmel" X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sip@ietf.org, Rohan Mahy Subject: [Sip] Re: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-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 On Apr 3, 2006, at 23:02, Jeroen van Bemmel wrote: > Rohan, > =A0 > Two things, 1 comment and a nit: > =A0 > 1. clarification on recent flows: There are several references to the=20= > registrar using the most recent flow. Hi Jeroen, The intent is that if you have more than one registration with the same=20= AOR, instance, *AND* reg-id you use the most recently registered of=20 these. An AOR and Contact with no instance will never match one with=20 an instance so I think this is pretty safe. If you can think of a=20 better way to express this in the draft please let me know. > There are two potential issues with this: > 1a q-value ordering - if the UAC first registers a flow with q=3D0.8 = and=20 > later with q=3D0.1, I think the former should be used (i.e. q-value=20 > taking precedence over flow establishment time). Same goes for=20 > scenario's with two different UACs registering for the same user, one=20= > using outbound and another one not (with higher q-value) > 1b multiple flows established with a single REGISTER - what is the=20 > most recent one in this case? A single register request can only establish one flow maximum. > 2 - section 11 says "the proxy stores the value of the Path header=20 > field", this should be "the registrar" good catch. 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 Apr 04 13:01:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQosC-0001fh-UM; Tue, 04 Apr 2006 12:59:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQosB-0001eu-OL for sip@ietf.org; Tue, 04 Apr 2006 12:59:19 -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 1FQos9-0007GX-A3 for sip@ietf.org; Tue, 04 Apr 2006 12:59:19 -0400 Received: from HKaplan [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A5E001DC; Tue, 04 Apr 2006 12:59:12 -0400 From: "Hadriel Kaplan" To: "'Christer Holmberg \(JO/LMF\)'" , "'Fredrik Thulin'" , Subject: RE: [Sip] Outbound: Questions on reg-id Date: Tue, 4 Apr 2006 12:59:19 -0400 Message-ID: <04d501c65809$1d644ba0$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZX7MP5wcymRsijQUuBtoWVfY8UpQAAX5KwAAYcA/A= In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1C92@esealmw113.eemea.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 Yeah it took me a while to figure that piece out as well the first time I read the draft. I think the answer is the Registrar doesn't need to know you "rebooted". It just needs to know to update the bindings of the previous set. (ie, replace them) Since the instance-id is the same for every flow, it can't be used. So they needed something which was different per active flow, but would collide when "replacing" stale flows. It's not just for UA reboots: if the UA's using UDP and the NAT rebooted and gave a different dynamic mapped port, then this helps update that as well. (I think? Would the STUN XOR-MAPPED-ADDRESS change not cause a reg-id change hopefully?) And the proxy needs to know (or the registrar if it's the edge box) that if your flow info changed (ie, new socket), that this is replacing an old one and is not just a secondary one. If it happens to be the same (as it could with UDP) then no one needs to be updated and the fact that the same reg-id is used is fine. For TCP my guess is this would simply be the UA's ephemeral port number. For UDP it would have to be something like the configured proxy/registrar list order. (ie, proxy-1 = reg-id 1, etc.) For DNS resolved UDP URI's it's much harder if the resolution order changes after reboot or ever, but the worst that would happen is you have a stale flow which would expire eventually. So long as you have an outbound registrar it will use the most recent binding I think. (which ironically is always the "Backup" flow on boot up, not the "Primary" flow) -hadriel > -----Original Message----- > From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, April 04, 2006 9:49 AM > To: Fredrik Thulin; sip@ietf.org > Subject: RE: [Sip] Outbound: Questions on reg-id > > > Hi, > > Ok, I missed that text. I appologize for that. > > But, then, if I send a REGISTER with reg-id=1, then I reboot, then I > send a REGISTER with reg-id=1 again, how will the registrar know I have > rebooted? > > Regards, > > Christer > > -----Original Message----- > From: Fredrik Thulin [mailto:ft@it.su.se] > Sent: 4. huhtikuuta 2006 16:32 > To: sip@ietf.org > Cc: Christer Holmberg (JO/LMF) > Subject: Re: [Sip] Outbound: Questions on reg-id > > On Tuesday 04 April 2006 15:10, Christer Holmberg (JO/LMF) wrote: > ... > > [CHH] My understanding of the draft is NOT that the SAME req-id would > > be used. Where is that said? > > > > The draft says that when the UA registers multiple times, each > > registration gets a unique reg-id value. But, it does not say anything > > > about re-usage the same reg-id values after a reboot. > > "The > reg-id sequence does not have to be sequential but MUST be exactly > the same reg-id sequence each time the device power cycles or reboots > so that the reg-id values will collide with the previously used > reg-id values. This is so the proxy can realize that the older > registrations are probably not useful." > > /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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 04 13:51:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQpfD-00066f-5Y; Tue, 04 Apr 2006 13:49:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQpfB-00066a-K0 for sip@ietf.org; Tue, 04 Apr 2006 13:49:57 -0400 Received: from [66.155.254.250] (helo=isdmail1.inovsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQpf9-0001PA-BV for sip@ietf.org; Tue, 04 Apr 2006 13:49:57 -0400 Received: from greatwall ([12.181.128.3]) by isdmail1.inovsys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 4 Apr 2006 13:49:50 -0400 From: "Gary Gan" To: "'Dale R. Worley'" Subject: RE: [Sip] draft-ietf-sipping-conference-package : MTU Date: Tue, 4 Apr 2006 13:49:58 -0400 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: <1144165102.26176.6.camel@niagra.pingtel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZX/dd4gP9bMcdxRFaMNh0lN5DgtQAEJeVQ Message-ID: X-OriginalArrivalTime: 04 Apr 2006 17:49:51.0009 (UTC) FILETIME=[2C26A910:01C65810] 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 Does it mean the SIP UA is supposed to check the SIP message size, if it is too big, it will automatically switch to TCP? Is it a mixed TCP/UDP SIP messages within a SIP session or it needs to decide UDP or TCP at the beginning of a session? How TCP is used in SIP? Is it a connection/disconnect per message like a WEB request, or connection on each session, or even a connection pool based on the destinations? I think only the WEB request style makes sense for SIP/TCP. SIP doesn't define differently for TCP in terms of connect and disconnect. Gary Gan -----Original Message----- From: Dale R. Worley [mailto:dworley@pingtel.com] Sent: Tuesday, April 04, 2006 11:38 AM To: Sip Subject: Re: [Sip] draft-ietf-sipping-conference-package : MTU On Tue, 2006-04-04 at 10:07 -0400, Gary Gan wrote: > The SIP conference info package could be very large depending on the size of > the conference. How does it handle the MTU issue? Such a NOTIFY would be sent using TCP. RFC 3261 section 18: All SIP elements MUST implement UDP and TCP. Section 18.1.1: 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 [43] congestion controlled transport protocol, such as TCP. 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 Tue Apr 04 15:05:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQqns-0004Gj-Sf; Tue, 04 Apr 2006 15:03:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQqnr-0004Ge-W5 for sip@ietf.org; Tue, 04 Apr 2006 15:02:59 -0400 Received: from smtp1.versatel.nl ([62.58.50.88] helo=smtp3.versatel.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQqnr-0004Aq-J1 for sip@ietf.org; Tue, 04 Apr 2006 15:02:59 -0400 Received: (qmail 12442 invoked by uid 0); 4 Apr 2006 19:02:58 -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 < >; 4 Apr 2006 19:02:58 -0000 Message-ID: <003201c6581a$5dc93820$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Rohan Mahy" References: <001b01c657ad$4e1f7140$31713b51@BEMBUSTER> <724f0adb9bc60dd7c2470bafe1051049@ekabal.com> Date: Tue, 4 Apr 2006 21:02:48 +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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: sip@ietf.org, Rohan Mahy Subject: [Sip] Re: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-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 Hi Rohan see inline Regards, Jeroen ----- Original Message ----- From: "Rohan Mahy" To: "Jeroen van Bemmel" Cc: "Rohan Mahy" ; Sent: Tuesday, April 04, 2006 6:26 PM Subject: Re: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-03.txt On Apr 3, 2006, at 23:02, Jeroen van Bemmel wrote: > Rohan, > > Two things, 1 comment and a nit: > > 1. clarification on recent flows: There are several references to the > registrar using the most recent flow. Hi Jeroen, The intent is that if you have more than one registration with the same AOR, instance, *AND* reg-id you use the most recently registered of these. An AOR and Contact with no instance will never match one with an instance so I think this is pretty safe. If you can think of a better way to express this in the draft please let me know. [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? > There are two potential issues with this: > 1a q-value ordering - if the UAC first registers a flow with q=0.8 and > later with q=0.1, I think the former should be used (i.e. q-value taking > precedence over flow establishment time). Same goes for scenario's with > two different UACs registering for the same user, one using outbound and > another one not (with higher q-value) > 1b multiple flows established with a single REGISTER - what is the most > recent one in this case? A single register request can only establish one flow maximum. [Jvb] Right, I mixed up my thoughts. So should the draft state then that the REGISTER request SHOULD NOT contain more than 1 Contact? > 2 - section 11 says "the proxy stores the value of the Path header field", > this should be "the registrar" good catch. 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 Apr 04 15:19:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQr2Q-0006JC-2L; Tue, 04 Apr 2006 15:18:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQr2O-0006J7-0h for sip@ietf.org; Tue, 04 Apr 2006 15:18:00 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQr2L-0004W9-CX for sip@ietf.org; Tue, 04 Apr 2006 15:17:59 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IX700401PMRO8@siemenscomms.co.uk> for sip@ietf.org; Tue, 04 Apr 2006 20:18:28 +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 <0IX70014JPMRST@siemenscomms.co.uk>; Tue, 04 Apr 2006 20:18:27 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 04 Apr 2006 20:17:55 +0100 Content-return: allowed Date: Tue, 04 Apr 2006 20:17:48 +0100 From: "Elwell, John" Subject: RE: [Sip] Connected-identity and changing the To header fieldinar esponse To: georg.mayer@nokia.com, christer.holmberg@ericsson.com, BPenfield@acmepacket.com, sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F266708969A87@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: 2a76bcd37b1c8a21336eb0a1ea6bbf48 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 Georg, The decision in Vancouver concerned the From header field URI in mid-dialog requests compared with (depending on direction) the From or To header field URI in the dialog-forming INVITE request. This was already anticipated when RFC3261 was written (see 12.2.1.1), so implementations have had a good 4 years to align. The issue we are discussing in this thread concerns changing the To header field URI in a response to make it different from the To header field URI in a request. It is not so clear that this was anticipated by RFC 3261, so I am rather cautious about allowing this - perhaps it is safer not to. But some people wish to be able to do this. John > -----Original Message----- > From: georg.mayer@nokia.com [mailto:georg.mayer@nokia.com] > Sent: 04 April 2006 14:26 > To: christer.holmberg@ericsson.com; BPenfield@acmepacket.com; > Elwell, John; sip@ietf.org > Subject: RE: [Sip] Connected-identity and changing the To > header fieldinaresponse > > Hi, > > I just wonder which principle we going to change next. I always liked > ASN.1 encoding - maybe we can consider that for the April > change to RFC > 3261. > > I don't know who decided this in Vancouver, but I think a > specification > that was implemented by a quite bigger group of people than > participants > in IETF (ad hoc) meetings should be handled with great great care. > Breaking compatibility with existing implementations is a horrible > scenario and will not help the acceptance of SIP. > > Currently I see tendencies in IETF to change the basic specs > (e.g. also > PRACK). Please be aware that here we do not only talk about existing > implementations but also other standards bodies (OMA, TISPAN, 3G, 3G2) > that use RFCs as the base for their architectures. The reliablity of > IETF specifications is a very important issue in these bodies and the > amount of work it would cost, to align e.g. existing 3G specs > to changes > to very basic RFC 3261 principles, should be taken into > account by IETF. > > I know that the more technical line of argumentation is favoured here, > but I cannot help myself to get a little worried about the general > attitude. > > Best regards > Georg > > -- > Georg Mayer - Nokia > http://www.nokia.com/openness > http://www.imsbook.com > > > >-----Original Message----- > >From: ext Christer Holmberg (JO/LMF) > >[mailto:christer.holmberg@ericsson.com] > >Sent: 04 April, 2006 15:14 > >To: Bob Penfield; Elwell, John; sip@ietf.org > >Subject: RE: [Sip] Connected-identity and changing the To > >header fieldinaresponse > > > > > >Hi Bob, > > > >I was told (see a few mails back) that it had been decided > >that backward compability with RFC 2543 does not need to be > >taken into account. > > > >Regards, > > > >Christer > > > > > > > >-----Original Message----- > >From: Bob Penfield [mailto:BPenfield@acmepacket.com] > >Sent: 4. huhtikuuta 2006 14:58 > >To: Elwell, John; sip@ietf.org > >Subject: Re: [Sip] Connected-identity and changing the To > >header field inaresponse > > > >The issue with changing the To in a response is backward > >compatibility with RFC 2543 which does use the To for > >transaction matching. RFC 2543 section > >1.4.3 says: > > > > All responses to a request contain the same values in > > the Call-ID, CSeq, To, and From fields (with the possible > > addition of a tag in the To field (section 6.37)). > > This allows responses to be matched with requests. > > > >cheers, > >(-:bob > > > >Robert F. Penfield > >Chief Software Architect > >Acme Packet, Inc. > >71 Third Avenue > >Burlington, MA 01803 > >bpenfield@acmepacket.com > > > >----- Original Message ----- > >From: "Elwell, John" > >To: > >Sent: Tuesday, April 04, 2006 2:45 AM > >Subject: [Sip] Connected-identity and changing the To header > >field in aresponse > > > > > >> During discussion of draft-elwell-connected-identity in Dallas, > >> somebody put forward the opinion that it would be dangerous > >to change > >> the To header field URI in a response (i.e., make it > different from > >> the From header field URI in the request). My assumption > at the time > >> was that it would undermine the transaction concept in SIP, yet > >> reading what RFC3261 has to say about transactions, the > value of the > >> To header field URI in a response does not appear to be > involved in > >> coupling a response to a request. Therefore I assume the > person who > >> indicated the danger (which was not challenged at the > >> meeting) has other reasons in mind. I would greatly appreciate > >> opinions on the wisdom or otherwise of allowing the To > header field > >> URI to change. It seems that from discussion of connected-identity > >> there is a desire from some parts of the community to include an > >> (unauthenticated) identity in a response. > >> > >> 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 > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol Use > >sip-implementors@cs.columbia.edu for questions on current sip > >Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 04 15:23:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQr5V-000737-4A; Tue, 04 Apr 2006 15:21:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQr5U-000732-AS for sip@ietf.org; Tue, 04 Apr 2006 15:21:12 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQr5U-0004bC-0X for sip@ietf.org; Tue, 04 Apr 2006 15:21:12 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IX700501PS67M@siemenscomms.co.uk> for sip@ietf.org; Tue, 04 Apr 2006 20:21: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 <0IX70016HPS6ST@siemenscomms.co.uk> for sip@ietf.org; Tue, 04 Apr 2006 20:21:42 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 04 Apr 2006 20:21:10 +0100 Content-return: allowed Date: Tue, 04 Apr 2006 20:20:12 +0100 From: "Elwell, John" To: sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F266708969A88@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Subject: [Sip] Updated connected-identity draft imminent X-BeenThere: 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="===============0568475814==" 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. --===============0568475814== Content-return: allowed Content-type: multipart/alternative; boundary="Boundary_(ID_Ja+Ea8/vEgDvFGtoCcpJMQ)" 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_Ja+Ea8/vEgDvFGtoCcpJMQ) Content-type: text/plain Content-transfer-encoding: 7BIT I am in the final stages of producing an updated connected-identity draft. As this is expected to become a working group document, I would just like to check that the proposed content captures what has been discussed or commented in Dallas and the mailing list. Compared to the previous version (draft-elwell-sip-connected-identity-01) I am making the following changes: - Change of To header field URI in sent mid-dialog requests to reflect the URI received in the From header field of the most recently received mid-dialog request. - Removal of open issue concerning UPDATE. - Re-organisation of UA behaviour sections to clarify and avoid duplication, with greater use of MUST. - Reference to procedures of sip-identity. - Inclusion of sections on proxy impact. - Minor corrections The use of a revised To header field URI in a response (compared with that in the Request) is left as an open issue (see ongoing mailing list thread). John --Boundary_(ID_Ja+Ea8/vEgDvFGtoCcpJMQ) Content-type: text/html Content-transfer-encoding: 7BIT Updated connected-identity draft imminent

I am in the final stages of producing an updated connected-identity draft. As this is expected to become a working group document, I would just like to check that the proposed content captures what has been discussed or commented in Dallas and the mailing list.

Compared to the previous version (draft-elwell-sip-connected-identity-01) I am making the following changes:
- Change of To header field URI in sent mid-dialog requests to reflect the URI received in the From header field of the most recently received mid-dialog request.

- Removal of open issue concerning UPDATE.
- Re-organisation of UA behaviour sections to clarify and avoid duplication, with greater use of MUST.
- Reference to procedures of sip-identity.
- Inclusion of sections on proxy impact.
- Minor corrections

The use of a revised To header field URI in a response (compared with that in the Request) is left as an open issue (see ongoing mailing list thread).

John


--Boundary_(ID_Ja+Ea8/vEgDvFGtoCcpJMQ)-- --===============0568475814== 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 --===============0568475814==-- From sip-bounces@ietf.org Tue Apr 04 15:23:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQr62-0007Ao-6z; Tue, 04 Apr 2006 15:21:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQr60-0007Ag-A0 for sip@ietf.org; Tue, 04 Apr 2006 15:21:44 -0400 Received: from smtp1.versatel.nl ([62.58.50.88] helo=smtp3.versatel.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQr5z-0004dg-RX for sip@ietf.org; Tue, 04 Apr 2006 15:21:44 -0400 Received: (qmail 9786 invoked by uid 0); 4 Apr 2006 19:21:43 -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 < >; 4 Apr 2006 19:21:43 -0000 Message-ID: <002101c6581c$fc2b9100$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Michael Hammer \(mhammer\)" , "Bob Penfield" , "Elwell, John" , References: <072C5B76F7CEAB488172C6F64B30B5E3014A3AD9@xmb-rtp-20b.amer.cisco.com> Subject: Re: [Sip] Connected-identity and changing the To header fieldinaresponse Date: Tue, 4 Apr 2006 21:21:33 +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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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 big humm on that ----- Original Message ----- From: "Michael Hammer (mhammer)" To: "Bob Penfield" ; "Elwell, John" ; Sent: Tuesday, April 04, 2006 4:00 PM Subject: RE: [Sip] Connected-identity and changing the To header fieldinaresponse It has now been about 4 years since RFC-3261 was published. Is it about time to declare RFC-2543 really obsolete and end discussion of backwards compatibility with it? Mike > -----Original Message----- > From: Bob Penfield [mailto:BPenfield@acmepacket.com] > Sent: Tuesday, April 04, 2006 7:58 AM > To: Elwell, John; sip@ietf.org > Subject: Re: [Sip] Connected-identity and changing the To > header field inaresponse > > The issue with changing the To in a response is backward > compatibility with RFC 2543 which does use the To for > transaction matching. RFC 2543 section > 1.4.3 says: > > All responses to a request contain the same values in > the Call-ID, CSeq, To, and From fields (with the possible > addition of a tag in the To field (section 6.37)). > This allows responses to be matched with requests. > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 71 Third Avenue > Burlington, MA 01803 > bpenfield@acmepacket.com > > ----- Original Message ----- > From: "Elwell, John" > To: > Sent: Tuesday, April 04, 2006 2:45 AM > Subject: [Sip] Connected-identity and changing the To header > field in aresponse > > > > During discussion of draft-elwell-connected-identity in Dallas, > > somebody put forward the opinion that it would be dangerous > to change > > the To header field URI in a response (i.e., make it different from > > the From header field URI in the request). My assumption at > the time > > was that it would undermine the transaction concept in SIP, yet > > reading what RFC3261 has to say about transactions, the > value of the > > To header field URI in a response does not appear to be involved in > > coupling a response to a request. Therefore I assume the person who > > indicated the danger (which was not challenged at the > > meeting) has other reasons in mind. I would greatly appreciate > > opinions on the wisdom or otherwise of allowing the To header field > > URI to change. It seems that from discussion of connected-identity > > there is a desire from some parts of the community to include an > > (unauthenticated) identity in a response. > > > > 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 04 15:52:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQrXU-0007ub-7Z; Tue, 04 Apr 2006 15:50:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQrXO-0007nt-9v; Tue, 04 Apr 2006 15:50:02 -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 1FQrXN-0005Z0-Vn; Tue, 04 Apr 2006 15:50:02 -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 k34Jo1vP027855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 4 Apr 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FQrXN-0003IW-I8; Tue, 04 Apr 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, 04 Apr 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-fork-loop-fix-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 : Addressing an Amplification Vulnerability in Forking Proxies Author(s) : R. Sparks, et al. Filename : draft-ietf-sip-fork-loop-fix-01.txt Pages : 9 Date : 2006-4-4 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). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-fork-loop-fix-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-fork-loop-fix-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-fork-loop-fix-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-4-4135043.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-fork-loop-fix-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-fork-loop-fix-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-4135043.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 Apr 04 15:59:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQreU-0007V9-Ie; Tue, 04 Apr 2006 15:57:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQreT-0007Uz-Aj for sip@ietf.org; Tue, 04 Apr 2006 15:57:21 -0400 Received: from [66.155.254.250] (helo=isdmail1.inovsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQreS-0006JZ-UU for sip@ietf.org; Tue, 04 Apr 2006 15:57:21 -0400 Received: from greatwall ([12.181.128.3]) by isdmail1.inovsys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 4 Apr 2006 15:57:19 -0400 From: "Gary Gan" To: "'Gary Gan'" , "'Dale R. Worley'" Subject: RE: [Sip] draft-ietf-sipping-conference-package : MTU Date: Tue, 4 Apr 2006 15:57:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZX/dd4gP9bMcdxRFaMNh0lN5DgtQAEJeVQAAOxbZA= Message-ID: X-OriginalArrivalTime: 04 Apr 2006 19:57:20.0085 (UTC) FILETIME=[FB5B0850:01C65821] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 did a network trace for protocol analysis. For the SIP client I tested, the TCP connection is created when it first registers, shutdown when it un-registers. In between, it uses the same connection for SIP requests and responses. When a UA registers, it specifies the TCP/UDP or both. But for large SIP messages like the conference info package, MTU will be an issue. The sender can not guarantee the path not to exceed the MTU size, and the sender will not know if all the nodes in the path support TCP. As far as I know, a lot of SIP clients either support UDP or TCP, but not both at the same time. A lot of SIP products work better on UDP protocol and shaky on TCP protocol, both servers and clients. Gary Gan =================================================================== Does it mean the SIP UA is supposed to check the SIP message size, if it is too big, it will automatically switch to TCP? Is it a mixed TCP/UDP SIP messages within a SIP session or it needs to decide UDP or TCP at the beginning of a session? How TCP is used in SIP? Is it a connection/disconnect per message like a WEB request, or connection on each session, or even a connection pool based on the destinations? I think only the WEB request style makes sense for SIP/TCP. SIP doesn't define differently for TCP in terms of connect and disconnect. Gary Gan -----Original Message----- From: Dale R. Worley [mailto:dworley@pingtel.com] Sent: Tuesday, April 04, 2006 11:38 AM To: Sip Subject: Re: [Sip] draft-ietf-sipping-conference-package : MTU On Tue, 2006-04-04 at 10:07 -0400, Gary Gan wrote: > The SIP conference info package could be very large depending on the size of > the conference. How does it handle the MTU issue? Such a NOTIFY would be sent using TCP. RFC 3261 section 18: All SIP elements MUST implement UDP and TCP. Section 18.1.1: 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 [43] congestion controlled transport protocol, such as TCP. 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 04 16:27:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQs5k-000845-9P; Tue, 04 Apr 2006 16:25:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQs5i-000840-Tb for sip@ietf.org; Tue, 04 Apr 2006 16:25:30 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQs5h-0008IS-Iq for sip@ietf.org; Tue, 04 Apr 2006 16:25:30 -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 k34KPPdt009363; Tue, 4 Apr 2006 15:25:26 -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 k34KPP521673; Tue, 4 Apr 2006 15:25:25 -0500 (CDT) Message-ID: <4432D635.5050503@lucent.com> Date: Tue, 04 Apr 2006 15:25:25 -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: Michael Thomas Subject: Re: [Sip] SIP/TLS (1): Domain certificates in SIP References: <44328C0D.9020407@lucent.com> <44329E69.4080205@cisco.com> In-Reply-To: <44329E69.4080205@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d 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: , Content-Type: multipart/mixed; boundary="===============0914481501==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0914481501== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070200030706030208030906" This is a cryptographically signed message in MIME format. --------------ms070200030706030208030906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mike: Thanks for your comments. Michael Thomas wrote: > One thing that strikes me about this is that it seems to imply that > there is exactly two states: > > 0) you don't speak for the domain > 1) you do speak for the domain > > Are people convinced that this is sufficiently granular? Yes, good question for discussion. It has been said that in SIP, we invest a lot of trust in our proxies. As such, having an explicit acknowledgement that the proxy is an authority for a domain would back up that trust. > What if I > want to limit the scope of what a particular sip entity is entitled > to speak for? In particular, what about outsourced business > functions that I might want to allow the outsourcer to speak for > me in a more limited capacity -- say the extent of an outsourced > marketing campaign or somesuch? Are you perhaps concerned about an enterprise outsourcing to a SIP service provider (virtual SIP servers?) ... what Ian Foster calls "SourceForge for science" (I. Foster, "Service-Oriented Science," Science, Vol. 308, No. 5723, pp. 814-817, May 2005; available online at http://www.sciencemag.org/cgi/content/full/308/5723/814?ijkey=aqCCmCFix8Ll.&keytype=ref&siteid=sci) I am trying to understand how different that would be than an explicit permission (business level agreement) given to the outsourcer that it can act as a point of contact for a SIP service provider... 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) --------------ms070200030706030208030906 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA0MDQyMDI1MjVaMCMGCSqGSIb3DQEJ BDEWBBRQluAy38ThyDdOLUmrRl6SWzh7sDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGARbr+9wF2ydSiIavVAlcpNQVAO4TN0Ao2x2cl0DZdYxPxmxNNLIv3 Xt11+Aa9wBUxiwPwITo2UVcy+9Wvx41RzFWNtdmeP8ocm8w5NhpzxxJhIwnHqb222KZUWzbx q6ynXYD4rbthgsxs9l9tZfL6l5dVp56kkReRt/GVRv9+cFEAAAAAAAA= --------------ms070200030706030208030906-- --===============0914481501== 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 --===============0914481501==-- From sip-bounces@ietf.org Tue Apr 04 16:28:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQs70-0008UA-HN; Tue, 04 Apr 2006 16:26:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQs6y-0008U0-Nb for sip@ietf.org; Tue, 04 Apr 2006 16:26:48 -0400 Received: from ms-smtp-02-smtplb.rdc-nyc.rr.com ([24.29.109.6] helo=ms-smtp-02.rdc-nyc.rr.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQs6w-0008Oe-Em for sip@ietf.org; Tue, 04 Apr 2006 16:26:48 -0400 Received: from tarragona (cpe-68-175-84-59.nyc.res.rr.com [68.175.84.59]) by ms-smtp-02.rdc-nyc.rr.com (8.13.4/8.13.4) with ESMTP id k34KIhYR001478; Tue, 4 Apr 2006 16:18:44 -0400 (EDT) From: "Tarun Kapoor" To: "'Gary Gan'" , "'Dale R. Worley'" Subject: RE: [Sip] draft-ietf-sipping-conference-package : MTU Date: Tue, 4 Apr 2006 16:24:53 -0400 Message-ID: <014a01c65825$d5e44920$6501a8c0@tarragona> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Thread-Index: AcZX/dd4gP9bMcdxRFaMNh0lN5DgtQAEJeVQAAWZJiA= X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I believe that whether to use a "persistent" TCP connection or a connect/disconnect TCP model as a HTTP request is not specified anywhere. It really depends on many factors such as what service is being offered, what is the architecture, are there any NATs/firewalls to traverse, general network infrastructure, etc. In the end it is up to the particular vendor to decide on what "type" of TCP connection they need. However, the UA should decide whether it will support TCP or UDP at the beginning of a session and stick to it until it initiates another session. It's generally safer to use TCP if you know there is a chance of a SIP packet > MTU. -----Original Message----- From: Gary Gan [mailto:ggan@cliquecom.com] Sent: Tuesday, April 04, 2006 1:50 PM To: 'Dale R. Worley' Cc: sip@ietf.org Subject: RE: [Sip] draft-ietf-sipping-conference-package : MTU Does it mean the SIP UA is supposed to check the SIP message size, if it is too big, it will automatically switch to TCP? Is it a mixed TCP/UDP SIP messages within a SIP session or it needs to decide UDP or TCP at the beginning of a session? How TCP is used in SIP? Is it a connection/disconnect per message like a WEB request, or connection on each session, or even a connection pool based on the destinations? I think only the WEB request style makes sense for SIP/TCP. SIP doesn't define differently for TCP in terms of connect and disconnect. Gary Gan -----Original Message----- From: Dale R. Worley [mailto:dworley@pingtel.com] Sent: Tuesday, April 04, 2006 11:38 AM To: Sip Subject: Re: [Sip] draft-ietf-sipping-conference-package : MTU On Tue, 2006-04-04 at 10:07 -0400, Gary Gan wrote: > The SIP conference info package could be very large depending on the > size of > the conference. How does it handle the MTU issue? Such a NOTIFY would be sent using TCP. RFC 3261 section 18: All SIP elements MUST implement UDP and TCP. Section 18.1.1: 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 [43] congestion controlled transport protocol, such as TCP. 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 04 16:44:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsLy-0002fa-Kg; Tue, 04 Apr 2006 16:42:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsLw-0002fV-DZ for sip@ietf.org; Tue, 04 Apr 2006 16:42:16 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQsLv-0000KE-3R for sip@ietf.org; Tue, 04 Apr 2006 16:42:16 -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 k34KgDUr029878; Tue, 4 Apr 2006 15:42:14 -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 k34KgD507326; Tue, 4 Apr 2006 15:42:13 -0500 (CDT) Message-ID: <4432DA25.4060305@lucent.com> Date: Tue, 04 Apr 2006 15:42:13 -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: Tarun Kapoor Subject: Re: [Sip] draft-ietf-sipping-conference-package : MTU References: <014a01c65825$d5e44920$6501a8c0@tarragona> In-Reply-To: <014a01c65825$d5e44920$6501a8c0@tarragona> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 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="===============0545237868==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0545237868== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080403010908030802040408" This is a cryptographically signed message in MIME format. --------------ms080403010908030802040408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Tarun Kapoor wrote: > I believe that whether to use a "persistent" TCP connection or a > connect/disconnect TCP model as a HTTP request is not specified > anywhere. It really depends on many factors such as what service is > being offered, what is the architecture, are there any NATs/firewalls > to traverse, general network infrastructure, etc. In the end it is > up to the particular vendor to decide on what "type" of TCP > connection they need. It is true that there isn't *one* authoritative document that you can use to decipher persistent TCP connections. A few of us did work on this a while ago, which has since languished (see http://bgp.potaroo.net/ietf/all-ids/draft-gurbani-sipping-connection-guidelines-01.txt) Currently, the behavior of persistent TCP connections is straddled among rfc3261, sip-connect-reuse and sip-outbound drafts. 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) --------------ms080403010908030802040408 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA0MDQyMDQyMTNaMCMGCSqGSIb3DQEJ BDEWBBQXZHrWPENzzakceXV65KcK5VLDczBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGAWaH6LWUTKhXINt6l1ELxFalOlceabTBMIKT2EuPnk1GK6Voy41Kr NVVTAG8Hjxgk2sCWqQJz29Y4+F8uOa3cE6jcC8pf6AlbjXA0Imw158gnIq3UFoMhHjVI6hzS FAraIsZColVZiSJNHT6o2URfVV/hVt5s9NhnYgy0AxzT5QkAAAAAAAA= --------------ms080403010908030802040408-- --===============0545237868== 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 --===============0545237868==-- From sip-bounces@ietf.org Tue Apr 04 16:51:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsSi-0005Ym-FE; Tue, 04 Apr 2006 16:49:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsSh-0005Wc-Gr for sip@ietf.org; Tue, 04 Apr 2006 16:49:15 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQsSh-0000WU-89 for sip@ietf.org; Tue, 04 Apr 2006 16:49:15 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 04 Apr 2006 13:49:15 -0700 X-IronPort-AV: i="4.03,164,1141632000"; d="scan'208"; a="266601522:sNHT32278404" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k34KnE1j007403; Tue, 4 Apr 2006 13:49:14 -0700 (PDT) Received: from 10.21.89.11 ([10.21.89.11]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 4 Apr 2006 20:49:13 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Tue, 04 Apr 2006 13:49:14 -0700 From: Cullen Jennings To: Jean-Francois Mule , "Kevin Lingle (klingle)" , "sip@ietf.org" Message-ID: Thread-Topic: SIP MIB ietf-sip-mib comments Thread-Index: AcY5j29dKQxxIed4SCWenzWDWU3cwgCDbzWgAWHdczABPKwkYAAB1NDAAC8iRbAEU4MgYw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: "Romascanu, Dan \(Dan\)" , Juergen Schoenwaelder Subject: [Sip] SIP MIB ietf-sip-mib 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 Sorry I did not read these until IETF last call but few comments ... take these very much as questions not requests for change. I would be thrilled if we could resolve them all with no changes to the draft. I suspect some of them are issues that have been discussed before and I have just not follwed the whole discussion. SipTransportProtocol It is weird to include TLS given we have TLS for TCP, SCTP, and might have for UDP too. sipMaxTransactions - I really don't know how I would decide what to report in most proxies or what an administrator would do with this information. Max transaction per second would be a a way that might make more sense to me. At first I just sort of ignored this but when I saw it was one of the mandatory to implement ones, well, I'm not sure I know how to implement it or what it is used for. (The one proxy where I would really know how to implement this, and the one that I suspect motivated this idea, has been end of lifted which says something about the length of time we have been working on this MIB :-) In sipOptionTagTable, I did not see how the HeaderField stuff ended up with 0xA0. I imagine this is all right, it was just not obvious to me how this all worked. It seem that not many people use sipOrganization - do we really want this is the mandatory group. Given the many ways that UA determine what the next hop is, the sipUACfgServerAddr left me feeling pretty uncomfortable. On the sipProxyAUthMethod, what do you do if using both TLS and Digest. TLS often uses Digest at the same time. in sipProxyAuthRealm, the comment about this may need to be stored per user was concerning. I agree that in some cases it may need to be. However, I don't see how this MIB could work when it is per user. Do we just say this item is empty or ignored if it is per user? Does the MIB work if it is per user and I just don't understand how? sipRegAlloowThirdParty - there are two definitions in common usage for 3rd party reg. This is one of them. However, I don't know of any deployment situations that allow this type of 3rd party reg. It is the other type that are allowed in practice. Do we need to this at all? Do we need to update? sipUserAuthenticationFailures - when there is a successful authentication, does this reset to zero. s/Jennins/Jennings/ :-) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 04 16:56:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsYG-0006W5-Tr; Tue, 04 Apr 2006 16:55:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsYF-0006W0-Mi for sip@ietf.org; Tue, 04 Apr 2006 16:54:59 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQsYC-0000c1-Dl for sip@ietf.org; Tue, 04 Apr 2006 16:54:59 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 04 Apr 2006 13:54:57 -0700 X-IronPort-AV: i="4.03,164,1141632000"; d="scan'208"; a="1791729147:sNHT32180112" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k34Kst1j009675; Tue, 4 Apr 2006 13:54:55 -0700 (PDT) Received: from 10.21.89.11 ([10.21.89.11]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 4 Apr 2006 20:54:55 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Tue, 04 Apr 2006 13:54:55 -0700 Subject: Re: [Sip] SIP/TLS (1): Domain certificates in SIP From: Cullen Jennings To: "Vijay K. Gurbani" , "sip@ietf.org" Message-ID: Thread-Topic: [Sip] SIP/TLS (1): Domain certificates in SIP Thread-Index: AcZYKgalRW4K8sQdEdqkAgARJEEJ/A== In-Reply-To: <44328C0D.9020407@lucent.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 don't understand the DNS name would refer to a host or conversely why the SIP name does not. Either can refer to either. I don't see the need for distinction - the cert needs to refer to the name used to reach the proxy - that is typically called the "domain" but may refer to a single host or many. I see no need to step into any CN disasters - they are very hard to specify and we have no backwards compatible need to do it. SIP has been SAN from the beginning. On 4/4/06 8:09 AM, "Vijay K. Gurbani" wrote: > Folks: The SIP TLS draft presented during the Dallas IETF had > spawned discussions, the next step of which was to discuss > the open issues on the list. > > Over the next week or so, I will open up discrete threads to > track the issues, beginning with this email. > > A rather important open issue discussed during the meeting has > been that of domain certificates in SIP and their contents. > > To jump start this particular discussion, I have submitted a draft > on domain certificates in SIP. Until it becomes available in > the archives, you can get a version from: > > http://www.iit.edu/~gurbvij/I-D/draft-gurbani-sip-domain-certs-00.txt > http://www.iit.edu/~gurbvij/I-D/draft-gurbani-sip-domain-certs-00.html > > This draft contains some initial thoughts on the contents of a > domain certificate. The intent is to start a discussion on > whether this is a good approach or whether we should consider > other alternatives. > > Comments and feedback would be most 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 Tue Apr 04 17:05:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsgR-0006WI-Rn; Tue, 04 Apr 2006 17:03:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsgQ-0006WD-KQ for sip@ietf.org; Tue, 04 Apr 2006 17:03:26 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQsgQ-000109-9g for sip@ietf.org; Tue, 04 Apr 2006 17:03:26 -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 k34L3JY17271; Tue, 4 Apr 2006 17:03:20 -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] SIP MIB ietf-sip-mib comments Date: Tue, 4 Apr 2006 16:03:16 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60B4DB1BB@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP MIB ietf-sip-mib comments Thread-Index: AcY5j29dKQxxIed4SCWenzWDWU3cwgCDbzWgAWHdczABPKwkYAAB1NDAAC8iRbAEU4MgYwAALwMw From: "Samir Srivastava" To: "Cullen Jennings" , "Jean-Francois Mule" , "Kevin Lingle \(klingle\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: "Romascanu, Dan \(Dan\)" , Juergen Schoenwaelder X-BeenThere: sip@ietf.org X-Mailman-Version: 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 was thinking on the SipTransportProtocol too. SipTransportProtocol is used within SipPortEntry where it has SipPort (InetPortNumber). I conclued that on a given port we can have SIP over TLS over TCP, SCTP, UDP, or (DCCP or whatever in future ) with different bit set in SipTransportProtocol =20 SIP over TLS over TCP e.g. port 5061 will have SipTransportProtocol bits 10100 While SIP over TLS over SCTP with different port will have SipTransportProtocol bits 11000 So it is allowed. Am I missing something ?=20 Thx Samir -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com]=20 Sent: Tuesday, April 04, 2006 1:49 PM To: Jean-Francois Mule; Kevin Lingle (klingle); sip@ietf.org Cc: Romascanu, Dan (Dan); Juergen Schoenwaelder Subject: [Sip] SIP MIB ietf-sip-mib comments Sorry I did not read these until IETF last call but few comments ... take these very much as questions not requests for change. I would be thrilled if we could resolve them all with no changes to the draft. I suspect some of them are issues that have been discussed before and I have just not follwed the whole discussion. SipTransportProtocol It is weird to include TLS given we have TLS for TCP, SCTP, and might have for UDP too. sipMaxTransactions - I really don't know how I would decide what to report in most proxies or what an administrator would do with this information. Max transaction per second would be a a way that might make more sense to me. At first I just sort of ignored this but when I saw it was one of the mandatory to implement ones, well, I'm not sure I know how to implement it or what it is used for. (The one proxy where I would really know how to implement this, and the one that I suspect motivated this idea, has been end of lifted which says something about the length of time we have been working on this MIB :-) In sipOptionTagTable, I did not see how the HeaderField stuff ended up with 0xA0. I imagine this is all right, it was just not obvious to me how this all worked.=20 It seem that not many people use sipOrganization - do we really want this is the mandatory group. Given the many ways that UA determine what the next hop is, the sipUACfgServerAddr left me feeling pretty uncomfortable. On the sipProxyAUthMethod, what do you do if using both TLS and Digest. TLS often uses Digest at the same time. in sipProxyAuthRealm, the comment about this may need to be stored per user was concerning. I agree that in some cases it may need to be. However, I don't see how this MIB could work when it is per user. Do we just say this item is empty or ignored if it is per user? Does the MIB work if it is per user and I just don't understand how? sipRegAlloowThirdParty - there are two definitions in common usage for 3rd party reg. This is one of them. However, I don't know of any deployment situations that allow this type of 3rd party reg. It is the other type that are allowed in practice. Do we need to this at all? Do we need to update? sipUserAuthenticationFailures - when there is a successful authentication, does this reset to zero. s/Jennins/Jennings/ :-) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 04 17:13:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsoL-00038R-1r; Tue, 04 Apr 2006 17:11:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsoJ-00035r-K8 for sip@ietf.org; Tue, 04 Apr 2006 17:11:35 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQsoJ-0001Ou-A5 for sip@ietf.org; Tue, 04 Apr 2006 17:11:35 -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 k34LBXm8021335; Tue, 4 Apr 2006 16:11:33 -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 k34LBX504655; Tue, 4 Apr 2006 16:11:33 -0500 (CDT) Message-ID: <4432E105.6000704@lucent.com> Date: Tue, 04 Apr 2006 16:11:33 -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: Cullen Jennings Subject: Re: [Sip] SIP/TLS (1): Domain certificates in SIP References: In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae 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="===============0550046390==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0550046390== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040705080804080202000602" This is a cryptographically signed message in MIME format. --------------ms040705080804080202000602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > I don't understand the DNS name would refer to a host or conversely > why the SIP name does not. Either can refer to either. I don't see > the need for distinction - the cert needs to refer to the name used > to reach the proxy - that is typically called the "domain" but may > refer to a single host or many. If the "domain" refers to many hosts, then is the cert shared among all the hosts? Or does each host have a different cert with the same domainname in SAN but a unique serial number? If a cert only has a SAN of DNS:proxy-1.example.com" is the intent, then that proxy-1 is the authority for example.com? Then, if another cert has a SAN of "DNS:proxy-1.south.example.com" is the intent that proxy-1 is the authority for south.example.com zone AND example.com zone? > I see no need to step into any CN disasters - they are very hard to > specify and we have no backwards compatible need to do it. SIP has > been SAN from the beginning. OK. Thanks for the clarification. However, in rfc3261, SAN is only mentioned in connection with S/MIME certs (section 23.2). For TLS certs, rfc3261 simply says "Proxy servers, redirect servers, and registrars SHOULD possess a site certificate whose subject corresponds to their canonical hostname". It is probably the intent that the "subject" in that sentence refer to SAN; but it is not clear from simply reading the sentence that this is indeed the intent. 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) --------------ms040705080804080202000602 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA0MDQyMTExMzNaMCMGCSqGSIb3DQEJ BDEWBBTe1WaSqLJa8ijZuWOVuZOCrRDWQjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGAftjbtPDUOCsicvNzQHqPVDsIulZ4eZ8ePpMGf5+nnhmqU014Glp2 u1bPWwn8m0ERkICsKoEBHoh3OsOUjQT0lt4jFklcDb9/twMr4b/4jqeR+5xpRBlGd6G75Xk5 zglzeqEzWKAhDkYPv0eFizvKVqk8//tODxNK//xnXtoMbWUAAAAAAAA= --------------ms040705080804080202000602-- --===============0550046390== 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 --===============0550046390==-- From sip-bounces@ietf.org Tue Apr 04 17:34:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQt8P-0004Gi-Je; Tue, 04 Apr 2006 17:32:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQt8N-0004Fk-DI for sip@ietf.org; Tue, 04 Apr 2006 17:32:19 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQt8M-000268-FM for sip@ietf.org; Tue, 04 Apr 2006 17:32:19 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CC6BE555; Tue, 4 Apr 2006 23:32: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); Tue, 4 Apr 2006 23:32:17 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 23:32: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="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Connected-identity and changing the To headerfieldinaresponse Date: Tue, 4 Apr 2006 23:32:16 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1C98@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Connected-identity and changing the To headerfieldinaresponse Thread-Index: AcZYHywppMsBJ3KmQ0eFbr+NoWANXgAD/DTQ From: "Christer Holmberg \(JO/LMF\)" To: "Jeroen van Bemmel" , "Michael Hammer \(mhammer\)" , "Bob Penfield" , "Elwell, John" , X-OriginalArrivalTime: 04 Apr 2006 21:32:17.0078 (UTC) FILETIME=[3F072D60:01C6582F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 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, It would probably give us better flexibility and freedom when defining SIP extensions. Regards, Christer=20 -----Original Message----- From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 Sent: 4. huhtikuuta 2006 22:22 To: Michael Hammer (mhammer); Bob Penfield; Elwell, John; sip@ietf.org Subject: Re: [Sip] Connected-identity and changing the To headerfieldinaresponse big humm on that ----- Original Message ----- From: "Michael Hammer (mhammer)" To: "Bob Penfield" ; "Elwell, John"=20 ; Sent: Tuesday, April 04, 2006 4:00 PM Subject: RE: [Sip] Connected-identity and changing the To header fieldinaresponse It has now been about 4 years since RFC-3261 was published. Is it about time to declare RFC-2543 really obsolete and end discussion of backwards compatibility with it? Mike > -----Original Message----- > From: Bob Penfield [mailto:BPenfield@acmepacket.com] > Sent: Tuesday, April 04, 2006 7:58 AM > To: Elwell, John; sip@ietf.org > Subject: Re: [Sip] Connected-identity and changing the To header field > inaresponse > > The issue with changing the To in a response is backward compatibility > with RFC 2543 which does use the To for transaction matching. RFC 2543 > section > 1.4.3 says: > > All responses to a request contain the same values in > the Call-ID, CSeq, To, and From fields (with the possible > addition of a tag in the To field (section 6.37)). > This allows responses to be matched with requests. > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 71 Third Avenue > Burlington, MA 01803 > bpenfield@acmepacket.com > > ----- Original Message ----- > From: "Elwell, John" > To: > Sent: Tuesday, April 04, 2006 2:45 AM > Subject: [Sip] Connected-identity and changing the To header field in=20 > aresponse > > > > During discussion of draft-elwell-connected-identity in Dallas,=20 > > somebody put forward the opinion that it would be dangerous > to change > > the To header field URI in a response (i.e., make it different from=20 > > the From header field URI in the request). My assumption at > the time > > was that it would undermine the transaction concept in SIP, yet=20 > > reading what RFC3261 has to say about transactions, the > value of the > > To header field URI in a response does not appear to be involved in=20 > > coupling a response to a request. Therefore I assume the person who=20 > > indicated the danger (which was not challenged at the > > meeting) has other reasons in mind. I would greatly appreciate=20 > > opinions on the wisdom or otherwise of allowing the To header field=20 > > URI to change. It seems that from discussion of connected-identity=20 > > there is a desire from some parts of the community to include an > > (unauthenticated) identity in a response. > > > > John > > > > > > > -------------------------------------------------------------- > ------------------ > > > > _______________________________________________ > > 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Tue Apr 04 21:07:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQwSb-00083s-0a; Tue, 04 Apr 2006 21:05:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQwSY-00083k-VV for sip@ietf.org; Tue, 04 Apr 2006 21:05:22 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQwSY-0002zb-8g for sip@ietf.org; Tue, 04 Apr 2006 21:05:22 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k3515LBW014356; Wed, 5 Apr 2006 01:05:21 GMT Received: from stntexch03.cis.neustar.com ([10.31.13.45]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 21:05:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Connected-identity and changing the To header field in aresponse Date: Tue, 4 Apr 2006 21:05:19 -0400 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD597054F43D3@stntexch03.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Connected-identity and changing the To header field in aresponse Thread-Index: AcZXtAuL0Q5celP0R3Kt549+t5HnegAG8+GA From: "Peterson, Jon" To: "Elwell, John" , X-OriginalArrivalTime: 05 Apr 2006 01:05:19.0860 (UTC) FILETIME=[0228EB40:01C6584D] X-Spam-Score: 0.5 (/) X-Scan-Signature: c40ff0c70161549dbde2f89c7946385a 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="===============1997377659==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1997377659== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6584D.02054A07" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6584D.02054A07 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, I was asked for clarification on this point after the meeting, and = I'll be providing it here. As you surmised, it is not that RFC3261 = relies on the addr-spec of the To or From header field for transaction = identification, or something. In fact, I would have essentially the same = concerns about any proposal that provided an additional header (say, a = 'Connected-Party' header) in responses to dialog-forming requests which = was understood to clobber the To header field and identify the AoR of = the party who was reached after retargeting of the request took place. =20 Starting with the goals of this approach: what sort of UAC decisions or = behavior do we hope to enable through sending a response with a modified = To header field? As far as I can understand, we either want to render = this AoR to the user of a UAC (so the user can react in one way or = another), or input the AoR to some sort of policy manager (e.g. = blacklist/whitelist) that might make a decision about whether or not the = session should continue -prior- to session establishment. If we don't = care about this occurring prior to session establishment, of course, = then we could go with the connected-identity draft as it is written = today. =20 A little refresher on my sipping-retarget draft: The core problem with = any scheme for connected party is figuring out how you'd decide whether = or not a particular respondent is authorized. This is the argument of = 2.2.1 of sipping-retarget, the "unanticipated respondent" problem. When = we think about what sorts of policy decisions we expect a human or = automata to make when receiving a response with identity information, we = have to acknowledge that the UAC has no way of knowing which respondents = are or are not authorized to respond to the request in question. Since = the UAC has no insight into any retargeting that has taken place, the = UAC has to assume that virtually any response is a potentially = legitimate one. As such, there is little room for any meaningful policy = decision when receiving a response. This problem is further compounded = by the fact that the UAS may have several possible legitimate AoRs it = could claim (I have a UA that registers its contact address under 3 = separate SIP services simultaneously), and of course the fact that AoRs = may be pretty uninformative (e.g. = sip:user31@freesipservice.example.com), all of which complicate = authorization decisions. Solving this problem is on the same footing as = solving the request-history problem set. =20 With that background, the problems with providing this connected party = information in responses (via the To header or what have you) are = roughly as follows: =20 a) The "unanticipated respondent" problem is especially an issue for = response identity because not all responses are success responses. If = you end up connecting to a party (receiving a 200), you can potentially = rely on human factors to help you identify who you are talking to (after = all, Carol can always answer Bob's phone regardless of who SIP thinks = you connected to) and/or use the connected party information to change = how you might address the party on the other side. With a 403 response, = you are in a very different predicament - how is UAC or user behavior = supposed to change based on the connected URI attributed to a 403, given = the unanticipated respondent problem? For provisional responses, the = issues become even worse - we then get into the wonders of forking, = multiple provisional responses from multiple sources asserting different = To header fields - in short, nothing which makes it any easier to render = a "responding" AoR to a user, for example. Response identity, in so far = as it deals with non-final, non-successful responses, opens up the = "unconnected party" problem set. I think this is just the wrong framing = of the problem. You want to know who you connected to, not who you = didn't connect to. =20 b) Getting a signature over the To header field in responses would be = difficult. In full awareness of Mr. Elwell's note below that certain = parties are interested in "(unauthenticated) identity in a response", if = this information is going to be put to any purpose, cause any change in = human or UAC behavior, I have a hard time seeing how anyone could defend = it being unsecured. If you want a human or an automata to make a policy = decision based on the AoR in the To header field of the response, some = sort of response identity signature would be necessary to prevent = obvious impersonation attacks designed to thwart authorization = decisions. With all due respect to the authors of = draft-cao-sip-response-identity/auth, I'm not sure this problem is = readily solved. Making sure that an appropriate authentication service = is in the path of responses is problematic, since responses must = traverse exactly the same path as requests. I played around with this a = lot in the early phases of SIP identity, and at the end of the day, I = had to conclude that the only way to make this work was to eliminate = retargeting. Since providing connected-identity in responses assumes = that retargeting has taken place, it wouldn't exactly be getting off on = the right foot. Constraining inbound request routing to a domain such = that responses will traverse an authentication service, or forcing a UAS = to participate in the Identity scheme, is likely to require mandatory = option-tags or comparable mechanisms that will limit the applicability = of response identity and more or less eliminate its opportunistic use. =20 c) The inability to reject a response. Take the easiest case - let's say = that the UAC receives a final success response, say a 200 response, with = a modified To header field from a party that is blacklisted by UAC = policy. What exactly is the UAC supposed to do? Send a 403? One cannot = reject responses. Maybe a CANCEL? As section 9.1 of RFC3261 says, CANCEL = "has no effect on requests that have already generated a final = response." Drop the request on the floor? You'll just receive = retransmissions. All you can do is ACK it, since the dialog has already = been formed, and then send a BYE. In other words, a session -will- be = established, there simply isn't an opportunity for policy to be put into = effect prior to session establishment. Also, consider the need for the = new responses defined in the sip-identity draft, like say the 438 = response - if the UAC receives a 200 response with a potentially = repairable error in the Identity header, how can it express that error = to the UAS, since it can't send responses to a response? =20 Given the above, why does the UAC need to know who has been reached in = the response, rather than in a request after the dialog has been formed? = As (c) illustrates, in the 200 response case a session will be = established anyway, so sharing the identity of the connected party after = session establishment doesn't actually miss some opportunity for = applying policy - moreover, an UPDATE or similar request that provides = the connected-identity information could be rejected by the = session-originating UA in a manner that is helpful to the = session-terminating UA (e.g., a 438 response could be sent). If we go = with the mechanism in the connected-identity draft, problem (b) = disappears, since request routing is far more malleable than response = routing. Additionally, the connected-identity draft wisely does not = attempt to solve "unconnected party" problems from (a), which are the = least tractable of the unanticipated respondent problems. Rather, = connected-identity provides an indication more along the lines of, "your = dialog was established, however that might have happened, and this is = who is on the other side". =20 Furthermore, any solution that tried to put the connected-identity = information into responses would be providing an imprimatur of = legitimacy to those responses - presuming they had a signature, UACs = would validate it, and provided it checked out, they would be tempted = say "this is a legitimate response." Nothing could be further from the = truth, as sipping-retarget illustrates. Legitimacy of responses cannot = be determined by UACs in the absence of something like request-history. =20 Finally, I like having one Identity header, and for the meaning of that = Identity header to *always* be that it is a signature over the From = header field issued by the domain identified by the host portion of the = addr-spec of the From header field. The current connected-identity = header draft provides that property. =20 Jon Peterson NeuStar, Inc. -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens.com] Sent: Monday, April 03, 2006 11:46 PM To: sip@ietf.org Subject: [Sip] Connected-identity and changing the To header field in = aresponse During discussion of draft-elwell-connected-identity in Dallas, somebody = put forward the opinion that it would be dangerous to change the To = header field URI in a response (i.e., make it different from the From = header field URI in the request). My assumption at the time was that it = would undermine the transaction concept in SIP, yet reading what RFC3261 = has to say about transactions, the value of the To header field URI in a = response does not appear to be involved in coupling a response to a = request. Therefore I assume the person who indicated the danger (which = was not challenged at the meeting) has other reasons in mind. I would = greatly appreciate opinions on the wisdom or otherwise of allowing the = To header field URI to change. It seems that from discussion of = connected-identity there is a desire from some parts of the community to = include an (unauthenticated) identity in a response. John=20 ------_=_NextPart_001_01C6584D.02054A07 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Connected-identity and changing the To header field in a = response
Yes, I=20 was asked for clarification on this point after the meeting, and I'll be = providing it here. As you surmised, it is not that RFC3261 relies on the = addr-spec of the To or From header field for transaction = identification, or=20 something. In fact, I would have essentially the same concerns about any = proposal that provided an additional header (say, a 'Connected-Party' = header) in=20 responses to dialog-forming requests which was understood to clobber the = To=20 header field and identify the AoR of the party who was reached after = retargeting=20 of the request took place.
 
Starting with the goals of this approach: what sort of UAC = decisions or=20 behavior do we hope to enable through sending a response with a modified = To=20 header field? As far as I can understand, we either want to render this = AoR to=20 the user of a UAC (so the user can react in one way or another), or = input the=20 AoR to some sort of policy manager (e.g. blacklist/whitelist) that = might=20 make a decision about whether or not the session should continue -prior- = to=20 session establishment. If we don't care about this occurring prior to = session=20 establishment, of course, then we could go with the = connected-identity=20 draft as it is written today.
 
A little refresher on my = sipping-retarget draft:=20 The core problem with any scheme for connected party is figuring out how = you'd=20 decide whether or not a particular respondent is authorized. This is the = argument of 2.2.1 of sipping-retarget, the "unanticipated respondent" = problem.=20 When we think about what sorts of policy decisions we expect a human or = automata=20 to make when receiving a response with identity information, we = have to=20 acknowledge that the UAC has no way of knowing which respondents are or = are not=20 authorized to respond to the request in question. Since the UAC has no = insight=20 into any retargeting that has taken place, the UAC has to assume = that=20 virtually any response is a potentially legitimate one. As such, there = is little=20 room for any meaningful policy decision when receiving a response. This = problem=20 is further compounded by the fact that the UAS may have several possible = legitimate AoRs it could claim (I have a UA that registers its = contact=20 address under 3 separate SIP services simultaneously), and of course the = fact=20 that AoRs may be pretty uninformative (e.g.=20 sip:user31@freesipservice.example.com), all of which complicate = authorization=20 decisions. Solving this problem is on the same footing as solving = the=20 request-history problem set.
 
With=20 that background, the problems with providing this connected party = information in=20 responses (via the To header or what have you) are roughly as=20 follows:
 
a) The=20 "unanticipated respondent" problem is especially an issue for response = identity=20 because not all responses are success responses. If you end up = connecting to a=20 party (receiving a 200), you can potentially rely on human factors to = help you=20 identify who you are talking to (after all, Carol can always answer = Bob's phone=20 regardless of who SIP thinks you connected to) and/or use the connected = party=20 information to change how you might address the party on the other side. = With a=20 403 response, you are in a very different predicament - how is UAC = or user=20 behavior supposed to change based on the connected URI attributed = to a=20 403, given the unanticipated respondent problem? For provisional = responses,=20 the issues become even worse - we then get into the = wonders of=20 forking, multiple provisional responses from multiple sources asserting=20 different To header fields - in short, nothing which makes it any = easier to=20 render a "responding" AoR to a user, for example. Response = identity, in so=20 far as it deals with non-final, non-successful responses, opens up = the=20 "unconnected party" problem set. I think this is just the wrong framing = of the=20 problem. You want to know who you connected to, not who you didn't = connect=20 to.
 
b) Getting a signature over the To header field in=20 responses would be difficult. In full awareness of Mr. = Elwell's=20 note below that certain parties are interested in "(unauthenticated) identity in a = response", if this=20 information is going to be put to any purpose, cause any change in human = or UAC=20 behavior, I have a hard time seeing how anyone could defend it being = unsecured.=20 If you want a human or an automata to make a policy decision based on = the AoR in=20 the To header field of the response, some sort of response identity = signature=20 would be necessary to prevent obvious impersonation attacks designed to = thwart=20 authorization decisions. With all due respect to the authors of=20 draft-cao-sip-response-identity/auth, I'm not sure this problem is = readily=20 solved. Making sure that an appropriate authentication service is in the = path of=20 responses is problematic, since responses must traverse exactly the same = path as=20 requests. I played around with this a lot in the early phases of SIP = identity,=20 and at the end of the day, I had to conclude that the only way to make = this work=20 was to eliminate retargeting. Since providing connected-identity in = responses=20 assumes that retargeting has taken place, it wouldn't exactly be getting = off on=20 the right foot. Constraining inbound request routing to a domain such = that=20 responses will traverse an authentication service, or forcing a UAS to=20 participate in the Identity scheme, is likely to require=20 mandatory option-tags or comparable mechanisms that will limit the=20 applicability of response identity and more or less eliminate its = opportunistic=20 use.
 
c) The inability to reject a response. Take the easiest = case - let's=20 say that the UAC receives a final success response, say a 200 response, = with a=20 modified To header field from a party that is blacklisted by UAC policy. = What=20 exactly is the UAC supposed to do? Send a 403? One cannot reject = responses.=20 Maybe a CANCEL? As section 9.1 of RFC3261 says, CANCEL "has no effect on = requests that have already generated a final response." Drop the request = on the=20 floor? You'll just receive retransmissions. All you can do is ACK it, = since the=20 dialog has already been formed, and then send a BYE. In other words, a = session=20 -will- be established, there simply isn't an opportunity for policy to = be put=20 into effect prior to session establishment. Also, consider the need for = the new=20 responses defined in the sip-identity draft, like say the 438 response - = if the=20 UAC receives a 200 response with a potentially repairable error in = the=20 Identity header, how can it express that error to the UAS, since it=20 can't send responses to a response?
 
Given=20 the above, why does the UAC need to know who has been reached in the = response,=20 rather than in a request after the dialog has been formed? As (c)=20 illustrates, in the 200 response case a session will be established = anyway, so=20 sharing the identity of the connected party after session establishment = doesn't=20 actually miss some opportunity for applying policy - moreover, an UPDATE = or=20 similar request that provides the connected-identity information could = be=20 rejected by the session-originating UA in a manner that is helpful to = the=20 session-terminating UA (e.g., a 438 response could be sent). If we = go with=20 the mechanism in the connected-identity draft, problem (b) disappears, = since=20 request routing is far more malleable than response routing. = Additionally, the=20 connected-identity draft wisely does not attempt to solve "unconnected = party"=20 problems from (a), which are the least tractable of the unanticipated = respondent=20 problems. Rather, connected-identity provides an indication more along = the lines=20 of, "your dialog was established, however that might have happened, and = this is=20 who is on the other side".
 
Furthermore, any solution that tried to put the = connected-identity=20 information into responses would be providing an imprimatur of = legitimacy to=20 those responses - presuming they had a signature, UACs would validate = it, and=20 provided it checked out, they would be tempted say "this is a = legitimate=20 response." Nothing could be further from the truth, as sipping-retarget=20 illustrates. Legitimacy of responses cannot be determined by UACs in the = absence=20 of something like request-history.
 
Finally, I like having one Identity header, and for the meaning = of that=20 Identity header to *always* be that it is a signature over the From = header field=20 issued by the domain identified by the host portion of the addr-spec of = the From=20 header field. The current connected-identity header draft provides that=20 property.
 
Jon=20 Peterson
NeuStar, Inc.
-----Original Message-----
From: Elwell, John=20 [mailto:john.elwell@siemens.com]
Sent: Monday, April 03, = 2006 11:46=20 PM
To: sip@ietf.org
Subject: [Sip] = Connected-identity and=20 changing the To header field in aresponse

During discussion of=20 draft-elwell-connected-identity in Dallas, somebody put forward the = opinion=20 that it would be dangerous to change the To header field URI in a = response=20 (i.e., make it different from the From header field URI in the = request). My=20 assumption at the time was that it would undermine the transaction = concept in=20 SIP, yet reading what RFC3261 has to say about transactions, the value = of the=20 To header field URI in a response does not appear to be involved in = coupling a=20 response to a request. Therefore I assume the person who indicated the = danger=20 (which was not challenged at the meeting) has other reasons in mind. I = would=20 greatly appreciate opinions on the wisdom or otherwise of allowing the = To=20 header field URI to change. It seems that from discussion of=20 connected-identity there is a desire from some parts of the community = to=20 include an (unauthenticated) identity in a response.

John =

------_=_NextPart_001_01C6584D.02054A07-- --===============1997377659== 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 --===============1997377659==-- From sip-bounces@ietf.org Wed Apr 05 03:07:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR25A-0004EJ-FI; Wed, 05 Apr 2006 03:05:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR24N-0003pA-3P for sip@ietf.org; Wed, 05 Apr 2006 03:04:47 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR212-0007l4-P1 for sip@ietf.org; Wed, 05 Apr 2006 03:01:22 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IX800D01M733W@siemenscomms.co.uk> for sip@ietf.org; Wed, 05 Apr 2006 08:01:51 +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 <0IX800B4UM73IT@siemenscomms.co.uk>; Wed, 05 Apr 2006 08:01:51 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 05 Apr 2006 08:01:19 +0100 Content-return: allowed Date: Wed, 05 Apr 2006 08:01:09 +0100 From: "Elwell, John" Subject: RE: [Sip] Connected-identity and changing the To header field in aresponse To: "Peterson, Jon" , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F266708969ACD@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 1.0 (+) X-Scan-Signature: 75ac86d24bd0a3cd8a26e327ae61143e 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="===============1120875081==" 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. --===============1120875081== Content-return: allowed Content-type: multipart/alternative; boundary="Boundary_(ID_RG/ofSksR7CK5ymUZU85fw)" 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_RG/ofSksR7CK5ymUZU85fw) Content-type: text/plain Content-transfer-encoding: 7BIT Jon, Thanks for this excellent summary of the issue, which I fully agree with and which unfortunately seems to need restating at regular intervals. It appears that the chief motivation of those asking for something in the response is to facilitate interworking with PSTN (by including it in the 200 response so that it can be mapped directly to the PSTN "connected" message). As you say, such a response is always going to be unauthenticated, and I don't think that meets the requirements of PSTN interworking. Far better to figure out a way of using an authenticated connected identity in an UPDATE message for mapping to PSTN connected identity. Of course, in trusted networks there may be other means for ensuring the authenticity of an identity in a response, just as there is in a request using P-Asserted-Identity. Unfortunately RFC3325 is unclear on the use of PAI in responses, although in practice I think it is used and is probably OK if the last hop is secured by TLS so that previous authentication of the UAS can be relied on for making the assertion. I think if those trusted networks really need a solution for response identity, PAI would be a better avenue to explore (taking into account the risks). But not for the Internet. I am becoming more and more convinced that diluting the connected-identity draft with a weak solution for response identity would be the wrong way to go. John _____ From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: 05 April 2006 02:05 To: Elwell, John; sip@ietf.org Subject: RE: [Sip] Connected-identity and changing the To header field in aresponse Yes, I was asked for clarification on this point after the meeting, and I'll be providing it here. As you surmised, it is not that RFC3261 relies on the addr-spec of the To or From header field for transaction identification, or something. In fact, I would have essentially the same concerns about any proposal that provided an additional header (say, a 'Connected-Party' header) in responses to dialog-forming requests which was understood to clobber the To header field and identify the AoR of the party who was reached after retargeting of the request took place. Starting with the goals of this approach: what sort of UAC decisions or behavior do we hope to enable through sending a response with a modified To header field? As far as I can understand, we either want to render this AoR to the user of a UAC (so the user can react in one way or another), or input the AoR to some sort of policy manager (e.g. blacklist/whitelist) that might make a decision about whether or not the session should continue -prior- to session establishment. If we don't care about this occurring prior to session establishment, of course, then we could go with the connected-identity draft as it is written today. A little refresher on my sipping-retarget draft: The core problem with any scheme for connected party is figuring out how you'd decide whether or not a particular respondent is authorized. This is the argument of 2.2.1 of sipping-retarget, the "unanticipated respondent" problem. When we think about what sorts of policy decisions we expect a human or automata to make when receiving a response with identity information, we have to acknowledge that the UAC has no way of knowing which respondents are or are not authorized to respond to the request in question. Since the UAC has no insight into any retargeting that has taken place, the UAC has to assume that virtually any response is a potentially legitimate one. As such, there is little room for any meaningful policy decision when receiving a response. This problem is further compounded by the fact that the UAS may have several possible legitimate AoRs it could claim (I have a UA that registers its contact address under 3 separate SIP services simultaneously), and of course the fact that AoRs may be pretty uninformative (e.g. sip:user31@freesipservice.example.com), all of which complicate authorization decisions. Solving this problem is on the same footing as solving the request-history problem set. With that background, the problems with providing this connected party information in responses (via the To header or what have you) are roughly as follows: a) The "unanticipated respondent" problem is especially an issue for response identity because not all responses are success responses. If you end up connecting to a party (receiving a 200), you can potentially rely on human factors to help you identify who you are talking to (after all, Carol can always answer Bob's phone regardless of who SIP thinks you connected to) and/or use the connected party information to change how you might address the party on the other side. With a 403 response, you are in a very different predicament - how is UAC or user behavior supposed to change based on the connected URI attributed to a 403, given the unanticipated respondent problem? For provisional responses, the issues become even worse - we then get into the wonders of forking, multiple provisional responses from multiple sources asserting different To header fields - in short, nothing which makes it any easier to render a "responding" AoR to a user, for example. Response identity, in so far as it deals with non-final, non-successful responses, opens up the "unconnected party" problem set. I think this is just the wrong framing of the problem. You want to know who you connected to, not who you didn't connect to. b) Getting a signature over the To header field in responses would be difficult. In full awareness of Mr. Elwell's note below that certain parties are interested in "(unauthenticated) identity in a response", if this information is going to be put to any purpose, cause any change in human or UAC behavior, I have a hard time seeing how anyone could defend it being unsecured. If you want a human or an automata to make a policy decision based on the AoR in the To header field of the response, some sort of response identity signature would be necessary to prevent obvious impersonation attacks designed to thwart authorization decisions. With all due respect to the authors of draft-cao-sip-response-identity/auth, I'm not sure this problem is readily solved. Making sure that an appropriate authentication service is in the path of responses is problematic, since responses must traverse exactly the same path as requests. I played around with this a lot in the early phases of SIP identity, and at the end of the day, I had to conclude that the only way to make this work was to eliminate retargeting. Since providing connected-identity in responses assumes that retargeting has taken place, it wouldn't exactly be getting off on the right foot. Constraining inbound request routing to a domain such that responses will traverse an authentication service, or forcing a UAS to participate in the Identity scheme, is likely to require mandatory option-tags or comparable mechanisms that will limit the applicability of response identity and more or less eliminate its opportunistic use. c) The inability to reject a response. Take the easiest case - let's say that the UAC receives a final success response, say a 200 response, with a modified To header field from a party that is blacklisted by UAC policy. What exactly is the UAC supposed to do? Send a 403? One cannot reject responses. Maybe a CANCEL? As section 9.1 of RFC3261 says, CANCEL "has no effect on requests that have already generated a final response." Drop the request on the floor? You'll just receive retransmissions. All you can do is ACK it, since the dialog has already been formed, and then send a BYE. In other words, a session -will- be established, there simply isn't an opportunity for policy to be put into effect prior to session establishment. Also, consider the need for the new responses defined in the sip-identity draft, like say the 438 response - if the UAC receives a 200 response with a potentially repairable error in the Identity header, how can it express that error to the UAS, since it can't send responses to a response? Given the above, why does the UAC need to know who has been reached in the response, rather than in a request after the dialog has been formed? As (c) illustrates, in the 200 response case a session will be established anyway, so sharing the identity of the connected party after session establishment doesn't actually miss some opportunity for applying policy - moreover, an UPDATE or similar request that provides the connected-identity information could be rejected by the session-originating UA in a manner that is helpful to the session-terminating UA (e.g., a 438 response could be sent). If we go with the mechanism in the connected-identity draft, problem (b) disappears, since request routing is far more malleable than response routing. Additionally, the connected-identity draft wisely does not attempt to solve "unconnected party" problems from (a), which are the least tractable of the unanticipated respondent problems. Rather, connected-identity provides an indication more along the lines of, "your dialog was established, however that might have happened, and this is who is on the other side". Furthermore, any solution that tried to put the connected-identity information into responses would be providing an imprimatur of legitimacy to those responses - presuming they had a signature, UACs would validate it, and provided it checked out, they would be tempted say "this is a legitimate response." Nothing could be further from the truth, as sipping-retarget illustrates. Legitimacy of responses cannot be determined by UACs in the absence of something like request-history. Finally, I like having one Identity header, and for the meaning of that Identity header to *always* be that it is a signature over the From header field issued by the domain identified by the host portion of the addr-spec of the From header field. The current connected-identity header draft provides that property. Jon Peterson NeuStar, Inc. -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens.com] Sent: Monday, April 03, 2006 11:46 PM To: sip@ietf.org Subject: [Sip] Connected-identity and changing the To header field in aresponse During discussion of draft-elwell-connected-identity in Dallas, somebody put forward the opinion that it would be dangerous to change the To header field URI in a response (i.e., make it different from the From header field URI in the request). My assumption at the time was that it would undermine the transaction concept in SIP, yet reading what RFC3261 has to say about transactions, the value of the To header field URI in a response does not appear to be involved in coupling a response to a request. Therefore I assume the person who indicated the danger (which was not challenged at the meeting) has other reasons in mind. I would greatly appreciate opinions on the wisdom or otherwise of allowing the To header field URI to change. It seems that from discussion of connected-identity there is a desire from some parts of the community to include an (unauthenticated) identity in a response. John --Boundary_(ID_RG/ofSksR7CK5ymUZU85fw) Content-type: text/html Content-transfer-encoding: 7BIT Connected-identity and changing the To header field in a response
Jon,
 
Thanks for this excellent summary of the issue, which I fully agree with and which unfortunately seems to need restating at regular intervals. It appears that the chief motivation of those asking for something in the response is to facilitate interworking with PSTN (by including it in the 200 response so that it can be mapped directly to the PSTN "connected" message). As you say, such a response is always going to be unauthenticated, and I don't think that meets the requirements of PSTN interworking. Far better to figure out a way of using an authenticated connected identity in an UPDATE message for mapping to PSTN connected identity.
 
Of course, in trusted networks there may be other means for ensuring the authenticity of an identity in a response, just as there is in a request using P-Asserted-Identity. Unfortunately RFC3325 is unclear on the use of PAI in responses, although in practice I think it is used and is probably OK if the last hop is secured by TLS so that previous authentication of the UAS can be relied on for making the assertion. I think if those trusted networks really need a solution for response identity, PAI would be a better avenue to explore (taking into account the risks). But not for the Internet. I am becoming more and more convinced that diluting the connected-identity draft with a weak solution for response identity would be the wrong way to go.
 
John

From: Peterson, Jon [mailto:jon.peterson@neustar.biz]
Sent: 05 April 2006 02:05
To: Elwell, John; sip@ietf.org
Subject: RE: [Sip] Connected-identity and changing the To header field in aresponse

Yes, I was asked for clarification on this point after the meeting, and I'll be providing it here. As you surmised, it is not that RFC3261 relies on the addr-spec of the To or From header field for transaction identification, or something. In fact, I would have essentially the same concerns about any proposal that provided an additional header (say, a 'Connected-Party' header) in responses to dialog-forming requests which was understood to clobber the To header field and identify the AoR of the party who was reached after retargeting of the request took place.
 
Starting with the goals of this approach: what sort of UAC decisions or behavior do we hope to enable through sending a response with a modified To header field? As far as I can understand, we either want to render this AoR to the user of a UAC (so the user can react in one way or another), or input the AoR to some sort of policy manager (e.g. blacklist/whitelist) that might make a decision about whether or not the session should continue -prior- to session establishment. If we don't care about this occurring prior to session establishment, of course, then we could go with the connected-identity draft as it is written today.
 
A little refresher on my sipping-retarget draft: The core problem with any scheme for connected party is figuring out how you'd decide whether or not a particular respondent is authorized. This is the argument of 2.2.1 of sipping-retarget, the "unanticipated respondent" problem. When we think about what sorts of policy decisions we expect a human or automata to make when receiving a response with identity information, we have to acknowledge that the UAC has no way of knowing which respondents are or are not authorized to respond to the request in question. Since the UAC has no insight into any retargeting that has taken place, the UAC has to assume that virtually any response is a potentially legitimate one. As such, there is little room for any meaningful policy decision when receiving a response. This problem is further compounded by the fact that the UAS may have several possible legitimate AoRs it could claim (I have a UA that registers its contact address under 3 separate SIP services simultaneously), and of course the fact that AoRs may be pretty uninformative (e.g. sip:user31@freesipservice.example.com), all of which complicate authorization decisions. Solving this problem is on the same footing as solving the request-history problem set.
 
With that background, the problems with providing this connected party information in responses (via the To header or what have you) are roughly as follows:
 
a) The "unanticipated respondent" problem is especially an issue for response identity because not all responses are success responses. If you end up connecting to a party (receiving a 200), you can potentially rely on human factors to help you identify who you are talking to (after all, Carol can always answer Bob's phone regardless of who SIP thinks you connected to) and/or use the connected party information to change how you might address the party on the other side. With a 403 response, you are in a very different predicament - how is UAC or user behavior supposed to change based on the connected URI attributed to a 403, given the unanticipated respondent problem? For provisional responses, the issues become even worse - we then get into the wonders of forking, multiple provisional responses from multiple sources asserting different To header fields - in short, nothing which makes it any easier to render a "responding" AoR to a user, for example. Response identity, in so far as it deals with non-final, non-successful responses, opens up the "unconnected party" problem set. I think this is just the wrong framing of the problem. You want to know who you connected to, not who you didn't connect to.
 
b) Getting a signature over the To header field in responses would be difficult. In full awareness of Mr. Elwell's note below that certain parties are interested in "(unauthenticated) identity in a response", if this information is going to be put to any purpose, cause any change in human or UAC behavior, I have a hard time seeing how anyone could defend it being unsecured. If you want a human or an automata to make a policy decision based on the AoR in the To header field of the response, some sort of response identity signature would be necessary to prevent obvious impersonation attacks designed to thwart authorization decisions. With all due respect to the authors of draft-cao-sip-response-identity/auth, I'm not sure this problem is readily solved. Making sure that an appropriate authentication service is in the path of responses is problematic, since responses must traverse exactly the same path as requests. I played around with this a lot in the early phases of SIP identity, and at the end of the day, I had to conclude that the only way to make this work was to eliminate retargeting. Since providing connected-identity in responses assumes that retargeting has taken place, it wouldn't exactly be getting off on the right foot. Constraining inbound request routing to a domain such that responses will traverse an authentication service, or forcing a UAS to participate in the Identity scheme, is likely to require mandatory option-tags or comparable mechanisms that will limit the applicability of response identity and more or less eliminate its opportunistic use.
 
c) The inability to reject a response. Take the easiest case - let's say that the UAC receives a final success response, say a 200 response, with a modified To header field from a party that is blacklisted by UAC policy. What exactly is the UAC supposed to do? Send a 403? One cannot reject responses. Maybe a CANCEL? As section 9.1 of RFC3261 says, CANCEL "has no effect on requests that have already generated a final response." Drop the request on the floor? You'll just receive retransmissions. All you can do is ACK it, since the dialog has already been formed, and then send a BYE. In other words, a session -will- be established, there simply isn't an opportunity for policy to be put into effect prior to session establishment. Also, consider the need for the new responses defined in the sip-identity draft, like say the 438 response - if the UAC receives a 200 response with a potentially repairable error in the Identity header, how can it express that error to the UAS, since it can't send responses to a response?
 
Given the above, why does the UAC need to know who has been reached in the response, rather than in a request after the dialog has been formed? As (c) illustrates, in the 200 response case a session will be established anyway, so sharing the identity of the connected party after session establishment doesn't actually miss some opportunity for applying policy - moreover, an UPDATE or similar request that provides the connected-identity information could be rejected by the session-originating UA in a manner that is helpful to the session-terminating UA (e.g., a 438 response could be sent). If we go with the mechanism in the connected-identity draft, problem (b) disappears, since request routing is far more malleable than response routing. Additionally, the connected-identity draft wisely does not attempt to solve "unconnected party" problems from (a), which are the least tractable of the unanticipated respondent problems. Rather, connected-identity provides an indication more along the lines of, "your dialog was established, however that might have happened, and this is who is on the other side".
 
Furthermore, any solution that tried to put the connected-identity information into responses would be providing an imprimatur of legitimacy to those responses - presuming they had a signature, UACs would validate it, and provided it checked out, they would be tempted say "this is a legitimate response." Nothing could be further from the truth, as sipping-retarget illustrates. Legitimacy of responses cannot be determined by UACs in the absence of something like request-history.
 
Finally, I like having one Identity header, and for the meaning of that Identity header to *always* be that it is a signature over the From header field issued by the domain identified by the host portion of the addr-spec of the From header field. The current connected-identity header draft provides that property.
 
Jon Peterson
NeuStar, Inc.
-----Original Message-----
From: Elwell, John [mailto:john.elwell@siemens.com]
Sent: Monday, April 03, 2006 11:46 PM
To: sip@ietf.org
Subject: [Sip] Connected-identity and changing the To header field in aresponse

During discussion of draft-elwell-connected-identity in Dallas, somebody put forward the opinion that it would be dangerous to change the To header field URI in a response (i.e., make it different from the From header field URI in the request). My assumption at the time was that it would undermine the transaction concept in SIP, yet reading what RFC3261 has to say about transactions, the value of the To header field URI in a response does not appear to be involved in coupling a response to a request. Therefore I assume the person who indicated the danger (which was not challenged at the meeting) has other reasons in mind. I would greatly appreciate opinions on the wisdom or otherwise of allowing the To header field URI to change. It seems that from discussion of connected-identity there is a desire from some parts of the community to include an (unauthenticated) identity in a response.

John

--Boundary_(ID_RG/ofSksR7CK5ymUZU85fw)-- --===============1120875081== 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 --===============1120875081==-- From sip-bounces@ietf.org Wed Apr 05 04:04:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR2yD-0000Y1-VG; Wed, 05 Apr 2006 04:02:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR2yB-0000XW-4v for sip@ietf.org; Wed, 05 Apr 2006 04:02:27 -0400 Received: from fmmailgate05.web.de ([217.72.192.243]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR2y9-0001dm-1P for sip@ietf.org; Wed, 05 Apr 2006 04:02:27 -0400 Received: by fmmailgate05.web.de (8.12.10/8.12.10/webde Linux 0.7) with SMTP id k35817iK009322; Wed, 5 Apr 2006 10:02:23 +0200 Received: from [217.167.116.182] by freemailng0802.web.de with HTTP; Wed, 05 Apr 2006 10:02:13 +0200 Date: Wed, 05 Apr 2006 10:02:13 +0200 Message-Id: <600146328@web.de> MIME-Version: 1.0 From: Roland Jesske To: "Elwell, John" , "Peterson, Jon" , sip@ietf.org Subject: =?iso-8859-15?Q?RE:_[Sip]_Connected-identity_and_changing_the_To_heade?= =?iso-8859-15?Q?r_field_in_aresponse?= Precedence: fm-user Organization: http://freemail.web.de/ Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.5 (/) X-Scan-Signature: be922d419820e291bde1362184dc32fd Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org John, You wrote:=20 >Unfortunately RFC3325 is unclear on the use of PAI in responses, although= in practice I think it is used and is probably OK if >the last hop is sec= ured by TLS so that previous authentication of the UAS can be relied on fo= r making the assertion. You aready quoted in a Mail 2. January 2006 the use of PAI in responses as= written within RFC3324. Again RFC 3324 says: 5. Parties with Network Asserted Identities A Network Asserted Identity identifies the originator of the message in which it was received. For example, a Network Asserted Identity received in an initial INVITE (outside the context of any existing dialog) identifies the calling party. a Network Asserted Identity received in a 180 Ringing response to such an INVITE identifies the party who is ringing. a Network Asserted Identity received in a 200 response to such an INVITE identifies the party who has answered. Also in RFC 3325 the use is allowed as follows: This document adds the following entry to Table 2 of [1]: Header field where proxy ACK BYE CAN INV OPT REG ------------ ----- ----- --- --- --- --- --- --- P-Asserted-Identity adr - o - o o - A=3D SUB NOT REF INF UPD PRA --- --- --- --- --- --- o o o - - - Is this all wrong now=3F Is it forbidden to use a P-Asserted-Identity in Res= ponses. The 3GPP and TISPAN IMS are using the P-Asserted-Identity in Responses and= it is not forced to use TLS.=20 Is this all now wrong=3F Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: "Elwell, John" > Gesendet: 05.04.06 09:07:07 > An: sip@ietf.org > Betreff: RE: [Sip] Connected-identity and changing the To header field i= n aresponse > Jon, >=20 > =20 >=20 > Thanks for this excellent summary of the issue, which I fully agree with= and which unfortunately seems to need restating at regular intervals. It = appears that the chief motivation of those asking for something in the res= ponse is to facilitate interworking with PSTN (by including it in the 200 = response so that it can be mapped directly to the PSTN "connected" message= ). As you say, such a response is always going to be unauthenticated, and = I don't think that meets the requirements of PSTN interworking. Far better= to figure out a way of using an authenticated connected identity in an UP= DATE message for mapping to PSTN connected identity. >=20 > =20 >=20 > Of course, in trusted networks there may be other means for ensuring the= authenticity of an identity in a response, just as there is in a request = using P-Asserted-Identity. Unfortunately RFC3325 is unclear on the use of = PAI in responses, although in practice I think it is used and is probably = OK if the last hop is secured by TLS so that previous authentication of th= e UAS can be relied on for making the assertion. I think if those trusted = networks really need a solution for response identity, PAI would be a bett= er avenue to explore (taking into account the risks). But not for the Inte= rnet. I am becoming more and more convinced that diluting the connected-id= entity draft with a weak solution for response identity would be the wrong= way to go. >=20 > =20 >=20 > John > =20 > =20 > ----------------------------------------------------------------- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz]=20 > Sent: 05 April 2006 02:05 > To: Elwell, John; sip@ietf.org > Subject: RE: [Sip] Connected-identity and changing the To header field i= n aresponse >=20 > =20 > =20 > Yes, I was asked for clarification on this point after the meeting, and = I'll be providing it here. As you surmised, it is not that RFC3261 relies = on the addr-spec of the To or From header field for transaction identifica= tion, or something. In fact, I would have essentially the same concerns ab= out any proposal that provided an additional header (say, a 'Connected-Par= ty' header) in responses to dialog-forming requests which was understood t= o clobber the To header field and identify the AoR of the party who was re= ached after retargeting of the request took place. > =20 > =20 > =20 > Starting with the goals of this approach: what sort of UAC decisions or = behavior do we hope to enable through sending a response with a modified T= o header field=3F As far as I can understand, we either want to render this = AoR to the user of a UAC (so the user can react in one way or another), or= input the AoR to some sort of policy manager (e.g. blacklist/whitelist) t= hat might make a decision about whether or not the session should continue= -prior- to session establishment. If we don't care about this occurring p= rior to session establishment, of course, then we could go with the connec= ted-identity draft as it is written today. > =20 > =20 > =20 > A little refresher on my sipping-retarget draft: The core problem with a= ny scheme for connected party is figuring out how you'd decide whether or = not a particular respondent is authorized. This is the argument of 2.2.1 o= f sipping-retarget, the "unanticipated respondent" problem. When we think = about what sorts of policy decisions we expect a human or automata to make= when receiving a response with identity information, we have to acknowled= ge that the UAC has no way of knowing which respondents are or are not aut= horized to respond to the request in question. Since the UAC has no insigh= t into any retargeting that has taken place, the UAC has to assume that vi= rtually any response is a potentially legitimate one. As such, there is li= ttle room for any meaningful policy decision when receiving a response. Th= is problem is further compounded by the fact that the UAS may have several= possible legitimate AoRs it could claim (I have a UA that registers its c= ontact address under 3 separate SIP services simultaneously), and of cours= e the fact that AoRs may be pretty uninformative (e.g. sip:user31@freesips= ervice.example.com), all of which complicate authorization decisions. Solv= ing this problem is on the same footing as solving the request-history pro= blem set. > =20 > =20 > =20 > With that background, the problems with providing this connected party i= nformation in responses (via the To header or what have you) are roughly a= s follows: > =20 > =20 > =20 > a) The "unanticipated respondent" problem is especially an issue for res= ponse identity because not all responses are success responses. If you end= up connecting to a party (receiving a 200), you can potentially rely on h= uman factors to help you identify who you are talking to (after all, Carol= can always answer Bob's phone regardless of who SIP thinks you connected = to) and/or use the connected party information to change how you might add= ress the party on the other side. With a 403 response, you are in a very d= ifferent predicament - how is UAC or user behavior supposed to change base= d on the connected URI attributed to a 403, given the unanticipated respon= dent problem=3F For provisional responses, the issues become even worse - we= then get into the wonders of forking, multiple provisional responses from= multiple sources asserting different To header fields - in short, nothing= which makes it any easier to render a "responding" AoR to a user, for exa= mple. Response identity, in so far as it deals with non-final, non-success= ful responses, opens up the "unconnected party" problem set. I think this = is just the wrong framing of the problem. You want to know who you connect= ed to, not who you didn't connect to. > =20 > =20 > =20 > b) Getting a signature over the To header field in responses would be di= fficult. In full awareness of Mr. Elwell's note below that certain parties= are interested in "(unauthenticated) identity in a response", if this inf= ormation is going to be put to any purpose, cause any change in human or U= AC behavior, I have a hard time seeing how anyone could defend it being un= secured. If you want a human or an automata to make a policy decision base= d on the AoR in the To header field of the response, some sort of response= identity signature would be necessary to prevent obvious impersonation at= tacks designed to thwart authorization decisions. With all due respect to = the authors of draft-cao-sip-response-identity/auth, I'm not sure this pro= blem is readily solved. Making sure that an appropriate authentication ser= vice is in the path of responses is problematic, since responses must trav= erse exactly the same path as requests. I played around with this a lot in= the early phases of SIP identity, and at the end of the day, I had to con= clude that the only way to make this work was to eliminate retargeting. Si= nce providing connected-identity in responses assumes that retargeting has= taken place, it wouldn't exactly be getting off on the right foot. Constr= aining inbound request routing to a domain such that responses will traver= se an authentication service, or forcing a UAS to participate in the Ident= ity scheme, is likely to require mandatory option-tags or comparable mecha= nisms that will limit the applicability of response identity and more or l= ess eliminate its opportunistic use. > =20 > =20 > =20 > c) The inability to reject a response. Take the easiest case - let's say= that the UAC receives a final success response, say a 200 response, with = a modified To header field from a party that is blacklisted by UAC policy.= What exactly is the UAC supposed to do=3F Send a 403=3F One cannot reject res= ponses. Maybe a CANCEL=3F As section 9.1 of RFC3261 says, CANCEL "has no eff= ect on requests that have already generated a final response." Drop the re= quest on the floor=3F You'll just receive retransmissions. All you can do is= ACK it, since the dialog has already been formed, and then send a BYE. In= other words, a session -will- be established, there simply isn't an oppor= tunity for policy to be put into effect prior to session establishment. Al= so, consider the need for the new responses defined in the sip-identity dr= aft, like say the 438 response - if the UAC receives a 200 response with a= potentially repairable error in the Identity header, how can it express t= hat error to the UAS, since it can't send responses to a response=3F > =20 > =20 > =20 > Given the above, why does the UAC need to know who has been reached in t= he response, rather than in a request after the dialog has been formed=3F As= (c) illustrates, in the 200 response case a session will be established a= nyway, so sharing the identity of the connected party after session establ= ishment doesn't actually miss some opportunity for applying policy - moreo= ver, an UPDATE or similar request that provides the connected-identity inf= ormation could be rejected by the session-originating UA in a manner that = is helpful to the session-terminating UA (e.g., a 438 response could be se= nt). If we go with the mechanism in the connected-identity draft, problem = (b) disappears, since request routing is far more malleable than response = routing. Additionally, the connected-identity draft wisely does not attemp= t to solve "unconnected party" problems from (a), which are the least trac= table of the unanticipated respondent problems. Rather, connected-identity= provides an indication more along the lines of, "your dialog was establis= hed, however that might have happened, and this is who is on the other sid= e". > =20 > =20 > =20 > Furthermore, any solution that tried to put the connected-identity infor= mation into responses would be providing an imprimatur of legitimacy to th= ose responses - presuming they had a signature, UACs would validate it, an= d provided it checked out, they would be tempted say "this is a legitimate= response." Nothing could be further from the truth, as sipping-retarget i= llustrates. Legitimacy of responses cannot be determined by UACs in the ab= sence of something like request-history. > =20 > =20 > =20 > Finally, I like having one Identity header, and for the meaning of that = Identity header to *always* be that it is a signature over the From header= field issued by the domain identified by the host portion of the addr-spe= c of the From header field. The current connected-identity header draft pr= ovides that property. > =20 > =20 > =20 > Jon Peterson > =20 > NeuStar, Inc. > =20 > =20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Monday, April 03, 2006 11:46 PM > To: sip@ietf.org > Subject: [Sip] Connected-identity and changing the To header field in ar= esponse >=20 > =20 >=20 > During discussion of draft-elwell-connected-identity in Dallas, somebody= put forward the opinion that it would be dangerous to change the To heade= r field URI in a response (i.e., make it different from the From header fi= eld URI in the request). My assumption at the time was that it would under= mine the transaction concept in SIP, yet reading what RFC3261 has to say a= bout transactions, the value of the To header field URI in a response does= not appear to be involved in coupling a response to a request. Therefore = I assume the person who indicated the danger (which was not challenged at = the meeting) has other reasons in mind. I would greatly appreciate opinion= s on the wisdom or otherwise of allowing the To header field URI to change= . It seems that from discussion of connected-identity there is a desire fr= om some parts of the community to include an (unauthenticated) identity in= a response. > =20 >=20 > John=20 >=20 > ----------------------------------------------------------------- > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip =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=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/=3Fmc=3D021192 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 05 04:25:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR3IP-0002nt-UP; Wed, 05 Apr 2006 04:23:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR3IO-0002no-Rz for sip@ietf.org; Wed, 05 Apr 2006 04:23:20 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR3IN-0002YR-LJ for sip@ietf.org; Wed, 05 Apr 2006 04:23:20 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6E28D4F0002; Wed, 5 Apr 2006 09:34:01 +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, 5 Apr 2006 09:34:01 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 09:34:01 +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] Connected-identity and changing the To header field inaresponse Date: Wed, 5 Apr 2006 09:34:00 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1CA0@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Connected-identity and changing the To header field inaresponse Thread-Index: AcZYf4XMmMy8DdNZSsuggMi05qc+0QAAVL+g From: "Christer Holmberg \(JO/LMF\)" To: "Elwell, John" , "Peterson, Jon" , X-OriginalArrivalTime: 05 Apr 2006 07:34:01.0122 (UTC) FILETIME=[4EB71820:01C65883] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.5 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae 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, In PSTN terms we are talking about that the TO header shall be mapped to the additional connected number, and that does NOT need to be authorized in the same way as the connected number. And, whether the interworking node sends this value to PSTN is of course based on local policy, based on trust etc. Regards, Christer ________________________________ From: Elwell, John [mailto:john.elwell@siemens.com]=20 Sent: 5. huhtikuuta 2006 10:01 To: Peterson, Jon; sip@ietf.org Subject: RE: [Sip] Connected-identity and changing the To header field inaresponse Jon, =20 Thanks for this excellent summary of the issue, which I fully agree with and which unfortunately seems to need restating at regular intervals. It appears that the chief motivation of those asking for something in the response is to facilitate interworking with PSTN (by including it in the 200 response so that it can be mapped directly to the PSTN "connected" message). As you say, such a response is always going to be unauthenticated, and I don't think that meets the requirements of PSTN interworking. Far better to figure out a way of using an authenticated connected identity in an UPDATE message for mapping to PSTN connected identity. =20 Of course, in trusted networks there may be other means for ensuring the authenticity of an identity in a response, just as there is in a request using P-Asserted-Identity. Unfortunately RFC3325 is unclear on the use of PAI in responses, although in practice I think it is used and is probably OK if the last hop is secured by TLS so that previous authentication of the UAS can be relied on for making the assertion. I think if those trusted networks really need a solution for response identity, PAI would be a better avenue to explore (taking into account the risks). But not for the Internet. I am becoming more and more convinced that diluting the connected-identity draft with a weak solution for response identity would be the wrong way to go. =20 John ________________________________ From: Peterson, Jon [mailto:jon.peterson@neustar.biz]=20 Sent: 05 April 2006 02:05 To: Elwell, John; sip@ietf.org Subject: RE: [Sip] Connected-identity and changing the To header field in aresponse =09 =09 Yes, I was asked for clarification on this point after the meeting, and I'll be providing it here. As you surmised, it is not that RFC3261 relies on the addr-spec of the To or From header field for transaction identification, or something. In fact, I would have essentially the same concerns about any proposal that provided an additional header (say, a 'Connected-Party' header) in responses to dialog-forming requests which was understood to clobber the To header field and identify the AoR of the party who was reached after retargeting of the request took place. =20 Starting with the goals of this approach: what sort of UAC decisions or behavior do we hope to enable through sending a response with a modified To header field? As far as I can understand, we either want to render this AoR to the user of a UAC (so the user can react in one way or another), or input the AoR to some sort of policy manager (e.g. blacklist/whitelist) that might make a decision about whether or not the session should continue -prior- to session establishment. If we don't care about this occurring prior to session establishment, of course, then we could go with the connected-identity draft as it is written today. =20 A little refresher on my sipping-retarget draft: The core problem with any scheme for connected party is figuring out how you'd decide whether or not a particular respondent is authorized. This is the argument of 2.2.1 of sipping-retarget, the "unanticipated respondent" problem. When we think about what sorts of policy decisions we expect a human or automata to make when receiving a response with identity information, we have to acknowledge that the UAC has no way of knowing which respondents are or are not authorized to respond to the request in question. Since the UAC has no insight into any retargeting that has taken place, the UAC has to assume that virtually any response is a potentially legitimate one. As such, there is little room for any meaningful policy decision when receiving a response. This problem is further compounded by the fact that the UAS may have several possible legitimate AoRs it could claim (I have a UA that registers its contact address under 3 separate SIP services simultaneously), and of course the fact that AoRs may be pretty uninformative (e.g. sip:user31@freesipservice.example.com), all of which complicate authorization decisions. Solving this problem is on the same footing as solving the request-history problem set. =20 With that background, the problems with providing this connected party information in responses (via the To header or what have you) are roughly as follows: =20 a) The "unanticipated respondent" problem is especially an issue for response identity because not all responses are success responses. If you end up connecting to a party (receiving a 200), you can potentially rely on human factors to help you identify who you are talking to (after all, Carol can always answer Bob's phone regardless of who SIP thinks you connected to) and/or use the connected party information to change how you might address the party on the other side. With a 403 response, you are in a very different predicament - how is UAC or user behavior supposed to change based on the connected URI attributed to a 403, given the unanticipated respondent problem? For provisional responses, the issues become even worse - we then get into the wonders of forking, multiple provisional responses from multiple sources asserting different To header fields - in short, nothing which makes it any easier to render a "responding" AoR to a user, for example. Response identity, in so far as it deals with non-final, non-successful responses, opens up the "unconnected party" problem set. I think this is just the wrong framing of the problem. You want to know who you connected to, not who you didn't connect to. =20 b) Getting a signature over the To header field in responses would be difficult. In full awareness of Mr. Elwell's note below that certain parties are interested in "(unauthenticated) identity in a response", if this information is going to be put to any purpose, cause any change in human or UAC behavior, I have a hard time seeing how anyone could defend it being unsecured. If you want a human or an automata to make a policy decision based on the AoR in the To header field of the response, some sort of response identity signature would be necessary to prevent obvious impersonation attacks designed to thwart authorization decisions. With all due respect to the authors of draft-cao-sip-response-identity/auth, I'm not sure this problem is readily solved. Making sure that an appropriate authentication service is in the path of responses is problematic, since responses must traverse exactly the same path as requests. I played around with this a lot in the early phases of SIP identity, and at the end of the day, I had to conclude that the only way to make this work was to eliminate retargeting. Since providing connected-identity in responses assumes that retargeting has taken place, it wouldn't exactly be getting off on the right foot. Constraining inbound request routing to a domain such that responses will traverse an authentication service, or forcing a UAS to participate in the Identity scheme, is likely to require mandatory option-tags or comparable mechanisms that will limit the applicability of response identity and more or less eliminate its opportunistic use. =20 c) The inability to reject a response. Take the easiest case - let's say that the UAC receives a final success response, say a 200 response, with a modified To header field from a party that is blacklisted by UAC policy. What exactly is the UAC supposed to do? Send a 403? One cannot reject responses. Maybe a CANCEL? As section 9.1 of RFC3261 says, CANCEL "has no effect on requests that have already generated a final response." Drop the request on the floor? You'll just receive retransmissions. All you can do is ACK it, since the dialog has already been formed, and then send a BYE. In other words, a session -will- be established, there simply isn't an opportunity for policy to be put into effect prior to session establishment. Also, consider the need for the new responses defined in the sip-identity draft, like say the 438 response - if the UAC receives a 200 response with a potentially repairable error in the Identity header, how can it express that error to the UAS, since it can't send responses to a response? =20 Given the above, why does the UAC need to know who has been reached in the response, rather than in a request after the dialog has been formed? As (c) illustrates, in the 200 response case a session will be established anyway, so sharing the identity of the connected party after session establishment doesn't actually miss some opportunity for applying policy - moreover, an UPDATE or similar request that provides the connected-identity information could be rejected by the session-originating UA in a manner that is helpful to the session-terminating UA (e.g., a 438 response could be sent). If we go with the mechanism in the connected-identity draft, problem (b) disappears, since request routing is far more malleable than response routing. Additionally, the connected-identity draft wisely does not attempt to solve "unconnected party" problems from (a), which are the least tractable of the unanticipated respondent problems. Rather, connected-identity provides an indication more along the lines of, "your dialog was established, however that might have happened, and this is who is on the other side". =20 Furthermore, any solution that tried to put the connected-identity information into responses would be providing an imprimatur of legitimacy to those responses - presuming they had a signature, UACs would validate it, and provided it checked out, they would be tempted say "this is a legitimate response." Nothing could be further from the truth, as sipping-retarget illustrates. Legitimacy of responses cannot be determined by UACs in the absence of something like request-history. =20 Finally, I like having one Identity header, and for the meaning of that Identity header to *always* be that it is a signature over the >From header field issued by the domain identified by the host portion of the addr-spec of the From header field. The current connected-identity header draft provides that property. =20 Jon Peterson NeuStar, Inc. -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens.com] Sent: Monday, April 03, 2006 11:46 PM To: sip@ietf.org Subject: [Sip] Connected-identity and changing the To header field in aresponse =09 =09 During discussion of draft-elwell-connected-identity in Dallas, somebody put forward the opinion that it would be dangerous to change the To header field URI in a response (i.e., make it different from the From header field URI in the request). My assumption at the time was that it would undermine the transaction concept in SIP, yet reading what RFC3261 has to say about transactions, the value of the To header field URI in a response does not appear to be involved in coupling a response to a request. Therefore I assume the person who indicated the danger (which was not challenged at the meeting) has other reasons in mind. I would greatly appreciate opinions on the wisdom or otherwise of allowing the To header field URI to change. It seems that from discussion of connected-identity there is a desire from some parts of the community to include an (unauthenticated) identity in a response. John=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 Apr 05 04:30:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR3Nw-0004GK-3A; Wed, 05 Apr 2006 04:29:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR3Nu-0004GE-GL for sip@ietf.org; Wed, 05 Apr 2006 04:29:02 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR3Nu-0002gc-5b for sip@ietf.org; Wed, 05 Apr 2006 04:29:02 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 416F14F00A9; Wed, 5 Apr 2006 09:50:13 +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, 5 Apr 2006 09:50:13 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 09:50:13 +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: Questions on reg-id Date: Wed, 5 Apr 2006 09:50:12 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1CA1@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: Questions on reg-id Thread-Index: AcZX775+mJ0TxX+FS9yGTubnNt13yQAlMfIw From: "Christer Holmberg \(JO/LMF\)" To: "Fredrik Thulin" X-OriginalArrivalTime: 05 Apr 2006 07:50:13.0004 (UTC) FILETIME=[920084C0:01C65885] X-Brightmail-Tracker: AAAAAA== 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 Hi Fredrik, I wonder if it would be good to combine the checking of the reg-id and Call-ID then. Because, even if the UA does NOT reboot, it is still going to send periodical registration refreshes, without updating the flow characteristics (source port etc).=20 So, if the reg-id AND Call-Id are identical from the previous register the receiver would assume this is just a refresh.=20 But, if the reg-id is identical, but the Call-Id is NOT, from the previous register (the Call-Id must change after the reboot, in order not cause problems with the Cseq check by the receiver) the receiver would assume that a flow has been "replaced" (e.g. due to a UA reboot). Regards, Christer =20 -----Original Message----- From: Fredrik Thulin [mailto:ft@it.su.se]=20 Sent: 4. huhtikuuta 2006 16:57 To: Christer Holmberg (JO/LMF) Cc: sip@ietf.org Subject: Re: [Sip] Outbound: Questions on reg-id On Tuesday 04 April 2006 15:48, Christer Holmberg (JO/LMF) wrote: > Hi, > > Ok, I missed that text. I appologize for that. > > But, then, if I send a REGISTER with reg-id=3D1, then I reboot, then I = > send a REGISTER with reg-id=3D1 again, how will the registrar know I=20 > have rebooted? I'd say it doesn't know that you rebooted, but it knows that you want to replace the entry in the location database from your first REGISTER with the one in your second. This means that you don't want to use the flow from your first REGISTER either. To better understand the benefit of this, picture the example with the first REGISTER going from IP tcp:192.0.2.11:1234 (source port 1234) with reg-id=3D1. Then a reboot and then your second REGISTER from tcp:192.0.2.11:1111 (new source port) but once again reg-id=3D1. Oh, and it's not really just saying that you "want" the registrar to stop using the old flow, you indicate to the registrar that it MUST stop using the old flow but may very well use the new flow you just initiated. /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 Apr 05 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 1FR3RE-0003S6-LQ; Wed, 05 Apr 2006 04:32:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR3RD-0003Qo-Rd for sip@ietf.org; Wed, 05 Apr 2006 04:32:27 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR3RD-0002w3-D4 for sip@ietf.org; Wed, 05 Apr 2006 04:32:27 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k358WNBW032437; Wed, 5 Apr 2006 08:32:23 GMT Received: from stntexch03.cis.neustar.com ([10.31.13.45]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 04:32:21 -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] Connected-identity and changing the To header field inaresponse Date: Wed, 5 Apr 2006 04:32:21 -0400 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD597054F43D4@stntexch03.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Connected-identity and changing the To header field inaresponse Thread-Index: AcZYf4XMmMy8DdNZSsuggMi05qc+0QAAVL+gAAJpT9A= From: "Peterson, Jon" To: "Christer Holmberg \(JO/LMF\)" , "Elwell, John" , X-OriginalArrivalTime: 05 Apr 2006 08:32:21.0737 (UTC) FILETIME=[753E8D90:01C6588B] X-Spam-Score: 0.5 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 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 Just for my edification, Additional Connected Number is one of the = Generic Number options that can appear in ANM (or CON)? Or is this = something else? Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com] > Sent: Wednesday, April 05, 2006 12:34 AM > To: Elwell, John; Peterson, Jon; sip@ietf.org > Subject: RE: [Sip] Connected-identity and changing the To header field > inaresponse >=20 >=20 > =20 > Hi, >=20 > In PSTN terms we are talking about that the TO header shall=20 > be mapped to > the additional connected number, and that does NOT need to be=20 > authorized > in the same way as the connected number. >=20 > And, whether the interworking node sends this value to PSTN=20 > is of course > based on local policy, based on trust etc. >=20 > Regards, >=20 > Christer >=20 >=20 > ________________________________ >=20 > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > Sent: 5. huhtikuuta 2006 10:01 > To: Peterson, Jon; sip@ietf.org > Subject: RE: [Sip] Connected-identity and changing the To header field > inaresponse >=20 >=20 > Jon, > =20 > Thanks for this excellent summary of the issue, which I fully=20 > agree with > and which unfortunately seems to need restating at regular=20 > intervals. It > appears that the chief motivation of those asking for something in the > response is to facilitate interworking with PSTN (by=20 > including it in the > 200 response so that it can be mapped directly to the PSTN "connected" > message). As you say, such a response is always going to be > unauthenticated, and I don't think that meets the requirements of PSTN > interworking. Far better to figure out a way of using an authenticated > connected identity in an UPDATE message for mapping to PSTN connected > identity. > =20 > Of course, in trusted networks there may be other means for=20 > ensuring the > authenticity of an identity in a response, just as there is=20 > in a request > using P-Asserted-Identity. Unfortunately RFC3325 is unclear on the use > of PAI in responses, although in practice I think it is used and is > probably OK if the last hop is secured by TLS so that previous > authentication of the UAS can be relied on for making the assertion. I > think if those trusted networks really need a solution for response > identity, PAI would be a better avenue to explore (taking into account > the risks). But not for the Internet. I am becoming more and more > convinced that diluting the connected-identity draft with a weak > solution for response identity would be the wrong way to go. > =20 > John >=20 >=20 > ________________________________ >=20 > From: Peterson, Jon [mailto:jon.peterson@neustar.biz]=20 > Sent: 05 April 2006 02:05 > To: Elwell, John; sip@ietf.org > Subject: RE: [Sip] Connected-identity and changing the To header > field in aresponse > =09 > =09 > Yes, I was asked for clarification on this point after the > meeting, and I'll be providing it here. As you surmised, it=20 > is not that > RFC3261 relies on the addr-spec of the To or From header field for > transaction identification, or something. In fact, I would have > essentially the same concerns about any proposal that provided an > additional header (say, a 'Connected-Party' header) in responses to > dialog-forming requests which was understood to clobber the To header > field and identify the AoR of the party who was reached after > retargeting of the request took place. > =20 > Starting with the goals of this approach: what sort of UAC > decisions or behavior do we hope to enable through sending a response > with a modified To header field? As far as I can understand, we either > want to render this AoR to the user of a UAC (so the user can react in > one way or another), or input the AoR to some sort of policy manager > (e.g. blacklist/whitelist) that might make a decision about whether or > not the session should continue -prior- to session=20 > establishment. If we > don't care about this occurring prior to session establishment, of > course, then we could go with the connected-identity draft as it is > written today. > =20 > A little refresher on my sipping-retarget draft: The core > problem with any scheme for connected party is figuring out how you'd > decide whether or not a particular respondent is authorized.=20 > This is the > argument of 2.2.1 of sipping-retarget, the "unanticipated respondent" > problem. When we think about what sorts of policy decisions=20 > we expect a > human or automata to make when receiving a response with identity > information, we have to acknowledge that the UAC has no way of knowing > which respondents are or are not authorized to respond to the=20 > request in > question. Since the UAC has no insight into any retargeting that has > taken place, the UAC has to assume that virtually any response is a > potentially legitimate one. As such, there is little room for any > meaningful policy decision when receiving a response. This problem is > further compounded by the fact that the UAS may have several possible > legitimate AoRs it could claim (I have a UA that registers its contact > address under 3 separate SIP services simultaneously), and of=20 > course the > fact that AoRs may be pretty uninformative (e.g. > sip:user31@freesipservice.example.com), all of which complicate > authorization decisions. Solving this problem is on the same=20 > footing as > solving the request-history problem set. > =20 > With that background, the problems with providing this connected > party information in responses (via the To header or what=20 > have you) are > roughly as follows: > =20 > a) The "unanticipated respondent" problem is especially an issue > for response identity because not all responses are success responses. > If you end up connecting to a party (receiving a 200), you can > potentially rely on human factors to help you identify who you are > talking to (after all, Carol can always answer Bob's phone=20 > regardless of > who SIP thinks you connected to) and/or use the connected party > information to change how you might address the party on the=20 > other side. > With a 403 response, you are in a very different predicament - how is > UAC or user behavior supposed to change based on the connected URI > attributed to a 403, given the unanticipated respondent problem? For > provisional responses, the issues become even worse - we then get into > the wonders of forking, multiple provisional responses from multiple > sources asserting different To header fields - in short, nothing which > makes it any easier to render a "responding" AoR to a user,=20 > for example. > Response identity, in so far as it deals with non-final,=20 > non-successful > responses, opens up the "unconnected party" problem set. I=20 > think this is > just the wrong framing of the problem. You want to know who you > connected to, not who you didn't connect to. > =20 > b) Getting a signature over the To header field in responses > would be difficult. In full awareness of Mr. Elwell's note below that > certain parties are interested in "(unauthenticated) identity in a > response", if this information is going to be put to any=20 > purpose, cause > any change in human or UAC behavior, I have a hard time seeing how > anyone could defend it being unsecured. If you want a human or an > automata to make a policy decision based on the AoR in the To header > field of the response, some sort of response identity=20 > signature would be > necessary to prevent obvious impersonation attacks designed to thwart > authorization decisions. With all due respect to the authors of > draft-cao-sip-response-identity/auth, I'm not sure this problem is > readily solved. Making sure that an appropriate authentication service > is in the path of responses is problematic, since responses must > traverse exactly the same path as requests. I played around=20 > with this a > lot in the early phases of SIP identity, and at the end of the day, I > had to conclude that the only way to make this work was to eliminate > retargeting. Since providing connected-identity in responses assumes > that retargeting has taken place, it wouldn't exactly be=20 > getting off on > the right foot. Constraining inbound request routing to a domain such > that responses will traverse an authentication service, or=20 > forcing a UAS > to participate in the Identity scheme, is likely to require mandatory > option-tags or comparable mechanisms that will limit the applicability > of response identity and more or less eliminate its opportunistic use. > =20 > c) The inability to reject a response. Take the easiest case - > let's say that the UAC receives a final success response, say a 200 > response, with a modified To header field from a party that is > blacklisted by UAC policy. What exactly is the UAC supposed=20 > to do? Send > a 403? One cannot reject responses. Maybe a CANCEL? As section 9.1 of > RFC3261 says, CANCEL "has no effect on requests that have already > generated a final response." Drop the request on the floor?=20 > You'll just > receive retransmissions. All you can do is ACK it, since the=20 > dialog has > already been formed, and then send a BYE. In other words, a session > -will- be established, there simply isn't an opportunity for policy to > be put into effect prior to session establishment. Also, consider the > need for the new responses defined in the sip-identity draft, like say > the 438 response - if the UAC receives a 200 response with a=20 > potentially > repairable error in the Identity header, how can it express that error > to the UAS, since it can't send responses to a response? > =20 > Given the above, why does the UAC need to know who has been > reached in the response, rather than in a request after the dialog has > been formed? As (c) illustrates, in the 200 response case a=20 > session will > be established anyway, so sharing the identity of the connected party > after session establishment doesn't actually miss some opportunity for > applying policy - moreover, an UPDATE or similar request that provides > the connected-identity information could be rejected by the > session-originating UA in a manner that is helpful to the > session-terminating UA (e.g., a 438 response could be sent). If we go > with the mechanism in the connected-identity draft, problem (b) > disappears, since request routing is far more malleable than response > routing. Additionally, the connected-identity draft wisely does not > attempt to solve "unconnected party" problems from (a), which are the > least tractable of the unanticipated respondent problems. Rather, > connected-identity provides an indication more along the=20 > lines of, "your > dialog was established, however that might have happened, and this is > who is on the other side". > =20 > Furthermore, any solution that tried to put the > connected-identity information into responses would be providing an > imprimatur of legitimacy to those responses - presuming they had a > signature, UACs would validate it, and provided it checked out, they > would be tempted say "this is a legitimate response." Nothing could be > further from the truth, as sipping-retarget illustrates. Legitimacy of > responses cannot be determined by UACs in the absence of=20 > something like > request-history. > =20 > Finally, I like having one Identity header, and for the meaning > of that Identity header to *always* be that it is a signature over the > From header field issued by the domain identified by the host=20 > portion of > the addr-spec of the From header field. The current connected-identity > header draft provides that property. > =20 > Jon Peterson > NeuStar, Inc. >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Monday, April 03, 2006 11:46 PM > To: sip@ietf.org > Subject: [Sip] Connected-identity and changing the To > header field in aresponse > =09 > =09 >=20 > During discussion of draft-elwell-connected-identity in > Dallas, somebody put forward the opinion that it would be dangerous to > change the To header field URI in a response (i.e., make it different > from the From header field URI in the request). My assumption at the > time was that it would undermine the transaction concept in SIP, yet > reading what RFC3261 has to say about transactions, the value=20 > of the To > header field URI in a response does not appear to be involved in > coupling a response to a request. Therefore I assume the person who > indicated the danger (which was not challenged at the=20 > meeting) has other > reasons in mind. I would greatly appreciate opinions on the wisdom or > otherwise of allowing the To header field URI to change. It seems that > from discussion of connected-identity there is a desire from=20 > some parts > of the community to include an (unauthenticated) identity in=20 > a response. >=20 > John=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 Apr 05 04:40:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR3Ww-0007jd-S7; Wed, 05 Apr 2006 04:38:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR3Wu-0007jV-UX for sip@ietf.org; Wed, 05 Apr 2006 04:38:20 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR3Wr-0003CN-PK for sip@ietf.org; Wed, 05 Apr 2006 04:38:20 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 38DE74F01CB; Wed, 5 Apr 2006 10:38:17 +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, 5 Apr 2006 10:38:16 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 10:38:16 +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] Connected-identity and changing the To header field inaresponse Date: Wed, 5 Apr 2006 10:38:15 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1CA5@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Connected-identity and changing the To header field inaresponse Thread-Index: AcZYf4XMmMy8DdNZSsuggMi05qc+0QAAVL+gAAJpT9AAAG+7sA== From: "Christer Holmberg \(JO/LMF\)" To: "Peterson, Jon" , "Elwell, John" , X-OriginalArrivalTime: 05 Apr 2006 08:38:16.0689 (UTC) FILETIME=[48CFEE10:01C6588C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.5 (/) X-Scan-Signature: abda3837e791065a13ac6f11cf8e625a 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 Jon,=20 The answer is yes. Regards, Christer -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz]=20 Sent: 5. huhtikuuta 2006 11:32 To: Christer Holmberg (JO/LMF); Elwell, John; sip@ietf.org Subject: RE: [Sip] Connected-identity and changing the To header field inaresponse Just for my edification, Additional Connected Number is one of the Generic Number options that can appear in ANM (or CON)? Or is this something else? Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:christer.holmberg@ericsson.com] > Sent: Wednesday, April 05, 2006 12:34 AM > To: Elwell, John; Peterson, Jon; sip@ietf.org > Subject: RE: [Sip] Connected-identity and changing the To header field > inaresponse >=20 >=20 > =20 > Hi, >=20 > In PSTN terms we are talking about that the TO header shall be mapped=20 > to the additional connected number, and that does NOT need to be=20 > authorized in the same way as the connected number. >=20 > And, whether the interworking node sends this value to PSTN is of=20 > course based on local policy, based on trust etc. >=20 > Regards, >=20 > Christer >=20 >=20 > ________________________________ >=20 > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: 5. huhtikuuta 2006 10:01 > To: Peterson, Jon; sip@ietf.org > Subject: RE: [Sip] Connected-identity and changing the To header field > inaresponse >=20 >=20 > Jon, > =20 > Thanks for this excellent summary of the issue, which I fully agree=20 > with and which unfortunately seems to need restating at regular=20 > intervals. It appears that the chief motivation of those asking for=20 > something in the response is to facilitate interworking with PSTN (by=20 > including it in the 200 response so that it can be mapped directly to=20 > the PSTN "connected" > message). As you say, such a response is always going to be=20 > unauthenticated, and I don't think that meets the requirements of PSTN > interworking. Far better to figure out a way of using an authenticated > connected identity in an UPDATE message for mapping to PSTN connected=20 > identity. > =20 > Of course, in trusted networks there may be other means for ensuring=20 > the authenticity of an identity in a response, just as there is in a=20 > request using P-Asserted-Identity. Unfortunately RFC3325 is unclear on > the use of PAI in responses, although in practice I think it is used=20 > and is probably OK if the last hop is secured by TLS so that previous=20 > authentication of the UAS can be relied on for making the assertion. I > think if those trusted networks really need a solution for response=20 > identity, PAI would be a better avenue to explore (taking into account > the risks). But not for the Internet. I am becoming more and more=20 > convinced that diluting the connected-identity draft with a weak=20 > solution for response identity would be the wrong way to go. > =20 > John >=20 >=20 > ________________________________ >=20 > From: Peterson, Jon [mailto:jon.peterson@neustar.biz]=20 > Sent: 05 April 2006 02:05 > To: Elwell, John; sip@ietf.org > Subject: RE: [Sip] Connected-identity and changing the To header > field in aresponse > =09 > =09 > Yes, I was asked for clarification on this point after the meeting,=20 > and I'll be providing it here. As you surmised, it is not that > RFC3261 relies on the addr-spec of the To or From header field for=20 > transaction identification, or something. In fact, I would have=20 > essentially the same concerns about any proposal that provided an=20 > additional header (say, a 'Connected-Party' header) in responses to=20 > dialog-forming requests which was understood to clobber the To header=20 > field and identify the AoR of the party who was reached after=20 > retargeting of the request took place. > =20 > Starting with the goals of this approach: what sort of UAC decisions=20 > or behavior do we hope to enable through sending a response with a=20 > modified To header field? As far as I can understand, we either want=20 > to render this AoR to the user of a UAC (so the user can react in one=20 > way or another), or input the AoR to some sort of policy manager (e.g. > blacklist/whitelist) that might make a decision about whether or not=20 > the session should continue -prior- to session establishment. If we=20 > don't care about this occurring prior to session establishment, of=20 > course, then we could go with the connected-identity draft as it is=20 > written today. > =20 > A little refresher on my sipping-retarget draft: The core problem=20 > with any scheme for connected party is figuring out how you'd decide=20 > whether or not a particular respondent is authorized. > This is the > argument of 2.2.1 of sipping-retarget, the "unanticipated respondent" > problem. When we think about what sorts of policy decisions we expect=20 > a human or automata to make when receiving a response with identity=20 > information, we have to acknowledge that the UAC has no way of knowing > which respondents are or are not authorized to respond to the request=20 > in question. Since the UAC has no insight into any retargeting that=20 > has taken place, the UAC has to assume that virtually any response is=20 > a potentially legitimate one. As such, there is little room for any=20 > meaningful policy decision when receiving a response. This problem is=20 > further compounded by the fact that the UAS may have several possible=20 > legitimate AoRs it could claim (I have a UA that registers its contact > address under 3 separate SIP services simultaneously), and of course=20 > the fact that AoRs may be pretty uninformative (e.g. > sip:user31@freesipservice.example.com), all of which complicate=20 > authorization decisions. Solving this problem is on the same footing=20 > as solving the request-history problem set. > =20 > With that background, the problems with providing this connected > party information in responses (via the To header or what have you)=20 > are roughly as follows: > =20 > a) The "unanticipated respondent" problem is especially an issue for=20 > response identity because not all responses are success responses. > If you end up connecting to a party (receiving a 200), you can=20 > potentially rely on human factors to help you identify who you are=20 > talking to (after all, Carol can always answer Bob's phone regardless=20 > of who SIP thinks you connected to) and/or use the connected party=20 > information to change how you might address the party on the other=20 > side. > With a 403 response, you are in a very different predicament - how is=20 > UAC or user behavior supposed to change based on the connected URI=20 > attributed to a 403, given the unanticipated respondent problem? For=20 > provisional responses, the issues become even worse - we then get into > the wonders of forking, multiple provisional responses from multiple=20 > sources asserting different To header fields - in short, nothing which > makes it any easier to render a "responding" AoR to a user, for=20 > example. > Response identity, in so far as it deals with non-final,=20 > non-successful responses, opens up the "unconnected party" problem=20 > set. I think this is just the wrong framing of the problem. You want=20 > to know who you connected to, not who you didn't connect to. > =20 > b) Getting a signature over the To header field in responses would be=20 > difficult. In full awareness of Mr. Elwell's note below that certain=20 > parties are interested in "(unauthenticated) identity in a response",=20 > if this information is going to be put to any purpose, cause any=20 > change in human or UAC behavior, I have a hard time seeing how anyone=20 > could defend it being unsecured. If you want a human or an automata to > make a policy decision based on the AoR in the To header field of the=20 > response, some sort of response identity signature would be necessary=20 > to prevent obvious impersonation attacks designed to thwart=20 > authorization decisions. With all due respect to the authors of=20 > draft-cao-sip-response-identity/auth, I'm not sure this problem is=20 > readily solved. Making sure that an appropriate authentication service > is in the path of responses is problematic, since responses must=20 > traverse exactly the same path as requests. I played around with this=20 > a lot in the early phases of SIP identity, and at the end of the day,=20 > I had to conclude that the only way to make this work was to eliminate > retargeting. Since providing connected-identity in responses assumes=20 > that retargeting has taken place, it wouldn't exactly be getting off=20 > on the right foot. Constraining inbound request routing to a domain=20 > such that responses will traverse an authentication service, or=20 > forcing a UAS to participate in the Identity scheme, is likely to=20 > require mandatory option-tags or comparable mechanisms that will limit > the applicability of response identity and more or less eliminate its=20 > opportunistic use. > =20 > c) The inability to reject a response. Take the easiest case - let's=20 > say that the UAC receives a final success response, say a 200=20 > response, with a modified To header field from a party that is=20 > blacklisted by UAC policy. What exactly is the UAC supposed to do?=20 > Send a 403? One cannot reject responses. Maybe a CANCEL? As section=20 > 9.1 of > RFC3261 says, CANCEL "has no effect on requests that have already=20 > generated a final response." Drop the request on the floor? > You'll just > receive retransmissions. All you can do is ACK it, since the dialog=20 > has already been formed, and then send a BYE. In other words, a=20 > session > -will- be established, there simply isn't an opportunity for policy to > be put into effect prior to session establishment. Also, consider the=20 > need for the new responses defined in the sip-identity draft, like say > the 438 response - if the UAC receives a 200 response with a=20 > potentially repairable error in the Identity header, how can it=20 > express that error to the UAS, since it can't send responses to a=20 > response? > =20 > Given the above, why does the UAC need to know who has been reached=20 > in the response, rather than in a request after the dialog has been=20 > formed? As (c) illustrates, in the 200 response case a session will be > established anyway, so sharing the identity of the connected party=20 > after session establishment doesn't actually miss some opportunity for > applying policy - moreover, an UPDATE or similar request that provides > the connected-identity information could be rejected by the=20 > session-originating UA in a manner that is helpful to the=20 > session-terminating UA (e.g., a 438 response could be sent). If we go=20 > with the mechanism in the connected-identity draft, problem (b)=20 > disappears, since request routing is far more malleable than response=20 > routing. Additionally, the connected-identity draft wisely does not=20 > attempt to solve "unconnected party" problems from (a), which are the=20 > least tractable of the unanticipated respondent problems. Rather,=20 > connected-identity provides an indication more along the lines of,=20 > "your dialog was established, however that might have happened, and=20 > this is who is on the other side". > =20 > Furthermore, any solution that tried to put the connected-identity=20 > information into responses would be providing an imprimatur of=20 > legitimacy to those responses - presuming they had a signature, UACs=20 > would validate it, and provided it checked out, they would be tempted=20 > say "this is a legitimate response." Nothing could be further from the > truth, as sipping-retarget illustrates. Legitimacy of responses cannot > be determined by UACs in the absence of something like=20 > request-history. > =20 > Finally, I like having one Identity header, and for the meaning of=20 > that Identity header to *always* be that it is a signature over the=20 > From header field issued by the domain identified by the host portion=20 > of the addr-spec of the From header field. The current=20 > connected-identity header draft provides that property. > =20 > Jon Peterson > NeuStar, Inc. >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Monday, April 03, 2006 11:46 PM > To: sip@ietf.org > Subject: [Sip] Connected-identity and changing the To header field=20 > in aresponse > =09 > =09 >=20 > During discussion of draft-elwell-connected-identity in Dallas,=20 > somebody put forward the opinion that it would be dangerous to change=20 > the To header field URI in a response (i.e., make it different from=20 > the From header field URI in the request). My assumption at the time=20 > was that it would undermine the transaction concept in SIP, yet=20 > reading what RFC3261 has to say about transactions, the value of the=20 > To header field URI in a response does not appear to be involved in=20 > coupling a response to a request. Therefore I assume the person who=20 > indicated the danger (which was not challenged at the > meeting) has other > reasons in mind. I would greatly appreciate opinions on the wisdom or=20 > otherwise of allowing the To header field URI to change. It seems that > from discussion of connected-identity there is a desire from some=20 > parts of the community to include an (unauthenticated) identity in a=20 > response. >=20 > John >=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 Apr 05 05:00:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR3qB-0004lS-E0; Wed, 05 Apr 2006 04:58:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR3qA-0004lN-0Q for sip@ietf.org; Wed, 05 Apr 2006 04:58:14 -0400 Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR3q9-0003w5-K8 for sip@ietf.org; Wed, 05 Apr 2006 04:58:13 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id AEF58740B4; Wed, 5 Apr 2006 10:58:12 +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 29469-01-84; Wed, 5 Apr 2006 10:58:03 +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 2074474025; Wed, 5 Apr 2006 10:58:03 +0200 (CEST) From: Fredrik Thulin To: "Christer Holmberg \(JO/LMF\)" Subject: Re: [Sip] Outbound: Questions on reg-id Date: Wed, 5 Apr 2006 10:57:59 +0200 User-Agent: KMail/1.9.1 References: <5EB80D22825EEE42872083AD5BFFB5945D1CA1@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1CA1@esealmw113.eemea.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200604051057.59223.ft@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.526 tagged_above=-99 required=7 tests=[AWL=0.139, BAYES_00=-1.665] X-Spam-Level: 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 On Wednesday 05 April 2006 09:50, Christer Holmberg (JO/LMF) wrote: > Hi Fredrik, > > I wonder if it would be good to combine the checking of the reg-id > and Call-ID then. > > Because, even if the UA does NOT reboot, it is still going to send > periodical registration refreshes, without updating the flow > characteristics (source port etc). > > So, if the reg-id AND Call-Id are identical from the previous > register the receiver would assume this is just a refresh. > > But, if the reg-id is identical, but the Call-Id is NOT, from the > previous register (the Call-Id must change after the reboot, in order > not cause problems with the Cseq check by the receiver) the receiver > would assume that a flow has been "replaced" (e.g. due to a UA > reboot). I think these are issues you have to deal with when implementing Outbound in a Registrar (something I have done), but not something that needs to be explained further in the standard. If Outbound _replaced_ RFC3261 #10.3 then it would have to be spelled out, but it doesn't - it just extends it. In my implementation I didn't touch the RFC3261 10.3 processing. I just added functionality to remove any contacts in the location database whose instance-id and reg-id matched the contact (from a REGISTER) currently being processed to the code that already removed any bindings in the location database for the current AOR whose URI matched the contact being processed. After SIPIT I hope to be able to tell you if this works in practice and not only in theory (theory plus test cases). /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 Apr 05 05:07:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR3x9-0006i5-Jo; Wed, 05 Apr 2006 05:05:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR3x7-0006hM-Jx for sip@ietf.org; Wed, 05 Apr 2006 05:05:25 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR3x6-0004Lt-PT for sip@ietf.org; Wed, 05 Apr 2006 05:05:25 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EF6434F0001; Wed, 5 Apr 2006 11:05:23 +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, 5 Apr 2006 11:05:23 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 11:05: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: Questions on reg-id Date: Wed, 5 Apr 2006 11:05:22 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1CA7@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: Questions on reg-id Thread-Index: AcZYjxOPYr/hHePxRAe/wR/bZbL0nQAAF0zQ From: "Christer Holmberg \(JO/LMF\)" To: "Fredrik Thulin" X-OriginalArrivalTime: 05 Apr 2006 09:05:23.0078 (UTC) FILETIME=[12373260:01C65890] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 Fredrik, If you agree on what I say, I see no harm in documenting it. I think it will clarify things, and HELP interoperability :) I've been to a number of SIPits (and bake-offs before that) myself, and I believe many of the problems that have occured could have been avoided with a little better explanation/clarification in the documents. RFC 3261 also says that the same Call-Id value should be used for all registrations sent from a UA. I don't think it matters if the same Call-Id is used for different reg-ids or not, but in order to avoid questions in the future I see no harm in putting down a few words about it. Regards, Christer -----Original Message----- From: Fredrik Thulin [mailto:ft@it.su.se]=20 Sent: 5. huhtikuuta 2006 11:58 To: Christer Holmberg (JO/LMF) Cc: sip@ietf.org Subject: Re: [Sip] Outbound: Questions on reg-id On Wednesday 05 April 2006 09:50, Christer Holmberg (JO/LMF) wrote: > Hi Fredrik, > > I wonder if it would be good to combine the checking of the reg-id and > Call-ID then. > > Because, even if the UA does NOT reboot, it is still going to send=20 > periodical registration refreshes, without updating the flow=20 > characteristics (source port etc). > > So, if the reg-id AND Call-Id are identical from the previous register > the receiver would assume this is just a refresh. > > But, if the reg-id is identical, but the Call-Id is NOT, from the=20 > previous register (the Call-Id must change after the reboot, in order=20 > not cause problems with the Cseq check by the receiver) the receiver=20 > would assume that a flow has been "replaced" (e.g. due to a UA=20 > reboot). I think these are issues you have to deal with when implementing Outbound in a Registrar (something I have done), but not something that needs to be explained further in the standard. If Outbound _replaced_ RFC3261 #10.3 then it would have to be spelled out, but it doesn't - it just extends it. In my implementation I didn't touch the RFC3261 10.3 processing. I just added functionality to remove any contacts in the location database whose instance-id and reg-id matched the contact (from a REGISTER) currently being processed to the code that already removed any bindings in the location database for the current AOR whose URI matched the contact being processed. After SIPIT I hope to be able to tell you if this works in practice and not only in theory (theory plus test cases). /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 Apr 05 05:14:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR43h-00022K-22; Wed, 05 Apr 2006 05:12:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR43g-00022F-3k for sip@ietf.org; Wed, 05 Apr 2006 05:12:12 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR43f-0004es-Sh for sip@ietf.org; Wed, 05 Apr 2006 05:12:12 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k359CBBW001794; Wed, 5 Apr 2006 09:12:11 GMT Received: from stntexch03.cis.neustar.com ([10.31.13.45]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 05:12:08 -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] SIP/TLS (1): Domain certificates in SIP Date: Wed, 5 Apr 2006 05:12:08 -0400 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD597054F43D6@stntexch03.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP/TLS (1): Domain certificates in SIP Thread-Index: AcZYLGQdTyIbohpCQziaC48V5ck0NwAYpU/g From: "Peterson, Jon" To: "Vijay K. Gurbani" , "Cullen Jennings" X-OriginalArrivalTime: 05 Apr 2006 09:12:08.0880 (UTC) FILETIME=[0417AB00:01C65891] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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 In sip-identity-06 (13.4), we defer the whole CN/SAN issue to RFC 2818: A verifier MUST evaluate the correspondence between the user's identity and the signing certificate by following the procedures defined in RFC 2818 [11] Section 3.1. While RFC2818 deals with the use of HTTP in TLS, the procedures described are applicable to verifying identity if one subtitutes the "hostname of the server" in HTTP for the domain portion of the user's identity in the From header field of a SIP request with an Identity header. Essentially, the rules in RFC2818 state that SAN is used if present, and = if not present, the most specific CN is used. We follow RFC2818 so that = we'll have the closest correspondence to the practices of web = certificate authorities for traditional TLS usage. We should probably = update the canonical RFC3261 procedures to do the same. Regarding name subordination, again, I think the guidance in = sip-identity-06 13.4 is the best text we have today. "Virtual hosting" = scenarios are discussed in that text, and the ramifications of the = design of RFC3263 on virtual hosting configurations are explicitly laid = out. I suspect the text there is the best starting place for = establishing rules for how domain certificates are understood in SIP. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@lucent.com] > Sent: Tuesday, April 04, 2006 2:12 PM > To: Cullen Jennings > Cc: sip@ietf.org > Subject: Re: [Sip] SIP/TLS (1): Domain certificates in SIP >=20 >=20 > Cullen Jennings wrote: > > I don't understand the DNS name would refer to a host or conversely > > why the SIP name does not. Either can refer to either. I don't see > > the need for distinction - the cert needs to refer to the name used > > to reach the proxy - that is typically called the "domain" but may > > refer to a single host or many. >=20 > If the "domain" refers to many hosts, then is the cert shared among > all the hosts? Or does each host have a different cert with the same > domainname in SAN but a unique serial number? >=20 > If a cert only has a SAN of DNS:proxy-1.example.com" is the intent, > then that proxy-1 is the authority for example.com? Then, if another > cert has a SAN of "DNS:proxy-1.south.example.com" is the intent that > proxy-1 is the authority for south.example.com zone AND example.com > zone? >=20 > > I see no need to step into any CN disasters - they are very hard to > > specify and we have no backwards compatible need to do it. SIP has > > been SAN from the beginning. >=20 > OK. Thanks for the clarification. >=20 > However, in rfc3261, SAN is only mentioned in connection with S/MIME > certs (section 23.2). For TLS certs, rfc3261 simply says "Proxy > servers, redirect servers, and registrars SHOULD possess a site > certificate whose subject corresponds to their canonical hostname". > It is probably the intent that the "subject" in that sentence refer > to SAN; but it is not clear from simply reading the sentence that > this is indeed the intent. >=20 > Thanks, >=20 > - 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) >=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 Apr 05 05:26:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR4Fq-0007qS-SC; Wed, 05 Apr 2006 05:24:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR4Fp-0007qN-Lg for sip@ietf.org; Wed, 05 Apr 2006 05:24:45 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR4Fp-0005KY-DF for sip@ietf.org; Wed, 05 Apr 2006 05:24: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 k359OfO0028398; Wed, 5 Apr 2006 04:24:41 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 5 Apr 2006 10:24:41 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0129680D5@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Gary Gan Subject: RE: [Sip] draft-ietf-sipping-conference-package : MTU Date: Wed, 5 Apr 2006 10:24: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: 0fa76816851382eb71b0a882ccdc29ac 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 Please read section 18.1.1 of RFC 3261. At least one other RFC tightens this up for specific extensions, but in essence this is the core of the SIP requirement. Yes, a UA must check before generating UDP greated that MTU less 200 (or else use a reliable transport protocol all the time). regards Keith > -----Original Message----- > From: Gary Gan [mailto:ggan@cliquecom.com] > Sent: 04 April 2006 18:50 > To: 'Dale R. Worley' > Cc: sip@ietf.org > Subject: RE: [Sip] draft-ietf-sipping-conference-package : MTU > > > Does it mean the SIP UA is supposed to check the SIP message > size, if it is > too big, it will automatically switch to TCP? Is it a mixed > TCP/UDP SIP > messages within a SIP session or it needs to decide UDP or TCP at the > beginning of a session? > > How TCP is used in SIP? Is it a connection/disconnect per > message like a WEB > request, or connection on each session, or even a connection > pool based on > the destinations? I think only the WEB request style makes sense for > SIP/TCP. SIP doesn't define differently for TCP in terms of > connect and > disconnect. > > Gary Gan > > -----Original Message----- > From: Dale R. Worley [mailto:dworley@pingtel.com] > Sent: Tuesday, April 04, 2006 11:38 AM > To: Sip > Subject: Re: [Sip] draft-ietf-sipping-conference-package : MTU > > On Tue, 2006-04-04 at 10:07 -0400, Gary Gan wrote: > > The SIP conference info package could be very large > depending on the size > of > > the conference. How does it handle the MTU issue? > > Such a NOTIFY would be sent using TCP. > > RFC 3261 section 18: > > All SIP elements MUST implement UDP and TCP. > > Section 18.1.1: > > 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 [43] congestion controlled transport > protocol, such as > TCP. > > 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 05 05:40:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR4Sl-0006ZS-Su; Wed, 05 Apr 2006 05:38:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR4Sl-0006ZN-8D for sip@ietf.org; Wed, 05 Apr 2006 05:38:07 -0400 Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR4Sj-0005zD-VV for sip@ietf.org; Wed, 05 Apr 2006 05:38:07 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id 8614174031; Wed, 5 Apr 2006 11:38:05 +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 01881-01-23; Wed, 5 Apr 2006 11:38:05 +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 28D4A74030; Wed, 5 Apr 2006 11:38:05 +0200 (CEST) From: Fredrik Thulin To: "Christer Holmberg \(JO/LMF\)" Subject: Re: [Sip] Outbound: Questions on reg-id Date: Wed, 5 Apr 2006 11:38:01 +0200 User-Agent: KMail/1.9.1 References: <5EB80D22825EEE42872083AD5BFFB5945D1CA7@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1CA7@esealmw113.eemea.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200604051138.01051.ft@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.526 tagged_above=-99 required=7 tests=[AWL=0.139, BAYES_00=-1.665] X-Spam-Level: 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 Wednesday 05 April 2006 11:05, Christer Holmberg (JO/LMF) wrote: > Hi Fredrik, > > If you agree on what I say, I see no harm in documenting it. What _are_ you saying? What is it that you want to document? I must be misunderstanding you somewhere, because it sounds to me like you want the Outbound specification to say that you must not only do REGISTER processing as per the Outbound specification, but also according to RFC3261 #10.3. I think that is obvious and I think it makes no sense to litter Outbound with such references. /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 Apr 05 05:49:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR4bd-0000LU-PU; Wed, 05 Apr 2006 05:47:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR4bb-0000LM-Pe for sip@ietf.org; Wed, 05 Apr 2006 05:47:15 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR4ba-00067o-9M for sip@ietf.org; Wed, 05 Apr 2006 05:47:15 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E05B24F0069; Wed, 5 Apr 2006 11:45:22 +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, 5 Apr 2006 11:45:22 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 11:45:22 +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: Questions on reg-id Date: Wed, 5 Apr 2006 11:45:22 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1CAC@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: Questions on reg-id Thread-Index: AcZYlKmNx89Yirs3Rr6Izc9a19X7zAAAG4zg From: "Christer Holmberg \(JO/LMF\)" To: "Fredrik Thulin" X-OriginalArrivalTime: 05 Apr 2006 09:45:22.0482 (UTC) FILETIME=[A85F3120:01C65895] X-Brightmail-Tracker: AAAAAA== 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 Hi, >>Hi Fredrik, >> >>If you agree on what I say, I see no harm in documenting it.=20 > >What _are_ you saying? What is it that you want to document? > >I must be misunderstanding you somewhere, because it sounds to me like you want the Outbound specification to say that=20 >you must not only do REGISTER processing as per the Outbound specification, but also according to RFC3261 #10.3. I think=20 >that is obvious and I think it makes no sense to litter Outbound with such references. That is not what I am saying. I am asking to: 1. Adding a few words saying that checking the Call-Id to detect whether a REGISTER is a refresh or a new REGISTER after a reboot. The document currently says that the reg-id alone is used to indicate reboot, but I think we have agreed that is not the case. 2. Adding a few words saying that the same Call-Id value MAY be used for all flows (assuming we agree there are no impacts whether the same values are used or not). 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 Apr 05 06:00:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR4mP-0000st-Rn; Wed, 05 Apr 2006 05:58:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR4mM-0000so-FV for sip@ietf.org; Wed, 05 Apr 2006 05:58:22 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR4mJ-0006JJ-N5 for sip@ietf.org; Wed, 05 Apr 2006 05:58:22 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1F9E64F00C8 for ; Wed, 5 Apr 2006 11:58:19 +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, 5 Apr 2006 11:58:18 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 11:58:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Apr 2006 11:58:18 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1CB3@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Outbound: Multiple flows and forking Thread-Index: AcZYipuMuZenoSc3RB2Ae8gUfKD0rgAB5trw From: "Christer Holmberg \(JO/LMF\)" To: X-OriginalArrivalTime: 05 Apr 2006 09:58:18.0489 (UTC) FILETIME=[76E87690:01C65897] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Subject: [Sip] RE: Outbound: Multiple flows and forking X-BeenThere: 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="===============0958532226==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0958532226== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65897.76BC29A3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65897.76BC29A3 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, One more thing about mandating the sending of REGISTERs to multiple proxies. To maintain a single registration flow will most likely have impacts on batteries in mobile devices, and mandating to maintain multiple flows would have even bigger impacts. So, that's another reason I don't think it shall be mandated. Regards, Christer > _____________________________________________=20 > From: Christer Holmberg (JO/LMF) =20 > Sent: 5. huhtikuuta 2006 11:26 > To: sip@ietf.org > Subject: Outbound: Multiple flows and forking >=20 >=20 > Hi, >=20 > A couple of issues on chapter 4.2. >=20 > The text says: >=20 > "However, a UA MUST support sets with at least two outbound proxy URIs > (primary and backup) 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." >=20 > I don't think we should mandate this, because it is very much > dependent on the architecture, transport techniques etc.=20 >=20 > Also, if the UA has registered multiple flows, should the registrar > fork dialog initiation requests (addressed for the UA) on all of them? > I realize it is an implementation issue, but I think it would be good > to have some words about it in the draft, for example saying that a > registrar may choose not to fork if the same instance-id is used for > multiple bindings. Or something like that... >=20 > Regards, >=20 > Christer ------_=_NextPart_001_01C65897.76BC29A3 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: Outbound: Multiple flows and forking

Hi,

One more thing about = mandating the sending of REGISTERs to multiple proxies. To maintain a = single registration flow will most likely have impacts on batteries in = mobile devices, and mandating to maintain multiple flows would have even = bigger impacts. So, that's another reason I don't think it shall be = mandated.

Regards,

Christer


_____________________________________________
From:   Christer Holmberg (JO/LMF) 
Sent:   5. huhtikuuta 2006 11:26
To:     sip@ietf.org
Subject:       = Outbound: Multiple flows and = forking


Hi,

A couple of issues on chapter = 4.2.

The text says:

"However, a UA MUST support sets = with at least two outbound proxy URIs (primary and backup) 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."

I don't think we should mandate this, = because it is very much dependent on the architecture, transport = techniques etc.

Also, if the UA has registered multiple = flows, should the registrar fork dialog initiation requests (addressed = for the UA) on all of them? I realize it is an implementation issue, but = I think it would be good to have some words about it in the draft, for = example saying that a registrar may choose not to fork if the same = instance-id is used for multiple bindings. Or something like = that...

Regards,

Christer

------_=_NextPart_001_01C65897.76BC29A3-- --===============0958532226== 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 --===============0958532226==-- From sip-bounces@ietf.org Wed Apr 05 06:00:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR4mp-00012K-9Y; Wed, 05 Apr 2006 05:58:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR4mo-00012F-2a for sip@ietf.org; Wed, 05 Apr 2006 05:58:50 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR4mn-0006Nm-On for sip@ietf.org; Wed, 05 Apr 2006 05:58:50 -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 k359wfZu029559; Wed, 5 Apr 2006 03:58: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SIP MIB ietf-sip-mib comments - SipTransportProtocol Date: Wed, 5 Apr 2006 03:58:41 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP MIB ietf-sip-mib comments - SipTransportProtocol Thread-Index: AcY5j29dKQxxIed4SCWenzWDWU3cwgCDbzWgAWHdczABPKwkYAAB1NDAAC8iRbAEU4MgYwAALwMwABl5jWA= From: "Jean-Francois Mule" To: "Cullen Jennings" , "Samir Srivastava" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: sip@ietf.org, "Romascanu, Dan \(Dan\)" , Juergen Schoenwaelder , "Kevin Lingle \(klingle\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 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, and Samir, Thx for the comments. I will limit this response to your notes on SipTransportProtocol. Cullen wrote: > SipTransportProtocol > It is weird to include TLS given we have TLS for TCP, SCTP, and might > have for UDP too. Good point. Let me bring some context first, then propose some recommendations to = the wg to close the comment. First, this SipTransportProtocol is a textual-convention we designed = based on the transport layer descriptions in RFC 3261 (section 18, Via = header - 20.42). A textual-convention is designed as a type and it can = evolve as new values are added, or as existing general values are = refined to derive new specific values. --> Excerpts from RFC 3261 section 18: - defines sip transport as UDP, TCP, SCTP, TLS over TCP - defines transport ports as:=20 "5060 for UDP, TCP and SCTP, 5061 for TLS." (18.1.1) "5061 for TLS over TCP" (18.2.1) - 3261 vaguely mentions TLS over SCTP but the text is inconsistent as = RFC 4168 pointed out and clarified. (side note: should RFC 4168 be = considered an "update" of RFC3261 - it is not and may it should). --> Excerpts from 3261 section 20.42: - "Transport protocols defined here are "UDP", "TCP", "TLS", and = "SCTP". "TLS" means TLS over TCP. When a request is sent to a SIPS URI, = the protocol still indicates "SIP", and the transport protocol is TLS." --> Excerpts from RFC 4168: transport =3D "UDP" / "TCP" / "TLS" / "SCTP" / "TLS-SCTP" / other-transport Not to excuse the way we looked at sip transport but, if you recall, we = as co-authors expressly wanted or were told to stick to 3261 to manage = the scope of the mib as many extensions were popping up. We did change = the mib to align with this direction at some point. Then 4168 clarified the BNF for transport and how to express TLS over = SCTP. =3D=3D> Recommendations: - rename 'tls(4)' to be 'tls-tcp(4)' and be explicit that bit 4 is for = TLS over TCP per RFC 3261 - add a new bit value for 'tls-sctp(5)' for TLS over SCTP and add a = sentence to say that transport of SIP over SCTP is defined in RFC 4168. - add informative reference to RFC 4168 The new rough text would look like this, feel free to propose = enhancements: SipTransportProtocol ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "This convention is a bit map. Each bit represents a transport protocol. If a bit has value 1, then that selected transport protocol is in some way dependent on the context of the object using this convention. If a bit has value 0, then that transport protocol is not selected. Combinations of bits can be set when multiple transport protocols are selected. bit 0 : a protocol other than those defined here. bit 1 : User Datagram Protocol. bit 2 : Transmission Control Protocol. bit 3 : Stream Control Transmission Protocol. bit 4 : Transport Layer Security Protocol over TCP. bit 5 : Transport Layer Security Protocol over SCTP. = SYNTAX BITS { other(0), -- none of the following udp(1), tcp(2), sctp(3), tls-tcp(4) tls-sctp(5) -- RFC 4168 } -- REFERENCE "RFC 3261, Section 18" -- REFERENCE "RFC 4168" Comments welcome. Jean-Fran=E7ois _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 05 07:06:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR5oR-0002EI-U6; Wed, 05 Apr 2006 07:04:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR5oR-0002E9-4D for sip@ietf.org; Wed, 05 Apr 2006 07:04:35 -0400 Received: from smtp1.versatel.nl ([62.58.50.88] helo=smtp3.versatel.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR5oQ-0000YE-DC for sip@ietf.org; Wed, 05 Apr 2006 07:04:35 -0400 Received: (qmail 14771 invoked by uid 0); 5 Apr 2006 11:04:30 -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 < >; 5 Apr 2006 11:04:30 -0000 Message-ID: <003701c658a0$b5ded890$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Christer Holmberg \(JO/LMF\)" , References: <5EB80D22825EEE42872083AD5BFFB5945D1CB3@esealmw113.eemea.ericsson.se> Subject: Re: [Sip] RE: Outbound: Multiple flows and forking Date: Wed, 5 Apr 2006 13:04:29 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.1 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b 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="===============2109998521==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2109998521== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0034_01C658B1.7930E120" This is a multi-part message in MIME format. ------=_NextPart_000_0034_01C658B1.7930E120 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Outbound: Multiple flows and forkingChrister, I wouldn't recommend using outbound for mobile devices in the first = place In = http://www.ietf.org/internet-drafts/draft-brok-simple-regulate-publish-02= .txt section 2.2 there are some estimates for the effect of periodic = transmissions on the battery lifetime. This is for periodic PUBLISH, for = periodic keepalive (UDP: every 24-29 seconds, TCP: every 95-120 seconds) = it would even be worse. Your battery would be depleted in about a day Regards, Jeroen ----- Original Message -----=20 From: Christer Holmberg (JO/LMF)=20 To: sip@ietf.org=20 Sent: Wednesday, April 05, 2006 11:58 AM Subject: [Sip] RE: Outbound: Multiple flows and forking Hi,=20 One more thing about mandating the sending of REGISTERs to multiple = proxies. To maintain a single registration flow will most likely have = impacts on batteries in mobile devices, and mandating to maintain = multiple flows would have even bigger impacts. So, that's another reason = I don't think it shall be mandated. Regards,=20 Christer=20 _____________________________________________=20 From: Christer Holmberg (JO/LMF) =20 Sent: 5. huhtikuuta 2006 11:26=20 To: sip@ietf.org=20 Subject: Outbound: Multiple flows and forking=20 Hi,=20 A couple of issues on chapter 4.2.=20 The text says:=20 "However, a UA MUST support sets with at least two outbound proxy URIs = (primary and backup) 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." I don't think we should mandate this, because it is very much = dependent on the architecture, transport techniques etc.=20 Also, if the UA has registered multiple flows, should the registrar = fork dialog initiation requests (addressed for the UA) on all of them? I = realize it is an implementation issue, but I think it would be good to = have some words about it in the draft, for example saying that a = registrar may choose not to fork if the same instance-id is used for = multiple bindings. Or something like that... Regards,=20 Christer=20 -------------------------------------------------------------------------= ----- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------=_NextPart_000_0034_01C658B1.7930E120 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Outbound: Multiple flows and forking
Christer,
 
I wouldn't recommend using outbound for = mobile=20 devices in the first place
 
In http://www.ietf.org/internet-drafts/draft-brok-simple-regul= ate-publish-02.txt section=20 2.2 there are some estimates for the effect of periodic transmissions on = the=20 battery lifetime. This is for periodic PUBLISH, for periodic keepalive = (UDP:=20 every 24-29 seconds, TCP: every 95-120 seconds) it would even be worse. = Your=20 battery would be depleted in about a day
 
Regards,
 
Jeroen
 
----- Original Message -----
From:=20 Christer Holmberg = (JO/LMF)=20
Sent: Wednesday, April 05, 2006 = 11:58=20 AM
Subject: [Sip] RE: Outbound: = Multiple=20 flows and forking


Hi,

One more thing about = mandating the=20 sending of REGISTERs to multiple proxies. To maintain a single = registration=20 flow will most likely have impacts on batteries in mobile devices, and = mandating to maintain multiple flows would have even bigger impacts. = So,=20 that's another reason I don't think it shall be mandated.

Regards,

Christer =


_____________________________________________=20
From:   = Christer Holmberg (JO/LMF)  =
Sent:   5.=20 huhtikuuta 2006 11:26
To:     sip@ietf.org
Subject:        = Outbound: Multiple flows and forking =


Hi,

A couple of issues on chapter = 4.2.

The text says:

"However, a UA MUST support sets with = at least two=20 outbound proxy URIs (primary and backup) and SHOULD support sets with = up to=20 four URIs.  For each

outbound proxy URI in the set, the UA = MUST send a=20 REGISTER in the normal way using this URI as the default outbound=20 proxy."

I don't think we should mandate this, = because it is=20 very much dependent on the architecture, transport techniques etc. =

Also, if the UA has registered multiple = flows,=20 should the registrar fork dialog initiation requests (addressed for = the UA) on=20 all of them? I realize it is an implementation issue, but I think it = would be=20 good to have some words about it in the draft, for example saying that = a=20 registrar may choose not to fork if the same instance-id is used for = multiple=20 bindings. Or something like that...

Regards,

Christer

_______________________________________________
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_0034_01C658B1.7930E120-- --===============2109998521== 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 --===============2109998521==-- From sip-bounces@ietf.org Wed Apr 05 07:06:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR5ot-0002Oy-Or; Wed, 05 Apr 2006 07:05:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR5os-0002Ot-GM for sip@ietf.org; Wed, 05 Apr 2006 07:05:02 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR5oq-0000cA-UA for sip@ietf.org; Wed, 05 Apr 2006 07:05:02 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9DFE24F0003 for ; Wed, 5 Apr 2006 10:26:18 +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, 5 Apr 2006 10:26:18 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 10:26:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Apr 2006 10:26:16 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1CA3@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Outbound: Multiple flows and forking Thread-Index: AcZYipuMuZenoSc3RB2Ae8gUfKD0rg== From: "Christer Holmberg \(JO/LMF\)" To: X-OriginalArrivalTime: 05 Apr 2006 08:26:18.0182 (UTC) FILETIME=[9C8C7660:01C6588A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Subject: [Sip] Outbound: Multiple flows and forking X-BeenThere: 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="===============1976684950==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1976684950== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6588A.9BADC19B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6588A.9BADC19B Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, A couple of issues on chapter 4.2. The text says: "However, a UA MUST support sets with at least two outbound proxy URIs (primary and backup) 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." I don't think we should mandate this, because it is very much dependent on the architecture, transport techniques etc.=20 Also, if the UA has registered multiple flows, should the registrar fork dialog initiation requests (addressed for the UA) on all of them? I realize it is an implementation issue, but I think it would be good to have some words about it in the draft, for example saying that a registrar may choose not to fork if the same instance-id is used for multiple bindings. Or something like that... Regards, Christer ------_=_NextPart_001_01C6588A.9BADC19B Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Outbound: Multiple flows and forking

Hi,

A couple of issues on chapter = 4.2.

The text says:

"However, a UA MUST support sets = with at least two outbound proxy URIs (primary and backup) 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."

I don't think we should mandate this, = because it is very much dependent on the architecture, transport = techniques etc.

Also, if the UA has registered multiple = flows, should the registrar fork dialog initiation requests (addressed = for the UA) on all of them? I realize it is an implementation issue, but = I think it would be good to have some words about it in the draft, for = example saying that a registrar may choose not to fork if the same = instance-id is used for multiple bindings. Or something like = that...

Regards,

Christer

------_=_NextPart_001_01C6588A.9BADC19B-- --===============1976684950== 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 --===============1976684950==-- From sip-bounces@ietf.org Wed Apr 05 07:27:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR69A-00032B-Un; Wed, 05 Apr 2006 07:26:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR699-000326-Vz for sip@ietf.org; Wed, 05 Apr 2006 07:25:59 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR698-0001vg-Ms for sip@ietf.org; Wed, 05 Apr 2006 07:25:59 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id D540C3BF09; Wed, 5 Apr 2006 13:25:57 +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 14267-01-26; Wed, 5 Apr 2006 13:25:57 +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 7F13D3BED9; Wed, 5 Apr 2006 13:25:57 +0200 (CEST) From: Fredrik Thulin To: sip@ietf.org Subject: Re: [Sip] Outbound: Multiple flows and forking Date: Wed, 5 Apr 2006 13:25:54 +0200 User-Agent: KMail/1.9.1 References: <5EB80D22825EEE42872083AD5BFFB5945D1CA3@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1CA3@esealmw113.eemea.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200604051325.54478.ft@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.501 tagged_above=-99 required=7 tests=[AWL=0.164, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: "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 Wednesday 05 April 2006 10:26, Christer Holmberg (JO/LMF) wrote: ... > Also, if the UA has registered multiple flows, should the registrar > fork dialog initiation requests (addressed for the UA) on all of > them? I realize it is an implementation issue, but I think it would > be good to have some words about it in the draft, for example saying > that a registrar may choose not to fork if the same instance-id is > used for multiple bindings. Or something like that... It does say. 6.2 Forwarding Requests When a proxy uses the location service to look up a registration binding and then proxies a request to a particular contact, it selects a contact to use normally, with a few additional rules: o The proxy MUST NOT populate the target set with more than one contact with the same AOR and instance-id at a time. If a request for a particular AOR and instance-id fails with a 410 response, the proxy SHOULD replace the failed branch with another target (if one is available) with the same AOR and instance-id, but a different reg-id. o If two bindings have the same instance-id and reg-id, the proxy SHOULD prefer the contact that was most recently updated. The suitability of responding 410 here has already been questioned on the list (Adam Roach, 2006-03-18, subject "[Sip] Outbound and 410"). /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 Apr 05 07:45:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR6QZ-0001L3-PN; Wed, 05 Apr 2006 07:43:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR6QX-0001Ky-VH for sip@ietf.org; Wed, 05 Apr 2006 07:43:57 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR6QX-0002KM-2I for sip@ietf.org; Wed, 05 Apr 2006 07:43:57 -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 k35BgYCn020911; Wed, 5 Apr 2006 14:42:36 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 14:43:54 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 14:43:53 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] RE: Outbound: Multiple flows and forking Date: Wed, 5 Apr 2006 14:43:54 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0229A8E0@esebe103.NOE.Nokia.com> In-Reply-To: <003701c658a0$b5ded890$31713b51@BEMBUSTER> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Outbound: Multiple flows and forking Thread-Index: AcZYoNj6054HIKg6R+SZzNE1/RUCdwAApPvA From: To: , , X-OriginalArrivalTime: 05 Apr 2006 11:43:53.0958 (UTC) FILETIME=[37245060:01C658A6] X-Spam-Score: 0.2 (/) X-Scan-Signature: e3901bdd61b234d82da85cc76f05a7e8 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="===============1889169919==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1889169919== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C658A6.3771919B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C658A6.3771919B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 While the referred estimates give an idea about the impact of keepalives when using certain cellular technologies, the mobile devices might as well use WLAN. In that case the impact for battery lifetime is much less dramatic, but not negligible. So mobile devices might well use outbound, but still like to minimize the flows to be kept alive. =20 I would also request to downgrade the requirement as follows: =20 "However, a UA SHOULD support sets with at least two outbound proxy URIs (primary and backup) and MAY support sets with up to four URIs." =20 Otherwise the spec would be too stringent for some environments. I can=20 also imagine certain cases where only one single proxy is available due to cost=20 or other architectural reasons. While not ideal, I would not like ban a mobile=20 service provider or a small company to apply outbound with one single proxy=20 only and cope with UAs supporting a single proxy only. The spec could=20 however be explicit on mentioning the limitations or risks caused by doing so. =20 Regards, =20 Erkki ________________________________ From: ext Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 Sent: 05.April.2006 14:04 To: Christer Holmberg (JO/LMF); sip@ietf.org Subject: Re: [Sip] RE: Outbound: Multiple flows and forking =09 =09 Christer, =20 I wouldn't recommend using outbound for mobile devices in the first place =20 In http://www.ietf.org/internet-drafts/draft-brok-simple-regulate-publish-0 2.txt section 2.2 there are some estimates for the effect of periodic transmissions on the battery lifetime. This is for periodic PUBLISH, for periodic keepalive (UDP: every 24-29 seconds, TCP: every 95-120 seconds) it would even be worse. Your battery would be depleted in about a day =20 Regards, =20 Jeroen =20 ----- Original Message -----=20 From: Christer Holmberg (JO/LMF) =20 To: sip@ietf.org=20 Sent: Wednesday, April 05, 2006 11:58 AM Subject: [Sip] RE: Outbound: Multiple flows and forking Hi,=20 One more thing about mandating the sending of REGISTERs to multiple proxies. To maintain a single registration flow will most likely have impacts on batteries in mobile devices, and mandating to maintain multiple flows would have even bigger impacts. So, that's another reason I don't think it shall be mandated. Regards,=20 Christer=20 _____________________________________________=20 From: Christer Holmberg (JO/LMF) =20 Sent: 5. huhtikuuta 2006 11:26=20 To: sip@ietf.org=20 Subject: Outbound: Multiple flows and forking=20 Hi,=20 A couple of issues on chapter 4.2.=20 The text says:=20 "However, a UA MUST support sets with at least two outbound proxy URIs (primary and backup) 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." I don't think we should mandate this, because it is very much dependent on the architecture, transport techniques etc.=20 Also, if the UA has registered multiple flows, should the registrar fork dialog initiation requests (addressed for the UA) on all of them? I realize it is an implementation issue, but I think it would be good to have some words about it in the draft, for example saying that a registrar may choose not to fork if the same instance-id is used for multiple bindings. Or something like that... Regards,=20 Christer=20 =09 ________________________________ =09 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_01C658A6.3771919B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Outbound: Multiple flows and forking
Hi,
 
While the referred estimates give an idea about = the impact=20 of keepalives
when using certain cellular technologies, the = mobile=20 devices might as well
use WLAN. In that case the impact for battery = lifetime is=20 much less dramatic,
but not negligible. So mobile devices=20 might well use outbound, but still like
to minimize the flows to be kept = alive.
 
I would also request to downgrade the = requirement as=20 follows:
 
"However, a=20 UA SHOULD support sets with = at least=20 two outbound proxy URIs (primary and backup) and MAY support sets with up to four = URIs."
 
Otherwise the spec would be too stringent for = some=20 environments. I can
also imagine certain = cases where only=20 one single proxy is available due to cost=20
or=20 other architectural reasons. While not ideal, I would not = like ban a=20 mobile
service provider or a small company to = apply=20 outbound with one single proxy=20
only=20 and cope with UAs supporting a single proxy only. The spec could=20
however be explicit on = mentioning the=20 limitations or risks caused by doing=20 so.
 
Regards,
 
Erkki

From: ext Jeroen van Bemmel=20 [mailto:jbemmel@zonnet.nl]
Sent: 05.April.2006 = 14:04
To:=20 Christer Holmberg (JO/LMF); sip@ietf.org
Subject: Re: [Sip] = RE:=20 Outbound: Multiple flows and forking

Christer,
 
I wouldn't recommend using outbound = for mobile=20 devices in the first place
 
In http://www.ietf.org/internet-drafts/draft-brok-simple-regul= ate-publish-02.txt section=20 2.2 there are some estimates for the effect of periodic transmissions = on the=20 battery lifetime. This is for periodic PUBLISH, for periodic keepalive = (UDP:=20 every 24-29 seconds, TCP: every 95-120 seconds) it would even be = worse. Your=20 battery would be depleted in about a day
 
Regards,
 
Jeroen
 
----- Original Message -----
From:=20 Christer Holmberg = (JO/LMF)=20
Sent: Wednesday, April 05, = 2006 11:58=20 AM
Subject: [Sip] RE: Outbound: = Multiple=20 flows and forking


Hi,

One more thing about = mandating the=20 sending of REGISTERs to multiple proxies. To maintain a single = registration=20 flow will most likely have impacts on batteries in mobile devices, = and=20 mandating to maintain multiple flows would have even bigger impacts. = So,=20 that's another reason I don't think it shall be mandated.

Regards,

Christer =


_____________________________________________=20
From:   = Christer Holmberg (JO/LMF)  =
Sent:   5.=20 huhtikuuta 2006 11:26
To:     sip@ietf.org
Subject:        = Outbound: Multiple flows and forking =


Hi,

A couple of issues on chapter = 4.2.

The text says:

"However, a UA MUST support sets with = at least=20 two outbound proxy URIs (primary and backup) and SHOULD support sets = with up=20 to four URIs.  For each

outbound proxy URI in the set, the UA = MUST send a=20 REGISTER in the normal way using this URI as the default outbound=20 proxy."

I don't think we should mandate this, = because it=20 is very much dependent on the architecture, transport techniques = etc.=20

Also, if the UA has registered = multiple flows,=20 should the registrar fork dialog initiation requests (addressed for = the UA)=20 on all of them? I realize it is an implementation issue, but I think = it=20 would be good to have some words about it in the draft, for example = saying=20 that a registrar may choose not to fork if the same instance-id is = used for=20 multiple bindings. Or something like that...

Regards,

Christer

_______________________________________________
Sip = mailing=20 list  https://www1.ietf.org/mailman/listinfo/sip
This list = is for=20 NEW development of the core SIP Protocol
Use=20 sip-implementors@cs.columbia.edu for questions on current sip
Use = sipping@ietf.org for new developments on the application of=20 sip
------_=_NextPart_001_01C658A6.3771919B-- --===============1889169919== 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 --===============1889169919==-- From sip-bounces@ietf.org Wed Apr 05 08:22:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR700-0004bf-IL; Wed, 05 Apr 2006 08:20:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR6zy-0004bZ-SJ for sip@ietf.org; Wed, 05 Apr 2006 08:20:34 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR6zx-0003fu-MQ for sip@ietf.org; Wed, 05 Apr 2006 08:20:34 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EA0FBDD8; Wed, 5 Apr 2006 14:20:32 +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, 5 Apr 2006 14:20:32 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 14:20:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] RE: Outbound: Multiple flows and forking Date: Wed, 5 Apr 2006 14:20:31 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1CB6@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Outbound: Multiple flows and forking Thread-Index: AcZYoNj6054HIKg6R+SZzNE1/RUCdwAApPvAAAGzeEA= From: "Christer Holmberg \(JO/LMF\)" To: , , X-OriginalArrivalTime: 05 Apr 2006 12:20:32.0338 (UTC) FILETIME=[557A7B20:01C658AB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8e9fbe727bc2159b431d624c595c1eab 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="===============0946694490==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0946694490== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C658AB.550D0753" This is a multi-part message in MIME format. ------_=_NextPart_001_01C658AB.550D0753 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, =20 I agree with Erkki - mobile devices may well use outbound. =20 However, to comment Erikki's new text proposal: I don't think the main issue how many outbuond proxies the UA is mandated to support, but that fact that the UA MUST send a REGISTER to each of them. I think the UA should be allowed to send a REGISTER with only one of the outbound proxies. If we think that may cause problems we can always RECOMMEND sending REGISTER to multiple outbound proxies. =20 Also, we talk about "outbound proxy URIs". Are we sure that the UA will always have the outbound proxy in a form of a URI? =20 Regards, =20 Christer =20 =20 ________________________________ From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com]=20 Sent: 5. huhtikuuta 2006 14:44 To: jbemmel@zonnet.nl; Christer Holmberg (JO/LMF); sip@ietf.org Subject: RE: [Sip] RE: Outbound: Multiple flows and forking Hi, =20 While the referred estimates give an idea about the impact of keepalives when using certain cellular technologies, the mobile devices might as well use WLAN. In that case the impact for battery lifetime is much less dramatic, but not negligible. So mobile devices might well use outbound, but still like to minimize the flows to be kept alive. =20 I would also request to downgrade the requirement as follows: =20 "However, a UA SHOULD support sets with at least two outbound proxy URIs (primary and backup) and MAY support sets with up to four URIs." =20 Otherwise the spec would be too stringent for some environments. I can=20 also imagine certain cases where only one single proxy is available due to cost=20 or other architectural reasons. While not ideal, I would not like ban a mobile=20 service provider or a small company to apply outbound with one single proxy=20 only and cope with UAs supporting a single proxy only. The spec could=20 however be explicit on mentioning the limitations or risks caused by doing so. =20 Regards, =20 Erkki ________________________________ From: ext Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 Sent: 05.April.2006 14:04 To: Christer Holmberg (JO/LMF); sip@ietf.org Subject: Re: [Sip] RE: Outbound: Multiple flows and forking =09 =09 Christer, =20 I wouldn't recommend using outbound for mobile devices in the first place =20 In http://www.ietf.org/internet-drafts/draft-brok-simple-regulate-publish-0 2.txt section 2.2 there are some estimates for the effect of periodic transmissions on the battery lifetime. This is for periodic PUBLISH, for periodic keepalive (UDP: every 24-29 seconds, TCP: every 95-120 seconds) it would even be worse. Your battery would be depleted in about a day =20 Regards, =20 Jeroen =20 ----- Original Message -----=20 From: Christer Holmberg (JO/LMF) =20 To: sip@ietf.org=20 Sent: Wednesday, April 05, 2006 11:58 AM Subject: [Sip] RE: Outbound: Multiple flows and forking =09 =09 Hi,=20 One more thing about mandating the sending of REGISTERs to multiple proxies. To maintain a single registration flow will most likely have impacts on batteries in mobile devices, and mandating to maintain multiple flows would have even bigger impacts. So, that's another reason I don't think it shall be mandated. Regards,=20 Christer=20 _____________________________________________=20 From: Christer Holmberg (JO/LMF) =20 Sent: 5. huhtikuuta 2006 11:26=20 To: sip@ietf.org=20 Subject: Outbound: Multiple flows and forking=20 Hi,=20 A couple of issues on chapter 4.2.=20 The text says:=20 "However, a UA MUST support sets with at least two outbound proxy URIs (primary and backup) 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." I don't think we should mandate this, because it is very much dependent on the architecture, transport techniques etc.=20 Also, if the UA has registered multiple flows, should the registrar fork dialog initiation requests (addressed for the UA) on all of them? I realize it is an implementation issue, but I think it would be good to have some words about it in the draft, for example saying that a registrar may choose not to fork if the same instance-id is used for multiple bindings. Or something like that... Regards,=20 Christer=20 =09 =09 ________________________________ =09 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_01C658AB.550D0753 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: Outbound: Multiple flows and forking
Hi,
 
I=20 agree with Erkki - mobile devices may well use = outbound.
 
However, to comment Erikki's new text = proposal: I don't=20 think the main issue how many outbuond proxies the UA is mandated=20 to support, but that fact that the UA MUST send a REGISTER to each = of them.=20 I think the UA should be allowed to send a REGISTER with only one of the = outbound proxies. If we think that may cause problems we can always = RECOMMEND=20 sending REGISTER to multiple outbound proxies.
 
Also,=20 we talk about "outbound proxy URIs". Are we sure that the UA will always = have=20 the outbound proxy in a form of a URI?
 
Regards,
 
Christer
 
 

From: Erkki.Koivusalo@nokia.com=20 [mailto:Erkki.Koivusalo@nokia.com]
Sent: 5. huhtikuuta 2006=20 14:44
To: jbemmel@zonnet.nl; Christer Holmberg (JO/LMF);=20 sip@ietf.org
Subject: RE: [Sip] RE: Outbound: Multiple flows = and=20 forking

Hi,
 
While the referred estimates give an idea about = the impact=20 of keepalives
when using certain cellular technologies, the = mobile=20 devices might as well
use WLAN. In that case the impact for battery = lifetime is=20 much less dramatic,
but not negligible. So mobile devices=20 might well use outbound, but still like
to minimize the flows to be kept = alive.
 
I would also request to downgrade the = requirement as=20 follows:
 
"However, a=20 UA SHOULD support sets with = at least=20 two outbound proxy URIs (primary and backup) and MAY support sets with up to four = URIs."
 
Otherwise the spec would be too stringent for = some=20 environments. I can
also imagine certain = cases where only=20 one single proxy is available due to cost=20
or=20 other architectural reasons. While not ideal, I would not = like ban a=20 mobile
service provider or a small company to = apply=20 outbound with one single proxy=20
only=20 and cope with UAs supporting a single proxy only. The spec could=20
however be explicit on = mentioning the=20 limitations or risks caused by doing=20 so.
 
Regards,
 
Erkki

From: ext Jeroen van Bemmel=20 [mailto:jbemmel@zonnet.nl]
Sent: 05.April.2006 = 14:04
To:=20 Christer Holmberg (JO/LMF); sip@ietf.org
Subject: Re: [Sip] = RE:=20 Outbound: Multiple flows and forking

Christer,
 
I wouldn't recommend using outbound = for mobile=20 devices in the first place
 
In http://www.ietf.org/internet-drafts/draft-brok-simple-regul= ate-publish-02.txt section=20 2.2 there are some estimates for the effect of periodic transmissions = on the=20 battery lifetime. This is for periodic PUBLISH, for periodic keepalive = (UDP:=20 every 24-29 seconds, TCP: every 95-120 seconds) it would even be = worse. Your=20 battery would be depleted in about a day
 
Regards,
 
Jeroen
 
----- Original Message -----
From:=20 Christer Holmberg = (JO/LMF)=20
Sent: Wednesday, April 05, = 2006 11:58=20 AM
Subject: [Sip] RE: Outbound: = Multiple=20 flows and forking


Hi,

One more thing about = mandating the=20 sending of REGISTERs to multiple proxies. To maintain a single = registration=20 flow will most likely have impacts on batteries in mobile devices, = and=20 mandating to maintain multiple flows would have even bigger impacts. = So,=20 that's another reason I don't think it shall be mandated.

Regards,

Christer =


_____________________________________________=20
From:   = Christer Holmberg (JO/LMF)  =
Sent:   5.=20 huhtikuuta 2006 11:26
To:     sip@ietf.org
Subject:        = Outbound: Multiple flows and forking =


Hi,

A couple of issues on chapter = 4.2.

The text says:

"However, a UA MUST support sets with = at least=20 two outbound proxy URIs (primary and backup) and SHOULD support sets = with up=20 to four URIs.  For each

outbound proxy URI in the set, the UA = MUST send a=20 REGISTER in the normal way using this URI as the default outbound=20 proxy."

I don't think we should mandate this, = because it=20 is very much dependent on the architecture, transport techniques = etc.=20

Also, if the UA has registered = multiple flows,=20 should the registrar fork dialog initiation requests (addressed for = the UA)=20 on all of them? I realize it is an implementation issue, but I think = it=20 would be good to have some words about it in the draft, for example = saying=20 that a registrar may choose not to fork if the same instance-id is = used for=20 multiple bindings. Or something like that...

Regards,

Christer

_______________________________________________
Sip = mailing=20 list  https://www1.ietf.org/mailman/listinfo/sip
This list = is for=20 NEW development of the core SIP Protocol
Use=20 sip-implementors@cs.columbia.edu for questions on current sip
Use = sipping@ietf.org for new developments on the application of=20 sip
------_=_NextPart_001_01C658AB.550D0753-- --===============0946694490== 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 --===============0946694490==-- From sip-bounces@ietf.org Wed Apr 05 08:44:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR7L4-0002a6-0p; Wed, 05 Apr 2006 08:42:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR7L3-0002a1-4Z for sip@ietf.org; Wed, 05 Apr 2006 08:42:21 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR7Ky-0004Yg-Ug for sip@ietf.org; Wed, 05 Apr 2006 08:42:21 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k35CeTZ5017571; Wed, 5 Apr 2006 15:40:33 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 15:41:38 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 15:41:38 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] RE: Outbound: Multiple flows and forking Date: Wed, 5 Apr 2006 15:41:37 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0229A98C@esebe103.NOE.Nokia.com> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1CB6@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Outbound: Multiple flows and forking Thread-Index: AcZYoNj6054HIKg6R+SZzNE1/RUCdwAApPvAAAGzeEAAAORiwA== From: To: , , X-OriginalArrivalTime: 05 Apr 2006 12:41:38.0267 (UTC) FILETIME=[4807EAB0:01C658AE] X-Spam-Score: 0.2 (/) X-Scan-Signature: 2b428fb4265163ba7f2ac2af0ebfcf00 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="===============0957910982==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0957910982== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C658AE.478BD3C9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C658AE.478BD3C9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Christer, =20 Regarding to your proposal: Why would it be a MUST to the UA to support two outbound proxy URIs if it is legal to send a REGISTER to only one of them ? Why would the second URI be needed ? =20 In my text proposal the idea was that the UA would send REGISTER and create flow to as many outbound proxy URIs as the UA supports: 1, 2, 3 or 4. =20 If the UA only supports creating only one flow it could do it by supporting a proxy set with one single URI only. =20 Regards, =20 Erkki ________________________________ From: ext Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com]=20 Sent: 05.April.2006 15:21 To: Koivusalo Erkki (Nokia-TP/Helsinki); jbemmel@zonnet.nl; sip@ietf.org Subject: RE: [Sip] RE: Outbound: Multiple flows and forking =09 =09 Hi, =20 I agree with Erkki - mobile devices may well use outbound. =20 However, to comment Erikki's new text proposal: I don't think the main issue how many outbuond proxies the UA is mandated to support, but that fact that the UA MUST send a REGISTER to each of them. I think the UA should be allowed to send a REGISTER with only one of the outbound proxies. If we think that may cause problems we can always RECOMMEND sending REGISTER to multiple outbound proxies. =20 Also, we talk about "outbound proxy URIs". Are we sure that the UA will always have the outbound proxy in a form of a URI? =20 Regards, =20 Christer =20 =20 =09 =09 ________________________________ From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com]=20 Sent: 5. huhtikuuta 2006 14:44 To: jbemmel@zonnet.nl; Christer Holmberg (JO/LMF); sip@ietf.org Subject: RE: [Sip] RE: Outbound: Multiple flows and forking =09 =09 Hi, =20 While the referred estimates give an idea about the impact of keepalives when using certain cellular technologies, the mobile devices might as well use WLAN. In that case the impact for battery lifetime is much less dramatic, but not negligible. So mobile devices might well use outbound, but still like to minimize the flows to be kept alive. =20 I would also request to downgrade the requirement as follows: =20 "However, a UA SHOULD support sets with at least two outbound proxy URIs (primary and backup) and MAY support sets with up to four URIs." =20 Otherwise the spec would be too stringent for some environments. I can=20 also imagine certain cases where only one single proxy is available due to cost=20 or other architectural reasons. While not ideal, I would not like ban a mobile=20 service provider or a small company to apply outbound with one single proxy=20 only and cope with UAs supporting a single proxy only. The spec could=20 however be explicit on mentioning the limitations or risks caused by doing so. =20 Regards, =20 Erkki =09 =09 ________________________________ From: ext Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 Sent: 05.April.2006 14:04 To: Christer Holmberg (JO/LMF); sip@ietf.org Subject: Re: [Sip] RE: Outbound: Multiple flows and forking =09 =09 Christer, =20 I wouldn't recommend using outbound for mobile devices in the first place =20 In http://www.ietf.org/internet-drafts/draft-brok-simple-regulate-publish-0 2.txt section 2.2 there are some estimates for the effect of periodic transmissions on the battery lifetime. This is for periodic PUBLISH, for periodic keepalive (UDP: every 24-29 seconds, TCP: every 95-120 seconds) it would even be worse. Your battery would be depleted in about a day =20 Regards, =20 Jeroen =20 ----- Original Message -----=20 From: Christer Holmberg (JO/LMF) =20 To: sip@ietf.org=20 Sent: Wednesday, April 05, 2006 11:58 AM Subject: [Sip] RE: Outbound: Multiple flows and forking =09 =09 Hi,=20 One more thing about mandating the sending of REGISTERs to multiple proxies. To maintain a single registration flow will most likely have impacts on batteries in mobile devices, and mandating to maintain multiple flows would have even bigger impacts. So, that's another reason I don't think it shall be mandated. Regards,=20 Christer=20 _____________________________________________=20 From: Christer Holmberg (JO/LMF) =20 Sent: 5. huhtikuuta 2006 11:26=20 To: sip@ietf.org=20 Subject: Outbound: Multiple flows and forking=20 Hi,=20 A couple of issues on chapter 4.2.=20 The text says:=20 "However, a UA MUST support sets with at least two outbound proxy URIs (primary and backup) 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." I don't think we should mandate this, because it is very much dependent on the architecture, transport techniques etc.=20 Also, if the UA has registered multiple flows, should the registrar fork dialog initiation requests (addressed for the UA) on all of them? I realize it is an implementation issue, but I think it would be good to have some words about it in the draft, for example saying that a registrar may choose not to fork if the same instance-id is used for multiple bindings. Or something like that... Regards,=20 Christer=20 =09 =09 ________________________________ =09 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_01C658AE.478BD3C9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Outbound: Multiple flows and forking
Hi Christer,
 
Regarding to your proposal: Why would it be a = MUST to the=20 UA to support two outbound proxy
URIs if it is legal to send a REGISTER to only = one of them=20 ? Why would the second URI be needed ?
 
In my text proposal the idea was that the UA = would send=20 REGISTER and create flow to as many
outbound proxy URIs as the UA supports: 1, 2, 3 = or=20 4.
 
If the UA only supports creating only one flow = it could do=20 it by supporting a proxy set with one
single URI only.
 
Regards,
 
Erkki

From: ext Christer Holmberg = (JO/LMF)=20 [mailto:christer.holmberg@ericsson.com]
Sent: 05.April.2006 = 15:21
To: Koivusalo Erkki (Nokia-TP/Helsinki); = jbemmel@zonnet.nl;=20 sip@ietf.org
Subject: RE: [Sip] RE: Outbound: Multiple flows = and=20 forking

Hi,
 
I=20 agree with Erkki - mobile devices may well use = outbound.
 
However, to comment Erikki's new text = proposal: I=20 don't think the main issue how many outbuond proxies the UA is = mandated=20 to support, but that fact that the UA MUST send a REGISTER to = each of=20 them. I think the UA should be allowed to send a REGISTER with only = one of the=20 outbound proxies. If we think that may cause problems we can always = RECOMMEND=20 sending REGISTER to multiple outbound proxies.
 
Also, we talk about "outbound proxy URIs". = Are we=20 sure that the UA will always have the outbound proxy in a form of a=20 URI?
 
Regards,
 
Christer
 
 

From: Erkki.Koivusalo@nokia.com=20 [mailto:Erkki.Koivusalo@nokia.com]
Sent: 5. huhtikuuta 2006 = 14:44
To: jbemmel@zonnet.nl; Christer Holmberg (JO/LMF);=20 sip@ietf.org
Subject: RE: [Sip] RE: Outbound: Multiple flows = and=20 forking

Hi,
 
While the referred estimates give an idea = about the=20 impact of keepalives
when using certain cellular technologies, the = mobile=20 devices might as well
use WLAN. In that case the impact for battery = lifetime is=20 much less dramatic,
but not negligible. So mobile=20 devices might well use outbound, but still like
to minimize the flows to be kept=20 alive.
 
I would also request to downgrade the = requirement as=20 follows:
 
"However,=20 a UA SHOULD support sets = with at=20 least two outbound proxy URIs (primary and backup) and MAY support sets with up to four = URIs."
 
Otherwise the spec would be too stringent = for some=20 environments. I can
also imagine certain = cases where only=20 one single proxy is available due to cost=20
or=20 other architectural reasons. While not ideal, I = would not=20 like ban a mobile
service provider or a small company to = apply=20 outbound with one single proxy =
only=20 and cope with UAs supporting a single proxy only. The spec could=20
however be explicit on = mentioning the=20 limitations or risks caused by doing=20 so.
 
Regards,
 
Erkki

From: ext Jeroen van Bemmel=20 [mailto:jbemmel@zonnet.nl]
Sent: 05.April.2006=20 14:04
To: Christer Holmberg (JO/LMF);=20 sip@ietf.org
Subject: Re: [Sip] RE: Outbound: Multiple = flows and=20 forking

Christer,
 
I wouldn't recommend using outbound = for mobile=20 devices in the first place
 
In http://www.ietf.org/internet-drafts/draft-brok-simple-regul= ate-publish-02.txt section=20 2.2 there are some estimates for the effect of periodic = transmissions on the=20 battery lifetime. This is for periodic PUBLISH, for periodic = keepalive (UDP:=20 every 24-29 seconds, TCP: every 95-120 seconds) it would even be = worse. Your=20 battery would be depleted in about a day
 
Regards,
 
Jeroen
 
----- Original Message ----- =
From:=20 Christer Holmberg=20 (JO/LMF)
Sent: Wednesday, April 05, = 2006 11:58=20 AM
Subject: [Sip] RE: = Outbound: Multiple=20 flows and forking


Hi,

One more thing = about mandating=20 the sending of REGISTERs to multiple proxies. To maintain a single = registration flow will most likely have impacts on batteries in = mobile=20 devices, and mandating to maintain multiple flows would have even = bigger=20 impacts. So, that's another reason I don't think it shall be=20 mandated.

Regards, =

Christer =


_____________________________________________=20
From:   = Christer Holmberg (JO/LMF)  =
Sent:   5. huhtikuuta 2006 11:26
To:     sip@ietf.org
Subject:        = Outbound: Multiple flows and forking =


Hi,

A couple of issues on chapter = 4.2.

The text says:

"However, a UA MUST support sets = with at least=20 two outbound proxy URIs (primary and backup) and SHOULD support = sets with=20 up to four URIs.  For each

outbound proxy URI in the set, the = UA MUST send=20 a REGISTER in the normal way using this URI as the default = outbound=20 proxy."

I don't think we should mandate = this, because=20 it is very much dependent on the architecture, transport = techniques etc.=20

Also, if the UA has registered = multiple flows,=20 should the registrar fork dialog initiation requests (addressed = for the=20 UA) on all of them? I realize it is an implementation issue, but I = think=20 it would be good to have some words about it in the draft, for = example=20 saying that a registrar may choose not to fork if the same = instance-id is=20 used for multiple bindings. Or something like that...

Regards,

Christer

_______________________________________________
Sip = mailing=20 list  https://www1.ietf.org/mailman/listinfo/sip
This list = is for=20 NEW development of the core SIP Protocol
Use=20 sip-implementors@cs.columbia.edu for questions on current = sip
Use=20 sipping@ietf.org for new developments on the application of=20 sip
------_=_NextPart_001_01C658AE.478BD3C9-- --===============0957910982== 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 --===============0957910982==-- From sip-bounces@ietf.org Wed Apr 05 08:51:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR7SW-0003BL-P1; Wed, 05 Apr 2006 08:50:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR7SW-0003BG-0p for sip@ietf.org; Wed, 05 Apr 2006 08:50:04 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR7SU-0004gF-4I for sip@ietf.org; Wed, 05 Apr 2006 08:50:04 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IX900B012C8XO@siemenscomms.co.uk> for sip@ietf.org; Wed, 05 Apr 2006 13:50:33 +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 <0IX900AAR2C8DK@siemenscomms.co.uk>; Wed, 05 Apr 2006 13:50:32 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 05 Apr 2006 13:50:00 +0100 Content-return: allowed Date: Wed, 05 Apr 2006 13:49:39 +0100 From: "Elwell, John" Subject: RE: [Sip] Connected-identity and changing the To header field in aresponse To: Roland Jesske , "Peterson, Jon" , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670896A0B5@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.5 (/) X-Scan-Signature: 9c7d7a899dc8f3389bf7ace6f0ad8e29 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 Roland, Well, I don't want to get into a long discussion about what RFC3325 = allows or disallows. It appears that current practice supports the point I am trying to make - if you don't need a cryptographically authenticated response identity, then PAI is sufficient within trusted environments, provided you have some means of authenticating the responding UA (since = the UA will be outside the trusted environment). If you say that TLS is not used, what is used instead? John > -----Original Message----- > From: Roland Jesske [mailto:roland.jesske@web.de]=20 > Sent: 05 April 2006 09:02 > To: Elwell, John; Peterson, Jon; sip@ietf.org > Subject: RE: [Sip] Connected-identity and changing the To=20 > header field in aresponse >=20 > John, > You wrote:=20 > >Unfortunately RFC3325 is unclear on the use of PAI in=20 > responses, although in practice I think it is used and is=20 > probably OK if >the last hop is secured by TLS so that=20 > previous authentication of the UAS can be relied on for=20 > making the assertion. >=20 > You aready quoted in a Mail 2. January 2006 the use of PAI in=20 > responses as written within RFC3324. >=20 > Again RFC 3324 says: > 5. Parties with Network Asserted Identities >=20 > A Network Asserted Identity identifies the originator of=20 > the message > in which it was received. >=20 > For example, >=20 > a Network Asserted Identity received in an initial=20 > INVITE (outside > the context of any existing dialog) identifies the=20 > calling party. >=20 > a Network Asserted Identity received in a 180 Ringing=20 > response to > such an INVITE identifies the party who is ringing. >=20 > a Network Asserted Identity received in a 200 response=20 > to such an > INVITE identifies the party who has answered. >=20 >=20 > Also in RFC 3325 the use is allowed as follows: >=20 > This document adds the following entry to Table 2 of [1]: >=20 > Header field where proxy ACK BYE CAN INV=20 > OPT REG > ------------ ----- ----- --- --- --- ---=20 > --- --- > P-Asserted-Identity adr - o - o o = - >=20 > A=3D > SUB NOT REF INF=20 > UPD PRA > --- --- --- ---=20 > --- --- > o o o - - = - >=20 > Is this all wrong now? Is it forbidden to use a=20 > P-Asserted-Identity in Responses. >=20 > The 3GPP and TISPAN IMS are using the P-Asserted-Identity in=20 > Responses and it is not forced to use TLS.=20 >=20 > Is this all now wrong? >=20 > Best Regards >=20 > Roland > > -----Urspr=FCngliche Nachricht----- > > Von: "Elwell, John" > > Gesendet: 05.04.06 09:07:07 > > An: sip@ietf.org > > Betreff: RE: [Sip] Connected-identity and changing the To=20 > header field in aresponse >=20 >=20 > > Jon, > >=20 > > =20 > >=20 > > Thanks for this excellent summary of the issue, which I=20 > fully agree with and which unfortunately seems to need=20 > restating at regular intervals. It appears that the chief=20 > motivation of those asking for something in the response is=20 > to facilitate interworking with PSTN (by including it in the=20 > 200 response so that it can be mapped directly to the PSTN=20 > "connected" message). As you say, such a response is always=20 > going to be unauthenticated, and I don't think that meets the=20 > requirements of PSTN interworking. Far better to figure out a=20 > way of using an authenticated connected identity in an UPDATE=20 > message for mapping to PSTN connected identity. > >=20 > > =20 > >=20 > > Of course, in trusted networks there may be other means for=20 > ensuring the authenticity of an identity in a response, just=20 > as there is in a request using P-Asserted-Identity.=20 > Unfortunately RFC3325 is unclear on the use of PAI in=20 > responses, although in practice I think it is used and is=20 > probably OK if the last hop is secured by TLS so that=20 > previous authentication of the UAS can be relied on for=20 > making the assertion. I think if those trusted networks=20 > really need a solution for response identity, PAI would be a=20 > better avenue to explore (taking into account the risks). But=20 > not for the Internet. I am becoming more and more convinced=20 > that diluting the connected-identity draft with a weak=20 > solution for response identity would be the wrong way to go. > >=20 > > =20 > >=20 > > John > > =20 > > =20 > > ----------------------------------------------------------------- > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz]=20 > > Sent: 05 April 2006 02:05 > > To: Elwell, John; sip@ietf.org > > Subject: RE: [Sip] Connected-identity and changing the To=20 > header field in aresponse > >=20 > > =20 > > =20 > > Yes, I was asked for clarification on this point after the=20 > meeting, and I'll be providing it here. As you surmised, it=20 > is not that RFC3261 relies on the addr-spec of the To or From=20 > header field for transaction identification, or something. In=20 > fact, I would have essentially the same concerns about any=20 > proposal that provided an additional header (say, a=20 > 'Connected-Party' header) in responses to dialog-forming=20 > requests which was understood to clobber the To header field=20 > and identify the AoR of the party who was reached after=20 > retargeting of the request took place. > > =20 > > =20 > > =20 > > Starting with the goals of this approach: what sort of UAC=20 > decisions or behavior do we hope to enable through sending a=20 > response with a modified To header field? As far as I can=20 > understand, we either want to render this AoR to the user of=20 > a UAC (so the user can react in one way or another), or input=20 > the AoR to some sort of policy manager (e.g.=20 > blacklist/whitelist) that might make a decision about whether=20 > or not the session should continue -prior- to session=20 > establishment. If we don't care about this occurring prior to=20 > session establishment, of course, then we could go with the=20 > connected-identity draft as it is written today. > > =20 > > =20 > > =20 > > A little refresher on my sipping-retarget draft: The core=20 > problem with any scheme for connected party is figuring out=20 > how you'd decide whether or not a particular respondent is=20 > authorized. This is the argument of 2.2.1 of=20 > sipping-retarget, the "unanticipated respondent" problem.=20 > When we think about what sorts of policy decisions we expect=20 > a human or automata to make when receiving a response with=20 > identity information, we have to acknowledge that the UAC has=20 > no way of knowing which respondents are or are not authorized=20 > to respond to the request in question. Since the UAC has no=20 > insight into any retargeting that has taken place, the UAC=20 > has to assume that virtually any response is a potentially=20 > legitimate one. As such, there is little room for any=20 > meaningful policy decision when receiving a response. This=20 > problem is further compounded by the fact that the UAS may=20 > have several possible legitimate AoRs it could claim (I have=20 > a UA that registers its contact address under 3 separate SIP=20 > services simultaneously), and of course the fact that AoRs=20 > may be pretty uninformative (e.g.=20 > sip:user31@freesipservice.example.com), all of which=20 > complicate authorization decisions. Solving this problem is=20 > on the same footing as solving the request-history problem set. > > =20 > > =20 > > =20 > > With that background, the problems with providing this=20 > connected party information in responses (via the To header=20 > or what have you) are roughly as follows: > > =20 > > =20 > > =20 > > a) The "unanticipated respondent" problem is especially an=20 > issue for response identity because not all responses are=20 > success responses. If you end up connecting to a party > (receiving a 200), you can potentially rely on human factors=20 > to help you identify who you are talking to (after all, Carol=20 > can always answer Bob's phone regardless of who SIP thinks=20 > you connected to) and/or use the connected party information=20 > to change how you might address the party on the other side.=20 > With a 403 response, you are in a very different predicament=20 > - how is UAC or user behavior supposed to change based on the=20 > connected URI attributed to a 403, given the unanticipated=20 > respondent problem? For provisional responses, the issues=20 > become even worse - we then get into the wonders of forking,=20 > multiple provisional responses from multiple sources=20 > asserting different To header fields - in short, nothing=20 > which makes it any easier to render a "responding" AoR to a=20 > user, for example. Response identity, in so far as it deals=20 > with non-final, non-successful responses, opens up the=20 > "unconnected party" problem set. I think this is just the=20 > wrong framing of the problem. You want to know who you=20 > connected to, not who you didn't connect to. > > =20 > > =20 > > =20 > > b) Getting a signature over the To header field in=20 > responses would be difficult. In full awareness of Mr.=20 > Elwell's note below that certain parties are interested in=20 > "(unauthenticated) identity in a response", if this=20 > information is going to be put to any purpose, cause any=20 > change in human or UAC behavior, I have a hard time seeing=20 > how anyone could defend it being unsecured. If you want a=20 > human or an automata to make a policy decision based on the=20 > AoR in the To header field of the response, some sort of=20 > response identity signature would be necessary to prevent=20 > obvious impersonation attacks designed to thwart=20 > authorization decisions. With all due respect to the authors=20 > of draft-cao-sip-response-identity/auth, I'm not sure this=20 > problem is readily solved. Making sure that an appropriate=20 > authentication service is in the path of responses is=20 > problematic, since responses must traverse exactly the same=20 > path as requests. I played around with this a lot in the=20 > early phases of SIP identity, and at the end of the day, I=20 > had to conclude that the only way to make this work was to=20 > eliminate retargeting. Since providing connected-identity in=20 > responses assumes that retargeting has taken place, it=20 > wouldn't exactly be getting off on the right foot.=20 > Constraining inbound request routing to a domain such that=20 > responses will traverse an authentication service, or forcing=20 > a UAS to participate in the Identity scheme, is likely to=20 > require mandatory option-tags or comparable mechanisms that=20 > will limit the applicability of response identity and more or=20 > less eliminate its opportunistic use. > > =20 > > =20 > > =20 > > c) The inability to reject a response. Take the easiest=20 > case - let's say that the UAC receives a final success=20 > response, say a 200 response, with a modified To header field=20 > from a party that is blacklisted by UAC policy. What exactly=20 > is the UAC supposed to do? Send a 403? One cannot reject=20 > responses. Maybe a CANCEL? As section 9.1 of RFC3261 says,=20 > CANCEL "has no effect on requests that have already generated=20 > a final response." Drop the request on the floor? You'll just=20 > receive retransmissions. All you can do is ACK it, since the=20 > dialog has already been formed, and then send a BYE. In other=20 > words, a session -will- be established, there simply isn't an=20 > opportunity for policy to be put into effect prior to session=20 > establishment. Also, consider the need for the new responses=20 > defined in the sip-identity draft, like say the 438 response=20 > - if the UAC receives a 200 response with a potentially=20 > repairable error in the Identity header, how can it express=20 > that error to the UAS, since it can't send responses to a response? > > =20 > > =20 > > =20 > > Given the above, why does the UAC need to know who has been=20 > reached in the response, rather than in a request after the=20 > dialog has been formed? As (c) illustrates, in the 200=20 > response case a session will be established anyway, so=20 > sharing the identity of the connected party after session=20 > establishment doesn't actually miss some opportunity for=20 > applying policy - moreover, an UPDATE or similar request that=20 > provides the connected-identity information could be rejected=20 > by the session-originating UA in a manner that is helpful to=20 > the session-terminating UA (e.g., a 438 response could be=20 > sent). If we go with the mechanism in the connected-identity=20 > draft, problem (b) disappears, since request routing is far=20 > more malleable than response routing. Additionally, the=20 > connected-identity draft wisely does not attempt to solve=20 > "unconnected party" problems from (a), which are the least=20 > tractable of the unanticipated respondent problems. Rather,=20 > connected-identity provides an indication more along the=20 > lines of, "your dialog was established, however that might=20 > have happened, and this is who is on the other side". > > =20 > > =20 > > =20 > > Furthermore, any solution that tried to put the=20 > connected-identity information into responses would be=20 > providing an imprimatur of legitimacy to those responses -=20 > presuming they had a signature, UACs would validate it, and=20 > provided it checked out, they would be tempted say "this is a=20 > legitimate response." Nothing could be further from the=20 > truth, as sipping-retarget illustrates. Legitimacy of=20 > responses cannot be determined by UACs in the absence of=20 > something like request-history. > > =20 > > =20 > > =20 > > Finally, I like having one Identity header, and for the=20 > meaning of that Identity header to *always* be that it is a=20 > signature over the From header field issued by the domain=20 > identified by the host portion of the addr-spec of the From=20 > header field. The current connected-identity header draft=20 > provides that property. > > =20 > > =20 > > =20 > > Jon Peterson > > =20 > > NeuStar, Inc. > > =20 > > =20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: Monday, April 03, 2006 11:46 PM > > To: sip@ietf.org > > Subject: [Sip] Connected-identity and changing the To=20 > header field in aresponse > >=20 > > =20 > >=20 > > During discussion of draft-elwell-connected-identity in=20 > Dallas, somebody put forward the opinion that it would be=20 > dangerous to change the To header field URI in a response=20 > (i.e., make it different from the From header field URI in=20 > the request). My assumption at the time was that it would=20 > undermine the transaction concept in SIP, yet reading what=20 > RFC3261 has to say about transactions, the value of the To=20 > header field URI in a response does not appear to be involved=20 > in coupling a response to a request. Therefore I assume the=20 > person who indicated the danger (which was not challenged at=20 > the meeting) has other reasons in mind. I would greatly=20 > appreciate opinions on the wisdom or otherwise of allowing=20 > the To header field URI to change. It seems that from=20 > discussion of connected-identity there is a desire from some=20 > parts of the community to include an (unauthenticated)=20 > identity in a response. > > =20 > >=20 > > John=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 >=20 > _______________________________________________________________ > SMS schreiben mit WEB.DE FreeMail - einfach, schnell und > kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=3D021192 >=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 Apr 05 08:57:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR7Xq-00078l-KV; Wed, 05 Apr 2006 08:55:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR7Xp-00078g-1m for sip@ietf.org; Wed, 05 Apr 2006 08:55:33 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR7Xo-0004mz-AJ for sip@ietf.org; Wed, 05 Apr 2006 08:55:33 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IX900D012LF1M@siemenscomms.co.uk> for sip@ietf.org; Wed, 05 Apr 2006 13:56:03 +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 <0IX900C7X2LF50@siemenscomms.co.uk>; Wed, 05 Apr 2006 13:56:03 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 05 Apr 2006 13:55:30 +0100 Content-return: allowed Date: Wed, 05 Apr 2006 13:55:05 +0100 From: "Elwell, John" Subject: RE: [Sip] Connected-identity and changing the To header field ina response To: "Christer Holmberg (JO/LMF)" , "Peterson, Jon" , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670896A0CD@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.5 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 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 Christer, This "additional connected number" is not a requirement that I have been trying to address. Was this among the requirements that TISPAN brought into the IETF recently? John > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:christer.holmberg@ericsson.com] > Sent: 05 April 2006 08:34 > To: Elwell, John; Peterson, Jon; sip@ietf.org > Subject: RE: [Sip] Connected-identity and changing the To > header field inaresponse > > > Hi, > > In PSTN terms we are talking about that the TO header shall > be mapped to > the additional connected number, and that does NOT need to be > authorized > in the same way as the connected number. > > And, whether the interworking node sends this value to PSTN > is of course > based on local policy, based on trust etc. > > Regards, > > Christer > > > ________________________________ > > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: 5. huhtikuuta 2006 10:01 > To: Peterson, Jon; sip@ietf.org > Subject: RE: [Sip] Connected-identity and changing the To header field > inaresponse > > > Jon, > > Thanks for this excellent summary of the issue, which I fully > agree with > and which unfortunately seems to need restating at regular > intervals. It > appears that the chief motivation of those asking for something in the > response is to facilitate interworking with PSTN (by > including it in the > 200 response so that it can be mapped directly to the PSTN "connected" > message). As you say, such a response is always going to be > unauthenticated, and I don't think that meets the requirements of PSTN > interworking. Far better to figure out a way of using an authenticated > connected identity in an UPDATE message for mapping to PSTN connected > identity. > > Of course, in trusted networks there may be other means for > ensuring the > authenticity of an identity in a response, just as there is > in a request > using P-Asserted-Identity. Unfortunately RFC3325 is unclear on the use > of PAI in responses, although in practice I think it is used and is > probably OK if the last hop is secured by TLS so that previous > authentication of the UAS can be relied on for making the assertion. I > think if those trusted networks really need a solution for response > identity, PAI would be a better avenue to explore (taking into account > the risks). But not for the Internet. I am becoming more and more > convinced that diluting the connected-identity draft with a weak > solution for response identity would be the wrong way to go. > > John > > > ________________________________ > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: 05 April 2006 02:05 > To: Elwell, John; sip@ietf.org > Subject: RE: [Sip] Connected-identity and changing the To header > field in aresponse > > > Yes, I was asked for clarification on this point after the > meeting, and I'll be providing it here. As you surmised, it > is not that > RFC3261 relies on the addr-spec of the To or From header field for > transaction identification, or something. In fact, I would have > essentially the same concerns about any proposal that provided an > additional header (say, a 'Connected-Party' header) in responses to > dialog-forming requests which was understood to clobber the To header > field and identify the AoR of the party who was reached after > retargeting of the request took place. > > Starting with the goals of this approach: what sort of UAC > decisions or behavior do we hope to enable through sending a response > with a modified To header field? As far as I can understand, we either > want to render this AoR to the user of a UAC (so the user can react in > one way or another), or input the AoR to some sort of policy manager > (e.g. blacklist/whitelist) that might make a decision about whether or > not the session should continue -prior- to session > establishment. If we > don't care about this occurring prior to session establishment, of > course, then we could go with the connected-identity draft as it is > written today. > > A little refresher on my sipping-retarget draft: The core > problem with any scheme for connected party is figuring out how you'd > decide whether or not a particular respondent is authorized. > This is the > argument of 2.2.1 of sipping-retarget, the "unanticipated respondent" > problem. When we think about what sorts of policy decisions > we expect a > human or automata to make when receiving a response with identity > information, we have to acknowledge that the UAC has no way of knowing > which respondents are or are not authorized to respond to the > request in > question. Since the UAC has no insight into any retargeting that has > taken place, the UAC has to assume that virtually any response is a > potentially legitimate one. As such, there is little room for any > meaningful policy decision when receiving a response. This problem is > further compounded by the fact that the UAS may have several possible > legitimate AoRs it could claim (I have a UA that registers its contact > address under 3 separate SIP services simultaneously), and of > course the > fact that AoRs may be pretty uninformative (e.g. > sip:user31@freesipservice.example.com), all of which complicate > authorization decisions. Solving this problem is on the same > footing as > solving the request-history problem set. > > With that background, the problems with providing this connected > party information in responses (via the To header or what > have you) are > roughly as follows: > > a) The "unanticipated respondent" problem is especially an issue > for response identity because not all responses are success responses. > If you end up connecting to a party (receiving a 200), you can > potentially rely on human factors to help you identify who you are > talking to (after all, Carol can always answer Bob's phone > regardless of > who SIP thinks you connected to) and/or use the connected party > information to change how you might address the party on the > other side. > With a 403 response, you are in a very different predicament - how is > UAC or user behavior supposed to change based on the connected URI > attributed to a 403, given the unanticipated respondent problem? For > provisional responses, the issues become even worse - we then get into > the wonders of forking, multiple provisional responses from multiple > sources asserting different To header fields - in short, nothing which > makes it any easier to render a "responding" AoR to a user, > for example. > Response identity, in so far as it deals with non-final, > non-successful > responses, opens up the "unconnected party" problem set. I > think this is > just the wrong framing of the problem. You want to know who you > connected to, not who you didn't connect to. > > b) Getting a signature over the To header field in responses > would be difficult. In full awareness of Mr. Elwell's note below that > certain parties are interested in "(unauthenticated) identity in a > response", if this information is going to be put to any > purpose, cause > any change in human or UAC behavior, I have a hard time seeing how > anyone could defend it being unsecured. If you want a human or an > automata to make a policy decision based on the AoR in the To header > field of the response, some sort of response identity > signature would be > necessary to prevent obvious impersonation attacks designed to thwart > authorization decisions. With all due respect to the authors of > draft-cao-sip-response-identity/auth, I'm not sure this problem is > readily solved. Making sure that an appropriate authentication service > is in the path of responses is problematic, since responses must > traverse exactly the same path as requests. I played around > with this a > lot in the early phases of SIP identity, and at the end of the day, I > had to conclude that the only way to make this work was to eliminate > retargeting. Since providing connected-identity in responses assumes > that retargeting has taken place, it wouldn't exactly be > getting off on > the right foot. Constraining inbound request routing to a domain such > that responses will traverse an authentication service, or > forcing a UAS > to participate in the Identity scheme, is likely to require mandatory > option-tags or comparable mechanisms that will limit the applicability > of response identity and more or less eliminate its opportunistic use. > > c) The inability to reject a response. Take the easiest case - > let's say that the UAC receives a final success response, say a 200 > response, with a modified To header field from a party that is > blacklisted by UAC policy. What exactly is the UAC supposed > to do? Send > a 403? One cannot reject responses. Maybe a CANCEL? As section 9.1 of > RFC3261 says, CANCEL "has no effect on requests that have already > generated a final response." Drop the request on the floor? > You'll just > receive retransmissions. All you can do is ACK it, since the > dialog has > already been formed, and then send a BYE. In other words, a session > -will- be established, there simply isn't an opportunity for policy to > be put into effect prior to session establishment. Also, consider the > need for the new responses defined in the sip-identity draft, like say > the 438 response - if the UAC receives a 200 response with a > potentially > repairable error in the Identity header, how can it express that error > to the UAS, since it can't send responses to a response? > > Given the above, why does the UAC need to know who has been > reached in the response, rather than in a request after the dialog has > been formed? As (c) illustrates, in the 200 response case a > session will > be established anyway, so sharing the identity of the connected party > after session establishment doesn't actually miss some opportunity for > applying policy - moreover, an UPDATE or similar request that provides > the connected-identity information could be rejected by the > session-originating UA in a manner that is helpful to the > session-terminating UA (e.g., a 438 response could be sent). If we go > with the mechanism in the connected-identity draft, problem (b) > disappears, since request routing is far more malleable than response > routing. Additionally, the connected-identity draft wisely does not > attempt to solve "unconnected party" problems from (a), which are the > least tractable of the unanticipated respondent problems. Rather, > connected-identity provides an indication more along the > lines of, "your > dialog was established, however that might have happened, and this is > who is on the other side". > > Furthermore, any solution that tried to put the > connected-identity information into responses would be providing an > imprimatur of legitimacy to those responses - presuming they had a > signature, UACs would validate it, and provided it checked out, they > would be tempted say "this is a legitimate response." Nothing could be > further from the truth, as sipping-retarget illustrates. Legitimacy of > responses cannot be determined by UACs in the absence of > something like > request-history. > > Finally, I like having one Identity header, and for the meaning > of that Identity header to *always* be that it is a signature over the > From header field issued by the domain identified by the host > portion of > the addr-spec of the From header field. The current connected-identity > header draft provides that property. > > Jon Peterson > NeuStar, Inc. > > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Monday, April 03, 2006 11:46 PM > To: sip@ietf.org > Subject: [Sip] Connected-identity and changing the To > header field in aresponse > > > > During discussion of draft-elwell-connected-identity in > Dallas, somebody put forward the opinion that it would be dangerous to > change the To header field URI in a response (i.e., make it different > from the From header field URI in the request). My assumption at the > time was that it would undermine the transaction concept in SIP, yet > reading what RFC3261 has to say about transactions, the value > of the To > header field URI in a response does not appear to be involved in > coupling a response to a request. Therefore I assume the person who > indicated the danger (which was not challenged at the > meeting) has other > reasons in mind. I would greatly appreciate opinions on the wisdom or > otherwise of allowing the To header field URI to change. It seems that > from discussion of connected-identity there is a desire from > some parts > of the community to include an (unauthenticated) identity in > a response. > > 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 Apr 05 09:15:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR7pY-0002Au-Ej; Wed, 05 Apr 2006 09:13:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR7pX-00029x-76 for sip@ietf.org; Wed, 05 Apr 2006 09:13:51 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR7pV-0005eg-L8 for sip@ietf.org; Wed, 05 Apr 2006 09:13:51 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 211157AA; Wed, 5 Apr 2006 14:47:01 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 14:47:00 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 14:47:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] RE: Outbound: Multiple flows and forking Date: Wed, 5 Apr 2006 14:46:59 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1CBE@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Outbound: Multiple flows and forking Thread-Index: AcZYoNj6054HIKg6R+SZzNE1/RUCdwAApPvAAAGzeEAAAORiwAAAKolw From: "Christer Holmberg \(JO/LMF\)" To: , , X-OriginalArrivalTime: 05 Apr 2006 12:47:00.0094 (UTC) FILETIME=[07DAD1E0:01C658AF] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 466662da679e1d2dece19de64e166a5b 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="===============1027928828==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1027928828== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C658AF.07A29213" This is a multi-part message in MIME format. ------_=_NextPart_001_01C658AF.07A29213 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Erkki, =20 I don't think the UA MUST support two outbound proxy URIs, so I agree with your text change proposal. =20 What I meant was that the main issue is the fact that the UA MUST send REGISTER to all of the proxies. The number of URIs does not impact battery life, but the number of registration flows do :) =20 So, no matter how many outbound proxy URIs the UA supports, it should not be mandated to send REGISTER to all of them. =20 Regards, =20 Christer ________________________________ From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com]=20 Sent: 5. huhtikuuta 2006 15:42 To: Christer Holmberg (JO/LMF); jbemmel@zonnet.nl; sip@ietf.org Subject: RE: [Sip] RE: Outbound: Multiple flows and forking Hi Christer, =20 Regarding to your proposal: Why would it be a MUST to the UA to support two outbound proxy URIs if it is legal to send a REGISTER to only one of them ? Why would the second URI be needed ? =20 In my text proposal the idea was that the UA would send REGISTER and create flow to as many outbound proxy URIs as the UA supports: 1, 2, 3 or 4. =20 If the UA only supports creating only one flow it could do it by supporting a proxy set with one single URI only. =20 Regards, =20 Erkki ________________________________ From: ext Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com]=20 Sent: 05.April.2006 15:21 To: Koivusalo Erkki (Nokia-TP/Helsinki); jbemmel@zonnet.nl; sip@ietf.org Subject: RE: [Sip] RE: Outbound: Multiple flows and forking =09 =09 Hi, =20 I agree with Erkki - mobile devices may well use outbound. =20 However, to comment Erikki's new text proposal: I don't think the main issue how many outbuond proxies the UA is mandated to support, but that fact that the UA MUST send a REGISTER to each of them. I think the UA should be allowed to send a REGISTER with only one of the outbound proxies. If we think that may cause problems we can always RECOMMEND sending REGISTER to multiple outbound proxies. =20 Also, we talk about "outbound proxy URIs". Are we sure that the UA will always have the outbound proxy in a form of a URI? =20 Regards, =20 Christer =20 =20 =09 =09 ________________________________ From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com]=20 Sent: 5. huhtikuuta 2006 14:44 To: jbemmel@zonnet.nl; Christer Holmberg (JO/LMF); sip@ietf.org Subject: RE: [Sip] RE: Outbound: Multiple flows and forking =09 =09 Hi, =20 While the referred estimates give an idea about the impact of keepalives when using certain cellular technologies, the mobile devices might as well use WLAN. In that case the impact for battery lifetime is much less dramatic, but not negligible. So mobile devices might well use outbound, but still like to minimize the flows to be kept alive. =20 I would also request to downgrade the requirement as follows: =20 "However, a UA SHOULD support sets with at least two outbound proxy URIs (primary and backup) and MAY support sets with up to four URIs." =20 Otherwise the spec would be too stringent for some environments. I can=20 also imagine certain cases where only one single proxy is available due to cost=20 or other architectural reasons. While not ideal, I would not like ban a mobile=20 service provider or a small company to apply outbound with one single proxy=20 only and cope with UAs supporting a single proxy only. The spec could=20 however be explicit on mentioning the limitations or risks caused by doing so. =20 Regards, =20 Erkki =09 =09 ________________________________ From: ext Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 Sent: 05.April.2006 14:04 To: Christer Holmberg (JO/LMF); sip@ietf.org Subject: Re: [Sip] RE: Outbound: Multiple flows and forking =09 =09 Christer, =20 I wouldn't recommend using outbound for mobile devices in the first place =20 In http://www.ietf.org/internet-drafts/draft-brok-simple-regulate-publish-0 2.txt section 2.2 there are some estimates for the effect of periodic transmissions on the battery lifetime. This is for periodic PUBLISH, for periodic keepalive (UDP: every 24-29 seconds, TCP: every 95-120 seconds) it would even be worse. Your battery would be depleted in about a day =20 Regards, =20 Jeroen =20 ----- Original Message -----=20 From: Christer Holmberg (JO/LMF) =20 To: sip@ietf.org=20 Sent: Wednesday, April 05, 2006 11:58 AM Subject: [Sip] RE: Outbound: Multiple flows and forking =09 =09 Hi,=20 One more thing about mandating the sending of REGISTERs to multiple proxies. To maintain a single registration flow will most likely have impacts on batteries in mobile devices, and mandating to maintain multiple flows would have even bigger impacts. So, that's another reason I don't think it shall be mandated. Regards,=20 Christer=20 _____________________________________________=20 From: Christer Holmberg (JO/LMF) =20 Sent: 5. huhtikuuta 2006 11:26=20 To: sip@ietf.org=20 Subject: Outbound: Multiple flows and forking=20 Hi,=20 A couple of issues on chapter 4.2.=20 The text says:=20 "However, a UA MUST support sets with at least two outbound proxy URIs (primary and backup) 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." I don't think we should mandate this, because it is very much dependent on the architecture, transport techniques etc.=20 Also, if the UA has registered multiple flows, should the registrar fork dialog initiation requests (addressed for the UA) on all of them? I realize it is an implementation issue, but I think it would be good to have some words about it in the draft, for example saying that a registrar may choose not to fork if the same instance-id is used for multiple bindings. Or something like that... Regards,=20 Christer=20 =09 =09 ________________________________ =09 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_01C658AF.07A29213 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: Outbound: Multiple flows and forking
Hi=20 Erkki,
 
I=20 don't think the UA MUST support two outbound proxy URIs, so I agree with = your=20 text change proposal.
 
What I=20 meant was that the main issue is the fact that the UA MUST = send=20 REGISTER to all of the proxies. The number of URIs does not impact = battery life,=20 but the number of registration flows do :)
 
So, no=20 matter how many outbound proxy URIs the UA supports, it should not be = mandated=20 to send REGISTER to all of them.
 
Regards,
 
Christer

From: Erkki.Koivusalo@nokia.com=20 [mailto:Erkki.Koivusalo@nokia.com]
Sent: 5. huhtikuuta 2006=20 15:42
To: Christer Holmberg (JO/LMF); jbemmel@zonnet.nl;=20 sip@ietf.org
Subject: RE: [Sip] RE: Outbound: Multiple flows = and=20 forking

Hi Christer,
 
Regarding to your proposal: Why would it be a = MUST to the=20 UA to support two outbound proxy
URIs if it is legal to send a REGISTER to only = one of them=20 ? Why would the second URI be needed ?
 
In my text proposal the idea was that the UA = would send=20 REGISTER and create flow to as many
outbound proxy URIs as the UA supports: 1, 2, 3 = or=20 4.
 
If the UA only supports creating only one flow = it could do=20 it by supporting a proxy set with one
single URI only.
 
Regards,
 
Erkki

From: ext Christer Holmberg = (JO/LMF)=20 [mailto:christer.holmberg@ericsson.com]
Sent: 05.April.2006 = 15:21
To: Koivusalo Erkki (Nokia-TP/Helsinki); = jbemmel@zonnet.nl;=20 sip@ietf.org
Subject: RE: [Sip] RE: Outbound: Multiple flows = and=20 forking

Hi,
 
I=20 agree with Erkki - mobile devices may well use = outbound.
 
However, to comment Erikki's new text = proposal: I=20 don't think the main issue how many outbuond proxies the UA is = mandated=20 to support, but that fact that the UA MUST send a REGISTER to = each of=20 them. I think the UA should be allowed to send a REGISTER with only = one of the=20 outbound proxies. If we think that may cause problems we can always = RECOMMEND=20 sending REGISTER to multiple outbound proxies.
 
Also, we talk about "outbound proxy URIs". = Are we=20 sure that the UA will always have the outbound proxy in a form of a=20 URI?
 
Regards,
 
Christer
 
 

From: Erkki.Koivusalo@nokia.com=20 [mailto:Erkki.Koivusalo@nokia.com]
Sent: 5. huhtikuuta 2006 = 14:44
To: jbemmel@zonnet.nl; Christer Holmberg (JO/LMF);=20 sip@ietf.org
Subject: RE: [Sip] RE: Outbound: Multiple flows = and=20 forking

Hi,
 
While the referred estimates give an idea = about the=20 impact of keepalives
when using certain cellular technologies, the = mobile=20 devices might as well
use WLAN. In that case the impact for battery = lifetime is=20 much less dramatic,
but not negligible. So mobile=20 devices might well use outbound, but still like
to minimize the flows to be kept=20 alive.
 
I would also request to downgrade the = requirement as=20 follows:
 
"However,=20 a UA SHOULD support sets = with at=20 least two outbound proxy URIs (primary and backup) and MAY support sets with up to four = URIs."
 
Otherwise the spec would be too stringent = for some=20 environments. I can
also imagine certain = cases where only=20 one single proxy is available due to cost=20
or=20 other architectural reasons. While not ideal, I = would not=20 like ban a mobile
service provider or a small company to = apply=20 outbound with one single proxy =
only=20 and cope with UAs supporting a single proxy only. The spec could=20
however be explicit on = mentioning the=20 limitations or risks caused by doing=20 so.
 
Regards,
 
Erkki

From: ext Jeroen van Bemmel=20 [mailto:jbemmel@zonnet.nl]
Sent: 05.April.2006=20 14:04
To: Christer Holmberg (JO/LMF);=20 sip@ietf.org
Subject: Re: [Sip] RE: Outbound: Multiple = flows and=20 forking

Christer,
 
I wouldn't recommend using outbound = for mobile=20 devices in the first place
 
In http://www.ietf.org/internet-drafts/draft-brok-simple-regul= ate-publish-02.txt section=20 2.2 there are some estimates for the effect of periodic = transmissions on the=20 battery lifetime. This is for periodic PUBLISH, for periodic = keepalive (UDP:=20 every 24-29 seconds, TCP: every 95-120 seconds) it would even be = worse. Your=20 battery would be depleted in about a day
 
Regards,
 
Jeroen
 
----- Original Message ----- =
From:=20 Christer Holmberg=20 (JO/LMF)
Sent: Wednesday, April 05, = 2006 11:58=20 AM
Subject: [Sip] RE: = Outbound: Multiple=20 flows and forking


Hi,

One more thing = about mandating=20 the sending of REGISTERs to multiple proxies. To maintain a single = registration flow will most likely have impacts on batteries in = mobile=20 devices, and mandating to maintain multiple flows would have even = bigger=20 impacts. So, that's another reason I don't think it shall be=20 mandated.

Regards, =

Christer =


_____________________________________________=20
From:   = Christer Holmberg (JO/LMF)  =
Sent:   5. huhtikuuta 2006 11:26
To:     sip@ietf.org
Subject:        = Outbound: Multiple flows and forking =


Hi,

A couple of issues on chapter = 4.2.

The text says:

"However, a UA MUST support sets = with at least=20 two outbound proxy URIs (primary and backup) and SHOULD support = sets with=20 up to four URIs.  For each

outbound proxy URI in the set, the = UA MUST send=20 a REGISTER in the normal way using this URI as the default = outbound=20 proxy."

I don't think we should mandate = this, because=20 it is very much dependent on the architecture, transport = techniques etc.=20

Also, if the UA has registered = multiple flows,=20 should the registrar fork dialog initiation requests (addressed = for the=20 UA) on all of them? I realize it is an implementation issue, but I = think=20 it would be good to have some words about it in the draft, for = example=20 saying that a registrar may choose not to fork if the same = instance-id is=20 used for multiple bindings. Or something like that...

Regards,

Christer

_______________________________________________
Sip = mailing=20 list  https://www1.ietf.org/mailman/listinfo/sip
This list = is for=20 NEW development of the core SIP Protocol
Use=20 sip-implementors@cs.columbia.edu for questions on current = sip
Use=20 sipping@ietf.org for new developments on the application of=20 sip
------_=_NextPart_001_01C658AF.07A29213-- --===============1027928828== 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 --===============1027928828==-- From sip-bounces@ietf.org Wed Apr 05 09:20:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR7u8-000654-4g; Wed, 05 Apr 2006 09:18:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR7u6-00064z-Ng for sip@ietf.org; Wed, 05 Apr 2006 09:18:34 -0400 Received: from fmmailgate04.web.de ([217.72.192.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR7u5-0005y2-Hb for sip@ietf.org; Wed, 05 Apr 2006 09:18:34 -0400 Received: by fmmailgate04.web.de (8.12.10/8.12.10/webde Linux 0.7) with SMTP id k35DHwrC024335; Wed, 5 Apr 2006 15:18:31 +0200 Received: from [217.167.116.182] by freemailng0802.web.de with HTTP; Wed, 05 Apr 2006 15:18:29 +0200 Date: Wed, 05 Apr 2006 15:18:29 +0200 Message-Id: <600748017@web.de> MIME-Version: 1.0 From: Roland Jesske To: "Christer Holmberg (JO/LMF)" , john.elwell@siemens.com, "Peterson, Jon" , sip@ietf.org Subject: =?iso-8859-15?Q?FW:_RE:_[Sip]_Connected-identity_and_changing_the_To_h?= =?iso-8859-15?Q?eader_field_in_aresponse?= Precedence: fm-user Organization: http://freemail.web.de/ Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.5 (/) X-Scan-Signature: b5216aa5b0df24d46eaed76d4f65aa31 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org John, what we want to have is we an additional connected number (additional con= nected identity) as described within www.ietf.org/internet-drafts/ draft-j= esske-sipping-tispan-requirements-02.txt. (Section 3.3 ). It is the same as the conected and generic number within the ISUP (Q.763)= I thought that your goal was also to have an additional connected identit= y (like the replaced to/from headers in requests) And we don't need an trusted additional connected identity. So it is a re= al user provided identity. =20 Best Regards =20 Roland =20 =20 =20 =20 =20 > > -----Urspr=FCngliche Nachricht----- > > Von: "Elwell, John" > > Gesendet: 05.04.06 14:50:08 > > An: sip@ietf.org > > Betreff: RE: [Sip] Connected-identity and changing the To header field= in aresponse >=20 >=20 > > Roland, > >=20 > > Well, I don't want to get into a long discussion about what RFC3325 al= lows > > or disallows. It appears that current practice supports the point I am= > > trying to make - if you don't need a cryptographically authenticated > > response identity, then PAI is sufficient within trusted environments,= > > provided you have some means of authenticating the responding UA (sinc= e the > > UA will be outside the trusted environment). If you say that TLS is no= t > > used, what is used instead=3F > >=20 > > John > >=20 > > > -----Original Message----- > > > From: Roland Jesske [mailto:roland.jesske@web.de]=20 > > > Sent: 05 April 2006 09:02 > > > To: Elwell, John; Peterson, Jon; sip@ietf.org > > > Subject: RE: [Sip] Connected-identity and changing the To=20 > > > header field in aresponse > > >=20 > > > John, > > > You wrote:=20 > > > >Unfortunately RFC3325 is unclear on the use of PAI in=20 > > > responses, although in practice I think it is used and is=20 > > > probably OK if >the last hop is secured by TLS so that=20 > > > previous authentication of the UAS can be relied on for=20 > > > making the assertion. > > >=20 > > > You aready quoted in a Mail 2. January 2006 the use of PAI in=20 > > > responses as written within RFC3324. > > >=20 > > > Again RFC 3324 says: > > > 5. Parties with Network Asserted Identities > > >=20 > > > A Network Asserted Identity identifies the originator of=20 > > > the message > > > in which it was received. > > >=20 > > > For example, > > >=20 > > > a Network Asserted Identity received in an initial=20 > > > INVITE (outside > > > the context of any existing dialog) identifies the=20 > > > calling party. > > >=20 > > > a Network Asserted Identity received in a 180 Ringing=20 > > > response to > > > such an INVITE identifies the party who is ringing. > > >=20 > > > a Network Asserted Identity received in a 200 response=20 > > > to such an > > > INVITE identifies the party who has answered. > > >=20 > > >=20 > > > Also in RFC 3325 the use is allowed as follows: > > >=20 > > > This document adds the following entry to Table 2 of [1]: > > >=20 > > > Header field where proxy ACK BYE CAN INV=20 > > > OPT REG > > > ------------ ----- ----- --- --- --- ---=20 > > > --- --- > > > P-Asserted-Identity adr - o - o o = - > > >=20 > > > A=3D > > > SUB NOT REF INF=20 > > > UPD PRA > > > --- --- --- ---=20 > > > --- --- > > > o o o - - = - > > >=20 > > > Is this all wrong now=3F Is it forbidden to use a=20 > > > P-Asserted-Identity in Responses. > > >=20 > > > The 3GPP and TISPAN IMS are using the P-Asserted-Identity in=20 > > > Responses and it is not forced to use TLS.=20 > > >=20 > > > Is this all now wrong=3F > > >=20 > > > Best Regards > > >=20 > > > Roland > > > > -----Urspr=FCngliche Nachricht----- > > > > Von: "Elwell, John" > > > > Gesendet: 05.04.06 09:07:07 > > > > An: sip@ietf.org > > > > Betreff: RE: [Sip] Connected-identity and changing the To=20 > > > header field in aresponse > > >=20 > > >=20 > > > > Jon, > > > >=20 > > > > =20 > > > >=20 > > > > Thanks for this excellent summary of the issue, which I=20 > > > fully agree with and which unfortunately seems to need=20 > > > restating at regular intervals. It appears that the chief=20 > > > motivation of those asking for something in the response is=20 > > > to facilitate interworking with PSTN (by including it in the=20 > > > 200 response so that it can be mapped directly to the PSTN=20 > > > "connected" message). As you say, such a response is always=20 > > > going to be unauthenticated, and I don't think that meets the=20 > > > requirements of PSTN interworking. Far better to figure out a=20 > > > way of using an authenticated connected identity in an UPDATE=20 > > > message for mapping to PSTN connected identity. > > > >=20 > > > > =20 > > > >=20 > > > > Of course, in trusted networks there may be other means for=20 > > > ensuring the authenticity of an identity in a response, just=20 > > > as there is in a request using P-Asserted-Identity.=20 > > > Unfortunately RFC3325 is unclear on the use of PAI in=20 > > > responses, although in practice I think it is used and is=20 > > > probably OK if the last hop is secured by TLS so that=20 > > > previous authentication of the UAS can be relied on for=20 > > > making the assertion. I think if those trusted networks=20 > > > really need a solution for response identity, PAI would be a=20 > > > better avenue to explore (taking into account the risks). But=20 > > > not for the Internet. I am becoming more and more convinced=20 > > > that diluting the connected-identity draft with a weak=20 > > > solution for response identity would be the wrong way to go. > > > >=20 > > > > =20 > > > >=20 > > > > John > > > > =20 > > > > =20 > > > > ----------------------------------------------------------------- > > > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz]=20 > > > > Sent: 05 April 2006 02:05 > > > > To: Elwell, John; sip@ietf.org > > > > Subject: RE: [Sip] Connected-identity and changing the To=20 > > > header field in aresponse > > > >=20 > > > > =20 > > > > =20 > > > > Yes, I was asked for clarification on this point after the=20 > > > meeting, and I'll be providing it here. As you surmised, it=20 > > > is not that RFC3261 relies on the addr-spec of the To or From=20 > > > header field for transaction identification, or something. In=20 > > > fact, I would have essentially the same concerns about any=20 > > > proposal that provided an additional header (say, a=20 > > > 'Connected-Party' header) in responses to dialog-forming=20 > > > requests which was understood to clobber the To header field=20 > > > and identify the AoR of the party who was reached after=20 > > > retargeting of the request took place. > > > > =20 > > > > =20 > > > > =20 > > > > Starting with the goals of this approach: what sort of UAC=20 > > > decisions or behavior do we hope to enable through sending a=20 > > > response with a modified To header field=3F As far as I can=20 > > > understand, we either want to render this AoR to the user of=20 > > > a UAC (so the user can react in one way or another), or input=20 > > > the AoR to some sort of policy manager (e.g.=20 > > > blacklist/whitelist) that might make a decision about whether=20 > > > or not the session should continue -prior- to session=20 > > > establishment. If we don't care about this occurring prior to=20 > > > session establishment, of course, then we could go with the=20 > > > connected-identity draft as it is written today. > > > > =20 > > > > =20 > > > > =20 > > > > A little refresher on my sipping-retarget draft: The core=20 > > > problem with any scheme for connected party is figuring out=20 > > > how you'd decide whether or not a particular respondent is=20 > > > authorized. This is the argument of 2.2.1 of=20 > > > sipping-retarget, the "unanticipated respondent" problem.=20 > > > When we think about what sorts of policy decisions we expect=20 > > > a human or automata to make when receiving a response with=20 > > > identity information, we have to acknowledge that the UAC has=20 > > > no way of knowing which respondents are or are not authorized=20 > > > to respond to the request in question. Since the UAC has no=20 > > > insight into any retargeting that has taken place, the UAC=20 > > > has to assume that virtually any response is a potentially=20 > > > legitimate one. As such, there is little room for any=20 > > > meaningful policy decision when receiving a response. This=20 > > > problem is further compounded by the fact that the UAS may=20 > > > have several possible legitimate AoRs it could claim (I have=20 > > > a UA that registers its contact address under 3 separate SIP=20 > > > services simultaneously), and of course the fact that AoRs=20 > > > may be pretty uninformative (e.g.=20 > > > sip:user31@freesipservice.example.com), all of which=20 > > > complicate authorization decisions. Solving this problem is=20 > > > on the same footing as solving the request-history problem set. > > > > =20 > > > > =20 > > > > =20 > > > > With that background, the problems with providing this=20 > > > connected party information in responses (via the To header=20 > > > or what have you) are roughly as follows: > > > > =20 > > > > =20 > > > > =20 > > > > a) The "unanticipated respondent" problem is especially an=20 > > > issue for response identity because not all responses are=20 > > > success responses. If you end up connecting to a party=20 > > > (receiving a 200), you can potentially rely on human factors=20 > > > to help you identify who you are talking to (after all, Carol=20 > > > can always answer Bob's phone regardless of who SIP thinks=20 > > > you connected to) and/or use the connected party information=20 > > > to change how you might address the party on the other side.=20 > > > With a 403 response, you are in a very different predicament=20 > > > - how is UAC or user behavior supposed to change based on the=20 > > > connected URI attributed to a 403, given the unanticipated=20 > > > respondent problem=3F For provisional responses, the issues=20 > > > become even worse - we then get into the wonders of forking,=20 > > > multiple provisional responses from multiple sources=20 > > > asserting different To header fields - in short, nothing=20 > > > which makes it any easier to render a "responding" AoR to a=20 > > > user, for example. Response identity, in so far as it deals=20 > > > with non-final, non-successful responses, opens up the=20 > > > "unconnected party" problem set. I think this is just the=20 > > > wrong framing of the problem. You want to know who you=20 > > > connected to, not who you didn't connect to. > > > > =20 > > > > =20 > > > > =20 > > > > b) Getting a signature over the To header field in=20 > > > responses would be difficult. In full awareness of Mr.=20 > > > Elwell's note below that certain parties are interested in=20 > > > "(unauthenticated) identity in a response", if this=20 > > > information is going to be put to any purpose, cause any=20 > > > change in human or UAC behavior, I have a hard time seeing=20 > > > how anyone could defend it being unsecured. If you want a=20 > > > human or an automata to make a policy decision based on the=20 > > > AoR in the To header field of the response, some sort of=20 > > > response identity signature would be necessary to prevent=20 > > > obvious impersonation attacks designed to thwart=20 > > > authorization decisions. With all due respect to the authors=20 > > > of draft-cao-sip-response-identity/auth, I'm not sure this=20 > > > problem is readily solved. Making sure that an appropriate=20 > > > authentication service is in the path of responses is=20 > > > problematic, since responses must traverse exactly the same=20 > > > path as requests. I played around with this a lot in the=20 > > > early phases of SIP identity, and at the end of the day, I=20 > > > had to conclude that the only way to make this work was to=20 > > > eliminate retargeting. Since providing connected-identity in=20 > > > responses assumes that retargeting has taken place, it=20 > > > wouldn't exactly be getting off on the right foot.=20 > > > Constraining inbound request routing to a domain such that=20 > > > responses will traverse an authentication service, or forcing=20 > > > a UAS to participate in the Identity scheme, is likely to=20 > > > require mandatory option-tags or comparable mechanisms that=20 > > > will limit the applicability of response identity and more or=20 > > > less eliminate its opportunistic use. > > > > =20 > > > > =20 > > > > =20 > > > > c) The inability to reject a response. Take the easiest=20 > > > case - let's say that the UAC receives a final success=20 > > > response, say a 200 response, with a modified To header field=20 > > > from a party that is blacklisted by UAC policy. What exactly=20 > > > is the UAC supposed to do=3F Send a 403=3F One cannot reject=20 > > > responses. Maybe a CANCEL=3F As section 9.1 of RFC3261 says,=20 > > > CANCEL "has no effect on requests that have already generated=20 > > > a final response." Drop the request on the floor=3F You'll just=20 > > > receive retransmissions. All you can do is ACK it, since the=20 > > > dialog has already been formed, and then send a BYE. In other=20 > > > words, a session -will- be established, there simply isn't an=20 > > > opportunity for policy to be put into effect prior to session=20 > > > establishment. Also, consider the need for the new responses=20 > > > defined in the sip-identity draft, like say the 438 response=20 > > > - if the UAC receives a 200 response with a potentially=20 > > > repairable error in the Identity header, how can it express=20 > > > that error to the UAS, since it can't send responses to a response=3F > > > > =20 > > > > =20 > > > > =20 > > > > Given the above, why does the UAC need to know who has been=20 > > > reached in the response, rather than in a request after the=20 > > > dialog has been formed=3F As (c) illustrates, in the 200=20 > > > response case a session will be established anyway, so=20 > > > sharing the identity of the connected party after session=20 > > > establishment doesn't actually miss some opportunity for=20 > > > applying policy - moreover, an UPDATE or similar request that=20 > > > provides the connected-identity information could be rejected=20 > > > by the session-originating UA in a manner that is helpful to=20 > > > the session-terminating UA (e.g., a 438 response could be=20 > > > sent). If we go with the mechanism in the connected-identity=20 > > > draft, problem (b) disappears, since request routing is far=20 > > > more malleable than response routing. Additionally, the=20 > > > connected-identity draft wisely does not attempt to solve=20 > > > "unconnected party" problems from (a), which are the least=20 > > > tractable of the unanticipated respondent problems. Rather,=20 > > > connected-identity provides an indication more along the=20 > > > lines of, "your dialog was established, however that might=20 > > > have happened, and this is who is on the other side". > > > > =20 > > > > =20 > > > > =20 > > > > Furthermore, any solution that tried to put the=20 > > > connected-identity information into responses would be=20 > > > providing an imprimatur of legitimacy to those responses -=20 > > > presuming they had a signature, UACs would validate it, and=20 > > > provided it checked out, they would be tempted say "this is a=20 > > > legitimate response." Nothing could be further from the=20 > > > truth, as sipping-retarget illustrates. Legitimacy of=20 > > > responses cannot be determined by UACs in the absence of=20 > > > something like request-history. > > > > =20 > > > > =20 > > > > =20 > > > > Finally, I like having one Identity header, and for the=20 > > > meaning of that Identity header to *always* be that it is a=20 > > > signature over the From header field issued by the domain=20 > > > identified by the host portion of the addr-spec of the From=20 > > > header field. The current connected-identity header draft=20 > > > provides that property. > > > > =20 > > > > =20 > > > > =20 > > > > Jon Peterson > > > > =20 > > > > NeuStar, Inc. > > > > =20 > > > > =20 > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > > Sent: Monday, April 03, 2006 11:46 PM > > > > To: sip@ietf.org > > > > Subject: [Sip] Connected-identity and changing the To=20 > > > header field in aresponse > > > >=20 > > > > =20 > > > >=20 > > > > During discussion of draft-elwell-connected-identity in=20 > > > Dallas, somebody put forward the opinion that it would be=20 > > > dangerous to change the To header field URI in a response=20 > > > (i.e., make it different from the From header field URI in=20 > > > the request). My assumption at the time was that it would=20 > > > undermine the transaction concept in SIP, yet reading what=20 > > > RFC3261 has to say about transactions, the value of the To=20 > > > header field URI in a response does not appear to be involved=20 > > > in coupling a response to a request. Therefore I assume the=20 > > > person who indicated the danger (which was not challenged at=20 > > > the meeting) has other reasons in mind. I would greatly=20 > > > appreciate opinions on the wisdom or otherwise of allowing=20 > > > the To header field URI to change. It seems that from=20 > > > discussion of connected-identity there is a desire from some=20 > > > parts of the community to include an (unauthenticated)=20 > > > identity in a response. > > > > =20 > > > >=20 > > > > John=20 > > > >=20 > > > > ----------------------------------------------------------------- > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org for new developments on the application of si= p > > >=20 > > >=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=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > > SMS schreiben mit WEB.DE FreeMail - einfach, schnell und > > > kostenguenstig. Jetzt gleich testen! http://f.web.de/=3Fmc=3D021192 > > >=20 >=20 >=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=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/=3Fmc=3D021192 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 05 09:22:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR7vo-0007Fx-LQ; Wed, 05 Apr 2006 09:20:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR7vn-00076k-1O for sip@ietf.org; Wed, 05 Apr 2006 09:20:19 -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 1FR7vl-000636-LG for sip@ietf.org; Wed, 05 Apr 2006 09:20:19 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 05 Apr 2006 06:20:17 -0700 X-IronPort-AV: i="4.04,89,1144047600"; d="scan'208"; a="318912743:sNHT31075660" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k35DKHw1025743; Wed, 5 Apr 2006 06:20:17 -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); Wed, 5 Apr 2006 06:20:17 -0700 Received: from [24.120.193.53] ([10.21.80.197]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Apr 2006 06:20:16 -0700 Message-ID: <4433C410.8020903@cisco.com> Date: Wed, 05 Apr 2006 09:20:16 -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: Multiple flows and forking References: <5EB80D22825EEE42872083AD5BFFB5945D1CA3@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1CA3@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Apr 2006 13:20:16.0497 (UTC) FILETIME=[ADCDBE10:01C658B3] X-Spam-Score: 0.0 (/) 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 inline: Christer Holmberg (JO/LMF) wrote: > > Hi, > > A couple of issues on chapter 4.2. > > The text says: > > "However, a UA MUST support sets with at least two outbound proxy URIs > (primary and backup) 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." > > I don't think we should mandate this, because it is very much dependent > on the architecture, transport techniques etc. Mandate what? The minimal number of outbound proxies that should be supported? Or the fact that you register on each? For the latter, its an essential part of the story so I don't see how you can make it optional. In the former case, if you don't specify a minimum that is supported, how do you have interop? -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 Apr 05 09:34:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR882-0001vR-7K; Wed, 05 Apr 2006 09:32:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR87z-0001vM-T7 for sip@ietf.org; Wed, 05 Apr 2006 09:32:55 -0400 Received: from fmmailgate04.web.de ([217.72.192.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR87x-0006ig-UM for sip@ietf.org; Wed, 05 Apr 2006 09:32:55 -0400 Received: by fmmailgate04.web.de (8.12.10/8.12.10/webde Linux 0.7) with SMTP id k35DWcr6015060; Wed, 5 Apr 2006 15:32:52 +0200 Received: from [217.167.116.182] by freemailng0802.web.de with HTTP; Wed, 05 Apr 2006 15:32:51 +0200 Date: Wed, 05 Apr 2006 15:32:51 +0200 Message-Id: <600749736@web.de> MIME-Version: 1.0 From: Roland Jesske To: "Christer Holmberg (JO/LMF)" , "Elwell, John" , "Peterson, Jon" , sip@ietf.org Subject: =?iso-8859-15?Q?RE:_[Sip]_Connected-identity_and_changing_the_To_heade?= =?iso-8859-15?Q?r_field_ina_response?= Precedence: fm-user Organization: http://freemail.web.de/ Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.5 (/) X-Scan-Signature: 17cf8eab1d6bbd2874a56f9e3554d91d Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org John, there it looks like a misunderstanding. Thought all requirements from IETF= and TISPAN can be solved within your draft. As you saw he additional connected identity is a requirement comming from = TISPAN and that was discussed in also in Vancover. In draft-sasaki-sipping= -tispan-adhoc-summary-00.txt it is mentioned. Terminating Identification Presentation(TIP)- The working group requests that this requirement be better defined and documented. It is also suggested that TISPAN consider reading draft-rosenberg-sip-identity-privacy-00 as it may solve the problem of calling into an 800 number, getting an operator, and being able to call back that operator and still protect the privacy of the operator. In addition, work is progressing on draft-elwell-sip-connected-identity-00. So using the PAI does not need to go deeper into draft-rosenberg-sip-ident= ity-privacy-00, but looking into your draft.=20 And looking within your draft using the dialogUriChange element we thought= we have the solution if this can be done within the final Response of the= initial INVITE.=20 Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: "Elwell, John" > Gesendet: 05.04.06 14:56:20 > An: sip@ietf.org > Betreff: RE: [Sip] Connected-identity and changing the To header field i= na response > Christer, >=20 > This "additional connected number" is not a requirement that I have been= > trying to address. Was this among the requirements that TISPAN brought i= nto > the IETF recently=3F >=20 > John >=20 > > -----Original Message----- > > From: Christer Holmberg (JO/LMF)=20 > > [mailto:christer.holmberg@ericsson.com]=20 > > Sent: 05 April 2006 08:34 > > To: Elwell, John; Peterson, Jon; sip@ietf.org > > Subject: RE: [Sip] Connected-identity and changing the To=20 > > header field inaresponse > >=20 > > =20 > > Hi, > >=20 > > In PSTN terms we are talking about that the TO header shall=20 > > be mapped to > > the additional connected number, and that does NOT need to be=20 > > authorized > > in the same way as the connected number. > >=20 > > And, whether the interworking node sends this value to PSTN=20 > > is of course > > based on local policy, based on trust etc. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=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 > >=20 > > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > > Sent: 5. huhtikuuta 2006 10:01 > > To: Peterson, Jon; sip@ietf.org > > Subject: RE: [Sip] Connected-identity and changing the To header field= > > inaresponse > >=20 > >=20 > > Jon, > > =20 > > Thanks for this excellent summary of the issue, which I fully=20 > > agree with > > and which unfortunately seems to need restating at regular=20 > > intervals. It > > appears that the chief motivation of those asking for something in the= > > response is to facilitate interworking with PSTN (by=20 > > including it in the > > 200 response so that it can be mapped directly to the PSTN "connected"= > > message). As you say, such a response is always going to be > > unauthenticated, and I don't think that meets the requirements of PSTN= > > interworking. Far better to figure out a way of using an authenticated= > > connected identity in an UPDATE message for mapping to PSTN connected > > identity. > > =20 > > Of course, in trusted networks there may be other means for=20 > > ensuring the > > authenticity of an identity in a response, just as there is=20 > > in a request > > using P-Asserted-Identity. Unfortunately RFC3325 is unclear on the use= > > of PAI in responses, although in practice I think it is used and is > > probably OK if the last hop is secured by TLS so that previous > > authentication of the UAS can be relied on for making the assertion. I= > > think if those trusted networks really need a solution for response > > identity, PAI would be a better avenue to explore (taking into account= > > the risks). But not for the Internet. I am becoming more and more > > convinced that diluting the connected-identity draft with a weak > > solution for response identity would be the wrong way to go. > > =20 > > John > >=20 > >=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 > >=20 > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz]=20 > > Sent: 05 April 2006 02:05 > > To: Elwell, John; sip@ietf.org > > Subject: RE: [Sip] Connected-identity and changing the To header > > field in aresponse > > =09 > > =09 > > Yes, I was asked for clarification on this point after the > > meeting, and I'll be providing it here. As you surmised, it=20 > > is not that > > RFC3261 relies on the addr-spec of the To or From header field for > > transaction identification, or something. In fact, I would have > > essentially the same concerns about any proposal that provided an > > additional header (say, a 'Connected-Party' header) in responses to > > dialog-forming requests which was understood to clobber the To header > > field and identify the AoR of the party who was reached after > > retargeting of the request took place. > > =20 > > Starting with the goals of this approach: what sort of UAC > > decisions or behavior do we hope to enable through sending a response > > with a modified To header field=3F As far as I can understand, we either= > > want to render this AoR to the user of a UAC (so the user can react in= > > one way or another), or input the AoR to some sort of policy manager > > (e.g. blacklist/whitelist) that might make a decision about whether or= > > not the session should continue -prior- to session=20 > > establishment. If we > > don't care about this occurring prior to session establishment, of > > course, then we could go with the connected-identity draft as it is > > written today. > > =20 > > A little refresher on my sipping-retarget draft: The core > > problem with any scheme for connected party is figuring out how you'd > > decide whether or not a particular respondent is authorized.=20 > > This is the > > argument of 2.2.1 of sipping-retarget, the "unanticipated respondent" > > problem. When we think about what sorts of policy decisions=20 > > we expect a > > human or automata to make when receiving a response with identity > > information, we have to acknowledge that the UAC has no way of knowing= > > which respondents are or are not authorized to respond to the=20 > > request in > > question. Since the UAC has no insight into any retargeting that has > > taken place, the UAC has to assume that virtually any response is a > > potentially legitimate one. As such, there is little room for any > > meaningful policy decision when receiving a response. This problem is > > further compounded by the fact that the UAS may have several possible > > legitimate AoRs it could claim (I have a UA that registers its contact= > > address under 3 separate SIP services simultaneously), and of=20 > > course the > > fact that AoRs may be pretty uninformative (e.g. > > sip:user31@freesipservice.example.com), all of which complicate > > authorization decisions. Solving this problem is on the same=20 > > footing as > > solving the request-history problem set. > > =20 > > With that background, the problems with providing this connected > > party information in responses (via the To header or what=20 > > have you) are > > roughly as follows: > > =20 > > a) The "unanticipated respondent" problem is especially an issue > > for response identity because not all responses are success responses.= > > If you end up connecting to a party (receiving a 200), you can > > potentially rely on human factors to help you identify who you are > > talking to (after all, Carol can always answer Bob's phone=20 > > regardless of > > who SIP thinks you connected to) and/or use the connected party > > information to change how you might address the party on the=20 > > other side. > > With a 403 response, you are in a very different predicament - how is > > UAC or user behavior supposed to change based on the connected URI > > attributed to a 403, given the unanticipated respondent problem=3F For > > provisional responses, the issues become even worse - we then get into= > > the wonders of forking, multiple provisional responses from multiple > > sources asserting different To header fields - in short, nothing which= > > makes it any easier to render a "responding" AoR to a user,=20 > > for example. > > Response identity, in so far as it deals with non-final,=20 > > non-successful > > responses, opens up the "unconnected party" problem set. I=20 > > think this is > > just the wrong framing of the problem. You want to know who you > > connected to, not who you didn't connect to. > > =20 > > b) Getting a signature over the To header field in responses > > would be difficult. In full awareness of Mr. Elwell's note below that > > certain parties are interested in "(unauthenticated) identity in a > > response", if this information is going to be put to any=20 > > purpose, cause > > any change in human or UAC behavior, I have a hard time seeing how > > anyone could defend it being unsecured. If you want a human or an > > automata to make a policy decision based on the AoR in the To header > > field of the response, some sort of response identity=20 > > signature would be > > necessary to prevent obvious impersonation attacks designed to thwart > > authorization decisions. With all due respect to the authors of > > draft-cao-sip-response-identity/auth, I'm not sure this problem is > > readily solved. Making sure that an appropriate authentication service= > > is in the path of responses is problematic, since responses must > > traverse exactly the same path as requests. I played around=20 > > with this a > > lot in the early phases of SIP identity, and at the end of the day, I > > had to conclude that the only way to make this work was to eliminate > > retargeting. Since providing connected-identity in responses assumes > > that retargeting has taken place, it wouldn't exactly be=20 > > getting off on > > the right foot. Constraining inbound request routing to a domain such > > that responses will traverse an authentication service, or=20 > > forcing a UAS > > to participate in the Identity scheme, is likely to require mandatory > > option-tags or comparable mechanisms that will limit the applicability= > > of response identity and more or less eliminate its opportunistic use.= > > =20 > > c) The inability to reject a response. Take the easiest case - > > let's say that the UAC receives a final success response, say a 200 > > response, with a modified To header field from a party that is > > blacklisted by UAC policy. What exactly is the UAC supposed=20 > > to do=3F Send > > a 403=3F One cannot reject responses. Maybe a CANCEL=3F As section 9.1 of > > RFC3261 says, CANCEL "has no effect on requests that have already > > generated a final response." Drop the request on the floor=3F=20 > > You'll just > > receive retransmissions. All you can do is ACK it, since the=20 > > dialog has > > already been formed, and then send a BYE. In other words, a session > > -will- be established, there simply isn't an opportunity for policy to= > > be put into effect prior to session establishment. Also, consider the > > need for the new responses defined in the sip-identity draft, like say= > > the 438 response - if the UAC receives a 200 response with a=20 > > potentially > > repairable error in the Identity header, how can it express that error= > > to the UAS, since it can't send responses to a response=3F > > =20 > > Given the above, why does the UAC need to know who has been > > reached in the response, rather than in a request after the dialog has= > > been formed=3F As (c) illustrates, in the 200 response case a=20 > > session will > > be established anyway, so sharing the identity of the connected party > > after session establishment doesn't actually miss some opportunity for= > > applying policy - moreover, an UPDATE or similar request that provides= > > the connected-identity information could be rejected by the > > session-originating UA in a manner that is helpful to the > > session-terminating UA (e.g., a 438 response could be sent). If we go > > with the mechanism in the connected-identity draft, problem (b) > > disappears, since request routing is far more malleable than response > > routing. Additionally, the connected-identity draft wisely does not > > attempt to solve "unconnected party" problems from (a), which are the > > least tractable of the unanticipated respondent problems. Rather, > > connected-identity provides an indication more along the=20 > > lines of, "your > > dialog was established, however that might have happened, and this is > > who is on the other side". > > =20 > > Furthermore, any solution that tried to put the > > connected-identity information into responses would be providing an > > imprimatur of legitimacy to those responses - presuming they had a > > signature, UACs would validate it, and provided it checked out, they > > would be tempted say "this is a legitimate response." Nothing could be= > > further from the truth, as sipping-retarget illustrates. Legitimacy of= > > responses cannot be determined by UACs in the absence of=20 > > something like > > request-history. > > =20 > > Finally, I like having one Identity header, and for the meaning > > of that Identity header to *always* be that it is a signature over the= > > From header field issued by the domain identified by the host=20 > > portion of > > the addr-spec of the From header field. The current connected-identity= > > header draft provides that property. > > =20 > > Jon Peterson > > NeuStar, Inc. > >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: Monday, April 03, 2006 11:46 PM > > To: sip@ietf.org > > Subject: [Sip] Connected-identity and changing the To > > header field in aresponse > > =09 > > =09 > >=20 > > During discussion of draft-elwell-connected-identity in > > Dallas, somebody put forward the opinion that it would be dangerous to= > > change the To header field URI in a response (i.e., make it different > > from the From header field URI in the request). My assumption at the > > time was that it would undermine the transaction concept in SIP, yet > > reading what RFC3261 has to say about transactions, the value=20 > > of the To > > header field URI in a response does not appear to be involved in > > coupling a response to a request. Therefore I assume the person who > > indicated the danger (which was not challenged at the=20 > > meeting) has other > > reasons in mind. I would greatly appreciate opinions on the wisdom or > > otherwise of allowing the To header field URI to change. It seems that= > > from discussion of connected-identity there is a desire from=20 > > some parts > > of the community to include an (unauthenticated) identity in=20 > > a response. > >=20 > > John=20 > >=20 >=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip =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=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/=3Fmc=3D021192 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 05 09:35:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR88L-0001wC-Vg; Wed, 05 Apr 2006 09:33:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR88K-0001w7-AV for sip@ietf.org; Wed, 05 Apr 2006 09:33:16 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR88I-0006lk-RM for sip@ietf.org; Wed, 05 Apr 2006 09:33:16 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A1C94EFB; Wed, 5 Apr 2006 15:33: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, 5 Apr 2006 15:33:13 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 15:33: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="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound: Multiple flows and forking Date: Wed, 5 Apr 2006 15:33:12 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1CC3@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: Multiple flows and forking Thread-Index: AcZYs7J66M8UpSAnQNykqs3gGva+3AAAMBng From: "Christer Holmberg \(JO/LMF\)" To: "Jonathan Rosenberg" X-OriginalArrivalTime: 05 Apr 2006 13:33:12.0682 (UTC) FILETIME=[7C722CA0:01C658B5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 Jonathan,=20 >A couple of issues on chapter 4.2. >=20 >The text says: >=20 >"However, a UA MUST support sets with at least two outbound proxy URIs=20 >(primary and backup) and SHOULD support sets with up to four URIs. =20 >For each outbound proxy URI in the set, the UA MUST send a REGISTER in the=20 >normal way using this URI as the default outbound proxy." >=20 >I don't think we should mandate this, because it is very much=20 >dependent on the architecture, transport techniques etc. Mandate what? The minimal number of outbound proxies that should be supported? Or the fact that you register on each? [CHH] Both, but ESPECIALLY the fact that you register on all of them. >For the latter, its an essential part of the story so I don't see how you can make it optional. [CHH] It may very well be a good thing to do, but because of the battery issue (and maybe other issues I can't think of at the moment) I think it should be optional.=20 >In the former case, if you don't specify a minimum that is supported, how do you have interop? [CHH] I don't see what this has to do with interop. The entities are supposed to work no matter if a single flow, or multiple flows, have been created. A registrar shall of course be prepared to support multiple flows, even if the spec doesn't mandate the user to creat them. Regards, Christer --=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 From sip-bounces@ietf.org Wed Apr 05 09:56:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR8ST-0001YG-BY; Wed, 05 Apr 2006 09:54:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR8SS-0001YB-AN for sip@ietf.org; Wed, 05 Apr 2006 09:54:04 -0400 Received: from ptr-64-201-174-137.ptr.terago.ca ([64.201.174.137] helo=cgy01-fw01.citel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR8SR-00076H-1O for sip@ietf.org; Wed, 05 Apr 2006 09:54:04 -0400 Received: from [10.7.1.3] (helo=not01-mxc01.citel.com) by cgy01-fw01.citel.com with esmtp (Exim 4.43) id 1FR8SN-0007Ms-R6; Wed, 05 Apr 2006 07:54:00 -0600 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip-mib comments) Date: Wed, 5 Apr 2006 14:53:59 +0100 Message-ID: <592CA2F7E2BFBD4088AC87ECFF34BECE2D6D47@not01-mxc01.citel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP MIB ietf-sip-mib comments Thread-Index: AcY5j29dKQxxIed4SCWenzWDWU3cwgCDbzWgAWHdczABPKwkYAAB1NDAAC8iRbAEU4MgYwAjT98A From: "Michael Procter" To: "Cullen Jennings" , "Jean-Francois Mule" , "Kevin Lingle \(klingle\)" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: "Romascanu, Dan \(Dan\)" , Juergen Schoenwaelder X-BeenThere: sip@ietf.org X-Mailman-Version: 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: > sipRegAlloowThirdParty - there are two definitions in common=20 > usage for 3rd > party reg. This is one of them. However, I don't know of any=20 > deployment > situations that allow this type of 3rd party reg. It is the=20 > other type that > are allowed in practice. Do we need to this at all? Do we=20 > need to update? At the risk of raising a tangent, this form of 3rd Party Registration (that is to say when the To header differs from the From header in the REGISTER) is used in the current Bridged Line Appearance draft (draft-anil-sipping-bla-02). Jonathan Rosenburg mentioned on this list (Dec 15, 2005) that draft-ietf-sip-outbound breaks 3rd party registrations, but I can't find the paragraph in the draft that states this after a brief reading. Para 4.2.1 appears to relate to the *other* meaning of 3rd party registration. Regards, Michael Procter _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Apr 05 10:08:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR8e7-0005SY-My; Wed, 05 Apr 2006 10:06:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR8e6-0005ST-KT for sip@ietf.org; Wed, 05 Apr 2006 10:06:06 -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 1FR8e6-0007TM-7L for sip@ietf.org; Wed, 05 Apr 2006 10:06:06 -0400 Received: from HKaplan [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id AEC90364; Wed, 05 Apr 2006 10:06:01 -0400 From: "Hadriel Kaplan" To: "'Hadriel Kaplan'" , "'Christer Holmberg \(JO/LMF\)'" , "'Fredrik Thulin'" , Subject: RE: [Sip] Outbound: Questions on reg-id Date: Wed, 5 Apr 2006 10:06:08 -0400 Message-ID: <066e01c658ba$163bffb0$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZX7MP5wcymRsijQUuBtoWVfY8UpQAAX5KwAAYcA/AALKuDQA== In-Reply-To: <04d501c65809$1d644ba0$6501a8c0@acmepacket.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 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 thought about it more last night and take that last paragraph back - the UA needs to keep using the same reg-id if a previous tcp socket failed, so it's really just the active flow number not ephemeral port at all. If an active flow fails, a new socket would need to reuse the reg-id. So if the ua only ever intends to create one active flow, it should just keep re-using reg-id 1, for example. -hadriel > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Tuesday, April 04, 2006 12:59 PM > To: 'Christer Holmberg (JO/LMF)'; 'Fredrik Thulin'; sip@ietf.org > Subject: RE: [Sip] Outbound: Questions on reg-id > > Yeah it took me a while to figure that piece out as well the first time I > read the draft. > > I think the answer is the Registrar doesn't need to know you "rebooted". > It > just needs to know to update the bindings of the previous set. (ie, > replace > them) Since the instance-id is the same for every flow, it can't be used. > So they needed something which was different per active flow, but would > collide when "replacing" stale flows. It's not just for UA reboots: if > the > UA's using UDP and the NAT rebooted and gave a different dynamic mapped > port, then this helps update that as well. (I think? Would the STUN > XOR-MAPPED-ADDRESS change not cause a reg-id change hopefully?) > > And the proxy needs to know (or the registrar if it's the edge box) that > if > your flow info changed (ie, new socket), that this is replacing an old one > and is not just a secondary one. If it happens to be the same (as it > could > with UDP) then no one needs to be updated and the fact that the same reg- > id > is used is fine. > > For TCP my guess is this would simply be the UA's ephemeral port number. > For UDP it would have to be something like the configured proxy/registrar > list order. (ie, proxy-1 = reg-id 1, etc.) For DNS resolved UDP URI's > it's > much harder if the resolution order changes after reboot or ever, but the > worst that would happen is you have a stale flow which would expire > eventually. So long as you have an outbound registrar it will use the > most > recent binding I think. (which ironically is always the "Backup" flow on > boot up, not the "Primary" flow) > > -hadriel > > > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] > > Sent: Tuesday, April 04, 2006 9:49 AM > > To: Fredrik Thulin; sip@ietf.org > > Subject: RE: [Sip] Outbound: Questions on reg-id > > > > > > Hi, > > > > Ok, I missed that text. I appologize for that. > > > > But, then, if I send a REGISTER with reg-id=1, then I reboot, then I > > send a REGISTER with reg-id=1 again, how will the registrar know I have > > rebooted? > > > > Regards, > > > > Christer > > > > -----Original Message----- > > From: Fredrik Thulin [mailto:ft@it.su.se] > > Sent: 4. huhtikuuta 2006 16:32 > > To: sip@ietf.org > > Cc: Christer Holmberg (JO/LMF) > > Subject: Re: [Sip] Outbound: Questions on reg-id > > > > On Tuesday 04 April 2006 15:10, Christer Holmberg (JO/LMF) wrote: > > ... > > > [CHH] My understanding of the draft is NOT that the SAME req-id would > > > be used. Where is that said? > > > > > > The draft says that when the UA registers multiple times, each > > > registration gets a unique reg-id value. But, it does not say anything > > > > > about re-usage the same reg-id values after a reboot. > > > > "The > > reg-id sequence does not have to be sequential but MUST be exactly > > the same reg-id sequence each time the device power cycles or reboots > > so that the reg-id values will collide with the previously used > > reg-id values. This is so the proxy can realize that the older > > registrations are probably not useful." > > > > /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 > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 05 10:08:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR8eo-0005rC-2j; Wed, 05 Apr 2006 10:06:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR8en-0005oY-7L for sip@ietf.org; Wed, 05 Apr 2006 10:06:49 -0400 Received: from wproxy.gmail.com ([64.233.184.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR8el-0007UV-WC for sip@ietf.org; Wed, 05 Apr 2006 10:06:49 -0400 Received: by wproxy.gmail.com with SMTP id i32so1511669wra for ; Wed, 05 Apr 2006 07:06:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=teregMXGBttBRNFdaM4pyuuJ+4NUMoCv1vnmSIlc7sLkEwn1O0Z7AFCwvy2wbiDlaqJFlUb8XwkLm9TzBIDFHryN/I/MW3woab5x7exbLicgqLADCwN0aPczIdmFvgQnjSVJA6jgFvU+EE+f4sHaVijhiGb0pYjNes3bsz6Ksrg= Received: by 10.65.151.3 with SMTP id d3mr1799637qbo; Wed, 05 Apr 2006 07:06:46 -0700 (PDT) Received: by 10.65.150.9 with HTTP; Wed, 5 Apr 2006 07:06:46 -0700 (PDT) Message-ID: <296966940604050706p6dbeb1abv9c7321b5fd9f86e8@mail.gmail.com> Date: Wed, 5 Apr 2006 08:06:46 -0600 From: "Alan Hawrylyshen" To: "Michael Procter" Subject: Re: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip-mib comments) In-Reply-To: <592CA2F7E2BFBD4088AC87ECFF34BECE2D6D47@not01-mxc01.citel.com> MIME-Version: 1.0 References: <592CA2F7E2BFBD4088AC87ECFF34BECE2D6D47@not01-mxc01.citel.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Cullen Jennings , Juergen Schoenwaelder , sip@ietf.org, "Kevin Lingle \(klingle\)" , "Romascanu, Dan \(Dan\)" , Jean-Francois Mule X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alan@jasomi.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1756576062==" Errors-To: sip-bounces@ietf.org --===============1756576062== Content-Type: multipart/alternative; boundary="----=_Part_20468_3625060.1144246006473" ------=_Part_20468_3625060.1144246006473 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 4/5/06, Michael Procter wrote: > > > Jonathan Rosenburg mentioned on this list (Dec 15, 2005) that > draft-ietf-sip-outbound breaks 3rd party registrations, but > I can't find the paragraph in the draft that states this after > a brief reading. Para 4.2.1 appears to relate to the *other* > meaning of 3rd party registration. Well, by binding an AoR to a 'flow', the outbound draft effectively limits your ability to register a contact URI that get fair RFC3263 treatment, and therefore, makes 3rd party registration significantly more challenging. (Th= e association between your flow and the AoR that gets made using the outbound mechanism may not be what you want for 3pr). Alan Hawrylyshen -- > -- > a d o t h a w r y l y s h e n a t g m a i l d o t c o m ------=_Part_20468_3625060.1144246006473 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

On 4/5/06, M= ichael Procter <michael= .procter@citel.com> wrote:

Jonathan Rosenburg mentioned= on this list (Dec 15, 2005) that
draft-ietf-sip-outbound breaks 3rd par= ty registrations, but
I can't find the paragraph in the draft that states this after
a bri= ef reading.  Para 4.2.1 appears to relate to the *other*
meani= ng of 3rd party registration.
 
 
Well, by binding an AoR to a 'flow', the outbound draft effectively li= mits your ability to register a contact URI that get fair RFC3263 treatment= , and therefore, makes 3rd party registration significantly more challengin= g. (The association between your flow and the AoR that gets made using the = outbound mechanism may not be what you want for 3pr).
 
Alan Hawrylyshen

--
--
a d o t h a w r y l= y s h e n a t g m a i l d o t c o m
------=_Part_20468_3625060.1144246006473-- --===============1756576062== 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 --===============1756576062==-- From sip-bounces@ietf.org Wed Apr 05 10:24:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR8tY-0003FH-PK; Wed, 05 Apr 2006 10:22:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR8tW-0003Es-CO for sip@ietf.org; Wed, 05 Apr 2006 10:22: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 1FR8tW-0008FP-5A for sip@ietf.org; Wed, 05 Apr 2006 10:22:02 -0400 Received: from HKaplan [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A284030C; Wed, 05 Apr 2006 10:21:56 -0400 From: "Hadriel Kaplan" To: "'Christer Holmberg \(JO/LMF\)'" , "'Fredrik Thulin'" Subject: RE: [Sip] Outbound: Questions on reg-id Date: Wed, 5 Apr 2006 10:22:02 -0400 Message-ID: <067801c658bc$4efd5900$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZYlKmNx89Yirs3Rr6Izc9a19X7zAAAG4zgAAlYjUA= In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1CAC@esealmw113.eemea.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Christer, comments inline... > -----Original Message----- > From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] > Sent: Wednesday, April 05, 2006 5:45 AM > To: Fredrik Thulin > Cc: sip@ietf.org > Subject: RE: [Sip] Outbound: Questions on reg-id > > 1. Adding a few words saying that checking the Call-Id to detect whether > a REGISTER is a refresh or a new REGISTER after a reboot. The document > currently says that the reg-id alone is used to indicate reboot, but I > think we have agreed that is not the case. Why do you need to know if the UA rebooted? You only need to know if an old flow/entry is stale. If the UA detects a flow failure (STUN XOR-MAPPED-ADDRESS change, socket failure, etc.), then it will send a whole new register and it will probably be a new call-id. If it wasn't a new call-id, and it came in on a new flow to the registrar, the registrar's supposed to update the flow it received it on anyway. If it came in on a new flow to the proxy, then it would create a new flow token anyway. Am I missing something? > 2. Adding a few words saying that the same Call-Id value MAY be used for > all flows (assuming we agree there are no impacts whether the same > values are used or not). I don't agree. They're unique requests. -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 Wed Apr 05 10:32:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR91U-0006YK-5N; Wed, 05 Apr 2006 10:30:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR91S-0006YA-CO for sip@ietf.org; Wed, 05 Apr 2006 10:30:14 -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 1FR91R-0000Qj-E6 for sip@ietf.org; Wed, 05 Apr 2006 10:30:14 -0400 Received: from HKaplan [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A4720230; Wed, 05 Apr 2006 10:30:10 -0400 From: "Hadriel Kaplan" To: "'Christer Holmberg \(JO/LMF\)'" , "'Jonathan Rosenberg'" Subject: RE: [Sip] Outbound: Multiple flows and forking Date: Wed, 5 Apr 2006 10:30:17 -0400 Message-ID: <067901c658bd$75a3a540$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZYs7J66M8UpSAnQNykqs3gGva+3AAAMBngAAIFSFA= In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1CC3@esealmw113.eemea.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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, I'm confused. You can't "connect" to two outbound proxies simultaneously without Registering on each. There would be no point to being connected to the one you didn't register through. For battery life, wouldn't the STUN or TCP keep-alive drain it even more? The register message does not need to be sent very often relative to those. What is a little screwed up is that the spec strongly implies (or mandates) a UA has to support two simultaneous connections, which is clearly not the case. -hadriel > -----Original Message----- > From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] > Sent: Wednesday, April 05, 2006 9:33 AM > To: Jonathan Rosenberg > Cc: sip@ietf.org > Subject: RE: [Sip] Outbound: Multiple flows and forking > > > Hi Jonathan, > > >A couple of issues on chapter 4.2. > > > >The text says: > > > >"However, a UA MUST support sets with at least two outbound proxy URIs > >(primary and backup) 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." > > > >I don't think we should mandate this, because it is very much > >dependent on the architecture, transport techniques etc. > > Mandate what? The minimal number of outbound proxies that should be > supported? Or the fact that you register on each? > > [CHH] Both, but ESPECIALLY the fact that you register on all of them. > > >For the latter, its an essential part of the story so I don't see how > you can make it optional. > > [CHH] It may very well be a good thing to do, but because of the battery > issue (and maybe other issues I can't think of at the moment) I think it > should be optional. > > >In the former case, if you don't specify a minimum that is supported, > how do you have interop? > > [CHH] I don't see what this has to do with interop. The entities are > supposed to work no matter if a single flow, or multiple flows, have > been created. A registrar shall of course be prepared to support > multiple flows, even if the spec doesn't mandate the user to creat them. > > > Regards, > > Christer > > > > > > -- > 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 Apr 05 10:43:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR9C5-0002J6-6b; Wed, 05 Apr 2006 10:41:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR9C3-0002If-Rj for sip@ietf.org; Wed, 05 Apr 2006 10:41:11 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR9C2-00018k-6i for sip@ietf.org; Wed, 05 Apr 2006 10:41:11 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 93A034F0002; Wed, 5 Apr 2006 16:41:09 +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, 5 Apr 2006 16:41:08 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 16:41:08 +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: Multiple flows and forking Date: Wed, 5 Apr 2006 16:41:08 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1CC7@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: Multiple flows and forking Thread-Index: AcZYs7J66M8UpSAnQNykqs3gGva+3AAAMBngAAIFSFAAAGSPIA== From: "Christer Holmberg \(JO/LMF\)" To: "Hadriel Kaplan" , "Jonathan Rosenberg" X-OriginalArrivalTime: 05 Apr 2006 14:41:08.0672 (UTC) FILETIME=[F9ECE400:01C658BE] X-Brightmail-Tracker: AAAAAA== 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 Hi,=20 >I'm confused. You can't "connect" to two outbound proxies simultaneously without Registering on each. [CHH] You WOULD register on each. You would register the same AoR, with different reg-ids. >There would be no point to being connected to the one you didn't register through. For battery life, wouldn't the STUN=20 >or TCP keep-alive drain it even more? The register message does not need to be sent very often relative to those. [CHH] If you MUST send a register to EACH outbound proxy, you could end up having to send keep-alives on EACH of those flows, and THAT drains the battery more than sending a single REGISTER (even if the UA supports multiple outbound proxies) and then sending keep-alives on that SINGLE flow. >What is a little screwed up is that the spec strongly implies (or mandates) a UA has to support two simultaneous=20 >connections, which is clearly not the case. =20 [CHH] Well, that is how I read the spec :)=20 The text 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.". IF the text means something else it needs rewording. Regards, Christer > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com] > Sent: Wednesday, April 05, 2006 9:33 AM > To: Jonathan Rosenberg > Cc: sip@ietf.org > Subject: RE: [Sip] Outbound: Multiple flows and forking >=20 >=20 > Hi Jonathan, >=20 > >A couple of issues on chapter 4.2. > > > >The text says: > > > >"However, a UA MUST support sets with at least two outbound proxy=20 > >URIs (primary and backup) and SHOULD support sets with up to four URIs. > >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." > > > >I don't think we should mandate this, because it is very much=20 > >dependent on the architecture, transport techniques etc. >=20 > Mandate what? The minimal number of outbound proxies that should be=20 > supported? Or the fact that you register on each? >=20 > [CHH] Both, but ESPECIALLY the fact that you register on all of them. >=20 > >For the latter, its an essential part of the story so I don't see how > you can make it optional. >=20 > [CHH] It may very well be a good thing to do, but because of the=20 > battery issue (and maybe other issues I can't think of at the moment)=20 > I think it should be optional. >=20 > >In the former case, if you don't specify a minimum that is supported, > how do you have interop? >=20 > [CHH] I don't see what this has to do with interop. The entities are=20 > supposed to work no matter if a single flow, or multiple flows, have=20 > been created. A registrar shall of course be prepared to support=20 > multiple flows, even if the spec doesn't mandate the user to creat them. >=20 >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 05 10:57:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR9Q4-0004lM-U5; Wed, 05 Apr 2006 10:55:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR9Q2-0004k9-Te for sip@ietf.org; Wed, 05 Apr 2006 10:55:38 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR9Q1-0001Wc-8v for sip@ietf.org; Wed, 05 Apr 2006 10:55:38 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 716D94F0036; Wed, 5 Apr 2006 16:55:36 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 16:55:35 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 16:55:35 +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: Questions on reg-id Date: Wed, 5 Apr 2006 16:55:35 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1CC8@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: Questions on reg-id Thread-Index: AcZYlKmNx89Yirs3Rr6Izc9a19X7zAAAG4zgAAlYjUAAASrxcA== From: "Christer Holmberg \(JO/LMF\)" To: "Hadriel Kaplan" , "Fredrik Thulin" X-OriginalArrivalTime: 05 Apr 2006 14:55:35.0474 (UTC) FILETIME=[FE946120:01C658C0] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 Hadriel,=20 >1. Adding a few words saying that checking the Call-Id to detect=20 >whether a REGISTER is a refresh or a new REGISTER after a reboot. The=20 >document currently says that the reg-id alone is used to indicate=20 >reboot, but I think we have agreed that is not the case. Why do you need to know if the UA rebooted? You only need to know if an old flow/entry is stale. If the UA detects a flow failure (STUN XOR-MAPPED-ADDRESS change, socket failure, etc.), then it will send a whole new register and it will probably be a new call-id. If it wasn't a new call-id, and it came in on a new flow to the registrar, the registrar's supposed to update the flow it received it on anyway. If it came in on a new flow to the proxy, then it would create a new flow token anyway. Am I missing something? [CHH] The idea was that if the Call-Id value wasn't new, the registrar could assume the REGISTER is just a refresh.=20 >2. Adding a few words saying that the same Call-Id value MAY be used for all flows (assuming we agree there are no=20 >impacts whether the same values are used or not). I don't agree. They're unique requests. =20 [CHH] I am not sure I undertand what you mean by "unique request"... RFC3261 currently says that an UA SHOULD use the same Call-ID for ALL REGISTERs it sends. The RFC does not (for obvious reasons) talk about "flows", "reg-ids" etc.=20 Now, if it is ok to use the same Call-ID for all REGISTERs/flows also for outbound we don't need to add any text in order to extend/change RFC3261. It would only be clarification text, to avoid questions in the future. However, IF we must use different Call-Ids for each flow I think that is new functionality, compared to what is currently said in RFC3261. Or, is there some text somewhere I've missed (it does happen :)? Regards, Christer =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 Apr 05 11:06:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR9YY-0002Sx-Va; Wed, 05 Apr 2006 11:04:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR9YX-0002Ss-IZ for sip@ietf.org; Wed, 05 Apr 2006 11:04:25 -0400 Received: from smtp1.versatel.nl ([62.58.50.88] helo=smtp3.versatel.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR9YW-00028v-6l for sip@ietf.org; Wed, 05 Apr 2006 11:04:25 -0400 Received: (qmail 14212 invoked by uid 0); 5 Apr 2006 15:04: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 < >; 5 Apr 2006 15:04:23 -0000 Message-ID: <004701c658c2$3894bf90$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Christer Holmberg \(JO/LMF\)" , "Hadriel Kaplan" , "Jonathan Rosenberg" References: <5EB80D22825EEE42872083AD5BFFB5945D1CC7@esealmw113.eemea.ericsson.se> Subject: Re: [Sip] Outbound: Multiple flows and forking Date: Wed, 5 Apr 2006 17:04:20 +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.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.1 (/) 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 Christer, [CHH] If you MUST send a register to EACH outbound proxy, you could end up having to send keep-alives on EACH of those flows, and THAT drains the battery more than sending a single REGISTER (even if the UA supports multiple outbound proxies) and then sending keep-alives on that SINGLE flow. [Jvb] Actually, if you would somehow (be allowed to) synchronize the keepalives for all flows, the impact on the battery wouldn't be linear in the number of flows. Once the network link is up, sending 1 or a bunch of messages isn't that much more expensive Perhaps a remark on this could be added to the draft - i.e. let the UA draw a random number from 24..29 (UDP) or 95..120 (TCP), but allow it to use the same interval on multiple, independent flows (i.e. primary and backup) 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 Wed Apr 05 11:49:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRADx-0000RU-1K; Wed, 05 Apr 2006 11:47:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRADv-0000RP-6E for sip@ietf.org; Wed, 05 Apr 2006 11:47:11 -0400 Received: from ptr-64-201-174-137.ptr.terago.ca ([64.201.174.137] helo=cgy01-fw01.citel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRADu-0004MG-Ol for sip@ietf.org; Wed, 05 Apr 2006 11:47:11 -0400 Received: from [10.7.1.3] (helo=not01-mxc01.citel.com) by cgy01-fw01.citel.com with esmtp (Exim 4.43) id 1FRADq-0001tX-VG; Wed, 05 Apr 2006 09:47:07 -0600 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip-mib comments) Date: Wed, 5 Apr 2006 16:47:06 +0100 Message-ID: <592CA2F7E2BFBD4088AC87ECFF34BECE2D6D49@not01-mxc01.citel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip-mib comments) Thread-Index: AcZYujN+t8SpjFZHQnezbBLgdplsIQABaaZA From: "Michael Procter" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Cullen Jennings , Juergen Schoenwaelder , sip@ietf.org, "Kevin Lingle \(klingle\)" , "Romascanu, Dan \(Dan\)" , Jean-Francois Mule X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Alan Hawrylyshen wrote: > On 4/5/06, Michael Procter wrote:=20 >=20 >> Jonathan Rosenburg mentioned on this list (Dec 15, 2005) that >> draft-ietf-sip-outbound breaks 3rd party registrations, but=20 >> I can't find the paragraph in the draft that states this after >> a brief reading. Para 4.2.1 appears to relate to the *other* >> meaning of 3rd party registration. >=20 > Well, by binding an AoR to a 'flow', the outbound draft > effectively limits your ability to register a contact URI=20 > that get fair RFC3263 treatment, and therefore, makes 3rd > party registration significantly more challenging. (The > association between your flow and the AoR that gets made > using the outbound mechanism may not be what you want for 3pr). I think I understand your concern, but I don't think it applies in this case. Maybe I should explain the scenario in more detail. Suppose Bob's phone needs to register a line with Alice's AOR (for example, Bob is Alice's secretary - the normal example). Bob's phone can send a REGISTER with the following headers: To: sip:alice@example.com From: sip:bob@example.com Contact: sip:bobs-phone@bobs-desk.example.com This is a 3rd party registration (To !=3D From), but (and I think this is where the confusion occurs), the Contact header relates to the device that is sending the REGISTER (Bob's phone). I believe that this will still work with 'outbound' but I'd welcome comments if this is not the case. I agree with you that if you tried to register a Contact that didn't point to the same device (e.g. Bob trying to register a contact from Carol's phone), then outbound would break it. But this is the *other* understanding of 3rd party registration that Cullen originally commented on (I think). Given these two scenarios, I believe that Jonathan's original comment may have been ambiguous. To provide some context, I've appended an extract from the orignal message: > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > Jonathan Rosenberg > Sent: 15 December 2005 14:54 > To: Paul Kyzivat > Cc: Cullen Jennings; sip@ietf.org > Subject: Re: =1B$B%b%X=1B(B?: RE: [Sip] one question on the = authentication > forthird-party registration >=20 >=20 > I think these use cases are better handled through configuration of a=20 > forwarding feature that runs on the proxy. I had always=20 > envisioned xcap=20 > being used for this kind of thing too; we need only define schema for=20 > the forwarding numbers. >=20 > Note that, with draft-ietf-sip-outbound, third-party=20 > registrations are=20 > not possible anymore. I think thats a good thing; it allows us to=20 > separate routing from retargeting, per the discussion we had at ietf. >=20 > -Jonathan R. >=20 > Paul Kyzivat wrote: >=20 > > I'm not aware of any. But I've been discussing use cases for it for=20 > > years. One is for a boss/secretary arrangement, where the=20 > secretary can=20 > > register for the boss' AOR, but doesn't need the boss' own=20 > credentials=20 > > to do it. > >=20 > > Somebody has to be first. Go for it! > >=20 > > Paul > >=20 > > Cullen Jennings wrote: > >=20 > >> Has anyone build a proxy that allows the configuration of a policy=20 > >> that says > >> Bob is allowed to register for Alice's AOR? > >> Regards, Michael Procter _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Apr 05 12:04:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRAT0-0005gh-UT; Wed, 05 Apr 2006 12:02:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRASz-0005gb-EZ for sip@ietf.org; Wed, 05 Apr 2006 12:02:45 -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 1FRASz-0005HE-2G for sip@ietf.org; Wed, 05 Apr 2006 12:02:45 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 05 Apr 2006 09:02:44 -0700 X-IronPort-AV: i="4.04,90,1144047600"; d="scan'208"; a="422229162:sNHT34451708" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k35G2iYg011226; Wed, 5 Apr 2006 09:02:44 -0700 (PDT) Received: from 10.21.91.84 ([10.21.91.84]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Wed, 5 Apr 2006 16:02:43 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 05 Apr 2006 09:02:45 -0700 Subject: Re: [Sip] SIP MIB ietf-sip-mib comments - SipTransportProtocol From: Cullen Jennings To: "Kevin Lingle (klingle)" , Jean-Francois Mule , Samir Srivastava Message-ID: Thread-Topic: [Sip] SIP MIB ietf-sip-mib comments - SipTransportProtocol Thread-Index: AcY5j29dKQxxIed4SCWenzWDWU3cwgCDbzWgAWHdczABPKwkYAAB1NDAAC8iRbAEU4MgYwAALwMwABl5jWAAC8IrkAAC3oRM In-Reply-To: <0DEB933345E95A4083C4403CD2E7980C017B7956@xmb-rtp-211.amer.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: "sip@ietf.org" , "Romascanu, Dan \(Dan\)" , Juergen Schoenwaelder X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org works for me - it makes it clear how to a handle future extensions too On 4/5/06 7:42 AM, "Kevin Lingle (klingle)" wrote: > jean-francois, >=20 > i am fine with what you suggest. minor syntax issue though. > the new enum labels you propose cannot have hyphens. > therefore, they should be tlsTcp(4) and tlsSctp(5). >=20 > kevin >=20 > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: Wednesday, April 05, 2006 5:59 AM > To: Cullen Jennings (fluffy); Samir Srivastava > Cc: Romascanu, Dan (Dan); Juergen Schoenwaelder; Kevin Lingle (klingle); > sip@ietf.org > Subject: RE: [Sip] SIP MIB ietf-sip-mib comments - SipTransportProtocol >=20 > Cullen, and Samir, >=20 > Thx for the comments. > I will limit this response to your notes on SipTransportProtocol. >=20 > Cullen wrote: >> SipTransportProtocol >> It is weird to include TLS given we have TLS for TCP, SCTP, and might >> have for UDP too. >=20 > Good point. > Let me bring some context first, then propose some recommendations to the= wg > to close the comment. >=20 > First, this SipTransportProtocol is a textual-convention we designed base= d on > the transport layer descriptions in RFC 3261 (section 18, Via header - 20= .42). > A textual-convention is designed as a type and it can evolve as new value= s are > added, or as existing general values are refined to derive new specific > values. >=20 > --> Excerpts from RFC 3261 section 18: > - defines sip transport as UDP, TCP, SCTP, TLS over TCP > - defines transport ports as: > "5060 for UDP, TCP and SCTP, 5061 for TLS." (18.1.1) > "5061 for TLS over TCP" (18.2.1) > - 3261 vaguely mentions TLS over SCTP but the text is inconsistent as R= FC > 4168 pointed out and clarified. (side note: should RFC 4168 be considered= an > "update" of RFC3261 - it is not and may it should). >=20 > --> Excerpts from 3261 section 20.42: > - "Transport protocols defined here are "UDP", "TCP", "TLS", and "SCTP= ". > "TLS" means TLS over TCP. When a request is sent to a SIPS URI, the prot= ocol > still indicates "SIP", and the transport protocol is TLS." >=20 > --> Excerpts from RFC 4168: > transport =3D "UDP" / "TCP" / "TLS" / "SCTP" / "TLS-SCTP" > / other-transport >=20 > Not to excuse the way we looked at sip transport but, if you recall, we a= s > co-authors expressly wanted or were told to stick to 3261 to manage the s= cope > of the mib as many extensions were popping up. We did change the mib to a= lign > with this direction at some point. > Then 4168 clarified the BNF for transport and how to express TLS over SCT= P. >=20 >=20 > =3D=3D> Recommendations: > - rename 'tls(4)' to be 'tls-tcp(4)' and be explicit that bit 4 is for TL= S > over TCP per RFC 3261 > - add a new bit value for 'tls-sctp(5)' for TLS over SCTP and add a sente= nce > to say that transport of SIP over SCTP is defined in RFC 4168. > - add informative reference to RFC 4168 >=20 > The new rough text would look like this, feel free to propose enhancement= s: > SipTransportProtocol ::=3D TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "This convention is a bit map. Each bit represents a > transport protocol. If a bit has value 1, then that > selected transport protocol is in some way dependent > on the context of the object using this convention. > If a bit has value 0, then that transport protocol > is not selected. Combinations of bits can be > set when multiple transport protocols are selected. >=20 > bit 0 : a protocol other than those defined here. > bit 1 : User Datagram Protocol. > bit 2 : Transmission Control Protocol. > bit 3 : Stream Control Transmission Protocol. > bit 4 : Transport Layer Security Protocol over TCP. > bit 5 : Transport Layer Security Protocol over SCTP. > SYNTAX BITS { > other(0), -- none of the following > udp(1), > tcp(2), > sctp(3), > tls-tcp(4) > tls-sctp(5) -- RFC 4168 > } > -- REFERENCE "RFC 3261, Section 18" > -- REFERENCE "RFC 4168" >=20 > Comments welcome. > Jean-Fran=E7ois _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 05 12:07:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRAVL-00067L-SW; Wed, 05 Apr 2006 12:05:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRAVJ-00067G-Ui for sip@ietf.org; Wed, 05 Apr 2006 12:05:09 -0400 Received: from wproxy.gmail.com ([64.233.184.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRAVJ-0005aN-LF for sip@ietf.org; Wed, 05 Apr 2006 12:05:09 -0400 Received: by wproxy.gmail.com with SMTP id i23so1576840wra for ; Wed, 05 Apr 2006 09:05:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=dnimRhXlbO1UhuELThCSAgjhAg9dZyfsiaJE+rCwKOG7RjfIfjRxvd5Vo1HxsPnoqCsEgN3fHVOticEBBOu1zaABOAN+zVDX3/hFUYgW2kUJOys5PBauaVVIon1rl8CGjOHimZTrcSzrH/cI1GUH7SeZEdhamUo9pp/2d+JNed0= Received: by 10.65.157.19 with SMTP id j19mr974008qbo; Wed, 05 Apr 2006 09:05:09 -0700 (PDT) Received: by 10.65.150.9 with HTTP; Wed, 5 Apr 2006 09:05:08 -0700 (PDT) Message-ID: <296966940604050905p57df9428x280da2dbfa25d10f@mail.gmail.com> Date: Wed, 5 Apr 2006 10:05:09 -0600 From: "Alan Hawrylyshen" To: "Michael Procter" , "Cullen Jennings" Subject: Re: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip-mib comments) In-Reply-To: <592CA2F7E2BFBD4088AC87ECFF34BECE2D6D49@not01-mxc01.citel.com> MIME-Version: 1.0 References: <592CA2F7E2BFBD4088AC87ECFF34BECE2D6D49@not01-mxc01.citel.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: sip@ietf.org, "Romascanu, Dan \(Dan\)" , Jean-Francois Mule , Juergen Schoenwaelder , "Kevin Lingle \(klingle\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ahawrylyshen@ditechcom.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0695790892==" Errors-To: sip-bounces@ietf.org --===============0695790892== Content-Type: multipart/alternative; boundary="----=_Part_22663_263650.1144253109043" ------=_Part_22663_263650.1144253109043 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Disposition: inline Going back to the original thread here: > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > > Jonathan Rosenberg > > Sent: 15 December 2005 14:54 > > To: Paul Kyzivat > > Cc: Cullen Jennings; sip@ietf.org > > Subject: Re: $B%b%X(B?: RE: [Sip] one question on the authentication > > forthird-party registration > > > > > > I think these use cases are better handled through configuration of a > > forwarding feature that runs on the proxy. I had always > > envisioned xcap > > being used for this kind of thing too; we need only define schema for > > the forwarding numbers. > > > > Note that, with draft-ietf-sip-outbound, third-party > > registrations are > > not possible anymore. I think thats a good thing; it allows us to > > separate routing from retargeting, per the discussion we had at ietf. > > > > -Jonathan R. > > > > Paul Kyzivat wrote: > > > > > I'm not aware of any. But I've been discussing use cases for it for > > > years. One is for a boss/secretary arrangement, where the > > secretary can > > > register for the boss' AOR, but doesn't need the boss' own > > credentials > > > to do it. > > > > > > Somebody has to be first. Go for it! > > > > > > Paul > > > > > > Cullen Jennings wrote: > > > > > >> Has anyone build a proxy that allows the configuration of a policy > > >> that says > > >> Bob is allowed to register for Alice's AOR? > > >> Cullen; Yes. I have seen a couple vendors, one in the US and another in Europe that rely on this feature to be able to either implement the 'administrative registration' (secretary registering the boss' AoR) AND in order to permit some 3rd party device to register for arbitrary AoRs with 'magic / special' credentials. These credentials allow the third device to register as any one of a collection of AoRs that the proxy knows about. It is almost like a group credential. Cheers, Alan -- -- a d o t h a w r y l y s h e n a t g m a i l d o t c o m ------=_Part_22663_263650.1144253109043 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Disposition: inline

Going back to the original thread here:

> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of
> Jonathan Rosenberg
> Sent: 15 December 2005 14:54
> To: Paul Kyzivat
> Cc: Cullen Jennings; sip@ietf.org
> Subject: Re: $B%b%X(B?: RE: [Sip] one question on the authentication
> forthird-party registration
>
>
> I think these use cases are better handled through configuration of a
> forwarding feature that runs on the proxy. I had always
> envisioned xcap
> being used for this kind of thing too; we need only define schema for
> the forwarding numbers.
>
> Note that, with draft-ietf-sip-outbound, third-party
> registrations are
> not possible anymore. I think thats a good thing; it allows us to
> separate routing from retargeting, per the discussion we had at ietf.
>
> -Jonathan R.
>
> Paul Kyzivat wrote:
>
> > I'm not aware of any. But I've been discussing use cases for it for
> > years. One is for a boss/secretary arrangement, where the
> secretary can
> > register for the boss' AOR, but doesn't need the boss' own
> credentials
> > to do it.
> >
> > Somebody has to be first. Go for it!
> >
> >     Paul
> >
> > Cullen Jennings wrote:
> >
> >> Has anyone build a proxy that allows the configuration of a policy
> >> that says
> >> Bob is allowed to register for Alice's AOR?
> >>


Cullen;

Yes. I have seen a couple vendors, one in the US and another in Europe that rely on this feature to be able to either implement the 'administrative registration' (secretary registering the boss' AoR) AND in order to permit some 3rd party device to register for arbitrary AoRs with 'magic / special' credentials. These credentials allow the third device to register as any one of a collection of AoRs that the proxy knows about. It is almost like a group credential.

Cheers,
Alan

--
--
a d o t h a w r y l y s h e n a t g m a i l d o t c o m ------=_Part_22663_263650.1144253109043-- --===============0695790892== 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 --===============0695790892==-- From sip-bounces@ietf.org Wed Apr 05 12:24:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRAmZ-0005UI-K6; Wed, 05 Apr 2006 12:22:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRAmX-0005UD-Oh for sip@ietf.org; Wed, 05 Apr 2006 12:22:57 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRAmX-0006Tv-Fk for sip@ietf.org; Wed, 05 Apr 2006 12:22:57 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 05 Apr 2006 09:22:56 -0700 X-IronPort-AV: i="4.04,90,1144047600"; d="scan'208"; a="266776300:sNHT2414800824" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k35GMt1j002654; Wed, 5 Apr 2006 09:22:55 -0700 (PDT) Received: from 10.21.91.84 ([10.21.91.84]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Wed, 5 Apr 2006 16:22:55 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 05 Apr 2006 09:22:56 -0700 Subject: Re: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip-mib comments) From: Cullen Jennings To: Michael Procter , Jean-Francois Mule , "Kevin Lingle (klingle)" , "sip@ietf.org" Message-ID: Thread-Topic: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip-mib comments) Thread-Index: AcY5j29dKQxxIed4SCWenzWDWU3cwgCDbzWgAWHdczABPKwkYAAB1NDAAC8iRbAEU4MgYwAjT98AAAWt1EU= In-Reply-To: <592CA2F7E2BFBD4088AC87ECFF34BECE2D6D47@not01-mxc01.citel.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: "Romascanu, Dan \(Dan\)" , Juergen Schoenwaelder X-BeenThere: sip@ietf.org X-Mailman-Version: 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 way off track of anything to do with the MIB but ... We have two definitions of 3rd party reg. One is To != From. The other is that contact != source of the REGISTER message is coming from. Outbound does not work for contact = source case meaning that the extra things outbound provides won't work in this case - however it does not make that case any worse than it is today. Outbound works fine with the To != >From case. I will note that nothing to do with outbound, the contact != source is the cause of the huge DOS attacks that Robert, Alan, Et Al point out in their drafts. If we required CONSENT from the consent framework when doing contact != source, well it would solve the DOS problem. On 4/5/06 6:53 AM, "Michael Procter" wrote: > Cullen Jennings wrote: >> sipRegAlloowThirdParty - there are two definitions in common >> usage for 3rd >> party reg. This is one of them. However, I don't know of any >> deployment >> situations that allow this type of 3rd party reg. It is the >> other type that >> are allowed in practice. Do we need to this at all? Do we >> need to update? > > At the risk of raising a tangent, this form of 3rd Party > Registration (that is to say when the To header differs from > the From header in the REGISTER) is used in the current > Bridged Line Appearance draft (draft-anil-sipping-bla-02). > > Jonathan Rosenburg mentioned on this list (Dec 15, 2005) that > draft-ietf-sip-outbound breaks 3rd party registrations, but > I can't find the paragraph in the draft that states this after > a brief reading. Para 4.2.1 appears to relate to the *other* > meaning of 3rd party registration. > > Regards, > > Michael Procter _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Apr 05 12:28:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRApg-0006nm-1y; Wed, 05 Apr 2006 12:26:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRApe-0006ng-94 for sip@ietf.org; Wed, 05 Apr 2006 12:26:10 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRApd-0006fu-VT for sip@ietf.org; Wed, 05 Apr 2006 12:26:10 -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 k35GQ5m4022372; Wed, 5 Apr 2006 11:26:05 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 5 Apr 2006 17:26:04 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0129681E3@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Gary Gan , sip@ietf.org Subject: RE: [Sip] draft-ietf-sipping-conference-package - Media Mixing Date: Wed, 5 Apr 2006 17:26:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff 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="===============0910535402==" 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. --===============0910535402== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C658CD.A110CA90" 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_01C658CD.A110CA90 Content-Type: text/plain Please note that the conference package has been created by SIPPING and any discussion should take place on that list. Please also that work to extend this package to meet XCON extra capabilities has been allocated to XCON, and should be discussed on the XCON list. regards Keith -----Original Message----- From: Gary Gan [mailto:ggan@cliquecom.com] Sent: 04 April 2006 15:51 To: sip@ietf.org Subject: [Sip] draft-ietf-sipping-conference-package - Media Mixing In conference info package, it contains a lot of detailed information to share among participants. It should add more information to the tag to help conference media mixing. In the SIP conference, imagine the multi-unicast media mixing scenario. Each participant need to share the media listening IP+PORT to the others. Since the Focus knows everybody's rtp/rtcp/codec info, on the conference info package, it should share it in the tag. Also it need to a new attribute like type, to define the type of media mixing the participant should anticipate. Gary Gan Sr. Software Developer Clique Communications, LLC 205 Rockingham Row Princeton Forrestal Village Princeton, NJ 08540 Phone: 609-564-0206 ------_=_NextPart_001_01C658CD.A110CA90 Content-Type: text/html
Please note that the conference package has been created by SIPPING and any discussion should take place on that list.
 
Please also that work to extend this package to meet XCON extra capabilities has been allocated to XCON, and should be discussed on the XCON list.
 
regards
 
Keith
-----Original Message-----
From: Gary Gan [mailto:ggan@cliquecom.com]
Sent: 04 April 2006 15:51
To: sip@ietf.org
Subject: [Sip] draft-ietf-sipping-conference-package - Media Mixing

In conference info package, it contains a lot of detailed information to share among participants. It should add more information to the <media> tag to help conference media mixing. In the SIP conference, imagine the multi-unicast media mixing scenario. Each participant need to share the media listening IP+PORT to the others.

 

Since the Focus knows everybody’s rtp/rtcp/codec info, on the conference info package, it should share it in the <media> tag. Also it need to a new attribute like <media-mixing> type, to define the type of media mixing the participant should anticipate.

Gary Gan
Sr. Software Developer

Clique Communications, LLC
205 Rockingham Row
Princeton Forrestal Village
Princeton, NJ 08540
Phone: 609-564-0206

 

------_=_NextPart_001_01C658CD.A110CA90-- --===============0910535402== 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 --===============0910535402==-- From sip-bounces@ietf.org Wed Apr 05 12:44:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRB5U-0003Mk-BT; Wed, 05 Apr 2006 12:42:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRB5S-0003IB-DU for sip@ietf.org; Wed, 05 Apr 2006 12:42:30 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRB5Q-0007Jp-3o for sip@ietf.org; Wed, 05 Apr 2006 12:42:30 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 05 Apr 2006 09:42:27 -0700 X-IronPort-AV: i="4.04,90,1144047600"; d="scan'208"; a="1792018153:sNHT32339548" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k35GgRYg029654; Wed, 5 Apr 2006 09:42:27 -0700 (PDT) Received: from 10.21.91.84 ([10.21.91.84]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Wed, 5 Apr 2006 16:42:27 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 05 Apr 2006 09:42:28 -0700 Subject: Re: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip-mib comments) From: Cullen Jennings To: Michael Procter , Jean-Francois Mule , "Kevin Lingle (klingle)" , "sip@ietf.org" Message-ID: Thread-Topic: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip-mib comments) Thread-Index: AcY5j29dKQxxIed4SCWenzWDWU3cwgCDbzWgAWHdczABPKwkYAAB1NDAAC8iRbAEU4MgYwAjT98AAAWt1EUAAK6k4w== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: "Romascanu, Dan \(Dan\)" , Juergen Schoenwaelder X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Fixing a very confusing typo I put in message below - thanks to Spencer for catching my blunder On 4/5/06 9:22 AM, "Cullen Jennings" wrote: > This is way off track of anything to do with the MIB but ... > > We have two definitions of 3rd party reg. One is To != From. The other is that > contact != source of the REGISTER message is coming from. > > Outbound does not work for contact = source case meaning that the extra things This should have been contact != source - sorry > outbound provides won't work in this case - however it does not make that case > any worse than it is today. Outbound works fine with the To != From case. > > I will note that nothing to do with outbound, the contact != source is the > cause of the huge DOS attacks that Robert, Alan, Et Al point out in their > drafts. If we required CONSENT from the consent framework when doing contact > != source, well it would solve the DOS problem. > > > On 4/5/06 6:53 AM, "Michael Procter" wrote: > >> Cullen Jennings wrote: >>> sipRegAlloowThirdParty - there are two definitions in common >>> usage for 3rd >>> party reg. This is one of them. However, I don't know of any >>> deployment >>> situations that allow this type of 3rd party reg. It is the >>> other type that >>> are allowed in practice. Do we need to this at all? Do we >>> need to update? >> >> At the risk of raising a tangent, this form of 3rd Party >> Registration (that is to say when the To header differs from >> the From header in the REGISTER) is used in the current >> Bridged Line Appearance draft (draft-anil-sipping-bla-02). >> >> Jonathan Rosenburg mentioned on this list (Dec 15, 2005) that >> draft-ietf-sip-outbound breaks 3rd party registrations, but >> I can't find the paragraph in the draft that states this after >> a brief reading. Para 4.2.1 appears to relate to the *other* >> meaning of 3rd party registration. >> >> Regards, >> >> Michael Procter _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Apr 05 13:06:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRBRG-0003yR-Ci; Wed, 05 Apr 2006 13:05:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRBRE-0003yJ-ID for sip@ietf.org; Wed, 05 Apr 2006 13:05:00 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRBRD-0007qZ-7x for sip@ietf.org; Wed, 05 Apr 2006 13:05:00 -0400 Received: from [10.10.2.211] (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 k35H5aU1031576 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 5 Apr 2006 12:05:37 -0500 In-Reply-To: <3A6671F8B360D34FAAC98771AD4D9990029D9AD6@DEDUS-WICL01M01.vf-de.internal.vodafone.com> References: <3A6671F8B360D34FAAC98771AD4D9990029D9AD6@DEDUS-WICL01M01.vf-de.internal.vodafone.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Question on Service Route Discovery Procedure during Registration Date: Wed, 5 Apr 2006 12:05:32 -0500 To: "Lu, Yang, VF-DE" X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) 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 Apr 3, 2006, at 7:09 AM, Lu, Yang, VF-DE wrote: > > Dear All > > RFC 3261 Section 8.2.4 "Applying Extensions" says > > "A UAS that wishes to apply some extension when generating the > response > MUST NOT do so unless support for that extension is indicated in the > Supported header field in the request". > > However, the Service Route discovery procedure during Registration > described in RFC 3608 does not follow this as shown in the example in > Section 6. > > Are there any reasons for that and for the fact that there is no > need to > define an Option Tag for Service Route? I remember debating this at the time that RFC 3608 was being edited, but do not recall why we ended up with the text therein. Looking at it from the perspective of history, at the moment it appears that you're absolutely right and that RFC 3608 is inconsistent with RFC 3261 in this respect. I do recall that there was a decision to not provide an option-tag for Service-Route related to the extremely "optional" nature of the information conveyed by Service-Route, which is actually completely orthogonal to the operation of the REGISTER request itself. We didn't want the UAC to be able to "demand" a service-route. With some deployment experience behind us, I'm not sure that this was really an important issue. Jonathan is very fond of saying that both RFC 3608 and RFC 3327 are "broken, or at best horribly underspecified". I've been planning to rev them once GRUU and the route-construction draft stabilize, although its also been proposed that the route-construction draft might actually replace both 3608 and 3327. In either case, we should address this issue at that time. Question to the WG: Should we post an errata for RFC 3608 to the RFC Editor page discussing 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 Wed Apr 05 13:51:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRC88-0008BN-20; Wed, 05 Apr 2006 13:49:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRC86-0008B9-Ey for sip@ietf.org; Wed, 05 Apr 2006 13:49:18 -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 1FRARx-0005Bu-FM for sip@ietf.org; Wed, 05 Apr 2006 12:01:41 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FRACF-00039v-Mw for sip@ietf.org; Wed, 05 Apr 2006 11:45:30 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4569EFDB for ; Wed, 5 Apr 2006 17:45:23 +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, 5 Apr 2006 17:45:22 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 17:45:22 +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 Date: Wed, 5 Apr 2006 17:45:22 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1CCD@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Outbound: Maximum number of flows reached - how to reject? Thread-Index: AcZYx/J8R0A7zS4OSgqYcuhY2xpWUw== From: "Christer Holmberg \(JO/LMF\)" To: X-OriginalArrivalTime: 05 Apr 2006 15:45:22.0683 (UTC) FILETIME=[F3184CB0:01C658C7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -2.6 (--) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Sip] Outbound: Maximum number of flows reached - how to reject? X-BeenThere: sip@ietf.org X-Mailman-Version: 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, Chapter 6.1 of the outbound draft says: "The registrar MUST be prepared to receive, simultaneously for the same AOR, some registrations that use instance-id and reg-id and some that do not." My question is: what error response code shall the registrar use if it does not accept a flow for a non-temporary reason, for example due to the fact that the number of supported flows for a specific instance-id has reached the maximum value (configured or "hard coded")? Chapter 4.2 talks about the usage of 503, which is ok for if the reason for the rejection is "temporary". But, would that be usable also in non-temporary cases (without a Retry-After header), or should we use a 4/6xx response? I think it would be good to specify which value to use. The problem with 503 is that it could cause a re-sending of the REGISTER later, but if the registrar simply doesn't accept more flows for the instance-id the UA should not re-send (until other flows have been removed).=20 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 Apr 05 14:07:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRCNh-0005yZ-9o; Wed, 05 Apr 2006 14:05:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRCNg-0005VC-0u for sip@ietf.org; Wed, 05 Apr 2006 14:05:24 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRCMD-0001k9-O3 for sip@ietf.org; Wed, 05 Apr 2006 14:03:54 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 05 Apr 2006 07:42:22 -0700 X-BrightmailFiltered: true X-IronPort-AV: i="4.04,90,1144047600"; d="scan'208"; a="25241222:sNHT37428040" 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 k35EgOWe024677; Wed, 5 Apr 2006 10:42:24 -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); Wed, 5 Apr 2006 10:42:24 -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] SIP MIB ietf-sip-mib comments - SipTransportProtocol Date: Wed, 5 Apr 2006 10:42:23 -0400 Message-ID: <0DEB933345E95A4083C4403CD2E7980C017B7956@xmb-rtp-211.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP MIB ietf-sip-mib comments - SipTransportProtocol Thread-Index: AcY5j29dKQxxIed4SCWenzWDWU3cwgCDbzWgAWHdczABPKwkYAAB1NDAAC8iRbAEU4MgYwAALwMwABl5jWAAC8IrkA== From: "Kevin Lingle \(klingle\)" To: "Jean-Francois Mule" , "Cullen Jennings \(fluffy\)" , "Samir Srivastava" X-OriginalArrivalTime: 05 Apr 2006 14:42:24.0431 (UTC) FILETIME=[2714CBF0:01C658BF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: sip@ietf.org, "Romascanu, Dan \(Dan\)" , Juergen Schoenwaelder X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org jean-francois, i am fine with what you suggest. minor syntax issue though. the new enum labels you propose cannot have hyphens. =20 therefore, they should be tlsTcp(4) and tlsSctp(5). kevin -----Original Message----- From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 Sent: Wednesday, April 05, 2006 5:59 AM To: Cullen Jennings (fluffy); Samir Srivastava Cc: Romascanu, Dan (Dan); Juergen Schoenwaelder; Kevin Lingle (klingle); = sip@ietf.org Subject: RE: [Sip] SIP MIB ietf-sip-mib comments - SipTransportProtocol Cullen, and Samir, Thx for the comments. I will limit this response to your notes on SipTransportProtocol. Cullen wrote: > SipTransportProtocol > It is weird to include TLS given we have TLS for TCP, SCTP, and might=20 > have for UDP too. Good point. Let me bring some context first, then propose some recommendations to = the wg to close the comment. First, this SipTransportProtocol is a textual-convention we designed = based on the transport layer descriptions in RFC 3261 (section 18, Via = header - 20.42). A textual-convention is designed as a type and it can = evolve as new values are added, or as existing general values are = refined to derive new specific values. --> Excerpts from RFC 3261 section 18: - defines sip transport as UDP, TCP, SCTP, TLS over TCP - defines transport ports as:=20 "5060 for UDP, TCP and SCTP, 5061 for TLS." (18.1.1) "5061 for TLS over TCP" (18.2.1) - 3261 vaguely mentions TLS over SCTP but the text is inconsistent as = RFC 4168 pointed out and clarified. (side note: should RFC 4168 be = considered an "update" of RFC3261 - it is not and may it should). --> Excerpts from 3261 section 20.42: - "Transport protocols defined here are "UDP", "TCP", "TLS", and = "SCTP". "TLS" means TLS over TCP. When a request is sent to a SIPS URI, = the protocol still indicates "SIP", and the transport protocol is TLS." --> Excerpts from RFC 4168: transport =3D "UDP" / "TCP" / "TLS" / "SCTP" / "TLS-SCTP" / other-transport Not to excuse the way we looked at sip transport but, if you recall, we = as co-authors expressly wanted or were told to stick to 3261 to manage = the scope of the mib as many extensions were popping up. We did change = the mib to align with this direction at some point. Then 4168 clarified the BNF for transport and how to express TLS over = SCTP. =3D=3D> Recommendations: - rename 'tls(4)' to be 'tls-tcp(4)' and be explicit that bit 4 is for = TLS over TCP per RFC 3261 - add a new bit value for 'tls-sctp(5)' for TLS over SCTP and add a = sentence to say that transport of SIP over SCTP is defined in RFC 4168. - add informative reference to RFC 4168 The new rough text would look like this, feel free to propose = enhancements: SipTransportProtocol ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "This convention is a bit map. Each bit represents a transport protocol. If a bit has value 1, then that selected transport protocol is in some way dependent on the context of the object using this convention. If a bit has value 0, then that transport protocol is not selected. Combinations of bits can be set when multiple transport protocols are selected. bit 0 : a protocol other than those defined here. bit 1 : User Datagram Protocol. bit 2 : Transmission Control Protocol. bit 3 : Stream Control Transmission Protocol. bit 4 : Transport Layer Security Protocol over TCP. bit 5 : Transport Layer Security Protocol over SCTP. = SYNTAX BITS { other(0), -- none of the following udp(1), tcp(2), sctp(3), tls-tcp(4) tls-sctp(5) -- RFC 4168 } -- REFERENCE "RFC 3261, Section 18" -- REFERENCE "RFC 4168" Comments welcome. Jean-Fran=E7ois _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 05 14:17:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRCXt-0001Wj-4o; Wed, 05 Apr 2006 14:15:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRCXr-0001WL-AX for sip@ietf.org; Wed, 05 Apr 2006 14:15:55 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRCXr-00029s-0d for sip@ietf.org; Wed, 05 Apr 2006 14:15:55 -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 k35IFpOB024433; Wed, 5 Apr 2006 13:15:52 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 5 Apr 2006 19:15:51 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB012968217@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Jeroen van Bemmel , "Michael Hammer (mhammer)" , Bob Penfield , "Elwell, John" , sip@ietf.org Subject: RE: [Sip] Connected-identity and changing the To header fieldinar esponse Date: Wed, 5 Apr 2006 19:15:42 +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: 22bbb45ef41b733eb2d03ee71ece8243 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 (personal preference at the moment) I guess I would like to see working group decisions that have impact on SIP deliverables, rather than general statements of principle. It would seem to me that there are various bits of text spread throughout RFC 3261 that reflect this interoperability issue, including quite a few requirements. Perhaps you should see what support you get for specific proposals to modify such text, presumably based on an i-d that updates part of RFC 3261 (in the same manner as e.g. RFC 4320 does). regards Keith > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: 04 April 2006 20:22 > To: Michael Hammer (mhammer); Bob Penfield; Elwell, John; sip@ietf.org > Subject: Re: [Sip] Connected-identity and changing the To header > fieldinaresponse > > > big humm on that > > ----- Original Message ----- > From: "Michael Hammer (mhammer)" > To: "Bob Penfield" ; "Elwell, John" > ; > Sent: Tuesday, April 04, 2006 4:00 PM > Subject: RE: [Sip] Connected-identity and changing the To header > fieldinaresponse > > > It has now been about 4 years since RFC-3261 was published. > Is it about time to declare RFC-2543 really obsolete and > end discussion of backwards compatibility with it? > > Mike > > > > -----Original Message----- > > From: Bob Penfield [mailto:BPenfield@acmepacket.com] > > Sent: Tuesday, April 04, 2006 7:58 AM > > To: Elwell, John; sip@ietf.org > > Subject: Re: [Sip] Connected-identity and changing the To > > header field inaresponse > > > > The issue with changing the To in a response is backward > > compatibility with RFC 2543 which does use the To for > > transaction matching. RFC 2543 section > > 1.4.3 says: > > > > All responses to a request contain the same values in > > the Call-ID, CSeq, To, and From fields (with the possible > > addition of a tag in the To field (section 6.37)). > > This allows responses to be matched with requests. > > > > cheers, > > (-:bob > > > > Robert F. Penfield > > Chief Software Architect > > Acme Packet, Inc. > > 71 Third Avenue > > Burlington, MA 01803 > > bpenfield@acmepacket.com > > > > ----- Original Message ----- > > From: "Elwell, John" > > To: > > Sent: Tuesday, April 04, 2006 2:45 AM > > Subject: [Sip] Connected-identity and changing the To header > > field in aresponse > > > > > > > During discussion of draft-elwell-connected-identity in Dallas, > > > somebody put forward the opinion that it would be dangerous > > to change > > > the To header field URI in a response (i.e., make it > different from > > > the From header field URI in the request). My assumption at > > the time > > > was that it would undermine the transaction concept in SIP, yet > > > reading what RFC3261 has to say about transactions, the > > value of the > > > To header field URI in a response does not appear to be > involved in > > > coupling a response to a request. Therefore I assume the > person who > > > indicated the danger (which was not challenged at the > > > meeting) has other reasons in mind. I would greatly appreciate > > > opinions on the wisdom or otherwise of allowing the To > header field > > > URI to change. It seems that from discussion of connected-identity > > > there is a desire from some parts of the community to include an > > > (unauthenticated) identity in a response. > > > > > > 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 > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 05 16:33:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FREew-0004kj-PX; Wed, 05 Apr 2006 16:31:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FREev-0004ke-LT for sip@ietf.org; Wed, 05 Apr 2006 16:31:21 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FREeu-0003Qd-BL for sip@ietf.org; Wed, 05 Apr 2006 16:31:21 -0400 Received: from [204.244.68.63] (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 k35KVtc1000562 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 5 Apr 2006 15:31:56 -0500 In-Reply-To: <014a01c65825$d5e44920$6501a8c0@tarragona> References: <014a01c65825$d5e44920$6501a8c0@tarragona> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7A2D2648-2318-4A80-8688-CED31D6C34E9@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] draft-ietf-sipping-conference-package : MTU Date: Wed, 5 Apr 2006 15:31:13 -0500 To: Tarun Kapoor X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 4, 2006, at 3:24 PM, Tarun Kapoor wrote: > However, the UA should decide whether it will support TCP or UDP at > the > beginning of a session and stick to it until it initiates another > session. > It's generally safer to use TCP if you know there is a chance of a SIP > packet > MTU. I'd like to restate this: "It's generally safer to use TCP if you know there is a chance of a SIP packet." -- 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 Apr 05 16:50:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FREvy-0004Gm-0v; Wed, 05 Apr 2006 16:48:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FREvw-0004Gh-33 for sip@ietf.org; Wed, 05 Apr 2006 16:48:56 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FREvu-00045H-6D for sip@ietf.org; Wed, 05 Apr 2006 16:48:56 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IX900G01OICYG@siemenscomms.co.uk> for sip@ietf.org; Wed, 05 Apr 2006 21:49:25 +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 <0IX900D6LOIC0O@siemenscomms.co.uk>; Wed, 05 Apr 2006 21:49:24 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 05 Apr 2006 21:48:52 +0100 Content-return: allowed Date: Wed, 05 Apr 2006 21:48:05 +0100 From: "Elwell, John" Subject: RE: [Sip] Connected-identity and changing the To header field ina response To: Roland Jesske , "Christer Holmberg (JO/LMF)" , "Peterson, Jon" , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670896A542@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.5 (/) X-Scan-Signature: 9a9ddb14fac983e71b59f23b52a45b4e 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 Roland, Yes, there was indeed a misunderstanding, but my draft was not written = with TISPAN requirements in mind. It was written to solve the problem of authenticated identity, or rather to extend the present concept of the Identity header to mid-dialog requests and show how that can be used to solve certain problems. The Terminating Identity Presentation (TIP) requirement from TISPAN = needs to be addressed by some other means. I don't think modifying the To header = is appropriate. Whereas RFC 3261 anticipates deprecating fixed To/From = header field URIs throughout a dialog (i.e., it anticipates that these will be allowed to change mid-dialog), it says nothing to warn of any future = removal of the requirement that the To header field URI in the response be the = same as that in the request. Therefore it seems that whatever solution you adopt for solving the = TISPAN TIP problem, it would have little in common with the connected-identity draft. John > -----Original Message----- > From: Roland Jesske [mailto:roland.jesske@web.de]=20 > Sent: 05 April 2006 14:33 > To: Christer Holmberg (JO/LMF); Elwell, John; Peterson, Jon;=20 > sip@ietf.org > Subject: RE: [Sip] Connected-identity and changing the To=20 > header field ina response >=20 > John, > there it looks like a misunderstanding. Thought all=20 > requirements from IETF and TISPAN can be solved within your draft. >=20 > As you saw he additional connected identity is a requirement=20 > comming from TISPAN and that was discussed in also in=20 > Vancover. In draft-sasaki-sipping-tispan-adhoc-summary-00.txt=20 > it is mentioned. >=20 > Terminating Identification Presentation(TIP)- The working group > requests that this requirement be better defined and = documented. > It is also suggested that TISPAN consider reading > draft-rosenberg-sip-identity-privacy-00 as it may solve the > problem of calling into an 800 number, getting an operator, and > being able to call back that operator and still protect the > privacy of the operator. > In addition, work is progressing on > draft-elwell-sip-connected-identity-00. >=20 > So using the PAI does not need to go deeper into=20 > draft-rosenberg-sip-identity-privacy-00, but looking into your draft. = > And looking within your draft using the dialogUriChange=20 > element we thought we have the solution if this can be done=20 > within the final Response of the initial INVITE.=20 >=20 > Best Regards >=20 > Roland >=20 >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: "Elwell, John" > > Gesendet: 05.04.06 14:56:20 > > An: sip@ietf.org > > Betreff: RE: [Sip] Connected-identity and changing the To=20 > header field ina response >=20 >=20 > > Christer, > >=20 > > This "additional connected number" is not a requirement=20 > that I have been > > trying to address. Was this among the requirements that=20 > TISPAN brought into > > the IETF recently? > >=20 > > John > >=20 > > > -----Original Message----- > > > From: Christer Holmberg (JO/LMF)=20 > > > [mailto:christer.holmberg@ericsson.com]=20 > > > Sent: 05 April 2006 08:34 > > > To: Elwell, John; Peterson, Jon; sip@ietf.org > > > Subject: RE: [Sip] Connected-identity and changing the To=20 > > > header field inaresponse > > >=20 > > > =20 > > > Hi, > > >=20 > > > In PSTN terms we are talking about that the TO header shall=20 > > > be mapped to > > > the additional connected number, and that does NOT need to be=20 > > > authorized > > > in the same way as the connected number. > > >=20 > > > And, whether the interworking node sends this value to PSTN=20 > > > is of course > > > based on local policy, based on trust etc. > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > > > ________________________________ > > >=20 > > > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > > > Sent: 5. huhtikuuta 2006 10:01 > > > To: Peterson, Jon; sip@ietf.org > > > Subject: RE: [Sip] Connected-identity and changing the To=20 > header field > > > inaresponse > > >=20 > > >=20 > > > Jon, > > > =20 > > > Thanks for this excellent summary of the issue, which I fully=20 > > > agree with > > > and which unfortunately seems to need restating at regular=20 > > > intervals. It > > > appears that the chief motivation of those asking for=20 > something in the > > > response is to facilitate interworking with PSTN (by=20 > > > including it in the > > > 200 response so that it can be mapped directly to the=20 > PSTN "connected" > > > message). As you say, such a response is always going to be > > > unauthenticated, and I don't think that meets the=20 > requirements of PSTN > > > interworking. Far better to figure out a way of using an=20 > authenticated > > > connected identity in an UPDATE message for mapping to=20 > PSTN connected > > > identity. > > > =20 > > > Of course, in trusted networks there may be other means for=20 > > > ensuring the > > > authenticity of an identity in a response, just as there is=20 > > > in a request > > > using P-Asserted-Identity. Unfortunately RFC3325 is=20 > unclear on the use > > > of PAI in responses, although in practice I think it is=20 > used and is > > > probably OK if the last hop is secured by TLS so that previous > > > authentication of the UAS can be relied on for making the=20 > assertion. I > > > think if those trusted networks really need a solution=20 > for response > > > identity, PAI would be a better avenue to explore (taking=20 > into account > > > the risks). But not for the Internet. I am becoming more and more > > > convinced that diluting the connected-identity draft with a weak > > > solution for response identity would be the wrong way to go. > > > =20 > > > John > > >=20 > > >=20 > > > ________________________________ > > >=20 > > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz]=20 > > > Sent: 05 April 2006 02:05 > > > To: Elwell, John; sip@ietf.org > > > Subject: RE: [Sip] Connected-identity and changing the To header > > > field in aresponse > > > =09 > > > =09 > > > Yes, I was asked for clarification on this point after the > > > meeting, and I'll be providing it here. As you surmised, it=20 > > > is not that > > > RFC3261 relies on the addr-spec of the To or From header field = for > > > transaction identification, or something. In fact, I would have > > > essentially the same concerns about any proposal that provided an > > > additional header (say, a 'Connected-Party' header) in=20 > responses to > > > dialog-forming requests which was understood to clobber=20 > the To header > > > field and identify the AoR of the party who was reached after > > > retargeting of the request took place. > > > =20 > > > Starting with the goals of this approach: what sort of UAC > > > decisions or behavior do we hope to enable through=20 > sending a response > > > with a modified To header field? As far as I can=20 > understand, we either > > > want to render this AoR to the user of a UAC (so the user=20 > can react in > > > one way or another), or input the AoR to some sort of=20 > policy manager > > > (e.g. blacklist/whitelist) that might make a decision=20 > about whether or > > > not the session should continue -prior- to session=20 > > > establishment. If we > > > don't care about this occurring prior to session establishment, = of > > > course, then we could go with the connected-identity=20 > draft as it is > > > written today. > > > =20 > > > A little refresher on my sipping-retarget draft: The core > > > problem with any scheme for connected party is figuring=20 > out how you'd > > > decide whether or not a particular respondent is authorized.=20 > > > This is the > > > argument of 2.2.1 of sipping-retarget, the "unanticipated=20 > respondent" > > > problem. When we think about what sorts of policy decisions=20 > > > we expect a > > > human or automata to make when receiving a response with identity > > > information, we have to acknowledge that the UAC has no=20 > way of knowing > > > which respondents are or are not authorized to respond to the=20 > > > request in > > > question. Since the UAC has no insight into any=20 > retargeting that has > > > taken place, the UAC has to assume that virtually any=20 > response is a > > > potentially legitimate one. As such, there is little room for any > > > meaningful policy decision when receiving a response.=20 > This problem is > > > further compounded by the fact that the UAS may have=20 > several possible > > > legitimate AoRs it could claim (I have a UA that=20 > registers its contact > > > address under 3 separate SIP services simultaneously), and of=20 > > > course the > > > fact that AoRs may be pretty uninformative (e.g. > > > sip:user31@freesipservice.example.com), all of which complicate > > > authorization decisions. Solving this problem is on the same=20 > > > footing as > > > solving the request-history problem set. > > > =20 > > > With that background, the problems with providing this connected > > > party information in responses (via the To header or what=20 > > > have you) are > > > roughly as follows: > > > =20 > > > a) The "unanticipated respondent" problem is especially an issue > > > for response identity because not all responses are=20 > success responses. > > > If you end up connecting to a party (receiving a 200), you can > > > potentially rely on human factors to help you identify who you = are > > > talking to (after all, Carol can always answer Bob's phone=20 > > > regardless of > > > who SIP thinks you connected to) and/or use the connected party > > > information to change how you might address the party on the=20 > > > other side. > > > With a 403 response, you are in a very different=20 > predicament - how is > > > UAC or user behavior supposed to change based on the connected = URI > > > attributed to a 403, given the unanticipated respondent=20 > problem? For > > > provisional responses, the issues become even worse - we=20 > then get into > > > the wonders of forking, multiple provisional responses=20 > from multiple > > > sources asserting different To header fields - in short,=20 > nothing which > > > makes it any easier to render a "responding" AoR to a user,=20 > > > for example. > > > Response identity, in so far as it deals with non-final,=20 > > > non-successful > > > responses, opens up the "unconnected party" problem set. I=20 > > > think this is > > > just the wrong framing of the problem. You want to know who you > > > connected to, not who you didn't connect to. > > > =20 > > > b) Getting a signature over the To header field in responses > > > would be difficult. In full awareness of Mr. Elwell's=20 > note below that > > > certain parties are interested in "(unauthenticated) identity in = a > > > response", if this information is going to be put to any=20 > > > purpose, cause > > > any change in human or UAC behavior, I have a hard time seeing = how > > > anyone could defend it being unsecured. If you want a human or an > > > automata to make a policy decision based on the AoR in=20 > the To header > > > field of the response, some sort of response identity=20 > > > signature would be > > > necessary to prevent obvious impersonation attacks=20 > designed to thwart > > > authorization decisions. With all due respect to the authors of > > > draft-cao-sip-response-identity/auth, I'm not sure this problem = is > > > readily solved. Making sure that an appropriate=20 > authentication service > > > is in the path of responses is problematic, since responses must > > > traverse exactly the same path as requests. I played around=20 > > > with this a > > > lot in the early phases of SIP identity, and at the end=20 > of the day, I > > > had to conclude that the only way to make this work was=20 > to eliminate > > > retargeting. Since providing connected-identity in=20 > responses assumes > > > that retargeting has taken place, it wouldn't exactly be=20 > > > getting off on > > > the right foot. Constraining inbound request routing to a=20 > domain such > > > that responses will traverse an authentication service, or=20 > > > forcing a UAS > > > to participate in the Identity scheme, is likely to=20 > require mandatory > > > option-tags or comparable mechanisms that will limit the=20 > applicability > > > of response identity and more or less eliminate its=20 > opportunistic use. > > > =20 > > > c) The inability to reject a response. Take the easiest case - > > > let's say that the UAC receives a final success response,=20 > say a 200 > > > response, with a modified To header field from a party that is > > > blacklisted by UAC policy. What exactly is the UAC supposed=20 > > > to do? Send > > > a 403? One cannot reject responses. Maybe a CANCEL? As=20 > section 9.1 of > > > RFC3261 says, CANCEL "has no effect on requests that have already > > > generated a final response." Drop the request on the floor?=20 > > > You'll just > > > receive retransmissions. All you can do is ACK it, since the=20 > > > dialog has > > > already been formed, and then send a BYE. In other words,=20 > a session > > > -will- be established, there simply isn't an opportunity=20 > for policy to > > > be put into effect prior to session establishment. Also,=20 > consider the > > > need for the new responses defined in the sip-identity=20 > draft, like say > > > the 438 response - if the UAC receives a 200 response with a=20 > > > potentially > > > repairable error in the Identity header, how can it=20 > express that error > > > to the UAS, since it can't send responses to a response? > > > =20 > > > Given the above, why does the UAC need to know who has been > > > reached in the response, rather than in a request after=20 > the dialog has > > > been formed? As (c) illustrates, in the 200 response case a=20 > > > session will > > > be established anyway, so sharing the identity of the=20 > connected party > > > after session establishment doesn't actually miss some=20 > opportunity for > > > applying policy - moreover, an UPDATE or similar request=20 > that provides > > > the connected-identity information could be rejected by the > > > session-originating UA in a manner that is helpful to the > > > session-terminating UA (e.g., a 438 response could be=20 > sent). If we go > > > with the mechanism in the connected-identity draft, problem (b) > > > disappears, since request routing is far more malleable=20 > than response > > > routing. Additionally, the connected-identity draft=20 > wisely does not > > > attempt to solve "unconnected party" problems from (a),=20 > which are the > > > least tractable of the unanticipated respondent problems. Rather, > > > connected-identity provides an indication more along the=20 > > > lines of, "your > > > dialog was established, however that might have happened,=20 > and this is > > > who is on the other side". > > > =20 > > > Furthermore, any solution that tried to put the > > > connected-identity information into responses would be=20 > providing an > > > imprimatur of legitimacy to those responses - presuming they had = a > > > signature, UACs would validate it, and provided it=20 > checked out, they > > > would be tempted say "this is a legitimate response."=20 > Nothing could be > > > further from the truth, as sipping-retarget illustrates.=20 > Legitimacy of > > > responses cannot be determined by UACs in the absence of=20 > > > something like > > > request-history. > > > =20 > > > Finally, I like having one Identity header, and for the meaning > > > of that Identity header to *always* be that it is a=20 > signature over the > > > From header field issued by the domain identified by the host=20 > > > portion of > > > the addr-spec of the From header field. The current=20 > connected-identity > > > header draft provides that property. > > > =20 > > > Jon Peterson > > > NeuStar, Inc. > > >=20 > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > Sent: Monday, April 03, 2006 11:46 PM > > > To: sip@ietf.org > > > Subject: [Sip] Connected-identity and changing the To > > > header field in aresponse > > > =09 > > > =09 > > >=20 > > > During discussion of draft-elwell-connected-identity in > > > Dallas, somebody put forward the opinion that it would be=20 > dangerous to > > > change the To header field URI in a response (i.e., make=20 > it different > > > from the From header field URI in the request). My=20 > assumption at the > > > time was that it would undermine the transaction concept=20 > in SIP, yet > > > reading what RFC3261 has to say about transactions, the value=20 > > > of the To > > > header field URI in a response does not appear to be involved in > > > coupling a response to a request. Therefore I assume the=20 > person who > > > indicated the danger (which was not challenged at the=20 > > > meeting) has other > > > reasons in mind. I would greatly appreciate opinions on=20 > the wisdom or > > > otherwise of allowing the To header field URI to change.=20 > It seems that > > > from discussion of connected-identity there is a desire from=20 > > > some parts > > > of the community to include an (unauthenticated) identity in=20 > > > a response. > > >=20 > > > John=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 >=20 > _______________________________________________________________ > SMS schreiben mit WEB.DE FreeMail - einfach, schnell und > kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=3D021192 >=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 Apr 05 17:28:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFWo-00087U-77; Wed, 05 Apr 2006 17:27:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFWm-00087P-SA for sip@ietf.org; Wed, 05 Apr 2006 17:27:00 -0400 Received: from [66.155.254.250] (helo=isdmail1.inovsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRFWk-0006De-Kx for sip@ietf.org; Wed, 05 Apr 2006 17:27:00 -0400 Received: from greatwall ([12.181.128.3]) by isdmail1.inovsys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 5 Apr 2006 17:26:57 -0400 From: "Gary Gan" To: "'Dean Willis'" , "'Tarun Kapoor'" Subject: RE: [Sip] draft-ietf-sipping-conference-package : MTU Date: Wed, 5 Apr 2006 17:27:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcZY7+UOv7krT4B1Q5WBwM8LYZsqMQABofTQ In-Reply-To: <7A2D2648-2318-4A80-8688-CED31D6C34E9@softarmor.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 05 Apr 2006 21:26:57.0718 (UTC) FILETIME=[AB167560:01C658F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org My concern is that one side, which knows its packet will exceed MTU, can stick on TCP, how can it know the other peer also support TCP? Does it mean all SIP UA must support TCP and must register it to the registrar as a TCP endpoint in order to receive such SIP sessions? Gary Gan -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Wednesday, April 05, 2006 4:31 PM To: Tarun Kapoor Cc: 'Gary Gan'; 'Dale R. Worley'; sip@ietf.org Subject: Re: [Sip] draft-ietf-sipping-conference-package : MTU On Apr 4, 2006, at 3:24 PM, Tarun Kapoor wrote: > However, the UA should decide whether it will support TCP or UDP at > the > beginning of a session and stick to it until it initiates another > session. > It's generally safer to use TCP if you know there is a chance of a SIP > packet > MTU. I'd like to restate this: "It's generally safer to use TCP if you know there is a chance of a SIP packet." -- 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 Apr 05 18:05:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRG6e-0002UA-2x; Wed, 05 Apr 2006 18:04:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRG6c-0002U4-J3 for sip@ietf.org; Wed, 05 Apr 2006 18:04:02 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRG6b-0008Im-CW for sip@ietf.org; Wed, 05 Apr 2006 18:04:02 -0400 Received: from [127.0.0.1] (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k35M3w9X020043 for ; Wed, 5 Apr 2006 22:04:01 GMT Message-ID: <44343EA9.9070508@neustar.biz> Date: Wed, 05 Apr 2006 15:03:21 -0700 From: Jeff Hodges User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: sip@ietf.org Subject: Re: [Sip] draft-tschofenig-sip-saml-05.txt References: <475FF955A05DD411980D00508B6D5FB0127491C5@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB0127491C5@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed X-BeenThere: sip@ietf.org X-Mailman-Version: 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 duly "hum" for the draft. Of course, I'm a co-author, so pls consider with appropriate salt. JeffH http://www.stanford.edu/~hodges/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 05 18:20:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRGKZ-0000r0-Kc; Wed, 05 Apr 2006 18:18:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRGKX-0000qv-VM for sip@ietf.org; Wed, 05 Apr 2006 18:18:25 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRGKW-0000Pc-Ay for sip@ietf.org; Wed, 05 Apr 2006 18:18:25 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id B65596C023 for ; Wed, 5 Apr 2006 18:18:22 -0400 (EDT) Subject: RE: [Sip] draft-ietf-sipping-conference-package : MTU From: "Dale R. Worley" To: Sip In-Reply-To: References: Content-Type: text/plain Date: Wed, 05 Apr 2006 18:18:21 -0400 Message-Id: <1144275501.6991.40.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 Wed, 2006-04-05 at 17:27 -0400, Gary Gan wrote: > My concern is that one side, which knows its packet will exceed MTU, can > stick on TCP, how can it know the other peer also support TCP? Does it mean > all SIP UA must support TCP and must register it to the registrar as a TCP > endpoint in order to receive such SIP sessions? To repeat: RFC 3261 section 18: "All SIP elements MUST implement UDP and TCP." The TCP port does not need to be separately registered. A URI like "foo@host" implies that the agent is listening on UDP port 5060 and also TCP port 5060. If a port number is added, it is listening on that port for both UDP and TCP. 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 Apr 05 18:38:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRGbw-00083M-T4; Wed, 05 Apr 2006 18:36:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRGbv-00083H-MY for sip@ietf.org; Wed, 05 Apr 2006 18:36:23 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRGbu-00015N-FC for sip@ietf.org; Wed, 05 Apr 2006 18:36:23 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 1A8DD6C021 for ; Wed, 5 Apr 2006 18:36:22 -0400 (EDT) Subject: RE: [Sip] draft-ietf-sipping-conference-package : MTU From: "Dale R. Worley" To: Sip In-Reply-To: References: Content-Type: text/plain Date: Wed, 05 Apr 2006 18:36:21 -0400 Message-Id: <1144276581.6991.52.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 Tue, 2006-04-04 at 13:49 -0400, Gary Gan wrote: > Does it mean the SIP UA is supposed to check the SIP message size, if it is > too big, it will automatically switch to TCP? Is it a mixed TCP/UDP SIP > messages within a SIP session or it needs to decide UDP or TCP at the > beginning of a session? As a general rule, how a SIP agent processes a message does not depend on the transport used to get the message there. So it is possible for some messages in a dialog to be transported via TCP and some via UDP. In addition, different messages in a dialog may (within certain limits) traverse a different set of proxies. 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 Apr 05 18:55:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRGsU-0006qV-Cm; Wed, 05 Apr 2006 18:53:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRGsS-0006i6-BQ for sip@ietf.org; Wed, 05 Apr 2006 18:53:28 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRGsQ-0001kO-9E for sip@ietf.org; Wed, 05 Apr 2006 18:53:28 -0400 Received: from [10.10.2.211] ([204.244.76.21]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k35Ms1Bu001498 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 5 Apr 2006 17:54:02 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] draft-ietf-sipping-conference-package : MTU Date: Wed, 5 Apr 2006 17:53:19 -0500 To: Gary Gan X-Mailer: Apple Mail (2.746.3) 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 Apr 5, 2006, at 4:27 PM, Gary Gan wrote: > My concern is that one side, which knows its packet will exceed > MTU, can > stick on TCP, how can it know the other peer also support TCP? Does > it mean > all SIP UA must support TCP and must register it to the registrar > as a TCP > endpoint in order to receive such SIP sessions? Pretty much, yes. But we really haven't been willing to say that very loudly so far. RFC 3261 Section 18 P4 says: All SIP elements MUST implement UDP and TCP. SIP elements MAY implement other protocols. So, ALL SIP UA MUST SUPPORT TCP. That's been said fairly loudly. We've also said, in section 18.1.1 of RFC 3261: 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 [43] congestion controlled transport protocol, such as TCP. So, a large request MUST NOT BE SENT over UDP. What we haven't said is that "if a UA does not register a TCP (or other congestion controlled transport) as a contact, that UA will not receive large requests." But I think this fairly clearly follows from the above-quoted statements in RFC 3261. I think that this means that TCP (better yet, TLS) should be the default transport, and UDP should be used only in very special cases that have an explicit awareness of the fact that they aren't going to get large messages. In practice, nobody seems to care, and everybody pumps out large UDP messages in fragmented form and just hopes they get there in the right order, which usually works. -- 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 Apr 05 20:12:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRI55-0000CZ-OM; Wed, 05 Apr 2006 20:10:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRI54-0000CI-NF for sip@ietf.org; Wed, 05 Apr 2006 20:10:34 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRI53-0003yR-CT for sip@ietf.org; Wed, 05 Apr 2006 20:10:34 -0400 Received: from [10.10.2.211] (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 k360B7en001953 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 5 Apr 2006 19:11:08 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] draft-ietf-sipping-conference-package : MTU Date: Wed, 5 Apr 2006 19:10:25 -0500 To: Dean Willis X-Mailer: Apple Mail (2.746.3) 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 Apr 5, 2006, at 5:53 PM, Dean Willis wrote: > > On Apr 5, 2006, at 4:27 PM, Gary Gan wrote: > >> My concern is that one side, which knows its packet will exceed >> MTU, can >> stick on TCP, how can it know the other peer also support TCP? >> Does it mean >> all SIP UA must support TCP and must register it to the registrar >> as a TCP >> endpoint in order to receive such SIP sessions? > > Pretty much, yes. But we really haven't been willing to say that > very loudly so far. > > RFC 3261 Section 18 P4 says: > > All SIP elements MUST implement UDP and TCP. SIP elements MAY > implement other protocols. > > So, ALL SIP UA MUST SUPPORT TCP. That's been said fairly loudly. > > We've also said, in section 18.1.1 of RFC 3261: > > 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 [43] congestion controlled transport protocol, > such > as TCP. > > So, a large request MUST NOT BE SENT over UDP. > > What we haven't said is that "if a UA does not register a TCP (or > other congestion controlled transport) as a contact, that UA will > not receive large requests." > Let me restate this is: "If a UA does not use TCP (or another congestion controlled transport negotiated with its proxy), that UA will not receive large requests. -- 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 Apr 05 21:21:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRJ9S-0000Ml-M7; Wed, 05 Apr 2006 21:19:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRJ9R-0000Mb-EG for sip@ietf.org; Wed, 05 Apr 2006 21:19:09 -0400 Received: from smtp112.iad.emailsrvr.com ([207.97.245.112] helo=smtp132.iad.emailsrvr.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRJ9Q-0007cD-6C for sip@ietf.org; Wed, 05 Apr 2006 21:19:09 -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 relay1.r1.iad.emailsrvr.com (SMTP Server) with ESMTP id 9BBE744ECB5; Wed, 5 Apr 2006 21:19:06 -0400 (EDT) From: "Derek MacDonald" To: "'Dean Willis'" Subject: RE: [Sip] draft-ietf-sipping-conference-package : MTU Date: Wed, 5 Apr 2006 18:19:06 -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 Thread-Index: AcZZDqY77nUtqYc7Tuei4k5LgrH5cAABKpiA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Message-Id: <20060406011906.9BBE744ECB5@relay1.r1.iad.emailsrvr.com> X-Virus-Scanned: OK 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 One major issue is that 3261 doesn't consider NAT traversal. For example, if Alice is behind a NAT and sends a SUBSCRIBE with a UDP contact, Alice cannot receive large messages even if she supports TCP on the same port, even if she Registered a separate TCP contact. Bob can have TCP as the contact in the NOTIFY, and alice & bob can send TCP or UDP to their respective proxies, but this doesn't help. I believe that a Dialog-ICE like mechanism was proposed once for this, which could work w/ sip-outbound, but it makes more sense to just stop using UDP if you have to register both anyhow. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, April 05, 2006 5:10 PM > To: Dean Willis > Cc: sip@ietf.org > Subject: Re: [Sip] draft-ietf-sipping-conference-package : MTU > > > On Apr 5, 2006, at 5:53 PM, Dean Willis wrote: > > > > > On Apr 5, 2006, at 4:27 PM, Gary Gan wrote: > > > >> My concern is that one side, which knows its packet will exceed > >> MTU, can > >> stick on TCP, how can it know the other peer also support TCP? > >> Does it mean > >> all SIP UA must support TCP and must register it to the registrar > >> as a TCP > >> endpoint in order to receive such SIP sessions? > > > > Pretty much, yes. But we really haven't been willing to say that > > very loudly so far. > > > > RFC 3261 Section 18 P4 says: > > > > All SIP elements MUST implement UDP and TCP. SIP elements MAY > > implement other protocols. > > > > So, ALL SIP UA MUST SUPPORT TCP. That's been said fairly loudly. > > > > We've also said, in section 18.1.1 of RFC 3261: > > > > 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 [43] congestion controlled transport protocol, > > such > > as TCP. > > > > So, a large request MUST NOT BE SENT over UDP. > > > > What we haven't said is that "if a UA does not register a TCP (or > > other congestion controlled transport) as a contact, that UA will > > not receive large requests." > > > > Let me restate this is: "If a UA does not use TCP (or another > congestion controlled transport negotiated with its proxy), that UA > will not receive large requests. > > -- > 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 Apr 05 22:16:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRK1X-0008IH-Pf; Wed, 05 Apr 2006 22:15:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRK1V-0008I9-U8 for sip@ietf.org; Wed, 05 Apr 2006 22:15:01 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRK1U-00018w-LI for sip@ietf.org; Wed, 05 Apr 2006 22:15:01 -0400 Received: from [192.168.0.102] (ppp-70-249-157-165.dsl.rcsntx.swbell.net [70.249.157.165]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k362EuNr017325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Apr 2006 21:14:57 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4434799B.5070909@nostrum.com> Date: Wed, 05 Apr 2006 21:14:51 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Derek MacDonald Subject: Re: [Sip] draft-ietf-sipping-conference-package : MTU References: <20060406011906.9BBE744ECB5@relay1.r1.iad.emailsrvr.com> In-Reply-To: <20060406011906.9BBE744ECB5@relay1.r1.iad.emailsrvr.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.157.165 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 Derek MacDonald wrote: >One major issue is that 3261 doesn't consider NAT traversal. For example, >if Alice is behind a NAT and sends a SUBSCRIBE with a UDP contact, Alice >cannot receive large messages even if she supports TCP on the same port, >even if she Registered a separate TCP contact. > I think Dean's point was: "don't do that, then." /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Apr 05 22:22:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRK6x-0001uH-SX; Wed, 05 Apr 2006 22:20:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRK6x-0001uC-Ez for sip@ietf.org; Wed, 05 Apr 2006 22:20:39 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRK6w-0001Jy-7G for sip@ietf.org; Wed, 05 Apr 2006 22:20:39 -0400 Received: from [192.168.0.102] (ppp-70-249-157-165.dsl.rcsntx.swbell.net [70.249.157.165]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k362Kau8017828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Apr 2006 21:20:36 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <44347AEE.1080306@nostrum.com> Date: Wed, 05 Apr 2006 21:20:30 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach Subject: Re: [Sip] draft-ietf-sipping-conference-package : MTU References: <20060406011906.9BBE744ECB5@relay1.r1.iad.emailsrvr.com> <4434799B.5070909@nostrum.com> In-Reply-To: <4434799B.5070909@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.157.165 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Adam Roach wrote: > Derek MacDonald wrote: > >> One major issue is that 3261 doesn't consider NAT traversal. For >> example, >> if Alice is behind a NAT and sends a SUBSCRIBE with a UDP contact, Alice >> cannot receive large messages even if she supports TCP on the same port, >> even if she Registered a separate TCP contact. >> > > I think Dean's point was: "don't do that, then." Sorry; I just read more context, and realize that Dean's point was that we don't say "don't do that, then" anywhere. *I* think the proper answer is saying "don't do that, then" in a document somewhere. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Apr 05 22:59:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRKgp-0006Er-BU; Wed, 05 Apr 2006 22:57:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRKgo-0006Dt-Ds for sip@ietf.org; Wed, 05 Apr 2006 22:57:42 -0400 Received: from smtp112.iad.emailsrvr.com ([207.97.245.112] helo=smtp132.iad.emailsrvr.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRKgn-0002nH-7y for sip@ietf.org; Wed, 05 Apr 2006 22:57:42 -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 relay1.r1.iad.emailsrvr.com (SMTP Server) with ESMTP id B7B0A44ECC8; Wed, 5 Apr 2006 22:57:39 -0400 (EDT) From: "Derek MacDonald" To: "'Adam Roach'" Subject: RE: [Sip] draft-ietf-sipping-conference-package : MTU Date: Wed, 5 Apr 2006 19:57:39 -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 Thread-Index: AcZZILD/PmktiVYFT1yymXslCf0LcgABO49g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <44347AEE.1080306@nostrum.com> Message-Id: <20060406025739.B7B0A44ECC8@relay1.r1.iad.emailsrvr.com> X-Virus-Scanned: OK X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Yeah. It should prob. be added to the NAT best practices draft(Full disclosure, haven't read it yet). However, everything boils down to "don't use UDP". I'm was just re-enforcing the message. > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Wednesday, April 05, 2006 7:21 PM > To: Adam Roach > Cc: Derek MacDonald; sip@ietf.org; 'Dean Willis' > Subject: Re: [Sip] draft-ietf-sipping-conference-package : MTU > > Adam Roach wrote: > > > Derek MacDonald wrote: > > > >> One major issue is that 3261 doesn't consider NAT traversal. For > >> example, > >> if Alice is behind a NAT and sends a SUBSCRIBE with a UDP contact, > Alice > >> cannot receive large messages even if she supports TCP on the same > port, > >> even if she Registered a separate TCP contact. > >> > > > > I think Dean's point was: "don't do that, then." > > > Sorry; I just read more context, and realize that Dean's point was that > we don't say "don't do that, then" anywhere. *I* think the proper answer > is saying "don't do that, then" in a document somewhere. > > /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Apr 06 03:01:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FROSK-0001rD-CG; Thu, 06 Apr 2006 02:59:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FROSJ-0001r2-H9 for sip@ietf.org; Thu, 06 Apr 2006 02:58:59 -0400 Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56] helo=zrtps0kp.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FROSE-0002nv-7D for sip@ietf.org; Thu, 06 Apr 2006 02:58:56 -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 k366wpk22767; Thu, 6 Apr 2006 02:58:51 -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: Thu, 6 Apr 2006 01:58:49 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60B54D30F@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: Maximum number of flows reached - how to reject? Thread-Index: AcZYx/J8R0A7zS4OSgqYcuhY2xpWUwAfr8Xg From: "Samir Srivastava" To: "Christer Holmberg \(JO/LMF\)" , X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 The problem with 503 is that it could cause a re-sending of the REGISTER later, but if the registrar simply doesn't accept more flows for the instance-id the UA should not re-send (until other flows have been removed).=20 SS>> How do you indicate UA when to register for another flow ? Reg event on the existing flow for another flow, as rejected registration flow is not kept alive. Or they are also for this new error code.. 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 Thu Apr 06 04:47:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRQ76-0001Ei-PI; Thu, 06 Apr 2006 04:45:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRQ75-0001Ed-G0 for sip@ietf.org; Thu, 06 Apr 2006 04:45:11 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRQ73-00076V-SV for sip@ietf.org; Thu, 06 Apr 2006 04:45:11 -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 k368hjbe015955; Thu, 6 Apr 2006 11:43:45 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 11:45:07 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 11:45:05 +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: Multiple flows and forking Date: Thu, 6 Apr 2006 11:45:04 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0229ADE2@esebe103.NOE.Nokia.com> In-Reply-To: <4433C410.8020903@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: Multiple flows and forking Thread-Index: AcZYs8k8l4LD9v5pSk2cfMo4fm5yTgAnsqVg From: To: , X-OriginalArrivalTime: 06 Apr 2006 08:45:05.0072 (UTC) FILETIME=[66A3FB00:01C65956] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 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 Jonathan,=20 >> The text says: >>=20 >>"However, a UA MUST support sets with at least two outbound=20 >> proxy URIs (primary and backup) and SHOULD support sets=20 >> with up to four URIs. For each outbound proxy URI in the=20 >> set, the UA MUST send a REGISTER in the normal=20 >> way using this URI as the default outbound proxy." >>=20 >> I don't think we should mandate this, because it is very=20 >> much dependent on the architecture, transport techniques > >Mandate what? The minimal number of outbound proxies that=20 >should be supported? Or the fact that you register on each?=20 >For the latter, its an essential part of the story so I=20 >don't see how you can make it optional. In the former case,=20 >if you don't specify a minimum that is supported,=20 >how do you have interop? Please remember that section 3 Overview of the spec clearly describes three different example configurations as follows: 3.2 Single Registrar and UA 3.3 Multiple Connections from a User Agent 3.4 Edge Proxies There is clearly a possibility for the registrar/proxy and=20 UA to use only one single flow between them: 3.2 Single Registrar and UA In this example, a single server is acting as both a registrar and proxy. +-----------+ | Registrar | | Proxy | +-----+-----+ | | +----+--+ | User | | Agent | +-------+ User Agents which form only a single flow continue to register normally but include the instance-id as described in Section 4.1. Sections 3.3 and 3.4 discuss the ways of building extra reliability by forming multiple flows towards multiple next hops. In my understanding section 4 allows the outbound-proxy-set to consist of a single proxy or multiple ones (depending on what has been configured to the UA) but currently mandate the UA to support configuring multiple proxies (2 - 4) into the set. This would preclude implementations that would only support configuring one single proxy to outbound-proxy-set, even if this would work and be sufficient for certain types of deployment. 4.2 Initial Registrations UAs are configured with one or more SIP URIs representing the default outbound-proxy-set. The specification assumes the set is determined via configuration but future specifications may define other 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 (primary and backup) 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. Further on it is mandated that each of the registrations shall form a new flow, that the UA must keep alive and monitor: These ordinary registration requests MUST also add a distinct reg-id parameter to the Contact header field. Each one of these registrations will form a new flow from the UA to the proxy. I would be happy for changing the text as follows: However, a UA SHOULD support sets with at least two outbound proxy URIs (primary and backup) and MAY support sets with up to four URIs. For each outbound proxy URI configured or automatically discovered in=20 the set, the UA MUST send a REGISTER in the normal way using this=20 URI as the default outbound proxy. This would mean the following: 1. An UA vendor would be allowed to implement an UA supporting 1 - 4 URIs for the outbound-proxy-set. 2. The UA must a send a separate registration (and form a separate flow) to each of the proxy (configured or automatically discovered) within the outbound-proxy-set (up to the implementation specific maximum). So this would mean that you could have e.g. - An UA supporting and configured a single outbound proxy, sending REGISTER and forming a single flow towards it - An UA supporting and configured three proxies, sending REGISTER=20 and forming a separate flow towards each of them - An UA supporting four proxies but configured with only two proxies. In this case UA would send REGISTER and form separate flows towards those two proxies configured. - An UA configured with a single outbound proxy URI and resolving it with DNS to a primary and backup proxy, towards which the REGISTER must be sent and the flows formed. (Note: I am working on the I-D to specify the related DNS mechanisms). Regards, Erkki >-----Original Message----- >From: ext Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 >Sent: 05.April.2006 16:20 >To: Christer Holmberg (JO/LMF) >Cc: sip@ietf.org >Subject: Re: [Sip] Outbound: Multiple flows and forking > >inline: > >Christer Holmberg (JO/LMF) wrote: > >>=20 >> Hi, >>=20 >> A couple of issues on chapter 4.2. >>=20 >> The text says: >>=20 >> "However, a UA MUST support sets with at least two outbound=20 >proxy URIs=20 >> (primary and backup) and SHOULD support sets with up to four=20 >URIs. For each >>=20 >> outbound proxy URI in the set, the UA MUST send a REGISTER=20 >in the normal=20 >> way using this URI as the default outbound proxy." >>=20 >> I don't think we should mandate this, because it is very=20 >much dependent=20 >> on the architecture, transport techniques etc. > >Mandate what? The minimal number of outbound proxies that should be=20 >supported? Or the fact that you register on each? For the=20 >latter, its an=20 >essential part of the story so I don't see how you can make it=20 >optional.=20 >In the former case, if you don't specify a minimum that is supported,=20 >how do you have interop? > >-Jonathan R. > >--=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 > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 06 04:59:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRQJX-0008Iz-A6; Thu, 06 Apr 2006 04:58:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRQJV-0008Ik-PV for sip@ietf.org; Thu, 06 Apr 2006 04:58:01 -0400 Received: from not01-fw01.citel.com ([62.190.107.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRQJU-0007NG-Cx for sip@ietf.org; Thu, 06 Apr 2006 04:58:01 -0400 Received: from [10.7.1.3] (helo=not01-mxc01.citel.com) by not01-fw01.citel.com with esmtp (Exim 4.43) id 1FRQJR-0000SL-3T; Thu, 06 Apr 2006 09:57:57 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip-mib comments) Date: Thu, 6 Apr 2006 09:57:57 +0100 Message-ID: <592CA2F7E2BFBD4088AC87ECFF34BECE2D6D4C@not01-mxc01.citel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip-mib comments) Thread-Index: AcY5j29dKQxxIed4SCWenzWDWU3cwgCDbzWgAWHdczABPKwkYAAB1NDAAC8iRbAEU4MgYwAjT98AAAWt1EUAICbuYA== From: "Michael Procter" To: "Cullen Jennings" , "Jean-Francois Mule" , "Kevin Lingle \(klingle\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: "Romascanu, Dan \(Dan\)" , Juergen Schoenwaelder X-BeenThere: sip@ietf.org X-Mailman-Version: 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: > This is way off track of anything to do with the MIB but ... Indeed. I'd like to try to bring it back to the topic, by referring to the original question that was posed. At least we all have more background to it now! > > Cullen Jennings wrote: > >> sipRegAlloowThirdParty - there are two definitions in common > >> usage for 3rd party reg. This is one of them. Looking again at the definition in the MIB draft, I am confused: DESCRIPTION "This object reflects whether or not the Registrar SHOULD allow third party registrations. In third-party registration, the entity issuing the request (in the From header) is different from the entity being registered (in the To header) to whom the provided Contact information applies. I first read this as describing the From !=3D To case, but looking again, I can see how it might be read as the Contact !=3D source case. The phrase that I find confusing is 'entity being registered (in the To header) to whom the provided Contact information applies'. This phrase always applies, since the main function of a REGISTER message is to provide a Contact that applies to the AoR in the To header. Is this clause supposed to identify the 'Contact does not correspond to the source of the REGISTER message' case? > >> However, I don't know of any > >> deployment situations that allow this type of 3rd party reg. I know of deployments of 3rd party registrations (of the To !=3D From type). I am no longer sure whether this is the same type as=20 defined in the MIB draft or not! Whether either or both approaches need MIB support is for more MIB-minded people than me to contemplate. I was just trying to clarify whether or not certain types of deployment exist. Regards, Michael Procter _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Apr 06 05:10:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRQTI-00053C-A7; Thu, 06 Apr 2006 05:08:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRQTG-000537-CS for sip@ietf.org; Thu, 06 Apr 2006 05:08:06 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRQTC-0007ob-Kk for sip@ietf.org; Thu, 06 Apr 2006 05:08:06 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 11FCAE0D; Thu, 6 Apr 2006 11:08:02 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 11:08:01 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 11:08:01 +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: Maximum number of flows reached - how to reject? Date: Thu, 6 Apr 2006 11:08:00 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1CD9@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: Maximum number of flows reached - how to reject? Thread-Index: AcZYx/J8R0A7zS4OSgqYcuhY2xpWUwAfr8XgAASuGZA= From: "Christer Holmberg \(JO/LMF\)" To: "Samir Srivastava" , X-OriginalArrivalTime: 06 Apr 2006 09:08:01.0005 (UTC) FILETIME=[9AC2B1D0:01C65959] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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, 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, Christer=20 -----Original Message----- From: Samir Srivastava [mailto:samirsr@nortel.com]=20 Sent: 6. huhtikuuta 2006 9:59 To: Christer Holmberg (JO/LMF); sip@ietf.org Subject: RE: [Sip] Outbound: Maximum number of flows reached - how to reject? The problem with 503 is that it could cause a re-sending of the REGISTER later, but if the registrar simply doesn't accept more flows for the instance-id the UA should not re-send (until other flows have been removed).=20 SS>> How do you indicate UA when to register for another flow ? Reg event on the existing flow for another flow, as rejected registration flow is not kept alive. Or they are also for this new error code.. 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 Thu Apr 06 05:47:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRR3k-0001cB-3D; Thu, 06 Apr 2006 05:45:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRR3i-0001az-IF for sip@ietf.org; Thu, 06 Apr 2006 05:45:46 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRR3f-0000t1-H2 for sip@ietf.org; Thu, 06 Apr 2006 05:45:46 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9F47F4F0001; Thu, 6 Apr 2006 11:45: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); Thu, 6 Apr 2006 11:45:42 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 11:45: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="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound: Multiple flows and forking Date: Thu, 6 Apr 2006 11:45:41 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1CDB@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: Multiple flows and forking Thread-Index: AcZYs8k8l4LD9v5pSk2cfMo4fm5yTgAnsqVgAALz/fA= From: "Christer Holmberg \(JO/LMF\)" To: , X-OriginalArrivalTime: 06 Apr 2006 09:45:41.0668 (UTC) FILETIME=[DE387E40:01C6595E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 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 Erikki, First, I may have missunderstood what you wrote, but you still seem to say that a UA MUST send a REGISTER to all outbuond proxies it is aware of. Second, I would again like to ask whether we should use "outbound proxy address" instead of "outbound proxy URI". Because, the outbound address may not be provided/configured to the UA as a URI (even if we want that as some kind of default behavior). Regards, Christer -----Original Message----- From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com]=20 Sent: 6. huhtikuuta 2006 11:45 To: jdrosen@cisco.com; Christer Holmberg (JO/LMF) Cc: sip@ietf.org Subject: RE: [Sip] Outbound: Multiple flows and forking Hi Jonathan,=20 >> The text says: >>=20 >>"However, a UA MUST support sets with at least two outbound proxy=20 >>URIs (primary and backup) and SHOULD support sets with up to four=20 >>URIs. For each outbound proxy URI in the set, the UA MUST send a=20 >>REGISTER in the normal way using this URI as the default outbound=20 >>proxy." >>=20 >> I don't think we should mandate this, because it is very much=20 >> dependent on the architecture, transport techniques > >Mandate what? The minimal number of outbound proxies that should be=20 >supported? Or the fact that you register on each? >For the latter, its an essential part of the story so I don't see how=20 >you can make it optional. In the former case, if you don't specify a=20 >minimum that is supported, how do you have interop? Please remember that section 3 Overview of the spec clearly describes three different example configurations as follows: 3.2 Single Registrar and UA 3.3 Multiple Connections from a User Agent 3.4 Edge Proxies There is clearly a possibility for the registrar/proxy and UA to use only one single flow between them: 3.2 Single Registrar and UA In this example, a single server is acting as both a registrar and proxy. +-----------+ | Registrar | | Proxy | +-----+-----+ | | +----+--+ | User | | Agent | +-------+ User Agents which form only a single flow continue to register normally but include the instance-id as described in Section 4.1. Sections 3.3 and 3.4 discuss the ways of building extra reliability by forming multiple flows towards multiple next hops. In my understanding section 4 allows the outbound-proxy-set to consist of a single proxy or multiple ones (depending on what has been configured to the UA) but currently mandate the UA to support configuring multiple proxies (2 - 4) into the set. This would preclude implementations that would only support configuring one single proxy to outbound-proxy-set, even if this would work and be sufficient for certain types of deployment. 4.2 Initial Registrations UAs are configured with one or more SIP URIs representing the default outbound-proxy-set. The specification assumes the set is determined via configuration but future specifications may define other 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 (primary and backup) 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. Further on it is mandated that each of the registrations shall form a new flow, that the UA must keep alive and monitor: These ordinary registration requests MUST also add a distinct reg-id parameter to the Contact header field. Each one of these registrations will form a new flow from the UA to the proxy. I would be happy for changing the text as follows: However, a UA SHOULD support sets with at least two outbound proxy URIs (primary and backup) and MAY support sets with up to four URIs. For each outbound proxy URI configured or automatically discovered in=20 the set, the UA MUST send a REGISTER in the normal way using this=20 URI as the default outbound proxy. This would mean the following: 1. An UA vendor would be allowed to implement an UA supporting 1 - 4 URIs for the outbound-proxy-set. 2. The UA must a send a separate registration (and form a separate flow) to each of the proxy (configured or automatically discovered) within the outbound-proxy-set (up to the implementation specific maximum). So this would mean that you could have e.g. - An UA supporting and configured a single outbound proxy, sending REGISTER and forming a single flow towards it - An UA supporting and configured three proxies, sending REGISTER and forming a separate flow towards each of them - An UA supporting four proxies but configured with only two proxies. In this case UA would send REGISTER and form separate flows towards those two proxies configured. - An UA configured with a single outbound proxy URI and resolving it with DNS to a primary and backup proxy, towards which the REGISTER must be sent and the flows formed. (Note: I am working on the I-D to specify the related DNS mechanisms). Regards, Erkki >-----Original Message----- >From: ext Jonathan Rosenberg [mailto:jdrosen@cisco.com] >Sent: 05.April.2006 16:20 >To: Christer Holmberg (JO/LMF) >Cc: sip@ietf.org >Subject: Re: [Sip] Outbound: Multiple flows and forking > >inline: > >Christer Holmberg (JO/LMF) wrote: > >>=20 >> Hi, >>=20 >> A couple of issues on chapter 4.2. >>=20 >> The text says: >>=20 >> "However, a UA MUST support sets with at least two outbound >proxy URIs >> (primary and backup) and SHOULD support sets with up to four >URIs. For each >>=20 >> 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 >> I don't think we should mandate this, because it is very >much dependent >> on the architecture, transport techniques etc. > >Mandate what? The minimal number of outbound proxies that should be=20 >supported? Or the fact that you register on each? For the latter, its=20 >an essential part of the story so I don't see how you can make it=20 >optional. >In the former case, if you don't specify a minimum that is supported,=20 >how do you have interop? > >-Jonathan R. > >--=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 > >_______________________________________________ >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 Apr 06 07:51:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRT02-00042E-9d; Thu, 06 Apr 2006 07:50:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRT00-00040W-KW for sip@ietf.org; Thu, 06 Apr 2006 07:50:04 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRSzy-00051T-Sr for sip@ietf.org; Thu, 06 Apr 2006 07:50:04 -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 k36BnDAd013908; Thu, 6 Apr 2006 14:49:14 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 14:49:34 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 14:49:33 +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: Multiple flows and forking Date: Thu, 6 Apr 2006 14:49:33 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F022CC691@esebe103.NOE.Nokia.com> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1CDB@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: Multiple flows and forking Thread-Index: AcZYs8k8l4LD9v5pSk2cfMo4fm5yTgAnsqVgAALz/fAAA5FAwA== From: To: , X-OriginalArrivalTime: 06 Apr 2006 11:49:33.0876 (UTC) FILETIME=[2C296F40:01C65970] X-Spam-Score: 0.2 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af 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, >First, I may have missunderstood what you wrote, but you still seem to >say that a UA MUST send a REGISTER to all outbuond proxies it is aware >of. Yes, you have understand me correctly. I said that since I did not get what would be the point of configuring the UA with multiple proxies while not sending the REGISTER to all of them ? In my email I separate these two items: 1. How many proxies the UA allows to be configured 2. How many proxies the UA is really configured with It could help me to understand the issue if you could point out to me to which purpose those proxies would be used that the UA is configured with but it would not send a REGISTER to ? And if you are referring to a case of configuring only a single proxy URI that would resolve to multiple proxy addresses by DNS, then my answer would come along with the separate I-D I am currently preparing. I will NOT suggest sending REGISTER to all the addresses a DNS SRV or A query might result. But if you think clarifying the=20 DNS issue must be done within the outbound I-D, please be a bit=20 more specific about your proposal.=20 >Second, I would again like to ask whether we should use "outbound proxy >address" instead of "outbound proxy URI". Because, the outbound address >may not be provided/configured to the UA as a URI (even if we want that >as some kind of default behavior). When being configured those could be SIP URIs (possibly with a number of URI parameters), FDQNs or even IP addresses. But in the end the UA would derive from those the SIP URIs of the proxies. So I find the following statement to be OK: UAs are configured with one or more SIP URIs representing the default outbound-proxy-set. To me it does not matter in which format those addresses are represented in the configuration UI or configuration message arriving to the UA. The statement above would just tell what would be the result of the configuration: the UA would, in the end of the day, own the SIP URIs=20 representing the proxies, as part of its configuration. Regards, Erkki >-----Original Message----- >From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com]=20 >Sent: 6. huhtikuuta 2006 11:45 >To: jdrosen@cisco.com; Christer Holmberg (JO/LMF) >Cc: sip@ietf.org >Subject: RE: [Sip] Outbound: Multiple flows and forking > > >Hi Jonathan,=20 > >>> The text says: >>>=20 >>>"However, a UA MUST support sets with at least two outbound proxy=20 >>>URIs (primary and backup) and SHOULD support sets with up to four=20 >>>URIs. For each outbound proxy URI in the set, the UA MUST send a=20 >>>REGISTER in the normal way using this URI as the default outbound=20 >>>proxy." >>>=20 >>> I don't think we should mandate this, because it is very much=20 >>> dependent on the architecture, transport techniques >> >>Mandate what? The minimal number of outbound proxies that should be=20 >>supported? Or the fact that you register on each? >>For the latter, its an essential part of the story so I don't see how=20 >>you can make it optional. In the former case, if you don't specify a=20 >>minimum that is supported, how do you have interop? > >Please remember that section 3 Overview of the spec clearly describes >three different example configurations as follows: > >3.2 Single Registrar and UA >3.3 Multiple Connections from a User Agent >3.4 Edge Proxies > >There is clearly a possibility for the registrar/proxy and UA to use >only one single flow between them: > >3.2 Single Registrar and UA > > In this example, a single server is acting as both a registrar and > proxy. > > +-----------+ > | Registrar | > | Proxy | > +-----+-----+ > | > | > +----+--+ > | User | > | Agent | > +-------+ > > User Agents which form only a single flow continue to register > normally but include the instance-id as described in Section 4.1. > >Sections 3.3 and 3.4 discuss the ways of building extra reliability by >forming multiple flows towards multiple next hops. In my understanding >section 4 allows the outbound-proxy-set to consist of a single proxy or >multiple ones (depending on what has been configured to the UA) but >currently mandate the UA to support configuring multiple proxies >(2 - 4) into the set. This would preclude implementations that would >only support configuring one single proxy to=20 >outbound-proxy-set, even if >this would work and be sufficient for certain types of deployment. > >4.2 Initial Registrations > > UAs are configured with one or more SIP URIs representing=20 >the default > outbound-proxy-set. The specification assumes the set is determined > via configuration but future specifications may define other > mechanisms such as using DNS to discover this set. How the UA is > configured is outside the scope of this specification. =20 >However, a UA > MUST support sets with at least two outbound proxy URIs (primary and > backup) 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. > >Further on it is mandated that each of the registrations shall form a >new flow, that the UA must keep alive and monitor: > > These ordinary registration requests MUST also add a distinct reg-id > parameter to the Contact header field. Each one of these > registrations will form a new flow from the UA to the proxy. > >I would be happy for changing the text as follows: > > However, a UA > SHOULD support sets with at least two outbound proxy URIs (primary >and > backup) and MAY support sets with up to four URIs. For each > outbound proxy URI configured or automatically discovered in=20 > the set, the UA MUST send a REGISTER in the normal way using this=20 > URI as the default outbound proxy. > >This would mean the following: > >1. An UA vendor would be allowed to implement an UA supporting 1 - 4 > URIs for the outbound-proxy-set. > >2. The UA must a send a separate registration (and form a separate > flow) to each of the proxy (configured or automatically discovered) > within the outbound-proxy-set (up to the implementation specific > maximum). > >So this would mean that you could have e.g. > >- An UA supporting and configured a single outbound proxy, sending > REGISTER and forming a single flow towards it > >- An UA supporting and configured three proxies, sending REGISTER > and forming a separate flow towards each of them > >- An UA supporting four proxies but configured with only two proxies. > In this case UA would send REGISTER and form separate flows towards > those two proxies configured. > >- An UA configured with a single outbound proxy URI and resolving it > with DNS to a primary and backup proxy, towards which the REGISTER > must be sent and the flows formed. (Note: I am working on the I-D > to specify the related DNS mechanisms). > >Regards, > >Erkki > >>-----Original Message----- >>From: ext Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>Sent: 05.April.2006 16:20 >>To: Christer Holmberg (JO/LMF) >>Cc: sip@ietf.org >>Subject: Re: [Sip] Outbound: Multiple flows and forking >> >>inline: >> >>Christer Holmberg (JO/LMF) wrote: >> >>>=20 >>> Hi, >>>=20 >>> A couple of issues on chapter 4.2. >>>=20 >>> The text says: >>>=20 >>> "However, a UA MUST support sets with at least two outbound >>proxy URIs >>> (primary and backup) and SHOULD support sets with up to four >>URIs. For each >>>=20 >>> 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 >>> I don't think we should mandate this, because it is very >>much dependent >>> on the architecture, transport techniques etc. >> >>Mandate what? The minimal number of outbound proxies that should be=20 >>supported? Or the fact that you register on each? For the latter, its=20 >>an essential part of the story so I don't see how you can make it=20 >>optional. >>In the former case, if you don't specify a minimum that is supported,=20 >>how do you have interop? >> >>-Jonathan R. >> >>--=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 >> >>_______________________________________________ >>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 Apr 06 08:12:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRTK1-0004qP-JJ; Thu, 06 Apr 2006 08:10:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRTJz-0004qK-Ht for sip@ietf.org; Thu, 06 Apr 2006 08:10:43 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRTJx-0006GJ-8L for sip@ietf.org; Thu, 06 Apr 2006 08:10:43 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9AA04742; Thu, 6 Apr 2006 14:10:40 +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, 6 Apr 2006 14:10:40 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 14:10:39 +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: Multiple flows and forking Date: Thu, 6 Apr 2006 14:10:39 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1CE2@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: Multiple flows and forking Thread-Index: AcZYs8k8l4LD9v5pSk2cfMo4fm5yTgAnsqVgAALz/fAAA5FAwAABKiyQ From: "Christer Holmberg \(JO/LMF\)" To: , X-OriginalArrivalTime: 06 Apr 2006 12:10:39.0975 (UTC) FILETIME=[1ED0CF70:01C65973] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 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 Erikki,=20 >First, I may have missunderstood what you wrote, but you still seem to=20 >say that a UA MUST send a REGISTER to all outbuond proxies it is aware=20 >of. Yes, you have understand me correctly. I said that since I did not get what would be the point of configuring the UA with multiple proxies while not sending the REGISTER to all of them ? [CHH] To give an example from IMS: an IME UE may have the address of multiple P-CSCFs. But, it only registers with one of them. And, I see no reason why it now should have to register with all of them. And, again, mobile terminals (not only IMS UEs) do have to consider the battery impacts. I haven't had time to think whehter Jerone's proposal from yesterday would have an impacts, but I still don't see a reason why a UA should be mandated to send REGISTER to all outbound proxies. I DO understand that there may be an advantage to do so, but sometimes it simply may not be possible/feasible. [/CHH] >In my email I separate these two items: >1. How many proxies the UA allows to be configured [CHH] I think that is an implementation issue, and I see no reason to standardize that. [/CHH] >2. How many proxies the UA is really configured with [CHH] Do you mean how many proxies the UA is registered with? If so, my answer is that it is also an implementation issue. [/CHH] >It could help me to understand the issue if you could point out to me to which purpose those proxies would be used that=20 >the UA is configured with but it would not send a REGISTER to ? [CHH] Please note that the proxies may also have other functions. Again, in IMS I guess the outbound proxy functionality would be located in the P-CSCF, and I don't think sending REGISTERs to multiple P-CSCFs is very wise. [/CHH] >And if you are referring to a case of configuring only a single proxy URI that would resolve to multiple proxy addresses=20 >by DNS, then my answer would come along with the separate I-D I am currently preparing. [CHH] Remember that the outbound proxy may not necessarily be configured. The address of the outbound proxy may be retrieved using other means, for example in the way an IMS UE gets the address(es) of the P-CSCF. [/CHH] I will NOT suggest sending REGISTER to all the addresses a DNS SRV or A query might result. But if you think clarifying the DNS issue must be done within the outbound I-D, please be a bit more specific about your proposal.=20 [CHH] My understanding of the text is that the UA shall send a REGISTER to each outbound proxy address it is aware of - no matter if they are retrieved from a single URI, or multiple URIs. [/CHH] >Second, I would again like to ask whether we should use "outbound proxy >address" instead of "outbound proxy URI". Because, the outbound address >may not be provided/configured to the UA as a URI (even if we want that >as some kind of default behavior). When being configured those could be SIP URIs (possibly with a number of URI parameters), FDQNs or even IP addresses. But in the end the UA would derive from those the SIP URIs of the proxies. So I find the following statement to be OK: UAs are configured with one or more SIP URIs representing the default outbound-proxy-set. [CHH] Of course the UA will derive a URI, but that doesn't mean you have to configure an URI. As you say, you can simply configure an IP address (or, you can retrieve it from somewhere else). [/CHH] To me it does not matter in which format those addresses are represented in the configuration UI or configuration message arriving to the UA. [CHH] Exactly. So we would need re-wording to make that clear. [/CHH] The statement above would just tell what would be the result of the configuration: the UA would, in the end of the day, own the SIP URIs representing the proxies, as part of its configuration. [CHH] I think the "result of the configuration" is basic SIP. Not sure we need to say so much about that. [/CHH] Regards, Christer >-----Original Message----- >From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com] >Sent: 6. huhtikuuta 2006 11:45 >To: jdrosen@cisco.com; Christer Holmberg (JO/LMF) >Cc: sip@ietf.org >Subject: RE: [Sip] Outbound: Multiple flows and forking > > >Hi Jonathan, > >>> The text says: >>>=20 >>>"However, a UA MUST support sets with at least two outbound proxy=20 >>>URIs (primary and backup) and SHOULD support sets with up to four=20 >>>URIs. For each outbound proxy URI in the set, the UA MUST send a=20 >>>REGISTER in the normal way using this URI as the default outbound=20 >>>proxy." >>>=20 >>> I don't think we should mandate this, because it is very much=20 >>> dependent on the architecture, transport techniques >> >>Mandate what? The minimal number of outbound proxies that should be=20 >>supported? Or the fact that you register on each? >>For the latter, its an essential part of the story so I don't see how=20 >>you can make it optional. In the former case, if you don't specify a=20 >>minimum that is supported, how do you have interop? > >Please remember that section 3 Overview of the spec clearly describes=20 >three different example configurations as follows: > >3.2 Single Registrar and UA >3.3 Multiple Connections from a User Agent >3.4 Edge Proxies > >There is clearly a possibility for the registrar/proxy and UA to use=20 >only one single flow between them: > >3.2 Single Registrar and UA > > In this example, a single server is acting as both a registrar and > proxy. > > +-----------+ > | Registrar | > | Proxy | > +-----+-----+ > | > | > +----+--+ > | User | > | Agent | > +-------+ > > User Agents which form only a single flow continue to register > normally but include the instance-id as described in Section 4.1. > >Sections 3.3 and 3.4 discuss the ways of building extra reliability by=20 >forming multiple flows towards multiple next hops. In my understanding=20 >section 4 allows the outbound-proxy-set to consist of a single proxy or >multiple ones (depending on what has been configured to the UA) but=20 >currently mandate the UA to support configuring multiple proxies >(2 - 4) into the set. This would preclude implementations that would=20 >only support configuring one single proxy to outbound-proxy-set, even=20 >if this would work and be sufficient for certain types of deployment. > >4.2 Initial Registrations > > UAs are configured with one or more SIP URIs representing the=20 >default > outbound-proxy-set. The specification assumes the set is determined > via configuration but future specifications may define other > mechanisms such as using DNS to discover this set. How the UA is > configured is outside the scope of this specification. =20 >However, a UA > MUST support sets with at least two outbound proxy URIs (primary and > backup) 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. > >Further on it is mandated that each of the registrations shall form a=20 >new flow, that the UA must keep alive and monitor: > > These ordinary registration requests MUST also add a distinct reg-id > parameter to the Contact header field. Each one of these > registrations will form a new flow from the UA to the proxy. > >I would be happy for changing the text as follows: > > However, a UA > SHOULD support sets with at least two outbound proxy URIs (primary=20 >and > backup) and MAY support sets with up to four URIs. For each > outbound proxy URI configured or automatically discovered in=20 > the set, the UA MUST send a REGISTER in the normal way using this=20 > URI as the default outbound proxy. > >This would mean the following: > >1. An UA vendor would be allowed to implement an UA supporting 1 - 4 > URIs for the outbound-proxy-set. > >2. The UA must a send a separate registration (and form a separate > flow) to each of the proxy (configured or automatically discovered) > within the outbound-proxy-set (up to the implementation specific > maximum). > >So this would mean that you could have e.g. > >- An UA supporting and configured a single outbound proxy, sending > REGISTER and forming a single flow towards it > >- An UA supporting and configured three proxies, sending REGISTER > and forming a separate flow towards each of them > >- An UA supporting four proxies but configured with only two proxies. > In this case UA would send REGISTER and form separate flows towards > those two proxies configured. > >- An UA configured with a single outbound proxy URI and resolving it > with DNS to a primary and backup proxy, towards which the REGISTER > must be sent and the flows formed. (Note: I am working on the I-D > to specify the related DNS mechanisms). > >Regards, > >Erkki > >>-----Original Message----- >>From: ext Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>Sent: 05.April.2006 16:20 >>To: Christer Holmberg (JO/LMF) >>Cc: sip@ietf.org >>Subject: Re: [Sip] Outbound: Multiple flows and forking >> >>inline: >> >>Christer Holmberg (JO/LMF) wrote: >> >>>=20 >>> Hi, >>>=20 >>> A couple of issues on chapter 4.2. >>>=20 >>> The text says: >>>=20 >>> "However, a UA MUST support sets with at least two outbound >>proxy URIs >>> (primary and backup) and SHOULD support sets with up to four >>URIs. For each >>>=20 >>> 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 >>> I don't think we should mandate this, because it is very >>much dependent >>> on the architecture, transport techniques etc. >> >>Mandate what? The minimal number of outbound proxies that should be=20 >>supported? Or the fact that you register on each? For the latter, its=20 >>an essential part of the story so I don't see how you can make it=20 >>optional. >>In the former case, if you don't specify a minimum that is supported,=20 >>how do you have interop? >> >>-Jonathan R. >> >>--=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 >> >>_______________________________________________ >>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 Apr 06 08:33:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRTdm-00056Q-SB; Thu, 06 Apr 2006 08:31:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRTdm-00056L-7Z for sip@ietf.org; Thu, 06 Apr 2006 08:31:10 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRTdk-0006sl-Sq for sip@ietf.org; Thu, 06 Apr 2006 08:31:10 -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 k36CV69g000875; Thu, 6 Apr 2006 06:31:06 -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] SIP MIB ietf-sip-mib comments - SipTransportProtocol Date: Thu, 6 Apr 2006 06:31:05 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP MIB ietf-sip-mib comments - SipTransportProtocol Thread-Index: AcY5j29dKQxxIed4SCWenzWDWU3cwgCDbzWgAWHdczABPKwkYAAB1NDAAC8iRbAEU4MgYwAALwMwABl5jWAAC8IrkAAtdP+Q From: "Jean-Francois Mule" To: "Kevin Lingle (klingle)" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: sip@ietf.org, "Romascanu, Dan \(Dan\)" , Juergen Schoenwaelder X-BeenThere: sip@ietf.org X-Mailman-Version: 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, You wrote: > i am fine with what you suggest. minor syntax issue though. > the new enum labels you propose cannot have hyphens. > therefore, they should be tlsTcp(4) and tlsSctp(5). Yes, I got carried away by the BNF from 4168... The new text should look like this: SipTransportProtocol ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "This convention is a bit map. Each bit represents a transport protocol. If a bit has value 1, then that selected transport protocol is in some way dependent on the context of the object using this convention. If a bit has value 0, then that transport protocol is not selected. Combinations of bits can be set when multiple transport protocols are selected. bit 0 : a protocol other than those defined here. bit 1 : User Datagram Protocol. bit 2 : Transmission Control Protocol. bit 3 : Stream Control Transmission Protocol. bit 4 : Transport Layer Security Protocol over TCP. bit 5 : Transport Layer Security Protocol over SCTP. SYNTAX BITS { other(0), -- none of the following udp(1), tcp(2), sctp(3), -- RFC4168=20 tlsTcp(4) =20 tlsSctp(5) -- RFC 4168 } -- REFERENCE "RFC 3261, Section 18" -- REFERENCE "RFC 4168" Jean-Francois. > -----Original Message----- > From: Kevin Lingle (klingle) [mailto:klingle@cisco.com] > Sent: Wednesday, April 05, 2006 8:42 AM > To: Jean-Francois Mule; Cullen Jennings (fluffy); Samir Srivastava > Cc: Romascanu, Dan (Dan); Juergen Schoenwaelder; sip@ietf.org > Subject: RE: [Sip] SIP MIB ietf-sip-mib comments - > SipTransportProtocol >=20 > jean-francois, >=20 > i am fine with what you suggest. minor syntax issue though. > the new enum labels you propose cannot have hyphens. > therefore, they should be tlsTcp(4) and tlsSctp(5). >=20 > kevin _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 06 11:02:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRVye-000792-UN; Thu, 06 Apr 2006 11:00:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRVyd-00078r-4A for sip@ietf.org; Thu, 06 Apr 2006 11:00:51 -0400 Received: from [66.155.254.250] (helo=isdmail1.inovsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRVyb-0002ke-TE for sip@ietf.org; Thu, 06 Apr 2006 11:00:51 -0400 Received: from greatwall ([12.181.128.3]) by isdmail1.inovsys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 6 Apr 2006 11:00:49 -0400 From: "Gary Gan" To: "'Dean Willis'" Subject: RE: [Sip] draft-ietf-sipping-conference-package : MTU Date: Thu, 6 Apr 2006 11:00:57 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcZZA77yGUfEMHOTS+aumfMT0Et7eQAg7DJA In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 06 Apr 2006 15:00:49.0579 (UTC) FILETIME=[E436BFB0:01C6598A] X-Spam-Score: 0.0 (/) 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 > In practice, nobody seems to care, and everybody pumps out large UDP > messages in fragmented form and just hopes they get there in the > right order, which usually works. > > -- > Dean The SIP doesn't define ways to reassemble the fragmented UDP messages. There is no size information in the SIP header to help reassemble. The receiver side usually just declares them as malformed messages and drops them on the floor. If we have to implement TCP, not only implement it but must load it at runtime, why do we need UDP at all? One may say that UDP has advantage for firewall traversal, they can utilize the STUN, ICE. One can also argue that UDP is more efficient since SIP handles the handshakes without the TCP's overhead. But if we MUST load TCP, where are the advantages? How do we deal with the drafts/FRCs made around UDP protocols only? Gary Gan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 06 12:20:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRXCE-0004JW-Uz; Thu, 06 Apr 2006 12:18:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRXCD-0004JR-IG for sip@ietf.org; Thu, 06 Apr 2006 12:18:57 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRXCC-0006eM-9J for sip@ietf.org; Thu, 06 Apr 2006 12:18:57 -0400 Received: from [192.168.0.102] (ppp-70-244-170-152.dsl.rcsntx.swbell.net [70.244.170.152]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k36GIpwk063511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Apr 2006 11:18:52 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <44353F66.3010400@nostrum.com> Date: Thu, 06 Apr 2006 11:18:46 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gary Gan Subject: Re: [Sip] draft-ietf-sipping-conference-package : MTU References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.244.170.152 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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 Gary Gan wrote: >The SIP doesn't define ways to reassemble the fragmented UDP messages. > You're right. That procedure is described in RFC 815. Read pages 8 and 9 of RFC 791 for context. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Apr 06 13:10:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRXxr-0002BC-0f; Thu, 06 Apr 2006 13:08:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsu8-0005Bi-2K for sip@ietf.org; Tue, 04 Apr 2006 17:17:36 -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 1FQsu6-0001Xu-Q1 for sip@ietf.org; Tue, 04 Apr 2006 17:17:36 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 04 Apr 2006 14:17:34 -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 k34LHX7T012160; Tue, 4 Apr 2006 14:17:33 -0700 (PDT) Received: from [216.102.208.11] (sjc-vpn6-700.cisco.com [10.21.122.188]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k34LHeUg014838; Tue, 4 Apr 2006 14:17:41 -0700 Message-ID: <4432E26B.1000100@cisco.com> Date: Tue, 04 Apr 2006 14:17:31 -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: "Vijay K. Gurbani" Subject: Re: [Sip] SIP/TLS (1): Domain certificates in SIP References: <44328C0D.9020407@lucent.com> <44329E69.4080205@cisco.com> <4432D635.5050503@lucent.com> In-Reply-To: <4432D635.5050503@lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1738; t=1144185462; x=1145049462; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=thomasm@cisco.com; z=From:Michael=20Thomas=20 |Subject:Re=3A=20[Sip]=20SIP/TLS=20(1)=3A=20Domain=20certificates=20in=20SIP |To:=22Vijay=20K.=20Gurbani=22=20; X=v=3Dcisco.com=3B=20h=3DBgfaRilq1at944TBLnEtlTFvjQc=3D; b=b14mTUq5CRq2wyiVGH0eXUiHqC1E0M8MMYCzJrLidC0m7kfajsWjbeTkl15qzbSegHJggXjL ovXHPl/afgNB0sKWBandV6PSf2tAnCjgl8KVWPJzMFysefy4AOPozJ9Z; Authentication-Results: imail.cisco.com; header.From=thomasm@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-Mailman-Approved-At: Thu, 06 Apr 2006 13:08:08 -0400 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: >> What if I >> want to limit the scope of what a particular sip entity is entitled >> to speak for? In particular, what about outsourced business >> functions that I might want to allow the outsourcer to speak for >> me in a more limited capacity -- say the extent of an outsourced >> marketing campaign or somesuch? > > > Are you perhaps concerned about an enterprise outsourcing to a > SIP service provider (virtual SIP servers?) ... what Ian Foster > calls "SourceForge for science" (I. Foster, "Service-Oriented > Science," Science, Vol. 308, No. 5723, pp. 814-817, May 2005; > available online at > http://www.sciencemag.org/cgi/content/full/308/5723/814?ijkey=aqCCmCFix8Ll.&keytype=ref&siteid=sci) > > > I am trying to understand how different that would be than > an explicit permission (business level agreement) given to > the outsourcer that it can act as a point of contact for > a SIP service provider... I'm coming at this from an analogous situation with email where I, say, want to outsource benefits@example.com to perform that business function, but I want to constrain the outsourcer to only speak for in this example "benefits", and not *@example.com. This is a very common arrangement with email, and with DKIM we wanted to explicitly allow this sort of arrangement, but limit the exposure from an outsourcer. I would think that similar outsourced functions for telephony, etc, will be common for SIP as well, especially when you're talking about call centers, etc. You are correct that you could also limit that at a business level, but as with most things, you'd like some layers defense, be they for honest mistakes or malfeasance. 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 Apr 06 13:10:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRXxq-0002B5-6s; Thu, 06 Apr 2006 13:08:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQoNJ-0006H1-Uu for sip@ietf.org; Tue, 04 Apr 2006 12:27:25 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQoNI-0005tT-Kx for sip@ietf.org; Tue, 04 Apr 2006 12:27:25 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 04 Apr 2006 09:27:24 -0700 X-IronPort-AV: i="4.03,164,1141632000"; d="scan'208"; a="266507363:sNHT32243632" 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 k34GRR7T004116; Tue, 4 Apr 2006 09:27:27 -0700 (PDT) Received: from [216.102.208.11] (sjc-vpn6-700.cisco.com [10.21.122.188]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k34GRVHL005202; Tue, 4 Apr 2006 09:27:32 -0700 Message-ID: <44329E69.4080205@cisco.com> Date: Tue, 04 Apr 2006 09:27:21 -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: "Vijay K. Gurbani" Subject: Re: [Sip] SIP/TLS (1): Domain certificates in SIP References: <44328C0D.9020407@lucent.com> In-Reply-To: <44328C0D.9020407@lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=2013; t=1144168053; x=1145032053; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=thomasm@cisco.com; z=From:Michael=20Thomas=20 |Subject:Re=3A=20[Sip]=20SIP/TLS=20(1)=3A=20Domain=20certificates=20in=20SIP |To:=22Vijay=20K.=20Gurbani=22=20; X=v=3Dcisco.com=3B=20h=3DBgfaRilq1at944TBLnEtlTFvjQc=3D; b=P5k7VAZfA4AHRlOygg5YtvrepxLb0CxtO6zrWV0MWHOJX3bghLKeJa+6pJplO2M241IilESj 8iV33/skO/5I0lBey/uDLKWAcEUvIKpRnxYzIwErguUzjv2ie8Gv6UMH; Authentication-Results: imail.cisco.com; header.From=thomasm@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-Mailman-Approved-At: Thu, 06 Apr 2006 13:08:08 -0400 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 One thing that strikes me about this is that it seems to imply that there is exactly two states: 0) you don't speak for the domain 1) you do speak for the domain Are people convinced that this is sufficiently granular? What if I want to limit the scope of what a particular sip entity is entitled to speak for? In particular, what about outsourced business functions that I might want to allow the outsourcer to speak for me in a more limited capacity -- say the extent of an outsourced marketing campaign or somesuch? Mike Vijay K. Gurbani wrote: > Folks: The SIP TLS draft presented during the Dallas IETF had > spawned discussions, the next step of which was to discuss > the open issues on the list. > > Over the next week or so, I will open up discrete threads to > track the issues, beginning with this email. > > A rather important open issue discussed during the meeting has > been that of domain certificates in SIP and their contents. > > To jump start this particular discussion, I have submitted a draft > on domain certificates in SIP. Until it becomes available in > the archives, you can get a version from: > > http://www.iit.edu/~gurbvij/I-D/draft-gurbani-sip-domain-certs-00.txt > http://www.iit.edu/~gurbvij/I-D/draft-gurbani-sip-domain-certs-00.html > > This draft contains some initial thoughts on the contents of a > domain certificate. The intent is to start a discussion on > whether this is a good approach or whether we should consider > other alternatives. > > Comments and feedback would be most 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 06 13:12:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRY0R-0002rV-AB; Thu, 06 Apr 2006 13:10:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRY0Q-0002pW-Gc for sip@ietf.org; Thu, 06 Apr 2006 13:10:50 -0400 Received: from maila.microsoft.com ([131.107.1.6] helo=mail1.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRY0P-00083y-3L for sip@ietf.org; Thu, 06 Apr 2006 13:10:50 -0400 Received: from mailout6.microsoft.com ([157.54.69.150]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 10:10:48 -0700 Received: from tuk-hub-02.redmond.corp.microsoft.com ([157.54.70.28]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 10:10:47 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by tuk-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 10:10:47 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 10:10:48 -0700 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] SIP/TLS (1): Domain certificates in SIP Date: Thu, 6 Apr 2006 10:11:00 -0700 Message-ID: <65F27F597EB1E44384BA802189D334C63BA237@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <44329E69.4080205@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP/TLS (1): Domain certificates in SIP Thread-Index: AcZZnL69n4+GjNG5To+ZV3GBhb4cBQAAFLLg From: "Sean Olson" To: "Michael Thomas" , "Vijay K. Gurbani" X-OriginalArrivalTime: 06 Apr 2006 17:10:48.0011 (UTC) FILETIME=[0C7109B0:01C6599D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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 SAML=20 -----Original Message----- From: Michael Thomas [mailto:thomasm@cisco.com]=20 Sent: Tuesday, April 04, 2006 9:27 AM To: Vijay K. Gurbani Cc: IETF SIP List Subject: Re: [Sip] SIP/TLS (1): Domain certificates in SIP One thing that strikes me about this is that it seems to imply that there is exactly two states: 0) you don't speak for the domain 1) you do speak for the domain Are people convinced that this is sufficiently granular? What if I want to limit the scope of what a particular sip entity is entitled to speak for? In particular, what about outsourced business functions that I might want to allow the outsourcer to speak for me in a more limited capacity -- say the extent of an outsourced marketing campaign or somesuch? Mike Vijay K. Gurbani wrote: > Folks: The SIP TLS draft presented during the Dallas IETF had spawned=20 > discussions, the next step of which was to discuss the open issues on=20 > the list. > > Over the next week or so, I will open up discrete threads to track the > issues, beginning with this email. > > A rather important open issue discussed during the meeting has been=20 > that of domain certificates in SIP and their contents. > > To jump start this particular discussion, I have submitted a draft on=20 > domain certificates in SIP. Until it becomes available in the=20 > archives, you can get a version from: > > http://www.iit.edu/~gurbvij/I-D/draft-gurbani-sip-domain-certs-00.txt > http://www.iit.edu/~gurbvij/I-D/draft-gurbani-sip-domain-certs-00.html > > This draft contains some initial thoughts on the contents of a domain=20 > certificate. The intent is to start a discussion on whether this is a > good approach or whether we should consider other alternatives. > > Comments and feedback would be most 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=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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 06 14:01:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRYlm-0000WI-CJ; Thu, 06 Apr 2006 13:59:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRYll-0000W5-CL for sip@ietf.org; Thu, 06 Apr 2006 13:59:45 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRYll-0001Hf-1X for sip@ietf.org; Thu, 06 Apr 2006 13:59:45 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 06 Apr 2006 10:59:45 -0700 X-IronPort-AV: i="4.04,93,1144047600"; d="scan'208"; a="1792492894:sNHT32909246" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k36HxiYg022713; Thu, 6 Apr 2006 10:59:44 -0700 (PDT) Received: from 171.68.225.134 ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 6 Apr 2006 17:59:44 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 06 Apr 2006 10:59:45 -0700 Subject: Re: [Sip] SIP/TLS (1): Domain certificates in SIP From: Cullen Jennings To: Sean Olsen , Mike Thomas , "Vijay K. Gurbani" Message-ID: Thread-Topic: [Sip] SIP/TLS (1): Domain certificates in SIP Thread-Index: AcZZnL69n4+GjNG5To+ZV3GBhb4cBQAAFLLgAAG0YDM= In-Reply-To: <65F27F597EB1E44384BA802189D334C63BA237@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org SAML, or the outsourced entity routes thought the main domain for identity services, or a contract that limits how they can use the key On 4/6/06 10:11 AM, "Sean Olson" wrote: > SAML > > -----Original Message----- > From: Michael Thomas [mailto:thomasm@cisco.com] > Sent: Tuesday, April 04, 2006 9:27 AM > To: Vijay K. Gurbani > Cc: IETF SIP List > Subject: Re: [Sip] SIP/TLS (1): Domain certificates in SIP > > One thing that strikes me about this is that it seems to imply that > there is exactly two states: > > 0) you don't speak for the domain > 1) you do speak for the domain > > Are people convinced that this is sufficiently granular? What if I want > to limit the scope of what a particular sip entity is entitled to speak > for? In particular, what about outsourced business functions that I > might want to allow the outsourcer to speak for me in a more limited > capacity -- say the extent of an outsourced marketing campaign or > somesuch? > > Mike > > Vijay K. Gurbani wrote: > >> Folks: The SIP TLS draft presented during the Dallas IETF had spawned >> discussions, the next step of which was to discuss the open issues on >> the list. >> >> Over the next week or so, I will open up discrete threads to track the > >> issues, beginning with this email. >> >> A rather important open issue discussed during the meeting has been >> that of domain certificates in SIP and their contents. >> >> To jump start this particular discussion, I have submitted a draft on >> domain certificates in SIP. Until it becomes available in the >> archives, you can get a version from: >> >> http://www.iit.edu/~gurbvij/I-D/draft-gurbani-sip-domain-certs-00.txt >> http://www.iit.edu/~gurbvij/I-D/draft-gurbani-sip-domain-certs-00.html >> >> This draft contains some initial thoughts on the contents of a domain >> certificate. The intent is to start a discussion on whether this is a > >> good approach or whether we should consider other alternatives. >> >> Comments and feedback would be most 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 >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 06 14:03:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRYnm-0001xo-7F; Thu, 06 Apr 2006 14:01:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRYnk-0001rr-Nt for sip@ietf.org; Thu, 06 Apr 2006 14:01:48 -0400 Received: from mail2.microsoft.com ([131.107.1.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRYnk-0001Ma-52 for sip@ietf.org; Thu, 06 Apr 2006 14:01:48 -0400 Received: from mailout5.microsoft.com ([157.54.69.148]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 11:01:47 -0700 Received: from tuk-hub-04.redmond.corp.microsoft.com ([157.54.70.30]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 11:01:19 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by tuk-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 11:01:19 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 11:01:19 -0700 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] SIP/TLS (1): Domain certificates in SIP Date: Thu, 6 Apr 2006 11:01:38 -0700 Message-ID: <65F27F597EB1E44384BA802189D334C63BA2DD@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP/TLS (1): Domain certificates in SIP Thread-Index: AcZZnL69n4+GjNG5To+ZV3GBhb4cBQAAFLLgAAG0YDMAAAy60A== From: "Sean Olson" To: "Cullen Jennings" , "Mike Thomas" , "Vijay K. Gurbani" X-OriginalArrivalTime: 06 Apr 2006 18:01:19.0094 (UTC) FILETIME=[1B1B9960:01C659A4] 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 Yep, that's an excellent point=20 -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com]=20 Sent: Thursday, April 06, 2006 11:00 AM To: Sean Olson; Mike Thomas; Vijay K. Gurbani Cc: sip@ietf.org Subject: Re: [Sip] SIP/TLS (1): Domain certificates in SIP SAML, or the outsourced entity routes thought the main domain for identity services, or a contract that limits how they can use the key On 4/6/06 10:11 AM, "Sean Olson" wrote: > SAML >=20 > -----Original Message----- > From: Michael Thomas [mailto:thomasm@cisco.com] > Sent: Tuesday, April 04, 2006 9:27 AM > To: Vijay K. Gurbani > Cc: IETF SIP List > Subject: Re: [Sip] SIP/TLS (1): Domain certificates in SIP >=20 > One thing that strikes me about this is that it seems to imply that=20 > there is exactly two states: >=20 > 0) you don't speak for the domain > 1) you do speak for the domain >=20 > Are people convinced that this is sufficiently granular? What if I=20 > want to limit the scope of what a particular sip entity is entitled to > speak for? In particular, what about outsourced business functions=20 > that I might want to allow the outsourcer to speak for me in a more=20 > limited capacity -- say the extent of an outsourced marketing campaign > or somesuch? >=20 > Mike >=20 > Vijay K. Gurbani wrote: >=20 >> Folks: The SIP TLS draft presented during the Dallas IETF had spawned >> discussions, the next step of which was to discuss the open issues on >> the list. >>=20 >> Over the next week or so, I will open up discrete threads to track=20 >> the >=20 >> issues, beginning with this email. >>=20 >> A rather important open issue discussed during the meeting has been=20 >> that of domain certificates in SIP and their contents. >>=20 >> To jump start this particular discussion, I have submitted a draft on >> domain certificates in SIP. Until it becomes available in the=20 >> archives, you can get a version from: >>=20 >> http://www.iit.edu/~gurbvij/I-D/draft-gurbani-sip-domain-certs-00.txt >> http://www.iit.edu/~gurbvij/I-D/draft-gurbani-sip-domain-certs-00.htm >> l >>=20 >> This draft contains some initial thoughts on the contents of a domain >> certificate. The intent is to start a discussion on whether this is=20 >> a >=20 >> good approach or whether we should consider other alternatives. >>=20 >> Comments and feedback would be most welcome. >>=20 >> Thank you. >>=20 >> - vijay >>=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 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 Apr 06 14:58:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRZeR-0001mo-0D; Thu, 06 Apr 2006 14:56:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRZeP-0001mi-4Z for sip@ietf.org; Thu, 06 Apr 2006 14:56:13 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRZeN-00037d-Q3 for sip@ietf.org; Thu, 06 Apr 2006 14:56:13 -0400 Received: from [10.10.2.211] (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 k36IulQB006361 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 6 Apr 2006 13:56:49 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <093FB525-1995-4863-99F8-CB3A81313735@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] draft-ietf-sipping-conference-package : MTU Date: Thu, 6 Apr 2006 13:56:07 -0500 To: Gary Gan X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 6, 2006, at 10:00 AM, Gary Gan wrote: > > If we have to implement TCP, not only implement it but must load it at > runtime, why do we need UDP at all? One may say that UDP has > advantage for > firewall traversal, they can utilize the STUN, ICE. One can also > argue that > UDP is more efficient since SIP handles the handshakes without the > TCP's > overhead. But if we MUST load TCP, where are the advantages? How do > we deal > with the drafts/FRCs made around UDP protocols only? > Just say "no"? -- 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 Apr 06 15:12:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRZsg-0008G2-Go; Thu, 06 Apr 2006 15:10:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRZsf-0008Fx-8B for sip@ietf.org; Thu, 06 Apr 2006 15:10:57 -0400 Received: from [66.155.254.250] (helo=isdmail1.inovsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRZsd-0003jM-Rx for sip@ietf.org; Thu, 06 Apr 2006 15:10:57 -0400 Received: from greatwall ([12.181.128.3]) by isdmail1.inovsys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 6 Apr 2006 15:10:55 -0400 From: "Gary Gan" To: "'Adam Roach'" Subject: RE: [Sip] draft-ietf-sipping-conference-package : MTU Date: Thu, 6 Apr 2006 15:11:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcZZlczxcvVxQvBCQ/2I6e21Z4fQ7QAF8kZg In-Reply-To: <44353F66.3010400@nostrum.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 06 Apr 2006 19:10:55.0515 (UTC) FILETIME=[D472DEB0:01C659AD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 I doubt the procedure is included in most TCP/IP stack. Gary Gan -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com] Sent: Thursday, April 06, 2006 12:19 PM To: Gary Gan Cc: 'Dean Willis'; sip@ietf.org Subject: Re: [Sip] draft-ietf-sipping-conference-package : MTU Gary Gan wrote: >The SIP doesn't define ways to reassemble the fragmented UDP messages. > You're right. That procedure is described in RFC 815. Read pages 8 and 9 of RFC 791 for context. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Apr 06 15:33:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRaCJ-0003ZU-MC; Thu, 06 Apr 2006 15:31:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRaCH-0003Xh-S6 for sip@ietf.org; Thu, 06 Apr 2006 15:31:13 -0400 Received: from rwcrmhc14.comcast.net ([204.127.192.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRaCG-0004Va-K1 for sip@ietf.org; Thu, 06 Apr 2006 15:31:13 -0400 Received: from s73602 (unknown[65.104.224.98]) by comcast.net (rwcrmhc14) with SMTP id <20060406193111m1400mjev6e>; Thu, 6 Apr 2006 19:31:11 +0000 Message-ID: <004801c659b0$56f375f0$5a087c0a@china.huawei.com> From: "Spencer Dawkins" To: References: Subject: Re: [Sip] draft-ietf-sipping-conference-package : MTU Date: Thu, 6 Apr 2006 14:28:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) 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: , Errors-To: sip-bounces@ietf.org >I doubt the procedure is included in most TCP/IP stack. > > Gary Gan I may be confused... are you saying that most TCP/IP stacks don't perform IP-level fragmentation and reassembly? Spencer > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Thursday, April 06, 2006 12:19 PM > To: Gary Gan > Cc: 'Dean Willis'; sip@ietf.org > Subject: Re: [Sip] draft-ietf-sipping-conference-package : MTU > > Gary Gan wrote: > >>The SIP doesn't define ways to reassemble the fragmented UDP messages. >> > > You're right. That procedure is described in RFC 815. Read pages 8 and 9 > of RFC 791 for context. > > /a > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Apr 06 18:44:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRdBG-00030c-CJ; Thu, 06 Apr 2006 18:42:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRdBE-00030U-6C for sip@ietf.org; Thu, 06 Apr 2006 18:42:20 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRdBC-0001nE-Rw for sip@ietf.org; Thu, 06 Apr 2006 18:42:20 -0400 Received: from [10.10.2.211] (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 k36Mgsq7007709 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 6 Apr 2006 17:42:55 -0500 Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <093FB525-1995-4863-99F8-CB3A81313735@softarmor.com> References: <093FB525-1995-4863-99F8-CB3A81313735@softarmor.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6292B969-D0BF-4007-AED3-95A2FAD608A4@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] draft-ietf-sipping-conference-package : MTU Date: Thu, 6 Apr 2006 17:42:13 -0500 To: Gary Gan , sip@ietf.org X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Apr 6, 2006, at 1:56 PM, Dean Willis wrote: > > On Apr 6, 2006, at 10:00 AM, Gary Gan wrote: >> >> If we have to implement TCP, not only implement it but must load >> it at >> runtime, why do we need UDP at all? One may say that UDP has >> advantage for >> firewall traversal, they can utilize the STUN, ICE. One can also >> argue that >> UDP is more efficient since SIP handles the handshakes without the >> TCP's >> overhead. But if we MUST load TCP, where are the advantages? How >> do we deal >> with the drafts/FRCs made around UDP protocols only? >> > > Just say "no"? > Some people thought I might be being flippant. I meant "just don't use UDP". Stuff that was built "around UDP only" is not compliant with the core SIP specs and we have no commitment to reverse compatibility for things that badly out of compliance. -- 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 Apr 06 21:12:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRfUc-0001RL-JB; Thu, 06 Apr 2006 21:10:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRfUa-0001RG-Un for sip@ietf.org; Thu, 06 Apr 2006 21:10:28 -0400 Received: from wproxy.gmail.com ([64.233.184.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRfUX-0007Bp-Nn for sip@ietf.org; Thu, 06 Apr 2006 21:10:28 -0400 Received: by wproxy.gmail.com with SMTP id i5so401961wra for ; Thu, 06 Apr 2006 18:10:25 -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=HNbyvaPhVfydmCM3zFgWqQPcX0UkRckwCuVZO+jQKzHoVzu5ZbPaovGP42+yXnIO0JyyX7SMB5tHsytghNsFb4zrhbcemPY4T0PXRrHDgnIfdUrst9znWA4NNhijILfW6NGt2BcyUbf1JH9dqaawW6+i0G4sT8RU9EpV8oabIic= Received: by 10.64.149.8 with SMTP id w8mr1257446qbd; Thu, 06 Apr 2006 18:10:25 -0700 (PDT) Received: by 10.64.156.5 with HTTP; Thu, 6 Apr 2006 18:10:25 -0700 (PDT) Message-ID: <7f5ac7240604061810y39ef7888yaeb0904c764d6791@mail.gmail.com> Date: Fri, 7 Apr 2006 10:10:25 +0900 From: "Mahesh Govind" To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Sip] dialog establishing notify X-BeenThere: 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="===============1840180408==" Errors-To: sip-bounces@ietf.org --===============1840180408== Content-Type: multipart/alternative; boundary="----=_Part_12590_29133076.1144372225215" ------=_Part_12590_29133076.1144372225215 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline HI, Can you please give an example of dialog established using NOTIFY and its usage . >From rfc 3265 "If a proxy wishes to see all of the SUBSCRIBE and NOTIFY requests for a given dialog, it MUST record-route the initial SUBSCRIBE and any dialog-establishing NOTIFY requests. Such proxies SHOULD also record-route all other SUBSCRIBE and NOTIFY requests." With regards Mahesh ------=_Part_12590_29133076.1144372225215 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
HI,
 
Can you please  give an example of  dialog established using= NOTIFY and its usage .
 
 
From rfc 3265
  "If a proxy wishes to see all of the SUBSCRIBE
 &n= bsp; and NOTIFY requests for a given dialog, it MUST record-route the
&n= bsp;  initial SUBSCRIBE and any dialog-establishing NOTIFY requests.&n= bsp; Such
   proxies SHOULD also record-route all other SUBSCR= IBE and NOTIFY
   requests."
 
With regards
Mahesh
 
------=_Part_12590_29133076.1144372225215-- --===============1840180408== 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 --===============1840180408==-- From sip-bounces@ietf.org Thu Apr 06 21:47:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRg2d-0001eo-At; Thu, 06 Apr 2006 21:45:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRg2a-0001eS-GM for sip@ietf.org; Thu, 06 Apr 2006 21:45:36 -0400 Received: from wproxy.gmail.com ([64.233.184.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRg2Z-0007lS-9I for sip@ietf.org; Thu, 06 Apr 2006 21:45:36 -0400 Received: by wproxy.gmail.com with SMTP id i22so275042wra for ; Thu, 06 Apr 2006 18:45:34 -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=JTHQl2U5Z94Bj9u0hQ4YBwIK9r3k3NTF9IX0b2zSK0JOH28ehWxvUdfDGWeVVGQqxkHMGQ9DZyRwXzxWH99wC9qCRz6/FPIdaD6k1GlEibf0tC9QAWX7csU7dXSY/rDbZkCgKkyGY71iA1s705LZm8bXyeIaX7Jyto99P3VghTI= Received: by 10.65.35.4 with SMTP id n4mr940075qbj; Thu, 06 Apr 2006 18:45:33 -0700 (PDT) Received: by 10.64.156.5 with HTTP; Thu, 6 Apr 2006 18:45:33 -0700 (PDT) Message-ID: <7f5ac7240604061845q5dd2be48h6bb2ca93349b84e1@mail.gmail.com> Date: Fri, 7 Apr 2006 10:45:33 +0900 From: "Mahesh Govind" To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Subject: [Sip] Fwd: dialog establishing notify(Please ignore) X-BeenThere: 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="===============2043025104==" Errors-To: sip-bounces@ietf.org --===============2043025104== Content-Type: multipart/alternative; boundary="----=_Part_12878_4784594.1144374333356" ------=_Part_12878_4784594.1144374333356 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline HI , Please ignore the previous mail . read it wrongly . -mahesh ---------- Forwarded message ---------- From: Mahesh Govind Date: Apr 7, 2006 10:10 AM Subject: dialog establishing notify To: sip@ietf.org HI, Can you please give an example of dialog established using NOTIFY and its usage . >From rfc 3265 "If a proxy wishes to see all of the SUBSCRIBE and NOTIFY requests for a given dialog, it MUST record-route the initial SUBSCRIBE and any dialog-establishing NOTIFY requests. Such proxies SHOULD also record-route all other SUBSCRIBE and NOTIFY requests." With regards Mahesh ------=_Part_12878_4784594.1144374333356 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
HI ,
Please ignore the previous mail .
read it wrongly .
 
-mahesh


---------- Forwarded message ----------
From: Mahesh Govind <vu3mmg@gmail.com>
Date: Apr 7, 2006 = 10:10 AM
Subject: dialog establishing notify
To: sip@ietf.org

 
HI,
 
Can you please  give an example of  dialog established using= NOTIFY and its usage .
 
 
From rfc 3265
  "If a proxy wishes to see all of the SUBSCRIBE
 &n= bsp; and NOTIFY requests for a given dialog, it MUST record-route the
&n= bsp;  initial SUBSCRIBE and any dialog-establishing NOTIFY requests.&n= bsp; Such
   proxies SHOULD also record-route all other SUBSCR= IBE and NOTIFY=20
   requests."
 
With regards
Mahesh
 
------=_Part_12878_4784594.1144374333356-- --===============2043025104== 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 --===============2043025104==-- From sip-bounces@ietf.org Fri Apr 07 02:01:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRjzn-0002Mq-O4; Fri, 07 Apr 2006 01:58:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRjzS-0002FN-SR for sip@ietf.org; Fri, 07 Apr 2006 01:58:38 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRjzJ-0006iP-BV for sip@ietf.org; Fri, 07 Apr 2006 01:58:38 -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 k375wLe00827 for ; Fri, 7 Apr 2006 01:58:21 -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 Date: Fri, 7 Apr 2006 00:58:18 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60B5B5C40@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Outbound Keep Alive and stun retransmission Thread-Index: AcZZnL69n4+GjNG5To+ZV3GBhb4cBQAAFLLgAAG0YDMAGGK5IA== From: "Samir Srivastava" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Sip] Outbound Keep Alive and stun retransmission X-BeenThere: sip@ietf.org X-Mailman-Version: 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, Section 4.4 of outbound-03 states=20 "The time between keep alive requests when using UDP based transports SHOULD be a random number between 24 and 29 seconds while for TCP based transports it SHOULD be a random number between 95 and 120 seconds. These times MAY be configurable." http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-03.txt states in section 7.1 "In other words, requests would be sent at times 0ms, 100ms, 300ms, 700ms, 1500ms, 3100ms, 4700ms, 6300ms, and 7900ms. At 9500ms, the client considers the transaction to have failed if no response has been received." Is the retransmission logic overridden in outbound in case of loss of responses ?=20 Thx Samiry _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 07 02:49:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRkkG-0005AE-3y; Fri, 07 Apr 2006 02:47:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRkkE-0005A9-KK for sip@ietf.org; Fri, 07 Apr 2006 02:46:58 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRkk6-0007vo-LG for sip@ietf.org; Fri, 07 Apr 2006 02:46:58 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k376junV008207; Fri, 7 Apr 2006 09:45:59 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 09:46:41 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 09:46:41 +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: Multiple flows and forking Date: Fri, 7 Apr 2006 09:46:40 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F022CCA0B@esebe103.NOE.Nokia.com> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1CE2@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: Multiple flows and forking Thread-Index: AcZYs8k8l4LD9v5pSk2cfMo4fm5yTgAnsqVgAALz/fAAA5FAwAABKiyQAAOe9IA= From: To: X-OriginalArrivalTime: 07 Apr 2006 06:46:41.0389 (UTC) FILETIME=[06EDB9D0:01C65A0F] X-Spam-Score: 0.2 (/) X-Scan-Signature: b058151374d77ee76edaac850f7449fb 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, So the problem with the current text it that if the UA gets a number of proxy URIs (or simply IP addresses of proxies) via DHCP SIP server option or DNS queries, the text could be understood to mandate UA to send REGISTER and maintain flow to all of them ? I doubt whether this has been the intention and would agree=20 that the text should be clarified.=20 Currently the text seems to assume that the number of proxies towards which to send REGISTER would be in the control of service provider or UA owner by configuration. However when finding proxies via DHCP that is not the case. When configuring DHCP there might be other reasons to populate multiple proxies into it, rather than just give primary and backup proxies in SIP Outbound sense. Your comment regarding to "proxy URI" seems also to have the point. In general when RFC 3261 referes to outbound proxies, it just refers them as "proxies" instead of=20 emphasizing the "URI". Keeping all those points in mind I would suggest rewriting first paragraph of section 4.2 as follows: 4.2 Initial Registrations Those outbound proxies that UA knows make up the default=20 outbound-proxy-set. The UA may learn those proxies via configuration or by using some other mechanisms like DHCP=20 or DNS. UA SHOULD support sets with at least two outbound proxies (primary and backup) and MAY support sets with up to four proxies. The UA MUST send a REGISTER via one or=20 multiple proxies belonging to the outbound-proxy-set. For reliability reasons the UA SHOULD send a REGISTER for at least via one primary and one backup proxy. Regards, Erkki =20 >-----Original Message----- >From: ext Christer Holmberg (JO/LMF)=20 >[mailto:christer.holmberg@ericsson.com]=20 >Sent: 06.April.2006 15:11 >To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki); jdrosen@cisco.com >Cc: sip@ietf.org >Subject: RE: [Sip] Outbound: Multiple flows and forking > > >Hi Erikki,=20 > >>First, I may have missunderstood what you wrote, but you=20 >still seem to=20 >>say that a UA MUST send a REGISTER to all outbuond proxies it=20 >is aware=20 >>of. > >Yes, you have understand me correctly. I said that since I did not get >what would be the point of configuring the UA with multiple proxies >while not sending the REGISTER to all of them ? > >[CHH] To give an example from IMS: an IME UE may have the address of >multiple P-CSCFs. But, it only registers with one of them.=20 >And, I see no >reason why it now should have to register with all of them. > >And, again, mobile terminals (not only IMS UEs) do have to consider the >battery impacts. I haven't had time to think whehter Jerone's proposal >from yesterday would have an impacts, but I still don't see a=20 >reason why >a UA should be mandated to send REGISTER to all outbound proxies. I DO >understand that there may be an advantage to do so, but sometimes it >simply may not be possible/feasible. [/CHH] > > >>In my email I separate these two items: >>1. How many proxies the UA allows to be configured > >[CHH] I think that is an implementation issue, and I see no reason to >standardize that. [/CHH] > >>2. How many proxies the UA is really configured with > >[CHH] Do you mean how many proxies the UA is registered with? If so, my >answer is that it is also an implementation issue. [/CHH] > > >>It could help me to understand the issue if you could point out to me >to which purpose those proxies would be used that=20 >>the UA is configured with but it would not send a REGISTER to ? > >[CHH] Please note that the proxies may also have other=20 >functions. Again, >in IMS I guess the outbound proxy functionality would be located in the >P-CSCF, and I don't think sending REGISTERs to multiple P-CSCFs is very >wise. [/CHH] > > >>And if you are referring to a case of configuring only a single proxy >URI that would resolve to multiple proxy addresses=20 >>by DNS, then my answer would come along with the separate I-D I am >currently preparing. > >[CHH] Remember that the outbound proxy may not necessarily be >configured. The address of the outbound proxy may be retrieved using >other means, for example in the way an IMS UE gets the address(es) of >the P-CSCF. [/CHH] > > >I will NOT suggest sending REGISTER to all the addresses a DNS SRV or A >query might result. But if you think clarifying the DNS issue must be >done within the outbound I-D, please be a bit more specific about your >proposal.=20 > >[CHH] My understanding of the text is that the UA shall send a REGISTER >to each outbound proxy address it is aware of - no matter if they are >retrieved from a single URI, or multiple URIs. [/CHH] > > > > >>Second, I would again like to ask whether we should use=20 >"outbound proxy > >>address" instead of "outbound proxy URI". Because, the=20 >outbound address > >>may not be provided/configured to the UA as a URI (even if we=20 >want that > >>as some kind of default behavior). > >When being configured those could be SIP URIs (possibly with a=20 >number of >URI parameters), FDQNs or even IP addresses. But in the end=20 >the UA would >derive from those the SIP URIs of the proxies. So I find the following >statement to be OK: > > UAs are configured with one or more SIP URIs representing=20 >the default > outbound-proxy-set. > >[CHH] Of course the UA will derive a URI, but that doesn't=20 >mean you have >to configure an URI. As you say, you can simply configure an IP address >(or, you can retrieve it from somewhere else). [/CHH] > > >To me it does not matter in which format those addresses are=20 >represented >in the configuration UI or configuration message arriving to the UA. > >[CHH] Exactly. So we would need re-wording to make that clear. [/CHH] > > >The statement above would just tell what would be the result of the >configuration: the UA would, in the end of the day, own the SIP URIs >representing the proxies, as part of its configuration. > >[CHH] I think the "result of the configuration" is basic SIP. Not sure >we need to say so much about that. [/CHH] > > >Regards, > >Christer > > > >>-----Original Message----- >>From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com] >>Sent: 6. huhtikuuta 2006 11:45 >>To: jdrosen@cisco.com; Christer Holmberg (JO/LMF) >>Cc: sip@ietf.org >>Subject: RE: [Sip] Outbound: Multiple flows and forking >> >> >>Hi Jonathan, >> >>>> The text says: >>>>=20 >>>>"However, a UA MUST support sets with at least two outbound proxy=20 >>>>URIs (primary and backup) and SHOULD support sets with up to four=20 >>>>URIs. For each outbound proxy URI in the set, the UA MUST send a=20 >>>>REGISTER in the normal way using this URI as the default outbound=20 >>>>proxy." >>>>=20 >>>> I don't think we should mandate this, because it is very much=20 >>>> dependent on the architecture, transport techniques >>> >>>Mandate what? The minimal number of outbound proxies that should be=20 >>>supported? Or the fact that you register on each? >>>For the latter, its an essential part of the story so I=20 >don't see how=20 >>>you can make it optional. In the former case, if you don't specify a=20 >>>minimum that is supported, how do you have interop? >> >>Please remember that section 3 Overview of the spec clearly describes=20 >>three different example configurations as follows: >> >>3.2 Single Registrar and UA >>3.3 Multiple Connections from a User Agent >>3.4 Edge Proxies >> >>There is clearly a possibility for the registrar/proxy and UA to use=20 >>only one single flow between them: >> >>3.2 Single Registrar and UA >> >> In this example, a single server is acting as both a registrar and >> proxy. >> >> +-----------+ >> | Registrar | >> | Proxy | >> +-----+-----+ >> | >> | >> +----+--+ >> | User | >> | Agent | >> +-------+ >> >> User Agents which form only a single flow continue to register >> normally but include the instance-id as described in Section 4.1. >> >>Sections 3.3 and 3.4 discuss the ways of building extra=20 >reliability by=20 >>forming multiple flows towards multiple next hops. In my=20 >understanding=20 >>section 4 allows the outbound-proxy-set to consist of a=20 >single proxy or > >>multiple ones (depending on what has been configured to the UA) but=20 >>currently mandate the UA to support configuring multiple proxies >>(2 - 4) into the set. This would preclude implementations that would=20 >>only support configuring one single proxy to outbound-proxy-set, even=20 >>if this would work and be sufficient for certain types of deployment. >> >>4.2 Initial Registrations >> >> UAs are configured with one or more SIP URIs representing the=20 >>default >> outbound-proxy-set. The specification assumes the set is=20 >determined >> via configuration but future specifications may define other >> mechanisms such as using DNS to discover this set. How the UA is >> configured is outside the scope of this specification. =20 >>However, a UA >> MUST support sets with at least two outbound proxy URIs=20 >(primary and >> backup) 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. >> >>Further on it is mandated that each of the registrations shall form a=20 >>new flow, that the UA must keep alive and monitor: >> >> These ordinary registration requests MUST also add a=20 >distinct reg-id >> parameter to the Contact header field. Each one of these >> registrations will form a new flow from the UA to the proxy. >> >>I would be happy for changing the text as follows: >> >> However, a UA >> SHOULD support sets with at least two outbound proxy URIs (primary=20 >>and >> backup) and MAY support sets with up to four URIs. For each >> outbound proxy URI configured or automatically discovered in=20 >> the set, the UA MUST send a REGISTER in the normal way using this=20 >> URI as the default outbound proxy. >> >>This would mean the following: >> >>1. An UA vendor would be allowed to implement an UA supporting 1 - 4 >> URIs for the outbound-proxy-set. >> >>2. The UA must a send a separate registration (and form a separate >> flow) to each of the proxy (configured or automatically discovered) >> within the outbound-proxy-set (up to the implementation specific >> maximum). >> >>So this would mean that you could have e.g. >> >>- An UA supporting and configured a single outbound proxy, sending >> REGISTER and forming a single flow towards it >> >>- An UA supporting and configured three proxies, sending REGISTER >> and forming a separate flow towards each of them >> >>- An UA supporting four proxies but configured with only two proxies. >> In this case UA would send REGISTER and form separate flows towards >> those two proxies configured. >> >>- An UA configured with a single outbound proxy URI and resolving it >> with DNS to a primary and backup proxy, towards which the REGISTER >> must be sent and the flows formed. (Note: I am working on the I-D >> to specify the related DNS mechanisms). >> >>Regards, >> >>Erkki >> >>>-----Original Message----- >>>From: ext Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>>Sent: 05.April.2006 16:20 >>>To: Christer Holmberg (JO/LMF) >>>Cc: sip@ietf.org >>>Subject: Re: [Sip] Outbound: Multiple flows and forking >>> >>>inline: >>> >>>Christer Holmberg (JO/LMF) wrote: >>> >>>>=20 >>>> Hi, >>>>=20 >>>> A couple of issues on chapter 4.2. >>>>=20 >>>> The text says: >>>>=20 >>>> "However, a UA MUST support sets with at least two outbound >>>proxy URIs >>>> (primary and backup) and SHOULD support sets with up to four >>>URIs. For each >>>>=20 >>>> 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 >>>> I don't think we should mandate this, because it is very >>>much dependent >>>> on the architecture, transport techniques etc. >>> >>>Mandate what? The minimal number of outbound proxies that should be=20 >>>supported? Or the fact that you register on each? For the=20 >latter, its=20 >>>an essential part of the story so I don't see how you can make it=20 >>>optional. >>>In the former case, if you don't specify a minimum that is=20 >supported,=20 >>>how do you have interop? >>> >>>-Jonathan R. >>> >>>--=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 >>> >>>_______________________________________________ >>>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 Fri Apr 07 03:10:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRl3g-0002EK-QY; Fri, 07 Apr 2006 03:07:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRl3Y-0001qu-Hy for sip@ietf.org; Fri, 07 Apr 2006 03:06:56 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRkuG-0008O9-QQ for sip@ietf.org; Fri, 07 Apr 2006 02:57:22 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 55D5013F90F; Fri, 7 Apr 2006 09:57:19 +0300 (EEST) Received: from rautu (guanine208.gprs.dnafinland.fi [62.78.120.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 287DE13F8F8; Fri, 7 Apr 2006 09:57:08 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id EB97DF15A8; Fri, 7 Apr 2006 09:57:57 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17462.3445.805316.929074@rautu.tutpro.com> Date: Fri, 7 Apr 2006 09:57:57 +0300 From: Juha Heinanen To: Subject: RE: [Sip] Outbound: Multiple flows and forking In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F022CCA0B@esebe103.NOE.Nokia.com> References: <5EB80D22825EEE42872083AD5BFFB5945D1CE2@esealmw113.eemea.ericsson.se> <8B1D53AEF7B03449A6D3771B3B7F850F022CCA0B@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: 7bac9cb154eb5790ae3b2913587a40de Cc: sip@ietf.org, 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: > The UA MUST send a REGISTER via one or > multiple proxies belonging to the outbound-proxy-set. > For reliability reasons the UA SHOULD send a REGISTER > for at least via one primary and one backup proxy. what is the reason for designating the proxies as primary or 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 Fri Apr 07 03:14:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRl8h-0003Mv-1j; Fri, 07 Apr 2006 03:12:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRl8f-0003Mq-Sx for sip@ietf.org; Fri, 07 Apr 2006 03:12:13 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRl8e-0000fZ-Dq for sip@ietf.org; Fri, 07 Apr 2006 03:12:13 -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 k377BLvU029137; Fri, 7 Apr 2006 10:11:22 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 10:11:27 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 10:11:26 +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: Multiple flows and forking Date: Fri, 7 Apr 2006 10:11:26 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F022CCA67@esebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: Multiple flows and forking Thread-Index: AcZaEJFDKhHrKdA+TX+bBXVEVSJ5iwAAPdpgAAAEsaA= From: To: X-OriginalArrivalTime: 07 Apr 2006 07:11:26.0591 (UTC) FILETIME=[7C2D90F0:01C65A12] X-Spam-Score: 0.2 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: sip@ietf.org, 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 Hi, >what is the reason for designating the proxies as primary or secondary? I do not know exactly. However it is a convention the current spec seems to consistently use starting from section 3.3 Multiple Connections from a User Agent To me these two flows look equivalent from the proxy / registrar perspective. I could not find any normative text to state that when forwarding inbound requests, the primary flow should be preferred over the backup flow. Maybe those consepts were just introduced to make the idea of multiple flows more understandable. However it could cause some confusion that there is some kind of preference between=20 those. I hope the authors could explain this if needed. Regards, Erkki >-----Original Message----- >From: ext Juha Heinanen [mailto:jh@tutpro.com]=20 >Sent: 07.April.2006 09:58 >To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki) >Cc: christer.holmberg@ericsson.com; sip@ietf.org >Subject: RE: [Sip] Outbound: Multiple flows and forking > >Erkki.Koivusalo@nokia.com writes: > > > The UA MUST send a REGISTER via one or=20 > > multiple proxies belonging to the outbound-proxy-set. > > For reliability reasons the UA SHOULD send a REGISTER > > for at least via one primary and one backup proxy. > >what is the reason for designating the proxies as primary or 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 Fri Apr 07 03:17:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRlBr-0003x1-Lw; Fri, 07 Apr 2006 03:15:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRlBp-0003ww-Lp for sip@ietf.org; Fri, 07 Apr 2006 03:15:29 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRlBp-0000o9-Bc for sip@ietf.org; Fri, 07 Apr 2006 03:15:29 -0400 Received: by tutpro.com (Postfix, from userid 65534) id C176513F90F; Fri, 7 Apr 2006 10:15:28 +0300 (EEST) Received: from rautu (guanine208.gprs.dnafinland.fi [62.78.120.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 4753913F90D; Fri, 7 Apr 2006 10:15:15 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id A95DDF15A9; Fri, 7 Apr 2006 10:15:37 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17462.4505.634488.176806@rautu.tutpro.com> Date: Fri, 7 Apr 2006 10:15:37 +0300 From: Juha Heinanen To: Subject: RE: [Sip] Outbound: Multiple flows and forking In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F022CCA67@esebe103.NOE.Nokia.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F022CCA67@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: d17f825e43c9aed4fd65b7edddddec89 Cc: sip@ietf.org, 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: > To me these two flows look equivalent from the proxy / registrar > perspective. I could not find any normative text to state that > when forwarding inbound requests, the primary flow should be > preferred over the backup flow. to me, load balancing sounds a better idea that using primarily the primary proxy. -- 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 Apr 07 03:38:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRlVO-0008LL-OT; Fri, 07 Apr 2006 03:35:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRlVN-0008Jv-5h for sip@ietf.org; Fri, 07 Apr 2006 03:35:41 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRlSk-0001hB-KN for sip@ietf.org; Fri, 07 Apr 2006 03:33:00 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id B330C3BEDF; Fri, 7 Apr 2006 09:32:52 +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 02020-01-100; Fri, 7 Apr 2006 09:32:52 +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 29EE53BE9E; Fri, 7 Apr 2006 09:32:48 +0200 (CEST) From: Fredrik Thulin To: sip@ietf.org Subject: Re: [Sip] Outbound: Multiple flows and forking Date: Fri, 7 Apr 2006 09:32:42 +0200 User-Agent: KMail/1.9.1 References: <8B1D53AEF7B03449A6D3771B3B7F850F022CCA67@esebe103.NOE.Nokia.com> In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F022CCA67@esebe103.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200604070932.42556.ft@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.505 tagged_above=-99 required=7 tests=[AWL=0.160, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: jh@tutpro.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 Friday 07 April 2006 09:11, Erkki.Koivusalo@nokia.com wrote: > Hi, > > >what is the reason for designating the proxies as primary or > > secondary? Thanks for bringing this up. I've been thinking about doing so myself. I'm not too fond of dividing my servers into primary and secondary servers either. Secondary servers seem to be out of order when they are needed (when the primary goes down) far too often. Bad (or underdimensioned) hardware is used, configuration is out of sync etc. This could of course all be blamed on the server operator not doing it's job, but I don't like standards introducing primary vs. secondary servers anyways. See more below though. > I do not know exactly. However it is a convention the current > spec seems to consistently use starting from section > > 3.3 Multiple Connections from a User Agent Quote from that section : " 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." I guess the reason for the primary/secondary separation is that the author(s) forsee that multi-homed proxys will be more common than the current norm in the future. Probably as an effect of IPv6 was my thought. If a proxy is multi-homed, presumably to obtain better network connectivity, what is the bad thing about getting two flows from a user agent to that same physical proxy? The explanation to that that I have come to think of is that if primary/secondary separation is removed, and a provider has two hosts with two IP addresses each, the UA would resolve the single proxy set to ProxyA-IP1, ProxyA-IP2, ProxyB-IP1, ProxyB-IP2 If the UA then decides that two flows is adequate, it would be a pity if it picked ProxyA-IP1 and ProxyA-IP2. > To me these two flows look equivalent from the proxy / registrar > perspective. I could not find any normative text to state that > when forwarding inbound requests, the primary flow should be > preferred over the backup flow. In case of two (or more) edge-proxys, the stored Path for the most recently registered binding would indicate to the Registrar which edge-proxy to use as "primary". For the proxys, I agree the flows are equal. This, together with clever provisioning systems that let different UAs use ProxyA as primary and ProxyB as secondary, and vice versa, makes the primary/secondary be "just" a DNS issue, like the draft suggests, I guess. /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 Apr 07 03:38:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRlVT-0008Na-80; Fri, 07 Apr 2006 03:35:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRlVR-0008MP-OR for sip@ietf.org; Fri, 07 Apr 2006 03:35:45 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRlNH-0001aS-AT for sip@ietf.org; Fri, 07 Apr 2006 03:27:20 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7F4C16E8; Fri, 7 Apr 2006 09:27:18 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 09:27:18 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 09:27: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="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound: Multiple flows and forking Date: Fri, 7 Apr 2006 09:27:17 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1CEA@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: Multiple flows and forking Thread-Index: AcZaExAs5x7E/91vSyir5fYm/j+51gAAV3IQ From: "Christer Holmberg \(JO/LMF\)" To: "Juha Heinanen" , X-OriginalArrivalTime: 07 Apr 2006 07:27:17.0784 (UTC) FILETIME=[B3221980:01C65A14] X-Brightmail-Tracker: AAAAAA== 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 Hi Erkki, Your proposed text change looks good. If we want to call it something else than "primary and secondary" I am ok with that too.=20 However, I am not sure "load balancing" is the best possible wording, because my understanding is that the purpose of contacting multiple outbound proxies is more related to realiablilty than load balancing. Regards, Christer=20 =20 -----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com]=20 Sent: 7. huhtikuuta 2006 10:16 To: Erkki.Koivusalo@nokia.com Cc: Christer Holmberg (JO/LMF); sip@ietf.org Subject: RE: [Sip] Outbound: Multiple flows and forking Erkki.Koivusalo@nokia.com writes: > To me these two flows look equivalent from the proxy / registrar > perspective. I could not find any normative text to state that > when forwarding inbound requests, the primary flow should be > preferred over the backup flow. to me, load balancing sounds a better idea that using primarily the primary proxy. -- 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 Apr 07 03:52:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRlid-0007ve-Ax; Fri, 07 Apr 2006 03:49:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRliW-0007sk-4S for sip@ietf.org; Fri, 07 Apr 2006 03:49:16 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRliU-00025F-Pf for sip@ietf.org; Fri, 07 Apr 2006 03:49:16 -0400 Received: by tutpro.com (Postfix, from userid 65534) id B7D7313F90D; Fri, 7 Apr 2006 10:49:13 +0300 (EEST) Received: from rautu (mitosis132.gprs.dnafinland.fi [62.78.122.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id BCCAD13F8F8; Fri, 7 Apr 2006 10:49:07 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 2A231F15A8; Fri, 7 Apr 2006 10:49:56 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17462.6564.120294.805508@rautu.tutpro.com> Date: Fri, 7 Apr 2006 10:49:56 +0300 From: Juha Heinanen To: "Christer Holmberg (JO/LMF)" Subject: RE: [Sip] Outbound: Multiple flows and forking In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1CEA@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1CEA@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: 7bac9cb154eb5790ae3b2913587a40de 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 Christer Holmberg (JO/LMF) writes: > However, I am not sure "load balancing" is the best possible wording, > because my understanding is that the purpose of contacting multiple > outbound proxies is more related to realiablilty than load balancing. if it is possible to achieve both at the same time, it is stupid to do only 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 Fri Apr 07 04:10:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRm1Y-0001Z8-92; Fri, 07 Apr 2006 04:08:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRlzr-0008C1-IC for sip@ietf.org; Fri, 07 Apr 2006 04:07:11 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRll9-00028k-Qa for sip@ietf.org; Fri, 07 Apr 2006 03:52:02 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3C6284F0001; Fri, 7 Apr 2006 09:51:59 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 09:51:58 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 09:51: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="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Outbound: Multiple flows and forking Date: Fri, 7 Apr 2006 09:51:57 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1CEF@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: Multiple flows and forking Thread-Index: AcZaF8imACADwVcUQwqgtBN4RepIlwAACQ/A From: "Christer Holmberg \(JO/LMF\)" To: "Juha Heinanen" X-OriginalArrivalTime: 07 Apr 2006 07:51:58.0337 (UTC) FILETIME=[259C8F10:01C65A18] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Then we could write something like: "For reliability or load balancing reasons, the UA MAY send REGISTER to more than one outbound proxy..." Or something like that... Regards, Christer=20 -----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com]=20 Sent: 7. huhtikuuta 2006 10:50 To: Christer Holmberg (JO/LMF) Cc: Erkki.Koivusalo@nokia.com; sip@ietf.org Subject: RE: [Sip] Outbound: Multiple flows and forking Christer Holmberg (JO/LMF) writes: > However, I am not sure "load balancing" is the best possible wording, > because my understanding is that the purpose of contacting multiple > outbound proxies is more related to realiablilty than load balancing. if it is possible to achieve both at the same time, it is stupid to do only 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 Fri Apr 07 05:23:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRn9f-0005sH-K7; Fri, 07 Apr 2006 05:21:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRn9e-0005sC-AT for sip@ietf.org; Fri, 07 Apr 2006 05:21:22 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRn9d-0005eY-Hg for sip@ietf.org; Fri, 07 Apr 2006 05:21:22 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A0567CC5; Fri, 7 Apr 2006 11:21:20 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 11:21:20 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 11:21:19 +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] Question on Service Route Discovery Procedure duringRegistration Date: Fri, 7 Apr 2006 11:21:19 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1CF7@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question on Service Route Discovery Procedure duringRegistration Thread-Index: AcZY11XLxNlAVgV4QtyjtYIOrSPtngBQ6ujA From: "Christer Holmberg \(JO/LMF\)" To: "Dean Willis" , "Lu, Yang, VF-DE" X-OriginalArrivalTime: 07 Apr 2006 09:21:19.0888 (UTC) FILETIME=[A1585100:01C65A24] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, If we are going to update RFC 3608 there are a couple of things I think we should also consider. 1. UA behavior Currently the text says that the UA MAY use the Service-Route e.g. to create a route for future requests. Now, if we are going to add an option-tag (to be used by the UA in the Require/Supported header) I think we should also say that the UA SHALL use the Service-Route for future request (why would it otherwise ask for it?), and also HOW the route is created. 24.229 defines how IMS UEs create the route, so similar text is needed for generic UA behavior. 2. Registrar processing of Path I think we should also take Jonathan's draft, draft-rosenberg-sip-route-construct-00, into consideration, which allows a registrar to build a Service-Route set based on the received Path headers. Regards, Christer =20 =20 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: 5. huhtikuuta 2006 20:06 To: Lu, Yang, VF-DE Cc: sip@ietf.org Subject: Re: [Sip] Question on Service Route Discovery Procedure duringRegistration On Apr 3, 2006, at 7:09 AM, Lu, Yang, VF-DE wrote: > > Dear All > > RFC 3261 Section 8.2.4 "Applying Extensions" says > > "A UAS that wishes to apply some extension when generating the=20 > response MUST NOT do so unless support for that extension is indicated > in the Supported header field in the request". > > However, the Service Route discovery procedure during Registration=20 > described in RFC 3608 does not follow this as shown in the example in=20 > Section 6. > > Are there any reasons for that and for the fact that there is no need=20 > to define an Option Tag for Service Route? I remember debating this at the time that RFC 3608 was being edited, but do not recall why we ended up with the text therein. Looking at it from the perspective of history, at the moment it appears that you're absolutely right and that RFC 3608 is inconsistent with RFC 3261 in this respect. I do recall that there was a decision to not provide an option-tag for Service-Route related to the extremely "optional" nature of the information conveyed by Service-Route, which is actually completely orthogonal to the operation of the REGISTER request itself. We didn't want the UAC to be able to "demand" a service-route. With some deployment experience behind us, I'm not sure that this was really an important issue. Jonathan is very fond of saying that both RFC 3608 and RFC 3327 are "broken, or at best horribly underspecified". I've been planning to rev them once GRUU and the route-construction draft stabilize, although its also been proposed that the route-construction draft might actually replace both 3608 and 3327. In either case, we should address this issue at that time. Question to the WG: Should we post an errata for RFC 3608 to the RFC Editor page discussing 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 07 08:20:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRpvT-0000yv-9A; Fri, 07 Apr 2006 08:18:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRpvR-0000yq-Jn for sip@ietf.org; Fri, 07 Apr 2006 08:18:53 -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 1FRpvQ-00024e-9j for sip@ietf.org; Fri, 07 Apr 2006 08:18:53 -0400 Received: from BPenfield [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A8A701F0; Fri, 07 Apr 2006 08:18:47 -0400 Message-ID: <004d01c65a3d$6ba83b10$800101df@acmepacket.com> From: "Bob Penfield" To: "Samir Srivastava" , References: <62B9B0847CC47543B6B3B5E26BD268E60B5B5C40@zrc2hxm2.corp.nortel.com> Subject: Re: [Sip] Outbound Keep Alive and stun retransmission Date: Fri, 7 Apr 2006 08:18:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 Section 4.4 is talking about how often to do a STUN keep alive transaction. The retransmission timers for an individual STUN transaction over UDP would follow the rfc3489bis procedures. I believe the intention is that the time between initiating the STUN keep alive is constant for a UA once it has selected a value. So for example, if the selected interval was 28, it would initiate a STUN keep alive transaction at t0, t0+28sec, t0+56secs, t0+84secs and so on regardless of how long an individual STUN transaction took to get a response. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 bpenfield@acmepacket.com ----- Original Message ----- From: "Samir Srivastava" To: Sent: Friday, April 07, 2006 1:58 AM Subject: [Sip] Outbound Keep Alive and stun retransmission Hi, Section 4.4 of outbound-03 states "The time between keep alive requests when using UDP based transports SHOULD be a random number between 24 and 29 seconds while for TCP based transports it SHOULD be a random number between 95 and 120 seconds. These times MAY be configurable." http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-03.txt states in section 7.1 "In other words, requests would be sent at times 0ms, 100ms, 300ms, 700ms, 1500ms, 3100ms, 4700ms, 6300ms, and 7900ms. At 9500ms, the client considers the transaction to have failed if no response has been received." Is the retransmission logic overridden in outbound in case of loss of responses ? Thx Samiry _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 07 19:00:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRzup-0006LQ-Jz; Fri, 07 Apr 2006 18:58:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRzuo-0006LI-RV for sip@ietf.org; Fri, 07 Apr 2006 18:58:54 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRzun-00013R-IO for sip@ietf.org; Fri, 07 Apr 2006 18:58:54 -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 k37Mwnn25936; Fri, 7 Apr 2006 18:58:49 -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: Multiple flows and forking Date: Fri, 7 Apr 2006 17:58:23 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60B5B690F@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: Multiple flows and forking Thread-Index: AcZaGEbX2rlLK/ykTma2QcJAIDadGAAe7kog From: "Samir Srivastava" To: "Juha Heinanen" , "Christer Holmberg \(JO/LMF\)" 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 Here keep alive traffic is most of the time. How the load balancing will be achieved unless we have different keep alive timers for primary and secondary or secondary flows comes into picture when primary is failed. Is that author intended ? SRV RFC used the term primary and secondary for services with different priority values. But here we don't have any of such designation as we are keeping flow alives with available proxies for reliability. Section 3.3 of outbound talks about the load balancing among primaries, but how it is achieved as mostly we have keep alive traffic ? How SRV helps here as noted in the draft. Thx Samir -----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com]=20 Sent: Friday, April 07, 2006 12:50 AM To: Christer Holmberg (JO/LMF) Cc: sip@ietf.org Subject: RE: [Sip] Outbound: Multiple flows and forking Christer Holmberg (JO/LMF) writes: > However, I am not sure "load balancing" is the best possible wording, > because my understanding is that the purpose of contacting multiple > outbound proxies is more related to realiablilty than load balancing. if it is possible to achieve both at the same time, it is stupid to do only 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 07 19:27:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS0KK-0006pk-0l; Fri, 07 Apr 2006 19:25:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS0KI-0006pf-Rn for sip@ietf.org; Fri, 07 Apr 2006 19:25:14 -0400 Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56] helo=zrtps0kp.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FS0KH-0001Zt-IE for sip@ietf.org; Fri, 07 Apr 2006 19:25:14 -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 k37NPAe03571; Fri, 7 Apr 2006 19:25:10 -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: Multiple flows and forking Date: Fri, 7 Apr 2006 18:25:07 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60B5B6967@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound: Multiple flows and forking Thread-Index: AcZaGEbX2rlLK/ykTma2QcJAIDadGAAe7kogAAEOuLA= From: "Samir Srivastava" To: "Samir Srivastava" , "Juha Heinanen" , "Christer Holmberg \(JO/LMF\)" X-Spam-Score: 0.1 (/) 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 After reading 3.3 again, it looks that a UA is going to connect two of the primary machines from the SRV lookup which will yield in set of machines. So multiple UA's are distibuting on the "set of primary machines" using SRV weight. While secondary is just a backup, No active flow.=20 I might be wrong in interpretation :-) Thx Samir=20 -----Original Message----- From: Srivastava, Samir [SC100:8826:EXCH]=20 Sent: Friday, April 07, 2006 3:58 PM To: 'Juha Heinanen'; Christer Holmberg (JO/LMF) Cc: sip@ietf.org Subject: RE: [Sip] Outbound: Multiple flows and forking Here keep alive traffic is most of the time. How the load balancing will be achieved unless we have different keep alive timers for primary and secondary or secondary flows comes into picture when primary is failed. Is that author intended ? SRV RFC used the term primary and secondary for services with different priority values. But here we don't have any of such designation as we are keeping flow alives with available proxies for reliability. Section 3.3 of outbound talks about the load balancing among primaries, but how it is achieved as mostly we have keep alive traffic ? How SRV helps here as noted in the draft. Thx Samir -----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com] Sent: Friday, April 07, 2006 12:50 AM To: Christer Holmberg (JO/LMF) Cc: sip@ietf.org Subject: RE: [Sip] Outbound: Multiple flows and forking Christer Holmberg (JO/LMF) writes: > However, I am not sure "load balancing" is the best possible wording, > because my understanding is that the purpose of contacting multiple > outbound proxies is more related to realiablilty than load balancing. if it is possible to achieve both at the same time, it is stupid to do only 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 09 20:04:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSjrQ-0006L2-S5; Sun, 09 Apr 2006 20:02:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSjrP-0006Kw-MN for sip@ietf.org; Sun, 09 Apr 2006 20:02:27 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSjrP-0004ab-9K for sip@ietf.org; Sun, 09 Apr 2006 20:02:27 -0400 Received: from [131.161.248.91] (open-131-161-248-91.cliq.com [131.161.248.91]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k3A02KF06492; Sun, 9 Apr 2006 17:02:20 -0700 In-Reply-To: <003201c6581a$5dc93820$31713b51@BEMBUSTER> References: <001b01c657ad$4e1f7140$31713b51@BEMBUSTER> <724f0adb9bc60dd7c2470bafe1051049@ekabal.com> <003201c6581a$5dc93820$31713b51@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7e2ba47a62b9533774cf8a0ba8b5ac0d@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Sat, 8 Apr 2006 16:07:09 -0700 To: "Jeroen van Bemmel" X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.3 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: sip@ietf.org, Rohan Mahy Subject: [Sip] Re: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-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 On Apr 4, 2006, at 12:02, Jeroen van Bemmel wrote: > Hi Rohan > > see inline > > Regards, > Jeroen > ----- Original Message ----- From: "Rohan Mahy" > To: "Jeroen van Bemmel" > Cc: "Rohan Mahy" ; > Sent: Tuesday, April 04, 2006 6:26 PM > Subject: Re: > http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-03.txt > > > > On Apr 3, 2006, at 23:02, Jeroen van Bemmel wrote: > >> Rohan, >> >> Two things, 1 comment and a nit: >> >> 1. clarification on recent flows: There are several references to the >> registrar using the most recent flow. > > Hi Jeroen, > > The intent is that if you have more than one registration with the same > AOR, instance, *AND* reg-id you use the most recently registered of > these. An AOR and Contact with no instance will never match one with > an instance so I think this is pretty safe. If you can think of a > better way to express this in the draft please let me know. > > [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. >> There are two potential issues with this: >> 1a q-value ordering - if the UAC first registers a flow with q=0.8 >> and later with q=0.1, I think the former should be used (i.e. q-value >> taking precedence over flow establishment time). Same goes for >> scenario's with two different UACs registering for the same user, one >> using outbound and another one not (with higher q-value) >> 1b multiple flows established with a single REGISTER - what is the >> most recent one in this case? > > A single register request can only establish one flow maximum. > > [Jvb] Right, I mixed up my thoughts. So should the draft state then > that the REGISTER request SHOULD NOT contain more than 1 Contact? yes. thanks, -rohan >> 2 - section 11 says "the proxy stores the value of the Path header >> field", this should be "the registrar" > > good catch. 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 Mon Apr 10 02:19:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSpiH-0002Dj-Uf; Mon, 10 Apr 2006 02:17:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSph5-00017W-Ay for sip@ietf.org; Mon, 10 Apr 2006 02:16:11 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSpUX-0000gP-0O for sip@ietf.org; Mon, 10 Apr 2006 02:03:17 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3A6JWXF010496 for ; Sun, 9 Apr 2006 23:19:32 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k3A6Gdxl021836 for ; Mon, 10 Apr 2006 01:16:39 -0500 (CDT) Received: from motorola.com ([10.232.117.39]) by ZMY16EXM66.ds.mot.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Apr 2006 14:03:09 +0800 Message-ID: <4439F7CE.2030001@motorola.com> Date: Mon, 10 Apr 2006 11:44:38 +0530 From: Preeti agarwal User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List References: <5EB80D22825EEE42872083AD5BFFB5945D1ABC@esealmw113.eemea.ericsson.se><440453A8.9020201@cisco.com> <44045C27.6000805@cisco.com> <002201c63d14$844bd3c0$31713b51@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Apr 2006 06:03:10.0006 (UTC) FILETIME=[71A98D60:01C65C64] X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.5 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Sip] Presence RLS X-BeenThere: sip@ietf.org X-Mailman-Version: 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, Need clearification for the below mentioned scenario in case of Presence RLS. 1. SUB1 has created RLS doc named 'list1', having entries a) 'A@domain.com', b) B@domain.com 2. 'B' does not exist on server . 3. SUB1 subscribe for 'list1@domain.com'; 4. SUB1 gets notify with meta information as 'active' for A and 'pending' for B. Now what should be the next response from the server? Should SUB1 receive one more notify with status "terminated' for B. OR, There won't be any further notifies containing B's information. Also please point me to the document i can refer to know the server's behaviour in such scenarios. Thanks. Priti _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Apr 10 02:25:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSpnQ-0004pE-II; Mon, 10 Apr 2006 02:22:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSpnP-0004p9-FA for sip@ietf.org; Mon, 10 Apr 2006 02:22:43 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSpnO-00022e-3y for sip@ietf.org; Mon, 10 Apr 2006 02:22:43 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 09 Apr 2006 23:22:42 -0700 X-IronPort-AV: i="4.04,105,1144047600"; d="scan'208"; a="1793299134:sNHT31450164" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k3A6MfYg004905; Sun, 9 Apr 2006 23:22:41 -0700 (PDT) Received: from 171.68.225.134 ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Mon, 10 Apr 2006 06:22:41 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Sun, 09 Apr 2006 23:22:43 -0700 Subject: Re: [Sip] SIP/TLS (1): Domain certificates in SIP From: Cullen Jennings To: "Vijay K. Gurbani" Message-ID: Thread-Topic: [Sip] SIP/TLS (1): Domain certificates in SIP Thread-Index: AcZcZyzSaxgDaMhaEdqaBAARJEEJ/A== In-Reply-To: <4432E105.6000704@lucent.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 4/4/06 2:11 PM, "Vijay K. Gurbani" wrote: > Cullen Jennings wrote: >> I don't understand the DNS name would refer to a host or conversely >> why the SIP name does not. Either can refer to either. I don't see >> the need for distinction - the cert needs to refer to the name used >> to reach the proxy - that is typically called the "domain" but may >> refer to a single host or many. > > If the "domain" refers to many hosts, then is the cert shared among > all the hosts? Or does each host have a different cert with the same > domainname in SAN but a unique serial number? > > If a cert only has a SAN of DNS:proxy-1.example.com" is the intent, > then that proxy-1 is the authority for example.com? Then, if another > cert has a SAN of "DNS:proxy-1.south.example.com" is the intent that > proxy-1 is the authority for south.example.com zone AND example.com > zone? It's like TLS for https. There could be 10 host that server web pages for www.example.com. All the hosts could use the same certificate or they could have different certificates but all the certificates would assert a name of www.example.com The fact that the a reverse dns lookup of the IP address of one of the hosts might return server1.example.com has nothing to do with what the certificate needs to say. The user was trying to connect to www.example.com and if the certificate asserts an identity other than what the user was trying to connect to, an error needs to be raised. > >> I see no need to step into any CN disasters - they are very hard to >> specify and we have no backwards compatible need to do it. SIP has >> been SAN from the beginning. > > OK. Thanks for the clarification. > > However, in rfc3261, SAN is only mentioned in connection with S/MIME > certs (section 23.2). For TLS certs, rfc3261 simply says "Proxy > servers, redirect servers, and registrars SHOULD possess a site > certificate whose subject corresponds to their canonical hostname". > It is probably the intent that the "subject" in that sentence refer > to SAN; but it is not clear from simply reading the sentence that > this is indeed the intent. I suspect that canonical hostname meant what the name by which the previous hop would try to connect. This is more what you would call domain - ie example.com not proxy-1.example.com. This phrase has caused much confusion and we should clarify it in the spec. > > Thanks, > > - 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 Apr 10 09:51:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSwlt-0001YF-3C; Mon, 10 Apr 2006 09:49:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSwlr-0001YA-Gu for sip@ietf.org; Mon, 10 Apr 2006 09:49:35 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSwlq-0001v8-6b for sip@ietf.org; Mon, 10 Apr 2006 09:49:35 -0400 Received: from [206.176.144.210] (206-176-144-210.waymark.net [206.176.144.210]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k3ADoDS8009881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Apr 2006 08:50:14 -0500 Message-ID: <443A626A.4040700@softarmor.com> Date: Mon, 10 Apr 2006 08:49:30 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] Question on Service Route Discovery Procedure duringRegistration References: <5EB80D22825EEE42872083AD5BFFB5945D1CF7@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1CF7@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Christer Holmberg (JO/LMF) wrote: > Currently the text says that the UA MAY use the Service-Route e.g. to > create a route for future requests. > > Now, if we are going to add an option-tag (to be used by the UA in the > Require/Supported header) I think we should also say that the UA SHALL > use the Service-Route for future request (why would it otherwise ask for > it?), and also HOW the route is created. 24.229 defines how IMS UEs > create the route, so similar text is needed for generic UA behavior. Why must the US a route all requests through this domain? What if it has multiple registrations? > 2. Registrar processing of Path > > I think we should also take Jonathan's draft, > draft-rosenberg-sip-route-construct-00, into consideration, which allows > a registrar to build a Service-Route set based on the received Path > headers. Lovely idea, and 3608 suggests it as a possibility. Doesn't work for IMS AFAIk, so it can't be a MUST. -- 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 Apr 10 10:09:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSx3f-0000k1-Us; Mon, 10 Apr 2006 10:07:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSx3d-0000jt-Qq for sip@ietf.org; Mon, 10 Apr 2006 10:07:57 -0400 Received: from wproxy.gmail.com ([64.233.184.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSx3c-0002mO-J1 for sip@ietf.org; Mon, 10 Apr 2006 10:07:57 -0400 Received: by wproxy.gmail.com with SMTP id i22so815565wra for ; Mon, 10 Apr 2006 07:07:56 -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=UkFJObeDBgnFwHoeRILma7tQe2NcOu7aEShQJlaTrd9iMVEaOicWmCqnDu5vrr4JJ0MiuZ0SvYYjEm9KzMgTLrTLPnbAU4mXrDrrFLl1va3iOlPYdSswk0wGhAsSmrHBl9Fqld4J92AVQ+IEdTRh/N+ErncBAAblMOwTy3DQaq8= Received: by 10.64.210.20 with SMTP id i20mr862437qbg; Mon, 10 Apr 2006 07:07:54 -0700 (PDT) Received: by 10.64.156.5 with HTTP; Mon, 10 Apr 2006 07:07:54 -0700 (PDT) Message-ID: <7f5ac7240604100707o7439e8dcn2ef2facfe3bfa5ad@mail.gmail.com> Date: Mon, 10 Apr 2006 23:07:54 +0900 From: "Mahesh Govind" To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Sip] offer answer X-BeenThere: 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="===============0358314597==" Errors-To: sip-bounces@ietf.org --===============0358314597== Content-Type: multipart/alternative; boundary="----=_Part_2246_12869820.1144678074943" ------=_Part_2246_12869820.1144678074943 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline HI, I have a doubt . If an offer is having a media line m=3Daudio 4000 RTP/AVP 1 2 3 can an answer contain , If an offer is having a media line m=3Daudio 4000 RTP/AVP 1 2 3 5 With thanks and regards Mahesh ------=_Part_2246_12869820.1144678074943 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
HI,
 
I have a doubt .
 
If  an offer is having  a media line
m=3Daudio 4000 RTP/AVP 1 2 3
 
can an answer  contain ,
 
If  an offer is having  a media line
m=3Daudio 4000 RTP/AVP 1 2 3 5
 
With thanks and regards
Mahesh
 
------=_Part_2246_12869820.1144678074943-- --===============0358314597== 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 --===============0358314597==-- From sip-bounces@ietf.org Mon Apr 10 10:40:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSxXf-0007NH-FD; Mon, 10 Apr 2006 10:38:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSxXd-0007N9-N8 for sip@ietf.org; Mon, 10 Apr 2006 10:38:57 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSxXc-00045a-B9 for sip@ietf.org; Mon, 10 Apr 2006 10:38:57 -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 k3AEcYSt009830; Mon, 10 Apr 2006 09:38:34 -0500 (CDT) Received: from [135.104.50.100] (dhcp50100.cs.bell-labs.com [135.104.50.100]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k3AEcXh12253; Mon, 10 Apr 2006 09:38:33 -0500 (CDT) Message-ID: <443A6EB9.2060304@bell-labs.com> Date: Mon, 10 Apr 2006 09:42:01 -0500 From: Alan Jeffrey User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051019) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] SIP/TLS (1): Domain certificates in SIP References: In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: "sip@ietf.org" , "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: , Content-Type: multipart/mixed; boundary="===============2139461430==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============2139461430== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080805000305010001030909" This is a cryptographically signed message in MIME format. --------------ms080805000305010001030909 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit The requirement for all SIP proxies handling incoming traffic have a DNS entry "example.com" is a reasonable one. However, requiring all SIP proxies handling outbound traffic to also have DNS entry "example.com" seems less reasonable. Imagine an architecture where example.com is a proxy which does nothing but forward messages to proxyN.example.com for processing. These proxies do not have a DNS entry example.com, but they are authorized as authoritative proxies for the domain example.com. The HTTP analogy is true for proxies handling incoming traffic, but not for proxies handling outgoing traffic. Alan. Cullen Jennings wrote: > On 4/4/06 2:11 PM, "Vijay K. Gurbani" wrote: > > >>Cullen Jennings wrote: >> >>>I don't understand the DNS name would refer to a host or conversely >>>why the SIP name does not. Either can refer to either. I don't see >>>the need for distinction - the cert needs to refer to the name used >>>to reach the proxy - that is typically called the "domain" but may >>>refer to a single host or many. >> >>If the "domain" refers to many hosts, then is the cert shared among >>all the hosts? Or does each host have a different cert with the same >>domainname in SAN but a unique serial number? >> >>If a cert only has a SAN of DNS:proxy-1.example.com" is the intent, >>then that proxy-1 is the authority for example.com? Then, if another >>cert has a SAN of "DNS:proxy-1.south.example.com" is the intent that >>proxy-1 is the authority for south.example.com zone AND example.com >>zone? > > > It's like TLS for https. There could be 10 host that server web pages for > www.example.com. All the hosts could use the same certificate or they could > have different certificates but all the certificates would assert a name of > www.example.com > > The fact that the a reverse dns lookup of the IP address of one of the hosts > might return server1.example.com has nothing to do with what the certificate > needs to say. The user was trying to connect to www.example.com and if the > certificate asserts an identity other than what the user was trying to > connect to, an error needs to be raised. > > >>>I see no need to step into any CN disasters - they are very hard to >>>specify and we have no backwards compatible need to do it. SIP has >>>been SAN from the beginning. >> >>OK. Thanks for the clarification. >> >>However, in rfc3261, SAN is only mentioned in connection with S/MIME >>certs (section 23.2). For TLS certs, rfc3261 simply says "Proxy >>servers, redirect servers, and registrars SHOULD possess a site >>certificate whose subject corresponds to their canonical hostname". >>It is probably the intent that the "subject" in that sentence refer >>to SAN; but it is not clear from simply reading the sentence that >>this is indeed the intent. > > > I suspect that canonical hostname meant what the name by which the previous > hop would try to connect. This is more what you would call domain - ie > example.com not proxy-1.example.com. This phrase has caused much confusion > and we should clarify it in the spec. > > >>Thanks, >> >>- 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 -- Alan Jeffrey +1 630 224 0175 Bell Labs, Lucent Technologies http://cm.bell-labs.com/who/ajeffrey/ --------------ms080805000305010001030909 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJZzCC Aw4wggJ3oAMCAQICAw+fEDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUxMDEwMDE0NzM2WhcNMDYxMDEwMDE0NzM2 WjB9MRAwDgYDVQQEEwdKZWZmcmV5MRwwGgYDVQQqExNBbGFuIFN0ZXdhcnQgQXVzdGluMSQw IgYDVQQDExtBbGFuIFN0ZXdhcnQgQXVzdGluIEplZmZyZXkxJTAjBgkqhkiG9w0BCQEWFmFq ZWZmcmV5QGJlbGwtbGFicy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDw 5Cul6gbCRPip8crm2iiMo6nYik6LiQLaF6gjTkhh0qs0ez2KtdxKmswHiuf7yZISvmvAGfqv GMsWrQejVvV7DlL2Tn2XL68FuFv6Sco6+mnM7tcRt5zjXpEyLwPzn1OFfoHW0CWxeM/LMrEN 7BIhUhzz4ZnFCYf0t1ws+sZH5YEwa2dvKRsxe9ThA1VwL9pWbfJxqtK2ETw7myV4/SdOJP68 Y0mAdXNw+LjmSCetvYxcg9K8YLGjpjloUeamGYU9v3LXznKUrXWaagU13XYYqOjt0Nv0awwJ 7Gn5fKTNEhLIfmA7w0CbrOzH+qhxQPNOJLbeQx9H/ySTHMFy3dLnAgMBAAGjMzAxMCEGA1Ud EQQaMBiBFmFqZWZmcmV5QGJlbGwtbGFicy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0B AQQFAAOBgQATaJTPOE4MEgjz7MOKXa7HsDzy/HyG29dlufCT/rQRvslmd3iibxAI5B1/vKik hhgSy41MWfIb/thRzvdN2qX4diPDuXCUW1wpsOeh9QU0qwvCda8311iIljiRqs7VKEN9bVRx yCAzL3REtosiDHKfc+CzagJAuDfJgTbel6LIaTCCAw4wggJ3oAMCAQICAw+fEDANBgkqhkiG 9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0 eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0Ew HhcNMDUxMDEwMDE0NzM2WhcNMDYxMDEwMDE0NzM2WjB9MRAwDgYDVQQEEwdKZWZmcmV5MRww GgYDVQQqExNBbGFuIFN0ZXdhcnQgQXVzdGluMSQwIgYDVQQDExtBbGFuIFN0ZXdhcnQgQXVz dGluIEplZmZyZXkxJTAjBgkqhkiG9w0BCQEWFmFqZWZmcmV5QGJlbGwtbGFicy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDw5Cul6gbCRPip8crm2iiMo6nYik6LiQLa F6gjTkhh0qs0ez2KtdxKmswHiuf7yZISvmvAGfqvGMsWrQejVvV7DlL2Tn2XL68FuFv6Sco6 +mnM7tcRt5zjXpEyLwPzn1OFfoHW0CWxeM/LMrEN7BIhUhzz4ZnFCYf0t1ws+sZH5YEwa2dv KRsxe9ThA1VwL9pWbfJxqtK2ETw7myV4/SdOJP68Y0mAdXNw+LjmSCetvYxcg9K8YLGjpjlo UeamGYU9v3LXznKUrXWaagU13XYYqOjt0Nv0awwJ7Gn5fKTNEhLIfmA7w0CbrOzH+qhxQPNO JLbeQx9H/ySTHMFy3dLnAgMBAAGjMzAxMCEGA1UdEQQaMBiBFmFqZWZmcmV5QGJlbGwtbGFi cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQATaJTPOE4MEgjz7MOKXa7H sDzy/HyG29dlufCT/rQRvslmd3iibxAI5B1/vKikhhgSy41MWfIb/thRzvdN2qX4diPDuXCU W1wpsOeh9QU0qwvCda8311iIljiRqs7VKEN9bVRxyCAzL3REtosiDHKfc+CzagJAuDfJgTbe l6LIaTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhh d3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me 7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQq E88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEA AaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9j cmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcN AQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNw PP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq72 6jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggM7MIIDNwIBATBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDD58QMAkGBSsOAwIaBQCgggGn MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA2MDQxMDE0NDIw MVowIwYJKoZIhvcNAQkEMRYEFHytccg6fGHPfZ8PTb2DIThfQ/lwMFIGCSqGSIb3DQEJDzFF MEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPnxAwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDD58QMA0GCSqGSIb3 DQEBAQUABIIBAHitMwtuE1IetipQ/C8M71zG2oG5OVUabijJhZCtJ+UBfEtrkV5ETRphWuYb yN7g3/fLc7T6YXVMvLXTiArfYzsC8lVnhpbZhXbAZlOwyFNseJRqT8z4Km1cKTzfg4SCX4oP anqdZakN4iXiJFHJwRLd781X5impBwGSM2wCebvcXtXWN5PkbM4IJquUenVzQHNKh84sgQn6 v7CirSL6MxQDSZfQM57C6lwMBBfFPUmk1u5nVJ2bx7DrcIEcs69ntbTVt9vMuACdcM4XHmAq CuLkakNk7AGbicCiM35scTXN5ouKxTfvu5YzyEEFFYmFAiZusd9nKKybjkuwUfUpA5UAAAAA AAA= --------------ms080805000305010001030909-- --===============2139461430== 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 --===============2139461430==-- From sip-bounces@ietf.org Mon Apr 10 16:17:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT2nZ-0001pm-Rg; Mon, 10 Apr 2006 16:15:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT2nY-0001pP-D7 for sip@ietf.org; Mon, 10 Apr 2006 16:15:44 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT2nX-0002Lh-1j for sip@ietf.org; Mon, 10 Apr 2006 16:15:44 -0400 Received: from [64.101.173.238] ([64.101.173.238]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k3AKGMC7011408 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 10 Apr 2006 15:16:24 -0500 Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <739E02BA-E514-436C-A12B-FD1B7AEC8DA0@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Mon, 10 Apr 2006 15:15:46 -0500 To: sip@ietf.org X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Robert Sparks , Keith Drage Subject: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-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 I'd like to ask the working group to review the "forking loop fix" draft preparatory to requesting publication of it as a standards- track RFC. The document revised following the Dallas meeting document is available from: http://www.ietf.org/internet-drafts/draft-ietf-sip-fork-loop-fix-01.txt I'd like to complete this review by May 7, 2006. Please send all comments to the list and copy the author, rjs@estacado.net -- 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 Apr 10 16:54:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT3NH-0002XM-3E; Mon, 10 Apr 2006 16:52:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT3NF-0002Wt-HP for sip@ietf.org; Mon, 10 Apr 2006 16:52:37 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT3NE-0003r0-Uk for sip@ietf.org; Mon, 10 Apr 2006 16:52:37 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 10 Apr 2006 13:52:38 -0700 X-IronPort-AV: i="4.04,109,1144047600"; d="scan'208"; a="267797454:sNHT32784468" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k3AKqV1t011865; Mon, 10 Apr 2006 13:52:36 -0700 (PDT) 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, 10 Apr 2006 16:52:36 -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, 10 Apr 2006 16:52:35 -0400 Message-ID: <443AC593.5070201@cisco.com> Date: Mon, 10 Apr 2006 16:52:35 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Apr 2006 20:52:35.0460 (UTC) FILETIME=[B1F39C40:01C65CE0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: SIP IETF Subject: [Sip] Re: I-D ACTION:draft-audet-sip-sips-guidelines-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 Francois, Its good that there is now work on this, since it is a very underspecified subject. I have a number of comments. These aren't complete answers to anything, but are a start at discussion of some issues. Paul > 3. Upgrading and dowgrading between SIP and SIPS This is complicated because the scheme name was used to signify this property. Given that is the way it is, IMO both upgrading and downgrading should be permitted, with the understanding that either change may fail if the called party doesn't support it. Note, I don't mean downgrading in mid-call. I mean that that someone in possession of a sip URI may derive and use the corresponding sips URI to send a request, and visa versa. A given request would have to be all-sip or all-sips end-to-end. > Upgrading a SIP to a SIPS URI AOR is very useful when registering. > It allows for a UAC to register both SIP and SIPS contacts in a > single registration (with multiple contacts) against a single SIP AOR > (registrations only allows for single AOR, but multiple contacts). > The registrar, upon seeing both a SIP and SIPS contact (potentially > prioritized with a proper q-value), and a single SIP AOR MUST infer > that the user is reachabe with a SIPS AOR consisting of the same AOR > as the SIP URI, but with the scheme changed from "sip" to "sips". I agree with the goal to eliminate the need for separately registering to a SIP and SIPS AOR. I also agree that there should be one way to register for support of both sip and sips - you shouldn't have to guess how the registrar does it. This may require the use of an option tag. But it seems entirely redundant to register two different contacts in order to support both secure and insecure calls. It also may be impossible to do both in a single REGISTER if a NAT is involved and -outbound- is required to resolve that. The trick is how to indicate what is intended. It seems to me the following should do the trick: - If you want the possibility of security, then the R-URI of the REGISTER must be SIPS. - if you support only SIPS, then the Contact address in the register needs to be SIPS. - if you support either SIP or SIPS, then the Contact address in the REGISTER needs to be SIP with transport=tls. (I don't think this has been deprecated. More on this later.) (The SIP contact with transport=tls can be safely upgraded to a SIPS contact with transport=tcp. There is however a problem with SCTP - TBD.) - if you only want to support SIP, then the contact address can be SIP without transport=tls. - I'm not sure about requirements on To (or From) in the REGISTER. With above it doesn't seem to matter. - There need to be some rules about Path and Service-Route. I'm not sure about those yet. > OPEN ISSUE: RFC 3261 is not very clear what a UAS is to do if it > doesn't support SIPS and TLS, in which case the previous paragraph > obviously can not apply. Shoud we state that the UAS MUST reject > the request with response code 416? In that case, should we say > that the UAC MUST NOT re-attempt the request with a SIP URI by > automatically replacing the SIPS scheme with a SIP scheme? The 416 seems right to me. But I see no reason to forbid the UAC from retrying with SIP. This should be a policy issue for it. What is essential is that it indicate to its user if the connection is secure or not. (This could get complex, since security of signaling and media are separate things. So you might have multiple lock icons in the UI.) > When a target refresh occurs within a dialog (e.g., re-INVITE, > UPDATE), the UAC SHOULD include a Contact header with a SIPS URI if > the original request creating the dialog was sent over TLS, and the > Request-URI contained a SIPS URI. I don't see why this should be forbidden in a *request*, where it may be refused. It is problematic in a response, where it can't be refused. Changing the level of security mid-dialog could be useful, at least in the case of 3pcc. It may reflect a transfer where the new partner doesn't have the same capabilities or requirements. OTOH, making the change in a response is also needed for many useful 3pcc flows. > OPEN ISSUE: Handling of annomalies are not very well defined in RFC > 3261. For example, what if the request contains a SIPS contact > but the response contains a SIP contact? What if a UAS receives a > SIP Contact replacing a SIPS contact in a target refresh? I guess the same options are available as when there is an unacceptable offer in a response: either cope with the undesired change, or else tear down the dialog if you can't live with it. > RFC 3261 makes it clear that the use of the "transport=tls" URI > transport parameter in SIPS or SIP URIs has been deprecated. > However, it has not been eliminated from the ABNF in section 25 of > RFC 3261. That isn't so clear to me. It seems to clearly ban this parameter in a SIPS URI, but I don't see the words as banning it in a SIP URI. The value in using it, as mentioned above, is that it means a TLS hop can be used for either insecure requests, but that the URI could also be upgraded to SIPS in order that it be permissible in a transaction that is using SIPS. This seems necessary to avoid two separate connections when using -outbound- for nat traversal. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 10 18:14:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT4cu-0000fj-JK; Mon, 10 Apr 2006 18:12:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT4ct-0000fe-2H for sip@ietf.org; Mon, 10 Apr 2006 18:12:51 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT4cr-0007dB-MW for sip@ietf.org; Mon, 10 Apr 2006 18:12:51 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 10 Apr 2006 15:12:49 -0700 X-IronPort-AV: i="4.04,109,1144047600"; d="scan'208"; a="1793593147:sNHT35238062" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k3AMCmYg025415; Mon, 10 Apr 2006 15:12:48 -0700 (PDT) Received: from 171.68.225.134 ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Mon, 10 Apr 2006 22:12:43 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Mon, 10 Apr 2006 15:12:44 -0700 Subject: Re: [Sip] SIP/TLS (1): Domain certificates in SIP From: Cullen Jennings To: Alan Jeffrey Message-ID: Thread-Topic: [Sip] SIP/TLS (1): Domain certificates in SIP Thread-Index: AcZc6+QQIs31N8jfEdqHRAARJEEJ/A== In-Reply-To: <443A6EB9.2060304@bell-labs.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: "sip@ietf.org" , "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 I don't think that any of the current SIP RFCs requires a proxy to have a DNS entry if it only sends requests. Personally I'm not sure I see the big deal in giving them a DNS entry because I am suspicious that there won't be many cases where "outbound only" is possible but I'm not seeing any reason that we do need to make them have a DNS entry either. On 4/10/06 7:42 AM, "Alan Jeffrey" wrote: > The requirement for all SIP proxies handling incoming traffic have a DNS > entry "example.com" is a reasonable one. However, requiring all SIP > proxies handling outbound traffic to also have DNS entry "example.com" > seems less reasonable. > > Imagine an architecture where example.com is a proxy which does nothing > but forward messages to proxyN.example.com for processing. These > proxies do not have a DNS entry example.com, but they are authorized as > authoritative proxies for the domain example.com. > > The HTTP analogy is true for proxies handling incoming traffic, but not > for proxies handling outgoing traffic. > > Alan. > > Cullen Jennings wrote: >> On 4/4/06 2:11 PM, "Vijay K. Gurbani" wrote: >> >> >>> Cullen Jennings wrote: >>> >>>> I don't understand the DNS name would refer to a host or conversely >>>> why the SIP name does not. Either can refer to either. I don't see >>>> the need for distinction - the cert needs to refer to the name used >>>> to reach the proxy - that is typically called the "domain" but may >>>> refer to a single host or many. >>> >>> If the "domain" refers to many hosts, then is the cert shared among >>> all the hosts? Or does each host have a different cert with the same >>> domainname in SAN but a unique serial number? >>> >>> If a cert only has a SAN of DNS:proxy-1.example.com" is the intent, >>> then that proxy-1 is the authority for example.com? Then, if another >>> cert has a SAN of "DNS:proxy-1.south.example.com" is the intent that >>> proxy-1 is the authority for south.example.com zone AND example.com >>> zone? >> >> >> It's like TLS for https. There could be 10 host that server web pages for >> www.example.com. All the hosts could use the same certificate or they could >> have different certificates but all the certificates would assert a name of >> www.example.com >> >> The fact that the a reverse dns lookup of the IP address of one of the hosts >> might return server1.example.com has nothing to do with what the certificate >> needs to say. The user was trying to connect to www.example.com and if the >> certificate asserts an identity other than what the user was trying to >> connect to, an error needs to be raised. >> >> >>>> I see no need to step into any CN disasters - they are very hard to >>>> specify and we have no backwards compatible need to do it. SIP has >>>> been SAN from the beginning. >>> >>> OK. Thanks for the clarification. >>> >>> However, in rfc3261, SAN is only mentioned in connection with S/MIME >>> certs (section 23.2). For TLS certs, rfc3261 simply says "Proxy >>> servers, redirect servers, and registrars SHOULD possess a site >>> certificate whose subject corresponds to their canonical hostname". >>> It is probably the intent that the "subject" in that sentence refer >>> to SAN; but it is not clear from simply reading the sentence that >>> this is indeed the intent. >> >> >> I suspect that canonical hostname meant what the name by which the previous >> hop would try to connect. This is more what you would call domain - ie >> example.com not proxy-1.example.com. This phrase has caused much confusion >> and we should clarify it in the spec. >> >> >>> Thanks, >>> >>> - 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 10 20:50:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT73c-0007rh-4t; Mon, 10 Apr 2006 20:48:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT73b-0007rc-5I for sip@ietf.org; Mon, 10 Apr 2006 20:48:35 -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 1FT5fZ-0001p5-Gr for sip@ietf.org; Mon, 10 Apr 2006 19:19:41 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FT5YH-0000FG-Eq for sip@ietf.org; Mon, 10 Apr 2006 19:12:10 -0400 Received: from [64.101.173.238] ([64.101.173.238]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k3ANCkjP011943 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 10 Apr 2006 18:12:48 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <33C7D45A-4A39-422C-894F-34AD67022023@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] SIP/TLS (1): Domain certificates in SIP Date: Mon, 10 Apr 2006 18:12:01 -0500 To: Cullen Jennings X-Mailer: Apple Mail (2.746.3) X-Spam-Score: -2.6 (--) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: "sip@ietf.org" , "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 Apr 10, 2006, at 5:12 PM, Cullen Jennings wrote: > > I don't think that any of the current SIP RFCs requires a proxy to > have a > DNS entry if it only sends requests. Personally I'm not sure I see > the big > deal in giving them a DNS entry because I am suspicious that there > won't be > many cases where "outbound only" is possible but I'm not seeing any > reason > that we do need to make them have a DNS entry either. I believe that according to this terminology, the IMS P-CSCF is "outbound only". It is not listed as the responsible proxy for an AOR in the DNS, as those records point at I-CSCF. But I suspect that buried somewhere in this discussion thread is a failure to conceptualize the distinction between a proxy serving users of a domain and a proxy serving to relay between domains. This probably relates to the "guess my registrar from my AOR" problem that Juha has raised, too. In what I think of as "typical" cases, the proxy that my phone routes everything through (my "outbound proxy") is not what I would see if I did an DNS lookup on the domain of my AOR -- ESPECIALLY if that lookup occurs in the "public" DNS rather than a local stub. For example, take my "atypical" house as of earlier this year (ok, late last year). I had a proxy at sip.softarmor.com with an A record of 206.176.144.210 (can't use SRV, idiot DNS hoster doesn't do it), supporting AOR sip:dwillis@sip.softarmor.com But since my phone had an IP address of 192.168.2.100, it used a proxy at 192.168.2.2 (the proxy was dual-homed). I either didn't have a DNS record for this proxy interface, or if I did, it was in an internally-visible stub domain and had some bogus name on it. I configured this default proxy address into my SIP clients manually, but could have used a DHCP option (were it actually supported) to have done the same thing. -- 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 Apr 11 02:22:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTCEN-0005En-1t; Tue, 11 Apr 2006 02:20:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTCEK-0005Ed-2c for sip@ietf.org; Tue, 11 Apr 2006 02:20:00 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTCEC-0002U3-Ev for sip@ietf.org; Tue, 11 Apr 2006 02:20:00 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 513CDD43; Tue, 11 Apr 2006 08:19:51 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 08:19:48 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 08:19:48 +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] WGLC for draft-ietf-sip-fork-loop-fix-01.txt Date: Tue, 11 Apr 2006 08:19:48 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1D0F@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt Thread-Index: AcZc25ajL+FWBr6ZS76iURmQ6F0KkAAUrjXQ From: "Christer Holmberg \(JO/LMF\)" To: "Dean Willis" , X-OriginalArrivalTime: 11 Apr 2006 06:19:48.0622 (UTC) FILETIME=[EF4C02E0:01C65D2F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Robert Sparks , 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 Hi, I don't have any technical comments, but just to make sure I haven't missed anything: the only thing this document does is changing, when a proxy forks, a SHOULD in 3261 to a MUST? If so, maybe it could be mentioned in the introduction. And, a extremely minor editorial comment: "The requirement to use the loop-detection algorithm in RFC 3261 is set at should-strength since it is expected that other mechanisms that will allow a proxy to determine it is not looping will be standardized in the near future." If 3261 was published 4 years ago - what does "near future" means in IETF terms? :)=20 Seriously, does the document really need to "explain" why things were done in this-or-that way in 3261? Let's just describe the problem (as the draft does) and fix it... Regards, Christer -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: 10. huhtikuuta 2006 23:16 To: sip@ietf.org Cc: Robert Sparks; Keith Drage Subject: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt I'd like to ask the working group to review the "forking loop fix" =20 draft preparatory to requesting publication of it as a standards- track RFC. The document revised following the Dallas meeting document is =20 available from: http://www.ietf.org/internet-drafts/draft-ietf-sip-fork-loop-fix-01.txt I'd like to complete this review by May 7, 2006. Please send all comments to the list and copy the author, =20 rjs@estacado.net -- 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 Tue Apr 11 05:18:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTEz0-0006Jx-Iv; Tue, 11 Apr 2006 05:16:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTEyy-0006Jn-DC for sip@ietf.org; Tue, 11 Apr 2006 05:16:20 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTEyx-0000Ue-29 for sip@ietf.org; Tue, 11 Apr 2006 05:16:20 -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 k3B9GHut019969; Tue, 11 Apr 2006 04:16:17 -0500 (CDT) Received: from [135.104.50.100] (dhcp50100.cs.bell-labs.com [135.104.50.100]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k3B9GGk19697; Tue, 11 Apr 2006 04:16:16 -0500 (CDT) Message-ID: <443B74AF.90507@bell-labs.com> Date: Tue, 11 Apr 2006 04:19:43 -0500 From: Alan Jeffrey User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051019) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] SIP/TLS (1): Domain certificates in SIP References: <33C7D45A-4A39-422C-894F-34AD67022023@softarmor.com> In-Reply-To: <33C7D45A-4A39-422C-894F-34AD67022023@softarmor.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: Cullen Jennings , "sip@ietf.org" , "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: , Content-Type: multipart/mixed; boundary="===============1829551511==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1829551511== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090703020102070607010507" This is a cryptographically signed message in MIME format. --------------ms090703020102070607010507 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Ah, you spotted my not-very-well-hidden IMS scenario :-) Indeed, one place where outbound proxy != inbound proxy is IMS, which distinguishes between the I-CSCF (which deals with all incoming requests) and the S-CSCF (which actually processes requests, and forwards them to other proxies if necessary). The IMS picture is even trickier, in that in roaming mode the P-CSCF is under administrative control of a different network. Of all these SIP proxies, only the I-CSCF would have a DNS entry of example.com, the others would be proxyN.example.com (or proxyN.visited.com for the P-CSCF), but they should all be considered as speaking authoritatively for example.com (or visited.com for the P-CSCF). Alan. Dean Willis wrote: > > On Apr 10, 2006, at 5:12 PM, Cullen Jennings wrote: > >> >> I don't think that any of the current SIP RFCs requires a proxy to >> have a >> DNS entry if it only sends requests. Personally I'm not sure I see >> the big >> deal in giving them a DNS entry because I am suspicious that there >> won't be >> many cases where "outbound only" is possible but I'm not seeing any >> reason >> that we do need to make them have a DNS entry either. > > > I believe that according to this terminology, the IMS P-CSCF is > "outbound only". It is not listed as the responsible proxy for an AOR > in the DNS, as those records point at I-CSCF. > > But I suspect that buried somewhere in this discussion thread is a > failure to conceptualize the distinction between a proxy serving users > of a domain and a proxy serving to relay between domains. > > This probably relates to the "guess my registrar from my AOR" problem > that Juha has raised, too. > > > In what I think of as "typical" cases, the proxy that my phone routes > everything through (my "outbound proxy") is not what I would see if I > did an DNS lookup on the domain of my AOR -- ESPECIALLY if that lookup > occurs in the "public" DNS rather than a local stub. > > For example, take my "atypical" house as of earlier this year (ok, late > last year). > > I had a proxy at sip.softarmor.com with an A record of 206.176.144.210 > (can't use SRV, idiot DNS hoster doesn't do it), supporting AOR > sip:dwillis@sip.softarmor.com > > But since my phone had an IP address of 192.168.2.100, it used a proxy > at 192.168.2.2 (the proxy was dual-homed). I either didn't have a DNS > record for this proxy interface, or if I did, it was in an > internally-visible stub domain and had some bogus name on it. > > I configured this default proxy address into my SIP clients manually, > but could have used a DHCP option (were it actually supported) to have > done the same thing. > > -- > Dean > > -- Alan Jeffrey +1 630 224 0175 Bell Labs, Lucent Technologies http://cm.bell-labs.com/who/ajeffrey/ --------------ms090703020102070607010507 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJZzCC Aw4wggJ3oAMCAQICAw+fEDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUxMDEwMDE0NzM2WhcNMDYxMDEwMDE0NzM2 WjB9MRAwDgYDVQQEEwdKZWZmcmV5MRwwGgYDVQQqExNBbGFuIFN0ZXdhcnQgQXVzdGluMSQw IgYDVQQDExtBbGFuIFN0ZXdhcnQgQXVzdGluIEplZmZyZXkxJTAjBgkqhkiG9w0BCQEWFmFq ZWZmcmV5QGJlbGwtbGFicy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDw 5Cul6gbCRPip8crm2iiMo6nYik6LiQLaF6gjTkhh0qs0ez2KtdxKmswHiuf7yZISvmvAGfqv GMsWrQejVvV7DlL2Tn2XL68FuFv6Sco6+mnM7tcRt5zjXpEyLwPzn1OFfoHW0CWxeM/LMrEN 7BIhUhzz4ZnFCYf0t1ws+sZH5YEwa2dvKRsxe9ThA1VwL9pWbfJxqtK2ETw7myV4/SdOJP68 Y0mAdXNw+LjmSCetvYxcg9K8YLGjpjloUeamGYU9v3LXznKUrXWaagU13XYYqOjt0Nv0awwJ 7Gn5fKTNEhLIfmA7w0CbrOzH+qhxQPNOJLbeQx9H/ySTHMFy3dLnAgMBAAGjMzAxMCEGA1Ud EQQaMBiBFmFqZWZmcmV5QGJlbGwtbGFicy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0B AQQFAAOBgQATaJTPOE4MEgjz7MOKXa7HsDzy/HyG29dlufCT/rQRvslmd3iibxAI5B1/vKik hhgSy41MWfIb/thRzvdN2qX4diPDuXCUW1wpsOeh9QU0qwvCda8311iIljiRqs7VKEN9bVRx yCAzL3REtosiDHKfc+CzagJAuDfJgTbel6LIaTCCAw4wggJ3oAMCAQICAw+fEDANBgkqhkiG 9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0 eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0Ew HhcNMDUxMDEwMDE0NzM2WhcNMDYxMDEwMDE0NzM2WjB9MRAwDgYDVQQEEwdKZWZmcmV5MRww GgYDVQQqExNBbGFuIFN0ZXdhcnQgQXVzdGluMSQwIgYDVQQDExtBbGFuIFN0ZXdhcnQgQXVz dGluIEplZmZyZXkxJTAjBgkqhkiG9w0BCQEWFmFqZWZmcmV5QGJlbGwtbGFicy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDw5Cul6gbCRPip8crm2iiMo6nYik6LiQLa F6gjTkhh0qs0ez2KtdxKmswHiuf7yZISvmvAGfqvGMsWrQejVvV7DlL2Tn2XL68FuFv6Sco6 +mnM7tcRt5zjXpEyLwPzn1OFfoHW0CWxeM/LMrEN7BIhUhzz4ZnFCYf0t1ws+sZH5YEwa2dv KRsxe9ThA1VwL9pWbfJxqtK2ETw7myV4/SdOJP68Y0mAdXNw+LjmSCetvYxcg9K8YLGjpjlo UeamGYU9v3LXznKUrXWaagU13XYYqOjt0Nv0awwJ7Gn5fKTNEhLIfmA7w0CbrOzH+qhxQPNO JLbeQx9H/ySTHMFy3dLnAgMBAAGjMzAxMCEGA1UdEQQaMBiBFmFqZWZmcmV5QGJlbGwtbGFi cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQATaJTPOE4MEgjz7MOKXa7H sDzy/HyG29dlufCT/rQRvslmd3iibxAI5B1/vKikhhgSy41MWfIb/thRzvdN2qX4diPDuXCU W1wpsOeh9QU0qwvCda8311iIljiRqs7VKEN9bVRxyCAzL3REtosiDHKfc+CzagJAuDfJgTbe l6LIaTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhh d3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me 7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQq E88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEA AaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9j cmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcN AQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNw PP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq72 6jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggM7MIIDNwIBATBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDD58QMAkGBSsOAwIaBQCgggGn MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA2MDQxMTA5MTk0 M1owIwYJKoZIhvcNAQkEMRYEFJar+mAZDsPcqpmXqWzJb7wSUBOBMFIGCSqGSIb3DQEJDzFF MEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPnxAwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDD58QMA0GCSqGSIb3 DQEBAQUABIIBAFNWs5VKhpdVw5fW8HBVIDQFB9vJ5UXMqYdOWZVUAAkxIErJJzfbnjzonJpg s/4/zmML7fj4c1oMG7E8tIisdxZe1g6ODGpI/TlqRM+vYVWgjNj+P6AmWs+jRujbtQ842yqr Ng7MGGja66vvt2MT3rLTaJj8TzYaosd6d9oqgzmweA3z0RlJF1fqr4mkZ2nQttPa2gBGdaAI OUJdLE7feb7Fs+87Nf6TyNOPLXdlnxusQYCdS9hBGgoL04IDxSjQ1ml7HO8lL3vYVun8hE7K TCaHt76o8cEakXNO0MJ8hm6wQW3ZsQocmIJQ8eEOo57TWAuhMuStvCOwIQ6YfiWOZI8AAAAA AAA= --------------ms090703020102070607010507-- --===============1829551511== 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 --===============1829551511==-- From sip-bounces@ietf.org Tue Apr 11 05:22:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTF2t-0006qH-Ov; Tue, 11 Apr 2006 05:20:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTF2r-0006qC-Uo for sip@ietf.org; Tue, 11 Apr 2006 05:20:21 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTF2r-0000oH-BL for sip@ietf.org; Tue, 11 Apr 2006 05:20:21 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k3B9KJQb013364; Tue, 11 Apr 2006 11:20:20 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k3B9KG9H030503; Tue, 11 Apr 2006 11:20:18 +0200 Received: from MCHP7I5A.ww002.siemens.net ([139.25.131.136]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 11:20: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: AW: WG: [Sip] Last Call: 'Suppression of Session Initiation Protocol REFER Method Implicit Subscription' to Proposed Standard Date: Tue, 11 Apr 2006 11:20:15 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG: [Sip] Last Call: 'Suppression of Session Initiation Protocol REFER Method Implicit Subscription' to Proposed Standard Thread-Index: AcZZoR31zAdOtVFIRAqGfeiKnlaRZADpr13A From: "Tan, Ya-Ching" To: "Dean Willis" X-OriginalArrivalTime: 11 Apr 2006 09:20:17.0090 (UTC) FILETIME=[25911A20:01C65D49] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: sip ietf , oritl@microsoft.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 Just noticed that the draft also failed to register the header field = parameter according to processes of RFC 3968. Ya Ching -----Urspr=FCngliche Nachricht----- Von: Dean Willis [mailto:dean.willis@softarmor.com]=20 Gesendet: Donnerstag, 6. April 2006 19:40 An: Tan, Ya-Ching Betreff: Re: WG: [Sip] Last Call: 'Suppression of Session Initiation = Protocol REFER Method Implicit Subscription' to Proposed Standard=20 Yes, very late -- the draft is already in the RFC Editor queue. I'll =20 see if the ADs will support fixing with an Instruction to the RFC =20 Editor. Thanks! -- Dean > > -----Urspr=FCngliche Nachricht----- > Von: Tan, Ya-Ching > Gesendet: Donnerstag, 6. April 2006 18:03 > An: 'oritl@microsoft.com'; 'iesg@ietf.org' > Betreff: WG: [Sip] Last Call: 'Suppression of Session Initiation =20 > Protocol REFER Method Implicit Subscription' to Proposed Standard > > Some very late comments : > > Section 9 : > "Should an intermediary maliciously insert a "Refer-Sub" header =20 > field > set to "false", two possibilities may occur. If the REFER-=20 > Recipient > does not support the extension, the REFER will fail with a "420 Bad > Extension" response. The REFER-Issuer will be confused as no =20 > "Refer- > Sub" was in the request, and the resulting request will fail." > > Here we are talking about an unknown header. There is no reason for =20 > a recipient of an unknown header to send a 420 response. Unknown =20 > headers are normally just discarded. > > And the last sentence of the same paragraph : > > "As a result the REFER-Recipient will not learn the outcome of the > operation on the Refer-To URI." > > It should be the "REFER-Issuer" instead. > > > > -----Urspr=FCngliche Nachricht----- > Von: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] Im Auftrag =20 > von The IESG > Gesendet: Freitag, 3. Februar 2006 15:49 > An: IETF-Announce > Cc: sip@ietf.org > Betreff: [Sip] Last Call: 'Suppression of Session Initiation =20 > Protocol REFER Method Implicit Subscription' to Proposed Standard > > The IESG has received a request from the Session Initiation =20 > Protocol WG to > consider the following document: > > - 'Suppression of Session Initiation Protocol REFER Method Implicit > Subscription ' > as a Proposed =20 > Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2006-02-17. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-with-=20 > norefersub-04.txt > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 11 05:45:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTFPi-0000g9-8R; Tue, 11 Apr 2006 05:43:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTFPg-0000fz-Pg for sip@ietf.org; Tue, 11 Apr 2006 05:43:56 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTFPg-0001ae-8z for sip@ietf.org; Tue, 11 Apr 2006 05:43:56 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k3B9htHQ010099; Tue, 11 Apr 2006 11:43:55 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k3B9hsl3020929; Tue, 11 Apr 2006 11:43:54 +0200 Received: from MCHP7I5A.ww002.siemens.net ([139.25.131.136]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 11:43: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: AW: WG: [Sip] Last Call: 'Suppression of Session Initiation ProtocolREFER Method Implicit Subscription' to Proposed Standard Date: Tue, 11 Apr 2006 11:43:51 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG: [Sip] Last Call: 'Suppression of Session Initiation ProtocolREFER Method Implicit Subscription' to Proposed Standard Thread-Index: AcZZoR31zAdOtVFIRAqGfeiKnlaRZADpr13AAAESOsA= From: "Tan, Ya-Ching" To: "Dean Willis" X-OriginalArrivalTime: 11 Apr 2006 09:43:54.0745 (UTC) FILETIME=[728E1690:01C65D4C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: sip ietf , oritl@microsoft.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 Please igonore the previous mail. I realized that the Refer-Sub header = has no parameter.=20 Ya Ching -----Urspr=FCngliche Nachricht----- Von: Tan, Ya-Ching=20 Gesendet: Dienstag, 11. April 2006 11:20 An: Dean Willis Cc: sip ietf; oritl@microsoft.com Betreff: AW: WG: [Sip] Last Call: 'Suppression of Session Initiation = ProtocolREFER Method Implicit Subscription' to Proposed Standard=20 Just noticed that the draft also failed to register the header field = parameter according to processes of RFC 3968. Ya Ching -----Urspr=FCngliche Nachricht----- Von: Dean Willis [mailto:dean.willis@softarmor.com]=20 Gesendet: Donnerstag, 6. April 2006 19:40 An: Tan, Ya-Ching Betreff: Re: WG: [Sip] Last Call: 'Suppression of Session Initiation = Protocol REFER Method Implicit Subscription' to Proposed Standard=20 Yes, very late -- the draft is already in the RFC Editor queue. I'll =20 see if the ADs will support fixing with an Instruction to the RFC =20 Editor. Thanks! -- Dean > > -----Urspr=FCngliche Nachricht----- > Von: Tan, Ya-Ching > Gesendet: Donnerstag, 6. April 2006 18:03 > An: 'oritl@microsoft.com'; 'iesg@ietf.org' > Betreff: WG: [Sip] Last Call: 'Suppression of Session Initiation =20 > Protocol REFER Method Implicit Subscription' to Proposed Standard > > Some very late comments : > > Section 9 : > "Should an intermediary maliciously insert a "Refer-Sub" header =20 > field > set to "false", two possibilities may occur. If the REFER-=20 > Recipient > does not support the extension, the REFER will fail with a "420 Bad > Extension" response. The REFER-Issuer will be confused as no =20 > "Refer- > Sub" was in the request, and the resulting request will fail." > > Here we are talking about an unknown header. There is no reason for =20 > a recipient of an unknown header to send a 420 response. Unknown =20 > headers are normally just discarded. > > And the last sentence of the same paragraph : > > "As a result the REFER-Recipient will not learn the outcome of the > operation on the Refer-To URI." > > It should be the "REFER-Issuer" instead. > > > > -----Urspr=FCngliche Nachricht----- > Von: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] Im Auftrag =20 > von The IESG > Gesendet: Freitag, 3. Februar 2006 15:49 > An: IETF-Announce > Cc: sip@ietf.org > Betreff: [Sip] Last Call: 'Suppression of Session Initiation =20 > Protocol REFER Method Implicit Subscription' to Proposed Standard > > The IESG has received a request from the Session Initiation =20 > Protocol WG to > consider the following document: > > - 'Suppression of Session Initiation Protocol REFER Method Implicit > Subscription ' > as a Proposed =20 > Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2006-02-17. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-with-=20 > norefersub-04.txt > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 11 06:55:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTGV0-0000zO-Av; Tue, 11 Apr 2006 06:53:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTGUz-0000zJ-MW for sip@ietf.org; Tue, 11 Apr 2006 06:53:29 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTGUx-000435-Tp for sip@ietf.org; Tue, 11 Apr 2006 06:53:29 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 52F974F002F; Tue, 11 Apr 2006 12:53:27 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 12:53:27 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 12:53:26 +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] WGLC for draft-ietf-sip-fork-loop-fix-01.txt Date: Tue, 11 Apr 2006 12:53:26 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1D16@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt Thread-Index: AcZdM6FeOftJAD2bSrGjdii51XkBSQAIT26A From: "Christer Holmberg \(JO/LMF\)" To: "Robert Sparks" X-OriginalArrivalTime: 11 Apr 2006 10:53:26.0794 (UTC) FILETIME=[294A3EA0:01C65D56] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: sip@ietf.org, Robert Sparks , 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 Hi,=20 >>Seriously, does the document really need to "explain" why things were >>done in this-or-that way in 3261? Let's just describe the problem (as >>the draft does) and fix it... >Are you referring to the paragraph you quote above? It doesn't explain >why things are in 3261 - it explains why the SHOULD in _this_ draft >is a SHOULD and not a MUST. Ok, my misstake. I thought you were referring to text in 3261. But still, is it a good idea to talk about what will happen in the "near future" in a standards document? Isn't it simply enough to keep the "MUST ensure that request is not looping through this proxy." statement? The proxy can then use whatever mechanism to acheive that.=20 Because, if we now make the 3261 way a SHOULD, it may in future be too "strong" due to other mechanisms (outbound etc) proxies may end up using. The 3261 mechanism can be listed as the "default mechanism". Regards. Christer > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 10. huhtikuuta 2006 23:16 > To: sip@ietf.org > Cc: Robert Sparks; Keith Drage > Subject: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt > > > I'd like to ask the working group to review the "forking loop fix" > draft preparatory to requesting publication of it as a standards- =20 > track > RFC. > > > The document revised following the Dallas meeting document is > available from: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-fork-loop-=20 > fix-01.txt > > > > I'd like to complete this review by May 7, 2006. > > Please send all comments to the list and copy the author, > rjs@estacado.net > > -- > 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 Tue Apr 11 09:12:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTIda-0008F2-G8; Tue, 11 Apr 2006 09:10:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTIdZ-0008Ex-6b for sip@ietf.org; Tue, 11 Apr 2006 09:10:29 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTIdX-0000yf-Hd for sip@ietf.org; Tue, 11 Apr 2006 09:10:29 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 11 Apr 2006 06:10:27 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,112,1144047600"; d="scan'208"; a="25635954:sNHT31449008" 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 k3BDAQWc012591; Tue, 11 Apr 2006 09:10:26 -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, 11 Apr 2006 09:10:26 -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, 11 Apr 2006 09:10:26 -0400 Message-ID: <443BAAC1.6080800@cisco.com> Date: Tue, 11 Apr 2006 09:10:25 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Jeffrey Subject: Re: [Sip] SIP/TLS (1): Domain certificates in SIP References: <33C7D45A-4A39-422C-894F-34AD67022023@softarmor.com> <443B74AF.90507@bell-labs.com> In-Reply-To: <443B74AF.90507@bell-labs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Apr 2006 13:10:26.0291 (UTC) FILETIME=[4C7DF430:01C65D69] X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: Cullen Jennings , "sip@ietf.org" , "Vijay K. Gurbani" , 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 Alan Jeffrey wrote: > Ah, you spotted my not-very-well-hidden IMS scenario :-) > > Indeed, one place where outbound proxy != inbound proxy is IMS, which > distinguishes between the I-CSCF (which deals with all incoming > requests) and the S-CSCF (which actually processes requests, and > forwards them to other proxies if necessary). The IMS picture is even > trickier, in that in roaming mode the P-CSCF is under administrative > control of a different network. > > Of all these SIP proxies, only the I-CSCF would have a DNS entry of > example.com, the others would be proxyN.example.com (or > proxyN.visited.com for the P-CSCF), but they should all be considered as > speaking authoritatively for example.com (or visited.com for the P-CSCF). Considered as speaking authoritatively in what sense? IMS uses P-Asserted-Identity rather than certs for identity, and has its own rules for what elements are trusted to insert it. That is outside the scope of this discussion. IMS also doesn't (yet, AFAIK) specify how to use TLS. So we have to read the tea leaves to figure out how it should do that. The place it would be most applicable to this discussion is between the UA and the P-CSCF. The UA has its own process for discovering the P-CSCF. The cert the P-CSCF uses needs to be consistent with this process, but that doesn't necessarily require each P-CSCF proxyN.example.com to have a cert for example.com. Then the P-CSCF needs to make a connection to an I-CSCF when registering. If that is to be done via TLS then the I-CSCF probably does need a cert for the example.com domain, since all the P-CSCF has to go on the the public user id being registered. All the interconnections of proxies within the domain are a private matter. Paul > Alan. > > Dean Willis wrote: > >> >> On Apr 10, 2006, at 5:12 PM, Cullen Jennings wrote: >> >>> >>> I don't think that any of the current SIP RFCs requires a proxy to >>> have a >>> DNS entry if it only sends requests. Personally I'm not sure I see >>> the big >>> deal in giving them a DNS entry because I am suspicious that there >>> won't be >>> many cases where "outbound only" is possible but I'm not seeing any >>> reason >>> that we do need to make them have a DNS entry either. >> >> >> >> I believe that according to this terminology, the IMS P-CSCF is >> "outbound only". It is not listed as the responsible proxy for an AOR >> in the DNS, as those records point at I-CSCF. >> >> But I suspect that buried somewhere in this discussion thread is a >> failure to conceptualize the distinction between a proxy serving >> users of a domain and a proxy serving to relay between domains. >> >> This probably relates to the "guess my registrar from my AOR" problem >> that Juha has raised, too. >> >> >> In what I think of as "typical" cases, the proxy that my phone routes >> everything through (my "outbound proxy") is not what I would see if I >> did an DNS lookup on the domain of my AOR -- ESPECIALLY if that >> lookup occurs in the "public" DNS rather than a local stub. >> >> For example, take my "atypical" house as of earlier this year (ok, >> late last year). >> >> I had a proxy at sip.softarmor.com with an A record of >> 206.176.144.210 (can't use SRV, idiot DNS hoster doesn't do it), >> supporting AOR sip:dwillis@sip.softarmor.com >> >> But since my phone had an IP address of 192.168.2.100, it used a >> proxy at 192.168.2.2 (the proxy was dual-homed). I either didn't have >> a DNS record for this proxy interface, or if I did, it was in an >> internally-visible stub domain and had some bogus name on it. >> >> I configured this default proxy address into my SIP clients manually, >> but could have used a DHCP option (were it actually supported) to >> have done the same thing. >> >> -- >> 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 Tue Apr 11 11:19:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTKcA-00087t-6J; Tue, 11 Apr 2006 11:17:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTKc8-00087o-Po for sip@ietf.org; Tue, 11 Apr 2006 11:17:08 -0400 Received: from sitemail2.everyone.net ([216.200.145.36] helo=omta16.mta.everyone.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTKc6-0005mv-5S for sip@ietf.org; Tue, 11 Apr 2006 11:17:08 -0400 Received: from dm17.mta.everyone.net (bigiplb-dsnat [172.16.0.19]) by omta16.mta.everyone.net (Postfix) with ESMTP id 66D86403BA; Tue, 11 Apr 2006 08:17:05 -0700 (PDT) X-Eon-Dm: dm17 Received: by dm17.mta.everyone.net (EON-AUTHRELAY2[SSL] - cf31a202) id dm17.44347f8d.baf10; Tue, 11 Apr 2006 08:17:04 -0700 (PDT) X-Eon-Sig: AQIH5JVEO8hwXA+T4gIAAAAC,ced058e7d99963aa20a0b8bb4cf2c214 From: "Bala Neelakantan" To: "'Mahesh Govind'" , Subject: RE: [Sip] offer answer Date: Tue, 11 Apr 2006 10:19:43 -0500 Message-ID: <001101c65d7b$5cca9a20$7502a8c0@NeelLT> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <7f5ac7240604100707o7439e8dcn2ef2facfe3bfa5ad@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: balasubramanian_neelakantan@quintum.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1924470244==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1924470244== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C65D51.73F49220" This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C65D51.73F49220 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See Section 6.1, page 10. =20 The stream MAY indicate additional media formats, not listed in the corresponding stream in the offer, that the answerer is willing to send or receive (of course, it will not be able to send them at this time, since it was not listed in the offer). For streams marked as =20 So, the answer can have additional media formats in the media line.. =20 Thanks, Neel =20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Mahesh Govind Sent: Monday, April 10, 2006 9:08 AM To: sip@ietf.org Subject: [Sip] offer answer =20 HI, =20 I have a doubt . =20 If an offer is having a media line=20 m=3Daudio 4000 RTP/AVP 1 2 3 =20 can an answer contain , =20 If an offer is having a media line=20 m=3Daudio 4000 RTP/AVP 1 2 3 5 =20 With thanks and regards Mahesh =20 ------=_NextPart_000_0012_01C65D51.73F49220 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

See Section 6.1, page = 10.

 

  The stream MAY indicate additional =
media formats, not listed in the
   corresponding stream in the =
offer, that the answerer is willing to
   send or receive (of course, it =
will not be able to send them at this
   time, since it was not listed in =
the offer).  For streams marked as

  

So, the answer can have additional media formats in the media = line..

 

Thanks,

Neel

 

-----Original = Message-----
From: = sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On = Behalf Of Mahesh Govind
Sent: Monday, April 10, = 2006 9:08 AM
To: sip@ietf.org
Subject: [Sip] offer = answer

 

HI,

 

I have a doubt .

 

If  an offer is having  a media = line

m=3Daudio 4000 RTP/AVP 1 2 = 3

 

can an answer  contain = ,

 

If  an offer is having  a media = line

m=3Daudio 4000 RTP/AVP 1 2 3 = 5

 

With thanks and regards

Mahesh

 

------=_NextPart_000_0012_01C65D51.73F49220-- --===============1924470244== 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 --===============1924470244==-- From sip-bounces@ietf.org Tue Apr 11 15:24:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTORO-0001oA-LF; Tue, 11 Apr 2006 15:22:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTORN-0001o5-7p for sip@ietf.org; Tue, 11 Apr 2006 15:22:17 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTORL-0006Ud-Vt for sip@ietf.org; Tue, 11 Apr 2006 15:22:17 -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 k3BJMEXC017509; Tue, 11 Apr 2006 14:22:14 -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 k3BJMAk26472; Tue, 11 Apr 2006 14:22:10 -0500 (CDT) Message-ID: <443C01E2.7080705@lucent.com> Date: Tue, 11 Apr 2006 14:22:10 -0500 From: "Vijay K. Gurbani" 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] SIP/TLS (1): Domain certificates in SIP References: <33C7D45A-4A39-422C-894F-34AD67022023@softarmor.com> <443B74AF.90507@bell-labs.com> <443BAAC1.6080800@cisco.com> In-Reply-To: <443BAAC1.6080800@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: SIP LIST X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: > Alan Jeffrey wrote: [...] >> Of all these SIP proxies, only the I-CSCF would have a DNS entry of >> example.com, the others would be proxyN.example.com (or >> proxyN.visited.com for the P-CSCF), but they should all be >> considered as speaking authoritatively for example.com (or >> visited.com for the P-CSCF). > > Considered as speaking authoritatively in what sense? > > IMS uses P-Asserted-Identity rather than certs for identity, and has > its own rules for what elements are trusted to insert it. That is > outside the scope of this discussion. I don't think the distinction being drawn here is P-A-I vs. certs. While a SIP AoR in a cert binds that cert to a specific user, TLS certs are not specific to a user, but a host representing the domain (the inbound proxy, for instance). Cullen's earlier email sheds some light in that when a user wants to talk to a URI of sip:me@example.com, then the inbound proxy (example.com) presenting a cert with a SAN of "sip:example.com" suffices. Now what if the inbound proxy wants to mutually authenticate the outbound proxy (visited.com) from which the request was sent? To do so, it asks for a cert from the outbound proxy. What should be the identity in the cert presented by the outbound proxy? And how is that identity correlated to the SIP vectors? The From header is no help due to retargetting. The only header that correlates the identity of the the outbound proxy to the cert is the sent-by production in the topmost Via. And that will most probably be in the form of proxyN.visited.com. BTW, I would agree with Dean's assessment: > But I suspect that buried somewhere in this discussion thread is a > failure to conceptualize the distinction between a proxy serving > users of a domain and a proxy serving to relay between domains. Thanks, - 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 Tue Apr 11 16:14:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTPDo-0006S7-8s; Tue, 11 Apr 2006 16:12:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTPDm-0006QV-8T for sip@ietf.org; Tue, 11 Apr 2006 16:12:18 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTPDl-000162-TT for sip@ietf.org; Tue, 11 Apr 2006 16:12:18 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 11 Apr 2006 13:12:04 -0700 X-IronPort-AV: i="4.04,112,1144047600"; d="scan'208"; a="1793966542:sNHT2044391814" 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 k3BKC3Yg006056; Tue, 11 Apr 2006 13:12:03 -0700 (PDT) Received: from 10.21.145.65 ([10.21.145.65]) by vtg-um-e2k2.sj21ad.cisco.com ([171.70.93.54]) with Microsoft Exchange Server HTTP-DAV ; Tue, 11 Apr 2006 20:12:03 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Tue, 11 Apr 2006 12:11:25 -0700 Subject: Re: [Sip] SIP/TLS (1): Domain certificates in SIP From: Cullen Jennings To: Alan Jeffrey , Dean Willis Message-ID: Thread-Topic: [Sip] SIP/TLS (1): Domain certificates in SIP Thread-Index: AcZdm7oW+L0MaMmOEdqN7gARJEEJ/A== In-Reply-To: <443B74AF.90507@bell-labs.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: "sip@ietf.org" , "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 Ok, I think we all agree that could be proxies that were authorities for example.com that the SIP DNS resolution for example.com would never end up resolving to that proxy. (Note I don't think this is the same as the proxy never sends a request). But given we agree on this, I'm actually lost on where this thread was going :-) On 4/11/06 2:19 AM, "Alan Jeffrey" wrote: > Ah, you spotted my not-very-well-hidden IMS scenario :-) > > Indeed, one place where outbound proxy != inbound proxy is IMS, which > distinguishes between the I-CSCF (which deals with all incoming > requests) and the S-CSCF (which actually processes requests, and > forwards them to other proxies if necessary). The IMS picture is even > trickier, in that in roaming mode the P-CSCF is under administrative > control of a different network. > > Of all these SIP proxies, only the I-CSCF would have a DNS entry of > example.com, the others would be proxyN.example.com (or > proxyN.visited.com for the P-CSCF), but they should all be considered as > speaking authoritatively for example.com (or visited.com for the P-CSCF). > > Alan. > > Dean Willis wrote: >> >> On Apr 10, 2006, at 5:12 PM, Cullen Jennings wrote: >> >>> >>> I don't think that any of the current SIP RFCs requires a proxy to >>> have a >>> DNS entry if it only sends requests. Personally I'm not sure I see >>> the big >>> deal in giving them a DNS entry because I am suspicious that there >>> won't be >>> many cases where "outbound only" is possible but I'm not seeing any >>> reason >>> that we do need to make them have a DNS entry either. >> >> >> I believe that according to this terminology, the IMS P-CSCF is >> "outbound only". It is not listed as the responsible proxy for an AOR >> in the DNS, as those records point at I-CSCF. >> >> But I suspect that buried somewhere in this discussion thread is a >> failure to conceptualize the distinction between a proxy serving users >> of a domain and a proxy serving to relay between domains. >> >> This probably relates to the "guess my registrar from my AOR" problem >> that Juha has raised, too. >> >> >> In what I think of as "typical" cases, the proxy that my phone routes >> everything through (my "outbound proxy") is not what I would see if I >> did an DNS lookup on the domain of my AOR -- ESPECIALLY if that lookup >> occurs in the "public" DNS rather than a local stub. >> >> For example, take my "atypical" house as of earlier this year (ok, late >> last year). >> >> I had a proxy at sip.softarmor.com with an A record of 206.176.144.210 >> (can't use SRV, idiot DNS hoster doesn't do it), supporting AOR >> sip:dwillis@sip.softarmor.com >> >> But since my phone had an IP address of 192.168.2.100, it used a proxy >> at 192.168.2.2 (the proxy was dual-homed). I either didn't have a DNS >> record for this proxy interface, or if I did, it was in an >> internally-visible stub domain and had some bogus name on it. >> >> I configured this default proxy address into my SIP clients manually, >> but could have used a DHCP option (were it actually supported) to have >> done the same thing. >> >> -- >> 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 Apr 11 16:32:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTPVW-0007eK-0t; Tue, 11 Apr 2006 16:30:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTPVU-0007eF-HQ for sip@ietf.org; Tue, 11 Apr 2006 16:30:36 -0400 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTPVU-0001eL-1l for sip@ietf.org; Tue, 11 Apr 2006 16:30:36 -0400 Received: from s73602 (unknown[65.104.224.98]) by comcast.net (sccrmhc11) with SMTP id <2006041120303501100ejc68e>; Tue, 11 Apr 2006 20:30:35 +0000 Message-ID: <08d101c65da6$73eb1ba0$0500a8c0@china.huawei.com> From: "Spencer Dawkins" To: Date: Tue, 11 Apr 2006 15:28:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 Subject: [Sip] My notes on draft-rosenberg-sip-hitchhikers-guide-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Jonathan, I've been through this draft, and had some comments that I wanted to pass along. Some of them may be relevant for WG discussion of the draft, so I'm posting to the list. I want to preface everything I type below with "thank you for putting this together". Spencer Abstract 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. Spencer: Just as a general thing - I love the Douglas Adams references, and agree with your suggestion from IETF 65 that you need more of them, but since (gasp!) there are people who may not have read them, there are a couple of places that I would suggest handling them differently - and this is one place. "Don't Panic!" appears in the abstract and in the Introduction, and I'd suggest removing it from the Abstract. (And "Hitchhiker's Guide" should be apostrophied, I think 1. Introduction The Session Initiation Protocol (SIP) [1] is the subject of numerous specifications that have been produced by the IETF. It can be Spencer: it seems fair to point out that, in addition to the (mostly) approved specifications that are described in this document, there are literally hundreds of proposals for SIP and extensions that are not included in this document because they are still being produced. difficult to locate the right document, or even to determine the set of Request for Comments (RFC) about SIP. Don't Panic! This Spencer: I don't have anything in my IETF 65 notes about adding the Douglas Adams book(s) as references, but thought I remembered this being mentioned, and I agree with adding it (for a couple of reasons). If you add the Douglas Adams book(s) as references, it would be helpful to use the reference to "tag" quotes and humorous references. "Don't Panic!" really doesn't need this in the Introduction, but there is at least one joke futher down that does (see comment below). And I believe I heard a suggestion to use reference [42] as the Douglas Adams reference number, at IETF 65, so the text would be "Don't Panic! [42]"... specification serves as a guide to the SIP RFC series. It lists the specifications under the SIP umbrella. For each specification, a paragraph or so description is included that summarizes the purpose of the specification. Each specification also includes a letter that Spencer: actually, there are a bunch of specifications that don't have an associated letter. If it's helpful, I could chase these down, but it looked like sending you diffs would be tedious for you to apply. We can talk. designates its category in the standards track [2]. These values are: S: Standards Track (Proposed Standard, Draft Standard, or Standard) E: Experimental B: Best Current Practice I: Informational The specifications are grouped together by topic. Typically, SIP extensions fit naturally into topic areas, and implementations interested in a particular topic often implement many or all of the specifications in that area. This document itself is not an update to RFC 3261 or an extension to SIP. It is an informational document, meant to guide newcomers and implementors to the SIP suite of specifications. Spencer: At this stage of the game, I'm assuming that deployers are as likely to find this document useful as implementors. Are they part of the target audience? I have a couple of notes further down that assume "yes". 2. Scope of this Document Spencer: this section should probably be split - part of it is about "scope of the document", and part of it defines "the other specifications that aren't SIP, but matter a lot". I'd suggest splitting it before the last line of the following paragraph. It is very difficult to enumerate the set of SIP specifications. This is because there are many protocols that are intimately related to SIP and used by nearly all SIP implementations, but are not formally SIP extensions. As such, this document formally defines a "SIP specification" as any specification that defines an extension to SIP itself, where an extension is a mechanism that changes or updates in some way a behavior specified in RFC 3261. This is in contrast to the "SIP family of specifications", which represent the set of specifications that define protocols that are integral parts of any SIP deployment, but are not SIP extensions per se. The SIP family of specifications includes the following specifications and their respective extensions: Spencer: It's definitely worth a section header that says "Related Specifications" above these documents. Spencer: it would be good to pick between "always mention the current specification first" and "always mention the historical specification first". There aren't many places where it's confusing, but the following paragraph confused me: RFC 3550: Real Time Transport Protocol (RTP) RTP [4] is the specification that started it all. It is the first in a long line of IETF specifications related to multimedia communications. Its initial version, RFC 1889 [3] was first specified in January of 1996. RTP is used to carry multimedia traffic, including voice, video and text, and is set up by SIP. There are countless extensions and payload formats (possibly as many as 42) defined for RTP. Spencer: Perhaps "RFC 3550: Real Time Transport Protocol (RTP) RTP [4] is the latest version of the specification that started it all - RFC 1889 [3], the first in a long line of IETF specifications related to multimedia communications, first specified in January 1996. RTP is used to carry multimedia traffic, including voice, video and text, and is set up by SIP. There are countless extensions and payload formats (possibly as many as 42) defined for RTP." Spencer: "possibly as many as 42" is funny, but I am more comfortable if you have adopted a reference to the Douglas Adams book(s), and have something like ("possibly as many as 42 [42])" in this paragraph. The current text is just a little too deadpan for people who aren't fluent in Vogon. RFC 3219: Telephony Routing over IP (TRIP) TRIP [15] defines a mechanism for exchanging SIP routes between administrative domains. Its derived from BGP. Spencer: s/Its/It's/, or s/Its/TRIP is/ Despite the importance of the SIP family of specifications, this Spencer: This seems slightly off - perhaps "Despite the importance of related specifications, ..." - aren't you saying that there is more to doing SIP than just doing what the SIP family of specifications describes? document concerns itself entirely with defining the set of specifications that make up SIP itself. Excluded from this list are requirements, architectures, registry definitions, non-normative frameworks, and processes. Best Current Practices are included when they are effectively standard mechanisms for accomplishing a task. Spencer: "effectively standard mechanisms" seems slightly off. Perhaps "when they normatively define mechanisms for accomplishing a task"? Also excluded are definitions of MIME objects that are used by SIP, such as the Authenticated Identity Body (AIB) [16] and various XML documents and extensions used by SIP. Though they are used by SIP, they are not extensions to SIP. [[OPEN ISSUE: Is this arbitrary? Maybe they should be included if they are specific to SIP.]] Spencer: You're the one who is doing the work, but if it's not too much work, I would like to see the MIME objects included - they are very important, and they are at least as obscure as other stuff you've included. The SIP change process [17] defines two types of extensions to SIP. These are normal extensions and the so-called P-headers, which are meant to be used in areas of limited applicability. P-headers cannot Spencer: probably spell out P-headers here? Not that we know what "P" stands for. Stealing text from RFC 3427: "... the so-called "preliminary", "private", or "proprietary" headers, or P-headers, which begin with "P-", and which are meant to be used in areas of limited applicability". be defined in the standards track. For the most part, P-headers are not included in the listing here, with the exception of those which have seen general usage despite their P-header status. 3. Core SIP Specifications RFC XXXX: Enhancements for Authenticated Identity Management in SIP (S) RFC XXXX [28] defines a mechanism for providing a cryptographically verifiable identity of the calling party in a SIP request. Also known as "SIP Identity", this mechanism provides an alternative to RFC 3325. It has seen little deployment so far, but its importance as a key construct for Spencer: NO idea what "almost also" is doing in this sentence, but assume that you meant to say something here. Just flagging for you. almost also anti-spam techniques makes it a core part of the SIP specifications. RFC XXXX: Managing Client Initiated Connections through SIP (S) RFC XXXX [30], also known as SIP outbound, defines important changes to the SIP registration mechanism which enable delivery of SIP messages towards a UA when it is behind a NAT. This specification is the cornerstone of the SIP NAT traversal strategy. Spencer: this is not news to you (of all people), but there are a lot of NAT traversal-related specifications - maybe enough to justify its own section? At the very least, having "the cornerstone" listed last seems less helpful... 5. General Purpose Infrastructure Extensions 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. Spencer: I know that draft-rosenberg-sip-info-harmful didn't advance (even though I wish it had), but am wondering if the guidance here could be stronger. Unless people really disagree with "However, since its initial usage for that purpose, INFO has seen widespread abuse as a means for introducing non-standard and non-interoperable extensions to SIP. For this reason, we now believe INFO should be considered harmful, and therefore, deprecated in its current form", maybe this text (from the draft) could be inserted here. RFC 3326: The Reason header field for SIP (S) RFC 3326 [40] defines the Reason header field. It is used in requests, such as BYE, to indicate the reason that the request is being sent. RFC 3840: Indicating User Agent Capabilities in SIP (S) RFC 3840 defines a mechanism for carrying capability information about a user agent in REGISTER requests and in dialog-forming requests like INVITE. It has found use with conferencing (the isfocus parameter declares that a user agent is a conference server) and with applications like push-to-talk. Spencer: is there a useful reference for "push-to-talk"? 10. Operations and Management Spencer: You have been pointing to specifications (this is good). I'm wondering if there are a couple of places (Operations and Emergency Services being two) where it is worth pointing to entire working groups developing specifications. If the answer is "no, because RFCs live forever and WGs don't", that's fine. Maybe this could be a general observation, much earlier in the document. 13. Security Mechanisms RFC 3329: Security Mechanism Agreement for SIP (S) RFC 3329 [80] defines a mechanism to prevent bid-down attacks in conjunction with SIP authentication. The mechanism has seen very limited deployment. It was defined as part of the 3gpp IMS specification Spencer: Same comment as "push to talk" - is there a helpful pointer to "IMS", which hasn't been spelled out yet, to use as a reference? suite, and is needed only when there are a multiplicity of security mechanisms deployed at a particular server. In practice, this has not been the case. RFC XXXX: End-to-Middle Security in SIP (S) RFC XXXX [81] defines mechanisms for encrypting content from user agents to specific Spencer: maybe you guys aren't used to working with people who are easily confused :-) but s/content/SIP message bodies/. Also - the I thought the draft last-called in December included integrity protection, not just encryption? Perhaps worth mentioning integrity protection as well. network intermediaries. 14. Instant Messaging and Presence SIP provides extensions for instant messaging and presence. Spencer: I wish there was a little more definition of "presence" than appears here, and probably earlier in the document ("presence" has a pretty specific meaning here). RFC 3428: SIP Extension for Instant Messaging RFC 3428 [82] defines the MESSAGE method, used for sending a page mode instant message. Spencer: "page mode" seems pretty obscure for the intended reader base. Perhaps "sending an instant message without setting up a session"? 15. Emergency Services Spencer: see previous note on possibly pointing out the existence of entire working groups. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 11 17:25:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTQL4-00010m-44; Tue, 11 Apr 2006 17:23:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTCdk-0007fT-Gz for sip@ietf.org; Tue, 11 Apr 2006 02:46:16 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTCdi-00038E-3T for sip@ietf.org; Tue, 11 Apr 2006 02:46:16 -0400 Received: from [192.168.0.105] ([71.240.162.175]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.4) with ESMTP id k3B6k3rM052161 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 11 Apr 2006 01:46:03 -0500 (CDT) (envelope-from rjsparks@estacado.net) In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1D0F@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1D0F@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9B98A03E-A793-42A1-A311-2AFB60B7721F@estacado.net> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt Date: Tue, 11 Apr 2006 01:46:01 -0500 To: Christer Holmberg ((JO/LMF)) X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 X-Mailman-Approved-At: Tue, 11 Apr 2006 17:23:50 -0400 Cc: sip@ietf.org, Robert Sparks , 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 On Apr 11, 2006, at 1:19 AM, Christer Holmberg ((JO/LMF)) wrote: > > Hi, > > I don't have any technical comments, but just to make sure I haven't > missed anything: the only thing this document does is changing, when a > proxy forks, a SHOULD in 3261 to a MUST? If so, maybe it could be > mentioned in the introduction. I can add a sentence setting the reader's expectations that the changes are this gentle. > > And, a extremely minor editorial comment: > > "The requirement to use the loop-detection algorithm in RFC 3261 is > set > at should-strength since it is expected that other mechanisms > that will allow a proxy to determine it is not looping will be > standardized in the near future." > > If 3261 was published 4 years ago - what does "near future" means in > IETF terms? :) Outbound. Sometime before Montreal. > > Seriously, does the document really need to "explain" why things were > done in this-or-that way in 3261? Let's just describe the problem (as > the draft does) and fix it... Are you referring to the paragraph you quote above? It doesn't explain why things are in 3261 - it explains why the SHOULD in _this_ draft is a SHOULD and not a MUST. (Putting a reason for SHOULDs is something there's been quite a bit of discussion around on-list in general). RjS > > Regards, > > Christer > > > > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 10. huhtikuuta 2006 23:16 > To: sip@ietf.org > Cc: Robert Sparks; Keith Drage > Subject: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt > > > I'd like to ask the working group to review the "forking loop fix" > draft preparatory to requesting publication of it as a standards- > track > RFC. > > > The document revised following the Dallas meeting document is > available from: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-fork-loop- > fix-01.txt > > > > I'd like to complete this review by May 7, 2006. > > Please send all comments to the list and copy the author, > rjs@estacado.net > > -- > 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 Tue Apr 11 17:25:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTQL4-00011K-QI; Tue, 11 Apr 2006 17:23:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTIIp-0001J2-EF for sip@ietf.org; Tue, 11 Apr 2006 08:49:03 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTIIo-0008P7-1n for sip@ietf.org; Tue, 11 Apr 2006 08:49:03 -0400 Received: from [192.168.0.105] ([71.240.162.175]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.4) with ESMTP id k3BCmuDl032923 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 11 Apr 2006 07:48:57 -0500 (CDT) (envelope-from rjsparks@estacado.net) In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1D16@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1D16@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt Date: Tue, 11 Apr 2006 07:48:54 -0500 To: "Christer Holmberg \(JO/LMF\)" X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b X-Mailman-Approved-At: Tue, 11 Apr 2006 17:23:50 -0400 Cc: sip@ietf.org, Robert Sparks , 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 Apr 11, 2006, at 5:53 AM, Christer Holmberg ((JO/LMF)) wrote: > > Hi, > >>> Seriously, does the document really need to "explain" why things >>> were >>> done in this-or-that way in 3261? Let's just describe the problem >>> (as >>> the draft does) and fix it... >> Are you referring to the paragraph you quote above? It doesn't >> explain >> why things are in 3261 - it explains why the SHOULD in _this_ draft >> is a SHOULD and not a MUST. > > Ok, my misstake. I thought you were referring to text in 3261. > > But still, is it a good idea to talk about what will happen in the > "near > future" in a standards document? > > Isn't it simply enough to keep the "MUST ensure that request is not > looping through this proxy." statement? The proxy can then use > whatever > mechanism to acheive that. > > Because, if we now make the 3261 way a SHOULD, it may in future be too > "strong" due to other mechanisms (outbound etc) proxies may end up > using. We had a thread related to this during the week of the Dallas meeting. Adam pushed to change this SHOULD to a MAY. Later in the week, Jonathan argued the other direction. The essence of the argument was that history has shown us proper loop detection without misdiagnosing spirals is hard (as demonstrated at the earlier SIPits) and implementations should use a standardized algorithm - right now the one in 3261 is the only standardized algorithm we have. > The 3261 mechanism can be listed as the "default mechanism". > > Regards. > > Christer > > > > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: 10. huhtikuuta 2006 23:16 >> To: sip@ietf.org >> Cc: Robert Sparks; Keith Drage >> Subject: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt >> >> >> I'd like to ask the working group to review the "forking loop fix" >> draft preparatory to requesting publication of it as a standards- >> track >> RFC. >> >> >> The document revised following the Dallas meeting document is >> available from: >> >> http://www.ietf.org/internet-drafts/draft-ietf-sip-fork-loop- >> fix-01.txt >> >> >> >> I'd like to complete this review by May 7, 2006. >> >> Please send all comments to the list and copy the author, >> rjs@estacado.net >> >> -- >> 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 Tue Apr 11 18:05:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTQxr-0005HH-Mq; Tue, 11 Apr 2006 18:03:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTQxq-0005HC-Pn for sip@ietf.org; Tue, 11 Apr 2006 18:03:58 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTQxo-0005uP-Fb for sip@ietf.org; Tue, 11 Apr 2006 18:03:58 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 11 Apr 2006 18:03:56 -0400 X-IronPort-AV: i="4.04,113,1144036800"; d="scan'208"; a="86235845:sNHT32290004" 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 k3BM3uVU006002; Tue, 11 Apr 2006 18:03:56 -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, 11 Apr 2006 18:03:55 -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, 11 Apr 2006 18:03:55 -0400 Message-ID: <443C27CB.1030902@cisco.com> Date: Tue, 11 Apr 2006 18:03:55 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Sip] SIP/TLS (1): Domain certificates in SIP References: <33C7D45A-4A39-422C-894F-34AD67022023@softarmor.com> <443B74AF.90507@bell-labs.com> <443BAAC1.6080800@cisco.com> <443C01E2.7080705@lucent.com> In-Reply-To: <443C01E2.7080705@lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Apr 2006 22:03:55.0587 (UTC) FILETIME=[D384E930:01C65DB3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: SIP LIST X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Vijay K. Gurbani wrote: > Paul Kyzivat wrote: > >> Alan Jeffrey wrote: > > [...] > >>> Of all these SIP proxies, only the I-CSCF would have a DNS entry of >>> example.com, the others would be proxyN.example.com (or >>> proxyN.visited.com for the P-CSCF), but they should all be >>> considered as speaking authoritatively for example.com (or >>> visited.com for the P-CSCF). >> >> Considered as speaking authoritatively in what sense? >> >> IMS uses P-Asserted-Identity rather than certs for identity, and has >> its own rules for what elements are trusted to insert it. That is >> outside the scope of this discussion. > > I don't think the distinction being drawn here is P-A-I vs. certs. > While a SIP AoR in a cert binds that cert to a specific user, TLS > certs are not specific to a user, but a host representing the domain > (the inbound proxy, for instance). OK. But then what is meant by "speaking authoritatively for"? > Cullen's earlier email sheds some light in that when a user wants > to talk to a URI of sip:me@example.com, then the inbound proxy > (example.com) presenting a cert with a SAN of "sip:example.com" > suffices. Now what if the inbound proxy wants to mutually authenticate > the outbound proxy (visited.com) from which the request was sent? > To do so, it asks for a cert from the outbound proxy. What should be > the identity in the cert presented by the outbound proxy? And how is > that identity correlated to the SIP vectors? The From header > is no help due to retargetting. The only header that correlates > the identity of the the outbound proxy to the cert is the sent-by > production in the topmost Via. And that will most probably be in > the form of proxyN.visited.com. So in the proxy-proxy case all the receiving proxy can do is check the sending proxy's cert against the via. That doesn't say a lot. For instance it doesn't provide an easy way for the receiving proxy to decide if it should trust a P-A-I from that proxy. Paul > BTW, I would agree with Dean's assessment: > >> But I suspect that buried somewhere in this discussion thread is a >> failure to conceptualize the distinction between a proxy serving >> users of a domain and a proxy serving to relay between domains. > > > Thanks, > > - 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 Tue Apr 11 22:52:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTVRG-0000zl-Iq; Tue, 11 Apr 2006 22:50:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTVRF-0000zg-Ag for sip@ietf.org; Tue, 11 Apr 2006 22:50:37 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTVRE-00010g-0x for sip@ietf.org; Tue, 11 Apr 2006 22:50:37 -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 k3C2pH83017343 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 11 Apr 2006 21:51:19 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <58B71318-CA4C-4565-85F5-275A3F87D340@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: AW: WG: [Sip] Last Call: 'Suppression of Session Initiation ProtocolREFER Method Implicit Subscription' to Proposed Standard Date: Tue, 11 Apr 2006 21:50:31 -0500 To: "Tan, Ya-Ching" X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: sip ietf , oritl@microsoft.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 Apr 11, 2006, at 4:43 AM, Tan, Ya-Ching wrote: > Please igonore the previous mail. I realized that the Refer-Sub > header has no parameter. > Oh good. I was about to resign in abject shame and apply for a job in Marketing. -- 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 Apr 11 22:55:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTVUI-0002HB-2I; Tue, 11 Apr 2006 22:53:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTVUF-0002H6-V0 for sip@ietf.org; Tue, 11 Apr 2006 22:53:43 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTVUF-000199-L1 for sip@ietf.org; Tue, 11 Apr 2006 22:53:43 -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 k3C2sMeJ017362 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 11 Apr 2006 21:54:23 -0500 In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1D16@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1D16@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5AEA08DD-39AD-4AAD-8F08-1A24F4568DA7@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt Date: Tue, 11 Apr 2006 21:53:36 -0500 To: Christer Holmberg ((JO/LMF)) X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: sip@ietf.org, Robert Sparks , Keith Drage , Robert Sparks X-BeenThere: sip@ietf.org X-Mailman-Version: 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 11, 2006, at 5:53 AM, Christer Holmberg ((JO/LMF)) wrote: > But still, is it a good idea to talk about what will happen in the > "near > future" in a standards document? Let me think. . . .No. I believe we should deprecate "Future Perfect Tense" because once we get there, we'll find out it wasn't [1]. [1] Paraphrased from Douglas Adams. -- 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 Apr 12 01:35:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTXyG-0004ha-Q8; Wed, 12 Apr 2006 01:32:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTXyF-0004gm-A0 for sip@ietf.org; Wed, 12 Apr 2006 01:32:51 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTXyC-0006pm-DO for sip@ietf.org; Wed, 12 Apr 2006 01:32:51 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 44D6C56E; Wed, 12 Apr 2006 07:32:47 +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, 12 Apr 2006 07:32:46 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Apr 2006 07:32: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="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt Date: Wed, 12 Apr 2006 07:32:46 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1D1B@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt Thread-Index: AcZdZlJZuhJDWBctSpe2tXmR106siQAi0CpQ From: "Christer Holmberg \(JO/LMF\)" To: "Robert Sparks" X-OriginalArrivalTime: 12 Apr 2006 05:32:46.0876 (UTC) FILETIME=[87D17DC0:01C65DF2] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: sip@ietf.org, Robert Sparks , 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 Hi,=20 >>But still, is it a good idea to talk about what will happen in the=20 >>"near future" in a standards document? >> >>Isn't it simply enough to keep the "MUST ensure that request is not=20 >>looping through this proxy." statement? The proxy can then use=20 >>whatever mechanism to acheive that. >> >>Because, if we now make the 3261 way a SHOULD, it may in future be too >>"strong" due to other mechanisms (outbound etc) proxies may end up=20 >>using. >We had a thread related to this during the week of the Dallas meeting. >Adam pushed to change this SHOULD to a MAY. Later in the week, Jonathan argued the other direction. The essence of the argument was that history has=20 >shown us proper loop detection without misdiagnosing spirals is hard (as demonstrated at the earlier SIPits) and implementations should use a >standardized algorithm - right now the one in 3261 is the only standardized algorithm we have. Yes - currently. But the document should be useful also when/if we have other mechansims. So, maybe you could say: "MUST ensure, using a standards lopp detection mechanism, that a request is not looping through this proxy. RFC 3261 defines a mechanism in chapter x.x.x.. Other standardized mechansims for loop detecting MAY be used instead, or in addition, to the one defined in RFC 3261.". Or something like that... Regards, Christer >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: 10. huhtikuuta 2006 23:16 >> To: sip@ietf.org >> Cc: Robert Sparks; Keith Drage >> Subject: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt >> >> >> I'd like to ask the working group to review the "forking loop fix" >> draft preparatory to requesting publication of it as a standards-=20 >> track RFC. >> >> >> The document revised following the Dallas meeting document is=20 >> available from: >> >> http://www.ietf.org/internet-drafts/draft-ietf-sip-fork-loop- >> fix-01.txt >> >> >> >> I'd like to complete this review by May 7, 2006. >> >> Please send all comments to the list and copy the author,=20 >> rjs@estacado.net >> >> -- >> 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 Wed Apr 12 02:53:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTZCU-0007kq-K7; Wed, 12 Apr 2006 02:51:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTZCR-0007ke-RN for sip@ietf.org; Wed, 12 Apr 2006 02:51:35 -0400 Received: from web36215.mail.mud.yahoo.com ([209.191.68.241]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FTZCQ-0000x3-Hd for sip@ietf.org; Wed, 12 Apr 2006 02:51:35 -0400 Received: (qmail 8112 invoked by uid 60001); 12 Apr 2006 06:51:34 -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=HAniXvs+qleqa0ppUMuUeL568s/w1XdLci9VKqMaKff0oU0WVA4vOcPGksul4X3u/HM0nvWz8R7Ve4Aj2Qr/aE7hNbSPTXVHuPvSfO1MsCR2bAcaKTXjanWTh0BtFIuwFaFEhzxUktbTHsDdaA2h8Yqmj+FYepV5Onq+kpf/lRM= ; Message-ID: <20060412065134.8110.qmail@web36215.mail.mud.yahoo.com> Received: from [196.1.111.169] by web36215.mail.mud.yahoo.com via HTTP; Tue, 11 Apr 2006 23:51:34 PDT Date: Tue, 11 Apr 2006 23:51:34 -0700 (PDT) From: Varun Gupta To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.0 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Sip] SIP Server Security X-BeenThere: sip@ietf.org X-Mailman-Version: 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 What are the relevant security considerations or rather requirements that need to implemented on a SIP server ?? Best Regards Varun __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Apr 12 05:03:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTbE5-0007Q5-5l; Wed, 12 Apr 2006 05:01:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTbE3-0007Q0-AQ for sip@ietf.org; Wed, 12 Apr 2006 05:01:23 -0400 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTbE2-0005Fp-5D for sip@ietf.org; Wed, 12 Apr 2006 05:01:23 -0400 Received: from s73602 (unknown[71.56.187.251]) by comcast.net (sccrmhc12) with SMTP id <2006041209012101200ht1e1e>; Wed, 12 Apr 2006 09:01:21 +0000 Message-ID: <0c8c01c65e0f$5411a240$0500a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: <5EB80D22825EEE42872083AD5BFFB5945D1D16@esealmw113.eemea.ericsson.se> <5AEA08DD-39AD-4AAD-8F08-1A24F4568DA7@softarmor.com> Subject: Re: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt Date: Wed, 12 Apr 2006 03:58:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yesterday, in my notes on the hitchhiker's guide draft, I mentioned including Douglas Adams' work as a reference, but did not realize until I saw Dean's note that we're getting to the point where it should be a NORMATIVE reference (I'm not sure you can implement current SIP without reading it!)... Thanks, Spencer > I believe we should deprecate "Future Perfect Tense" because once we get > there, we'll find out it wasn't [1]. > > [1] Paraphrased from Douglas Adams. > > -- > 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 Apr 12 06:19:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTcQA-0005Dn-76; Wed, 12 Apr 2006 06:17:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTcQ8-0005Di-6l for sip@ietf.org; Wed, 12 Apr 2006 06:17:56 -0400 Received: from nms.above.net.tw ([202.5.224.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTcQ6-0007qd-Pe for sip@ietf.org; Wed, 12 Apr 2006 06:17:56 -0400 Received: from mail.above.net.tw (localhost [127.0.0.1]) by nms.above.net.tw (Postfix) with ESMTP id 1444B20F15 for ; Wed, 12 Apr 2006 18:17:46 +0800 (CST) From: "kkuei" To: Subject: [Sip] Stateless proxy and reliable transport Date: Wed, 12 Apr 2006 18:17:46 +0800 Message-Id: <20060412101024.M61893@above.net.tw> X-Mailer: Open WebMail 2.51 20050228 X-OriginatingIP: 202.5.224.98 (kkuei) MIME-Version: 1.0 Content-Type: text/plain; charset=big5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dear all, This may be a stupid question, but I can't find the answer in RFC3261 and archive. Here is the story: A <-----> Stateless Proxy <------> Proxy <-------> B Assume the transport between A and stateless proxy is reliable (TCP). If A send INVITE to stateless proxy, it will not received 100 provisional response. Then, stateless proxy tries to relay it to proxy. If the packet dropped.. A will not do retransmite right?? Then the transaction will be timeout... Is it the correct behavior?? -- Kevin Kuei _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Apr 12 06:23:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTcTT-0007V3-6P; Wed, 12 Apr 2006 06:21:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTcTS-0007Uy-2i for sip@ietf.org; Wed, 12 Apr 2006 06:21:22 -0400 Received: from nms.above.net.tw ([202.5.224.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTcTR-0008As-KG for sip@ietf.org; Wed, 12 Apr 2006 06:21:22 -0400 Received: from mail.above.net.tw (localhost [127.0.0.1]) by nms.above.net.tw (Postfix) with ESMTP id 1F0B520F15; Wed, 12 Apr 2006 18:21:20 +0800 (CST) From: "kkuei" To: "kkuei" , Subject: Re: [Sip] Stateless proxy and reliable transport Date: Wed, 12 Apr 2006 18:21:20 +0800 Message-Id: <20060412102038.M30046@above.net.tw> In-Reply-To: <20060412101024.M61893@above.net.tw> References: <20060412101024.M61893@above.net.tw> X-Mailer: Open WebMail 2.51 20050228 X-OriginatingIP: 202.5.224.98 (kkuei) MIME-Version: 1.0 Content-Type: text/plain; charset=big5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 Sorry, I forgot the say the transport between stateless proxy and proxy is unreliable (say, UDP) -- Kevin Kuei On Wed, 12 Apr 2006 18:17:46 +0800, kkuei wrote > Dear all, > > This may be a stupid question, but I can't find the answer in > RFC3261 and archive. > > Here is the story: > > A <-----> Stateless Proxy <------> Proxy <-------> B > > Assume the transport between A and stateless proxy is reliable (TCP). > > If A send INVITE to stateless proxy, it will not received 100 > provisional response. Then, stateless proxy tries to relay it to > proxy. If the packet dropped.. A will not do retransmite right?? > > Then the transaction will be timeout... Is it the correct behavior?? > > -- > Kevin Kuei > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Kevin Kuei _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Apr 12 07:48:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTdnT-0008Jd-44; Wed, 12 Apr 2006 07:46:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTdnS-0008JY-2T for sip@ietf.org; Wed, 12 Apr 2006 07:46:06 -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 1FTdnQ-0001xF-Pd for sip@ietf.org; Wed, 12 Apr 2006 07:46:06 -0400 Received: from BPenfield [10.0.200.6] by acmepacket.com with ESMTP (SMTPD-9.02) id A86805D8; Wed, 12 Apr 2006 07:45:44 -0400 Message-ID: <005101c65e26$a2f43780$800101df@acmepacket.com> From: "Bob Penfield" To: , "kkuei" References: <20060412101024.M61893@above.net.tw> <20060412102038.M30046@above.net.tw> Subject: Re: [Sip] Stateless proxy and reliable transport Date: Wed, 12 Apr 2006 07:45:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="big5"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: SIP-Implementors X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Questions like this really belong on the Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors There is rule against a stateless proxy changing the transport for exactly this reason. In section 16.1 of RFC 3261 it says "Requests forwarded between different types of transports where the proxy's TU must take an active role in ensuring reliable delivery on one of the transports MUST be forwarded transaction statefully." cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 bpenfield@acmepacket.com ----- Original Message ----- From: "kkuei" To: "kkuei" ; Sent: Wednesday, April 12, 2006 6:21 AM Subject: Re: [Sip] Stateless proxy and reliable transport > Sorry, I forgot the say the transport between stateless proxy and proxy is > unreliable (say, UDP) > > -- > Kevin Kuei > > On Wed, 12 Apr 2006 18:17:46 +0800, kkuei wrote >> Dear all, >> >> This may be a stupid question, but I can't find the answer in >> RFC3261 and archive. >> >> Here is the story: >> >> A <-----> Stateless Proxy <------> Proxy <-------> B >> >> Assume the transport between A and stateless proxy is reliable (TCP). >> >> If A send INVITE to stateless proxy, it will not received 100 >> provisional response. Then, stateless proxy tries to relay it to >> proxy. If the packet dropped.. A will not do retransmite right?? >> >> Then the transaction will be timeout... Is it the correct behavior?? >> >> -- >> Kevin Kuei >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > -- > Kevin Kuei > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Apr 12 09:10:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTf5U-0003E5-C7; Wed, 12 Apr 2006 09:08:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTf5S-0003Dv-Qt for sip@ietf.org; Wed, 12 Apr 2006 09:08:46 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTf5R-0004yX-Cw for sip@ietf.org; Wed, 12 Apr 2006 09:08:46 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 300343BECB for ; Wed, 12 Apr 2006 15:08:44 +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 07368-01-64 for ; Wed, 12 Apr 2006 15:08:43 +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 C89EB3BE22 for ; Wed, 12 Apr 2006 15:08:43 +0200 (CEST) From: Fredrik Thulin To: sip@ietf.org Date: Wed, 12 Apr 2006 15:08:19 +0200 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200604121508.19273.ft@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.512 tagged_above=-99 required=7 tests=[AWL=0.153, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [Sip] Outbound: errors in example message flow X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Section 8 (Example Message Flow) in draft-ietf-sip-outbound-03 contains two example REGISTERs (included at the end of this e-mail). I think there are a number of errors in the second REGISTER message : * Via branch parameter equals that of the first one, although this is clearly a new transaction. * From-tag equals that of the first one. I believe it shouldn't. * Contact is missing expires parameter, while the first REGISTER has one. also, in the 200 OK response to the second REGISTER, the To-tag generated by the backup proxy should not be the same as the one generated by the primary proxy in the first 200 OK response. Please correct me if I'm wrong. /Fredrik The two example REGISTERs : REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP 10.0.1.1;branch=z9hG4bKnashds7 Max-Forwards: 70 From: Callee ;tag=a73kszlfl To: Callee Call-ID: 1j9FpLxk3uxtm8tn@10.0.1.1 CSeq: 1 REGISTER Supported: path Route: Contact: ;+sip.instance="" ;reg-id=1 Content-Length: 0 and REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP 10.0.1.1;branch=z9hG4bKnashds7 Max-Forwards: 70 From: Callee ;tag=a73kszlfl To: Callee Call-ID: 1j9FpLxk3uxtm8tn-2@10.0.1.1 CSeq: 1 REGISTER Supported: path Route: Contact: ;+sip.instance="" ;reg-id=2 Content-Length: 0 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 12 09:19:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTfDw-0000Ai-GA; Wed, 12 Apr 2006 09:17:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTfDv-0000Ad-PD for sip@ietf.org; Wed, 12 Apr 2006 09:17:31 -0400 Received: from pproxy.gmail.com ([64.233.166.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTfDu-0005C2-Hp for sip@ietf.org; Wed, 12 Apr 2006 09:17:31 -0400 Received: by pproxy.gmail.com with SMTP id t32so1610123pyc for ; Wed, 12 Apr 2006 06:17:28 -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=Fz6jZSfvRuANmtkD6UPWf6hnl0KA4AjO0UyovxY0G9lrbEFLYk7u72jkSR4R6wkjEY/0eJmlY0bTt2SWiuu6/z1prxVrT/OFr86yFeSJ6K9ea1ANK0tzw3ZMfkYgtx/F2HjyOnu23f7c5K1bBzygAA0WLksbKR6LXOMLbbYn1XI= Received: by 10.35.84.16 with SMTP id m16mr1745349pyl; Wed, 12 Apr 2006 06:17:28 -0700 (PDT) Received: by 10.35.89.19 with HTTP; Wed, 12 Apr 2006 06:17:28 -0700 (PDT) Message-ID: <9d77d7060604120617v5d7a8825k3675bea29546ff33@mail.gmail.com> Date: Wed, 12 Apr 2006 21:17:28 +0800 From: "Xiang Ting" To: balasubramanian_neelakantan@quintum.com Subject: Re: [Sip] offer answer In-Reply-To: <001101c65d7b$5cca9a20$7502a8c0@NeelLT> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <7f5ac7240604100707o7439e8dcn2ef2facfe3bfa5ad@mail.gmail.com> <001101c65d7b$5cca9a20$7502a8c0@NeelLT> X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 4/11/06, Bala Neelakantan wrote: > > > > See Section 6.1, page 10. > > The stream MAY indicate additional media formats, not listed in the > corresponding stream in the offer, that the answerer is willing to > send or receive (of course, it will not be able to send them at this > time, since it was not listed in the offer). For streams marked as > Then at what time it will be able to send media descreiption with additiona= l media formats? Thank you. > > So, the answer can have additional media formats in the media line.. > > > > > Thanks, > > Neel > > > > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Mah= esh > Govind > Sent: Monday, April 10, 2006 9:08 AM > To: sip@ietf.org > Subject: [Sip] offer answer > > > > > HI, > > > > > > I have a doubt . > > > > > > If an offer is having a media line > > > m=3Daudio 4000 RTP/AVP 1 2 3 > > > > > > can an answer contain , > > > > > > If an offer is having a media line > > > m=3Daudio 4000 RTP/AVP 1 2 3 5 > > > > > > With thanks and regards > > > Mahesh > > > > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on > current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 12 11:10:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTgxh-000099-VR; Wed, 12 Apr 2006 11:08:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTgxg-00008u-R9 for sip@ietf.org; Wed, 12 Apr 2006 11:08:52 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTgxf-0000vO-Gj for sip@ietf.org; Wed, 12 Apr 2006 11:08:52 -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 k3CF9Rtm020154 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 12 Apr 2006 10:09:28 -0500 In-Reply-To: <20060412101024.M61893@above.net.tw> References: <20060412101024.M61893@above.net.tw> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <520FB540-EF65-4639-BB9C-80DC844D3521@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Stateless proxy and reliable transport Date: Wed, 12 Apr 2006 10:08:41 -0500 To: "kkuei" X-Mailer: Apple Mail (2.749.3) 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 On Apr 12, 2006, at 5:17 AM, kkuei wrote: > Dear all, > > This may be a stupid question, but I can't find the answer in > RFC3261 and > archive. > > Here is the story: > > A <-----> Stateless Proxy <------> Proxy <-------> B > > Assume the transport between A and stateless proxy is reliable (TCP). > > If A send INVITE to stateless proxy, it will not received 100 > provisional > response. Then, stateless proxy tries to relay it to proxy. If the > packet > dropped.. A will not do retransmite right?? > > Then the transaction will be timeout... Is it the correct behavior?? > A is still responsible for retransmission, whether or not it receives a provisional response. This would be required even if all the proxies were stateful and all the links reliable, because there's always a chance that proxy will simply drop a request or fail in some other way. -- 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 Apr 12 11:13:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTh06-0001hq-R9; Wed, 12 Apr 2006 11:11:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTh04-0001ge-Vj for sip@ietf.org; Wed, 12 Apr 2006 11:11:20 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTh02-000134-O2 for sip@ietf.org; Wed, 12 Apr 2006 11:11:20 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 12 Apr 2006 11:11:19 -0400 X-IronPort-AV: i="4.04,115,1144036800"; d="scan'208"; a="86286545:sNHT30089638" 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 k3CFBIvH003078; Wed, 12 Apr 2006 11:11:18 -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, 12 Apr 2006 11:11:18 -0400 Received: from [192.168.1.101] ([10.86.242.88]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Apr 2006 11:11:17 -0400 Message-ID: <443D1895.3030801@cisco.com> Date: Wed, 12 Apr 2006 11:11:17 -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] WGLC for draft-ietf-sip-fork-loop-fix-01.txt References: <5EB80D22825EEE42872083AD5BFFB5945D1D1B@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1D1B@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Apr 2006 15:11:17.0770 (UTC) FILETIME=[591F96A0:01C65E43] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: sip@ietf.org, Robert Sparks , Keith Drage , Robert Sparks , 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 Christer Holmberg (JO/LMF) wrote: > So, maybe you could say: "MUST ensure, using a standards lopp detection > mechanism, that a request is not looping through this proxy. RFC 3261 > defines a mechanism in chapter x.x.x.. Other standardized mechansims for > loop detecting MAY be used instead, or in addition, to the one defined > in RFC 3261.". > > Or something like that... I don't like that wording. I think its important to give clear guidance on what an implementor should do. The clear guidance is to implement the loop detection mechanism in RFC3261. -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 Apr 12 12:14:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FThx9-0005x7-M8; Wed, 12 Apr 2006 12:12:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FThwF-0005LB-1g for sip@ietf.org; Wed, 12 Apr 2006 12:11:27 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FThpU-0002vF-7W for sip@ietf.org; Wed, 12 Apr 2006 12:04:29 -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 k3CG4QPx021473; Wed, 12 Apr 2006 11:04:26 -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 k3CG4Qr24287; Wed, 12 Apr 2006 11:04:26 -0500 (CDT) Message-ID: <443D250A.9050603@lucent.com> Date: Wed, 12 Apr 2006 11:04:26 -0500 From: "Vijay K. Gurbani" 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] SIP/TLS (1): Domain certificates in SIP References: <33C7D45A-4A39-422C-894F-34AD67022023@softarmor.com> <443B74AF.90507@bell-labs.com> <443BAAC1.6080800@cisco.com> <443C01E2.7080705@lucent.com> <443C27CB.1030902@cisco.com> In-Reply-To: <443C27CB.1030902@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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: > OK. But then what is meant by "speaking authoritatively for"? Paul: Thanks for your comments. I will summarize this issue in a followup email to Cullen's note on where this thread is headed. > So in the proxy-proxy case all the receiving proxy can do is check the > sending proxy's cert against the via. That doesn't say a lot. For > instance it doesn't provide an easy way for the receiving proxy to > decide if it should trust a P-A-I from that proxy. Yes, exactly. All the receiving proxy can do is to ensure that the request is coming from where it should be coming from. Thanks. - 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 Wed Apr 12 12:29:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTiBO-0001RL-JV; Wed, 12 Apr 2006 12:27:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTiBN-0001RG-2m for sip@ietf.org; Wed, 12 Apr 2006 12:27:05 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTiBM-0003m8-Oq for sip@ietf.org; Wed, 12 Apr 2006 12:27:05 -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 k3CGR3tJ015899; Wed, 12 Apr 2006 11:27:03 -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 k3CGR2r16870; Wed, 12 Apr 2006 11:27:02 -0500 (CDT) Message-ID: <443D2A57.50200@lucent.com> Date: Wed, 12 Apr 2006 11:27:03 -0500 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] SIP/TLS (1): Domain certificates in SIP References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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 Cullen Jennings wrote: > Ok, I think we all agree that could be proxies that were authorities for > example.com that the SIP DNS resolution for example.com would never end up > resolving to that proxy. (Note I don't think this is the same as the proxy > never sends a request). But given we agree on this, I'm actually lost on > where this thread was going :-) Cullen: Thanks for your comments. Fair enough ... so lets recap. We were drilling down to examine the identities stored in the certs and tying this identity to the notion of an authoritative proxy (more on the latter in a bit). The specific agreement that we appear to have reached is the mechanics of identifying the proxy when the said proxy presents a cert (the "inbound" proxy case). That is, when a user agent receives a cert, the cert should assert an identity corresponding to the name that the agent performed a RFC3263-type resolution on. A cert asserting an identity of "sip:example.com" provides a sufficient anchor for identifying the said proxy if the user agent was attempting to connect to a R-URI that contained a domainname of "example.com" using RFC3263. In this direction (i.e., the proxy server presenting a cert for verification), there is no need to search for a canonical hostname as an identity in the cert (i.e., if RFC3263 leads to the choice of "proxy-1.example.com", then it is not necessary to specifically look for a dNSName SAN extension matching this canonical name). In fact, certain deployments specifically forbid this (sip-identity mentions an example of 3263 resolution on "sip:jon@example.com" leading to a service located at "sip1.example.org"). The following items are open to discussion: (1) What is the meaning of a proxy "speaking authoritatively for a domain?". To me, this is a trait that we have given to a proxy that allows it to act as an authority for incoming requests as well as outgoing requests. And these may be different proxies; i.e., inbound != outbound. In my conceptualization of the problem, the notion of speaking authoritatively for a domain also exists in sip-identity. When the proxy as a holder of the private key of the domain asserts that the originator of this request has been authenticated and is indeed authorized to claim the identity in the From header, the proxy is essentially acting as an authority for that domain. (2) Is the notion of being an authoritative proxy an all-or-none proposition? Do we need to make it more granular? (cf. Mike Thomas' "outsourcing" scenario). (3) While we appear to have reached an agreement on the identities stored in a cert for an inbound proxy case, what about the outbound proxy case? The outbound proxies may not receive session setup requests as a result of RFC3263-type resolution, but they do *send out* requests to other domains. What sort of identities need to be stored in the cert (i.e., "sip:proxyN.example.com", and "sip:example.com", ...) And there has not been any discussion on othe other issues in the domain certs draft, such as the notion of of having two identities ("sip:example.com", "sip:proxy-1.example.com") that actually neatly ties up (3) above. The receiving proxy can, at the very least, have some guarantees that the request orginated from the said domain (Via sent-by will contain "proxy-1.example.com", which matches the identity in the cert, and the From *may* contain the domainname of example.com). Also there has not been any discussion about proxy clusters and wildcarding that are contained in the document. Thanks, - 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 Wed Apr 12 14:15:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTjpx-0004YX-EY; Wed, 12 Apr 2006 14:13:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTjpv-0004Y7-Ah; Wed, 12 Apr 2006 14:13:03 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTjpu-0007PC-2a; Wed, 12 Apr 2006 14:13:03 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k3CID1BW021739; Wed, 12 Apr 2006 18:13:01 GMT Received: from stntexch03.cis.neustar.com ([10.31.13.45]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Apr 2006 14:13:01 -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 Date: Wed, 12 Apr 2006 14:13:00 -0400 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD597054F43E6@stntexch03.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Announcement of Real Time Security list Thread-Index: AcZeXHrJfzAz66E3Q72gu3thk4IDNQ== From: "Peterson, Jon" To: , , , , X-OriginalArrivalTime: 12 Apr 2006 18:13:01.0030 (UTC) FILETIME=[BBF90860:01C65E5C] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: fluffy@cisco.com Subject: [Sip] Announcement of Real Time Security 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 Following our discussion in the RAI Open Area Meeting in Dallas a few = weeks ago on the many strategies circulating for securing RTP, we've = formed a new mailing list in order to further refine our understanding = of the problem space and figure out a way forward. Subscription information for the list is available here.=20 The agenda item from the RAI Open Meeting, including the list of = associated drafts, is pasted below. Interested parties, please move = discussion of these documents to this list. Jon Peterson NeuStar, Inc. ---- There are many proposal discussing keying for RTP when used with = SIP. These issues cross SIPPING, MMUSIC, AVT, and MSEC. What are the common underling requirements driving these proposals? At the high level what are the various architectures? What cross WG architectural level question do we need to answer? Can we come to consensus on high level approaches we would like to investigate? RFC 3830 (MIKEY) RFC 3711 (SRTP) draft-ietf-msec-mikey-rsa-r-02 draft-ietf-mmusic-sdescriptions-12 draft-ietf-mmusic-kmgmt-ext-15 draft-wing-mmusic-sdes-early-media-00 draft-mcgrew-srtp-ekt-00 draft-baugher-mmusic-sdp-dh-00 draft-zimmerman-avt-zrtp-00 draft-tschofenig-avt-rtp-dtls-00 draft-fischl-sipping-media-dtls-0 draft-fischl-mmusic-sdp-dtls-00 draft-rescorla-tls-partial-00 draft-modadugu-dtls-short-00 draft-fries-msec-mikey-applicability-00 draft-ietf-msec-mikey-dhhmac-11 draft-lehtovirta-srtp-rcc-01 draft-saito-mmusic-ipsec-negotiation-req-02 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 12 18:04:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTnQO-0002MS-B0; Wed, 12 Apr 2006 18:02:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTnQM-0002MN-Rc for sip@ietf.org; Wed, 12 Apr 2006 18:02:54 -0400 Received: from sitemail2.everyone.net ([216.200.145.36] helo=omta16.mta.everyone.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTnQM-0002Pl-FY for sip@ietf.org; Wed, 12 Apr 2006 18:02:54 -0400 Received: from dm17.mta.everyone.net (bigiplb-dsnat [172.16.0.19]) by omta16.mta.everyone.net (Postfix) with ESMTP id AF0424015E; Wed, 12 Apr 2006 15:02:53 -0700 (PDT) X-Eon-Dm: dm17 Received: by dm17.mta.everyone.net (EON-AUTHRELAY2[SSL] - cf31a202) id dm17.44347f8d.fc29e; Wed, 12 Apr 2006 15:02:53 -0700 (PDT) X-Eon-Sig: AQIH5JVEPXkNylq2OQIAAAAE,b0a5bbcdd1782a9665f3e4409f984aaa From: "Bala Neelakantan" To: "'Xiang Ting'" , Subject: RE: [Sip] offer answer Date: Wed, 12 Apr 2006 17:05:31 -0500 Message-ID: <000601c65e7d$3875e050$7902a8c0@NeelLT> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <9d77d7060604120617v5d7a8825k3675bea29546ff33@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: balasubramanian_neelakantan@quintum.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Xiang, If the answerer needs to enforce extra media formats, then it should = start a new Offer after the current offer/answer negotiation is completed. =20 Thanks, Neel -----Original Message----- From: Xiang Ting [mailto:x.victoria@gmail.com]=20 Sent: Wednesday, April 12, 2006 8:17 AM To: balasubramanian_neelakantan@quintum.com Cc: Mahesh Govind; sip@ietf.org Subject: Re: [Sip] offer answer On 4/11/06, Bala Neelakantan wrote: > > > > See Section 6.1, page 10. > > The stream MAY indicate additional media formats, not listed in the > corresponding stream in the offer, that the answerer is willing to > send or receive (of course, it will not be able to send them at = this > time, since it was not listed in the offer). For streams marked as > Then at what time it will be able to send media descreiption with = additional media formats? Thank you. > > So, the answer can have additional media formats in the media line.. > > > > > Thanks, > > Neel > > > > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Mahesh > Govind > Sent: Monday, April 10, 2006 9:08 AM > To: sip@ietf.org > Subject: [Sip] offer answer > > > > > HI, > > > > > > I have a doubt . > > > > > > If an offer is having a media line > > > m=3Daudio 4000 RTP/AVP 1 2 3 > > > > > > can an answer contain , > > > > > > If an offer is having a media line > > > m=3Daudio 4000 RTP/AVP 1 2 3 5 > > > > > > With thanks and regards > > > Mahesh > > > > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on > current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 12 20:24:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTpbl-0001WA-F4; Wed, 12 Apr 2006 20:22:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTpbj-0001W5-Sg for sip@ietf.org; Wed, 12 Apr 2006 20:22:47 -0400 Received: from m5tmail1.m5t.com ([207.134.65.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTpbi-0006p4-FX for sip@ietf.org; Wed, 12 Apr 2006 20:22:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 12 Apr 2006 20:24:11 -0400 Message-ID: <83F34964B9BBA546BF2584D46870EB992A33D2@m5tmail1.m5t.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Simultaneous client Non-Invite Transactions Thread-Index: AcZekJYVD+teOKnjRdCFejLxtU6SYA== From: "Eric Tremblay" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Subject: [Sip] Simultaneous client Non-Invite Transactions X-BeenThere: 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="===============1206861253==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1206861253== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65E8F.FD2C21E0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65E8F.FD2C21E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I have been digging the following question for a while without any clear answers, so I think it may be worth a clarification in RFC 3261. Is it allowed to send a non-INVITE request on an existing dialog while there is already a client non-INVITE request in progress on this dialog? Here is a summary of my findings: - In SIPWG Bugzilla, bug 113: The authors clearly wanted to allow simultaneous non-INVITE transactions. - In 3261, section 12.2.1.1 discusses how a UAC generates a request within a dialog. This section does not disallow a UAC from creating multiple non-INVITE client transactions. - In 3261, section 12.2.2 discusses how a UAS generates a response to a request within a dialog. This section explicitly states that a 500 response must be sent if the incoming request is out-of-order. - In 3261, section 28, changes from RFC 2543, clearly states that we can have multiple non-INVITE transactions on a dialog: -- quote o RFC 2543 was silent on whether a UA could initiate a new transaction to a peer while another was in progress. That is now specified here. It is allowed for non-INVITE requests, disallowed for INVITE. --- endquote So on the UAC side, we allow it, and on the UAS side, we allow it if the network behaves correctly, that is it does not reorder the incoming requests. The problem I have is with a subscriber receiving multiple NOTIFY over UDP, and as you might have guessed, the network reorders the packets and then it sends a 500 to a NOTIFY, as per 3261, which removes the subscription at the notifier. Is this the normal and expected behavior? Thank you for any pointers you can provide, Regards, EricT ________________________________________ Eric Tremblay Technical Product Manager M5T Centre D'Excellence en Telecom, Inc. http://www.m5t.com tel: +1-819-829-3972 x238 ------_=_NextPart_001_01C65E8F.FD2C21E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Simultaneous client Non-Invite Transactions

Hi All,

I have been digging the following = question for a while without any clear answers, so I think it may be = worth a clarification in RFC 3261.

Is it allowed to send a non-INVITE = request on an existing dialog while there is already a client non-INVITE = request in progress on this dialog?

Here is a summary of my = findings:

- In SIPWG Bugzilla, bug 113: The = authors clearly wanted to allow simultaneous non-INVITE = transactions.
- In 3261, section 12.2.1.1 discusses = how a UAC generates a request within a dialog. This section does not = disallow a UAC from creating multiple non-INVITE client = transactions.

- In 3261, section 12.2.2 discusses how = a UAS generates a response to a request within a dialog. This section = explicitly states that a 500 response must be sent if the incoming = request is out-of-order.

- In 3261, section 28, changes from RFC = 2543, clearly states that we can have multiple non-INVITE transactions = on a dialog:

-- quote
   o  RFC 2543 was = silent on whether a UA could initiate a new
      = transaction to a peer while another was in progress.  That is = now
      = specified here.  It is allowed for non-INVITE requests, = disallowed
      for = INVITE.
--- endquote

So on the UAC side, we allow it, and on = the UAS side, we allow it if the network behaves correctly, that is it = does not reorder the incoming requests.

The problem I have is with a subscriber = receiving multiple NOTIFY over UDP, and as you might have guessed, the = network reorders the packets and then it sends a 500 to a NOTIFY, as per = 3261, which removes the subscription at the notifier. Is this the normal = and expected behavior?

Thank you for any pointers you can = provide,

Regards,

EricT
________________________________________
Eric Tremblay <mailto:etremblay@m5t.com>
Technical Product Manager
M5T Centre D'Excellence en Telecom, = Inc.
http://www.m5t.com
tel: +1-819-829-3972 x238

------_=_NextPart_001_01C65E8F.FD2C21E0-- --===============1206861253== 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 --===============1206861253==-- From sip-bounces@ietf.org Wed Apr 12 20:31:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTpiA-0005Cb-IB; Wed, 12 Apr 2006 20:29:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTpi9-0005CW-7X for sip@ietf.org; Wed, 12 Apr 2006 20:29:25 -0400 Received: from m5tmail1.m5t.com ([207.134.65.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTpi8-0006vI-Ne for sip@ietf.org; Wed, 12 Apr 2006 20:29:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Simultaneous client Non-Invite Transactions Date: Wed, 12 Apr 2006 20:30:46 -0400 Message-ID: <83F34964B9BBA546BF2584D46870EB992A33D3@m5tmail1.m5t.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Simultaneous client Non-Invite Transactions Thread-Index: AcZekJYVD+teOKnjRdCFejLxtU6SYAAAJwWA From: "Eric Tremblay" To: , X-Spam-Score: 0.1 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba 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="===============1147818872==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1147818872== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65E90.E8B1CE8A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65E90.E8B1CE8A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Oops, sorry, I realize this should have been posted to sip-implementors. =20 Moving to the proper list, and please make sure to reply only to sip-implementors. =20 Regards, =20 EricT =20 ________________________________ From: Eric Tremblay [mailto:etremblay@m5t.com]=20 Sent: April 12, 2006 20:24 To: sip@ietf.org Subject: [Sip] Simultaneous client Non-Invite Transactions =09 =09 Hi All,=20 I have been digging the following question for a while without any clear answers, so I think it may be worth a clarification in RFC 3261. Is it allowed to send a non-INVITE request on an existing dialog while there is already a client non-INVITE request in progress on this dialog? Here is a summary of my findings:=20 - In SIPWG Bugzilla, bug 113: The authors clearly wanted to allow simultaneous non-INVITE transactions.=20 - In 3261, section 12.2.1.1 discusses how a UAC generates a request within a dialog. This section does not disallow a UAC from creating multiple non-INVITE client transactions. - In 3261, section 12.2.2 discusses how a UAS generates a response to a request within a dialog. This section explicitly states that a 500 response must be sent if the incoming request is out-of-order. - In 3261, section 28, changes from RFC 2543, clearly states that we can have multiple non-INVITE transactions on a dialog: -- quote=20 o RFC 2543 was silent on whether a UA could initiate a new=20 transaction to a peer while another was in progress. That is now=20 specified here. It is allowed for non-INVITE requests, disallowed=20 for INVITE.=20 --- endquote=20 So on the UAC side, we allow it, and on the UAS side, we allow it if the network behaves correctly, that is it does not reorder the incoming requests. The problem I have is with a subscriber receiving multiple NOTIFY over UDP, and as you might have guessed, the network reorders the packets and then it sends a 500 to a NOTIFY, as per 3261, which removes the subscription at the notifier. Is this the normal and expected behavior? Thank you for any pointers you can provide,=20 Regards,=20 EricT=20 ________________________________________=20 Eric Tremblay >=20 Technical Product Manager=20 M5T Centre D'Excellence en Telecom, Inc.=20 http://www.m5t.com =20 tel: +1-819-829-3972 x238=20 ------_=_NextPart_001_01C65E90.E8B1CE8A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Simultaneous client Non-Invite Transactions
Oops, sorry, I realize this should have been = posted to=20 sip-implementors.
 
Moving to the proper list, and please make = sure to=20 reply only to sip-implementors.
 
Regards,
 
EricT
 

From: Eric Tremblay = [mailto:etremblay@m5t.com]=20
Sent: April 12, 2006 20:24
To:=20 sip@ietf.org
Subject: [Sip] Simultaneous client Non-Invite=20 Transactions

Hi All,

I have been digging the following = question for a=20 while without any clear answers, so I think it may be worth a = clarification in=20 RFC 3261.

Is it allowed to send a non-INVITE = request on an=20 existing dialog while there is already a client non-INVITE request in = progress=20 on this dialog?

Here is a summary of my = findings:

- In SIPWG Bugzilla, bug 113: The = authors clearly=20 wanted to allow simultaneous non-INVITE transactions.
- In 3261, section 12.2.1.1 discusses how a UAC = generates a=20 request within a dialog. This section does not disallow a UAC from = creating=20 multiple non-INVITE client transactions.

- In 3261, section 12.2.2 discusses how = a UAS=20 generates a response to a request within a dialog. This section = explicitly=20 states that a 500 response must be sent if the incoming request is=20 out-of-order.

- In 3261, section 28, changes from RFC = 2543,=20 clearly states that we can have multiple non-INVITE transactions on a=20 dialog:

-- quote
   o  RFC 2543 was silent on whether a UA = could initiate=20 a new
     =20 transaction to a peer while another was in progress.  That is = now=20
      = specified=20 here.  It is allowed for non-INVITE requests, disallowed =
      for = INVITE.
--- endquote

So on the UAC side, we allow it, and on = the UAS=20 side, we allow it if the network behaves correctly, that is it does = not=20 reorder the incoming requests.

The problem I have is with a subscriber = receiving=20 multiple NOTIFY over UDP, and as you might have guessed, the network = reorders=20 the packets and then it sends a 500 to a NOTIFY, as per 3261, which = removes=20 the subscription at the notifier. Is this the normal and expected=20 behavior?

Thank you for any pointers you can = provide,=20

Regards,

EricT
________________________________________
Eric Tremblay <mailto:etremblay@m5t.com>
Technical Product=20 Manager
M5T Centre D'Excellence = en Telecom,=20 Inc.
http://www.m5t.com
tel:=20 +1-819-829-3972 x238

------_=_NextPart_001_01C65E90.E8B1CE8A-- --===============1147818872== 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 --===============1147818872==-- From sip-bounces@ietf.org Wed Apr 12 22:38:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTrhY-00021c-LN; Wed, 12 Apr 2006 22:36:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTrhW-00021U-Aj for sip@ietf.org; Wed, 12 Apr 2006 22:36:54 -0400 Received: from nms.above.net.tw ([202.5.224.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTrhU-0001iN-Sj for sip@ietf.org; Wed, 12 Apr 2006 22:36:54 -0400 Received: from mail.above.net.tw (localhost [127.0.0.1]) by nms.above.net.tw (Postfix) with ESMTP id B508920F03; Thu, 13 Apr 2006 10:36:49 +0800 (CST) From: "kkuei" To: Dean Willis Subject: Re: [Sip] Stateless proxy and reliable transport Date: Thu, 13 Apr 2006 10:36:49 +0800 Message-Id: <20060413023337.M71694@above.net.tw> In-Reply-To: <520FB540-EF65-4639-BB9C-80DC844D3521@softarmor.com> References: <20060412101024.M61893@above.net.tw> <520FB540-EF65-4639-BB9C-80DC844D3521@softarmor.com> X-Mailer: Open WebMail 2.51 20050228 X-OriginatingIP: 202.5.224.98 (kkuei) MIME-Version: 1.0 Content-Type: text/plain; charset=big5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 Hi Dean, Thanks for your reply. But rfc3261 section 17.1.1.1 said: INVITE client transaction: "The request is not retransmitted over reliable transports" You said: A responsible for retransmission Which layer will be responsible for retransmission?? Cheers, -- Kevin Kuei On Wed, 12 Apr 2006 10:08:41 -0500, Dean Willis wrote > On Apr 12, 2006, at 5:17 AM, kkuei wrote: > > > Dear all, > > > > This may be a stupid question, but I can't find the answer in > > RFC3261 and > > archive. > > > > Here is the story: > > > > A <-----> Stateless Proxy <------> Proxy <-------> B > > > > Assume the transport between A and stateless proxy is reliable (TCP). > > > > If A send INVITE to stateless proxy, it will not received 100 > > provisional > > response. Then, stateless proxy tries to relay it to proxy. If the > > packet > > dropped.. A will not do retransmite right?? > > > > Then the transaction will be timeout... Is it the correct behavior?? > > > > A is still responsible for retransmission, whether or not it > receives a provisional response. > > This would be required even if all the proxies were stateful and all > the links reliable, because there's always a chance that proxy will > simply drop a request or fail in some other way. > > -- > Dean -- Kevin Kuei _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Apr 13 07:50:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU0JP-00010k-UU; Thu, 13 Apr 2006 07:48:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU0JN-00010f-SE for sip@ietf.org; Thu, 13 Apr 2006 07:48:33 -0400 Received: from pproxy.gmail.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU0JN-0001Sk-KF for sip@ietf.org; Thu, 13 Apr 2006 07:48:33 -0400 Received: by pproxy.gmail.com with SMTP id t32so1856203pyc for ; Thu, 13 Apr 2006 04:48:33 -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=fjf+LCk0pyJf0rgu3LnP8fDNhcNLKEBhx1zj4E77sED5v9HOYQKxYq4s/7130jmNFxKLGHtO1tYdMbIrByxHejpAet3804Cp+xE1Nz5dZwrJZxY4OImlpPLnZkqkE2rt/3/lV/x8aFwhnJJbIHBpiFFAQohpZSLSz2u7jVVCCTw= Received: by 10.35.18.4 with SMTP id v4mr55199pyi; Thu, 13 Apr 2006 04:48:33 -0700 (PDT) Received: by 10.35.89.19 with HTTP; Thu, 13 Apr 2006 04:48:33 -0700 (PDT) Message-ID: <9d77d7060604130448v49cc374fs2f2829558a9ac29b@mail.gmail.com> Date: Thu, 13 Apr 2006 19:48:33 +0800 From: "Xiang Ting" To: balasubramanian_neelakantan@quintum.com Subject: Re: [Sip] offer answer In-Reply-To: <000601c65e7d$3875e050$7902a8c0@NeelLT> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <9d77d7060604120617v5d7a8825k3675bea29546ff33@mail.gmail.com> <000601c65e7d$3875e050$7902a8c0@NeelLT> X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 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 Bala, On 4/13/06, Bala Neelakantan wrote: > Xiang, > > If the answerer needs to enforce extra media formats, then it should star= t a > new Offer after the current offer/answer negotiation is completed. > That is to say the answerer can not add extra media format information in this particular transaction, isn't it? > Thanks, > Neel > > > -----Original Message----- > From: Xiang Ting [mailto:x.victoria@gmail.com] > Sent: Wednesday, April 12, 2006 8:17 AM > To: balasubramanian_neelakantan@quintum.com > Cc: Mahesh Govind; sip@ietf.org > Subject: Re: [Sip] offer answer > > On 4/11/06, Bala Neelakantan wrote: > > > > > > > > See Section 6.1, page 10. > > > > The stream MAY indicate additional media formats, not listed in the > > corresponding stream in the offer, that the answerer is willing to > > send or receive (of course, it will not be able to send them at this > > time, since it was not listed in the offer). For streams marked as > > > Then at what time it will be able to send media descreiption with additio= nal > media formats? > > Thank you. > > > > So, the answer can have additional media formats in the media line.. > > > > > > > > > > Thanks, > > > > Neel > > > > > > > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Mahesh > > Govind > > Sent: Monday, April 10, 2006 9:08 AM > > To: sip@ietf.org > > Subject: [Sip] offer answer > > > > > > > > > > HI, > > > > > > > > > > > > I have a doubt . > > > > > > > > > > > > If an offer is having a media line > > > > > > m=3Daudio 4000 RTP/AVP 1 2 3 > > > > > > > > > > > > can an answer contain , > > > > > > > > > > > > If an offer is having a media line > > > > > > m=3Daudio 4000 RTP/AVP 1 2 3 5 > > > > > > > > > > > > With thanks and regards > > > > > > Mahesh > > > > > > > > > > _______________________________________________ > > Sip mailing list > > https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on > > current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 13 10:36:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU2u1-0002Ss-Qh; Thu, 13 Apr 2006 10:34:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU2u0-0002Si-1P for sip@ietf.org; Thu, 13 Apr 2006 10:34:32 -0400 Received: from pproxy.gmail.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU2ty-0006m7-OO for sip@ietf.org; Thu, 13 Apr 2006 10:34:31 -0400 Received: by pproxy.gmail.com with SMTP id t32so1893736pyc for ; Thu, 13 Apr 2006 07:34:30 -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:mime-version:content-type:content-transfer-encoding:content-disposition; b=CeaCbEGm+T4omxO8XO2XVdhNlRTykNBonXrVAlkNQgooCstpGXgXGr0AvnKFT6K2oIOqyqKVNBMHypWq3ITZmz1x1Y1z89bO3LbIsunOtuzLUCI2deCDzfTLP/dcX+KFrKLbJaKEcD1nLro2MxbyLJsVEflE6q5P5g3lqsttY/0= Received: by 10.35.54.20 with SMTP id g20mr172536pyk; Thu, 13 Apr 2006 07:34:30 -0700 (PDT) Received: by 10.35.89.19 with HTTP; Thu, 13 Apr 2006 07:34:30 -0700 (PDT) Message-ID: <9d77d7060604130734y6d6604cfr7e2d47555daf746a@mail.gmail.com> Date: Thu, 13 Apr 2006 22:34:30 +0800 From: "Xiang Ting" To: sip@ietf.org Subject: [Sip]Does message/cpim is a valid Content-Type in SIP MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Jonathan Rosenberg , Eve Schooler , Robert Sparks , Henning Schulzrinne , Alan Johnston , Gonzalo Camarillo , Mark Handley , Jon Peterson X-BeenThere: sip@ietf.org X-Mailman-Version: 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 saw somebody assign message/cpim as Content-Type head field content in SIP. However, the cpim format requires a blank line between the Content-Type line and the cpim message header. I want to know which following SIP message segment is valid, or both, or neither? [snip1] MESSAGE sip:xt@as.example.org SIP/2.0 ... ... Content-Type: message/CPIM Content-Length: 115 NS: XX XX.Reply: no Conent-Type: text/plain This is a plain text in cpim. [/snip1] ------------------------ [snip2] MESSAGE sip:xt@as.example.org SIP/2.0 ... ... Content-Length: 115 Content-Type: message/CPIM NS: XX XX.Reply: no Conent-Type: text/plain This is a plain text in cpim. [/snip2] Thanks in advance! _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Apr 13 13:38:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU5k1-0002yH-OK; Thu, 13 Apr 2006 13:36:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU5k0-0002YQ-7d for sip@ietf.org; Thu, 13 Apr 2006 13:36:24 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU5gQ-0004TA-0R for sip@ietf.org; Thu, 13 Apr 2006 13:32:43 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 1C2496C017 for ; Thu, 13 Apr 2006 13:32:36 -0400 (EDT) Subject: Re: [Sip]Does message/cpim is a valid Content-Type in SIP From: "Dale R. Worley" To: Sip In-Reply-To: <9d77d7060604130734y6d6604cfr7e2d47555daf746a@mail.gmail.com> References: <9d77d7060604130734y6d6604cfr7e2d47555daf746a@mail.gmail.com> Content-Type: text/plain Date: Thu, 13 Apr 2006 13:32:36 -0400 Message-Id: <1144949556.29651.17.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: 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 On Thu, 2006-04-13 at 22:34 +0800, Xiang Ting wrote: > I saw somebody assign message/cpim as Content-Type head field content > in SIP. However, the cpim format requires a blank line between the > Content-Type line and the cpim message header. I want to know which > following SIP message segment is valid, or both, or neither? They are equivalent, because they differ only in the ordering of two different headers (Content-Type and Content-Length). 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 Apr 13 14:58:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU6z4-0004fz-CK; Thu, 13 Apr 2006 14:56:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU6z3-0004fu-Cu for sip@ietf.org; Thu, 13 Apr 2006 14:56:01 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU6z3-0007H7-3b for sip@ietf.org; Thu, 13 Apr 2006 14:56:01 -0400 Received: from [64.101.149.214] (deanwillis-ib.cisco.com [64.101.149.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k3DIucYv026299 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 13 Apr 2006 13:56:39 -0500 In-Reply-To: <20060413023337.M71694@above.net.tw> References: <20060412101024.M61893@above.net.tw> <520FB540-EF65-4639-BB9C-80DC844D3521@softarmor.com> <20060413023337.M71694@above.net.tw> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <557F9B20-15D4-48F2-9219-AF36F3539E6D@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Stateless proxy and reliable transport Date: Thu, 13 Apr 2006 13:48:51 -0500 To: kkuei X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 12, 2006, at 9:36 PM, kkuei wrote: > Hi Dean, > > Thanks for your reply. But rfc3261 section 17.1.1.1 said: > > INVITE client transaction: > "The request is not retransmitted over reliable transports" > > You said: > A responsible for retransmission > > Which layer will be responsible for retransmission?? > Theoretically, the application layer above the SIP UA, although I'm not sure I'm happy about this. I suppose it depends somewhat means by retransmitted". I suspect "retried" is a better term for the state I'm describing. If the transport is reliable, there are three possible occurrences that get us here: 1) The transport layer returns an error -- generally, something like "ICMP host unreachable" or "connection reset by peer". 2) The transport layer is happy, but we never see a response, so timer B fires. 3) The keepalive layer finds that the proxy we thought we were talking to is not talking to us anymore. The problem is that there may have been a proxy-discard somewhere, or an unreliable link at a "stateless" proxy that dropped the request (note that proxies adapting from reliable to unreliable transport really have to be at least transaction stateful, but sometimes aren't). There's a strong argument to be made that we need a fairly aggressive use of timer B, followed by "re-execution of the request" in the UA. This is especially pertinent if there are multiple possible next-hop routes towards the target. An example of this occurs in sip-outbound, when a UA discovers mid- transaction that the route identified by a "flow" has failed, and completes the transaction using a separate flow (and related route). Following 3261 strictly, we'd have to take the transaction to "terminated" state. But we don't, as I understand sip-outbound. -- 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 Apr 13 18:06:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU9vX-00025g-D9; Thu, 13 Apr 2006 18:04:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU9vW-00025b-Ng for sip@ietf.org; Thu, 13 Apr 2006 18:04:34 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU9vW-0005Ph-DB for sip@ietf.org; Thu, 13 Apr 2006 18:04:34 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 13 Apr 2006 15:04:34 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,118,1144047600"; d="scan'208"; a="25871214:sNHT24851828" 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 k3DM4XvF004427; Thu, 13 Apr 2006 18:04:33 -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, 13 Apr 2006 18:04:33 -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, 13 Apr 2006 18:04:33 -0400 Message-ID: <443ECAF0.3000403@cisco.com> Date: Thu, 13 Apr 2006 18:04:32 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Xiang Ting Subject: Re: [Sip] offer answer References: <9d77d7060604120617v5d7a8825k3675bea29546ff33@mail.gmail.com> <000601c65e7d$3875e050$7902a8c0@NeelLT> <9d77d7060604130448v49cc374fs2f2829558a9ac29b@mail.gmail.com> In-Reply-To: <9d77d7060604130448v49cc374fs2f2829558a9ac29b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Apr 2006 22:04:33.0330 (UTC) FILETIME=[3ED78920:01C65F46] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: sip@ietf.org, balasubramanian_neelakantan@quintum.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 Xiang Ting wrote: > Hi Bala, > > On 4/13/06, Bala Neelakantan wrote: > >>Xiang, >> >>If the answerer needs to enforce extra media formats, then it should start a >>new Offer after the current offer/answer negotiation is completed. >> > > That is to say the answerer can not add extra media format information > in this particular transaction, isn't it? The answerer may add them, but they may not be used. However they can serve as hints for the next offer/answer cycle. In general with offer/answer it seems to work out best if each side keeps stating what it wants, censoring itself based on what it thinks the other end wants. This isn't always possible - there are rules that must be followed that don't always allow this. But its still good policy when applied to the extent allowed. Paul >>Thanks, >>Neel >> >> >>-----Original Message----- >>From: Xiang Ting [mailto:x.victoria@gmail.com] >>Sent: Wednesday, April 12, 2006 8:17 AM >>To: balasubramanian_neelakantan@quintum.com >>Cc: Mahesh Govind; sip@ietf.org >>Subject: Re: [Sip] offer answer >> >>On 4/11/06, Bala Neelakantan wrote: >> >>> >>> >>>See Section 6.1, page 10. >>> >>> The stream MAY indicate additional media formats, not listed in the >>> corresponding stream in the offer, that the answerer is willing to >>> send or receive (of course, it will not be able to send them at this >>> time, since it was not listed in the offer). For streams marked as >>> >> >>Then at what time it will be able to send media descreiption with additional >>media formats? >> >>Thank you. >> >>>So, the answer can have additional media formats in the media line.. >>> >>> >>> >>> >>>Thanks, >>> >>>Neel >>> >>> >>> >>> >>>-----Original Message----- >>>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >> >>Mahesh >> >>>Govind >>>Sent: Monday, April 10, 2006 9:08 AM >>>To: sip@ietf.org >>>Subject: [Sip] offer answer >>> >>> >>> >>> >>>HI, >>> >>> >>> >>> >>> >>>I have a doubt . >>> >>> >>> >>> >>> >>>If an offer is having a media line >>> >>> >>>m=audio 4000 RTP/AVP 1 2 3 >>> >>> >>> >>> >>> >>>can an answer contain , >>> >>> >>> >>> >>> >>>If an offer is having a media line >>> >>> >>>m=audio 4000 RTP/AVP 1 2 3 5 >>> >>> >>> >>> >>> >>>With thanks and regards >>> >>> >>>Mahesh >>> >>> >>> >>> >>>_______________________________________________ >>>Sip mailing list >>>https://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol >>>Use sip-implementors@cs.columbia.edu for questions on >>>current sip >>>Use sipping@ietf.org for new developments on the application of sip >>> >>> >> >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 14 02:51:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUI6P-0007zu-J2; Fri, 14 Apr 2006 02:48:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUI6O-0007zp-H3 for sip@ietf.org; Fri, 14 Apr 2006 02:48:20 -0400 Received: from mssmx03.belgacom.be ([213.181.44.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUI6H-00061F-Nb for sip@ietf.org; Fri, 14 Apr 2006 02:48:20 -0400 Received: from aev002.bgc.net ([45.220.48.101]:1168) by mssmx03.belgacom.be with esmtp id 1FUI6H-0002Qs-54 for ; Fri, 14 Apr 2006 08:48:13 +0200 Received: from AE0005.BGC.NET ([45.220.48.36]) by AE0002.BGC.NET with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Apr 2006 08:48:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 14 Apr 2006 08:48:11 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Via syntax question Thread-Index: AcZfj2WDJqTaa5qeQMGSSRIRh2D+WQ== From: To: X-OriginalArrivalTime: 14 Apr 2006 06:48:11.0830 (UTC) FILETIME=[65BA2D60:01C65F8F] X-TM-AS-Product-Ver: SMEX-7.0.0.1433-3.5.1048-14384.000 X-TM-AS-Result: No--20.500000-8.000000-31 X-Spam-Score: 0.6 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Subject: [Sip] Via syntax 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="===============0325024522==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0325024522== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65F8F.65D31B76" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65F8F.65D31B76 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Dear SIP experts, I have the following question: In RFC 3261 I found the syntax for the Via header being: --------------------------------------------------------- Via =3D ( "Via" / "v" ) HCOLON via-parm *(COMMA via-parm) via-parm =3D sent-protocol LWS sent-by *( SEMI via-params ) via-params =3D via-ttl / via-maddr / via-received / via-branch / via-extension --------------------------------------------------------- In a response message in a call trace I found the following: --------------------------------------------------------- Via: SIP/2.0/UDP 10.127.128.230;branch=3Dz9hG4bK02aa.428ac753.0,SIP/2.0/UDP 10.127.246.8:5060;rport=3D5060;branch=3Dz9hG4bK-1145bc-43786746-21c68c42 ----------------------------------- Syntactically this seems to be correct, but how should I interprete this Via header. Is this the same as having 2 Via headers (showing the retrun path to be usedby this response) or does this indicate 2 alternative return paths ? Many thanks Jan Van Geel IT and Network Development Specialist Belgacom ITN/NIS/NST/NCP Tel : + 32 2 202 1035 Email : jan.van.geel@belgacom.be jan.van-geel@ties.itu.int www.cyberwezz.tk **** DISCLAIMER **** http://www.belgacom.be/maildisclaimer ------_=_NextPart_001_01C65F8F.65D31B76 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Via syntax question

Dear SIP experts,
I have the following question:

In RFC 3261 I found the syntax for the= Via header being:

---------------------------------------------------------
Via          = ;     =3D  ( "Via" / "v" )= HCOLON via-parm *(COMMA via-parm)
via-parm         = =3D  sent-protocol LWS sent-by *( SEMI via-params )
via-params        =3D = via-ttl / via-maddr
          &n= bsp;          / via-received /= via-branch
          &n= bsp;          /= via-extension
---------------------------------------------------------

In a response message in a call trace I= found the following:

---------------------------------------------------------
Via: SIP/2.0/UDP= 10.127.128.230;branch=3Dz9hG4bK02aa.428ac753.0,SIP/2.0/UDP= 10.127.246.8:5060;rport=3D5060;branch= =3Dz9hG4bK-1145bc-43786746-21c68c42

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

Syntactically this seems to be= correct, but how should I interprete this Via header.
Is this the same as having 2 Via= headers (showing the retrun path to be usedby this response) or does this= indicate 2 alternative return paths ?

Many thanks


Jan Van= Geel
IT and Network= Development Specialist
Belgacom= ITN/NIS/NST/NCP
Tel : + 32 2 202= 1035
Email := jan.van.geel@belgacom.be
          = jan.van-geel@ties.itu.int
www.cyberwezz.tk

**** DISCLAIMER **** http://www.belgacom.be/maildisclaimer
------_=_NextPart_001_01C65F8F.65D31B76-- --===============0325024522== 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 --===============0325024522==-- From sip-bounces@ietf.org Fri Apr 14 06:06:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUL9t-0003vv-3k; Fri, 14 Apr 2006 06:04:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUL9r-0003vq-AZ for sip@ietf.org; Fri, 14 Apr 2006 06:04:07 -0400 Received: from kecgate02.infosys.com ([61.95.162.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUL9q-0003hx-DE for sip@ietf.org; Fri, 14 Apr 2006 06:04:07 -0400 Received: from indhubbhs01.ad.infosys.com ([192.168.200.81]) by Kecgate02.infosys.com with InterScan Messaging Security Suite; Fri, 14 Apr 2006 15:33:27 +0530 Received: from BLRKECMSG14.ad.infosys.com ([172.22.147.6]) by indhubbhs01.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Apr 2006 15:33:00 +0530 Received: from BLRKECMSG01.ad.infosys.com ([172.25.213.131]) by BLRKECMSG14.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Apr 2006 15:33:00 +0530 Received: from 135.254.196.38 ([135.254.196.38]) by BLRKECMSG01.ad.infosys.com ([172.25.213.139]) with Microsoft Exchange Server HTTP-DAV ; Fri, 14 Apr 2006 10:03:00 +0000 Received: from dakota.india.ascend.com by BLRKECMSG01; 14 Apr 2006 15:47:52 +0530 Subject: Re: [Sip] Via syntax question From: "Kasthuri Ram V." To: jan.van.geel@belgacom.be In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Infosys Technologies Ltd. Date: Fri, 14 Apr 2006 15:47:52 +0530 Message-Id: <1145009872.25694.31.camel@dakota> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) X-OriginalArrivalTime: 14 Apr 2006 10:03:00.0684 (UTC) FILETIME=[9CD3C0C0:01C65FAA] X-Spam-Score: 1.5 (+) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kasthuriram_V@infosys.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Fri, 2006-04-14 at 08:48 +0200, jan.van.geel@belgacom.be wrote: > > Dear SIP experts, > I have the following question: > > In RFC 3261 I found the syntax for the Via header being: > > --------------------------------------------------------- > Via = ( "Via" / "v" ) HCOLON via-parm *(COMMA > via-parm) > via-parm = sent-protocol LWS sent-by *( SEMI via-params ) > via-params = via-ttl / via-maddr > / via-received / via-branch > / via-extension > --------------------------------------------------------- > > In a response message in a call trace I found the following: > > --------------------------------------------------------- > Via: SIP/2.0/UDP > 10.127.128.230;branch=z9hG4bK02aa.428ac753.0,SIP/2.0/UDP > 10.127.246.8:5060;rport=5060;branch=z9hG4bK-1145bc-43786746-21c68c42 > > ----------------------------------- > > Syntactically this seems to be correct, but how should I interprete > this Via header. > Is this the same as having 2 Via headers (showing the retrun path to > be usedby this response) or does this indicate 2 alternative return > paths ? > Reference: RFC 3261, Section "7.3.1 Header Field Format" Multiple header field rows with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list (that is, if follows the grammar defined in Section 7.3). It MUST be possible to combine the multiple header field rows into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The exceptions to this rule are the WWW-Authenticate, Authorization, Proxy- Authenticate, and Proxy-Authorization header fields. Via header is not an exception and hence in my understanding, your example should be interpreted same as having two Via headers in the respective order. HTH, KasthuriRam -- **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 15 01:43:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUdWR-0001tl-Cz; Sat, 15 Apr 2006 01:40:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUdWP-0001tg-P6 for sip@ietf.org; Sat, 15 Apr 2006 01:40:38 -0400 Received: from wproxy.gmail.com ([64.233.184.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUdWO-0000Dh-3E for sip@ietf.org; Sat, 15 Apr 2006 01:40:37 -0400 Received: by wproxy.gmail.com with SMTP id i22so157367wra for ; Fri, 14 Apr 2006 22:40:33 -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:references; b=F1YEjwg6RUuPRoYpgKw5ad5w1U1yXDlq00GTVKQsyz5qEeiT60fHM6g8Tmk0z7+ZqVm5x7kp6R5gKqhGDKcX++QOdaQ4uSkWtvSBQ8W8zrGQd5ojhR4D047PPw5NO7VPkBKiCi+qEcu8aX/quN8oIahwFMIsQSYdykcn+U/vvw4= Received: by 10.65.153.15 with SMTP id f15mr58452qbo; Fri, 14 Apr 2006 22:40:33 -0700 (PDT) Received: by 10.64.156.5 with HTTP; Fri, 14 Apr 2006 22:40:33 -0700 (PDT) Message-ID: <7f5ac7240604142240m3c68c5d3v6ef6d1ad3584036e@mail.gmail.com> Date: Sat, 15 Apr 2006 14:40:33 +0900 From: "Mahesh Govind" To: sip@ietf.org In-Reply-To: <7f5ac7240604141916g5a71dad0ya91eeacfdee64454@mail.gmail.com> MIME-Version: 1.0 References: <072C5B76F7CEAB488172C6F64B30B5E30156FFE8@xmb-rtp-20b.amer.cisco.com> <37085fc00604140556hfa28182m8ceb58169565b4c1@mail.gmail.com> <7f5ac7240604141916g5a71dad0ya91eeacfdee64454@mail.gmail.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 06d29b9b22258f4f07fe89b4d4a05a86 Cc: Rajkumar Nair , "Ivan Varghis \(ivarghis\)" Subject: [Sip] Fwd: [Sipping] SIP Status code for communicating about UA in minimalstate- Post active dialog X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0865735233==" Errors-To: sip-bounces@ietf.org --===============0865735233== Content-Type: multipart/alternative; boundary="----=_Part_35170_5495358.1145079633605" ------=_Part_35170_5495358.1145079633605 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline HI, We had earlier written a draft about service state of sip entities .Basically it is an event package. ( http://www.ietf.org/internet-drafts/draft-mahesh-sipping-svc-state-notify-0= 0.txt ) The draft is not telling exactly about the requirement in the thread , bu= t some thing similiar to it . If you have time please go through it .Currentl= y we have defined only one state , Out of service, but we see that we can define other intermediate states (dormant ) and another final state inservice .also and this can be extende= d very easily. (PS :In the examples couple of bugs are there about the usage and implict subscription) With thanks and regards Mahesh On 4/14/06, Ranga wrote: > > Correct me if I am wrong. > > As per the protocol, SIP responses are sent in response to the request bu= t > not generated. > > In this perticular case, you could implement this on top of NOTIFY ( > implicit SUBCRIPTION ). > > > Ranga > > > On 4/12/06, Michael Hammer (mhammer) < mhammer@cisco.com> wrote: > > > My concern is that the SIP status code is status about the dialog > > transaction, which is not experiencing any difficulty. What you are > > reporting status on is something outside that dialog, which seems > > inappropriate. > > > > Mike > > > > > > ------------------------------ > > *From:* Rajeev Narang (ranarang) > > *Sent:* Wednesday, April 12, 2006 10:14 AM > > *To:* Michael Hammer (mhammer); ' sipping@ietf.org' > > *Subject:* RE: [Sipping] SIP Status code for communicating about UA in > > minimalstate- Post active dialog > > > > > > Right, these are B2BUAs. > > > > Actually we need to keep B2BUA1 in knowledge of this specific state at > > B2BUA2 (as mentioned in scenario below). In case network link from B2BU= A1 to > > B2BUA2 is also lost, we need to do some action at B2BUA1. And action at= UA1 > > will be dependent on whether B2BUA2 was fully active or got into some > > minimal state due to its network issues with phone2. > > So was thinking if we can use some standard SIP Status code from B2BUA2 > > to B2BUA1. > > > > Thanks, > > Rajeev > > > > ------------------------------ > > *From:* Michael Hammer (mhammer) > > *Sent:* Wednesday, April 12, 2006 7:10 PM > > *To:* Rajeev Narang (ranarang); sipping@ietf.org > > *Subject:* RE: [Sipping] SIP Status code for communicating about UA in > > minimalstate- Post active dialog > > > > > > You are using B2BUAs are you not? > > > > They should have the intelligence to not involve dialog1 when something > > bad happens to the dialog with phone2. They are separate dialogs, are = they > > not? I assume you are intending to restore the dialog with phone 2 at = some > > point. > > > > I don't see the need to do anything new with dialog1. > > > > Mike > > > > > > ------------------------------ > > *From:* Rajeev Narang (ranarang) > > *Sent:* Wednesday, April 12, 2006 2:44 AM > > *To:* sipping@ietf.org > > *Subject:* [Sipping] SIP Status code for communicating about UA in > > minimalstate- Post active dialog > > > > > > Hi, > > > > Say we have the following scenario:- > > > > phone1-----B2BUA1----dialog1 (active) ----B2BUA2----phone2 > > > > There is a session timers active on the dialog1. Say UA1 is the > > refresher. > > > > An event occurs which results in B2BUA2 loosing network with phone2. > > For our requirement we still want to allow dialog1 to be active with no > > interupption to the periodic session refresh. The B2BUA2 must keep on > > responding to the session refresh. > > > > The *requirement* is that we want to communicate to B2BUA1 about this > > recent situation with B2BUA2 in response to the session refresh. The B2= BUA1 > > must be allowed to take some specific action based on the state of the > > B2BUA2. Also Proxy server between the UA's mustn't tear down the call. > > > > Basically the response code should be such that the session refresh > > procedure must go "on" but remote (refresher) must come to know about t= his > > situation. > > > > From the available SIP status codes the following are choices:- > > 1) 200 OK:- Using this status code would indicate a normal situation, s= o > > doesn't seem appropriate. > > 2) 488 Not Acceptable Here:- Not sure if this will make sense for mid > > call. > > 3) 480 Temporarily Unavailable:- Not sure if this will make sense for > > mid call. > > > > Any suggestions on the SIP Status code so that we can handle it in a > > standard way. > > > > How about creating a new SIP Status code. > > *Say:- "450 Call in Minimal/Preserved State"* > > > > Thanks much, > > Rajeev > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > ------=_Part_35170_5495358.1145079633605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
HI,
We had earlier written a draft about service state of sip entities .Ba= sically it is an event package.
The draft is not telling  exactly about the requirement in the th= read  , but some thing similiar to it . If you have time please go thr= ough it .Currently we have defined only one state ,
Out of service, but we see that we can define  other intermediate= states (dormant ) and another final state inservice .also and  this c= an be extended very easily.
 
(PS :In the examples couple of bugs are there about the usage and impl= ict subscription)

 
With thanks and regards
Mahesh
 
 
 

 
On 4/14/06, = Ranga <rangarao.v@gmail.com<= /a>> wrote: =20
Correct me if I am wrong.

As per the = protocol, SIP responses are sent in response to the request but not generat= ed.

In this perticular case, you could implement this on top of NOTI= FY ( implicit SUBCRIPTION ).=20
 

Ranga
My concern is that the SIP status code is status about the dialog trans= action, which is not experiencing any difficulty.  What you are report= ing status on is something outside that dialog, which seems inappropriate.= =20
 
Mike
 

From: Rajeev Narang (ranarang)
= Sent: Wednesday, April 12, 2006 10:14 AM
To: Michael Hamme= r (mhammer); ' sipping@ietf.org'
Subject: RE: [Sipping] SIP Status code for= communicating about UA in minimalstate- Post active dialog

&= nbsp;
Right= , these are B2BUAs.
 
Actua= lly we need to keep B2BUA1 in knowledge of this specific state at B2BUA2 (a= s mentioned in scenario below). In case network link from B2BUA1 to B2BUA2 = is also lost, we need to do some action at B2BUA1. And action at UA1 will b= e dependent on whether B2BUA2 was fully active or got into some minimal sta= te due to its network issues with phone2.=20
So wa= s thinking if we can use some standard SIP Status code from B2BUA2 to B2BUA= 1.
 
Thank= s,
Rajee= v

From: Michael Hammer (mhammer)
= Sent: Wednesday, April 12, 2006 7:10 PM
To: Rajeev Narang = (ranarang); sipping@ietf.org
Subject: RE: [Sipping] SIP Status code for c= ommunicating about UA in minimalstate- Post active dialog

&nb= sp;
You are using B2BUAs are you not?
 
They should have the intelligence to not involve dialog1 when something= bad happens to the dialog with phone2.  They are separate dialog= s, are they not?  I assume you are intending to restore the dialog wit= h phone 2 at some point.=20
 
I don't see the need to do anything new with dialog1.
 
Mike
 

From: Rajeev Narang (ranarang)
= Sent: Wednesday, April 12, 2006 2:44 AM
To: sipping@ietf.org
Subject: [Sipping] SIP Status code for commu= nicating about UA in minimalstate- Post active dialog

 <= /div>
Hi,
 
Say we have the following scenar= io:-
 
 phone1-----B2BUA1----dialog1 (active) ----B2BUA2----phone2
 
There is a session timers active= on the dialog1. Say UA1 is the refresher.
 
An event occurs which results in= B2BUA2 loosing network with phone2.
For our requirement we still wan= t to allow dialog1 to be active with no interupption to the periodic sessio= n refresh. The B2BUA2 must keep on responding to the session refresh.
 
The requirement= is that we want to communicate to B2BUA1 about this recent situation with = B2BUA2 in response to the session refresh. The B2BUA1 must be allowed to ta= ke some specific action based on the state of the B2BUA2. Also Proxy server= between the UA's mustn't tear down the call.=20
 
Basically the response code shou= ld be such that the session refresh procedure must go "on" b= ut remote (refresher) must come to know about this situation.
 
From the available SIP status co= des the following are choices:-
1) 200 OK:- Using this status co= de would indicate a normal situation, so doesn't seem appropriate.
2) 488 Not Acceptable Here:- Not sure if this will make= sense for mid call.
3) 480 Temporarily Unavailable:-= Not sure if this will make sense for mid call.
 
Any suggestions on the SIP Statu= s code so that we can handle it in a standard way.
 
How about creating a new SIP Sta= tus code.
= Say:- "450 Call in Minimal/Preserved State"
=  
Thanks much,
Rajeev

___________________________________= ____________
Sipping mailing list   https://www1.ietf.org/mailman/listinfo/sipping
This list is for NE= W development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use <= a onclick=3D"return top.js.OpenExtLink(window,event,this)" href=3D"mailto:s= ip@ietf.org" target=3D"_blank">sip@ietf.org for new developments of cor= e SIP=20


 

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


------=_Part_35170_5495358.1145079633605-- --===============0865735233== 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 --===============0865735233==-- From sip-bounces@ietf.org Sat Apr 15 02:23:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUeAR-0008Fk-PK; Sat, 15 Apr 2006 02:21:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUeAQ-0008ET-LZ for sip@ietf.org; Sat, 15 Apr 2006 02:21:58 -0400 Received: from delta.hssblr.co.in ([203.145.155.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUeAM-0001so-Vy for sip@ietf.org; Sat, 15 Apr 2006 02:21:57 -0400 Received: from espion.blr.hss.hns.com (espion.blr.hss.hns.com [10.203.193.21]) by delta.hssblr.co.in (8.11.6/8.11.6) with ESMTP id k3F6Kn210320; Sat, 15 Apr 2006 11:50:50 +0530 In-Reply-To: <20060413023337.M71694@above.net.tw> To: "kkuei" , sip@ietf.org Subject: Re: [Sip] Stateless proxy and reliable transport MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Pocha.Reddy@flextronicssoftware.com Date: Sat, 15 Apr 2006 11:50:44 +0530 X-MIMETrack: S/MIME Sign by Notes Client on P Thejeswara Reddy/BLR/HSS(Release 6.5.1|January 21, 2004) at 04/15/2006 11:50:44 AM, Serialize by Notes Client on P Thejeswara Reddy/BLR/HSS(Release 6.5.1|January 21, 2004) at 04/15/2006 11:50:44 AM, Serialize complete at 04/15/2006 11:50:44 AM, S/MIME Sign failed at 04/15/2006 11:50:44 AM: The cryptographic key was not found, Serialize by Router on Espion/BLR/HSS(Release 6.5.5|November 30, 2005) at 04/15/2006 11:50:13 AM, Serialize complete at 04/15/2006 11:50:13 AM X-Spam-Score: 0.3 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 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="===============1267683871==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1267683871== Content-Type: multipart/alternative; boundary="=_alternative 0022DB9265257151_=" This is a multipart message in MIME format. --=_alternative 0022DB9265257151_= Content-Type: text/plain; charset="US-ASCII" Is Stateless Proxy converting the request to UDP from TCP?, is it possible ?---- as per RFC 3261 "kkuei" 04/13/2006 08:06 AM To sip@ietf.org cc sip@ietf.org Subject Re: [Sip] Stateless proxy and reliable transport Hi Dean, Thanks for your reply. But rfc3261 section 17.1.1.1 said: INVITE client transaction: "The request is not retransmitted over reliable transports" You said: A responsible for retransmission Which layer will be responsible for retransmission?? Cheers, -- Kevin Kuei On Wed, 12 Apr 2006 10:08:41 -0500, Dean Willis wrote > On Apr 12, 2006, at 5:17 AM, kkuei wrote: > > > Dear all, > > > > This may be a stupid question, but I can't find the answer in > > RFC3261 and > > archive. > > > > Here is the story: > > > > A <-----> Stateless Proxy <------> Proxy <-------> B > > > > Assume the transport between A and stateless proxy is reliable (TCP). > > > > If A send INVITE to stateless proxy, it will not received 100 > > provisional > > response. Then, stateless proxy tries to relay it to proxy. If the > > packet > > dropped.. A will not do retransmite right?? > > > > Then the transaction will be timeout... Is it the correct behavior?? > > > > A is still responsible for retransmission, whether or not it > receives a provisional response. > > This would be required even if all the proxies were stateful and all > the links reliable, because there's always a chance that proxy will > simply drop a request or fail in some other way. > > -- > Dean -- Kevin Kuei _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip *********************** FSS-Restricted *********************** --=_alternative 0022DB9265257151_= Content-Type: text/html; charset="US-ASCII"
Is Stateless Proxy converting the request to UDP from TCP?, is it possible ?---- as per RFC 3261


"kkuei" <kkuei@above.net.tw>

04/13/2006 08:06 AM

To
sip@ietf.org
cc
sip@ietf.org
Subject
Re: [Sip] Stateless proxy and reliable transport





Hi Dean,

Thanks for your reply. But rfc3261 section 17.1.1.1 said:

INVITE client transaction:
"The request is not retransmitted over reliable transports"

You said:
A responsible for retransmission

Which layer will be responsible for retransmission??


Cheers,

--
Kevin Kuei

On Wed, 12 Apr 2006 10:08:41 -0500, Dean Willis wrote
> On Apr 12, 2006, at 5:17 AM, kkuei wrote:
>
> > Dear all,
> >
> > This may be a stupid question, but I can't find the answer in  
> > RFC3261 and
> > archive.
> >
> > Here is the story:
> >
> > A <-----> Stateless Proxy <------> Proxy <------->  B
> >
> > Assume the transport between A and stateless proxy is reliable (TCP).
> >
> > If A send INVITE to stateless proxy, it will not received 100  
> > provisional
> > response. Then, stateless proxy tries to relay it to proxy. If the  
> > packet
> > dropped.. A will not do retransmite right??
> >
> > Then the transaction will be timeout... Is it the correct behavior??
> >
>
> A is still responsible for retransmission, whether or not it
> receives  a provisional response.
>
> This would be required even if all the proxies were stateful and all
>  the links reliable, because there's always a chance that proxy will
>  simply drop a request or fail in some other way.
>
> --
> Dean


--
Kevin Kuei


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


***********************  FSS-Restricted   *********************** --=_alternative 0022DB9265257151_=-- --===============1267683871== 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 --===============1267683871==-- From sip-bounces@ietf.org Mon Apr 17 12:05:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVWC1-0005JU-Uc; Mon, 17 Apr 2006 12:03:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVWBz-0005IH-UX for sip@ietf.org; Mon, 17 Apr 2006 12:03:11 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVWBz-0005I7-L5 for sip@ietf.org; Mon, 17 Apr 2006 12:03:11 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 17 Apr 2006 09:03:11 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,125,1144047600"; d="scan'208"; a="26033144:sNHT72192972" 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 k3HG37vT004161; Mon, 17 Apr 2006 12:03: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, 17 Apr 2006 12:03:10 -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, 17 Apr 2006 12:03:10 -0400 Message-ID: <4443BC3C.4080109@cisco.com> Date: Mon, 17 Apr 2006 12:03:08 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] offer answer References: <9d77d7060604120617v5d7a8825k3675bea29546ff33@mail.gmail.com> <000601c65e7d$3875e050$7902a8c0@NeelLT> <9d77d7060604130448v49cc374fs2f2829558a9ac29b@mail.gmail.com> <443ECAF0.3000403@cisco.com> In-Reply-To: <443ECAF0.3000403@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Apr 2006 16:03:10.0347 (UTC) FILETIME=[6C6DE5B0:01C66238] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: sip@ietf.org, balasubramanian_neelakantan@quintum.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 just noticed I made a significant omission in what I posted earlier. See correction inline. Paul Paul Kyzivat wrote: > > > Xiang Ting wrote: > >> Hi Bala, >> >> On 4/13/06, Bala Neelakantan wrote: >> >>> Xiang, >>> >>> If the answerer needs to enforce extra media formats, then it should >>> start a >>> new Offer after the current offer/answer negotiation is completed. >>> >> >> That is to say the answerer can not add extra media format information >> in this particular transaction, isn't it? > > > The answerer may add them, but they may not be used. However they can > serve as hints for the next offer/answer cycle. > > In general with offer/answer it seems to work out best if each side > keeps stating what it wants, censoring itself based on what it thinks > the other end wants. I meant to say: In general with offer/answer it seems to work out best if each side keeps stating what it wants, RATHER THAN censoring itself based on what it thinks the other end wants. > This isn't always possible - there are rules that > must be followed that don't always allow this. But its still good > policy when applied to the extent allowed. > > Paul > >>> Thanks, >>> Neel >>> >>> >>> -----Original Message----- >>> From: Xiang Ting [mailto:x.victoria@gmail.com] >>> Sent: Wednesday, April 12, 2006 8:17 AM >>> To: balasubramanian_neelakantan@quintum.com >>> Cc: Mahesh Govind; sip@ietf.org >>> Subject: Re: [Sip] offer answer >>> >>> On 4/11/06, Bala Neelakantan wrote: >>> >>>> >>>> >>>> See Section 6.1, page 10. >>>> >>>> The stream MAY indicate additional media formats, not listed in the >>>> corresponding stream in the offer, that the answerer is willing to >>>> send or receive (of course, it will not be able to send them at this >>>> time, since it was not listed in the offer). For streams marked as >>>> >>> >>> Then at what time it will be able to send media descreiption with >>> additional >>> media formats? >>> >>> Thank you. >>> >>>> So, the answer can have additional media formats in the media line.. >>>> >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Neel >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >>> >>> >>> Mahesh >>> >>>> Govind >>>> Sent: Monday, April 10, 2006 9:08 AM >>>> To: sip@ietf.org >>>> Subject: [Sip] offer answer >>>> >>>> >>>> >>>> >>>> HI, >>>> >>>> >>>> >>>> >>>> >>>> I have a doubt . >>>> >>>> >>>> >>>> >>>> >>>> If an offer is having a media line >>>> >>>> >>>> m=audio 4000 RTP/AVP 1 2 3 >>>> >>>> >>>> >>>> >>>> >>>> can an answer contain , >>>> >>>> >>>> >>>> >>>> >>>> If an offer is having a media line >>>> >>>> >>>> m=audio 4000 RTP/AVP 1 2 3 5 >>>> >>>> >>>> >>>> >>>> >>>> With thanks and regards >>>> >>>> >>>> Mahesh >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list >>>> https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on >>>> current sip >>>> Use sipping@ietf.org for new developments on the application of sip >>>> >>>> >>> >>> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 17 16:49:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVad0-0007FE-VJ; Mon, 17 Apr 2006 16:47:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVad0-0007F9-0q for sip@ietf.org; Mon, 17 Apr 2006 16:47:22 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVacz-0004ON-O3 for sip@ietf.org; Mon, 17 Apr 2006 16:47:21 -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 k3HKlHY08240; Mon, 17 Apr 2006 16:47:17 -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 Date: Mon, 17 Apr 2006 15:46:27 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF08C5EACB@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-audet-sip-sips-guidelines-00.txt: use of transport=tls Thread-Index: AcZc4LW7OySEKKGfSS2UuvkP+cXe8AFe/qIA From: "Francois Audet" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: SIP IETF Subject: [Sip] draft-audet-sip-sips-guidelines-00.txt: use of transport=tls X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Paul, Thanks for your comments. I'm starting to digest them. Rather than copy the whole list of comments, I'll deal with individual comments separately. OPEN ISSUE: use of "transport=3Dtls". > > RFC 3261 makes it clear that the use of the "transport=3Dtls" URI > > transport parameter in SIPS or SIP URIs has been deprecated. > > However, it has not been eliminated from the ABNF in=20 > > section 25 of RFC 3261. >=20 > That isn't so clear to me. It seems to clearly ban this=20 > parameter in a=20 > SIPS URI, but I don't see the words as banning it in a SIP URI. >=20 > The value in using it, as mentioned above, is that it means a TLS hop=20 > can be used for either insecure requests, but that the URI=20 > could also be=20 > upgraded to SIPS in order that it be permissible in a=20 > transaction that=20 > is using SIPS. This seems necessary to avoid two separate connections=20 > when using -outbound- for nat traversal. I believe that we have a different opinion of how this should work. My understanding is that transport=3Dtls is deprecated, and it works the following way: - If a UA wants to indicate to the registrar that it supports both sip=20 and sips, and TCP and TLS, then it sends the following: - AOR (To field) =3D=3D sip=20 - 2 contacts are included: sips and sip (with q value for prefence) That explicitely lists both a sips and sip contact (as described in section 4.2 of my draft). I believe that what you are proposing is instead that to indicate support for both TCP and TLS transport, one should do: - AOR (To field) =3D=3D sip - 1 contact: sip with transport=3Dtls. With my proposal, one does not need a "new option tag". The idea is=20 that sip AOR is always "upgradable" to sips (but not the other way around), and that the Contact list in the registration ALWAYS include all the possible contacts, including both sip and sips if both are supported. In other words, the concept of "upgrading" from sip to sips is only=20 applicable to AORs (not to Contacts or other fields). Seems to me to=20 be clearer. It also avoids the sctp problem. I also believes that it doesn't have the problem or requiring 2 connections for sip-outbound. You would send the REGISTER using TLS in this case, but you would be prepared to receive incoming requests on this connection using either TLS or TCP. Am I misunderstanding what you are proposing? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 17 16:58:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVamO-0000cl-5r; Mon, 17 Apr 2006 16:57:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVamM-0000cg-E4 for sip@ietf.org; Mon, 17 Apr 2006 16:57:02 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVamM-0004ni-6T for sip@ietf.org; Mon, 17 Apr 2006 16:57:02 -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 k3HKuwY10929; Mon, 17 Apr 2006 16:56: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 Date: Mon, 17 Apr 2006 15:56:26 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF08C5EB07@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-audet-sip-sips-guidelines-00.txt Thread-Index: AcZc4LW7OySEKKGfSS2UuvkP+cXe8AFgJUlw From: "Francois Audet" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: SIP IETF Subject: [Sip] RE: I-D ACTION:draft-audet-sip-sips-guidelines-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 > > OPEN ISSUE: RFC 3261 is not very clear what a UAS is to do if it > > doesn't support SIPS and TLS, in which case the=20 > previous paragraph > > obviously can not apply. Shoud we state that the UAS=20 > MUST reject > > the request with response code 416? In that case,=20 > should we say > > that the UAC MUST NOT re-attempt the request with a SIP URI by > > automatically replacing the SIPS scheme with a SIP scheme? >=20 > The 416 seems right to me. >=20 > But I see no reason to forbid the UAC from retrying with SIP. This=20 > should be a policy issue for it. What is essential is that it=20 > indicate=20 > to its user if the connection is secure or not. (This could=20 > get complex,=20 > since security of signaling and media are separate things. So=20 > you might=20 > have multiple lock icons in the UI.) OK. I agree. I'll change the text accordingly. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 17 17:15:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVb2k-0008Qn-AF; Mon, 17 Apr 2006 17:13:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVb2j-0008Qi-Gb for sip@ietf.org; Mon, 17 Apr 2006 17:13:57 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVb2i-0005h2-8d for sip@ietf.org; Mon, 17 Apr 2006 17:13:57 -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 k3HLDkt02724; Mon, 17 Apr 2006 17:13:46 -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 Date: Mon, 17 Apr 2006 16:13:44 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF08C5EB74@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-audet-sip-sips-guidelines-00.txt Thread-Index: AcZc4LW7OySEKKGfSS2UuvkP+cXe8AFguAtg From: "Francois Audet" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: SIP IETF Subject: [Sip] RE: I-D ACTION:draft-audet-sip-sips-guidelines-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 > > When a target refresh occurs within a dialog (e.g., re-INVITE, > > UPDATE), the UAC SHOULD include a Contact header with a=20 > SIPS URI if > > the original request creating the dialog was sent over=20 > TLS, and the > > Request-URI contained a SIPS URI. >=20 > I don't see why this should be forbidden in a *request*,=20 > where it may be=20 > refused. It is problematic in a response, where it can't be refused.=20 > Changing the level of security mid-dialog could be useful, at=20 > least in=20 > the case of 3pcc. It may reflect a transfer where the new partner=20 > doesn't have the same capabilities or requirements. OTOH, making the=20 > change in a response is also needed for many useful 3pcc flows. OK. I'll align the wording with RFC 3261 section 12.2.1.1 which=20 acknowledges that there might be reasons to change 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 Mon Apr 17 17:26:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVbDX-0002Qt-Sg; Mon, 17 Apr 2006 17:25:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVbDW-0002Qo-Sh for sip@ietf.org; Mon, 17 Apr 2006 17:25:06 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVbDW-0006N9-Hi for sip@ietf.org; Mon, 17 Apr 2006 17:25:06 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 17 Apr 2006 14:25:06 -0700 X-IronPort-AV: i="4.04,127,1144047600"; d="scan'208"; a="269167300:sNHT35940200" 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 k3HLP5Yg024113; Mon, 17 Apr 2006 14:25:05 -0700 (PDT) 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, 17 Apr 2006 17:25:05 -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, 17 Apr 2006 17:25:04 -0400 Message-ID: <444407B0.5010508@cisco.com> Date: Mon, 17 Apr 2006 17:25:04 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet References: <1ECE0EB50388174790F9694F77522CCF08C5EACB@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF08C5EACB@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Apr 2006 21:25:04.0827 (UTC) FILETIME=[64C1A8B0:01C66265] X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: SIP IETF Subject: [Sip] Re: draft-audet-sip-sips-guidelines-00.txt: use of transport=tls X-BeenThere: sip@ietf.org X-Mailman-Version: 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: > Hi Paul, > > Thanks for your comments. I'm starting to digest them. > > Rather than copy the whole list of comments, I'll deal with > individual comments separately. > > OPEN ISSUE: use of "transport=tls". > > > >>> RFC 3261 makes it clear that the use of the "transport=tls" URI >>> transport parameter in SIPS or SIP URIs has been deprecated. >>> However, it has not been eliminated from the ABNF in >>> section 25 of RFC 3261. >> >>That isn't so clear to me. It seems to clearly ban this >>parameter in a >>SIPS URI, but I don't see the words as banning it in a SIP URI. >> >>The value in using it, as mentioned above, is that it means a TLS hop >>can be used for either insecure requests, but that the URI >>could also be >>upgraded to SIPS in order that it be permissible in a >>transaction that >>is using SIPS. This seems necessary to avoid two separate connections >>when using -outbound- for nat traversal. > > > I believe that we have a different opinion of how this should work. Note that I am not at all confident that I am on firm ground with what I am suggesting. In a way it is hopeful thinking. More below. > My understanding is that transport=tls is deprecated, and it works the > following way: > > - If a UA wants to indicate to the registrar that it supports both sip > and sips, and TCP and TLS, then it sends the following: > - AOR (To field) == sip > - 2 contacts are included: sips and sip (with q value for > prefence) > That explicitely lists both a sips and sip contact (as described in > section > 4.2 of my draft). > > I believe that what you are proposing is instead that to indicate > support for > both TCP and TLS transport, one should do: > - AOR (To field) == sip > - 1 contact: sip with transport=tls. More or less. As long as the R-URI is sips, its not clear to me it matters whether the To uri is sip or sips. > With my proposal, one does not need a "new option tag". The idea is > that sip AOR is always "upgradable" to sips (but not the other way > around), > and that the Contact list in the registration ALWAYS include all the > possible > contacts, including both sip and sips if both are supported. > > In other words, the concept of "upgrading" from sip to sips is only > applicable to AORs (not to Contacts or other fields). My thinking was that sips can only be used with e2e hop by hop security. But a TLS connection can be used either as one hop of an e2e hop by hop secure session, or as part of a session that has insecure hops and so is ineligible for sips. A proxy would be able to upgrade a sip uri with transport=tls to sips when it knew all other hops are secured. > Seems to me to > be clearer. It also avoids the sctp problem. I don't know about clearer. There are probably other solutions to the sctp problem. > I also believes that it > doesn't have the problem or requiring 2 connections for sip-outbound. That is a big issue to me. I'm not sure I follow. > You would send the REGISTER using TLS in this case, but you would be > prepared to receive incoming requests on this connection using either > TLS or TCP. So when using sip, the messages over the connection would not be encrypted, but when using sips they would? Can you do that with TLS? I'm no expert, but I thought once you establish a connection, it starts out TCP but if you do the TLS handshake then it is all TLS from then on. *If* you can register these two contacts, one sip and one sips, and they can share the same connection, then I am *less* concerned. I still suspect it will present complexities and problems. Maybe Cullen will be able to comment on the impact to outbound. > Am I misunderstanding what you are proposing? No, you seem to get it. 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 Apr 17 17:35:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVbM7-0005G0-Bv; Mon, 17 Apr 2006 17:33:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVbM5-0005Fv-Ko for sip@ietf.org; Mon, 17 Apr 2006 17:33:57 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVbM4-0006mc-CO for sip@ietf.org; Mon, 17 Apr 2006 17:33:57 -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 k3HLTDG09247; Mon, 17 Apr 2006 17:29:13 -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 Date: Mon, 17 Apr 2006 16:33:50 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF08C5EBE1@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-audet-sip-sips-guidelines-00.txt: use of transport=tls Thread-Index: AcZiZWlXgQ/5BI/xShCkuJHBt97kqgAAMPqA From: "Francois Audet" To: "Paul Kyzivat" , "Cullen Jennings" X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: SIP IETF Subject: [Sip] RE: draft-audet-sip-sips-guidelines-00.txt: use of transport=tls X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yeah, let's make sure Cullen is reading this... > > You would send the REGISTER using TLS in this case, but you=20 > would be=20 > > prepared to receive incoming requests on this connection=20 > using either=20 > > TLS or TCP. >=20 > So when using sip, the messages over the connection would not be=20 > encrypted, but when using sips they would? >=20 > Can you do that with TLS? I'm no expert, but I thought once you=20 > establish a connection, it starts out TCP but if you do the TLS=20 > handshake then it is all TLS from then on. I'm not sure either. Cullen? The alternative I guess is for using an Outbound proxy, and then re-using the existing TLS connection that is already there (created by the REGISTER). This would mean that when using Outbound and registering a sips=20 contact, you'd always be using TLS on the last hop. > *If* you can register these two contacts, one sip and one=20 > sips, and they=20 > can share the same connection, then I am *less* concerned. I still=20 > suspect it will present complexities and problems. >=20 > Maybe Cullen will be able to comment on the impact to outbound. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 17 18:04:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVbnu-0005lW-Ro; Mon, 17 Apr 2006 18:02:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVbnu-0005lI-8h for sip@ietf.org; Mon, 17 Apr 2006 18:02:42 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVbnt-0008NK-RY for sip@ietf.org; Mon, 17 Apr 2006 18:02:42 -0400 Received: (qmail 1312 invoked by uid 0); 17 Apr 2006 22:02:39 -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 Apr 2006 22:02:39 -0000 Message-ID: <00c901c6626a$a42e21e0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Francois Audet" , "Paul Kyzivat" , "Cullen Jennings" References: <1ECE0EB50388174790F9694F77522CCF08C5EBE1@zrc2hxm0.corp.nortel.com> Subject: Re: [Sip] RE: draft-audet-sip-sips-guidelines-00.txt: use oftransport=tls Date: Tue, 18 Apr 2006 00:02:38 +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: c0bedb65cce30976f0bf60a0a39edea4 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 Francois, Implementation wise you probably could use a single TCP connection for both encrypted and unencrypted data ( i.e. SSL records and regular data, much like you can do SIP and STUN over the same TCP connection). I doubt you'll find any SSL implementations that support this currently, main reason is probably that you SHOULD NOT want such a thing ... You can have a NULL cipher, but you'd still get SSL records on the TCP line. In other words, this would not be equivalent with what you currently get using the "sip:" scheme This triggered me though - is there any guidance on the mapping of a SIP message to SSL records? a one-to-one mapping seems beneficial for detection of message boundaries, but this would work only if it were standardized. Regards, Jeroen ----- Original Message ----- From: "Francois Audet" To: "Paul Kyzivat" ; "Cullen Jennings" Cc: "SIP IETF" Sent: Monday, April 17, 2006 11:33 PM Subject: [Sip] RE: draft-audet-sip-sips-guidelines-00.txt: use oftransport=tls Yeah, let's make sure Cullen is reading this... > > You would send the REGISTER using TLS in this case, but you > would be > > prepared to receive incoming requests on this connection > using either > > TLS or TCP. > > So when using sip, the messages over the connection would not be > encrypted, but when using sips they would? > > Can you do that with TLS? I'm no expert, but I thought once you > establish a connection, it starts out TCP but if you do the TLS > handshake then it is all TLS from then on. I'm not sure either. Cullen? The alternative I guess is for using an Outbound proxy, and then re-using the existing TLS connection that is already there (created by the REGISTER). This would mean that when using Outbound and registering a sips contact, you'd always be using TLS on the last hop. > *If* you can register these two contacts, one sip and one > sips, and they > can share the same connection, then I am *less* concerned. I still > suspect it will present complexities and problems. > > Maybe Cullen will be able to comment on the impact to outbound. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 18 08:10:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVp0A-0003Vg-Mu; Tue, 18 Apr 2006 08:08:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVp08-0003Vb-SS for sip@ietf.org; Tue, 18 Apr 2006 08:08:12 -0400 Received: from smtp3.clb.oleane.net ([213.56.31.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVp07-00023a-Fl for sip@ietf.org; Tue, 18 Apr 2006 08:08:12 -0400 Received: from Pavillonquatre ([194.3.133.88]) by smtp3.clb.oleane.net with ESMTP id k3IC8AOw012770 for ; Tue, 18 Apr 2006 14:08:10 +0200 Message-Id: <200604181208.k3IC8AOw012770@smtp3.clb.oleane.net> From: "Chantal Ladouce" To: Date: Tue, 18 Apr 2006 14:07:07 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZi4JzgxAhCKN2nQKyT+iWaA50vpQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Subject: [Sip] Mobile TV World Congress - Paris - France X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1491187432==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1491187432== Content-Type: multipart/alternative; boundary="----=_NextPart_000_05A4_01C662F1.60D91E40" This is a multi-part message in MIME format. ------=_NextPart_000_05A4_01C662F1.60D91E40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The Mobile TV World Congress, will be held in Paris January 23 to 26, together with the worldwide leader event TVoDSL 2007. Carriers, content providers and equipment vendors will address technical issues, describe the standardization process and discuss business and content delivery models. A call for proposals is online at: http://www.upperside.fr/mobiletv2007/mobiletv2007intro.htm ------=_NextPart_000_05A4_01C662F1.60D91E40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The Mobile TV World = Congress, will be held in Paris January 23 to 26, together with the worldwide leader event = TVoDSL = 2007.

Carriers, content providers and equipment = vendors will address technical issues, describe the standardization process and = discuss business and content delivery models.

 

A call for proposals is online = at:

http://www.upperside.fr/mobiletv2007/mobiletv2007intro.htm

 

------=_NextPart_000_05A4_01C662F1.60D91E40-- --===============1491187432== 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 --===============1491187432==-- From sip-bounces@ietf.org Wed Apr 19 06:40:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWA45-0001I6-JT; Wed, 19 Apr 2006 06:37:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWA43-0001EP-PI for sip@ietf.org; Wed, 19 Apr 2006 06:37:39 -0400 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWA42-0002Nx-AF for sip@ietf.org; Wed, 19 Apr 2006 06:37:39 -0400 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id k3JAbbn21317 for ; Wed, 19 Apr 2006 12:37:37 +0200 (MEST) Received: from heisenberg.fokus.fraunhofer.de ([10.147.9.232]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Apr 2006 12:37:37 +0200 Received: from [10.147.65.87] ([10.147.65.87]) by heisenberg.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Apr 2006 12:37:36 +0200 Message-ID: <444612F0.2090909@fokus.fraunhofer.de> Date: Wed, 19 Apr 2006 12:37:36 +0200 From: Sven Ehlert Organization: Fraunhofer FOKUS User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050921 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------080908050402060308030002" X-OriginalArrivalTime: 19 Apr 2006 10:37:36.0612 (UTC) FILETIME=[463DFA40:01C6639D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Subject: [Sip] Third VoIP Security Workshop, Program Available X-BeenThere: sip@ietf.org X-Mailman-Version: 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. --------------080908050402060308030002 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mailhub.fokus.fraunhofer.de id k3JAbbn21317 Third Annual VoIP Security Workshop In Cooperation with ACM SIGCOMM Berlin, Germany 01, 02 June 2006 www.iptel.org/voipsecurity Program Available and Registration open! This security workshop is the third following successful events in Dallas 2004 and Washington 2005. The workshop addresses the challenges, advanced technologies and regulations for providing secure VoIP services in the Internet as well as in third generation networks. The 2006 workshop will extend the scope of VoIP security to IMS services and present the latest advances in denial of service and SPIT detection and protection mechanisms. The format of the workshop is based on two-day single-track sessions, with presentations of invited and regular papers from academia and industry. The program is available at http://www.iptel.org/voipsecurity/workshop/program_1st_june_2006.php The workshop features a keynote speech from Virgil D. Gligor, University of Maryland, USA Session 1: Standardization and Regulation Session 2: New Approaches for SPIT and Denial of Service protection Session 3: Secure Identification and Media Session 4: Loadbalancing and media recording Session 5: VoIP Security in the Industry General Chair: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Radu Popescu-Zeletin Fraunhofer Fokus Program Chairs: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dorgham Sisalem Tekelec Ram Dantu University of North Texas Henning Schulzrinne Columbia University Local Organization Chair: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sven Ehlert Fraunhofer Fokus Technical Program Committee =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ralf Ackermann TU Darmstadt Hossam Afifi INT Evry Elisa Bertino Purdue University George Carle T=FCbingen University Jasson Casey Alcatel Ram Dantu University of North Texas Sven Ehlert Fraunhofer Fokus Sonia Fahmy Purdue University Dipak Ghosal University of California Davis G=FCnter M=FCller University of Freiburg Saverio Niccolini NEC Labs Europe J=F6rg Ott Helsinki University of Technolo= gy Ozgur Gurleyen Vodafone Basavaraj Patil Nokia Neeli Rashmi Prasad University of Aalborg Pradeep Samudra Samsung Peter Schoo DoCoMo Euro-Labs Henning Schulzrinne Columbia University Dorgham Sisalem Tekelec Jeff Smith DHS Burkhard Stiller University of Zurich and ETH Zuri= ch Duminda Wijesekeara George Mason University --------------080908050402060308030002 Content-Type: text/x-vcard; charset=utf-8; name="ehlert.vcf" Content-Disposition: attachment; filename="ehlert.vcf" Content-Transfer-Encoding: 7bit begin:vcard fn:Sven Ehlert n:Ehlert;Sven org:NGNI;Fraunhofer FOKUS adr:;;Kaiserin-Augusta-Allee 31;Berlin;;10589;Germany email;internet:ehlert@fokus.fraunhofer.de tel;work:+49-30-3463-7378 tel;fax:+49-30-3463-8000 url:http://www.fokus.fraunhofer.de version:2.1 end:vcard --------------080908050402060308030002 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 --------------080908050402060308030002-- From sip-bounces@ietf.org Wed Apr 19 13:43:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWGfM-0001yA-A1; Wed, 19 Apr 2006 13:40:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWGfK-0001wd-QV for sip@ietf.org; Wed, 19 Apr 2006 13:40:34 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWGaG-00062d-0Q for sip@ietf.org; Wed, 19 Apr 2006 13:35:21 -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 k3JHZGd08745; Wed, 19 Apr 2006 13:35:17 -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: Wed, 19 Apr 2006 12:34:59 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF08CFDD0B@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP Identity and RFC 3893 Thread-Index: AcZjnWn9uPfoSxLXSg+sbzj0NI0BTQAODYZg From: "Francois Audet" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [Sip] SIP Identity and RFC 3893 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jon, Does sip-identity-06 make RFC 3893 (the AIB format for S/MIME) obsolete? Sip-identity is remarkably silent about RFC 3893. It sorts of hints in = the=20 introduction that sip-identity is an alternative to S/MIME, but it is = not very specific. The changelog (which will be removed upon publication) sheds a bit of = light on the history behind this (i.e., in -01 we switched from AIB to new = header). Should RFC 3893 (which is currently "Standards Track") be deprecated=20 (moved to historical or whatever)? I'm kind of worried about developper=20 confusion between sip-identity and RFC 3893. Also, to add a little more confusion to this, there is "normative" = reference to RFC 3893 in sip-identity which, it seems to me, should be = "informative". ---- 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 Thu Apr 20 01:46:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWRxa-0005D4-OR; Thu, 20 Apr 2006 01:44:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWRxY-0005Cw-S7 for sip@ietf.org; Thu, 20 Apr 2006 01:44:08 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWRxS-0000RW-5l for sip@ietf.org; Thu, 20 Apr 2006 01:44:08 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 961944F0002; Thu, 20 Apr 2006 07:44:00 +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, 20 Apr 2006 07:44:00 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 07:44:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt Date: Thu, 20 Apr 2006 07:43:59 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1D51@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt Thread-Index: AcZeQ13rOpbxRGG5SiKqakanilhl2AF+cEwg From: "Christer Holmberg \(JO/LMF\)" To: "Jonathan Rosenberg" X-OriginalArrivalTime: 20 Apr 2006 05:44:00.0129 (UTC) FILETIME=[6C69BF10:01C6643D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: sip@ietf.org, Robert Sparks , Keith Drage , Robert Sparks , 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, So, all we want to say with this draft is: "You SHOULD implement this optional RFC3261 feature"? Regards, Christer =20 -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 Sent: 12. huhtikuuta 2006 18:11 To: Christer Holmberg (JO/LMF) Cc: Robert Sparks; sip@ietf.org; Robert Sparks; Keith Drage; Dean Willis Subject: Re: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt Christer Holmberg (JO/LMF) wrote: > So, maybe you could say: "MUST ensure, using a standards lopp=20 > detection mechanism, that a request is not looping through this proxy. > RFC 3261 defines a mechanism in chapter x.x.x.. Other standardized=20 > mechansims for loop detecting MAY be used instead, or in addition, to=20 > the one defined in RFC 3261.". >=20 > Or something like that... I don't like that wording. I think its important to give clear guidance on what an implementor should do. The clear guidance is to implement the loop detection mechanism in RFC3261. -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 From sip-bounces@ietf.org Thu Apr 20 01:48:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWS0F-0006Kx-JS; Thu, 20 Apr 2006 01:46:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWS0D-0006I2-N1 for sip@ietf.org; Thu, 20 Apr 2006 01:46:53 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWS0C-0000XK-5w for sip@ietf.org; Thu, 20 Apr 2006 01:46:53 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5FE151B2; Thu, 20 Apr 2006 07:46:51 +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, 20 Apr 2006 07:46:51 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 07:46:50 +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] Question on Service Route Discovery Procedure duringRegistration Date: Thu, 20 Apr 2006 07:46:50 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1D52@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question on Service Route Discovery Procedure duringRegistration Thread-Index: AcZcpZqjGexDpTnZS/Ghbs1gmuKj9QAtMHow From: "Christer Holmberg \(JO/LMF\)" To: "Dean Willis" X-OriginalArrivalTime: 20 Apr 2006 05:46:50.0647 (UTC) FILETIME=[D20CBA70:01C6643D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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,=20 >>Currently the text says that the UA MAY use the Service-Route e.g. to=20 >>create a route for future requests. >>=20 >>Now, if we are going to add an option-tag (to be used by the UA in the >>Require/Supported header) I think we should also say that the UA SHALL >>use the Service-Route for future request (why would it otherwise ask=20 >>for it?), and also HOW the route is created. 24.229 defines how IMS=20 >>UEs create the route, so similar text is needed for generic UA behavior. >Why must the US a route all requests through this domain? What if it has multiple registrations? Ok, in that case the UA could of course choose. But, I guess the most important thing is the second: IF the UA uses the Service-Route, it should be specified how the route is created. >>2. Registrar processing of Path >=20 >>I think we should also take Jonathan's draft, >>draft-rosenberg-sip-route-construct-00, into consideration, which allows >>a registrar to build a Service-Route set based on the received Path >>headers. >Lovely idea, and 3608 suggests it as a possibility. Doesn't work for IMS=20 >AFAIk, so it can't be a MUST. I need to check that. But, is there something special you have in mind why it wouldn't work with IMS? 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 Apr 20 02:59:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWT6L-0000AB-Q5; Thu, 20 Apr 2006 02:57:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWT6K-0000A6-5S for sip@ietf.org; Thu, 20 Apr 2006 02:57:16 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWT6I-0003wy-QG for sip@ietf.org; Thu, 20 Apr 2006 02:57:16 -0400 Received: from [203.178.157.234] (203-178-157-234.ip.sipit.net [203.178.157.234] (may be forged)) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.4) with ESMTP id k3K6v3RQ020664 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 20 Apr 2006 01:57:05 -0500 (CDT) (envelope-from rjsparks@estacado.net) In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1D51@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1D51@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <70E588EE-1A35-41C5-AAC0-51408558444B@estacado.net> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt Date: Thu, 20 Apr 2006 15:56:56 +0900 To: "Christer Holmberg \(JO/LMF\)" X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: sip@ietf.org, Robert Sparks , 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 How do you get that from this conversation? What we want to say is you MUST perform loop detection if you are forking to locations that might loop. You SHOULD use the 3261 algorithm to do this detection. That's stronger and more specific than simply saying you SHOULD use 3261 loop detection in a vacuum. RjS On 20-Apr-06, at 2:43 PM, Christer Holmberg ((JO/LMF)) wrote: > > Hi, > > So, all we want to say with this draft is: "You SHOULD implement this > optional RFC3261 feature"? > > Regards, > > Christer > > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: 12. huhtikuuta 2006 18:11 > To: Christer Holmberg (JO/LMF) > Cc: Robert Sparks; sip@ietf.org; Robert Sparks; Keith Drage; Dean > Willis > Subject: Re: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt > > > > Christer Holmberg (JO/LMF) wrote: > > >> So, maybe you could say: "MUST ensure, using a standards lopp >> detection mechanism, that a request is not looping through this >> proxy. > >> RFC 3261 defines a mechanism in chapter x.x.x.. Other standardized >> mechansims for loop detecting MAY be used instead, or in addition, to >> the one defined in RFC 3261.". >> >> Or something like that... > > I don't like that wording. I think its important to give clear > guidance > on what an implementor should do. The clear guidance is to > implement the > loop detection mechanism in RFC3261. > > -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 Apr 20 03:07:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWTDz-0002gN-Bl; Thu, 20 Apr 2006 03:05:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWTDx-0002gI-TZ for sip@ietf.org; Thu, 20 Apr 2006 03:05:09 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWTDt-0004K4-Tm for sip@ietf.org; Thu, 20 Apr 2006 03:05:09 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 06C0EE3E; Thu, 20 Apr 2006 09:05:05 +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, 20 Apr 2006 09:05:04 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 09:05: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] WGLC for draft-ietf-sip-fork-loop-fix-01.txt Date: Thu, 20 Apr 2006 09:05:03 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1D54@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt Thread-Index: AcZkR6iIA/NWIXxnSvuLb1tsHNBfCgAABfLQ From: "Christer Holmberg \(JO/LMF\)" To: "Robert Sparks" X-OriginalArrivalTime: 20 Apr 2006 07:05:04.0192 (UTC) FILETIME=[BF9EDC00:01C66448] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: sip@ietf.org, Robert Sparks , 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 Hi Robert, What you say is pretty much what I said in my proposed text (see below), that a proxy "MUST ensure, using a standards lopp=20 detection mechanism, that a request is not looping through this proxy.". After that I said that one mechanism is defined in RFC3261, but other mechanisms can also be used. The reason for that was that the text would be "valid" also after other mechanisms have been defined. Do we want to say that a proxy SHOULD use the 3261 mechanism, EVEN if other mechanims exist? Regards, Christer -----Original Message----- From: Robert Sparks [mailto:rjsparks@estacado.net]=20 Sent: 20. huhtikuuta 2006 9:57 To: Christer Holmberg (JO/LMF) Cc: Jonathan Rosenberg; sip@ietf.org; Robert Sparks; Keith Drage; Dean Willis Subject: Re: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt How do you get that from this conversation? What we want to say is you MUST perform loop detection if you are forking to locations that might loop. You SHOULD use the 3261 algorithm to do this detection. That's stronger and more specific than simply saying you SHOULD use 3261 loop detection in a vacuum. RjS On 20-Apr-06, at 2:43 PM, Christer Holmberg ((JO/LMF)) wrote: > > Hi, > > So, all we want to say with this draft is: "You SHOULD implement this=20 > optional RFC3261 feature"? > > Regards, > > Christer > > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: 12. huhtikuuta 2006 18:11 > To: Christer Holmberg (JO/LMF) > Cc: Robert Sparks; sip@ietf.org; Robert Sparks; Keith Drage; Dean=20 > Willis > Subject: Re: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt > > > > Christer Holmberg (JO/LMF) wrote: > > >> So, maybe you could say: "MUST ensure, using a standards lopp=20 >> detection mechanism, that a request is not looping through this=20 >> proxy. > >> RFC 3261 defines a mechanism in chapter x.x.x.. Other standardized=20 >> mechansims for loop detecting MAY be used instead, or in addition, to >> the one defined in RFC 3261.". >> >> Or something like that... > > I don't like that wording. I think its important to give clear=20 > guidance on what an implementor should do. The clear guidance is to=20 > implement the loop detection mechanism in RFC3261. > > -Jonathan R. > > > --=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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 20 03:42:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWTmC-00034j-3s; Thu, 20 Apr 2006 03:40:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWTmA-00034e-6h for sip@ietf.org; Thu, 20 Apr 2006 03:40:30 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWTm6-0006Qy-QU for sip@ietf.org; Thu, 20 Apr 2006 03:40:30 -0400 Received: from [203.178.157.234] (203-178-157-234.ip.sipit.net [203.178.157.234] (may be forged)) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.4) with ESMTP id k3K7eHpj030666 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 20 Apr 2006 02:40:19 -0500 (CDT) (envelope-from rjsparks@estacado.net) In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1D54@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1D54@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt Date: Thu, 20 Apr 2006 16:40:10 +0900 To: Christer Holmberg ((JO/LMF)) X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: sip@ietf.org, Robert Sparks , 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 Do you mean "EVEN if other standardized mechanisms exist?" If so, no - that's not what we're trying to say. RjS On 20-Apr-06, at 4:05 PM, Christer Holmberg ((JO/LMF)) wrote: > > Hi Robert, > > What you say is pretty much what I said in my proposed text (see > below), > that a proxy "MUST ensure, using a standards lopp > detection mechanism, that a request is not looping through this > proxy.". > > After that I said that one mechanism is defined in RFC3261, but other > mechanisms can also be used. The reason for that was that the text > would > be "valid" also after other mechanisms have been defined. > > Do we want to say that a proxy SHOULD use the 3261 mechanism, EVEN if > other mechanims exist? > > Regards, > > Christer > > > > > > > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@estacado.net] > Sent: 20. huhtikuuta 2006 9:57 > To: Christer Holmberg (JO/LMF) > Cc: Jonathan Rosenberg; sip@ietf.org; Robert Sparks; Keith Drage; Dean > Willis > Subject: Re: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt > > How do you get that from this conversation? > > What we want to say is you MUST perform loop detection if you are > forking to locations that might loop. You SHOULD use the 3261 > algorithm > to do this detection. > > That's stronger and more specific than simply saying you SHOULD use > 3261 loop detection in > a vacuum. > > RjS > > On 20-Apr-06, at 2:43 PM, Christer Holmberg ((JO/LMF)) wrote: > >> >> Hi, >> >> So, all we want to say with this draft is: "You SHOULD implement this >> optional RFC3261 feature"? >> >> Regards, >> >> Christer >> >> >> -----Original Message----- >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >> Sent: 12. huhtikuuta 2006 18:11 >> To: Christer Holmberg (JO/LMF) >> Cc: Robert Sparks; sip@ietf.org; Robert Sparks; Keith Drage; Dean >> Willis >> Subject: Re: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt >> >> >> >> Christer Holmberg (JO/LMF) wrote: >> >> >>> So, maybe you could say: "MUST ensure, using a standards lopp >>> detection mechanism, that a request is not looping through this >>> proxy. >> >>> RFC 3261 defines a mechanism in chapter x.x.x.. Other standardized >>> mechansims for loop detecting MAY be used instead, or in >>> addition, to > >>> the one defined in RFC 3261.". >>> >>> Or something like that... >> >> I don't like that wording. I think its important to give clear >> guidance on what an implementor should do. The clear guidance is to >> implement the loop detection mechanism in RFC3261. >> >> -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 Apr 20 04:04:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWU72-0001in-8F; Thu, 20 Apr 2006 04:02:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWU6y-0001em-2O for sip@ietf.org; Thu, 20 Apr 2006 04:02:00 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWTvr-0006hh-4G for sip@ietf.org; Thu, 20 Apr 2006 03:50:38 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 858A054D; Thu, 20 Apr 2006 09:50:30 +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, 20 Apr 2006 09:50:29 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 09:50:28 +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] WGLC for draft-ietf-sip-fork-loop-fix-01.txt Date: Thu, 20 Apr 2006 09:50:28 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1D59@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt Thread-Index: AcZkTbKCBzadLsk+QbOngmcwtgRMQwAAK0eA From: "Christer Holmberg \(JO/LMF\)" To: "Robert Sparks" X-OriginalArrivalTime: 20 Apr 2006 07:50:28.0723 (UTC) FILETIME=[17914C30:01C6644F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: sip@ietf.org, Robert Sparks , 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 >Do you mean "EVEN if other standardized mechanisms exist?" Yes. >If so, no - that's not what we're trying to say. Then, what is the problem with the text I proposed earlier: "RFC 3261 defines a mechanism in chapter x.x.x.. Other standardized mechansims for loop detecting MAY be used instead, or in addition,=20 To the one defined in RFC 3261.". Regards, Christer On 20-Apr-06, at 4:05 PM, Christer Holmberg ((JO/LMF)) wrote: > > Hi Robert, > > What you say is pretty much what I said in my proposed text (see=20 > below), that a proxy "MUST ensure, using a standards lopp detection=20 > mechanism, that a request is not looping through this proxy.". > > After that I said that one mechanism is defined in RFC3261, but other=20 > mechanisms can also be used. The reason for that was that the text=20 > would be "valid" also after other mechanisms have been defined. > > Do we want to say that a proxy SHOULD use the 3261 mechanism, EVEN if=20 > other mechanims exist? > > Regards, > > Christer > > > > > > > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@estacado.net] > Sent: 20. huhtikuuta 2006 9:57 > To: Christer Holmberg (JO/LMF) > Cc: Jonathan Rosenberg; sip@ietf.org; Robert Sparks; Keith Drage; Dean > Willis > Subject: Re: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt > > How do you get that from this conversation? > > What we want to say is you MUST perform loop detection if you are=20 > forking to locations that might loop. You SHOULD use the 3261=20 > algorithm to do this detection. > > That's stronger and more specific than simply saying you SHOULD use > 3261 loop detection in > a vacuum. > > RjS > > On 20-Apr-06, at 2:43 PM, Christer Holmberg ((JO/LMF)) wrote: > >> >> Hi, >> >> So, all we want to say with this draft is: "You SHOULD implement this >> optional RFC3261 feature"? >> >> Regards, >> >> Christer >> >> >> -----Original Message----- >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >> Sent: 12. huhtikuuta 2006 18:11 >> To: Christer Holmberg (JO/LMF) >> Cc: Robert Sparks; sip@ietf.org; Robert Sparks; Keith Drage; Dean=20 >> Willis >> Subject: Re: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt >> >> >> >> Christer Holmberg (JO/LMF) wrote: >> >> >>> So, maybe you could say: "MUST ensure, using a standards lopp=20 >>> detection mechanism, that a request is not looping through this=20 >>> proxy. >> >>> RFC 3261 defines a mechanism in chapter x.x.x.. Other standardized=20 >>> mechansims for loop detecting MAY be used instead, or in addition,=20 >>> to > >>> the one defined in RFC 3261.". >>> >>> Or something like that... >> >> I don't like that wording. I think its important to give clear=20 >> guidance on what an implementor should do. The clear guidance is to=20 >> implement the loop detection mechanism in RFC3261. >> >> -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 From sip-bounces@ietf.org Thu Apr 20 04:17:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWUKa-0005co-Cw; Thu, 20 Apr 2006 04:16:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWUKY-0005cj-Gh for sip@ietf.org; Thu, 20 Apr 2006 04:16:02 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWUKY-0008Lq-15 for sip@ietf.org; Thu, 20 Apr 2006 04:16:02 -0400 Received: from [203.178.157.234] (203-178-157-234.ip.sipit.net [203.178.157.234] (may be forged)) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.4) with ESMTP id k3K8Fso9039227 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 20 Apr 2006 03:15:56 -0500 (CDT) (envelope-from rjsparks@estacado.net) In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1D59@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1D59@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <19567930-BFE9-4B19-AB59-ED30AEB365D0@estacado.net> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt Date: Thu, 20 Apr 2006 17:15:47 +0900 To: "Christer Holmberg \(JO/LMF\)" X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: sip@ietf.org, Robert Sparks , 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 I don't have a problem with that. If I were to have any problem at all, it would be in the redundancy with what the spec language means anyhow. I'll throw a small monkey wrench into this. We're finding at SIPit (again) that the text for loop detection in 3261 is nigh-unimplementable. People who are trying to follow it for the first time are creating code that just does not work. It is far from a concise description of an algorithm, and some of its recommendations are wrong. (For instance, inclusion of the topmost Via in the hash always produces a miss even if there is a loop). Several of the participants here will be summarizing the problems they have with this text over the next few weeks. I will be offline for a couple of weeks starting this weekend - when I return I'll compile their input and see if we can provide a clear description of how to do this loop detection. I'll also note that these participants find the algorithm in stack- loop-detect clear and plan to implement it and send comparative performance numbers over what they have that reflects what 3261 says modified to actually work. RjS On 20-Apr-06, at 4:50 PM, Christer Holmberg ((JO/LMF)) wrote: > >> Do you mean "EVEN if other standardized mechanisms exist?" > > Yes. > >> If so, no - that's not what we're trying to say. > > Then, what is the problem with the text I proposed earlier: > > "RFC 3261 defines a mechanism in chapter x.x.x.. Other standardized > mechansims for loop detecting MAY be used instead, or in addition, > To the one defined in RFC 3261.". > > Regards, > > Christer > > > > > > > On 20-Apr-06, at 4:05 PM, Christer Holmberg ((JO/LMF)) wrote: > >> >> Hi Robert, >> >> What you say is pretty much what I said in my proposed text (see >> below), that a proxy "MUST ensure, using a standards lopp detection >> mechanism, that a request is not looping through this proxy.". >> >> After that I said that one mechanism is defined in RFC3261, but other >> mechanisms can also be used. The reason for that was that the text >> would be "valid" also after other mechanisms have been defined. >> >> Do we want to say that a proxy SHOULD use the 3261 mechanism, EVEN if >> other mechanims exist? >> >> Regards, >> >> Christer >> >> >> >> >> >> >> -----Original Message----- >> From: Robert Sparks [mailto:rjsparks@estacado.net] >> Sent: 20. huhtikuuta 2006 9:57 >> To: Christer Holmberg (JO/LMF) >> Cc: Jonathan Rosenberg; sip@ietf.org; Robert Sparks; Keith Drage; >> Dean > >> Willis >> Subject: Re: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt >> >> How do you get that from this conversation? >> >> What we want to say is you MUST perform loop detection if you are >> forking to locations that might loop. You SHOULD use the 3261 >> algorithm to do this detection. >> >> That's stronger and more specific than simply saying you SHOULD use >> 3261 loop detection in >> a vacuum. >> >> RjS >> >> On 20-Apr-06, at 2:43 PM, Christer Holmberg ((JO/LMF)) wrote: >> >>> >>> Hi, >>> >>> So, all we want to say with this draft is: "You SHOULD implement >>> this > >>> optional RFC3261 feature"? >>> >>> Regards, >>> >>> Christer >>> >>> >>> -----Original Message----- >>> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>> Sent: 12. huhtikuuta 2006 18:11 >>> To: Christer Holmberg (JO/LMF) >>> Cc: Robert Sparks; sip@ietf.org; Robert Sparks; Keith Drage; Dean >>> Willis >>> Subject: Re: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt >>> >>> >>> >>> Christer Holmberg (JO/LMF) wrote: >>> >>> >>>> So, maybe you could say: "MUST ensure, using a standards lopp >>>> detection mechanism, that a request is not looping through this >>>> proxy. >>> >>>> RFC 3261 defines a mechanism in chapter x.x.x.. Other standardized >>>> mechansims for loop detecting MAY be used instead, or in addition, >>>> to >> >>>> the one defined in RFC 3261.". >>>> >>>> Or something like that... >>> >>> I don't like that wording. I think its important to give clear >>> guidance on what an implementor should do. The clear guidance is to >>> implement the loop detection mechanism in RFC3261. >>> >>> -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 Apr 20 04:19:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWUMe-0005zC-4N; Thu, 20 Apr 2006 04:18:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWUMc-0005z4-D9 for sip@ietf.org; Thu, 20 Apr 2006 04:18:10 -0400 Received: from smtpout06-01.prod.mesa1.secureserver.net ([64.202.165.224] helo=smtpout06-04.prod.mesa1.secureserver.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FWUMb-0008SV-0v for sip@ietf.org; Thu, 20 Apr 2006 04:18:10 -0400 Received: (qmail 24015 invoked from network); 20 Apr 2006 08:18:08 -0000 Received: from unknown (69.168.100.213) by smtpout06-04.prod.mesa1.secureserver.net (64.202.165.227) with ESMTP; 20 Apr 2006 08:18:07 -0000 From: "Rajnish Jain" To: Date: Thu, 20 Apr 2006 04:18:12 -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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZkUvbYv0+5u1X/Sd6o5A4tlM4S4Q== X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Sip] Minor Typo 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 Message-Id: The last sentence in the following paragraph of RFC 3261 mentions the word "accepting". Section 17, 5th Paragraph, Page #123 : The client transaction is also responsible for receiving responses and delivering them to the TU, filtering out any response retransmissions or disallowed responses (such as a response to ACK). Additionally, in the case of an INVITE request, the client transaction is responsible for generating the ACK request for any final response accepting a 2xx response. The author(s) probably intended to use the word "excepting" instead of "accepting". Or am I missing something? Thanks, Rajnish _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 20 04:25:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWURe-0007bp-QI; Thu, 20 Apr 2006 04:23:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWURd-0007bh-GC for sip@ietf.org; Thu, 20 Apr 2006 04:23:21 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWURX-0000Ae-Fc for sip@ietf.org; Thu, 20 Apr 2006 04:23:21 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k3K8NE7g003976; Thu, 20 Apr 2006 10:23:14 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k3K8NEpu004560; Thu, 20 Apr 2006 10:23:14 +0200 Received: from MCHP7I5A.ww002.siemens.net ([139.25.131.136]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 10:23:14 +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: AW: [Sip] Minor Typo in RFC 3261? Date: Thu, 20 Apr 2006 10:23:11 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Minor Typo in RFC 3261? Thread-Index: AcZkUvbYv0+5u1X/Sd6o5A4tlM4S4QAAJKdg From: "Tan, Ya-Ching" To: "Rajnish Jain" , X-OriginalArrivalTime: 20 Apr 2006 08:23:14.0056 (UTC) FILETIME=[AAFF5080:01C66453] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 This is already in the Bugzilla : http://bugs.sipit.net/show_bug.cgi?id=3D768=20 -----Urspr=FCngliche Nachricht----- Von: Rajnish Jain [mailto:rjain@precisionscientific.org]=20 Gesendet: Donnerstag, 20. April 2006 10:18 An: sip@ietf.org Betreff: [Sip] Minor Typo in RFC 3261? The last sentence in the following paragraph of RFC 3261 mentions the = word "accepting".=20 Section 17, 5th Paragraph, Page #123 : The client transaction is also responsible for receiving responses and delivering them to the TU, filtering out any response retransmissions or disallowed responses (such as a response to ACK). Additionally, in the case of an INVITE request, the client transaction is responsible for generating the ACK request for any final response accepting a 2xx response. The author(s) probably intended to use the word "excepting" instead of "accepting". Or am I missing something?=20 Thanks, Rajnish _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 20 04:27:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWUTz-00087r-J3; Thu, 20 Apr 2006 04:25:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWUTy-00087m-Bt for sip@ietf.org; Thu, 20 Apr 2006 04:25:46 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWUTx-0000H0-JL for sip@ietf.org; Thu, 20 Apr 2006 04:25:46 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F234D4F0004; Thu, 20 Apr 2006 10:25:44 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 10:25:42 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 10:25: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="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt Date: Thu, 20 Apr 2006 10:25:41 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1D5A@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt Thread-Index: AcZkUquCnjt3tJUYRKyxTku607IcTQAADisA From: "Christer Holmberg \(JO/LMF\)" To: "Robert Sparks" X-OriginalArrivalTime: 20 Apr 2006 08:25:41.0987 (UTC) FILETIME=[032BCB30:01C66454] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: sip@ietf.org, Robert Sparks , 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 Hi Robert,=20 >I don't have a problem with that. Sorry, I noted it was Jonathan who didn't like it :) >If I were to have any problem at all, it would be in the redundancy with what the spec language means anyhow. > >I'll throw a small monkey wrench into this. We're finding at SIPit (again) >that the text for loop detection in 3261 is nigh-unimplementable. People who are trying to follow it for the first time are creating code that just does=20 >not work. It is far from a concise description of an algorithm, and some of its recommendations are wrong. (For instance, inclusion of the topmost Via in=20 >the hash always produces a miss even if there is a loop). > >Several of the participants here will be summarizing the problems they have with this text over the next few weeks. I will be offline for a couple of=20 >weeks starting this weekend - when I return I'll compile their input and see if we can provide a clear description of how to do this loop detection. > >I'll also note that these participants find the algorithm in stack- loop-detect clear and plan to implement it and send comparative performance numbers=20 >over what they have that reflects what 3261 says modified to actually work. So, what you are saying is: not only shall the draft say that people MUST use a loop detection mechanism (the one in 3261, and/or other standardized mechanism), the draft shall also CLARIFY the existing 3261 mechanism? Regards, Christer On 20-Apr-06, at 4:50 PM, Christer Holmberg ((JO/LMF)) wrote: > >> Do you mean "EVEN if other standardized mechanisms exist?" > > Yes. > >> If so, no - that's not what we're trying to say. > > Then, what is the problem with the text I proposed earlier: > > "RFC 3261 defines a mechanism in chapter x.x.x.. Other standardized=20 > mechansims for loop detecting MAY be used instead, or in addition, To=20 > the one defined in RFC 3261.". > > Regards, > > Christer > > > > > > > On 20-Apr-06, at 4:05 PM, Christer Holmberg ((JO/LMF)) wrote: > >> >> Hi Robert, >> >> What you say is pretty much what I said in my proposed text (see=20 >> below), that a proxy "MUST ensure, using a standards lopp detection=20 >> mechanism, that a request is not looping through this proxy.". >> >> After that I said that one mechanism is defined in RFC3261, but other >> mechanisms can also be used. The reason for that was that the text=20 >> would be "valid" also after other mechanisms have been defined. >> >> Do we want to say that a proxy SHOULD use the 3261 mechanism, EVEN if >> other mechanims exist? >> >> Regards, >> >> Christer >> >> >> >> >> >> >> -----Original Message----- >> From: Robert Sparks [mailto:rjsparks@estacado.net] >> Sent: 20. huhtikuuta 2006 9:57 >> To: Christer Holmberg (JO/LMF) >> Cc: Jonathan Rosenberg; sip@ietf.org; Robert Sparks; Keith Drage;=20 >> Dean > >> Willis >> Subject: Re: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt >> >> How do you get that from this conversation? >> >> What we want to say is you MUST perform loop detection if you are=20 >> forking to locations that might loop. You SHOULD use the 3261=20 >> algorithm to do this detection. >> >> That's stronger and more specific than simply saying you SHOULD use >> 3261 loop detection in >> a vacuum. >> >> RjS >> >> On 20-Apr-06, at 2:43 PM, Christer Holmberg ((JO/LMF)) wrote: >> >>> >>> Hi, >>> >>> So, all we want to say with this draft is: "You SHOULD implement=20 >>> this > >>> optional RFC3261 feature"? >>> >>> Regards, >>> >>> Christer >>> >>> >>> -----Original Message----- >>> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>> Sent: 12. huhtikuuta 2006 18:11 >>> To: Christer Holmberg (JO/LMF) >>> Cc: Robert Sparks; sip@ietf.org; Robert Sparks; Keith Drage; Dean=20 >>> Willis >>> Subject: Re: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt >>> >>> >>> >>> Christer Holmberg (JO/LMF) wrote: >>> >>> >>>> So, maybe you could say: "MUST ensure, using a standards lopp=20 >>>> detection mechanism, that a request is not looping through this=20 >>>> proxy. >>> >>>> RFC 3261 defines a mechanism in chapter x.x.x.. Other standardized=20 >>>> mechansims for loop detecting MAY be used instead, or in addition,=20 >>>> to >> >>>> the one defined in RFC 3261.". >>>> >>>> Or something like that... >>> >>> I don't like that wording. I think its important to give clear=20 >>> guidance on what an implementor should do. The clear guidance is to=20 >>> implement the loop detection mechanism in RFC3261. >>> >>> -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 From sip-bounces@ietf.org Thu Apr 20 06:39:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWWXC-0005Cf-P7; Thu, 20 Apr 2006 06:37:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWWXA-0005Ca-EU for sip@ietf.org; Thu, 20 Apr 2006 06:37:12 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWWXA-000727-5m for sip@ietf.org; Thu, 20 Apr 2006 06:37: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 k3KAbAjc028338; Thu, 20 Apr 2006 05:37:10 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 20 Apr 2006 11:37:10 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB012B602D7@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Francois Audet , sip@ietf.org, jon.peterson@neustar.biz Subject: RE: [Sip] SIP Identity and RFC 3893 Date: Thu, 20 Apr 2006 11:37:04 +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.5 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 Note that RFC 3893 (AIB) is a normative reference of RFC 3892 = (Referred-By). Additionally RFC 3893 is an informative reference from = RFC 3911 (Join), but given the context in which it appears, I am not = sure why it is only informative. regards Keith > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: 19 April 2006 18:35 > To: sip@ietf.org; jon.peterson@neustar.biz > Subject: [Sip] SIP Identity and RFC 3893 >=20 >=20 > Jon, >=20 > Does sip-identity-06 make RFC 3893 (the AIB format for=20 > S/MIME) obsolete? >=20 > Sip-identity is remarkably silent about RFC 3893. It sorts of=20 > hints in the=20 > introduction that sip-identity is an alternative to S/MIME,=20 > but it is not > very specific. >=20 > The changelog (which will be removed upon publication) sheds=20 > a bit of light > on the history behind this (i.e., in -01 we switched from AIB=20 > to new header). >=20 > Should RFC 3893 (which is currently "Standards Track") be deprecated=20 > (moved to historical or whatever)? I'm kind of worried about=20 > developper=20 > confusion between sip-identity and RFC 3893. >=20 > Also, to add a little more confusion to this, there is=20 > "normative" reference > to RFC 3893 in sip-identity which, it seems to me, should be=20 > "informative". >=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 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 Apr 20 10:13:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWZsm-0005jE-TS; Thu, 20 Apr 2006 10:11:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWZsm-0005j9-6r for sip@ietf.org; Thu, 20 Apr 2006 10:11:44 -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 1FWZsl-0001aS-S5 for sip@ietf.org; Thu, 20 Apr 2006 10:11:44 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 20 Apr 2006 07:11:43 -0700 X-IronPort-AV: i="4.04,141,1144047600"; d="scan'208"; a="320574138:sNHT31347204" 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 k3KEBgYi027299; Thu, 20 Apr 2006 07:11:43 -0700 (PDT) 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, 20 Apr 2006 10:11:42 -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, 20 Apr 2006 10:11:42 -0400 Message-ID: <4447969D.5030805@cisco.com> Date: Thu, 20 Apr 2006 10:11:41 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] Question on Service Route Discovery Procedure duringRegistration References: <5EB80D22825EEE42872083AD5BFFB5945D1D52@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1D52@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Apr 2006 14:11:42.0202 (UTC) FILETIME=[593935A0:01C66484] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 Christer Holmberg (JO/LMF) wrote: > But, I guess the most important thing is the second: IF the UA uses the > Service-Route, it should be specified how the route is created. > > >>>2. Registrar processing of Path >> >>>I think we should also take Jonathan's draft, >>>draft-rosenberg-sip-route-construct-00, into consideration, which >>>allows >>>a registrar to build a Service-Route set based on the received Path >>>headers. >> >>Lovely idea, and 3608 suggests it as a possibility. Doesn't work for >> IMS AFAIk, so it can't be a MUST. > > I need to check that. But, is there something special you have in mind > why it wouldn't work with IMS? The way IMS is organized, it is possible to have two UAs registered to the same AOR (Public User Identity), but accessing via different P-CSCFs. The Path must include the P-CSCF so that requests can reach the intended UA via the P-CSCF it uses. That means in the two UA case there must be two Paths - one for each registered Contact. This is supported by RFC 3327. If route-construct were used to construct the Service-Route, then there would be two different Service-Routes for the same AOR. But according to RFC 3608 there may be only one Service-Route per AOR. So the algorithm of route-construct won't work for IMS as currently defined. I believe Jonathan has advocated a revision to RFC 3608 so that there may be a separate Service-Route for each registered contact. But there has been no action to make such a change. 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 Thu Apr 20 10:54:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWaWm-0001V4-Bl; Thu, 20 Apr 2006 10:53:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWaWl-0001Uz-8g for sip@ietf.org; Thu, 20 Apr 2006 10:53:03 -0400 Received: from mail.gt.ca ([216.18.99.22]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FWaWj-0003TR-TX for sip@ietf.org; Thu, 20 Apr 2006 10:53:03 -0400 Received: from unknown(172.22.198.31) by mail.gt.ca via csmap id ce7d8e04_d07e_11da_8b1e_00304811dcb9_14233; Thu, 20 Apr 2006 08:03:20 -0700 (PDT) Received: by svbcexgr01.gt.ca with Internet Mail Service (5.5.2653.19) id <2W2YWVBV>; Thu, 20 Apr 2006 07:53:04 -0700 Message-ID: From: Rehan Khan To: "'sip@ietf.org'" Date: Thu, 20 Apr 2006 07:53:00 -0700 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.6 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Sip] Message Headers X-BeenThere: sip@ietf.org X-Mailman-Version: 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, Could anyone please tell me what the following means m: contact binding: URI: SIP contact address: sip:abc@128.103.XXX.XXX User-Agent:cisco ICD 1.0.1.26.1 f:;tag=0h787f 6r SIP from address: sip:abc@128.103.XXX.XXX SIP tag:0h787f 6r t:; SIP to address: :sip:abc@128.103.XXX.XXX L:0 What does these headers imply ( m, f, t, L). 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 Thu Apr 20 10:59:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWaat-0003vl-1U; Thu, 20 Apr 2006 10:57:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWaar-0003vY-Ln for sip@ietf.org; Thu, 20 Apr 2006 10:57:17 -0400 Received: from [217.205.209.100] (helo=vegastream.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWaap-0003eY-AS for sip@ietf.org; Thu, 20 Apr 2006 10:57:17 -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.0.6487.1 Subject: RE: [Sip] Message Headers Date: Thu, 20 Apr 2006 15:57:14 +0100 Message-ID: <8F1F2062CA7D754A838F0E66097D23A0C23BB9@veg-brk-svr-pri.vegastream> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Message Headers Thread-Index: AcZkii300crSIwvTTmaorXYRSMjIUgAACzuQ From: "Attila Sipos" To: "Rehan Khan" , X-Spam-Score: 0.6 (/) 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 Hi Rehan, They are short forms of SIP headers. "m:" is equivalent to "Contact:" "f:" is equivalent to "From:" "t:" is equivalent to "To:" "L:" is equivalent to "Content-Length:" (Note that all the above are case-insensitive) If you look at the RFC3261 grammar, these short forms are explicitly shown. For example... Content-Length =3D ( "Content-Length" / "l" ) HCOLON 1*DIGIT Regards, Attila Attila Sipos http://www.vegastream.com >> -----Original Message----- >> From: Rehan Khan [mailto:Rehan.Khan@bell.ca] >> Sent: 20 April 2006 15:53 >> To: 'sip@ietf.org' >> Subject: [Sip] Message Headers >>=20 >>=20 >>=20 >> HI, >>=20 >> Could anyone please tell me what the following means >>=20 >> m: >> contact binding: >> URI: >> SIP contact address: sip:abc@128.103.XXX.XXX >>=20 >> User-Agent:cisco ICD 1.0.1.26.1 >>=20 >> f:;tag=3D0h787f 6r >> SIP from address: sip:abc@128.103.XXX.XXX >> SIP tag:0h787f 6r >>=20 >> t:; >> SIP to address: :sip:abc@128.103.XXX.XXX >> L:0 >>=20 >> What does these headers imply ( m, f, t, L).=20 >>=20 >> Thank you >>=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 Apr 20 11:22:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWaxx-0003ha-OZ; Thu, 20 Apr 2006 11:21:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWaxv-0003hV-TY for sip@ietf.org; Thu, 20 Apr 2006 11:21:07 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWaxu-0005HC-Ik for sip@ietf.org; Thu, 20 Apr 2006 11:21:07 -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 k3KFKxPI018566; Thu, 20 Apr 2006 10:21:02 -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 k3KFKxQ26755; Thu, 20 Apr 2006 10:20:59 -0500 (CDT) Message-ID: <4447A6DB.5000607@lucent.com> Date: Thu, 20 Apr 2006 10:20:59 -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: Robert Sparks Subject: Re: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt References: <5EB80D22825EEE42872083AD5BFFB5945D1D59@esealmw113.eemea.ericsson.se> <19567930-BFE9-4B19-AB59-ED30AEB365D0@estacado.net> In-Reply-To: <19567930-BFE9-4B19-AB59-ED30AEB365D0@estacado.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: sip@ietf.org, Robert Sparks , 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: , Content-Type: multipart/mixed; boundary="===============1849355059==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1849355059== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020109000503060104000907" This is a cryptographically signed message in MIME format. --------------ms020109000503060104000907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Robert Sparks wrote: > I'll throw a small monkey wrench into this. We're finding at SIPit > (again) that the text for loop detection in 3261 is > nigh-unimplementable. People who are trying to follow it for the > first time are creating code that just does not work. It is far from > a concise description of an algorithm, and some of its > recommendations are wrong. (For instance, inclusion of the topmost > Via in the hash always produces a miss even if there is a loop). Robert: That is a known bug (see http://bugs.sipit.net/show_bug.cgi?id=648). We had opened this bug way back in 2002. Basically, proxies that do loop detection should not include the topmost Via in the hash. Instead, including a cryptographic hash of the To tag, the From tag, the Call-ID, R-URI (before translation), CSeq number, and Route headers should do the trick. The spec also mentions Proxy-Require and Proxy-Authorization fields, but I have had some success with just the first set of fields. Also, I am confused -- in previous bakeoffs, we have successfully tested loop detection; so why can't we do this now? > I'll also note that these participants find the algorithm in stack- > loop-detect clear and plan to implement it and send comparative > performance numbers over what they have that reflects what 3261 says > modified to actually work. That should be interesting. 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) --------------ms020109000503060104000907 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA0MjAxNTIwNTlaMCMGCSqGSIb3DQEJ BDEWBBS3xgN73XMKz+JtwgsSYFvoKddTxDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGAGkfUi6uGu/9WgvpKa3hjtxD5LRmd93/mjy/LJ7ExrYJEmvh4CrCH BJAxO9bK7rBqLsL3oKFOgheBJYoh7dGfTK8DgBlycRBCQqAXb2ZKsWfemnJXpgQ33zznvYpU xUrCM7WL5rbm81zn/fbmxmbXy7+oBaj5r2rGZgh0fmh/EykAAAAAAAA= --------------ms020109000503060104000907-- --===============1849355059== 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 --===============1849355059==-- From sip-bounces@ietf.org Thu Apr 20 12:13:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWbkm-0004os-7V; Thu, 20 Apr 2006 12:11:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWbkk-0004on-Qn for sip@ietf.org; Thu, 20 Apr 2006 12:11:34 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWbkj-0008ML-FH for sip@ietf.org; Thu, 20 Apr 2006 12:11:34 -0400 Received: from [172.18.41.244] (tcn003124.tcn-catv.ne.jp [219.109.193.124]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.4) with ESMTP id k3KGBTLJ048075 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 20 Apr 2006 11:11:31 -0500 (CDT) (envelope-from rjsparks@estacado.net) In-Reply-To: <4447A6DB.5000607@lucent.com> References: <5EB80D22825EEE42872083AD5BFFB5945D1D59@esealmw113.eemea.ericsson.se> <19567930-BFE9-4B19-AB59-ED30AEB365D0@estacado.net> <4447A6DB.5000607@lucent.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt Date: Fri, 21 Apr 2006 01:11:20 +0900 To: "Vijay K. Gurbani" X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: sip@ietf.org, Robert Sparks , 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 - On 21-Apr-06, at 12:20 AM, Vijay K. Gurbani wrote: > Robert Sparks wrote: >> I'll throw a small monkey wrench into this. We're finding at SIPit >> (again) that the text for loop detection in 3261 is >> nigh-unimplementable. People who are trying to follow it for the >> first time are creating code that just does not work. It is far from >> a concise description of an algorithm, and some of its >> recommendations are wrong. (For instance, inclusion of the topmost >> Via in the hash always produces a miss even if there is a loop). > > Robert: That is a known bug (see > http://bugs.sipit.net/show_bug.cgi?id=648). We had opened this > bug way back in 2002. Basically, proxies that do loop detection > should not include the topmost Via in the hash. Instead, > including a cryptographic hash of the To tag, the From tag, the > Call-ID, R-URI (before translation), CSeq number, and Route > headers should do the trick. The spec also mentions Proxy-Require > and Proxy-Authorization fields, but I have had some success with > just the first set of fields. > > Also, I am confused -- in previous bakeoffs, we have successfully > tested loop detection; so why can't we do this now? Well - if you remember, we went through a lot of pain at each event when we were testing new implementations of loop detection. By the end of each event, most of the people that were trying to get it right got it working, but at the start, it was a mess. That basically went away when we went to max-forwards because most people just took that logic out. Now that we're asking for it again, we're right back to things not working. > >> I'll also note that these participants find the algorithm in stack- >> loop-detect clear and plan to implement it and send comparative >> performance numbers over what they have that reflects what 3261 says >> modified to actually work. > > That should be interesting. > > 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 Apr 20 12:23:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWbup-00008P-PB; Thu, 20 Apr 2006 12:21:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWbuo-00006h-3O for sip@ietf.org; Thu, 20 Apr 2006 12:21:58 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWbum-0000Wc-Ql for sip@ietf.org; Thu, 20 Apr 2006 12:21:58 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 8965021008E; Thu, 20 Apr 2006 18:21:53 +0200 (CEST) Message-ID: <4447B521.6030300@pernau.at> Date: Thu, 20 Apr 2006 18:21:53 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] draft-audet-sip-sips-guidelines-00.txt: use of transport=tls References: <1ECE0EB50388174790F9694F77522CCF08C5EACB@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF08C5EACB@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: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: SIP IETF , 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 Francois Audet wrote: > Hi Paul, > > Thanks for your comments. I'm starting to digest them. > > Rather than copy the whole list of comments, I'll deal with > individual comments separately. > > OPEN ISSUE: use of "transport=tls". Hi! Although RFC3261 states that this parameter is depreciated, I do not understand why. Can you please explain it to me? Consider the following example: UserA ProxyA ProxyB UserB User A sends a request to its proxyA. Then, the request should be forwarded to proxyB via TLS, but there is no need for the whole chain to be TLS. Thus, I would asume that userA sends: INVITE sip:userB@proxyB;transport=tls But if this parameter is depreciated, how else can I force TLS on a certain hop? Thanks Klaus _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 20 12:25:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWbwS-0000zy-7O; Thu, 20 Apr 2006 12:23:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWbwQ-0000yl-JT for sip@ietf.org; Thu, 20 Apr 2006 12:23:38 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWbwP-0000b6-9V for sip@ietf.org; Thu, 20 Apr 2006 12:23:38 -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 k3KGHwaB012095 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 20 Apr 2006 11:17:59 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1BE14C26-3EBB-4E31-B853-2527F0FDC402@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Stateless proxy and reliable transport Date: Thu, 20 Apr 2006 11:17:06 -0500 To: Pocha.Reddy@flextronicssoftware.com X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: kkuei , 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 15, 2006, at 1:20 AM, Pocha.Reddy@flextronicssoftware.com wrote: > > Is Stateless Proxy converting the request to UDP from TCP?, is it > possible ?---- as per RFC 3261 > Some people have claimed that it is possible, but I don't see how one could get correct behavior. It seems to me that the proxy that is converting from TCP to UDP becomes responsible for assuring transaction reliability at the UDP layer, which I think makes it at least transaction-statefull. Conceivably, one could have a partially transaction- statefull proxy that discards the state used for reliability on receipt of a provisional response, but why bother? -- 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 Apr 20 12:31:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWc2D-0003Sw-5C; Thu, 20 Apr 2006 12:29:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWc2C-0003Sr-0J for sip@ietf.org; Thu, 20 Apr 2006 12:29:36 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWc2A-0000nY-Mh for sip@ietf.org; Thu, 20 Apr 2006 12:29:35 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k3KGTWYO021514; Thu, 20 Apr 2006 11:29:32 -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 k3KGTWQ08285; Thu, 20 Apr 2006 11:29:32 -0500 (CDT) Message-ID: <4447B6EC.9090007@lucent.com> Date: Thu, 20 Apr 2006 11:29:32 -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: Robert Sparks Subject: Re: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt References: <5EB80D22825EEE42872083AD5BFFB5945D1D59@esealmw113.eemea.ericsson.se> <19567930-BFE9-4B19-AB59-ED30AEB365D0@estacado.net> <4447A6DB.5000607@lucent.com> In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 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="===============1813443831==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1813443831== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060803040505000406040706" This is a cryptographically signed message in MIME format. --------------ms060803040505000406040706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Robert Sparks wrote: >> Also, I am confused -- in previous bakeoffs, we have successfully >> tested loop detection; so why can't we do this now? > > Well - if you remember, we went through a lot of pain at each event > when we were testing new implementations of loop detection. By the > end of each event, most of the people that were trying to get it > right got it working, but at the start, it was a mess. Yes, I remember those pains very well. But most implementations that did the "advanced scenarios" did eventually -- after much configuration problems -- get it working with the set of headers (except the Via header) suggested in rfc3261. > That basically went away when we went to max-forwards because most > people just took that logic out. Now that we're asking for it again, > we're right back to things not working. That's the thing that puzzles me -- rfc3261 never deprecated loop detection in favor of M-F. All through until rfc3261 was released (June 2002) and even thereafter, we used to do the loop detection tests in the bakeoffs. But I have not attended the bakeoff in the last couple of years, so is it the case that somewhere down the line we stopped doing loop detection tests in the bakeoffs despite it still being a MAY in rfc3261? Oh well... - 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) --------------ms060803040505000406040706 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA0MjAxNjI5MzJaMCMGCSqGSIb3DQEJ BDEWBBSmVJi7Aud59lQ7E7ZdepkkHbMiwjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGATNZsL9bPGre4RF/8P2Wo9gVv8s+Ah/iYxPuGk2DjtETzT3gTLfD4 pj9bB9bd8ldNP1vtb2Rbh0JqtxgaJolxvtkJtbWEFp9IOEcrT6GzrqV77e3HeHJ5iAbaPF04 dlaxQ4xR0HBKsizRZatbMLlw5RsPxjXhyUkmmD7plqA9c6oAAAAAAAA= --------------ms060803040505000406040706-- --===============1813443831== 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 --===============1813443831==-- From sip-bounces@ietf.org Thu Apr 20 14:07:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWdWV-0001vl-5M; Thu, 20 Apr 2006 14:04:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWdWT-0001vL-UR for sip@ietf.org; Thu, 20 Apr 2006 14:04:57 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWdWS-0005O8-KX for sip@ietf.org; Thu, 20 Apr 2006 14:04:57 -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 k3KI4n604621; Thu, 20 Apr 2006 14:04:50 -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] draft-audet-sip-sips-guidelines-00.txt: use of transport=tls Date: Thu, 20 Apr 2006 13:04:33 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF08D93811@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-audet-sip-sips-guidelines-00.txt: use of transport=tls Thread-Index: AcZklo4YBa28rSeWRQe/1AMguyfVeQADXk0Q From: "Francois Audet" To: "Klaus Darilion" X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: SIP IETF , 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 Proxy A would send it to Proxy B over TLS with: INVITE sip:userB@proxyB Via: SIP/2.0/TLS=20 > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]=20 > Sent: Thursday, April 20, 2006 09:22 > To: Audet, Francois [SC100:3055:EXCH] > Cc: Paul Kyzivat; SIP IETF > Subject: Re: [Sip] draft-audet-sip-sips-guidelines-00.txt:=20 > use of transport=3Dtls >=20 >=20 > Francois Audet wrote: > > Hi Paul, > >=20 > > Thanks for your comments. I'm starting to digest them. > >=20 > > Rather than copy the whole list of comments, I'll deal with=20 > individual=20 > > comments separately. > >=20 > > OPEN ISSUE: use of "transport=3Dtls". >=20 > Hi! >=20 > Although RFC3261 states that this parameter is depreciated, I do not=20 > understand why. Can you please explain it to me? >=20 > Consider the following example: > UserA ProxyA ProxyB UserB >=20 > User A sends a request to its proxyA. Then, the request should be=20 > forwarded to proxyB via TLS, but there is no need for the=20 > whole chain to=20 > be TLS. >=20 > Thus, I would asume that userA sends: >=20 > INVITE sip:userB@proxyB;transport=3Dtls >=20 > But if this parameter is depreciated, how else can I force TLS on a=20 > certain hop? >=20 > Thanks > Klaus >=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 Apr 20 19:09:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWiFM-0000I7-F7; Thu, 20 Apr 2006 19:07:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWiFK-0000Hw-JU for sip@ietf.org; Thu, 20 Apr 2006 19:07:34 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWiFK-0006bO-8C for sip@ietf.org; Thu, 20 Apr 2006 19:07:34 -0400 Received: from [203.178.157.234] (203-178-157-234.ip.sipit.net [203.178.157.234] (may be forged)) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.4) with ESMTP id k3KN7VXr043273 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 20 Apr 2006 18:07:32 -0500 (CDT) (envelope-from rjsparks@estacado.net) In-Reply-To: <4447B6EC.9090007@lucent.com> References: <5EB80D22825EEE42872083AD5BFFB5945D1D59@esealmw113.eemea.ericsson.se> <19567930-BFE9-4B19-AB59-ED30AEB365D0@estacado.net> <4447A6DB.5000607@lucent.com> <4447B6EC.9090007@lucent.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt Date: Fri, 21 Apr 2006 08:07:11 +0900 To: "Vijay K. Gurbani" X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 21-Apr-06, at 1:29 AM, Vijay K. Gurbani wrote: > Robert Sparks wrote: >>> Also, I am confused -- in previous bakeoffs, we have successfully >>> tested loop detection; so why can't we do this now? >> Well - if you remember, we went through a lot of pain at each event >> when we were testing new implementations of loop detection. By the >> end of each event, most of the people that were trying to get it >> right got it working, but at the start, it was a mess. > > Yes, I remember those pains very well. But most implementations > that did the "advanced scenarios" did eventually -- after much > configuration problems -- get it working with the set of headers > (except the Via header) suggested in rfc3261. > >> That basically went away when we went to max-forwards because most >> people just took that logic out. Now that we're asking for it again, >> we're right back to things not working. > > That's the thing that puzzles me -- rfc3261 never deprecated loop > detection in favor of M-F. All through until rfc3261 was released > (June 2002) and even thereafter, we used to do the loop detection > tests in the bakeoffs. But I have not attended the bakeoff in the > last couple of years, so is it the case that somewhere down the > line we stopped doing loop detection tests in the bakeoffs > despite it still being a MAY in rfc3261? We still run the loop/spirals test. But for the last several years of SIPits, almost no-one used the loop-detection concept. The vast majority of implementations relied on max-forwards to end loops. RjS > > Oh well... > > - 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 Apr 20 21:21:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWkJ2-0003Qh-Bn; Thu, 20 Apr 2006 21:19:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWkJ0-0003QT-73; Thu, 20 Apr 2006 21:19:30 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWkIz-0004qY-Tp; Thu, 20 Apr 2006 21:19:30 -0400 Received: from [203.178.157.234] (203-178-157-234.ip.sipit.net [203.178.157.234]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.4) with ESMTP id k3L1Imr3009533 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 20 Apr 2006 20:18:50 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v749.3) Content-Transfer-Encoding: 7bit Message-Id: <276CE187-CF5C-43E0-B2FA-7FCE941F521F@nostrum.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sip@ietf.org, simple@ietf.org, sip-implementors@cs.columbia.edu From: Robert Sparks Date: Fri, 21 Apr 2006 10:18:15 +0900 X-Mailer: Apple Mail (2.749.3) Received-SPF: pass (nostrum.com: 203.178.157.234 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: Subject: [Sip] preliminary report: SIPit 18 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org 160 people from 16 countries attended SIPit 18 with 73 different SIP implementations. A short summary of some of the capabilities of those implementations follows: UDP 73 TCP 53 TLS 30 SCTP 6 SRTP 10 (7 use sdes) rport 36 GRUU 5 outbound 2 connect-reuse 6 IPv6 19 Full 3263 25 3263 no naptr (SRV on) 13 A only 22 IP only (no DNS) 9 Session timer 38 Prack 32 (9 non-trivial users) Update 25 NIT fixes (4320) 7 Out of Dialog Refer 3 Dialog package 8 Turn 3 XCAP 4 (2 servers) Generally, the level of interoperability was very high. Very few of the attendees were aware of GRUU, but there were some implementations to test (and they interoperated). The big surprise was the number of SIP over SCTP implementations testing at this event. There was significant testing of TLS and SRTP. TLS interoperability is solidifying. SRTP interoperability was poor (key exchange is not working) There were several common implementation errors and questions. Below are rough descriptions of each (in no particular order). I'll send more detailed messages when I'm back online in a couple of weeks. - Several UAs were doing 3263 lookups but ignoring the port from the SRV record, always sending to 5060 - Many UAs are gratuitously putting ports in URIs when the appropriate thing to do would be to only place a domain name. This particularly caused error when the port retrieved from SRV was placed explicitly in the RURI of the message sent - There was non-trivial testing of RPID at this event. There was disagreement around where was legal or had meaning. - More than one implementation still has ACK-200 vs ACK-non200 confused. In particular, more than one implementation used the branch parameter from an INVITE in the ACK-200. There was also some confusion leading to reusing the INVITE branch parameter in PRACKs - Those testing IPv6 made different assumptions about enclosing literal v6 addresses in Vias in []. By the end of the event, most implementations were accepting either. Its about 50/50 on what gets sent. - The SIP over SCTP implementers point out a need for clarification around using the 1 to many vs 1 to 1 mode. - Several implementations (including a few mature ones) are still having case-insensitivity related interop problems. I saw arguments over "Digest" vs "DIGEST", and case sensitivity around mime-types. - There were many questions about record-routing when changing transports, and where the double-record-routing technique we've been suggesting people use is documented. - Implementers are looking for better guidance for solving the issue we identified with discarding transactions state on an ACK-200. We need to get more guidance into current bugzilla report and/or issue a draft on this soon. - There were a few XCAP tests at this event. Interoperability was mixed. Very little "just worked", but after agreements were made about URI paths and versions of schemas most tests were successful. - Several UAs still miss that request-merging and handling multiple-200s (or multiple 183s) is even a concern. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 21 04:10:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWqgp-0005fM-T3; Fri, 21 Apr 2006 04:08:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWqgo-0005fH-FW for sip@ietf.org; Fri, 21 Apr 2006 04:08:30 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWqgk-0007UC-Na for sip@ietf.org; Fri, 21 Apr 2006 04:08:30 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3260F4F0018; Fri, 21 Apr 2006 10:08:26 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Apr 2006 10:08:25 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Apr 2006 10:08: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="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Question on Service Route Discovery Procedure duringRegistration Date: Fri, 21 Apr 2006 10:08:25 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB5945D1D7B@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question on Service Route Discovery Procedure duringRegistration Thread-Index: AcZkhGEBdHdQ8+glQgWH8eCinWLnjAAlhrpA From: "Christer Holmberg \(JO/LMF\)" To: "Paul Kyzivat" X-OriginalArrivalTime: 21 Apr 2006 08:08:25.0775 (UTC) FILETIME=[C3F423F0:01C6651A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: sip@ietf.org, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Paul,=20 >>>>2. Registrar processing of Path >>>> >>>>I think we should also take Jonathan's draft,=20 >>>>draft-rosenberg-sip-route-construct-00, into consideration, which=20 >>>>allows a registrar to build a Service-Route set based on the received=20 >>>>Path headers. >>> >>>Lovely idea, and 3608 suggests it as a possibility. Doesn't work for >>>IMS AFAIk, so it can't be a MUST. >>=20 >>I need to check that. But, is there something special you have in mind >>why it wouldn't work with IMS? > >The way IMS is organized, it is possible to have two UAs registered to the same AOR (Public User Identity), but accessing via different P-CSCFs. > >The Path must include the P-CSCF so that requests can reach the intended UA via the P-CSCF it uses. That means in the two UA case there must be two Paths=20 >- one for each registered Contact. This is supported by RFC 3327. > >If route-construct were used to construct the Service-Route, then there would be two different Service-Routes for the same AOR. But according to RFC 3608=20 >there may be only one Service-Route per AOR. So the algorithm of route-construct won't work for IMS as currently defined. [CHH] Ok. So, it's more an RFC issue than an IMS issue. >I believe Jonathan has advocated a revision to RFC 3608 so that there may be a separate Service-Route for each registered contact. But there has been no=20 >action to make such a change. [CHH] I guess that change would have to be done together with the other change(s). 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 Apr 21 09:41:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWvr5-0007nX-BC; Fri, 21 Apr 2006 09:39:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWvr3-0007nM-VS for sip@ietf.org; Fri, 21 Apr 2006 09:39:25 -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 1FWu2F-0002Bn-S1 for sip@ietf.org; Fri, 21 Apr 2006 07:42:51 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FWtuS-0006re-8z for sip@ietf.org; Fri, 21 Apr 2006 07:34:50 -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 k3LBWv6T010778 for ; Fri, 21 Apr 2006 14:32:58 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Apr 2006 14:34:27 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Apr 2006 14:34:29 +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] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Date: Fri, 21 Apr 2006 14:34:27 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0239A74A@esebe103.NOE.Nokia.com> In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F0225E58C@esebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Thread-Index: AcZVFd0sG9YDgsEJEdqlkgARJEEJ/AB01mMgA5NdxsA= From: To: X-OriginalArrivalTime: 21 Apr 2006 11:34:29.0249 (UTC) FILETIME=[8D288F10:01C66537] X-Spam-Score: -2.2 (--) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, >I made up two proposals based on DNS for the UA to find >out proxies supporting outbound within the domain of SIP >AOR of the user or the domain got from DHCP ... > >I am now planning to put together an I-D for those proposals >as an update to RFC 3263. It may take some time, but hopefully >not too long. The promised I-D is now available: 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-00.txt Pages : 17 Date : 2006-4-20 =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 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-00.txt I would appreciate for anyone interested to review this spec and provide me with comments. 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 Apr 21 10:48:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWwuJ-0002oP-2s; Fri, 21 Apr 2006 10:46:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWwuH-0002oK-SL for sip@ietf.org; Fri, 21 Apr 2006 10:46:49 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWwuF-0004Ki-HU for sip@ietf.org; Fri, 21 Apr 2006 10:46:49 -0400 Received: by tutpro.com (Postfix, from userid 65534) id ACF5113F8B0; Fri, 21 Apr 2006 17:46:41 +0300 (EEST) Received: from rautu (allozyme63.gprs.dnafinland.fi [62.78.104.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id C252813F8AE; Fri, 21 Apr 2006 17:46:35 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id B97FFF0172; Fri, 21 Apr 2006 17:46:36 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17480.61516.435540.344668@rautu.tutpro.com> Date: Fri, 21 Apr 2006 17:46:36 +0300 From: Juha Heinanen To: Subject: RE: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F0239A74A@esebe103.NOE.Nokia.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F0225E58C@esebe103.NOE.Nokia.com> <8B1D53AEF7B03449A6D3771B3B7F850F0239A74A@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: 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 erkki, thanks for writing the i-d. i have one comment. in case SRV query returns more than one record with equal priority and weight value, i would suggest that server should then be selected randomly. -- 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 Apr 21 11:55:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWxwx-0002QP-15; Fri, 21 Apr 2006 11:53:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWxwv-0002QK-HN for sip@ietf.org; Fri, 21 Apr 2006 11:53:37 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWxwu-0007bA-6P for sip@ietf.org; Fri, 21 Apr 2006 11:53:37 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 48BDA13F8B2; Fri, 21 Apr 2006 18:53:34 +0300 (EEST) Received: from rautu (allozyme63.gprs.dnafinland.fi [62.78.104.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 7708E13F8AE; Fri, 21 Apr 2006 18:53:27 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 565F0F0172; Fri, 21 Apr 2006 18:53:25 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17480.65525.275170.897904@rautu.tutpro.com> Date: Fri, 21 Apr 2006 18:53:25 +0300 From: Juha Heinanen To: , sip@ietf.org Subject: RE: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt In-Reply-To: <17480.61516.435540.344668@rautu.tutpro.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F0225E58C@esebe103.NOE.Nokia.com> <8B1D53AEF7B03449A6D3771B3B7F850F0239A74A@esebe103.NOE.Nokia.com> <17480.61516.435540.344668@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: 30ac594df0e66ffa5a93eb4c48bcb014 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 forgot to ask the list, why are outbound proxies classified as primary and backup? last time when i asked, no-one came up with a justification. i would like to get rid of that classification, because with it, one would need four proxy hosts for load-balanced, resilient configuration, when without, only two would suffice. -- 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 Apr 21 13:09:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWz5y-0005qa-FT; Fri, 21 Apr 2006 13:07:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWjgR-0008PS-RL for sip@ietf.org; Thu, 20 Apr 2006 20:39:39 -0400 Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWjgQ-0002vI-GP for sip@ietf.org; Thu, 20 Apr 2006 20:39:39 -0400 Received: (qmail 15229 invoked by uid 510); 20 Apr 2006 21:28:17 -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.142.176):. Processed in 1.037109 secs); 21 Apr 2006 01:28:17 -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.142.176):. Processed in 1.037109 secs Process 15224) Received: from c-24-1-142-176.hsd1.tx.comcast.net (HELO 1AB764895C324D3) (henry@pulver.com@24.1.142.176) by 192.246.69.184 with SMTP; Fri, 21 Apr 2006 01:28:16 +0000 From: "Henry Sinnreich" To: Date: Thu, 20 Apr 2006 19:39:35 -0500 Organization: pulver.com 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: <9BF66EBF6BEFD942915B4D4D45C051F3E86669@dyn-tx-exch-001.dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcOz27rRYC5sCCrpT7KEUVyb5KMe+4Vh/kCg X-Antivirus-MYDOMAIN-Message-ID: <114558289683515224@mail.pulver.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Fri, 21 Apr 2006 13:06:59 -0400 Cc: sip@ietf.org Subject: [Sip] A Hitchhikers Guide to SIP 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 Message-Id: This is an excellent document, though I wonder why ICE has been omitted in the list of key documents. ICE is only mentioned in a reference associated with RFC 2327 for SDP. See: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-hitchhikers-guide-00 .txt TURN is not mentioned at all. Maybe a section on NAT traversal would be appropriate for the next version of the I-D. 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 Fri Apr 21 13:46:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWzfp-0001hm-Kn; Fri, 21 Apr 2006 13:44:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWzfo-0001hh-Ah for sip@ietf.org; Fri, 21 Apr 2006 13:44:04 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWzfm-00060E-Tp for sip@ietf.org; Fri, 21 Apr 2006 13:44:04 -0400 Received: (qmail 1420 invoked by uid 0); 21 Apr 2006 17:43:53 -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 Apr 2006 17:43:53 -0000 Message-ID: <001001c6656b$266ecee0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: , References: <8B1D53AEF7B03449A6D3771B3B7F850F0239A74A@esebe103.NOE.Nokia.com> Subject: Re: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Date: Fri, 21 Apr 2006 19:43:49 +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: 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 Erkki, To me the draft too easily discards the "this is not scalable" argument. It really is not scalable, and stacking features on DNS like this feels wrong. RFC2915 hints at an alternative approach in the description of the usage of the "U" flag: "[...] there may be applications that use NAPTR to also lookup aspects of URIs". You could use a regular expression including a flag that denotes outbound support. Regards, Jeroen ----- Original Message ----- From: To: Sent: Friday, April 21, 2006 1:34 PM Subject: RE: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Hi, >I made up two proposals based on DNS for the UA to find >out proxies supporting outbound within the domain of SIP >AOR of the user or the domain got from DHCP ... > >I am now planning to put together an I-D for those proposals >as an update to RFC 3263. It may take some time, but hopefully >not too long. The promised I-D is now available: 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-00.txt Pages : 17 Date : 2006-4-20 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 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-00.txt I would appreciate for anyone interested to review this spec and provide me with comments. 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 21 13:48:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWziI-00028U-4B; Fri, 21 Apr 2006 13:46:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWziG-00028O-LK for sip@ietf.org; Fri, 21 Apr 2006 13:46:36 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWziF-00067R-FD for sip@ietf.org; Fri, 21 Apr 2006 13:46:36 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 1CD856C021 for ; Fri, 21 Apr 2006 13:46:30 -0400 (EDT) Subject: RE: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt From: "Dale R. Worley" To: Sip In-Reply-To: <17480.61516.435540.344668@rautu.tutpro.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F0225E58C@esebe103.NOE.Nokia.com> <8B1D53AEF7B03449A6D3771B3B7F850F0239A74A@esebe103.NOE.Nokia.com> <17480.61516.435540.344668@rautu.tutpro.com> Content-Type: text/plain Date: Fri, 21 Apr 2006 13:46:29 -0400 Message-Id: <1145641589.17087.13.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: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: sip@ietf.org X-Mailman-Version: 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-04-21 at 17:46 +0300, Juha Heinanen wrote: > in case SRV query returns more than one record with equal priority and > weight value, i would suggest that server should then be selected > randomly. I haven't read the I-D, but I'm fairly familiar with DNS SRV. Isn't the idea to pick one proxy of the lowest available priority? In that case, it seems like the right algorithm is to choose one randomly, weighted by the weight values, as one would do during ordinary DNS SRV processing. Actually, is there any reason to specify any of this behavior? Once NAPTR has found a DNS name to use, the processes for using DNS names are already specified. One nit: In section 5, I see the phrase "as specified above, in the description of Weight in "The format of the SRV RR" Section", but there doesn't seem to be any such section. 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 Apr 21 13:56:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWzpV-0002gN-Bs; Fri, 21 Apr 2006 13:54:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWzpT-0002gI-NW for sip@ietf.org; Fri, 21 Apr 2006 13:54:03 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWzpS-0006S2-Ck for sip@ietf.org; Fri, 21 Apr 2006 13:54:03 -0400 Received: by tutpro.com (Postfix, from userid 65534) id E7A5E13F8AF; Fri, 21 Apr 2006 20:53:56 +0300 (EEST) Received: from rautu (allozyme181.gprs.dnafinland.fi [62.78.104.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id D8FD413F8AC; Fri, 21 Apr 2006 20:53:50 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 7DB16F0172; Fri, 21 Apr 2006 20:53:37 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17481.7201.224273.580536@rautu.tutpro.com> Date: Fri, 21 Apr 2006 20:53:37 +0300 From: Juha Heinanen To: "Dale R. Worley" Subject: RE: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt In-Reply-To: <1145641589.17087.13.camel@niagra.pingtel.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F0225E58C@esebe103.NOE.Nokia.com> <8B1D53AEF7B03449A6D3771B3B7F850F0239A74A@esebe103.NOE.Nokia.com> <17480.61516.435540.344668@rautu.tutpro.com> <1145641589.17087.13.camel@niagra.pingtel.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: 30ac594df0e66ffa5a93eb4c48bcb014 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 writes: > I haven't read the I-D, but I'm fairly familiar with DNS SRV. Isn't the > idea to pick one proxy of the lowest available priority? sure, but my point related to the case, where there are more than one proxy with the same priority. -- 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 Apr 21 15:00:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX0pd-0003rd-0F; Fri, 21 Apr 2006 14:58:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX0pa-0003rY-UC for sip@ietf.org; Fri, 21 Apr 2006 14:58:14 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX0pW-0000bx-Gx for sip@ietf.org; Fri, 21 Apr 2006 14:58:14 -0400 Received: from [64.101.173.149] ([64.101.173.149]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k3LIwuUU017514 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 21 Apr 2006 13:58:57 -0500 In-Reply-To: <5EB80D22825EEE42872083AD5BFFB5945D1D7B@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB5945D1D7B@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <57241AC9-726F-43DD-8E42-A35BD22CA1CA@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Question on Service Route Discovery Procedure duringRegistration Date: Fri, 21 Apr 2006 13:58:11 -0500 To: Christer Holmberg ((JO/LMF)) X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 Apr 21, 2006, at 3:08 AM, Christer Holmberg ((JO/LMF)) wrote: > > [CHH] Ok. So, it's more an RFC issue than an IMS issue. Not exactly. I believe the IMS Path is discongruent from the IMS Service-Route, specifically in the inclusion of P-CSCF in one (path) but not the other (s-r). Then again, it's been a few years since I looked at that part of the IMS spec. So a simple inversion doesn't work. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Apr 22 01:01:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXADS-00053k-M4; Sat, 22 Apr 2006 00:59:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXADQ-00053a-Ra for sip@ietf.org; Sat, 22 Apr 2006 00:59:28 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXADP-0007D5-Iv for sip@ietf.org; Sat, 22 Apr 2006 00:59:28 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 21 Apr 2006 21:59:27 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,146,1144047600"; d="scan'208"; a="26443074:sNHT23748946" 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 k3M4xRvF025347; Sat, 22 Apr 2006 00:59:27 -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); Sat, 22 Apr 2006 00:59:26 -0400 Received: from [192.168.1.104] ([10.86.242.87]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 22 Apr 2006 00:59:26 -0400 Message-ID: <4449B82E.3030107@cisco.com> Date: Sat, 22 Apr 2006 00:59:26 -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: henry@pulver.com References: <4uco4o$ffcqn@test-inbound-a.cisco.com> In-Reply-To: <4uco4o$ffcqn@test-inbound-a.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2006 04:59:26.0520 (UTC) FILETIME=[87A4E380:01C665C9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sip@ietf.org Subject: [Sip] Re: A Hitchhikers Guide to 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 One of the challenges in this document was figuring out what is covered under the umbrella of SIP, and what is used by SIP but not SIP itself. This draft, at least, said that things in here had to be extensions to be considered part of SIP. ICE isn't actually a SIP extension, its an SDP extension. My recollcetion is that, during the meeting, we did agree that it made sense to include things which were directly normatively dependent as well, which certainly includes SDP. ICE is questionable based on this criteria, but I personally would be happy to include it. Main open issue is really what is the criteria for inclusion in this document. Thanks, Jonathan R. Henry Sinnreich wrote: > This is an excellent document, though I wonder why ICE has been omitted in > the list of key documents. ICE is only mentioned in a reference associated > with RFC 2327 for SDP. See: > > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-hitchhikers-guide-00 > .txt > > TURN is not mentioned at all. > > Maybe a section on NAT traversal would be appropriate for the next version > of the I-D. > > Thanks, Henry > -- 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 Apr 22 05:04:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXE0j-0003lY-Uk; Sat, 22 Apr 2006 05:02:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXE0j-0003lT-Ag for sip@ietf.org; Sat, 22 Apr 2006 05:02:37 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXE0f-0003I0-RH for sip@ietf.org; Sat, 22 Apr 2006 05:02:37 -0400 Received: (qmail 5495 invoked by uid 0); 22 Apr 2006 09:02:26 -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 < >; 22 Apr 2006 09:02:26 -0000 Message-ID: <001401c665eb$782071f0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: , References: <8B1D53AEF7B03449A6D3771B3B7F850F0239A74A@esebe103.NOE.Nokia.com> <001001c6656b$266ecee0$31713b51@BEMBUSTER> Subject: Re: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Date: Sat, 22 Apr 2006 11:02:23 +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: 9a2be21919e71dc6faef12b370c4ecf5 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 Erkki, Another possibility: http://www.dns-sd.org/ServiceTypes.html lists the following TXT keys defined for the "sip" service (amongst others): sip Session Initiation Protocol, signalling protocol for VoIP registrar SIP registrar (see RFC3261) proxy SIP proxy (see RFC3261) natproxy SIP proxy for NATed clients outproxy outbound SIP proxy (see RFC3261) stunserver STUN server DNS name or IP address [Further TXT record keys may be added in the future.] We could define a new TXT record key, say "outbound", and return that along with the result of a SRV lookup. In other words: use DNS-SD (http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt) for the purpose of outbound proxy discovery Regards, jeroen ----- Original Message ----- From: "Jeroen van Bemmel" To: ; Sent: Friday, April 21, 2006 7:43 PM Subject: Re: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt > Erkki, > > To me the draft too easily discards the "this is not scalable" argument. > It really is not scalable, and stacking features on DNS like this feels > wrong. > > RFC2915 hints at an alternative approach in the description of the usage > of the "U" flag: "[...] there may be applications that use NAPTR to also > lookup aspects of URIs". You could use a regular expression including a > flag that denotes outbound support. > > Regards, > > Jeroen > > ----- Original Message ----- > From: > To: > Sent: Friday, April 21, 2006 1:34 PM > Subject: RE: [Sip] I-D > ACTION:draft-koivusalo-sip-outbound-discovery-00.txt > > > Hi, > >>I made up two proposals based on DNS for the UA to find >>out proxies supporting outbound within the domain of SIP >>AOR of the user or the domain got from DHCP ... >> >>I am now planning to put together an I-D for those proposals >>as an update to RFC 3263. It may take some time, but hopefully >>not too long. > > The promised I-D is now available: > > 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-00.txt > Pages : 17 > Date : 2006-4-20 > > 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 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-00.txt > > I would appreciate for anyone interested to review this spec > and provide me with comments. > > 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 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 25 03:27:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYHvH-0000t0-V1; Tue, 25 Apr 2006 03:25:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYHvG-0000sv-Vw for sip@ietf.org; Tue, 25 Apr 2006 03:25:22 -0400 Received: from seimg3e.sei.co.jp ([219.106.230.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYHvE-00060w-Dl for sip@ietf.org; Tue, 25 Apr 2006 03:25:22 -0400 Received: from audit-f2 ([133.153.48.182]) by seimg3e.sei.co.jp (8.11.6p2/3.7W) with SMTP id k3P7PI804981 for ; Tue, 25 Apr 2006 16:25:18 +0900 X-Received-seimh: from hqosaka.sei.co.jp (ns.hqosaka.sei.co.jp [133.153.208.120]) by seimh2.seimh.sei.co.jp (8.11.6p2/3.7W) with SMTP id k3P7PE710871 for ; Tue, 25 Apr 2006 16:25:15 +0900 Received: from smtp1.hqosaka.sei.co.jp by hqosaka.sei.co.jp (8.8.8/R8-sei-generic/solaris-1.0-02/27/98) with SMTP id QAA17766; Tue, 25 Apr 2006 16:24:36 +0900 (JST) Message-Id: <200604250724.QAA17766@hqosaka.sei.co.jp> Date: Tue, 25 Apr 2006 16:24:36 +0900 From: Yuko TAKAHASHI X-Mailer: EdMax Ver2.85.5F MIME-Version: 1.0 To: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-WAuditID: 0604251607570000106012 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Sip] Need clarification of the refresher's behavior X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dear all, Could I ask for clarification of the refresher's behavior in the following sequence? The refreshee rejects the refresh request with a 480 Temporarily Unavailable and then is silently disconnected from the network. The session is not extended here and eventually the session expiration time is reached, but no BYE is generated from the refreshee. RFC4028 mentions that the refreshee should send a BYE on session expiration, but how about for the refresher, if no BYE is received? The refresher holds state for session expiration, but no action is specified, as far as I know. Should it send refresh requests even after session expiration, because the session is still active? I personally feel this better suits the purpose of session timer. Thanks. Regards, Yuko _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 25 04:57:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYJKY-0002ms-0C; Tue, 25 Apr 2006 04:55:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYJKW-0002mn-Jq for sip@ietf.org; Tue, 25 Apr 2006 04:55:32 -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 1FYI2b-0006Py-Lb for sip@ietf.org; Tue, 25 Apr 2006 03:32:57 -0400 Received: from rat01037.dc-ratingen.de ([195.233.129.142]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FYHpQ-0005JZ-BA for sip@ietf.org; Tue, 25 Apr 2006 03:19:24 -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 k3P7Bgrw003104; Tue, 25 Apr 2006 09:11:42 +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 k3P7BfOR001322; Tue, 25 Apr 2006 09:11:41 +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.211); Tue, 25 Apr 2006 09:11:42 +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); Tue, 25 Apr 2006 09:11:42 +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] Question on Service Route DiscoveryProcedure duringRegistration Date: Tue, 25 Apr 2006 09:11:40 +0200 Message-ID: <3A6671F8B360D34FAAC98771AD4D9990029D9B1E@DEDUS-WICL01M01.vf-de.internal.vodafone.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question on Service Route DiscoveryProcedure duringRegistration Thread-Index: AcZkhJnq19Dz8rihSIyLOIdPQZH6hgDsiJeQ From: "Lu, Yang, VF-DE" To: "Dean Willis" , "Christer Holmberg \(JO/LMF\)" , "Paul Kyzivat" X-OriginalArrivalTime: 25 Apr 2006 07:11:42.0406 (UTC) FILETIME=[810A3E60:01C66837] X-Spam-Score: -2.6 (--) 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: , Errors-To: sip-bounces@ietf.org =20 Hi Dean, Christer and Paul Thanks for extending the valuable discussions into the usage of the PATH = and Service-Route in connection with IMS.=20 May I also come back to the primal issue, ie, how to deal with the = inconsistency between the using of the Service-Route Header at the UAS = written in RFC 3608 and the UAS behavior of applying extensions when = generating the response in RFC 3261. As I understood from Dean's primeval response, it seems likely that = there are two ways forward: 1) Modify 3608 by providing an option-tag for Service-Route, or 2) Replace both 3608 and 3327 with the route-construction draft. Are = there any available concrete proposals for that now?=20 If you could impart your views on choosing a way forward it would be = highly appreciated. Regards Yang=20 Vodafone Best Regards=20 =AD=AD=AD=AD=AD=AD=AD=AD=AD=AD=AD=AD=AD=AD=AD=AD*************************= ******** * Yang Lu @ VODAFONE GERMANY * * Tel: +49 (0)211 533 5432 * ********************************* -----Urspr=FCngliche Nachricht----- Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Gesendet: Donnerstag, 20. April 2006 16:12 An: Christer Holmberg (JO/LMF) Cc: sip@ietf.org; Dean Willis Betreff: Re: [Sip] Question on Service Route DiscoveryProcedure = duringRegistration Christer Holmberg (JO/LMF) wrote: > But, I guess the most important thing is the second: IF the UA uses=20 > the Service-Route, it should be specified how the route is created. >=20 >=20 >>>2. Registrar processing of Path >> >>>I think we should also take Jonathan's draft,=20 >>>draft-rosenberg-sip-route-construct-00, into consideration, which=20 >>>allows a registrar to build a Service-Route set based on the received = >>>Path headers. >> >>Lovely idea, and 3608 suggests it as a possibility. Doesn't work for =20 >>IMS AFAIk, so it can't be a MUST. >=20 > I need to check that. But, is there something special you have in mind = > why it wouldn't work with IMS? The way IMS is organized, it is possible to have two UAs registered to = the same AOR (Public User Identity), but accessing via different = P-CSCFs. The Path must include the P-CSCF so that requests can reach the intended = UA via the P-CSCF it uses. That means in the two UA case there must be = two Paths - one for each registered Contact. This is supported by RFC = 3327. If route-construct were used to construct the Service-Route, then there = would be two different Service-Routes for the same AOR. But according to = RFC 3608 there may be only one Service-Route per AOR. So the algorithm = of route-construct won't work for IMS as currently defined. I believe Jonathan has advocated a revision to RFC 3608 so that there = may be a separate Service-Route for each registered contact. But there = has been no action to make such a change. 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 Apr 25 09:10:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYNHR-0001CJ-OI; Tue, 25 Apr 2006 09:08:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYNHQ-0001CD-Am for sip@ietf.org; Tue, 25 Apr 2006 09:08:36 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYNHN-00079p-TD for sip@ietf.org; Tue, 25 Apr 2006 09:08:36 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 25 Apr 2006 06:08:34 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,153,1144047600"; d="scan'208"; a="26624791:sNHT25773562" 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 k3PD8XTL022280; Tue, 25 Apr 2006 09:08:33 -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, 25 Apr 2006 09:08:32 -0400 Received: from [161.44.79.144] ([161.44.79.144]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Apr 2006 09:08:32 -0400 Message-ID: <444E1F50.6080502@cisco.com> Date: Tue, 25 Apr 2006 09:08:32 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Lu, Yang, VF-DE" Subject: Re: AW: [Sip] Question on Service Route DiscoveryProcedure duringRegistration References: <3A6671F8B360D34FAAC98771AD4D9990029D9B1E@DEDUS-WICL01M01.vf-de.internal.vodafone.com> In-Reply-To: <3A6671F8B360D34FAAC98771AD4D9990029D9B1E@DEDUS-WICL01M01.vf-de.internal.vodafone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 25 Apr 2006 13:08:32.0545 (UTC) FILETIME=[5A7A3110:01C66869] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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 Lu, Yang, VF-DE wrote: > > Hi Dean, Christer and Paul > > Thanks for extending the valuable discussions into the usage of the PATH and Service-Route in connection with IMS. > > May I also come back to the primal issue, ie, how to deal with the inconsistency between the using of the Service-Route Header at the UAS written in RFC 3608 and the UAS behavior of applying extensions when generating the response in RFC 3261. What inconsistency is it that you are referring to? I especially do not see what this has to do with generating responses. Both Path and Service-Route have to do with generating the preloaded Route header for *requests*. The only response that has direct relevance to these is the response to REGISTER. Or are you referring to the general issue of how to manage preloaded Route headers, as explained in draft-rosenberg-sip-route-construct-00.txt? > As I understood from Dean's primeval response, it seems likely that there are two ways forward: > > 1) Modify 3608 by providing an option-tag for Service-Route, or > > 2) Replace both 3608 and 3327 with the route-construction draft. Are there any available concrete proposals for that now? > > If you could impart your views on choosing a way forward it would be highly appreciated. I don't have a well formed view just yet. The following are some thoughts on the subject: - I think it is useful/important to have a well defined set of rules for how routes are used and managed. The current situation is quite problematic. - Something consistent that covers all the cases will be inconsistent with current usage of Path and Service-Route in IMS. This could be dealt with via a new option tag, or by deprecating both of those headers and defining a single new one to replace them both. - I think it makes sense for inbound route (a.k.a. Service-Route) and the outbound route (a.k.a. Path) to be symmetric by default. But there should be some provision for them to be asymmetric in cases where that is useful. This could be achieved by using Path for both directions, but allowing the Path to be modified in the REGISTER response. - Impact of 305 responses needs to be dealt with. Jonathan tried, but as I recall there may still have been issues. (I don't remember the details any longer.) - The use (or non-use) of the "service-route" on registration refreshes needs to be clear. (I think it should apply to refreshes, but should not apply to a new register, or one send after the prior one timed out.) While I don't think draft-rosenberg-sip-route-construct-00 is finished and ready to go to RFC, a reasonable way forward would be to resume work with it as a starting point. Paul > Regards > Yang > Vodafone > > > Best Regards > ­­­­­­­­­­­­­­­­********************************* > * Yang Lu @ VODAFONE GERMANY * > * Tel: +49 (0)211 533 5432 * > ********************************* > > -----Ursprüngliche Nachricht----- > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Gesendet: Donnerstag, 20. April 2006 16:12 > An: Christer Holmberg (JO/LMF) > Cc: sip@ietf.org; Dean Willis > Betreff: Re: [Sip] Question on Service Route DiscoveryProcedure duringRegistration > > > > Christer Holmberg (JO/LMF) wrote: > > >>But, I guess the most important thing is the second: IF the UA uses >>the Service-Route, it should be specified how the route is created. >> >> >> >>>>2. Registrar processing of Path >>> >>>>I think we should also take Jonathan's draft, >>>>draft-rosenberg-sip-route-construct-00, into consideration, which >>>>allows a registrar to build a Service-Route set based on the received >>>>Path headers. >>> >>>Lovely idea, and 3608 suggests it as a possibility. Doesn't work for >>>IMS AFAIk, so it can't be a MUST. >> >>I need to check that. But, is there something special you have in mind >>why it wouldn't work with IMS? > > > The way IMS is organized, it is possible to have two UAs registered to the same AOR (Public User Identity), but accessing via different P-CSCFs. > > The Path must include the P-CSCF so that requests can reach the intended UA via the P-CSCF it uses. That means in the two UA case there must be two Paths - one for each registered Contact. This is supported by RFC 3327. > > If route-construct were used to construct the Service-Route, then there would be two different Service-Routes for the same AOR. But according to RFC 3608 there may be only one Service-Route per AOR. So the algorithm of route-construct won't work for IMS as currently defined. > > I believe Jonathan has advocated a revision to RFC 3608 so that there may be a separate Service-Route for each registered contact. But there has been no action to make such a change. > > 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 Apr 25 09:59:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYO2m-0007uq-49; Tue, 25 Apr 2006 09:57:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYO2k-0007ul-Jm for sip@ietf.org; Tue, 25 Apr 2006 09:57:30 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYO2j-0001VE-9O for sip@ietf.org; Tue, 25 Apr 2006 09:57:30 -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 k3PDwJmH019925 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 25 Apr 2006 08:58:21 -0500 In-Reply-To: <444E1F50.6080502@cisco.com> References: <3A6671F8B360D34FAAC98771AD4D9990029D9B1E@DEDUS-WICL01M01.vf-de.internal.vodafone.com> <444E1F50.6080502@cisco.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: AW: [Sip] Question on Service Route DiscoveryProcedure duringRegistration Date: Tue, 25 Apr 2006 08:57:39 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 25, 2006, at 8:08 AM, Paul Kyzivat wrote: > > - I think it makes sense for inbound route (a.k.a. Service-Route) and > the outbound route (a.k.a. Path) to be symmetric by default. > But there should be some provision for them to be asymmetric in > cases > where that is useful. This could be achieved by using Path for both > directions, but allowing the Path to be modified in the REGISTER > response. > This would run afoul of the IESG-induced requirement that, from an "OPES" perspective, the UA be informed of the outbound route (path) as seen by the serving proxy/registrar. Of course, none of the topology-hiding aficionados were willing to comply with any sort of OPES requirements anyhow. But that's where some of the apparent strangeness in Path/Service-route came from. -- 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 Apr 25 10:26:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYOSe-0007qn-OE; Tue, 25 Apr 2006 10:24:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYOSd-0007qi-By for sip@ietf.org; Tue, 25 Apr 2006 10:24:15 -0400 Received: from rat01038.dc-ratingen.de ([195.233.129.143]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYOSc-0002X4-GY for sip@ietf.org; Tue, 25 Apr 2006 10:24:15 -0400 Received: from heinz.vodafone-is.de (heinz_e0 [195.233.128.26]) by rat01038.dc-ratingen.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id k3PEGX59029299; Tue, 25 Apr 2006 16:16:33 +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 k3PEFYQh014587; Tue, 25 Apr 2006 16:16:31 +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.211); Tue, 25 Apr 2006 16:16:11 +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); Tue, 25 Apr 2006 16:16:12 +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: AW: [Sip] Question on Service Route DiscoveryProcedure duringRegistration Date: Tue, 25 Apr 2006 16:16:11 +0200 Message-ID: <3A6671F8B360D34FAAC98771AD4D9990029D9B23@DEDUS-WICL01M01.vf-de.internal.vodafone.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Sip] Question on Service Route DiscoveryProcedure duringRegistration Thread-Index: AcZoaWNsPLrlhRnMTROuIqkTlDcT0AACHtoA From: "Lu, Yang, VF-DE" To: "Paul Kyzivat" X-OriginalArrivalTime: 25 Apr 2006 14:16:12.0735 (UTC) FILETIME=[CE8A04F0:01C66872] X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 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 On Apr 25, 2006, at 8:08 AM, Paul Kyzivat wrote: > What inconsistency is it that you are referring to? Hi Paul The inconsistency I referred to can be found at =20 http://www1.ietf.org/mail-archive/web/sip/current/msg13858.html Regards Yang Vodafone -----Urspr=FCngliche Nachricht----- Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Gesendet: Dienstag, 25. April 2006 15:09 An: Lu, Yang, VF-DE Cc: sip@ietf.org Betreff: Re: AW: [Sip] Question on Service Route DiscoveryProcedure = duringRegistration Lu, Yang, VF-DE wrote: > =20 > Hi Dean, Christer and Paul >=20 > Thanks for extending the valuable discussions into the usage of the = PATH and Service-Route in connection with IMS.=20 >=20 > May I also come back to the primal issue, ie, how to deal with the = inconsistency between the using of the Service-Route Header at the UAS = written in RFC 3608 and the UAS behavior of applying extensions when = generating the response in RFC 3261. What inconsistency is it that you are referring to? I especially do not see what this has to do with generating responses.=20 Both Path and Service-Route have to do with generating the preloaded = Route header for *requests*. The only response that has direct relevance to these is the response to = REGISTER. Or are you referring to the general issue of how to manage preloaded = Route headers, as explained in = draft-rosenberg-sip-route-construct-00.txt? > As I understood from Dean's primeval response, it seems likely that = there are two ways forward: >=20 > 1) Modify 3608 by providing an option-tag for Service-Route, or >=20 > 2) Replace both 3608 and 3327 with the route-construction draft. Are = there any available concrete proposals for that now?=20 >=20 > If you could impart your views on choosing a way forward it would be = highly appreciated. I don't have a well formed view just yet. The following are some = thoughts on the subject: - I think it is useful/important to have a well defined set of rules for how routes are used and managed. The current situation is quite problematic. - Something consistent that covers all the cases will be inconsistent with current usage of Path and Service-Route in IMS. This could be dealt with via a new option tag, or by deprecating both of those headers and defining a single new one to replace them both. - I think it makes sense for inbound route (a.k.a. Service-Route) and the outbound route (a.k.a. Path) to be symmetric by default. But there should be some provision for them to be asymmetric in cases where that is useful. This could be achieved by using Path for both directions, but allowing the Path to be modified in the REGISTER response. - Impact of 305 responses needs to be dealt with. Jonathan tried, but as I recall there may still have been issues. (I don't remember the details any longer.) - The use (or non-use) of the "service-route" on registration refreshes needs to be clear. (I think it should apply to refreshes, but should not apply to a new register, or one send after the prior one timed out.) While I don't think draft-rosenberg-sip-route-construct-00 is finished = and ready to go to RFC, a reasonable way forward would be to resume work = with it as a starting point. Paul > Regards > Yang > Vodafone >=20 >=20 > Best Regards > = =AD=AD=AD=AD=AD=AD=AD=AD=AD=AD=AD=AD=AD=AD=AD=AD*************************= ******** > * Yang Lu @ VODAFONE GERMANY * > * Tel: +49 (0)211 533 5432 * > ********************************* >=20 > -----Urspr=FCngliche Nachricht----- > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Gesendet: Donnerstag, 20. April 2006 16:12 > An: Christer Holmberg (JO/LMF) > Cc: sip@ietf.org; Dean Willis > Betreff: Re: [Sip] Question on Service Route DiscoveryProcedure=20 > duringRegistration >=20 >=20 >=20 > Christer Holmberg (JO/LMF) wrote: >=20 >=20 >>But, I guess the most important thing is the second: IF the UA uses=20 >>the Service-Route, it should be specified how the route is created. >> >> >> >>>>2. Registrar processing of Path >>> >>>>I think we should also take Jonathan's draft,=20 >>>>draft-rosenberg-sip-route-construct-00, into consideration, which=20 >>>>allows a registrar to build a Service-Route set based on the=20 >>>>received Path headers. >>> >>>Lovely idea, and 3608 suggests it as a possibility. Doesn't work for=20 >>>IMS AFAIk, so it can't be a MUST. >> >>I need to check that. But, is there something special you have in mind = >>why it wouldn't work with IMS? >=20 >=20 > The way IMS is organized, it is possible to have two UAs registered to = the same AOR (Public User Identity), but accessing via different = P-CSCFs. >=20 > The Path must include the P-CSCF so that requests can reach the = intended UA via the P-CSCF it uses. That means in the two UA case there = must be two Paths - one for each registered Contact. This is supported = by RFC 3327. >=20 > If route-construct were used to construct the Service-Route, then = there would be two different Service-Routes for the same AOR. But = according to RFC 3608 there may be only one Service-Route per AOR. So = the algorithm of route-construct won't work for IMS as currently = defined. >=20 > I believe Jonathan has advocated a revision to RFC 3608 so that there = may be a separate Service-Route for each registered contact. But there = has been no action to make such a change. >=20 > Paul >=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 Tue Apr 25 19:58:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYXO8-0001GW-4D; Tue, 25 Apr 2006 19:56:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYXO6-0001GN-KX for sip@ietf.org; Tue, 25 Apr 2006 19:56:10 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYXO3-0000a5-7I for sip@ietf.org; Tue, 25 Apr 2006 19:56:10 -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 k3PNtuw22269; Tue, 25 Apr 2006 19:55:56 -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] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Date: Tue, 25 Apr 2006 18:54:58 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF09097BFA@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Thread-Index: AcZl67hluBmK8yWfRNGXamVxiCoNnAC16pHQ From: "Francois Audet" To: "Jeroen van Bemmel" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 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 Isn't "outproxy =3D=3D outbound SIP proxy" already in that list you just quoted? > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 > Sent: Saturday, April 22, 2006 02:02 > To: Erkki.Koivusalo@nokia.com; sip@ietf.org > Subject: Re: [Sip] I-D=20 > ACTION:draft-koivusalo-sip-outbound-discovery-00.txt=20 >=20 >=20 > Erkki, >=20 > Another possibility: http://www.dns-sd.org/ServiceTypes.html=20 > lists the=20 > following TXT keys defined for the "sip" service (amongst others): >=20 > sip Session Initiation Protocol, signalling=20 > protocol for VoIP > registrar SIP registrar (see RFC3261) > proxy SIP proxy (see RFC3261) > natproxy SIP proxy for NATed clients > outproxy outbound SIP proxy (see RFC3261) > stunserver STUN server DNS name or IP address > [Further TXT record keys may be added in the future.] >=20 > We could define a new TXT record key, say "outbound", and=20 > return that along=20 > with the result of a SRV lookup. In other words: use DNS-SD=20 > (http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt)=20 > for the purpose=20 > of outbound proxy discovery >=20 > Regards, >=20 > jeroen >=20 > ----- Original Message -----=20 > From: "Jeroen van Bemmel" > To: ; > Sent: Friday, April 21, 2006 7:43 PM > Subject: Re: [Sip] I-D=20 > ACTION:draft-koivusalo-sip-outbound-discovery-00.txt >=20 >=20 > > Erkki, > > > > To me the draft too easily discards the "this is not scalable"=20 > > argument. > > It really is not scalable, and stacking features on DNS=20 > like this feels=20 > > wrong. > > > > RFC2915 hints at an alternative approach in the description of the=20 > > usage > > of the "U" flag: "[...] there may be applications that use=20 > NAPTR to also=20 > > lookup aspects of URIs". You could use a regular expression=20 > including a=20 > > flag that denotes outbound support. > > > > Regards, > > > > Jeroen > > > > ----- Original Message ----- > > From: > > To: > > Sent: Friday, April 21, 2006 1:34 PM > > Subject: RE: [Sip] I-D=20 > > ACTION:draft-koivusalo-sip-outbound-discovery-00.txt > > > > > > Hi, > > > >>I made up two proposals based on DNS for the UA to find > >>out proxies supporting outbound within the domain of SIP > >>AOR of the user or the domain got from DHCP ... > >> > >>I am now planning to put together an I-D for those proposals as an=20 > >>update to RFC 3263. It may take some time, but hopefully=20 > not too long. > > > > The promised I-D is now available: > > > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > > > > > > Title : Discovering Proxies Supporting SIP Outbound > > Author(s) : E. Koivusalo > > Filename : draft-koivusalo-sip-outbound-discovery-00.txt > > Pages : 17 > > Date : 2006-4-20 > > > > This document describes modifications to DNS procedures used to > > resolve a SIP Uniform Resource Identifier (URI) into the=20 > IP address, > > port, and transport protocol of the next hop to contact. These > > modifications enable the SIP User Agent 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:=20 > >=20 > http://www.ietf.org/internet-drafts/draft-koivusalo-sip-outbound-disco > > ve > > ry-00.txt > > > > I would appreciate for anyone interested to review this spec and=20 > > provide me with comments. > > > > 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=20 > 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=20 > current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sipping@ietf.org for new developments on the=20 > application of sip >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Apr 25 20:15:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYXek-0007bF-QC; Tue, 25 Apr 2006 20:13:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYXei-0007RW-Rm for sip@ietf.org; Tue, 25 Apr 2006 20:13:20 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYXSs-00012C-KG for sip@ietf.org; Tue, 25 Apr 2006 20:01:07 -0400 Received: (qmail 7620 invoked by uid 0); 26 Apr 2006 00:00:59 -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 Apr 2006 00:00:59 -0000 Message-ID: <009201c668c4$80445b40$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Francois Audet" , , References: <1ECE0EB50388174790F9694F77522CCF09097BFA@zrc2hxm0.corp.nortel.com> Subject: Re: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Date: Wed, 26 Apr 2006 02:00:59 +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: 225414c974e0d6437992164e91287a51 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 Francois, No, it would have to be something new, for backwards compatibility reasons. If we would reuse "outproxy", existing deployments that already have this (not sure if they exist, but suppose there are some) would inadvertedly be declaring their proxies to be outbound-compliant Regards, jeroen ----- Original Message ----- From: "Francois Audet" To: "Jeroen van Bemmel" ; ; Sent: Wednesday, April 26, 2006 1:54 AM Subject: RE: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Isn't "outproxy == outbound SIP proxy" already in that list you just quoted? > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: Saturday, April 22, 2006 02:02 > To: Erkki.Koivusalo@nokia.com; sip@ietf.org > Subject: Re: [Sip] I-D > ACTION:draft-koivusalo-sip-outbound-discovery-00.txt > > > Erkki, > > Another possibility: http://www.dns-sd.org/ServiceTypes.html > lists the > following TXT keys defined for the "sip" service (amongst others): > > sip Session Initiation Protocol, signalling > protocol for VoIP > registrar SIP registrar (see RFC3261) > proxy SIP proxy (see RFC3261) > natproxy SIP proxy for NATed clients > outproxy outbound SIP proxy (see RFC3261) > stunserver STUN server DNS name or IP address > [Further TXT record keys may be added in the future.] > > We could define a new TXT record key, say "outbound", and > return that along > with the result of a SRV lookup. In other words: use DNS-SD > (http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt) > for the purpose > of outbound proxy discovery > > Regards, > > jeroen > > ----- Original Message ----- > From: "Jeroen van Bemmel" > To: ; > Sent: Friday, April 21, 2006 7:43 PM > Subject: Re: [Sip] I-D > ACTION:draft-koivusalo-sip-outbound-discovery-00.txt > > > > Erkki, > > > > To me the draft too easily discards the "this is not scalable" > > argument. > > It really is not scalable, and stacking features on DNS > like this feels > > wrong. > > > > RFC2915 hints at an alternative approach in the description of the > > usage > > of the "U" flag: "[...] there may be applications that use > NAPTR to also > > lookup aspects of URIs". You could use a regular expression > including a > > flag that denotes outbound support. > > > > Regards, > > > > Jeroen > > > > ----- Original Message ----- > > From: > > To: > > Sent: Friday, April 21, 2006 1:34 PM > > Subject: RE: [Sip] I-D > > ACTION:draft-koivusalo-sip-outbound-discovery-00.txt > > > > > > Hi, > > > >>I made up two proposals based on DNS for the UA to find > >>out proxies supporting outbound within the domain of SIP > >>AOR of the user or the domain got from DHCP ... > >> > >>I am now planning to put together an I-D for those proposals as an > >>update to RFC 3263. It may take some time, but hopefully > not too long. > > > > The promised I-D is now available: > > > > 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-00.txt > > Pages : 17 > > Date : 2006-4-20 > > > > 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 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-disco > > ve > > ry-00.txt > > > > I would appreciate for anyone interested to review this spec and > > provide me with comments. > > > > 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 > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on > current sip Use > > sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 25 21:59:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYZH2-0007aI-SN; Tue, 25 Apr 2006 21:57:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYZH0-0007aD-VL for sip@ietf.org; Tue, 25 Apr 2006 21:56:58 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYZGz-0008Hq-LJ for sip@ietf.org; Tue, 25 Apr 2006 21:56:58 -0400 Received: from [206.176.144.212] (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 k3Q1vnLj022450 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 25 Apr 2006 20:57:50 -0500 Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <675C53CC-68BC-4489-AFFF-CF683A80C44F@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Tue, 25 Apr 2006 20:57:09 -0500 To: sip ietf X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Keith Drage Subject: [Sip] Requests: Agenda for SIP 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 If you have topics you want to see on the agenda for IETF 66, please send them to Keith and I. As usual, I'll build a request tracker on the softarmor site. -- 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 Apr 26 00:31:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYbf4-0004xl-CK; Wed, 26 Apr 2006 00:29:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYbf3-0004w3-Dj for sip@ietf.org; Wed, 26 Apr 2006 00:29:57 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYbf2-0007xU-Tz for sip@ietf.org; Wed, 26 Apr 2006 00:29:57 -0400 Received: from [206.176.144.212] (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 k3Q4UbEA022929 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 25 Apr 2006 23:30:45 -0500 In-Reply-To: <1140698256.30530.154.camel@eeek.ingate.se> References: <26fbf302818a0cbbe4558f83410f081c@ekabal.com> <1140698256.30530.154.camel@eeek.ingate.se> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] WGLC for draft-ietf-sip-answermode-00 Date: Tue, 25 Apr 2006 23:29:57 -0500 To: Hans Persson X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 Cc: SIP WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thank you, Hans, for the incredibly detailed recounting of my horrific typographical error-rate. I have worked through your list point-by-point. Comments follow. On Feb 23, 2006, at 6:37 AM, Hans Persson wrote: > tor 2006-02-23 klockan 04.32 skrev Rohan Mahy: > >> I'd like to start a 3-week working group last call for: >> >> draft-ietf-sip-answermode-00.txt > > I have a couple of questions where I would like clarifications and a > whole slew of nits. > > > Questions: > > Page 8, Req-11: I'm not able to make sense of "[...] knowledge that > may > be important in informing UAC-user's usage of the session.". I've revised this to say: This knowledge may be important to UAC-user's decision-making process about how to use the session. For example, UAC-user may wish to ask "Are you there?" if the request was answered automatically. > > Page 12, Section 4.2.1: In this paragraph is the text: "must be done > very carefully and only in the context of an external agreement > between > the proxy operator and the user of the UA.". The text "the UA" > (singular) implies that we're talking about only one of the UAC and > the > UAS and not both, but I think it would be good to explicitly state > which > one is meant (I assume it would be the UAS, but more clarity won't > hurt). > Changed to: only in the context of an external agreement between the proxy operator and the user of the UA that the proxy is serving. > > Nits: > > Page 5, last paragraph: intercom(m) is spelled with first one, then > two, > then again one "m". > happens when you mix a Brit and a Texan on one draft. I've changed to "intercom" globally. > Page 6, first (complete) paragraph: two instances of "caes" instead of > "cases" and one of "Ther" instead of "There". Fixed. > Req-1: "for UAC" should be "for the UAC" and "UAS-user" should be "the > UAS-user". > Ah, the joyous subtleties of English. In this context, UAC and UAS-User are serving as proper or "placeholder" nouns (based on the definitions in 2). So here, we're speaking of UAC as a specific reference instance of "a UAC" within the reference model of this draft. One would not say "for the Alice". Instead, one would say "for Alice". It may be that this style, although correct, just doesn't work for non-native readers of English. If that's so, then I'll rewrite the whole section. It also means that there's an extra "the" in Req-2 that is not consistent. My bad. I've added the following just before the requirements:
The relationship between the entities used in these requirements is shown in the following: UAC-User UAC UAS UAS-USer | | | | | | | | | | | | |(1) Uses | | | |-------------->| | | | | |(2) Uses | | | |<--------------| | |(3) REQUEST | | | |-------------->| | | |(4) RESPONSE | | | |<--------------| | | | | | | | | | Note that "UAC-User", "UAC", "UAS", and "UAS- User" are referenced as actors in the following discussion."
> Page 7, Req-2: "the UAC", "the UAS-user", "the UAS". > Req-3: "the UAS". > Req-4: "the UAC", "the UAS". Period missing at the end. Fixed missing period. > Req-5: "the UAC" > Req-6: "the UAS" (twice), "and or" should be "and/or". fixed and/or > Req-7: "the UAS", duplicated "that", "the UAS". > fixed duplicated "that" > Page 8, Req-9: "the UAC", "the UAS". > Req-10: "the UAC or the UAS" > Req-11: "the UAS", "the UAC", "the UAC-user". > > Req-12: "a UAS" or "UASs". Actually this type of form may be the > correct > choise for some of the above cases as well, but *something* is > definitely missing. > Yes, that was clumsy. I rephrased this as: It MUST be possible for UAS to maintain the privacy expectations of UAS-User. According to local policy, UAS MAY either 1) not include information about which answering mode was applied in a response or 2) include misleading information about which answering mode was applied. Consequently, applications MUST NOT rely on the veracity of this information in the response. > Page 9, last paragraph of section 3: shouldn't this be > "implementations > MUST" for clarity? Good question. Typically implementations just ignore unknown stuff -- this isn't a MUST of this specification, it's just the way SIP works. However, here we have a specific goal in mind, so I've rephrased the paragraph substantially in order to support a MUST: Note also that this syntax includes extension hooks, "generic-param" for parameters, and "token" for options, that may be defined in future specifications extending this one. This specification defines only the behavior for the values given explicitly above. In order to provide forward compatibility, implementations MUST ignore unknown values. > Last paragraph: Period missing before "For example". Fixed. > > Page 10, first paragraph of section 4.1.3: insert "an" before > "appropriate parameter". Arguable, but I've added an "an" as requested. > second paragraph, 4.1.3: "a Answer-Mode" should be "an Answer-Mode". > Ditto in the following three paragraphs. > fixed. > Page 11, third (complete) paragraph: It looks messy to put text > containing double quotes inside double quotes. The same goes for the > following two paragraphs. In the last of these three, the problematic > passage also contains an extra spurious double quote. > Ok, I've added lots of figures showing the syntax that might have been obfuscated by quotes, and deleted the spurious doubleqoute. Example: To request that retargeting proxies in the path preferentially select targets that have indicated support for this extension in their registration, a UAC includes an Accept-Contact header field having a parameter of "extension="answermode"". This usage of Accept-Contact is described in [8]. Note that this would normally be used in conjunction with the "Require: answermode" header field as described above. Require: answermode Accept-Contact: *;extension="answermode";methods="INVITE" > Page 12, first (incomplete) paragraph: "prefxing" should be > "prefixing". fixed > Section 4.2.1: "a Answer-Mode" should be "an...". changed globally, even though some English books say we're referring to "a header", not "an Answer-Mode". > Section 4.2.2, first paragraph: "UAS" -> "UASs" (twice, and once > each in > the next two paragraphs). It's doubtful as to whether pluralization of an acronym ending in S requires adding another S. It might do to add an "es", as in UASes. Or one can treat them as self-plurals, which is what I did. > Page 13, section 4.3.1, first paragraph: "for unattended UAS" -> "for > unattended UASs". > Third paragraph: "a Answer-Mode" -> "an ...". > Fourth paragraph: This talks about 'an Answer-Mode *parameter* of > "Auto"'. The previous paragraph has 'an Answer-Mode *value* of > "Auto"'. > Please use a consistent naming scheme. Here's the rub: When we're talking about a modifier for a header field, we're talking about a parameter. When we talk about a specific setting for that parameter (assuming that the parameter supports such), we're talking about "parameter values", usually shortened to "values". So we're really talking about the value of an Answer-Mode parameter in both of the above cases. I don't know why we try to write specs in English. It's too damned subtle. Anyhow, I've polished the usage throughout the document. Maybe it's better. > > Page 15, section 5, first paragraph: Duplicated "the". > fixed. > Section 5.1: "a Answer-Mode" -> "an..." (twice). > > Page 16, first (incomplete) paragraph: "UAS" (last instance) -> > "UASs". > Section 6: Duplicated "an". "asnwering" -> "answering". > fixed. > Page 19, first (incomplete) paragraph: Duplicated "a". fixed. > > Page 20, first item 1: Missing period at end. fixed. > Item 4: "nee o" -> "need to". fixed. > First paragraph after items 1-5: Extra comma before "[2]". > Fixed. > Second item 1: Missing period at end (and also for item 2, on the next > page). 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 Wed Apr 26 00:43:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYbqD-0001It-Om; Wed, 26 Apr 2006 00:41:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYbqC-0001Io-8F for sip@ietf.org; Wed, 26 Apr 2006 00:41:28 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYbqA-0000EH-UB for sip@ietf.org; Wed, 26 Apr 2006 00:41:28 -0400 Received: from [206.176.144.212] (sj-natpool-219.cisco.com [128.107.248.219]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k3Q4g7kE022976 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 25 Apr 2006 23:42:13 -0500 In-Reply-To: <001601c638a4$3ab6fa60$31713b51@BEMBUSTER> References: <26fbf302818a0cbbe4558f83410f081c@ekabal.com> <001601c638a4$3ab6fa60$31713b51@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v749.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4C47A462-C633-40FE-99A1-498F4C175143@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] WGLC for draft-ietf-sip-answermode-00 Date: Tue, 25 Apr 2006 23:41:27 -0500 To: Jeroen van Bemmel X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: SIP WG , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks! I've applied these suggestions in the revised draft. -- Dean On Feb 23, 2006, at 12:09 PM, Jeroen van Bemmel wrote: > Rohan, > > Two remarks: > 1. I would propose to change the ABNF to allow for a list of > generic-params, as is common for most SIP headers > The current version limits the extensibility to 1 parameter > (name=value) which would replace "Manual" or "Auto", and possibly a > list of tokens (which would be interpreted as flag parameters) > > How about the following: > Answer-Mode = "Answer-Mode" HCOLON answer-mode *(SEMI answer-mode- > param) > Priv-Answer-Mode = "Priv-Answer-Mode" HCOLON answer-mode *(SEMI > answer-mode-param) > > answer-mode = "Manual" / "Auto" / token > answer-mode-param = "require" / generic-param2. (NIT) Example > section 6.2, "Requires" header should be "Require" > > Regards, > > jeroen > > > ----- Original Message ----- From: "Rohan Mahy" > To: "SIP WG" > Cc: "Dean Willis" > Sent: Thursday, February 23, 2006 4:32 AM > Subject: [Sip] WGLC for draft-ietf-sip-answermode-00 > > >> Hi, >> >> I'd like to start a 3-week working group last call for: >> >> draft-ietf-sip-answermode-00.txt >> >> This WGLC will complete on March 15th >> >> thanks, >> -rohan >> >> Rohan Mahy >> co-chair SIP WG >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Apr 26 00:53:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYc0G-0004l0-4V; Wed, 26 Apr 2006 00:51:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYc0E-0004km-JP for sip@ietf.org; Wed, 26 Apr 2006 00:51:50 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYc0E-00010L-9x for sip@ietf.org; Wed, 26 Apr 2006 00:51:50 -0400 Received: from [206.176.144.212] (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 k3Q4qZO7023011 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 25 Apr 2006 23:52:38 -0500 In-Reply-To: <43FEA4D0.3050806@cisco.com> References: <26fbf302818a0cbbe4558f83410f081c@ekabal.com> <43FEA4D0.3050806@cisco.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3D7113AD-291F-4535-8390-BB6A6F8FDA76@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] WGLC for draft-ietf-sip-answermode-00 Date: Tue, 25 Apr 2006 23:51:55 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: SIP WG , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I've addressed the typos. On Feb 24, 2006, at 12:16 AM, Paul Kyzivat wrote: > OK, I reviewed this one more time. Below are a bunch of things. > They are all small except for the last one. > > Paul > > Rohan Mahy wrote: >> Hi, >> I'd like to start a 3-week working group last call for: >> draft-ietf-sip-answermode-00.txt >> This WGLC will complete on March 15th > > There are several instances of a feature tag of > "extension="answermode"". That ought to be "extensions". > > (I know dean consulted me on this long ago to get it right, so its > most likely my own error.) > > Note that there are also some correct usages in the doc. > > In section 6.1, a Contact header is folded across multiple lines, > but the subsequent lines are not indented. > > In section 7.3: s/nee o make/need to make/ > > In section 7.4: > > User agents implementing this specification MUST NOT establish a > session providing outbound or bidirectional media without explicit > user acceptance. > > Isn't this a little strong? It totally eliminates the baby monitor > as a supported application. It also eliminates using this in > support of a loopback test mode. > I've rephrased this final bit as: User agents implementing this specification MUST NOT establish a session providing outbound or bidirectional media sourced from the user agent without explicit user acceptance. Note that "loopback" media used for connectivity testing is not constrained by this requirement. This requirement is intended to assure that this extension can not be used to turn a UAS into a remote-controlled microphone (or "bug") without the knowledge of its user. -- 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 Apr 26 15:52:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYq1g-0000cf-FL; Wed, 26 Apr 2006 15:50:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYq1S-0000Zx-Ua; Wed, 26 Apr 2006 15:50:02 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYq1S-00082t-3S; Wed, 26 Apr 2006 15: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 k3QJo19W003089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Apr 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FYq1R-00077X-QR; Wed, 26 Apr 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, 26 Apr 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: sip@ietf.org Subject: [Sip] I-D ACTION: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: , 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 : Connected Identity in the Session Initiation Protocol (SIP) Author(s) : J. Elwell Filename : draft-ietf-sip-connected-identity-00.txt Pages : 20 Date : 2006-4-26 Because of retargeting of a Session Initiation Protocol (SIP) dialog- forming request, the UAS can have a different identity from that in the To header. This document provides a means for that UA to supply its identity to the peer UA by means of a request in the reverse direction and for that identity to be signed by an Authentication Service. The same mechanism can be used to indicate a change of identity during a dialog, e.g., because of some action in a PSTN behind a gateway. This document normatively updates RFC 3261 (SIP). This work is being discussed on the sip@ietf.org mailing list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-identity-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-connected-identity-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-connected-identity-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-4-26122358.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-connected-identity-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-connected-identity-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-26122358.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 Apr 26 17:39:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYrhg-0004Nm-9r; Wed, 26 Apr 2006 17:37:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYrhf-0004Nh-52 for sip@ietf.org; Wed, 26 Apr 2006 17:37:43 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYrhe-0007cE-MA for sip@ietf.org; Wed, 26 Apr 2006 17:37:43 -0400 Received: (qmail 29007 invoked by uid 0); 26 Apr 2006 21:37:36 -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 Apr 2006 21:37:36 -0000 Message-ID: <002201c66979$a2a54fe0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: References: Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-connected-identity-00.txt Date: Wed, 26 Apr 2006 23:37:36 +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: 34d35111647d654d033d58d318c0d21a X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Comment on section 6.2: Can't it simply be specified that an UA that supports this feature MUST support UPDATE (and include that in an Allow: header in its INVITE)? reINVITE has many drawbacks, and since the mechanism shouldn't be used in the first place when the peer does not support it, it is possible to mandate UPDATE here Regards, Jeroen ----- Original Message ----- From: To: Cc: Sent: Wednesday, April 26, 2006 9:50 PM Subject: [Sip] I-D ACTION:draft-ietf-sip-connected-identity-00.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 : Connected Identity in the Session Initiation Protocol (SIP) > Author(s) : J. Elwell > Filename : draft-ietf-sip-connected-identity-00.txt > Pages : 20 > Date : 2006-4-26 > > Because of retargeting of a Session Initiation Protocol (SIP) dialog- > forming request, the UAS can have a different identity from that in > the To header. This document provides a means for that UA to supply > its identity to the peer UA by means of a request in the reverse > direction and for that identity to be signed by an Authentication > Service. The same mechanism can be used to indicate a change of > identity during a dialog, e.g., because of some action in a PSTN > behind a gateway. This document normatively updates RFC 3261 (SIP). > This work is being discussed on the sip@ietf.org mailing list. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-identity-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-connected-identity-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-connected-identity-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 27 04:00:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ1Mx-0005o0-B4; Thu, 27 Apr 2006 03:56:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ1Mw-0005nk-AU for sip@ietf.org; Thu, 27 Apr 2006 03:56:58 -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 1FZ1Mv-0001q1-PV for sip@ietf.org; Thu, 27 Apr 2006 03:56:58 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IYD00M01FFPJG@siemenscomms.co.uk> for sip@ietf.org; Thu, 27 Apr 2006 08:57:25 +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 <0IYD00L5TFFPAB@siemenscomms.co.uk>; Thu, 27 Apr 2006 08:57:25 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 27 Apr 2006 08:56:56 +0100 Content-return: allowed Date: Thu, 27 Apr 2006 08:56:55 +0100 From: "Elwell, John" Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-connected-identity-00.txt To: Jeroen van Bemmel , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F266708C69705@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: b22590c27682ace61775ee7b453b40d3 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 Jeroen, Thanks for the suggestion. I think that would be good. John > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: 26 April 2006 22:38 > To: sip@ietf.org > Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-connected-identity-00.txt > > Comment on section 6.2: Can't it simply be specified that an UA that > supports this feature MUST support UPDATE (and include that > in an Allow: > header in its INVITE)? reINVITE has many drawbacks, and since > the mechanism > shouldn't be used in the first place when the peer does not > support it, it > is possible to mandate UPDATE here > > Regards, > > Jeroen > > ----- Original Message ----- > From: > To: > Cc: > Sent: Wednesday, April 26, 2006 9:50 PM > Subject: [Sip] I-D ACTION:draft-ietf-sip-connected-identity-00.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 : Connected Identity in the Session Initiation Protocol (SIP) > > Author(s) : J. Elwell > > Filename : draft-ietf-sip-connected-identity-00.txt > > Pages : 20 > > Date : 2006-4-26 > > > > Because of retargeting of a Session Initiation Protocol > (SIP) dialog- > > forming request, the UAS can have a different identity > from that in > > the To header. This document provides a means for that > UA to supply > > its identity to the peer UA by means of a request in the reverse > > direction and for that identity to be signed by an Authentication > > Service. The same mechanism can be used to indicate a change of > > identity during a dialog, e.g., because of some action in a PSTN > > behind a gateway. This document normatively updates RFC > 3261 (SIP). > > This work is being discussed on the sip@ietf.org mailing list. > > > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-i > dentity-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-connected-identity-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-connected-identity-00.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > -------------------------------------------------------------- > ------------------ > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 27 16:52:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZDQz-0005NE-Nq; Thu, 27 Apr 2006 16:49:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZDQy-0005N9-Dh for sip@ietf.org; Thu, 27 Apr 2006 16:49:56 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZDQw-00023t-3C for sip@ietf.org; Thu, 27 Apr 2006 16:49:56 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 27 Apr 2006 13:49:54 -0700 X-IronPort-AV: i="4.04,161,1144047600"; d="scan'208"; a="271513749:sNHT29577596" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k3RKnrYg025632 for ; Thu, 27 Apr 2006 13:49:53 -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, 27 Apr 2006 13:49:53 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.97.39]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Apr 2006 13:49:52 -0700 Message-Id: <4.3.2.7.2.20060427154004.02870350@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Apr 2006 15:49:51 -0500 To: sip@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Apr 2006 20:49:53.0294 (UTC) FILETIME=[2250CAE0:01C66A3C] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Sip] Question about propagation of dual stack along message path X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hey Given this generic topology: Alice --> Proxy1 --> Proxy2 --> Proxy3 --> Bob If Alice has a dual stack (IPv4 and IPv6), can she include both types of addresses everywhere in each of her messages towards Bob? If so, can Proxy1 do the same (add both address types everywhere it can)? for example, in the Via header "received=" Can this Via header have "received="? If this is true, can this propagate all the way to Bob? What happens if there is a Proxy that does not have dual stacks? Does it drop the IPv6 addressing, or ignore then and pass them on? The intent is for the offerer to offer both choices, and the answerer answer with IPv6 if they have that stack (or both stacks), and v4 if they only have this one stack. Is this written anywhere in an RFC or ID (even an old one)? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 27 17:00:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZDZM-00070K-Pw; Thu, 27 Apr 2006 16:58:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZDZL-00070F-O1 for sip@ietf.org; Thu, 27 Apr 2006 16:58:35 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZDZL-0002E0-DC for sip@ietf.org; Thu, 27 Apr 2006 16:58:35 -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 k3RKvSx7012165; Thu, 27 Apr 2006 15:57:28 -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 k3RKvSd27301; Thu, 27 Apr 2006 15:57:28 -0500 (CDT) Message-ID: <44513037.1050603@lucent.com> Date: Thu, 27 Apr 2006 15:57:27 -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: "James M. Polk" Subject: Re: [Sip] Question about propagation of dual stack along message path References: <4.3.2.7.2.20060427154004.02870350@email.cisco.com> In-Reply-To: <4.3.2.7.2.20060427154004.02870350@email.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 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="===============0358879286==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0358879286== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050305000905050008070604" This is a cryptographically signed message in MIME format. --------------ms050305000905050008070604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit James: See http://www.ietf.org/internet-drafts/draft-ietf-sipping-v6-transition-02.txt for some answers to your questions. - vijay James M. Polk wrote: > Hey > > Given this generic topology: > > Alice --> Proxy1 --> Proxy2 --> Proxy3 --> Bob > > If Alice has a dual stack (IPv4 and IPv6), can she include both types of > addresses everywhere in each of her messages towards Bob? > > If so, can Proxy1 do the same (add both address types everywhere it can)? > > for example, in the Via header "received=" > > Can this Via header have "received="? > > If this is true, can this propagate all the way to Bob? > > What happens if there is a Proxy that does not have dual stacks? > > Does it drop the IPv6 addressing, or ignore then and pass them on? > > The intent is for the offerer to offer both choices, and the answerer > answer with IPv6 if they have that stack (or both stacks), and v4 if > they only have this one stack. > > Is this written anywhere in an RFC or ID (even an old one)? > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- 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) --------------ms050305000905050008070604 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA0MjcyMDU3MjhaMCMGCSqGSIb3DQEJ BDEWBBShkwd1SNAr9zVgUENS0x9QbjSUezBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGAsTTLwNTqRel2jG8YKSfFhS/sFHHLaSoAT48YyIgSW8pdY3RKmIkG p2NWmxDLs+DOHdSykCafU3CBSzA518+07J1W9BOfc8DzzNbCn/wnmbQK3a8SlLgYRRPY1dq4 OXlepK1ZCI/yZyCAbieJNc1yHYCCZRarQvjh5MnWbuiet64AAAAAAAA= --------------ms050305000905050008070604-- --===============0358879286== 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 --===============0358879286==-- From sip-bounces@ietf.org Thu Apr 27 17:59:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZEUw-0003kl-9I; Thu, 27 Apr 2006 17:58:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZEUu-0003kg-9E for sip@ietf.org; Thu, 27 Apr 2006 17:58:04 -0400 Received: from test-iport-2.cisco.com ([171.71.176.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZEUt-0005RD-0g for sip@ietf.org; Thu, 27 Apr 2006 17:58:04 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-2.cisco.com with ESMTP; 27 Apr 2006 14:58:02 -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 k3RLw2RT001657 for ; Thu, 27 Apr 2006 14:58: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); Thu, 27 Apr 2006 14:58:02 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.97.39]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Apr 2006 14:58:01 -0700 Message-Id: <4.3.2.7.2.20060427165323.0290e650@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Apr 2006 16:58:00 -0500 To: sip@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Apr 2006 21:58:01.0856 (UTC) FILETIME=[A749D800:01C66A45] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Sip] Dual Stack UAC in draft-ietf-sipping-v6-transition-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 How is a UAC going to include both v4 and v6 addressing in its INVITE/Offer? There doesn't seem to be text or an example given in this ID discussing this case. This ID seems to be dealing more with translation from v4 to v6 and visa-versa. Am I wrong? The usecase is a dualstack UAC that doesn't know which stack a UAS has (OPTIONS may be prevented), but wants to have a session/dialog in v6 if all SIP elements support it, and will go with v4 if that's the common demoninator. Thanks James _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 27 18:01:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZEWP-0004E8-Ez; Thu, 27 Apr 2006 17:59:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZEWN-0004E3-O9 for sip@ietf.org; Thu, 27 Apr 2006 17:59:35 -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 1FZEWM-0005VJ-EW for sip@ietf.org; Thu, 27 Apr 2006 17:59:35 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 27 Apr 2006 14:59:35 -0700 X-IronPort-AV: i="4.04,162,1144047600"; d="scan'208"; a="425537337:sNHT29579200" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3RLxXh0028184 for ; Thu, 27 Apr 2006 14:59:33 -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); Thu, 27 Apr 2006 14:59:33 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.97.39]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Apr 2006 14:59:33 -0700 Message-Id: <4.3.2.7.2.20060427165850.028ccba0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Apr 2006 16:59:32 -0500 To: sip@ietf.org From: "James M. Polk" Subject: Re: [Sip] Dual Stack UAC in draft-ietf-sipping-v6-transition-02.txt? In-Reply-To: <4.3.2.7.2.20060427165323.0290e650@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Apr 2006 21:59:33.0794 (UTC) FILETIME=[DE167820:01C66A45] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 just realized this is to the wrong list. I have posted the same question to SIPPING forigve me At 04:58 PM 4/27/2006 -0500, James M. Polk wrote: >How is a UAC going to include both v4 and v6 addressing in its >INVITE/Offer? There doesn't seem to be text or an example given in this >ID discussing this case. This ID seems to be dealing more with >translation from v4 to v6 and visa-versa. Am I wrong? > >The usecase is a dualstack UAC that doesn't know which stack a UAS has >(OPTIONS may be prevented), but wants to have a session/dialog in v6 if >all SIP elements support it, and will go with v4 if that's the common >demoninator. > >Thanks >James > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 28 11:45:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZV8M-0004YU-A0; Fri, 28 Apr 2006 11:43:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZV8K-0004YO-Pl for sip@ietf.org; Fri, 28 Apr 2006 11:43:52 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZV8H-0000n3-FB for sip@ietf.org; Fri, 28 Apr 2006 11:43:52 -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 k3SFidJL006568 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 28 Apr 2006 10:44:43 -0500 In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F0239A74A@esebe103.NOE.Nokia.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F0239A74A@esebe103.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1DCCF622-DFAA-49A1-B79F-B897918D468F@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Date: Fri, 28 Apr 2006 10:44:00 -0500 To: SIP WG X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 So, two questions to the list: 1) Are we basically happy with this approach? 2) Do we need to include a reference to this in Outbound? If so, is an informative reference adequate? -- 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 Apr 28 12:01:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZVN9-0003KE-PQ; Fri, 28 Apr 2006 11:59:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZVN8-0003K9-Dy for sip@ietf.org; Fri, 28 Apr 2006 11:59:10 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZVN7-0001Tl-3B for sip@ietf.org; Fri, 28 Apr 2006 11:59:10 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 8824C1400AE; Fri, 28 Apr 2006 18:59:03 +0300 (EEST) Received: from rautu (mitosis67.gprs.dnafinland.fi [62.78.122.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 5C0291400AA; Fri, 28 Apr 2006 18:58:57 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id F3C0FF0173; Fri, 28 Apr 2006 18:58:48 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17490.15288.883462.295305@rautu.tutpro.com> Date: Fri, 28 Apr 2006 18:58:48 +0300 From: Juha Heinanen To: Dean Willis Subject: Re: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt In-Reply-To: <1DCCF622-DFAA-49A1-B79F-B897918D468F@softarmor.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F0239A74A@esebe103.NOE.Nokia.com> <1DCCF622-DFAA-49A1-B79F-B897918D468F@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.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: SIP WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis writes: > 1) Are we basically happy with this approach? at least i'm happy. > > 2) Do we need to include a reference to this in Outbound? If so, is > an informative reference adequate? no, the reference MUST be at the same level as rfc3261 references rfc3263. there is no difference. -- 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 Apr 28 12:14:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZVaf-0002jn-J6; Fri, 28 Apr 2006 12:13:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZVad-0002jf-RP for sip@ietf.org; Fri, 28 Apr 2006 12:13:07 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZVac-0002hO-IT for sip@ietf.org; Fri, 28 Apr 2006 12:13:07 -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 k3SGCxb13474; Fri, 28 Apr 2006 12:12:59 -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] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Date: Fri, 28 Apr 2006 11:12:35 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF092042EC@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Thread-Index: AcZq3MA0Ialesbo2QrS++qPHWYUgLgAAaMcQ From: "Francois Audet" To: "Juha Heinanen" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: SIP WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org If we are happy with it, and it is normative, then why don't=20 we just integrate this draft into sip-outbound? I see no advantage to have it a separate draft. > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com]=20 > Sent: Friday, April 28, 2006 08:59 > To: Dean Willis > Cc: SIP WG > Subject: Re: [Sip] I-D=20 > ACTION:draft-koivusalo-sip-outbound-discovery-00.txt=20 >=20 >=20 > Dean Willis writes: >=20 > > 1) Are we basically happy with this approach? >=20 > at least i'm happy. > >=20 > > 2) Do we need to include a reference to this in Outbound?=20 > If so, is =20 > > an informative reference adequate? >=20 > no, the reference MUST be at the same level as rfc3261=20 > references rfc3263. there is no difference. >=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=20 > sip Use sipping@ietf.org for new developments on the=20 > application of sip >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Apr 28 12:29:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZVp7-0002nr-VL; Fri, 28 Apr 2006 12:28:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZVp6-0002nm-Dc for sip@ietf.org; Fri, 28 Apr 2006 12:28:04 -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 1FZVp5-0003vO-4b for sip@ietf.org; Fri, 28 Apr 2006 12:28:04 -0400 Received: from HKaplan [10.0.200.145] by acmepacket.com with ESMTP (SMTPD-9.03) id A27C0420; Fri, 28 Apr 2006 12:27:40 -0400 From: "Hadriel Kaplan" To: "'Dean Willis'" , "'SIP WG'" Subject: RE: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Date: Fri, 28 Apr 2006 12:27:54 -0400 Message-ID: <00a101c66ae0$b3b3a030$91c8000a@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: <1DCCF622-DFAA-49A1-B79F-B897918D468F@softarmor.com> Thread-Index: AcZq2snvTC54dM/9T8K6EqZmjQz6pwAA2Rag X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 Dean, To your first question, I'm not sure what the final approach is for this draft. I saw some emails debating using more NAPTR records vs. SRV service types. I don't care either way, but whatever the chosen mechanism there must be a way for a service provider to provide outbound support without confusion about whether UAs will do the outbound primary/backup load-balancing scheme, if the provider wants a real primary/backup (non-load-balance) scheme. Right now the terms are actually misleading. They're not primary and backup, they're primary and primary - both from a registration and session signaling perspective. That has real implications for how service providers size systems, manage and troubleshoot. DNS is the only way for a service provider to control that, since the outbound draft leaves it all up to the UA to decide. So to your second question I would say it would be normative (IF the UA does DNS discovery, then it MUST do it as in XYZ). -hadriel > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, April 28, 2006 11:44 AM > To: SIP WG > Subject: Re: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery- > 00.txt > > > So, two questions to the list: > > 1) Are we basically happy with this approach? > > 2) Do we need to include a reference to this in Outbound? If so, is > an informative reference adequate? > > -- > 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 Apr 28 12:33:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZVsD-0004CS-6s; Fri, 28 Apr 2006 12:31:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZVsB-0004CN-Ha for sip@ietf.org; Fri, 28 Apr 2006 12:31:15 -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 1FZVsA-0004B8-8x for sip@ietf.org; Fri, 28 Apr 2006 12:31:15 -0400 Received: from HKaplan [10.0.200.145] by acmepacket.com with ESMTP (SMTPD-9.03) id A3340458; Fri, 28 Apr 2006 12:30:44 -0400 From: "Hadriel Kaplan" To: "'Juha Heinanen'" , , Subject: RE: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Date: Fri, 28 Apr 2006 12:30:56 -0400 Message-ID: <00a501c66ae1$216e4b20$91c8000a@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: <17480.65525.275170.897904@rautu.tutpro.com> Thread-Index: AcZlW+Z8mdQIbhexSuO6GToyXD3t+gFhQPhQ X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 Juha, IMHO it's an editorial error. They're not primary/backup, they're primary/primary. BTW, why does the terminology mistake make you need four proxies? -hadriel > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com] > Sent: Friday, April 21, 2006 11:53 AM > To: Erkki.Koivusalo@nokia.com; sip@ietf.org > Subject: RE: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery- > 00.txt > > i forgot to ask the list, why are outbound proxies classified as > primary and backup? last time when i asked, no-one came up with a > justification. > > i would like to get rid of that classification, because with it, one > would need four proxy hosts for load-balanced, resilient configuration, > when without, only two would suffice. > > -- 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 Fri Apr 28 12:39:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZVyL-0008LK-KC; Fri, 28 Apr 2006 12:37:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZVyJ-0008LE-VL for sip@ietf.org; Fri, 28 Apr 2006 12:37:35 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZVyI-0004a2-KI for sip@ietf.org; Fri, 28 Apr 2006 12:37:35 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 9DBB51400AE; Fri, 28 Apr 2006 19:37:33 +0300 (EEST) Received: from rautu (mitosis67.gprs.dnafinland.fi [62.78.122.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 03DCB1400AA; Fri, 28 Apr 2006 19:37:27 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id EB57CF0173; Fri, 28 Apr 2006 19:37:21 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17490.17601.911631.927756@rautu.tutpro.com> Date: Fri, 28 Apr 2006 19:37:21 +0300 From: Juha Heinanen To: "Hadriel Kaplan" Subject: RE: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt In-Reply-To: <00a501c66ae1$216e4b20$91c8000a@acmepacket.com> References: <17480.65525.275170.897904@rautu.tutpro.com> <00a501c66ae1$216e4b20$91c8000a@acmepacket.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: 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 Hadriel Kaplan writes: > BTW, why does the terminology mistake make you need four proxies? if one is primary and one is backup, then ua would always use primary as long as it is alive, i.e., backup would be on hot standby. so if operator wants to have load balancing, there must be at least two primaries and perhaps also two backups organized in such a way that if one primary goes down. also the other needs to be brought down, because otherwise there would be no load balancing. if all proxies are the same, then operaor can add a new one to the set and it automatically receives also some of the load. -- 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 Apr 28 12:40:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZVyw-0000Wx-Mn; Fri, 28 Apr 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 1FZVyv-0000Rq-81 for sip@ietf.org; Fri, 28 Apr 2006 12:38:13 -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 1FZVyu-0004bi-Uz for sip@ietf.org; Fri, 28 Apr 2006 12:38:13 -0400 Received: from HKaplan [10.0.200.145] by acmepacket.com with ESMTP (SMTPD-9.03) id A4F60324; Fri, 28 Apr 2006 12:38:14 -0400 From: "Hadriel Kaplan" To: , Subject: RE: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Date: Fri, 28 Apr 2006 12:38:27 -0400 Message-ID: <00a601c66ae2$2d1398d0$91c8000a@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: <8B1D53AEF7B03449A6D3771B3B7F850F0239A74A@esebe103.NOE.Nokia.com> Thread-Index: AcZVFd0sG9YDgsEJEdqlkgARJEEJ/AB01mMgA5NdxsABaqE4YA== X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 Erkki, I am confused by one thing (well, for this topic): why did you choose to use the SRV priority in that way? You said "choose one of each priority level". If I understand the outbound draft correctly, there is no real distinction between primary and backups - any one of them can get new requests at any time, and the UA registers to all. So they're really all primaries once the UA chooses to create a flow to them. Thus I would think it more logical to have a UA which supports outbound connect to all servers of the same and lowest SRV priority if the server supported outbound, and only connect to higher ones upon failure of lower ones. That way a higher priority really means "connect if lower one fails", as it did for SRV before outbound. No? -hadriel > -----Original Message----- > From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com] > Sent: Friday, April 21, 2006 7:34 AM > To: sip@ietf.org > Subject: RE: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery- > 00.txt > > Hi, > > >I made up two proposals based on DNS for the UA to find > >out proxies supporting outbound within the domain of SIP > >AOR of the user or the domain got from DHCP ... > > > >I am now planning to put together an I-D for those proposals > >as an update to RFC 3263. It may take some time, but hopefully > >not too long. > > The promised I-D is now available: > > 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-00.txt > Pages : 17 > Date : 2006-4-20 > > 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 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-00.txt > > I would appreciate for anyone interested to review this spec > and provide me with comments. > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Apr 28 13:14:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZWVs-0004Bq-40; Fri, 28 Apr 2006 13:12:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZWVq-0004BW-Pe for sip@ietf.org; Fri, 28 Apr 2006 13:12:14 -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 1FZWVp-0006Mg-BJ for sip@ietf.org; Fri, 28 Apr 2006 13:12:14 -0400 Received: from HKaplan [10.0.200.145] by acmepacket.com with ESMTP (SMTPD-9.03) id ACED02A4; Fri, 28 Apr 2006 13:12:13 -0400 From: "Hadriel Kaplan" To: "'Juha Heinanen'" Subject: RE: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Date: Fri, 28 Apr 2006 13:12:25 -0400 Message-ID: <00a801c66ae6$ecc7d7a0$91c8000a@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: <17490.17601.911631.927756@rautu.tutpro.com> Thread-Index: AcZq4g4yVKovHyl0SlmIFaIJ9H0bwwAAXp+Q X-Spam-Score: 0.1 (/) 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 But I think no matter what it will be the UA which decides which one to use for active signaling. Even if you call them both primaries, the UAs would probably just use the first one configured/discovered/bound for signaling. If you specify they must choose it randomly then you could just say that about the primary and backup terms. (although I agree the terms would be highly confusing, as they already are for me) In some ways that's already going to happen - the draft does not say the UA must use the "primary" for new outbound requests, and the registrar has no idea which one the primary is, so new requests going to the UA will be pseudo-randomly chosen. (if anything, it would probably use the most recently bound one, which ironically means the backup will be the first used) -hadriel > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com] > Sent: Friday, April 28, 2006 12:37 PM > To: Hadriel Kaplan > Cc: Erkki.Koivusalo@nokia.com; sip@ietf.org > Subject: RE: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery- > 00.txt > > Hadriel Kaplan writes: > > > BTW, why does the terminology mistake make you need four proxies? > > if one is primary and one is backup, then ua would always use primary as > long as it is alive, i.e., backup would be on hot standby. so if > operator wants to have load balancing, there must be at least two > primaries and perhaps also two backups organized in such a way that if > one primary goes down. also the other needs to be brought down, because > otherwise there would be no load balancing. > > if all proxies are the same, then operaor can add a new one to the set > and it automatically receives also some of the load. > > -- 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 Apr 28 13:35:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZWqY-00025A-Oo; Fri, 28 Apr 2006 13:33:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZWqX-00024t-BH for sip@ietf.org; Fri, 28 Apr 2006 13:33:37 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZWqW-0007Hs-4l for sip@ietf.org; Fri, 28 Apr 2006 13:33:37 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id BC1476C020 for ; Fri, 28 Apr 2006 13:33:32 -0400 (EDT) Subject: RE: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt From: "Dale R. Worley" To: Sip In-Reply-To: <00a801c66ae6$ecc7d7a0$91c8000a@acmepacket.com> References: <00a801c66ae6$ecc7d7a0$91c8000a@acmepacket.com> Content-Type: text/plain Date: Fri, 28 Apr 2006 13:33:32 -0400 Message-Id: <1146245612.14513.38.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: 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 Fri, 2006-04-28 at 13:12 -0400, Hadriel Kaplan wrote: > But I think no matter what it will be the UA which decides which one to use > for active signaling. Even if you call them both primaries, the UAs would > probably just use the first one configured/discovered/bound for signaling. > If you specify they must choose it randomly then you could just say that > about the primary and backup terms. (although I agree the terms would be > highly confusing, as they already are for me) I haven't been following the discussion closely, but -- If you are going to allow specifying a prioritization of (whatever they are), you should copy the system that is used in DNS SRV records -- a priority and weight is given for each. Of the (whatever) that the UA can contact, the UA uses only the ones with the lowest priority number, and among them, distributes traffic proportionately to weight. This covers most popular primary/backup and load-balancing schemes in a way that parallels the existing DNS SRV infrastructure (which is implicitly inherited by the DNS NAPTR infrastructure). 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 Apr 28 13:51:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZX6U-0006um-LJ; Fri, 28 Apr 2006 13:50:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZX6S-0006uh-Oc for sip@ietf.org; Fri, 28 Apr 2006 13:50:04 -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 1FZX6R-0007vz-Fn for sip@ietf.org; Fri, 28 Apr 2006 13:50:04 -0400 Received: from HKaplan [10.0.200.145] by acmepacket.com with ESMTP (SMTPD-9.03) id A5B80210; Fri, 28 Apr 2006 13:49:44 -0400 From: "Hadriel Kaplan" To: "'Dale R. Worley'" , "'Sip'" Subject: RE: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Date: Fri, 28 Apr 2006 13:49:57 -0400 Message-ID: <00af01c66aec$2a719230$91c8000a@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: <1146245612.14513.38.camel@niagra.pingtel.com> Thread-Index: AcZq6f63uIx7RXvYS42ZReopBlFUKgAAgUpg X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 Yup, see another email I sent which I said that as well. (although not as directly) -hadriel > -----Original Message----- > From: Dale R. Worley [mailto:dworley@pingtel.com] > Sent: Friday, April 28, 2006 1:34 PM > To: Sip > Subject: RE: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery- > 00.txt > > On Fri, 2006-04-28 at 13:12 -0400, Hadriel Kaplan wrote: > > But I think no matter what it will be the UA which decides which one to > use > > for active signaling. Even if you call them both primaries, the UAs > would > > probably just use the first one configured/discovered/bound for > signaling. > > If you specify they must choose it randomly then you could just say that > > about the primary and backup terms. (although I agree the terms would be > > highly confusing, as they already are for me) > > I haven't been following the discussion closely, but -- > > If you are going to allow specifying a prioritization of (whatever they > are), you should copy the system that is used in DNS SRV records -- a > priority and weight is given for each. Of the (whatever) that the UA > can contact, the UA uses only the ones with the lowest priority number, > and among them, distributes traffic proportionately to weight. This > covers most popular primary/backup and load-balancing schemes in a way > that parallels the existing DNS SRV infrastructure (which is implicitly > inherited by the DNS NAPTR infrastructure). > > 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 Fri Apr 28 13:53:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZX83-00076d-0N; Fri, 28 Apr 2006 13:51:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZX81-00076Y-CG for sip@ietf.org; Fri, 28 Apr 2006 13:51:41 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZX80-0007zI-1R for sip@ietf.org; Fri, 28 Apr 2006 13:51:41 -0400 Received: by tutpro.com (Postfix, from userid 65534) id B2B941400AE; Fri, 28 Apr 2006 20:51:38 +0300 (EEST) Received: from rautu (mitosis67.gprs.dnafinland.fi [62.78.122.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id CD5B11400AA; Fri, 28 Apr 2006 20:51:31 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id F33CBF0173; Fri, 28 Apr 2006 20:51:17 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17490.22037.951665.230556@rautu.tutpro.com> Date: Fri, 28 Apr 2006 20:51:17 +0300 From: Juha Heinanen To: "Dale R. Worley" Subject: RE: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt In-Reply-To: <1146245612.14513.38.camel@niagra.pingtel.com> References: <00a801c66ae6$ecc7d7a0$91c8000a@acmepacket.com> <1146245612.14513.38.camel@niagra.pingtel.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: 30ac594df0e66ffa5a93eb4c48bcb014 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 writes: > Of the (whatever) that the UA > can contact, the UA uses only the ones with the lowest priority number, > and among them, distributes traffic proportionately to weight. exactly. this is all that is needed. -- 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 Sat Apr 29 03:08:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZjWV-00011p-UT; Sat, 29 Apr 2006 03:05:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZjWT-00011k-TG for sip@ietf.org; Sat, 29 Apr 2006 03:05:45 -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 1FZjWR-0004A9-E5 for sip@ietf.org; Sat, 29 Apr 2006 03:05:45 -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 <0IYH0025Z29Q8T@szxga01-in.huawei.com> for sip@ietf.org; Sat, 29 Apr 2006 15:03:27 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IYH00MOU29QGG@szxga01-in.huawei.com> for sip@ietf.org; Sat, 29 Apr 2006 15:03:26 +0800 (CST) Received: from z13645a ([10.70.145.105]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IYH0009S32XRV@szxml01-in.huawei.com>; Sat, 29 Apr 2006 15:20:58 +0800 (CST) Date: Sat, 29 Apr 2006 15:02:58 +0800 From: Lavis Zhou Subject: Re: [Sip] Comments on draft-ietf-sip-connect-reuse-05.txt To: Cullen Jennings , Jeroen van Bemmel , sip@ietf.org Message-id: <001001c66b5a$f2b5d7b0$6991460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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: , Errors-To: sip-bounces@ietf.org Hi, A quite old thread, just pick it up. If the following idea had been proposed or discussed before, Pls let it be. Is it possible to extend the Alias parameter in Via to make it have 2 values: one as received, one as sent-by? The sender will set the alias value to received as normal case, but for virtual host, the sender will set it to sent-by, so the receiver can use either the received IP or the sent-by in via as alias host. Maybe it's one way to resolve it, but this will make the processing in receiver little complex. 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! *************************************************************************************** ----- Original Message ----- From: "Cullen Jennings" To: "Jeroen van Bemmel" ; Sent: Friday, March 17, 2006 3:21 AM Subject: Re: [Sip] Comments on draft-ietf-sip-connect-reuse-05.txt > On 3/14/06 10:06 AM, "Jeroen van Bemmel" wrote: > > >> > >> If a proxy hosts two domain one.example.com and two.example.com on the > >> same > >> IP and port, this does not seem to work. The wrong TLS connection would be > >> used. The problem is the cache is populated with the IP/port as the index > >> instead of using the cert name as the index. > >> > > > > At first I did not understand your point, until I saw your other posting on > > the -04 version: [copy] > > > > | Second, I don't think it works. If a server runs two virtual domain a.com > > | and b.com both on 1.2.3.4:5060 and use the TLS extended hello to separate > > | them, then if it connects to C as A.com, and later C wants to send a sips > > | message to B.com, it will deliver it over the connection to A.com which is > > | totally broken from a security point of view. > > > > So what you're saying is that a TLS connection should not be used to > > multiplex traffic for different virtual domains, even though it is known to > > end up at the exact same host and port? > > Yes exactly, the problem is when the message arrives on a connection that is > from both A.com and B.com, the proxy receiving it does not know if it came > from A.com or B.com and can't make the appropriate policy decisions on what > to do with based on which domain it came from. Proxy often implement white > or black list style authorization policy based on where a call came from. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip