From drage@alcatel-lucent.com Sat Aug 1 14:36:42 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB1FC3A6917 for ; Sat, 1 Aug 2009 14:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.617 X-Spam-Level: X-Spam-Status: No, score=-3.617 tagged_above=-999 required=5 tests=[AWL=-1.368, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljHpvLJ67LjC for ; Sat, 1 Aug 2009 14:36:42 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id AEB433A67B5 for ; Sat, 1 Aug 2009 14:36:40 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n71LaeQM026102 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sat, 1 Aug 2009 23:36:41 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Sat, 1 Aug 2009 23:36:40 +0200 From: "DRAGE, Keith (Keith)" To: "sipcore@ietf.org" Date: Sat, 1 Aug 2009 23:36:39 +0200 Thread-Topic: Mixing old and new H-I Thread-Index: AcoRv3Us9se50y13SZ+McVW1Ysx44AARIxQg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Subject: Re: [sipcore] Mixing old and new H-I X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2009 21:36:42 -0000 Just to use Hadriels mail to add the comments I was trying to address in th= e meeting on the same issue. We were discussing whether the absence of a tag provided information that i= t was RFC 4244 compliant rather than rfc4244bis. I indicated that understan= ding compliance with RFC 4244 was irrelevant. The reason I believe this is that I believe information will be missing no = matter what happens for a number of reasons: i) If it was RFC 4244 it did not understand the new codings is obviously on= e of them ii) the sender failed to supply the information (I do agree that adding at = least one tag should be mandatory in rfc4244bis, but there will always be s= omeone out there who breaks the rules). We also have other parameters appli= ed to entries whose information whose usage is only optional. iii) the information got removed along the route, either in the name of pri= vacy or in the name of someones bigger and better SBC thinking it knew best= . So I think it is better to just treat the absence of a tag as "tag unknown"= rather than trying to apportion compliance criteria. We then do what we do= with what we do with any other unknown information which is try and make t= he best of the supplied information that we can, same as we already do with= RFC 4244 and what we will have to do in the future when someone comes up w= ith a new use case that really required a new tag but previous implementati= ons don't support it. I think the only reason we would need to worry about RFC 4244 compliance of= the sender is if we are trying to return some protocol to the sender in th= e reverse direction that is based on that compliance. At the moment I have = seen no reason for applying that (and even then we should look at option ta= gs rather than the type of protocol used as a means of supporting it). regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Hadriel Kaplan > Sent: Friday, July 31, 2009 10:16 AM > To: sipcore@ietf.org > Subject: [sipcore] Mixing old and new H-I >=20 > Howdy, > Someone got up at the mic during the WG meeting and said=20 > "mixing old and new H-I will be really confusing and cause=20 > problems". That person (me) wasn't too smart. It occurred=20 > to me as I sat down that this is really just equivalent to if=20 > proxies/middleboxes didn't support 4244 or 4244bis period. =20 >=20 > In other words, even if we said "start from scratch" and do a=20 > new header-name, the fact is that any middlebox not=20 > supporting that new header-name would cause the same type of=20 > issues as middleboxes supporting legacy 4244 but not 4244bis.=20 > It's unavoidable. >=20 > Mea culpa. >=20 > -hadriel > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From drage@alcatel-lucent.com Sun Aug 2 04:02:42 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A8C73A6A97 for ; Sun, 2 Aug 2009 04:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.541 X-Spam-Level: X-Spam-Status: No, score=-3.541 tagged_above=-999 required=5 tests=[AWL=-1.292, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9uE8nh-wMuB for ; Sun, 2 Aug 2009 04:02:41 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 8E0273A63C9 for ; Sun, 2 Aug 2009 04:02:41 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n72B2f2W000857 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 2 Aug 2009 13:02:41 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Sun, 2 Aug 2009 13:02:41 +0200 From: "DRAGE, Keith (Keith)" To: "sipcore@ietf.org" Date: Sun, 2 Aug 2009 13:02:40 +0200 Thread-Topic: location-conveyance - used-for-routing parameter Thread-Index: AcoTXxDFjf5A0WJ6SCaEeWF9F37pog== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: "draft-ietf-sipcore-location-conveyance@tools.ietf.org" Subject: [sipcore] location-conveyance - used-for-routing parameter X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2009 11:02:42 -0000 I see in the document a number of sentences that say: This also gives the "used-for-routing" header=20 field parameter added meaning - as the receiving SIP entity knows which location URI the message was routed upon. and In such a=20 case, proxies MUST NOT remove any existing "used-for-routing" header field parameter. In this instance, the SIP server retargeting based on another locationValue MUST add the "used-for-routing" header=20 field parameter to the locationValue used for retargeting by this=20 server. This will result in a Geolocation header field indicating=20 that the request has been retargeted more than once, which is=20 allowed As currently written, one implication of this text is that at the recipient= , I can audit how the call was routed based on locationValue. I do not beli= eve this is true. All I know is that at some point along the call path, thi= s locationValue was used for routeing. It doesn't tell me which was the las= t one, and it does not tell me which ones got used more that once (as a hea= der field parameter can only appear once). This mail is therefore a sanity check to see that we are getting what we wa= nt out of the procedures for the use of this parameter, i.e. that we want t= o know only that at some point in the call path this locationValue out of s= everal has been used for routeing, and not that we want to know for example= the last locationValue used for routeing. When considering this issue, note that for example, these parameter values = will survive a change of Request-URI, e.g. due to call forwarding, so "used= -for-routing" may apply for how I got to the forwarding point on the old Re= quest-URI. I'll make proposals to change the text to more accurately reflect what I un= derstand the intentions to be when I see some response to this message givi= ng me some more background to the thinking. regards Keith= From fmenard@xittel.net Sun Aug 2 17:31:08 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E97BB3A6CB4; Sun, 2 Aug 2009 17:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4ad5EtX7HZG; Sun, 2 Aug 2009 17:31:08 -0700 (PDT) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id 428823A6CB6; Sun, 2 Aug 2009 17:31:08 -0700 (PDT) Received: from relay.infoteck.qc.ca ([205.151.16.15]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1MXlSH-0001N4-Uh; Sun, 02 Aug 2009 20:31:10 -0400 Received: from [207.96.236.65] (helo=[192.168.3.252]) by relay.infoteck.qc.ca with esmtpa (Exim 4.69) (envelope-from ) id 1MXlSH-0003m1-Ov; Sun, 02 Aug 2009 20:31:09 -0400 Message-Id: <54A3EF51-9255-402F-A915-E3FB186B42D6@xittel.net> From: Francois Menard To: ecrit@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) X-Priority: 1 Date: Sun, 2 Aug 2009 20:31:09 -0400 X-Mailer: Apple Mail (2.935.3) Cc: sipcore@ietf.org Subject: [sipcore] updating of section 6.7 of draft-ietf-ecrit-phonebcp-13.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 07:19:07 -0000 I propose to change section 6.7 of draft-ietf-ecrit-phonebcp-13.txt to reflect the switch to sipcore-location-conveyance, i.e. http://www.ietf.org/id/draft-ietf-sipcore-location-conveyance-01.txt Text should now read ED-33/SP-15 Location sent between SIP elements MUST be conveyed using [I-D.ietf-sipcore-location-conveyance]. F. Francois Menard fmenard@xittel.net From christer.holmberg@ericsson.com Mon Aug 3 00:40:56 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05B1C3A6AB4 for ; Mon, 3 Aug 2009 00:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.592 X-Spam-Level: X-Spam-Status: No, score=-3.592 tagged_above=-999 required=5 tests=[AWL=-1.343, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oy+aF96ihF79 for ; Mon, 3 Aug 2009 00:40:55 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 7D82C3A6A64 for ; Mon, 3 Aug 2009 00:40:54 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-0c-4a769487c63d Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id AB.F9.18827.784967A4; Mon, 3 Aug 2009 09:40:55 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 09:40:55 +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: Mon, 3 Aug 2009 09:40:54 +0200 Message-ID: In-Reply-To: <4A72E6C5.5070905@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery Thread-Index: AcoR3HGPnleY8hi9Qw+8c5xwJKKBJwCMHfZQ References: <4A72B495.80407@softarmor.com> <4A72E6C5.5070905@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Hadriel Kaplan" X-OriginalArrivalTime: 03 Aug 2009 07:40:55.0152 (UTC) FILETIME=[BBCF0F00:01CA140D] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 07:40:56 -0000 Hi, Regarding UUI. As we know, the R-URI value is not end-to-end. It may change in the path, due to normal SIP procedures. That is the reason we have History-Info: to record what has happened, for applications etc which needs that information. But, in my opinion History-Info is not a generic mechanism of transporting parameters transparently end-to-end, however, and UUI is a parameter which is supposed to be transported end-to-end. Therefor I think it would fit better in a separate header. Regards, Christer =20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Friday, July 31, 2009 3:43 PM To: Hadriel Kaplan Cc: SIPCORE Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery Hadriel Kaplan wrote: > I believe the exact charter says "Delivering request-URI and parameters to UAS via proxy to IESG". 4244bis does that. It's just delivering ALL request-uri's, so we're just arguing over how to figure out which one was the "right" one. >=20 > With regard to UUI, Francois' point was "H-I delivers Req-URI and its params, but there is no consensus UUI should be a Req-URI param". Right. But it does raise the bar for UUI. IIRC, one of the arguments against using R-URI params for UUI was the problem of them getting lost along the way - not reaching the destination. If that problem is removed by H-I, is there another compelling argument for introducing a new header? Thanks, Paul > -hadriel >=20 >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 >> Behalf Of Dean Willis >> Sent: Friday, July 31, 2009 5:09 AM >> To: SIPCORE >> Subject: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter=20 >> delivery >> >> >> I propose that since we're claiming that RFC 4244bis meets our=20 >> charter deliverable goal of delivery of parameters from UAC to UAS=20 >> that the use cases document for RFC 4244bis should document this use case. >> >> Further, if we find out that History-Info does NOT effectively meet=20 >> the requirements of the use case, then we should find some other=20 >> mechanism by which to meet that charter deliverable. >> >> -- >> Dean >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From sanjsinh@cisco.com Mon Aug 3 01:21:49 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37C5A28C0F9 for ; Mon, 3 Aug 2009 01:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIJVuoJlFbRn for ; Mon, 3 Aug 2009 01:21:48 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 117EF28C0F8 for ; Mon, 3 Aug 2009 01:21:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFM6dkpAZnmf/2dsb2JhbAC5HogpjhoFhBg X-IronPort-AV: E=Sophos;i="4.43,312,1246838400"; d="scan'208";a="52658306" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 03 Aug 2009 08:21:49 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n738LnA9020235; Mon, 3 Aug 2009 04:21:49 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n738LnwI003615; Mon, 3 Aug 2009 08:21:49 GMT Received: from xmb-rtp-201.amer.cisco.com ([64.102.31.13]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 04:21:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Aug 2009 04:21:47 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery Thread-Index: AcoR3HGPnleY8hi9Qw+8c5xwJKKBJwCMHfZQAAFowQA= References: <4A72B495.80407@softarmor.com><4A72E6C5.5070905@cisco.com> From: "Sanjay Sinha (sanjsinh)" To: "Christer Holmberg" , "Paul Kyzivat (pkyzivat)" , "Hadriel Kaplan" X-OriginalArrivalTime: 03 Aug 2009 08:21:49.0536 (UTC) FILETIME=[72BC5600:01CA1413] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3616; t=1249287709; x=1250151709; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20 |Subject:=20RE=3A=20[sipcore]=20RFC=204244=20bis=20use=20ca ses=20and=20UAC->UAS=20parameter=20delivery |Sender:=20 |To:=20=22Christer=20Holmberg=22=20,=0A=20=20=20=20=20=20=20=20=22Paul=20Kyzivat=20(pky zivat)=22=20,=0A=20=20=20=20=20=20=20=20 =22Hadriel=20Kaplan=22=20; bh=4hfTB+TeSAeCtK6BHB4kMCKeYC3xLeQsZPFOQVy2xYI=; b=C01y9uCAykfo36wp1JL/3Sw+jZtz6tNiPdNKJRsPXGPbIJJqgQe02KZl/i D77uy/D5jnBTJq6XFWxme8YE0yldDxB67b6gZZ1hvWO3WQVttq+ymwSlfOjm jo+1zFEGXp; Authentication-Results: rtp-dkim-2; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIPCORE Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 08:21:49 -0000 I agree that a new header seems suitable to carry this information. However there may be proxies and middleboxes (B2BUA) which may not pass this header transparently.=20 So does this mean that they will need to be upgraded as well to support this functionality? Sanjay >-----Original Message----- >From: sipcore-bounces@ietf.org=20 >[mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg >Sent: Monday, August 03, 2009 1:11 PM >To: Paul Kyzivat (pkyzivat); Hadriel Kaplan >Cc: SIPCORE >Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS=20 >parameter delivery > > >Hi, > >Regarding UUI. > >As we know, the R-URI value is not end-to-end. It may change=20 >in the path, due to normal SIP procedures. That is the reason we have >History-Info: to record what has happened, for applications=20 >etc which needs that information. > >But, in my opinion History-Info is not a generic mechanism of=20 >transporting parameters transparently end-to-end, however, and=20 >UUI is a parameter which is supposed to be transported=20 >end-to-end. Therefor I think it would fit better in a separate header. > >Regards, > >Christer > >=20 > >-----Original Message----- >From: sipcore-bounces@ietf.org=20 >[mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >Sent: Friday, July 31, 2009 3:43 PM >To: Hadriel Kaplan >Cc: SIPCORE >Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS=20 >parameter delivery > > > >Hadriel Kaplan wrote: >> I believe the exact charter says "Delivering request-URI and >parameters to UAS via proxy to IESG". 4244bis does that. =20 >It's just delivering ALL request-uri's, so we're just arguing=20 >over how to figure out which one was the "right" one. >>=20 >> With regard to UUI, Francois' point was "H-I delivers Req-URI and its >params, but there is no consensus UUI should be a Req-URI param". > >Right. > >But it does raise the bar for UUI. IIRC, one of the arguments=20 >against using R-URI params for UUI was the problem of them=20 >getting lost along the way - not reaching the destination. If=20 >that problem is removed by H-I, is there another compelling=20 >argument for introducing a new header? > > Thanks, > Paul > >> -hadriel >>=20 >>> -----Original Message----- >>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 >>> Behalf Of Dean Willis >>> Sent: Friday, July 31, 2009 5:09 AM >>> To: SIPCORE >>> Subject: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter=20 >>> delivery >>> >>> >>> I propose that since we're claiming that RFC 4244bis meets our=20 >>> charter deliverable goal of delivery of parameters from UAC to UAS=20 >>> that the use cases document for RFC 4244bis should document this use >case. >>> >>> Further, if we find out that History-Info does NOT effectively meet=20 >>> the requirements of the use case, then we should find some other=20 >>> mechanism by which to meet that charter deliverable. >>> >>> -- >>> Dean >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@cisco.com Mon Aug 3 06:00:29 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFB1928C17B for ; Mon, 3 Aug 2009 06:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ei3z4wls3IKs for ; Mon, 3 Aug 2009 06:00:28 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B6BDA28C15D for ; Mon, 3 Aug 2009 05:59:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHt7dkpAZnmf/2dsb2JhbAC5a4gpjikFhBg X-IronPort-AV: E=Sophos;i="4.43,314,1246838400"; d="scan'208";a="52639257" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 03 Aug 2009 12:59:15 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n73CxFEx011980; Mon, 3 Aug 2009 08:59:15 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n73CxFhJ024489; Mon, 3 Aug 2009 12:59:15 GMT 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.3959); Mon, 3 Aug 2009 08:59:15 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 08:59:14 -0400 Message-ID: <4A76DF22.6030808@cisco.com> Date: Mon, 03 Aug 2009 08:59:14 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Christer Holmberg References: <4A72B495.80407@softarmor.com> <4A72E6C5.5070905@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Aug 2009 12:59:15.0002 (UTC) FILETIME=[3434E1A0:01CA143A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3610; t=1249304355; x=1250168355; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20RFC=204244=20bis=20use=20ca ses=20and=20UAC->UAS=20parameter=20delivery |Sender:=20 |To:=20Christer=20Holmberg=20; bh=xbMXU4+MVMT2SY/n4li5JqziJbD08WEomrv6ubGUUGY=; b=mr1OZuv7sgF4nberDIZ9tEtJysttNqYEODeTnAw6Dt0+K7VR3enXlwLAPt /yhbXr9HCzqlo09VVpuCfH+FTwRZM3CmrWY/Uh309wVgBbxc44mWFfgThrRF D10n1IiKIg; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 13:00:29 -0000 There are two questions here: - Should this UUI requirement be viewed as a use case for a general mechanism for passing parameters from calling application to called application? (Or is it is some way "special" so that it requires a unique mechanism just for it?) - If this is a use case for a general mechanism, then what should the general mechanism be? IMO the answer to the first question is that this should be a use case for a general mechanism. The only rationale I see for treating it separately is an impatience to wait for a general mechanism. Dean has been making strong arguments about the second question. I really don't have anything to add to them right now. Thanks, Paul Christer Holmberg wrote: > Hi, > > Regarding UUI. > > As we know, the R-URI value is not end-to-end. It may change in the > path, due to normal SIP procedures. That is the reason we have > History-Info: to record what has happened, for applications etc which > needs that information. > > But, in my opinion History-Info is not a generic mechanism of > transporting parameters transparently end-to-end, however, and UUI is a > parameter which is supposed to be transported end-to-end. Therefor I > think it would fit better in a separate header. > > Regards, > > Christer > > > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Friday, July 31, 2009 3:43 PM > To: Hadriel Kaplan > Cc: SIPCORE > Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter > delivery > > > > Hadriel Kaplan wrote: >> I believe the exact charter says "Delivering request-URI and > parameters to UAS via proxy to IESG". 4244bis does that. It's just > delivering ALL request-uri's, so we're just arguing over how to figure > out which one was the "right" one. >> With regard to UUI, Francois' point was "H-I delivers Req-URI and its > params, but there is no consensus UUI should be a Req-URI param". > > Right. > > But it does raise the bar for UUI. IIRC, one of the arguments against > using R-URI params for UUI was the problem of them getting lost along > the way - not reaching the destination. If that problem is removed by > H-I, is there another compelling argument for introducing a new header? > > Thanks, > Paul > >> -hadriel >> >>> -----Original Message----- >>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >>> Behalf Of Dean Willis >>> Sent: Friday, July 31, 2009 5:09 AM >>> To: SIPCORE >>> Subject: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter >>> delivery >>> >>> >>> I propose that since we're claiming that RFC 4244bis meets our >>> charter deliverable goal of delivery of parameters from UAC to UAS >>> that the use cases document for RFC 4244bis should document this use > case. >>> Further, if we find out that History-Info does NOT effectively meet >>> the requirements of the use case, then we should find some other >>> mechanism by which to meet that charter deliverable. >>> >>> -- >>> Dean >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From br@brianrosen.net Mon Aug 3 06:35:41 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AD1A28C1CE; Mon, 3 Aug 2009 06:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L95VE1gjWPaW; Mon, 3 Aug 2009 06:35:40 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 2E57328C1D1; Mon, 3 Aug 2009 06:35:18 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MXxgh-0005QS-0Y; Mon, 03 Aug 2009 08:35:13 -0500 From: "Brian Rosen" To: "'Francois Menard'" , References: <54A3EF51-9255-402F-A915-E3FB186B42D6@xittel.net> In-Reply-To: <54A3EF51-9255-402F-A915-E3FB186B42D6@xittel.net> Date: Mon, 3 Aug 2009 09:34:51 -0400 Message-ID: <018401ca143f$3e6768a0$bb3639e0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoT8HzHZUDjMDiQRKiYDQxBXGBrSgATcL5g Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: sipcore@ietf.org Subject: Re: [sipcore] [Ecrit] updating of section 6.7 of draft-ietf-ecrit-phonebcp-13.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 13:35:41 -0000 This problem was noted before, and will be addressed in the next version Brian > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Francois Menard > Sent: Sunday, August 02, 2009 8:31 PM > To: ecrit@ietf.org > Cc: sipcore@ietf.org > Subject: [Ecrit] updating of section 6.7 of draft-ietf-ecrit-phonebcp- > 13.txt > Importance: High > > I propose to change section 6.7 of draft-ietf-ecrit-phonebcp-13.txt > > to reflect the switch to sipcore-location-conveyance, i.e. > > http://www.ietf.org/id/draft-ietf-sipcore-location-conveyance-01.txt > > Text should now read > > ED-33/SP-15 Location sent between SIP elements MUST be conveyed using > [I-D.ietf-sipcore-location-conveyance]. > > F. > > > Francois Menard > fmenard@xittel.net > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From dean.willis@softarmor.com Mon Aug 3 12:25:00 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD4203A6985 for ; Mon, 3 Aug 2009 12:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXtN0M0n305Q for ; Mon, 3 Aug 2009 12:25:00 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 714213A6E7F for ; Mon, 3 Aug 2009 12:24:28 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n73JONxW003590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 Aug 2009 14:24:24 -0500 Message-Id: From: Dean Willis To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 3 Aug 2009 14:24:16 -0500 References: <4A72B495.80407@softarmor.com> <4A72E6C5.5070905@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 19:25:00 -0000 On Aug 3, 2009, at 2:40 AM, Christer Holmberg wrote: > > Hi, > > Regarding UUI. > > As we know, the R-URI value is not end-to-end. It may change in the > path, due to normal SIP procedures. That is the reason we have > History-Info: to record what has happened, for applications etc which > needs that information. > > But, in my opinion History-Info is not a generic mechanism of > transporting parameters transparently end-to-end, however, and UUI > is a > parameter which is supposed to be transported end-to-end. Therefor I > think it would fit better in a separate header. Once again: The reason I lobbied for and requested the milestone for end-to-end delivery of request URI AND parameters was SO THAT PARAMETERS COULD BE DELIVERED END TO END. That was also the initial goal of Jonathan's ua-loose-route draft, although in that process, we discovered that the non-parameter part of the target URI was also needed for some applications. If we don't think that History-Info is a generic mechanism of transporting parameters transparently end-to-end, then it is NOT meeting the goal of the charter deliverable. Do we, or do we not, have consensus on whether or not History-Info is an adequate solution to the problem? -- Dean From christer.holmberg@ericsson.com Mon Aug 3 13:12:39 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC2B728C271 for ; Mon, 3 Aug 2009 13:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.521 X-Spam-Level: X-Spam-Status: No, score=-3.521 tagged_above=-999 required=5 tests=[AWL=-1.272, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDrbElnhhKWE for ; Mon, 3 Aug 2009 13:12:39 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id B821A28C26F for ; Mon, 3 Aug 2009 13:12:38 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-2e-4a7744b756f0 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id BC.4F.18827.7B4477A4; Mon, 3 Aug 2009 22:12:39 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 22:12: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Aug 2009 22:12:38 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery Thread-Index: AcoUcAYefMM33KsxQW6QqtqPrCDVZgABcF5J References: <4A72B495.80407@softarmor.com> <4A72E6C5.5070905@cisco.com> From: "Christer Holmberg" To: "Dean Willis" X-OriginalArrivalTime: 03 Aug 2009 20:12:39.0558 (UTC) FILETIME=[C0213A60:01CA1476] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 20:12:39 -0000 Hi, =20 > As we know, the R-URI value is not end-to-end. It may change in the > path, due to normal SIP procedures. That is the reason we have > History-Info: to record what has happened, for applications etc which > needs that information. > > But, in my opinion History-Info is not a generic mechanism of > transporting parameters transparently end-to-end, however, and UUI=20 > is a > parameter which is supposed to be transported end-to-end. Therefor I > think it would fit better in a separate header. >Once again: The reason I lobbied for and requested the milestone for=20 >end-to-end delivery of request URI AND parameters was SO THAT=20 >PARAMETERS COULD BE DELIVERED END TO END. That was also the initial=20 >goal of Jonathan's ua-loose-route draft, although in that process, we=20 >discovered that the non-parameter part of the target URI was also=20 >needed for some applications. The initial goal of Jonathan's draft was NOT to transport transparent = parameters end-to-end. =20 The initial goal was to make sure that the initial R-URI reaches the = other end. >If we don't think that History-Info is a generic mechanism of=20 >transporting parameters transparently end-to-end, then it is NOT=20 >meeting the goal of the charter deliverable. The purpose of H-I is to make sure that certain parameters, which may = change in the path, are transported end-to-end.=20 That is not the same as transporting transparant parameters end-to-end, = in my opinion. >Do we, or do we not, have consensus on whether or not History-Info is = an adequate solution to the problem? I certainly think that that History-Info is a solution to the initial = goal of Jonathan's draft. Sending transparant parameters end-to-end is, in my opinion, a completly = separate issue. Regards, Christer =20 =20 -- Dean From BeckW@telekom.de Tue Aug 4 04:15:40 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D2E63A701C for ; Tue, 4 Aug 2009 04:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdLczVDlP-6v for ; Tue, 4 Aug 2009 04:15:39 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 481F928C356 for ; Tue, 4 Aug 2009 04:14:04 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 04 Aug 2009 13:14:00 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 13:14: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Aug 2009 13:13:59 +0200 Message-ID: <4A956CE47D1066408D5C7EB34368A51104CD2BBE@S4DE8PSAAQC.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Initial NOTIFY without state information Thread-Index: AcoU9KnC3MkjwRwcTFKMhb8yuh6vnQ== From: To: X-OriginalArrivalTime: 04 Aug 2009 11:14:00.0623 (UTC) FILETIME=[AAF4DBF0:01CA14F4] X-Mailman-Approved-At: Tue, 04 Aug 2009 06:10:32 -0700 Cc: sipcore@ietf.org Subject: [sipcore] Initial NOTIFY without state information X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 11:15:40 -0000 What should a notifier send in its initial NOTIFY if it doesn't have = valid state information? Do end devices handle NOTIFYs with an empty body properly? What's the "neutral state" for MWI simple-message-summary? RfC 3265 states: 'If the resource has no meaningful state at the time that the SUBSCRIBE = message is processed, this NOTIFY message MAY contain an empty or neutral body. See = section 3.2.2. for further details on NOTIFY message generation.' Sigh. This paragraph does not contain much useful information for my = problem. How do I debug a customer's problem, if the notifier sends 'made up' state information = instead of indicating that it currently has no information at all? Sending an empty or neutral = state is purely optional, I can't rely on it. The paragraph doesn't even mention the case where the notifier loses = state information during an ongoing subscription. This may happen when a PUBLISH expires, or the = notifier loses a database connection. What is a "neutral state"? RfC 3265: 'Documents which define new event packages MUST define this "neutral state" in such a way that makes sense for their = application' If they only would. Eg. RfC 3842 (MWI) doesn't seem to contain any hint = about it. Cross-posted to contribute to the ongoing discussion of 3265bis. Regards, Wolfgang Beck -- Deutsche Telekom Netzproduktion GmbH=20 Zentrum Technik Einf=FChrung=20 Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt=20 +49 61516282832 (Tel.)=20 http://www.telekom.com=20 Deutsche Telekom Netzproduktion GmbH=20 Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender)=20 Gesch=E4ftsf=FChrung: Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren=20 Handelsregister: Amtsgericht Bonn HRB 14190=20 Sitz der Gesellschaft: Bonn=20 USt-IdNr.: DE 814645262 Erleben, was verbindet. From michael@voip.co.uk Tue Aug 4 09:16:12 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2C5A3A69B3 for ; Tue, 4 Aug 2009 09:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGzA+J6uXrJA for ; Tue, 4 Aug 2009 09:16:12 -0700 (PDT) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by core3.amsl.com (Postfix) with SMTP id 62E333A67B6 for ; Tue, 4 Aug 2009 09:16:11 -0700 (PDT) Received: from source ([209.85.219.226]) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKSnher39RDknoPLpSsonqIVuWyuUqUpKg@postini.com; Tue, 04 Aug 2009 09:16:14 PDT Received: by mail-ew0-f226.google.com with SMTP id 26so3983657ewy.29 for ; Tue, 04 Aug 2009 09:15:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.51.202 with SMTP id b52mr1613038wec.38.1249402542987; Tue, 04 Aug 2009 09:15:42 -0700 (PDT) In-Reply-To: References: <4A72B495.80407@softarmor.com> <4A72E6C5.5070905@cisco.com> Date: Tue, 4 Aug 2009 17:15:42 +0100 Message-ID: From: Michael Procter To: Christer Holmberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 16:16:12 -0000 2009/8/3 Christer Holmberg : > > Dean Willis: >>Once again: The reason I lobbied for and requested the milestone for >>end-to-end delivery of request URI AND parameters was SO THAT >>PARAMETERS COULD BE DELIVERED END TO END. That was also the initial >>goal of Jonathan's ua-loose-route draft, although in that process, we >>discovered that the non-parameter part of the target URI was also >>needed for some applications. > > The initial goal of Jonathan's draft was NOT to transport transparent parameters end-to-end. > > The initial goal was to make sure that the initial R-URI reaches the other end. And that includes any parameters that are part of it. I thought one of the main motivating reasons for ua-loose-route was to allow the "grid" parameter to be passed through transparently, and hence removed from the gruu draft. Yes, there are a number of reasons why the rest of the request URI is also useful, but I thought uri parameters were a key component, and not just a 'nice to have'. Regards, Michael From christer.holmberg@ericsson.com Tue Aug 4 12:59:42 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9F8A3A70A3 for ; Tue, 4 Aug 2009 12:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.457 X-Spam-Level: X-Spam-Status: No, score=-5.457 tagged_above=-999 required=5 tests=[AWL=0.792, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+7wTvONlBBh for ; Tue, 4 Aug 2009 12:59:42 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 5932428C35E for ; Tue, 4 Aug 2009 12:59:19 -0700 (PDT) X-AuditID: c1b4fb3e-b7b53ae000004f0b-2c-4a7893183041 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 87.2F.20235.813987A4; Tue, 4 Aug 2009 21:59:20 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 21:59:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Aug 2009 21:59:19 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery Thread-Index: AcoVHtLSfcsCjmq1RcuWE6Aek9KywgAHjuDk References: <4A72B495.80407@softarmor.com><4A72E6C5.5070905@cisco.com> From: "Christer Holmberg" To: "Michael Procter" X-OriginalArrivalTime: 04 Aug 2009 19:59:20.0453 (UTC) FILETIME=[0E3D3B50:01CA153E] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 19:59:42 -0000 Hi, =20 >>>Once again: The reason I lobbied for and requested the milestone for >>>end-to-end delivery of request URI AND parameters was SO THAT >>>PARAMETERS COULD BE DELIVERED END TO END. That was also the initial >>>goal of Jonathan's ua-loose-route draft, although in that process, we >>>discovered that the non-parameter part of the target URI was also >>>needed for some applications. >> >>The initial goal of Jonathan's draft was NOT to transport transparent = parameters end-to-end. >> >>The initial goal was to make sure that the initial R-URI reaches the = other end. > >And that includes any parameters that are part of it. =20 Of course.=20 =20 But, in my opinion the R-URI contains information (which may or may not = be changed in the path) used to targeting and finding the UAS - not to = transport network transparent data between the users.=20 =20 I don't think we should start to define out-of-context R-URI parameters = just because we have a mechanism (History-Info) which will ensure that = the UAS receives them. =20 >I thought one of the main motivating reasons for ua-loose-route was to = allow the >"grid" parameter to be passed through transparently, and hence removed >from the gruu draft. Yes, there are a number of reasons why the rest >of the request URI is also useful, but I thought uri parameters were a >key component, and not just a 'nice to have'. AFAIK, R-URI parameters are related to addressing, targeting and finding = the remote SIP user. UUI has nothing to do with that. UUI doesn't even = have anything to do with the core SIP session itself. Regards, Christer =20 From AUDET@nortel.com Tue Aug 4 14:53:00 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E702E28C3C0 for ; Tue, 4 Aug 2009 14:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.409 X-Spam-Level: X-Spam-Status: No, score=-6.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwDXt-yG9gGP for ; Tue, 4 Aug 2009 14:53:00 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 449C728C2D4 for ; Tue, 4 Aug 2009 14:52:56 -0700 (PDT) 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 n74Lqs604728; Tue, 4 Aug 2009 21:52:54 GMT 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 Date: Tue, 4 Aug 2009 16:52:38 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F50910C@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery thread-index: AcoUcAYefMM33KsxQW6QqtqPrCDVZgABcF5JADYEnwA= References: <4A72B495.80407@softarmor.com><4A72E6C5.5070905@cisco.com> From: "Francois Audet" To: "Christer Holmberg" , "Dean Willis" Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 21:53:01 -0000 I completely agree with Christer on this point. =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Monday, August 03, 2009 13:13 > To: Dean Willis > Cc: SIPCORE; Hadriel Kaplan > Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS=20 > parameter delivery >=20 > Hi, > =20 > > As we know, the R-URI value is not end-to-end. It may change in the=20 > > path, due to normal SIP procedures. That is the reason we have > > History-Info: to record what has happened, for applications=20 > etc which=20 > > needs that information. > > > > But, in my opinion History-Info is not a generic mechanism of=20 > > transporting parameters transparently end-to-end, however,=20 > and UUI is=20 > > a parameter which is supposed to be transported end-to-end.=20 > Therefor I=20 > > think it would fit better in a separate header. >=20 >=20 > >Once again: The reason I lobbied for and requested the milestone for=20 > >end-to-end delivery of request URI AND parameters was SO THAT=20 > >PARAMETERS COULD BE DELIVERED END TO END. That was also the initial=20 > >goal of Jonathan's ua-loose-route draft, although in that=20 > process, we=20 > >discovered that the non-parameter part of the target URI was also=20 > >needed for some applications. >=20 > The initial goal of Jonathan's draft was NOT to transport=20 > transparent parameters end-to-end. > =20 > The initial goal was to make sure that the initial R-URI=20 > reaches the other end. >=20 > >If we don't think that History-Info is a generic mechanism of=20 > >transporting parameters transparently end-to-end, then it is NOT=20 > >meeting the goal of the charter deliverable. >=20 >=20 > The purpose of H-I is to make sure that certain parameters,=20 > which may change in the path, are transported end-to-end.=20 >=20 > That is not the same as transporting transparant parameters=20 > end-to-end, in my opinion. >=20 >=20 > >Do we, or do we not, have consensus on whether or not=20 > History-Info is an adequate solution to the problem? >=20 > I certainly think that that History-Info is a solution to the=20 > initial goal of Jonathan's draft. >=20 > Sending transparant parameters end-to-end is, in my opinion,=20 > a completly separate issue. >=20 > Regards, >=20 > Christer >=20 > =20 >=20 > =20 >=20 >=20 >=20 > -- > Dean >=20 >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From john.elwell@siemens-enterprise.com Wed Aug 5 01:26:53 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AD303A7188 for ; Wed, 5 Aug 2009 01:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jy-svCvP11Wv for ; Wed, 5 Aug 2009 01:26:52 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 163F43A710E for ; Wed, 5 Aug 2009 01:26:44 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KNW00M0JA4MM1@siemenscomms.co.uk> for sipcore@ietf.org; Wed, 05 Aug 2009 09:26:46 +0100 (BST) Date: Wed, 05 Aug 2009 09:26:45 +0100 From: "Elwell, John" In-reply-to: <1ECE0EB50388174790F9694F77522CCF1F50910C@zrc2hxm0.corp.nortel.com> To: Francois Audet , Christer Holmberg , Dean Willis Message-id: <0D5F89FAC29E2C41B98A6A762007F5D002393AA6@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery Thread-Index: AcoUcAYefMM33KsxQW6QqtqPrCDVZgABcF5JADYEnwAAFTX0EA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4A72B495.80407@softarmor.com> <4A72E6C5.5070905@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F50910C@zrc2hxm0.corp.nortel.com> Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 08:26:53 -0000 It think we need to ask the question whether, for a given class of information included by the UAC in the original request (e.g., UUI), that information should be preserved if the request is retargeted. Clearly most classes of information should be preserved when the Request-URI changes because of rerouting, but when retargeting occurs the answer might not be so clear. So taking UUI, if A sends a request with UUI to B and the request is retargeted to C, is the UUI relevant to C too, or only to B? If the UUI has implicit semantics, it is not at all clear to me that it is equally applicable to C. If the information is equally applicable to B and C, this would argue in favour of a separate header field for UUI. If the information is specifically targeted at B, this would argue for a URI parameter. In that case, although C might receive the information via H-I, it will at least know that the UUI was targeted at B and it can take it or leave it, depending on application. The problem with a separate header field in this case is that C would need to trawl through H-I to find out whether the UUI really was targeted at C, and if H-I is not available (e.g., because of privacy or lack of support) or somehow obfuscated, then C might interpret the UUI wrongly. Having said this, the cc-uui draft states: "REQ-4: The mechanism will allow UUI to be able to survive proxy retargeting." This seems to suggest that UUI should have semantics of being equally applicable to B and C, and this would indeed suggest a separate header field. However, I am not sure I have interpreted that requirement correctly or the motivation for that requirement. John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Francois Audet > Sent: 04 August 2009 22:53 > To: Christer Holmberg; Dean Willis > Cc: SIPCORE; Hadriel Kaplan > Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS=20 > parameter delivery >=20 > I completely agree with Christer on this point. >=20 > =20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org=20 > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > > Sent: Monday, August 03, 2009 13:13 > > To: Dean Willis > > Cc: SIPCORE; Hadriel Kaplan > > Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS=20 > > parameter delivery > >=20 > > Hi, > > =20 > > > As we know, the R-URI value is not end-to-end. It may=20 > change in the=20 > > > path, due to normal SIP procedures. That is the reason we have > > > History-Info: to record what has happened, for applications=20 > > etc which=20 > > > needs that information. > > > > > > But, in my opinion History-Info is not a generic mechanism of=20 > > > transporting parameters transparently end-to-end, however,=20 > > and UUI is=20 > > > a parameter which is supposed to be transported end-to-end.=20 > > Therefor I=20 > > > think it would fit better in a separate header. > >=20 > >=20 > > >Once again: The reason I lobbied for and requested the=20 > milestone for=20 > > >end-to-end delivery of request URI AND parameters was SO THAT=20 > > >PARAMETERS COULD BE DELIVERED END TO END. That was also=20 > the initial=20 > > >goal of Jonathan's ua-loose-route draft, although in that=20 > > process, we=20 > > >discovered that the non-parameter part of the target URI was also=20 > > >needed for some applications. > >=20 > > The initial goal of Jonathan's draft was NOT to transport=20 > > transparent parameters end-to-end. > > =20 > > The initial goal was to make sure that the initial R-URI=20 > > reaches the other end. > >=20 > > >If we don't think that History-Info is a generic mechanism of=20 > > >transporting parameters transparently end-to-end, then it is NOT=20 > > >meeting the goal of the charter deliverable. > >=20 > >=20 > > The purpose of H-I is to make sure that certain parameters,=20 > > which may change in the path, are transported end-to-end.=20 > >=20 > > That is not the same as transporting transparant parameters=20 > > end-to-end, in my opinion. > >=20 > >=20 > > >Do we, or do we not, have consensus on whether or not=20 > > History-Info is an adequate solution to the problem? > >=20 > > I certainly think that that History-Info is a solution to the=20 > > initial goal of Jonathan's draft. > >=20 > > Sending transparant parameters end-to-end is, in my opinion,=20 > > a completly separate issue. > >=20 > > Regards, > >=20 > > Christer > >=20 > > =20 > >=20 > > =20 > >=20 > >=20 > >=20 > > -- > > Dean > >=20 > >=20 > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From christer.holmberg@ericsson.com Wed Aug 5 01:49:50 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 533AA3A68A3 for ; Wed, 5 Aug 2009 01:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.439 X-Spam-Level: X-Spam-Status: No, score=-5.439 tagged_above=-999 required=5 tests=[AWL=0.810, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6zTt1dOzIwk for ; Wed, 5 Aug 2009 01:49:49 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 0A1D83A71A3 for ; Wed, 5 Aug 2009 01:49:38 -0700 (PDT) X-AuditID: c1b4fb3e-b7b53ae000004f0b-75-4a7947a1b27b Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id F9.D5.20235.1A7497A4; Wed, 5 Aug 2009 10:49:37 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 10:49:32 +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 Date: Wed, 5 Aug 2009 10:49:30 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery Thread-Index: AcoUcAYefMM33KsxQW6QqtqPrCDVZgABcF5JADYEnwAAFTX0EAABiu9b References: <4A72B495.80407@softarmor.com> <4A72E6C5.5070905@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F50910C@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D002393AA6@GBNTHT12009MSX.gb002.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "Francois Audet" , "Dean Willis" X-OriginalArrivalTime: 05 Aug 2009 08:49:32.0101 (UTC) FILETIME=[A6871F50:01CA15A9] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 08:49:50 -0000 Hi John, >It think we need to ask the question whether, for a given class of >information included by the UAC in the original request (e.g., UUI), >that information should be preserved if the request is retargeted. >Clearly most classes of information should be preserved when the >Request-URI changes because of rerouting, but when retargeting occurs >the answer might not be so clear. > >So taking UUI, if A sends a request with UUI to B and the request is >retargeted to C, is the UUI relevant to C too, or only to B? If the UUI >has implicit semantics, it is not at all clear to me that it is equally >applicable to C. > >If the information is equally applicable to B and C, this would argue = in >favour of a separate header field for UUI. Yes. >If the information is specifically targeted at B, this would argue for = a >URI parameter. In that case, although C might receive the information >via H-I, it will at least know that the UUI was targeted at B and it = can >take it or leave it, depending on application. The problem with a >separate header field in this case is that C would need to trawl = through >H-I to find out whether the UUI really was targeted at C, and if H-I is >not available (e.g., because of privacy or lack of support) or somehow >obfuscated, then C might interpret the UUI wrongly. > > >Having said this, the cc-uui draft states: >"REQ-4: The mechanism will allow UUI to be able to survive proxy = retargeting." >This seems to suggest that UUI should have semantics of being equally >applicable to B and C, and this would indeed suggest a separate header >field. =20 That is my understanding, and that is why I have used "network = transparent" wording, and that is why I think the information does not = belong to the R-URI. =20 >However, I am not sure I have interpreted that requirement correctly or = the motivation for that requirement. =20 So, maybe we should clarify that first, then :) =20 Regards, =20 Christer =20 > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Francois Audet > Sent: 04 August 2009 22:53 > To: Christer Holmberg; Dean Willis > Cc: SIPCORE; Hadriel Kaplan > Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS > parameter delivery > > I completely agree with Christer on this point. > >=20 > > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > > Sent: Monday, August 03, 2009 13:13 > > To: Dean Willis > > Cc: SIPCORE; Hadriel Kaplan > > Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS > > parameter delivery > > > > Hi, > >=20 > > > As we know, the R-URI value is not end-to-end. It may > change in the > > > path, due to normal SIP procedures. That is the reason we have > > > History-Info: to record what has happened, for applications > > etc which > > > needs that information. > > > > > > But, in my opinion History-Info is not a generic mechanism of > > > transporting parameters transparently end-to-end, however, > > and UUI is > > > a parameter which is supposed to be transported end-to-end. > > Therefor I > > > think it would fit better in a separate header. > > > > > > >Once again: The reason I lobbied for and requested the > milestone for > > >end-to-end delivery of request URI AND parameters was SO THAT > > >PARAMETERS COULD BE DELIVERED END TO END. That was also > the initial > > >goal of Jonathan's ua-loose-route draft, although in that > > process, we > > >discovered that the non-parameter part of the target URI was also > > >needed for some applications. > > > > The initial goal of Jonathan's draft was NOT to transport > > transparent parameters end-to-end. > >=20 > > The initial goal was to make sure that the initial R-URI > > reaches the other end. > > > > >If we don't think that History-Info is a generic mechanism of > > >transporting parameters transparently end-to-end, then it is NOT > > >meeting the goal of the charter deliverable. > > > > > > The purpose of H-I is to make sure that certain parameters, > > which may change in the path, are transported end-to-end. > > > > That is not the same as transporting transparant parameters > > end-to-end, in my opinion. > > > > > > >Do we, or do we not, have consensus on whether or not > > History-Info is an adequate solution to the problem? > > > > I certainly think that that History-Info is a solution to the > > initial goal of Jonathan's draft. > > > > Sending transparant parameters end-to-end is, in my opinion, > > a completly separate issue. > > > > Regards, > > > > Christer > > > >=20 > > > >=20 > > > > > > > > -- > > Dean > > > > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From oej@edvina.net Wed Aug 5 04:39:37 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 489D53A691E for ; Wed, 5 Aug 2009 04:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.824 X-Spam-Level: X-Spam-Status: No, score=-1.824 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOLjaXZALgw9 for ; Wed, 5 Aug 2009 04:39:36 -0700 (PDT) Received: from ns.webway.se (ns.webway.se [87.96.134.125]) by core3.amsl.com (Postfix) with ESMTP id 7EDBB28C497 for ; Wed, 5 Aug 2009 04:39:26 -0700 (PDT) Received: from [192.168.40.12] (unknown [192.168.40.12]) by ns.webway.se (Postfix) with ESMTP id 7654228424; Wed, 5 Aug 2009 13:15:28 +0200 (CEST) Message-Id: <8376427F-05D6-483B-A5B2-EE20751A8B03@edvina.net> From: "Olle E. Johansson" To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 5 Aug 2009 13:39:28 +0200 X-Mailer: Apple Mail (2.935.3) Subject: [sipcore] draft-ietf-sipcore-sec-flows-00 :: Feedback X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 11:39:37 -0000 I vaguely remember that Adam mentioned this draft at the IETF75 =20 meeting... ;-) Here's a few comments from someone who hasn't followed previous =20 discussion on it: A bit more of education needed ------------------------------------------ I think that since the area of security in SIP is covered in multiple =20= documents that are hard to navigate through, this document needs to =20 act a bit more as a hitchhiker's guide for both developers and =20 implementors - administrators of servers. Currently it requires a =20 great deal of TLS/PKI knowledge to be useful, something I humbly =20 suggest we should try to work around, to lower the bar. We actually =20 want people to implement this, and to do it correctly. The document starts quickly and the reader is lost in section 4.1 =20 where we throw a text encoding of a CA certificate in his face. The =20 really important information is hidden in section 7 and 8 after page =20 up and down with various encoding schemes that for most people will =20 look and feel like a strange Swedish dialect from Kn=E4ckebr=F6dshult... = =20 Can we restructure and move these sections up front? Relationship between server host name, served domain and SRV/NAPTR =20 records needs to be explained = --------------------------------------------------------------------------= -------------------------------------------------------------------- Even though this is propably explained in five other documents, I =20 think we could clarify this a bit. - how does one host serve multiple domains? Is this reflected at all =20 in the server certificate? - If SRV for example.com points to stockholm.example.com - which CN =20 and which subjAltName should be used? The example used for domain "example.com" with hostname "example.com" =20= is avoiding this... Explain the certificate request (CSR) ------------------------------------------------- In the real world, not in developer labs, the procedure for creating =20 the key pair and generating a CSR on the host and the actual routine =20 that signs and produces a certificate are two different procedures. =20 This is not covered at all in this draft. In order to get the =20 necessary Subject Alternative Names in the cert, and the EKU =20 information, the CSR needs to reflect that. If you parse the scripts =20 and the OpenSSL config file in the back, you can find out how this =20 fits together. I think it would help all of us to actually have some =20 examples of the parsed CSR as well to clearly explain the procedure. Small changes -------------------- Page 4, section 1: ..."this document provides a common certificate that can be"... I =20 would change that to ..."this document provides a common certificate and private key that =20 can be"... Page 5, section 4.1 "Note that the basic constraints allow it to be used as a CA" -> "Note that the X.509v3 Basic Constraints in the certificate allows =20= it to be used as a CA, certificate authority." I would insert a sentence at the end: "This certificate is used to verify client and host certificates, it's =20= not used directly in the TLS call flow." Page 10, Section 4.3 - User certs "This is necessary for interoperating with CPIM gateway" Now, english is not my native language, but I want a small "a" before =20= "CPIM" ;-) I would change the first sentence to: "The user certificate, used in many apps, for fluffy@example.com is =20 shown below" This would explain why we have other apps and data in there and also =20 point out that one user cert can be used for many different apps. Also, the last sentence: "Note that the X509v3 Extended Key Usage attribute refers to the SIP =20 OID introduced in [12] - 1.3.6.1.5.5.7.3.20 Page 28, section 7 The last paragraph seems to be about S/MIME but it doesn't say so. I =20 think that could be clarified. Page 33 "These could be in two PEM files or one .p12 file." Many servers actually has both PEM sections - the private key and the =20= cert - in one combined file. Yes, it's confusing, but it's done. ------- Well, that was the result of reading and drinking a Nice Cup of Tea =20 (TM) :-) /Olle From pkyzivat@cisco.com Wed Aug 5 06:02:44 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13A823A7172 for ; Wed, 5 Aug 2009 06:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQ3BXV19OQzw for ; Wed, 5 Aug 2009 06:02:42 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id BF96A3A7003 for ; Wed, 5 Aug 2009 06:02:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOYfeUqrR7PE/2dsb2JhbAC8WIgpkGIFhBg X-IronPort-AV: E=Sophos;i="4.43,328,1246838400"; d="scan'208";a="360899872" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 05 Aug 2009 13:02:45 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n75D2jl6006139; Wed, 5 Aug 2009 06:02:45 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n75D2jiJ002484; Wed, 5 Aug 2009 13:02:45 GMT 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.3959); Wed, 5 Aug 2009 09:02:45 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 09:02:44 -0400 Message-ID: <4A7982F6.7080808@cisco.com> Date: Wed, 05 Aug 2009 09:02:46 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Elwell, John" References: <4A72B495.80407@softarmor.com> <4A72E6C5.5070905@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F50910C@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D002393AA6@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D002393AA6@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Aug 2009 13:02:44.0773 (UTC) FILETIME=[0610E550:01CA15CD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5531; t=1249477365; x=1250341365; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20RFC=204244=20bis=20use=20ca ses=20and=20UAC->UAS=20parameter=20delivery |Sender:=20; bh=3bzN7HIdIfPS+RD6TWTvf/nluOweWVHiMmn/OHDr8ZI=; b=nYEvVxjYRuvjBcVSnU1X8ewF/f7c5dy/kbv3CeJdhuboGAF74tZAElW6Xt AEsMzBhoLm5q2esoWDJto5kFYkvRXrZvOk8Bk+BXTCecnz0GE5ghYQHutjz2 yws47uWn39; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 13:02:44 -0000 Comment at end Elwell, John wrote: > It think we need to ask the question whether, for a given class of > information included by the UAC in the original request (e.g., UUI), > that information should be preserved if the request is retargeted. > Clearly most classes of information should be preserved when the > Request-URI changes because of rerouting, but when retargeting occurs > the answer might not be so clear. > > So taking UUI, if A sends a request with UUI to B and the request is > retargeted to C, is the UUI relevant to C too, or only to B? If the UUI > has implicit semantics, it is not at all clear to me that it is equally > applicable to C. > > If the information is equally applicable to B and C, this would argue in > favour of a separate header field for UUI. > > If the information is specifically targeted at B, this would argue for a > URI parameter. In that case, although C might receive the information > via H-I, it will at least know that the UUI was targeted at B and it can > take it or leave it, depending on application. The problem with a > separate header field in this case is that C would need to trawl through > H-I to find out whether the UUI really was targeted at C, and if H-I is > not available (e.g., because of privacy or lack of support) or somehow > obfuscated, then C might interpret the UUI wrongly. > > Having said this, the cc-uui draft states: > "REQ-4: The mechanism will allow UUI to be able to survive proxy > retargeting." > This seems to suggest that UUI should have semantics of being equally > applicable to B and C, and this would indeed suggest a separate header > field. However, I am not sure I have interpreted that requirement > correctly or the motivation for that requirement. I agree with you John. I have been struggling to understand this because of the confusing answers I have been getting about UUI formats. The encoding is not negotiated, and apparently can include private and/or national formats. If that is true, then the info may only apply to certain recipients. If retargeted, it may not be understood. I can imagine that it may even contain info that should not be seen by another party. Thanks, Paul > John > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Francois Audet >> Sent: 04 August 2009 22:53 >> To: Christer Holmberg; Dean Willis >> Cc: SIPCORE; Hadriel Kaplan >> Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS >> parameter delivery >> >> I completely agree with Christer on this point. >> >> >> >>> -----Original Message----- >>> From: sipcore-bounces@ietf.org >>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg >>> Sent: Monday, August 03, 2009 13:13 >>> To: Dean Willis >>> Cc: SIPCORE; Hadriel Kaplan >>> Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS >>> parameter delivery >>> >>> Hi, >>> >>>> As we know, the R-URI value is not end-to-end. It may >> change in the >>>> path, due to normal SIP procedures. That is the reason we have >>>> History-Info: to record what has happened, for applications >>> etc which >>>> needs that information. >>>> >>>> But, in my opinion History-Info is not a generic mechanism of >>>> transporting parameters transparently end-to-end, however, >>> and UUI is >>>> a parameter which is supposed to be transported end-to-end. >>> Therefor I >>>> think it would fit better in a separate header. >>> >>>> Once again: The reason I lobbied for and requested the >> milestone for >>>> end-to-end delivery of request URI AND parameters was SO THAT >>>> PARAMETERS COULD BE DELIVERED END TO END. That was also >> the initial >>>> goal of Jonathan's ua-loose-route draft, although in that >>> process, we >>>> discovered that the non-parameter part of the target URI was also >>>> needed for some applications. >>> The initial goal of Jonathan's draft was NOT to transport >>> transparent parameters end-to-end. >>> >>> The initial goal was to make sure that the initial R-URI >>> reaches the other end. >>> >>>> If we don't think that History-Info is a generic mechanism of >>>> transporting parameters transparently end-to-end, then it is NOT >>>> meeting the goal of the charter deliverable. >>> >>> The purpose of H-I is to make sure that certain parameters, >>> which may change in the path, are transported end-to-end. >>> >>> That is not the same as transporting transparant parameters >>> end-to-end, in my opinion. >>> >>> >>>> Do we, or do we not, have consensus on whether or not >>> History-Info is an adequate solution to the problem? >>> >>> I certainly think that that History-Info is a solution to the >>> initial goal of Jonathan's draft. >>> >>> Sending transparant parameters end-to-end is, in my opinion, >>> a completly separate issue. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> >>> >>> >>> -- >>> Dean >>> >>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Wed Aug 5 11:42:05 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEF573A6F2C for ; Wed, 5 Aug 2009 11:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.474 X-Spam-Level: X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxGQb8vd9g1n for ; Wed, 5 Aug 2009 11:42:04 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id E2C123A68F2 for ; Wed, 5 Aug 2009 11:42:02 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-58-4a79d27b53b2 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 58.E5.18827.B72D97A4; Wed, 5 Aug 2009 20:42:03 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 20:40: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Aug 2009 20:37:08 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery Thread-Index: AcoVzQg9t7wpyaUvTdu7qwFJ3jMWgAALrTsD References: <4A72B495.80407@softarmor.com> <4A72E6C5.5070905@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F50910C@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D002393AA6@GBNTHT12009MSX.gb002.siemens.net> <4A7982F6.7080808@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Elwell, John" X-OriginalArrivalTime: 05 Aug 2009 18:40:50.0041 (UTC) FILETIME=[41072690:01CA15FC] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 18:42:05 -0000 Hi, =20 >> Having said this, the cc-uui draft states: >> "REQ-4: The mechanism will allow UUI to be able to survive proxy >> retargeting." >> This seems to suggest that UUI should have semantics of being equally >> applicable to B and C, and this would indeed suggest a separate = header >> field. However, I am not sure I have interpreted that requirement >> correctly or the motivation for that requirement. > >I agree with you John. > >I have been struggling to understand this because of the confusing >answers I have been getting about UUI formats. The encoding is not >negotiated, and apparently can include private and/or national formats. >If that is true, then the info may only apply to certain recipients. If >retargeted, it may not be understood. I can imagine that it may even >contain info that should not be seen by another party. Well, that is a generic issue with SIP - it is difficult to control what = is going to happen with your data when certain actions take place in the = network. Regards, Christer =20 From pkyzivat@cisco.com Wed Aug 5 11:56:21 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61F393A71F8 for ; Wed, 5 Aug 2009 11:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.521 X-Spam-Level: X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3y+skxyOI9A for ; Wed, 5 Aug 2009 11:56:20 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 5EDED3A6C4C for ; Wed, 5 Aug 2009 11:56:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGNyeUpAZnmf/2dsb2JhbAC8b4gpkGwFhBg X-IronPort-AV: E=Sophos;i="4.43,330,1246838400"; d="scan'208";a="53078526" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 05 Aug 2009 18:56:22 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n75IuMFf000598; Wed, 5 Aug 2009 14:56:22 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n75IuMVY026298; Wed, 5 Aug 2009 18:56:22 GMT 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.3959); Wed, 5 Aug 2009 14:56:22 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 14:56:21 -0400 Message-ID: <4A79D5D1.8020209@cisco.com> Date: Wed, 05 Aug 2009 14:56:17 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Christer Holmberg References: <4A72B495.80407@softarmor.com> <4A72E6C5.5070905@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F50910C@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D002393AA6@GBNTHT12009MSX.gb002.siemens.net> <4A7982F6.7080808@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Aug 2009 18:56:21.0740 (UTC) FILETIME=[6C5D22C0:01CA15FE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1413; t=1249498582; x=1250362582; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20RFC=204244=20bis=20use=20ca ses=20and=20UAC->UAS=20parameter=20delivery |Sender:=20 |To:=20Christer=20Holmberg=20; bh=tspy125KehfLMaQCcECzIAvo3OwaWZd+ZtrYvyhUPlU=; b=jJ2k+7H41YarenCZ4rbTqcWnI3JqE/JVQbcg75t8YflNY2r70H2+HsevjD Osf04ag5IHZzJLYdyBm9L5Jmkl3SYQZBCYW7GJ6CoyL3dEi76lZVBpDvXSQa 8Kw0tUejoG; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 18:56:21 -0000 Christer Holmberg wrote: > Hi, > >>> Having said this, the cc-uui draft states: >>> "REQ-4: The mechanism will allow UUI to be able to survive proxy >>> retargeting." >>> This seems to suggest that UUI should have semantics of being equally >>> applicable to B and C, and this would indeed suggest a separate header >>> field. However, I am not sure I have interpreted that requirement >>> correctly or the motivation for that requirement. >> I agree with you John. >> >> I have been struggling to understand this because of the confusing >> answers I have been getting about UUI formats. The encoding is not >> negotiated, and apparently can include private and/or national formats. >> If that is true, then the info may only apply to certain recipients. If >> retargeted, it may not be understood. I can imagine that it may even >> contain info that should not be seen by another party. > > Well, that is a generic issue with SIP - it is difficult to control what is going to happen with your data when certain actions take place in the network. That's why we negotiate where we can, and standardize what can't be negotiated. And for the rest, we specify that you ignore what you don't understand, or else return an error. I don't think there is enough standardized here (for UUI) for the recipient to know if it understands what is received or not. Thanks, Paul From christer.holmberg@ericsson.com Wed Aug 5 12:06:48 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D50CA3A6D2B for ; Wed, 5 Aug 2009 12:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.423 X-Spam-Level: X-Spam-Status: No, score=-5.423 tagged_above=-999 required=5 tests=[AWL=0.826, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDPjkeWa2e48 for ; Wed, 5 Aug 2009 12:06:48 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 8C40E3A6980 for ; Wed, 5 Aug 2009 12:06:47 -0700 (PDT) X-AuditID: c1b4fb3c-b7b51ae000003b25-d6-4a79d848e2a9 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 4D.A1.15141.848D97A4; Wed, 5 Aug 2009 21:06:48 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 21:05: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Aug 2009 21:01:44 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery Thread-Index: AcoV/m5RYLdqVezoRtib4l7sCkn58QAAL6EX References: <4A72B495.80407@softarmor.com> <4A72E6C5.5070905@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F50910C@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D002393AA6@GBNTHT12009MSX.gb002.siemens.net> <4A7982F6.7080808@cisco.com> <4A79D5D1.8020209@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 05 Aug 2009 19:05:22.0907 (UTC) FILETIME=[AEECAAB0:01CA15FF] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 19:06:48 -0000 Hi, =20 >>>> Having said this, the cc-uui draft states: >>>> "REQ-4: The mechanism will allow UUI to be able to survive proxy >>>> retargeting." >>>> This seems to suggest that UUI should have semantics of being = equally >>>> applicable to B and C, and this would indeed suggest a separate = header >>>> field. However, I am not sure I have interpreted that requirement >>>> correctly or the motivation for that requirement. >>> I agree with you John. >>> >>> I have been struggling to understand this because of the confusing >>> answers I have been getting about UUI formats. The encoding is not >>> negotiated, and apparently can include private and/or national = formats. >>> If that is true, then the info may only apply to certain recipients. = If >>> retargeted, it may not be understood. I can imagine that it may even >>> contain info that should not be seen by another party. >> >>Well, that is a generic issue with SIP - it is difficult to control = what is going to happen with your data when certain actions take place = in the network. > >That's why we negotiate where we can, and standardize what can't be >negotiated. And for the rest, we specify that you ignore what you don't >understand, or else return an error. > >I don't think there is enough standardized here (for UUI) for the >recipient to know if it understands what is received or not. You have the same issue with message bodies sent in the INVITE, before = anything is negotiated. Feature tags can of course help in many cases. But, I wasn't talking about understanding, but whether you want the = receiver to receive the data in the first place. Once you've sent your = INVITE, you normally don't know what is going to happen in case of = retargets etc. Regards, Christer =20 From christer.holmberg@ericsson.com Wed Aug 5 12:13:09 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8330128C586 for ; Wed, 5 Aug 2009 12:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.456 X-Spam-Level: X-Spam-Status: No, score=-5.456 tagged_above=-999 required=5 tests=[AWL=0.793, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UYtodMCCM9w for ; Wed, 5 Aug 2009 12:13:08 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 4BF9128C0E5 for ; Wed, 5 Aug 2009 12:13:08 -0700 (PDT) X-AuditID: c1b4fb3c-b7b51ae000003b25-72-4a79d9c5dc6e Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 6B.C1.15141.5C9D97A4; Wed, 5 Aug 2009 21:13:09 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 21:12:07 +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 Aug 2009 21:12:06 +0200 Message-ID: In-Reply-To: <4A7194F8.2090801@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] New revision of the re-INVITE handling draft Thread-Index: AcoREw9uQHnyC624QXCw1N1O0oaVcwE7U5ew References: <4A6861CC.5030300@cisco.com> <4A686715.3070909@ericsson.com> <4A689184.5050903@cisco.com> <4A6DA26F.7060205@ericsson.com> <50CA10F698AAD6shin@softfront.co.jp> <4A7194F8.2090801@ericsson.com> From: "Christer Holmberg" To: "Gonzalo Camarillo" , "OKUMURA Shinji" X-OriginalArrivalTime: 05 Aug 2009 19:12:07.0371 (UTC) FILETIME=[A000F9B0:01CA1600] X-Brightmail-Tracker: AAAAAA== Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 19:13:09 -0000 Hi, What about this ICE specific way of sending provisional responses "reliably" without using PRACK? If I use ICE as part of a re-INVITE, can those responses refresh the remote target? I hope the answer is "no", but whatever it is I guess it would be good to mention it. Regards, Christer=20 -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 Sent: Thursday, July 30, 2009 3:41 PM To: OKUMURA Shinji Cc: Paul Kyzivat; gao.yang2@zte.com.cn; Christer Holmberg; SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft Hi, please, read Section 8 of the draft. It points to the relevant paragraphs of RFC 3261. Cheers, Gonzalo OKUMURA Shinji wrote: > Hi, >=20 > I want to confirm one basic points, >=20 > Gonzalo Camarillo >> Hi, >> >> it seems we can cover most cases with the following rules: >> >> 1) a reliable provisional response or a 2xx response to a target=20 >> refresh confirms that the UAS has refreshed the target. This refresh=20 >> is not rolled back under any circumstance (i.e., even if the target=20 >> refresh was a re-INVITE that eventually failed or the target refresh=20 >> was an UPDATE within a re-INVITE that eventually failed). >=20 > I don't dislike this rule. But AFAIK RFC3261 and 3262 don't allow=20 > (even if reliable) provisional responses to refresh targets. > Therefore I think this is a normative change. >=20 > Regards, >=20 > Shinji From L.Liess@telekom.de Thu Aug 6 02:21:05 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1317F3A6919 for ; Thu, 6 Aug 2009 02:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_LOAN=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJ1Ynmr26+l2 for ; Thu, 6 Aug 2009 02:21:04 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id C36AF3A67E3 for ; Thu, 6 Aug 2009 02:21:03 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail51.telekom.de with ESMTP; 06 Aug 2009 11:20:58 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 11:20:58 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Aug 2009 11:20:57 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A0034311AB@S4DE9JSAANI.ost.t-com.de> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-kaplan-sip-session-id-02 Thread-Index: AcoIqtSPtz9zA6BtTM6gsU7oe1O8AwAJuwTQAB4q6xAADJX2cAAWKS/AAyfqD0A= References: <1245876685.3748.61.camel@victoria-pingtel-com.us.nortel.com><40FB0FFB97588246A1BEFB05759DC8A00330040F@S4DE9JSAANI.ost.t-com.de><1247883283.4025.2.camel@victoria-pingtel-com.us.nortel.com> From: To: , X-OriginalArrivalTime: 06 Aug 2009 09:20:58.0480 (UTC) FILETIME=[354F7700:01CA1677] Cc: sipcore@ietf.org, dworley@nortel.com, R.Jesske@telekom.de Subject: Re: [sipcore] draft-kaplan-sip-session-id-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 09:21:05 -0000 Martin and Hadriel, also the session-id draft is targeted to trubleshouting, I see no reason = why Application Servers should not to use it for telephony services to = correlate call legs across B2BUAs (SBCs or other App.Servers), where = there is no other way to do this correlation.=20 Hadriel, could you agree with this usage of the Session-ID?=20 Kind regards,=20 Laura=20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On = Behalf Of H=FClsemann, Martin Sent: Tuesday, July 21, 2009 9:44 AM To: HKaplan@acmepacket.com; dworley@nortel.com; sipcore@ietf.org Subject: Re: [sipcore] draft-kaplan-sip-session-id-02 Hi Hadriel, but perhaps it would nevertheless be worth to describe the session-id = mechanism as a solution for some problems under certain conditions. = Perhaps also a recommendation can be included that because of the = restrictions implementors should be careful when using it, and that it = is only valid for certain network architectures. BR, Martin > -----Urspr=FCngliche Nachricht----- > Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Gesendet: Montag, 20. Juli 2009 23:10 > An: H=FClsemann, Martin; dworley@nortel.com; sipcore@ietf.org > Betreff: RE: [sipcore] draft-kaplan-sip-session-id-02 >=20 >=20 > Hi Martin,=20 >=20 > Correct - secure-call-id won't fix it if a B2BUA changes the=20 > Call-ID and something breaks due to that (because=20 > secure-call-id is a Call-ID). =20 >=20 > The other draft mechanism (session-id) tried to do that=20 > originally, but met with derision for not being able to fix=20 > everything possible in all cases.=20 >=20 > -hadriel >=20 > > -----Original Message----- > > From: Martin.Huelsemann@telekom.de=20 > > [mailto:Martin.Huelsemann@telekom.de] > > Sent: Monday, July 20, 2009 11:41 AM > >=20 > > what could be the solution for the case that there is a=20 > concatenation=20 > > of full B2BUAs? E.g. there are several App Servers, and the=20 > > application is targetting the last App Server in the=20 > signalling path=20 > > or respectively needs to match a certain dialog at this AS. I think=20 > > even a secure-call-id won't be successfull here? >=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From adam@nostrum.com Thu Aug 6 11:57:38 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E78853A68CC for ; Thu, 6 Aug 2009 11:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.967 X-Spam-Level: X-Spam-Status: No, score=-2.967 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRDpwmHSGT7f for ; Thu, 6 Aug 2009 11:57:38 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id E153728C183 for ; Thu, 6 Aug 2009 11:57:37 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n76IvcV8006053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Aug 2009 13:57:39 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A7B27A2.6050408@nostrum.com> Date: Thu, 06 Aug 2009 13:57:38 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] Meeting Minutes Posted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 18:57:39 -0000 [as chair] A draft set of minutes for the SIPCORE meeting in Stockholm is now available: http://www.ietf.org/proceedings/75/minutes/sipcore.html If you have any proposed amendments or corrections, please inform the chairs. /a From mary.barnes@nortel.com Thu Aug 6 16:00:20 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8550D3A69C2 for ; Thu, 6 Aug 2009 16:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-gHgSO9JuXq for ; Thu, 6 Aug 2009 16:00:19 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 8EF833A6962 for ; Thu, 6 Aug 2009 16:00:19 -0700 (PDT) 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 n76Mw0h19599; Thu, 6 Aug 2009 22:58:00 GMT 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: Thu, 6 Aug 2009 18:02:18 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F59F6A5@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A7B27A2.6050408@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Meeting Minutes Posted thread-index: AcoWx8xIDJkcGn4bQcy6Shi+19ttJwAIWZ/g References: <4A7B27A2.6050408@nostrum.com> From: "Mary Barnes" To: "Adam Roach" , Subject: Re: [sipcore] Meeting Minutes Posted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 23:00:20 -0000 Hi Adam, The discussion around Issue 2 is a little chaotic (of course that likely reflects part of the reality of the discussion), but there's one sentence in there attributed to me that could use some clarification (I'm not denying I might have said it that way): Mary Barnes: If we got the next hop and see that it is not tagged we want to the the aor (or what it is called) prefers alternative 1. =20 I would suggest changing to: =20 "Mary Barnes: If we get to the next hop and see that the previous hop is not tagged, we want to add the aor (or whatever it's called) tag to the previous entry - I prefer alternative 1." =20 Thanks, Mary.=20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach Sent: Thursday, August 06, 2009 1:58 PM To: SIPCORE Subject: [sipcore] Meeting Minutes Posted [as chair] A draft set of minutes for the SIPCORE meeting in Stockholm is now available: http://www.ietf.org/proceedings/75/minutes/sipcore.html If you have any proposed amendments or corrections, please inform the chairs. /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From adam@nostrum.com Fri Aug 7 15:17:51 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4760A3A6946 for ; Fri, 7 Aug 2009 15:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.914 X-Spam-Level: X-Spam-Status: No, score=-2.914 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4ekLvkrPlbS for ; Fri, 7 Aug 2009 15:17:50 -0700 (PDT) Received: from nostrum.com (shaman.nostrum.com [72.232.179.90]) by core3.amsl.com (Postfix) with ESMTP id D20603A6D24 for ; Fri, 7 Aug 2009 15:17:49 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n77MGare026153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Aug 2009 17:16:37 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A7CA7C4.3070605@nostrum.com> Date: Fri, 07 Aug 2009 17:16:36 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Mary Barnes References: <4A7B27A2.6050408@nostrum.com> <1ECE0EB50388174790F9694F77522CCF1F59F6A5@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F59F6A5@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org Subject: Re: [sipcore] Meeting Minutes Posted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 22:17:51 -0000 Thanks. The minutes have been revised to read as you suggest. /a Mary Barnes wrote: > Hi Adam, > > The discussion around Issue 2 is a little chaotic (of course that likely > reflects part of the reality of the discussion), but there's one > sentence in there attributed to me that could use some clarification > (I'm not denying I might have said it that way): > > Mary Barnes: If we got the next hop and see that it is not tagged we > want to the the aor (or what it is called) prefers alternative 1. > > I would suggest changing to: > "Mary Barnes: If we get to the next hop and see that the previous hop is > not tagged, we want to add the aor (or whatever it's called) tag to the > previous entry - I prefer alternative 1." > > Thanks, > Mary. > > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Adam Roach > Sent: Thursday, August 06, 2009 1:58 PM > To: SIPCORE > Subject: [sipcore] Meeting Minutes Posted > > [as chair] > > A draft set of minutes for the SIPCORE meeting in Stockholm is now > available: > > http://www.ietf.org/proceedings/75/minutes/sipcore.html > > If you have any proposed amendments or corrections, please inform the > chairs. > > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Sun Aug 9 04:19:08 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D71B13A67E3 for ; Sun, 9 Aug 2009 04:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.496 X-Spam-Level: X-Spam-Status: No, score=-5.496 tagged_above=-999 required=5 tests=[AWL=0.752, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+stjIzq4ssI for ; Sun, 9 Aug 2009 04:19:08 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 2FD5A3A681E for ; Sun, 9 Aug 2009 04:18:48 -0700 (PDT) X-AuditID: c1b4fb3e-b7b53ae000004f0b-58-4a7eb09af751 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id F6.54.20235.A90BE7A4; Sun, 9 Aug 2009 13:18:50 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 9 Aug 2009 13:18:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA18E3.1D344AA9" Date: Sun, 9 Aug 2009 13:18:26 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Questions on RFC 3608 (Service Route) Thread-Index: AcoY4x1thwMXzJdSQAmcNuliJbFb7w== From: "Christer Holmberg" To: "SIPCORE" X-OriginalArrivalTime: 09 Aug 2009 11:18:27.0451 (UTC) FILETIME=[1E1054B0:01CA18E3] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Questions on RFC 3608 (Service Route) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 11:19:09 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA18E3.1D344AA9 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, Section 4 of 3608 says: "4. The service route constructed by the registrar is the same for all contacts associated with a single address-of-record. This mechanism does not provide for contact-specific service routes." Q1: Where does this restriction come from in the first place? Q2: If multiple devices, sharing the same AOR, registers, the register requests may traverse different intermediates. If the registrar wants to insert intermeidates into the service route it is then not sure that the service route would not be the same for each device. Q3: If a single devices, using outboung, register requests may also traverse different intermedites. Again, if the registrar wants to insert intermediates it is not sure that the service routes would be the same for every outbound flow from that device. Q4: Have I missunderstood the text? Does the text only says that the service route field pointing to the registrar is the same? Regards, Christer ------_=_NextPart_001_01CA18E3.1D344AA9 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Questions on RFC 3608 (Service Route)

Hi,

Section 4 of 3608 says:

 "4. The service route = constructed by the registrar is the same for all
      = contacts associated with a single address-of-record.  This
      = mechanism does not provide for contact-specific service = routes."



Q1: Where does this restriction come = from in the first place?

Q2: If multiple devices, sharing the = same AOR, registers, the register requests may traverse different = intermediates. If the registrar wants to insert intermeidates into the = service route it is then not sure that the service route would not be = the same for each device.

Q3: If a single devices, using = outboung, register requests may also traverse different intermedites. = Again, if the registrar wants to insert intermediates it is not sure = that the service routes would be the same for every outbound flow from = that device.

Q4: Have I missunderstood the text? = Does the text only says that the service route field pointing to the = registrar is the same?

Regards,

Christer


------_=_NextPart_001_01CA18E3.1D344AA9-- From christer.holmberg@ericsson.com Sun Aug 9 04:44:47 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56DB03A6872 for ; Sun, 9 Aug 2009 04:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.521 X-Spam-Level: X-Spam-Status: No, score=-5.521 tagged_above=-999 required=5 tests=[AWL=0.727, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuEgU5B8aQa5 for ; Sun, 9 Aug 2009 04:44:46 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 218F43A68CF for ; Sun, 9 Aug 2009 04:44:45 -0700 (PDT) X-AuditID: c1b4fb3e-b7b53ae000004f0b-46-4a7eb6b006e9 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 76.94.20235.0B6BE7A4; Sun, 9 Aug 2009 13:44:48 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 9 Aug 2009 13:44:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA18E6.CB9C3021" Date: Sun, 9 Aug 2009 13:44:47 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Outbound and simultaneous registration transactions Thread-Index: AcoY5svUG52kXhW9S7m0XzwvAdgeRA== From: "Christer Holmberg" To: "SIPCORE" X-OriginalArrivalTime: 09 Aug 2009 11:44:48.0015 (UTC) FILETIME=[CC2741F0:01CA18E6] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Outbound and simultaneous registration transactions X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 11:44:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA18E6.CB9C3021 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi outbound lovers, Section 10.2 of RFC 3261 says: "UAs MUST NOT send a new registration (that is, containing new Contact header field values, as opposed to a retransmission) until they have received a final response from the registrar for the previous one or the previous REGISTER request has timed out." Q1: I don't find any text in the outbound spec which would allow sending new registrations for the SAME Contact header value until a response has been received from the previous register (or the prevoius has timed out). So, my assumption is that the only-one-register-transaction-at-a-time rule also applies to outbound, or? Section 6 of outbound says: "The registrar MUST be prepared to receive, simultaneously for the same AOR, some registrations that use instance-id and reg-id and some registrations that do not." I assume "simultaneously" doesn't refer to simultaneous registration transactions, but simultaneus valid registrations.=20 Regards, Christer ------_=_NextPart_001_01CA18E6.CB9C3021 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Outbound and simultaneous registration transactions

Hi outbound lovers,

Section 10.2 of RFC 3261 says:

"UAs MUST NOT send a new = registration (that is, containing new Contact
header field values, as opposed to a = retransmission) until they have
received a final response from the = registrar for the previous one or
the previous REGISTER request has = timed out."


Q1: I don't find any text in the = outbound spec which would allow sending new registrations for the SAME = Contact header value until a response has been received from the = previous register (or the prevoius has timed out). So, my assumption is = that the only-one-register-transaction-at-a-time rule also applies to = outbound, or?


Section 6 of outbound says:

"The registrar MUST be prepared to = receive, simultaneously for the same AOR, some registrations that use = instance-id and reg-id and some registrations that do = not."

I assume "simultaneously" = doesn't refer to simultaneous registration transactions, but simultaneus = valid registrations.

Regards,

Christer

------_=_NextPart_001_01CA18E6.CB9C3021-- From pkyzivat@cisco.com Sun Aug 9 17:54:39 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 111703A6CBF for ; Sun, 9 Aug 2009 17:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOQyZuRltmvf for ; Sun, 9 Aug 2009 17:54:38 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id DC18A3A6D90 for ; Sun, 9 Aug 2009 17:54:08 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEAABAMf0qQ/uCKe2dsb2JhbACaSwEBFiQGmlWIK44WBYQY X-IronPort-AV: E=Sophos;i="4.43,350,1246838400"; d="scan'208";a="46750951" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 10 Aug 2009 00:54:11 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7A0sB5L004653; Mon, 10 Aug 2009 02:54:11 +0200 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7A0sB7r025349; Mon, 10 Aug 2009 00:54:11 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 02:54:11 +0200 Received: from [10.86.254.133] ([10.86.254.133]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 02:54:11 +0200 Message-ID: <4A7F6FAD.3040500@cisco.com> Date: Sun, 09 Aug 2009 20:54:05 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Christer Holmberg References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2009 00:54:11.0356 (UTC) FILETIME=[12E78DC0:01CA1955] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1992; t=1249865651; x=1250729651; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Questions=20on=20RFC=203608 =20(Service=20Route) |Sender:=20; bh=oDAwFYHcBYw3O0jqxUMSJ5LzrEXSp9QGymx0UYfud7s=; b=ZQdBEsekcyny2Ll44jvRodhPgH3TldVf1Ma/zXpwntVmXazz/UThoLHzpJ 411KzrbD+zPA3VR5pfpIUtZrIqWuMwA0cV3N8qCms48FUR8wtZIN9bs2DIZi pRviUodmro; Authentication-Results: ams-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: SIPCORE Subject: Re: [sipcore] Questions on RFC 3608 (Service Route) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 00:54:39 -0000 Christer Holmberg wrote: > > Hi, > > Section 4 of 3608 says: > > "4. The service route constructed by the registrar is the same for all > contacts associated with a single address-of-record. This > mechanism does not provide for contact-specific service routes." > > > > Q1: Where does this restriction come from in the first place? I don't really know where it came from, but in some sense its an intrinsic limitation of the encoding. The service route is delivered in a response to a register request. That response is the same regardless of who sends the request, or what contacts are in the register request. Nor is a register request with a contact necessarily sent by a UA that receives requests on that address. If you wanted a service route per-contact, then I guess the service route would have to be encoded as a contact header parameter rather than a header field in the response. > Q2: If multiple devices, sharing the same AOR, registers, the register > requests may traverse different intermediates. If the registrar wants to > insert intermeidates into the service route it is then not sure that the > service route would not be the same for each device. > > Q3: If a single devices, using outboung, register requests may also > traverse different intermedites. Again, if the registrar wants to insert > intermediates it is not sure that the service routes would be the same > for every outbound flow from that device. Outbound changes things, but it post dates the 3608. Thanks, Paul > Q4: Have I missunderstood the text? Does the text only says that the > service route field pointing to the registrar is the same? > > Regards, > > Christer > > > > ------------------------------------------------------------------------ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From dean.willis@softarmor.com Sun Aug 9 20:50:08 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3DD03A6904 for ; Sun, 9 Aug 2009 20:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkpyQQDmazGP for ; Sun, 9 Aug 2009 20:50:08 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 0522F3A6960 for ; Sun, 9 Aug 2009 20:50:07 -0700 (PDT) Received: from [192.168.2.2] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n7A3o675005494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 9 Aug 2009 22:50:08 -0500 Message-ID: <4A7F98E9.8030007@softarmor.com> Date: Sun, 09 Aug 2009 22:50:01 -0500 From: Dean Willis User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Christer Holmberg References: In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Questions on RFC 3608 (Service Route) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 03:50:09 -0000 Christer Holmberg wrote: > Hi, > > Section 4 of 3608 says: > > "4. The service route constructed by the registrar is the same for all > contacts associated with a single address-of-record. This > mechanism does not provide for contact-specific service routes." > > > > Q1: Where does this restriction come from in the first place? >From the fact that REGISTER stores contacts, not routes, and that I could not convince anybody that this was a Bad Idea at the time. This bit of intransigence has lead us to GRUU, Outbound, and all sorts of other ugly hacks. SIP would be better off if we stored route vectors rather than just the terminal component (contact) for each registration. > > Q2: If multiple devices, sharing the same AOR, registers, the register > requests may traverse different intermediates. If the registrar wants to > insert intermeidates into the service route it is then not sure that the > service route would not be the same for each device. The inserted intermediaries MUST be the same for all contacts for the AOR. > > Q3: If a single devices, using outboung, register requests may also > traverse different intermedites. Again, if the registrar wants to insert > intermediates it is not sure that the service routes would be the same > for every outbound flow from that device. 3608 predates "outbound". One could certainly envision combining the two techniques; indeed, I proposed something similar at the time of 3608 but was roundly shouted down. I couldn't even sell you people on symmetric routing, which is why we have Service-Route and Path. We can't even agree the double-recording of record-route-fix as either a BCP or a revision of RFC 3261, so I don't expect a lot of progress here. > Q4: Have I missunderstood the text? Does the text only says that the > service route field pointing to the registrar is the same? Do keep in mind that the service route is unidirectional (complement to Path) and that it's really only meant to include the components within the registrar's realm of knowledge. The real limitation here is driven by the perceived difficulty in managing diverse route sets per AOR. We discussed at the time the possibility of storing Service-Route and Path for each contact, using a contact-indexed format in the response message to convey it, but this is non-trivial and would further increase the size of the already grossly inflated SIP response message, which as we know has UDP fragmentation issues. Insert here my usual diatribe that this is something any rational SDO would fix by cleaning up completely and incrementing the SIP version number. We could shed 300 pages of specs by just globally fixing REGISTER. But no, that would be too easy, we have to do this the hard way! -- dean From christer.holmberg@ericsson.com Mon Aug 10 00:25:40 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A6A23A6A48 for ; Mon, 10 Aug 2009 00:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.545 X-Spam-Level: X-Spam-Status: No, score=-5.545 tagged_above=-999 required=5 tests=[AWL=0.704, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwYfdqTuK2zv for ; Mon, 10 Aug 2009 00:25:39 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id DF9883A6968 for ; Mon, 10 Aug 2009 00:25:38 -0700 (PDT) X-AuditID: c1b4fb3c-b7b30ae000002b54-97-4a7fcb74d650 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 8C.B5.11092.47BCF7A4; Mon, 10 Aug 2009 09:25:40 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 09:25: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 Date: Mon, 10 Aug 2009 09:25:39 +0200 Message-ID: In-Reply-To: <4A7F6FAD.3040500@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Questions on RFC 3608 (Service Route) Thread-Index: AcoZVRPGSa/4iAfhRbiwi6pJ0bbtBwANeHiA References: <4A7F6FAD.3040500@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 10 Aug 2009 07:25:40.0640 (UTC) FILETIME=[C39BDA00:01CA198B] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Questions on RFC 3608 (Service Route) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 07:25:40 -0000 Hi,=20 >>Section 4 of 3608 says: >>=20 >>"4. The service route constructed by the registrar is the=20 >>same for all contacts associated with a single address-of-record. This >>mechanism does not provide for contact-specific service routes." >>=20 >>=20 >>=20 >>Q1: Where does this restriction come from in the first place? >=20 >I don't really know where it came from, but in some sense its=20 >an intrinsic limitation of the encoding. The service route is=20 >delivered in a response to a register request. That response=20 >is the same regardless of who sends the request, or what=20 >contacts are in the register request. > >Nor is a register request with a contact necessarily sent by=20 >a UA that receives requests on that address. Sure, but I don't think that has anything to do with the limitation. Such UA may not even care about the service route. >If you wanted a service route per-contact, then I guess the service route would have to be encoded as a contact header=20 >parameter rather than a header field in the response. Perhaps, but that is an encoding issue. >>Q2: If multiple devices, sharing the same AOR, registers, the register >>requests may traverse different intermediates. If the registrar wants=20 >>to insert intermeidates into the service route it is then not sure=20 >>that the service route would not be the same for each device. >>=20 >>Q3: If a single devices, using outboung, register requests may also=20 >>traverse different intermedites. Again, if the registrar wants to=20 >>insert intermediates it is not sure that the service routes would be=20 >>the same for every outbound flow from that device. >=20 >Outbound changes things, but it post dates the 3608. In that case the Outbound spec should indicate that the rule in 3608 does not apply when using Outbound. Regards, Christer From christer.holmberg@ericsson.com Mon Aug 10 10:49:42 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7B2B3A6C48 for ; Mon, 10 Aug 2009 10:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.567 X-Spam-Level: X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[AWL=-1.318, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rKnGWSJQCun for ; Mon, 10 Aug 2009 10:49:40 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 17A023A68B0 for ; Mon, 10 Aug 2009 10:48:41 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-ce-4a805d7cd866 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id F8.C6.18827.C7D508A4; Mon, 10 Aug 2009 19:48:44 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 19:48:44 +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 Date: Mon, 10 Aug 2009 19:48:43 +0200 Message-ID: <224F5CB1ECAB2C45BC64065AFD0339650406B50DCA@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Questions on RFC 3608 (Service Route) Thread-Index: AcoZVRPGSa/4iAfhRbiwi6pJ0bbtBwANeHiAAAjS8EA= References: <4A7F6FAD.3040500@cisco.com> From: "Christer Holmberg" To: "Christer Holmberg" , "Paul Kyzivat" X-OriginalArrivalTime: 10 Aug 2009 17:48:44.0339 (UTC) FILETIME=[CE07A030:01CA19E2] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Questions on RFC 3608 (Service Route) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 17:49:42 -0000 Hi, Another potential (it needs to be more investigated) issue with = identical service routes is that it may not always be possible to = determine from which device (or, in the case of outbound, on which flow) = an outgoing request is received. Giving a dedicated service route value for each registered device/flow = would allow the register, by looking at the Route header, to determine = where the outgoing request comes from. Regards, Christer > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 10. elokuuta 2009 10:26 > To: Paul Kyzivat > Cc: SIPCORE > Subject: Re: [sipcore] Questions on RFC 3608 (Service Route) > > > Hi, > > >>Section 4 of 3608 says: > >> > >>"4. The service route constructed by the registrar is the > same for all > >>contacts associated with a single address-of-record. > This > >>mechanism does not provide for contact-specific service routes." > >> > >> > >> > >>Q1: Where does this restriction come from in the first place? > > > >I don't really know where it came from, but in some sense its an > >intrinsic limitation of the encoding. The service route is > delivered in > >a response to a register request. That response is the same > regardless > >of who sends the request, or what contacts are in the > register request. > > > >Nor is a register request with a contact necessarily sent by > a UA that > >receives requests on that address. > > Sure, but I don't think that has anything to do with the limitation. > Such UA may not even care about the service route. > > >If you wanted a service route per-contact, then I guess the service > route would have to be encoded as a contact header > >parameter rather than a header field in the response. > > Perhaps, but that is an encoding issue. > > > >>Q2: If multiple devices, sharing the same AOR, registers, > the register > > >>requests may traverse different intermediates. If the > registrar wants > >>to insert intermeidates into the service route it is then not sure > >>that the service route would not be the same for each device. > >> > >>Q3: If a single devices, using outboung, register requests may also > >>traverse different intermedites. Again, if the registrar wants to > >>insert intermediates it is not sure that the service routes > would be > >>the same for every outbound flow from that device. > > > >Outbound changes things, but it post dates the 3608. > > In that case the Outbound spec should indicate that the rule > in 3608 does not apply when using Outbound. > > Regards, > > Christer > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From vkg@alcatel-lucent.com Mon Aug 10 11:01:16 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87F2E3A6EAE for ; Mon, 10 Aug 2009 11:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUz8LsFPyoQJ for ; Mon, 10 Aug 2009 11:01:15 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 6C4083A6EA7 for ; Mon, 10 Aug 2009 11:01:15 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id n7AI1Bhh027119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Aug 2009 13:01:12 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n7AI1BmI022326; Mon, 10 Aug 2009 13:01:11 -0500 (CDT) Message-ID: <4A806066.7010907@alcatel-lucent.com> Date: Mon, 10 Aug 2009 13:01:10 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Salvatore Loreto References: <4A49AC25.7010602@alcatel-lucent.com> <4A548AF7.6020505@ericsson.com> In-Reply-To: <4A548AF7.6020505@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: SIPCORE , "Jain, Rajnish" , Hadriel Kaplan Subject: Re: [sipcore] I-D on TCP/SCTP connection reuse X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 18:01:16 -0000 Salvatore: Sorry for the delayed response; circling back to unanswered emails after vacation and Stockholm IETF...please see inline. Salvatore Loreto wrote: > Hi Vijay, > > a question more relate to I-D.ietf-sip-connect-reuse that the draft in > object. > Working on draft-loreto-mmusic-sctp-sdp > I have > been told that no one has implemented yet TLS/SCTP as described > in RFC3436 (due to several technical problems), and instead TSVwg is > working on DTLS/SCTP in I-D.ietf-tsvwg-dtls-for-sctp. > So maybe it should be opportune recognize this fact also in the > I-D.ietf-sip-connect-reuse OK, great. This is good; thanks. > on Section 11 "Closing a TCP or SCTP connection", note that the *closure > alert* is something TLS specific. > Here you should talk more in TCP or SCTP specific way, and explain if > TCP half closed is supported or not, > or SCTP Graceful close. If you have specific text you can contribute, that'll be great. Otherwise, we will put something along these lines in the next revision and it'll be great if you could kindly review the addition at that time. Thanks again, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From ian.elz@ericsson.com Tue Aug 11 08:59:40 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72ECA3A6FFB for ; Tue, 11 Aug 2009 08:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fESZUfexZbqf for ; Tue, 11 Aug 2009 08:59:39 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A4B983A6B91 for ; Tue, 11 Aug 2009 08:59:01 -0700 (PDT) X-AuditID: c1b4fb3e-b7b53ae000004f0b-60-4a818a38e004 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 6F.70.20235.83A818A4; Tue, 11 Aug 2009 17:11:52 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 17:11:51 +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, 11 Aug 2009 17:11:50 +0200 Message-ID: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D002393AA6@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery Thread-Index: Acoalg06aC6gYBMzS+yjFD1f6pDNQw== References: <4A72B495.80407@softarmor.com><4A72E6C5.5070905@cisco.com><1ECE0EB50388174790F9694F77522CCF1F50910C@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D002393AA6@GBNTHT12009MSX.gb002.siemens.net> From: "Ian Elz" To: "Elwell, John" , "Francois Audet" , "Christer Holmberg" , "Dean Willis" X-OriginalArrivalTime: 11 Aug 2009 15:11:51.0454 (UTC) FILETIME=[0DED1BE0:01CA1A96] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 15:59:40 -0000 All, Sorry that I am a bit late in this thread but I am catching up. The UUI may only be applicable to B but there is no way of knowing if it may also be applicable to C following retargeting. This will depend upon the content of the UUI, its purpose and the capabilities of C. The key issue with trying to pass the UUI as a parameter in H-I is Privacy. If A sets Privacy to value 'header' then the H-I entry included by the retargeting to the registered terminal address will be removed and will not even be received by B let alone C as the H-I will be removed. You need to place the UUI in a separate header to ensure that it is not removed when the URI is protected by Privacy. Ian Elz -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: 05 August 2009 09:27 To: Francois Audet; Christer Holmberg; Dean Willis Cc: SIPCORE; Hadriel Kaplan Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery It think we need to ask the question whether, for a given class of information included by the UAC in the original request (e.g., UUI), that information should be preserved if the request is retargeted. Clearly most classes of information should be preserved when the Request-URI changes because of rerouting, but when retargeting occurs the answer might not be so clear. So taking UUI, if A sends a request with UUI to B and the request is retargeted to C, is the UUI relevant to C too, or only to B? If the UUI has implicit semantics, it is not at all clear to me that it is equally applicable to C. If the information is equally applicable to B and C, this would argue in favour of a separate header field for UUI. If the information is specifically targeted at B, this would argue for a URI parameter. In that case, although C might receive the information via H-I, it will at least know that the UUI was targeted at B and it can take it or leave it, depending on application. The problem with a separate header field in this case is that C would need to trawl through H-I to find out whether the UUI really was targeted at C, and if H-I is not available (e.g., because of privacy or lack of support) or somehow obfuscated, then C might interpret the UUI wrongly. Having said this, the cc-uui draft states: "REQ-4: The mechanism will allow UUI to be able to survive proxy retargeting." This seems to suggest that UUI should have semantics of being equally applicable to B and C, and this would indeed suggest a separate header field. However, I am not sure I have interpreted that requirement correctly or the motivation for that requirement. John > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Francois Audet > Sent: 04 August 2009 22:53 > To: Christer Holmberg; Dean Willis > Cc: SIPCORE; Hadriel Kaplan > Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter=20 > delivery >=20 > I completely agree with Christer on this point. >=20 > =20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > > Sent: Monday, August 03, 2009 13:13 > > To: Dean Willis > > Cc: SIPCORE; Hadriel Kaplan > > Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter > > delivery > >=20 > > Hi, > > =20 > > > As we know, the R-URI value is not end-to-end. It may > change in the > > > path, due to normal SIP procedures. That is the reason we have > > > History-Info: to record what has happened, for applications > > etc which > > > needs that information. > > > > > > But, in my opinion History-Info is not a generic mechanism of=20 > > > transporting parameters transparently end-to-end, however, > > and UUI is > > > a parameter which is supposed to be transported end-to-end.=20 > > Therefor I > > > think it would fit better in a separate header. > >=20 > >=20 > > >Once again: The reason I lobbied for and requested the > milestone for > > >end-to-end delivery of request URI AND parameters was SO THAT=20 > > >PARAMETERS COULD BE DELIVERED END TO END. That was also > the initial > > >goal of Jonathan's ua-loose-route draft, although in that > > process, we > > >discovered that the non-parameter part of the target URI was also=20 > > >needed for some applications. > >=20 > > The initial goal of Jonathan's draft was NOT to transport=20 > > transparent parameters end-to-end. > > =20 > > The initial goal was to make sure that the initial R-URI reaches the > > other end. > >=20 > > >If we don't think that History-Info is a generic mechanism of=20 > > >transporting parameters transparently end-to-end, then it is NOT=20 > > >meeting the goal of the charter deliverable. > >=20 > >=20 > > The purpose of H-I is to make sure that certain parameters, which=20 > > may change in the path, are transported end-to-end. > >=20 > > That is not the same as transporting transparant parameters=20 > > end-to-end, in my opinion. > >=20 > >=20 > > >Do we, or do we not, have consensus on whether or not > > History-Info is an adequate solution to the problem? > >=20 > > I certainly think that that History-Info is a solution to the=20 > > initial goal of Jonathan's draft. > >=20 > > Sending transparant parameters end-to-end is, in my opinion, a=20 > > completly separate issue. > >=20 > > Regards, > >=20 > > Christer > >=20 > > =20 > >=20 > > =20 > >=20 > >=20 > >=20 > > -- > > Dean > >=20 > >=20 > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From mdolly@att.com Tue Aug 11 09:48:01 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC9B23A67FD for ; Tue, 11 Aug 2009 09:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.314 X-Spam-Level: X-Spam-Status: No, score=-106.314 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQQq-mqy+jcu for ; Tue, 11 Aug 2009 09:48:00 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with SMTP id 64CB93A6F3F for ; Tue, 11 Aug 2009 09:48:00 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-6.tower-146.messagelabs.com!1250008739!10663496!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 16807 invoked from network); 11 Aug 2009 16:38:59 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-6.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 Aug 2009 16:38:59 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n7BGcx2R008103 for ; Tue, 11 Aug 2009 12:38:59 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n7BGctFs008079 for ; Tue, 11 Aug 2009 12:38:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Tue, 11 Aug 2009 12:38:54 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD497B@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery thread-index: Acoalg06aC6gYBMzS+yjFD1f6pDNQwADCoB4 From: "DOLLY, MARTIN C, ATTLABS" To: , , , , Cc: sipcore@ietf.org, HKaplan@acmepacket.com Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 16:48:01 -0000 V2Ugc2hvdWxkIHB1dCBVVUkgaW4gSC1JLiANCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0t LQ0KRnJvbTogc2lwY29yZS1ib3VuY2VzQGlldGYub3JnIDxzaXBjb3JlLWJvdW5jZXNAaWV0Zi5v cmc+DQpUbzogRWx3ZWxsLCBKb2huIDxqb2huLmVsd2VsbEBzaWVtZW5zLWVudGVycHJpc2UuY29t PjsgRnJhbmNvaXMgQXVkZXQgPGF1ZGV0QG5vcnRlbC5jb20+OyBDaHJpc3RlciBIb2xtYmVyZyA8 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPjsgRGVhbiBXaWxsaXMgPGRlYW4ud2lsbGlz QHNvZnRhcm1vci5jb20+DQpDYzogU0lQQ09SRSA8c2lwY29yZUBpZXRmLm9yZz47IEhhZHJpZWwg S2FwbGFuIDxIS2FwbGFuQGFjbWVwYWNrZXQuY29tPg0KU2VudDogVHVlIEF1ZyAxMSAxMToxMTo1 MCAyMDA5DQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIFJGQyA0MjQ0IGJpcyB1c2UgY2FzZXMgYW5k IFVBQy0+VUFTIHBhcmFtZXRlciBkZWxpdmVyeQ0KDQpBbGwsDQoNClNvcnJ5IHRoYXQgSSBhbSBh IGJpdCBsYXRlIGluIHRoaXMgdGhyZWFkIGJ1dCBJIGFtIGNhdGNoaW5nIHVwLg0KDQpUaGUgVVVJ IG1heSBvbmx5IGJlIGFwcGxpY2FibGUgdG8gQiBidXQgdGhlcmUgaXMgbm8gd2F5IG9mIGtub3dp bmcgaWYgaXQNCm1heSBhbHNvIGJlIGFwcGxpY2FibGUgdG8gQyBmb2xsb3dpbmcgcmV0YXJnZXRp bmcuIFRoaXMgd2lsbCBkZXBlbmQgdXBvbg0KdGhlIGNvbnRlbnQgb2YgdGhlIFVVSSwgaXRzIHB1 cnBvc2UgYW5kIHRoZSBjYXBhYmlsaXRpZXMgb2YgQy4NCg0KVGhlIGtleSBpc3N1ZSB3aXRoIHRy eWluZyB0byBwYXNzIHRoZSBVVUkgYXMgYSBwYXJhbWV0ZXIgaW4gSC1JIGlzDQpQcml2YWN5LiBJ ZiBBIHNldHMgUHJpdmFjeSB0byB2YWx1ZSAnaGVhZGVyJyB0aGVuIHRoZSBILUkgZW50cnkgaW5j bHVkZWQNCmJ5IHRoZSByZXRhcmdldGluZyB0byB0aGUgcmVnaXN0ZXJlZCB0ZXJtaW5hbCBhZGRy ZXNzIHdpbGwgYmUgcmVtb3ZlZA0KYW5kIHdpbGwgbm90IGV2ZW4gYmUgcmVjZWl2ZWQgYnkgQiBs ZXQgYWxvbmUgQyBhcyB0aGUgSC1JIHdpbGwgYmUNCnJlbW92ZWQuDQoNCllvdSBuZWVkIHRvIHBs YWNlIHRoZSBVVUkgaW4gYSBzZXBhcmF0ZSBoZWFkZXIgdG8gZW5zdXJlIHRoYXQgaXQgaXMgbm90 DQpyZW1vdmVkIHdoZW4gdGhlIFVSSSBpcyBwcm90ZWN0ZWQgYnkgUHJpdmFjeS4NCg0KSWFuIEVs eg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRWx3ZWxsLCBKb2huIFttYWls dG86am9obi5lbHdlbGxAc2llbWVucy1lbnRlcnByaXNlLmNvbV0gDQpTZW50OiAwNSBBdWd1c3Qg MjAwOSAwOToyNw0KVG86IEZyYW5jb2lzIEF1ZGV0OyBDaHJpc3RlciBIb2xtYmVyZzsgRGVhbiBX aWxsaXMNCkNjOiBTSVBDT1JFOyBIYWRyaWVsIEthcGxhbg0KU3ViamVjdDogUmU6IFtzaXBjb3Jl XSBSRkMgNDI0NCBiaXMgdXNlIGNhc2VzIGFuZCBVQUMtPlVBUyBwYXJhbWV0ZXINCmRlbGl2ZXJ5 DQoNCkl0IHRoaW5rIHdlIG5lZWQgdG8gYXNrIHRoZSBxdWVzdGlvbiB3aGV0aGVyLCBmb3IgYSBn aXZlbiBjbGFzcyBvZg0KaW5mb3JtYXRpb24gaW5jbHVkZWQgYnkgdGhlIFVBQyBpbiB0aGUgb3Jp Z2luYWwgcmVxdWVzdCAoZS5nLiwgVVVJKSwNCnRoYXQgaW5mb3JtYXRpb24gc2hvdWxkIGJlIHBy ZXNlcnZlZCBpZiB0aGUgcmVxdWVzdCBpcyByZXRhcmdldGVkLg0KQ2xlYXJseSBtb3N0IGNsYXNz ZXMgb2YgaW5mb3JtYXRpb24gc2hvdWxkIGJlIHByZXNlcnZlZCB3aGVuIHRoZQ0KUmVxdWVzdC1V UkkgY2hhbmdlcyBiZWNhdXNlIG9mIHJlcm91dGluZywgYnV0IHdoZW4gcmV0YXJnZXRpbmcgb2Nj dXJzDQp0aGUgYW5zd2VyIG1pZ2h0IG5vdCBiZSBzbyBjbGVhci4NCg0KU28gdGFraW5nIFVVSSwg aWYgQSBzZW5kcyBhIHJlcXVlc3Qgd2l0aCBVVUkgdG8gQiBhbmQgdGhlIHJlcXVlc3QgaXMNCnJl dGFyZ2V0ZWQgdG8gQywgaXMgdGhlIFVVSSByZWxldmFudCB0byBDIHRvbywgb3Igb25seSB0byBC PyBJZiB0aGUgVVVJDQpoYXMgaW1wbGljaXQgc2VtYW50aWNzLCBpdCBpcyBub3QgYXQgYWxsIGNs ZWFyIHRvIG1lIHRoYXQgaXQgaXMgZXF1YWxseQ0KYXBwbGljYWJsZSB0byBDLg0KDQpJZiB0aGUg aW5mb3JtYXRpb24gaXMgZXF1YWxseSBhcHBsaWNhYmxlIHRvIEIgYW5kIEMsIHRoaXMgd291bGQg YXJndWUgaW4NCmZhdm91ciBvZiBhIHNlcGFyYXRlIGhlYWRlciBmaWVsZCBmb3IgVVVJLg0KDQpJ ZiB0aGUgaW5mb3JtYXRpb24gaXMgc3BlY2lmaWNhbGx5IHRhcmdldGVkIGF0IEIsIHRoaXMgd291 bGQgYXJndWUgZm9yIGENClVSSSBwYXJhbWV0ZXIuIEluIHRoYXQgY2FzZSwgYWx0aG91Z2ggQyBt aWdodCByZWNlaXZlIHRoZSBpbmZvcm1hdGlvbg0KdmlhIEgtSSwgaXQgd2lsbCBhdCBsZWFzdCBr bm93IHRoYXQgdGhlIFVVSSB3YXMgdGFyZ2V0ZWQgYXQgQiBhbmQgaXQgY2FuDQp0YWtlIGl0IG9y IGxlYXZlIGl0LCBkZXBlbmRpbmcgb24gYXBwbGljYXRpb24uIFRoZSBwcm9ibGVtIHdpdGggYQ0K c2VwYXJhdGUgaGVhZGVyIGZpZWxkIGluIHRoaXMgY2FzZSBpcyB0aGF0IEMgd291bGQgbmVlZCB0 byB0cmF3bCB0aHJvdWdoDQpILUkgdG8gZmluZCBvdXQgd2hldGhlciB0aGUgVVVJIHJlYWxseSB3 YXMgdGFyZ2V0ZWQgYXQgQywgYW5kIGlmIEgtSSBpcw0Kbm90IGF2YWlsYWJsZSAoZS5nLiwgYmVj YXVzZSBvZiBwcml2YWN5IG9yIGxhY2sgb2Ygc3VwcG9ydCkgb3Igc29tZWhvdw0Kb2JmdXNjYXRl ZCwgdGhlbiBDIG1pZ2h0IGludGVycHJldCB0aGUgVVVJIHdyb25nbHkuDQoNCkhhdmluZyBzYWlk IHRoaXMsIHRoZSBjYy11dWkgZHJhZnQgc3RhdGVzOg0KIlJFUS00OiBUaGUgbWVjaGFuaXNtIHdp bGwgYWxsb3cgVVVJIHRvIGJlIGFibGUgdG8gc3Vydml2ZSBwcm94eQ0KICAgcmV0YXJnZXRpbmcu Ig0KVGhpcyBzZWVtcyB0byBzdWdnZXN0IHRoYXQgVVVJIHNob3VsZCBoYXZlIHNlbWFudGljcyBv ZiBiZWluZyBlcXVhbGx5DQphcHBsaWNhYmxlIHRvIEIgYW5kIEMsIGFuZCB0aGlzIHdvdWxkIGlu ZGVlZCBzdWdnZXN0IGEgc2VwYXJhdGUgaGVhZGVyDQpmaWVsZC4gSG93ZXZlciwgSSBhbSBub3Qg c3VyZSBJIGhhdmUgaW50ZXJwcmV0ZWQgdGhhdCByZXF1aXJlbWVudA0KY29ycmVjdGx5IG9yIHRo ZSBtb3RpdmF0aW9uIGZvciB0aGF0IHJlcXVpcmVtZW50Lg0KDQpKb2huDQoNCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc2lwY29yZS1ib3VuY2VzQGlldGYub3JnDQo+IFtt YWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRnJhbmNvaXMgQXVk ZXQNCj4gU2VudDogMDQgQXVndXN0IDIwMDkgMjI6NTMNCj4gVG86IENocmlzdGVyIEhvbG1iZXJn OyBEZWFuIFdpbGxpcw0KPiBDYzogU0lQQ09SRTsgSGFkcmllbCBLYXBsYW4NCj4gU3ViamVjdDog UmU6IFtzaXBjb3JlXSBSRkMgNDI0NCBiaXMgdXNlIGNhc2VzIGFuZCBVQUMtPlVBUyBwYXJhbWV0 ZXIgDQo+IGRlbGl2ZXJ5DQo+IA0KPiBJIGNvbXBsZXRlbHkgYWdyZWUgd2l0aCBDaHJpc3RlciBv biB0aGlzIHBvaW50Lg0KPiANCj4gIA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiA+IEZyb206IHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZw0KPiA+IFttYWlsdG86c2lwY29y ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0ZXIgSG9sbWJlcmcNCj4gPiBT ZW50OiBNb25kYXksIEF1Z3VzdCAwMywgMjAwOSAxMzoxMw0KPiA+IFRvOiBEZWFuIFdpbGxpcw0K PiA+IENjOiBTSVBDT1JFOyBIYWRyaWVsIEthcGxhbg0KPiA+IFN1YmplY3Q6IFJlOiBbc2lwY29y ZV0gUkZDIDQyNDQgYmlzIHVzZSBjYXNlcyBhbmQgVUFDLT5VQVMgcGFyYW1ldGVyDQoNCj4gPiBk ZWxpdmVyeQ0KPiA+IA0KPiA+IEhpLA0KPiA+ICANCj4gPiA+IEFzIHdlIGtub3csIHRoZSBSLVVS SSB2YWx1ZSBpcyBub3QgZW5kLXRvLWVuZC4gSXQgbWF5DQo+IGNoYW5nZSBpbiB0aGUNCj4gPiA+ IHBhdGgsIGR1ZSB0byBub3JtYWwgU0lQIHByb2NlZHVyZXMuIFRoYXQgaXMgdGhlIHJlYXNvbiB3 ZSBoYXZlDQo+ID4gPiBIaXN0b3J5LUluZm86IHRvIHJlY29yZCB3aGF0IGhhcyBoYXBwZW5lZCwg Zm9yIGFwcGxpY2F0aW9ucw0KPiA+IGV0YyB3aGljaA0KPiA+ID4gbmVlZHMgdGhhdCBpbmZvcm1h dGlvbi4NCj4gPiA+DQo+ID4gPiBCdXQsIGluIG15IG9waW5pb24gSGlzdG9yeS1JbmZvIGlzIG5v dCBhIGdlbmVyaWMgbWVjaGFuaXNtIG9mIA0KPiA+ID4gdHJhbnNwb3J0aW5nIHBhcmFtZXRlcnMg dHJhbnNwYXJlbnRseSBlbmQtdG8tZW5kLCBob3dldmVyLA0KPiA+IGFuZCBVVUkgaXMNCj4gPiA+ IGEgcGFyYW1ldGVyIHdoaWNoIGlzIHN1cHBvc2VkIHRvIGJlIHRyYW5zcG9ydGVkIGVuZC10by1l bmQuIA0KPiA+IFRoZXJlZm9yIEkNCj4gPiA+IHRoaW5rIGl0IHdvdWxkIGZpdCBiZXR0ZXIgaW4g YSBzZXBhcmF0ZSBoZWFkZXIuDQo+ID4gDQo+ID4gDQo+ID4gPk9uY2UgYWdhaW46IFRoZSByZWFz b24gSSBsb2JiaWVkIGZvciBhbmQgcmVxdWVzdGVkIHRoZQ0KPiBtaWxlc3RvbmUgZm9yDQo+ID4g PmVuZC10by1lbmQgZGVsaXZlcnkgb2YgcmVxdWVzdCBVUkkgQU5EIHBhcmFtZXRlcnMgd2FzIFNP IFRIQVQgDQo+ID4gPlBBUkFNRVRFUlMgQ09VTEQgQkUgREVMSVZFUkVEIEVORCBUTyBFTkQuIFRo YXQgd2FzIGFsc28NCj4gdGhlIGluaXRpYWwNCj4gPiA+Z29hbCBvZiBKb25hdGhhbidzIHVhLWxv b3NlLXJvdXRlIGRyYWZ0LCBhbHRob3VnaCBpbiB0aGF0DQo+ID4gcHJvY2Vzcywgd2UNCj4gPiA+ ZGlzY292ZXJlZCB0aGF0IHRoZSBub24tcGFyYW1ldGVyIHBhcnQgb2YgdGhlIHRhcmdldCBVUkkg d2FzIGFsc28gDQo+ID4gPm5lZWRlZCBmb3Igc29tZSBhcHBsaWNhdGlvbnMuDQo+ID4gDQo+ID4g VGhlIGluaXRpYWwgZ29hbCBvZiBKb25hdGhhbidzIGRyYWZ0IHdhcyBOT1QgdG8gdHJhbnNwb3J0 IA0KPiA+IHRyYW5zcGFyZW50IHBhcmFtZXRlcnMgZW5kLXRvLWVuZC4NCj4gPiAgDQo+ID4gVGhl IGluaXRpYWwgZ29hbCB3YXMgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIGluaXRpYWwgUi1VUkkgcmVh Y2hlcyB0aGUNCg0KPiA+IG90aGVyIGVuZC4NCj4gPiANCj4gPiA+SWYgd2UgZG9uJ3QgdGhpbmsg dGhhdCBIaXN0b3J5LUluZm8gaXMgYSBnZW5lcmljIG1lY2hhbmlzbSBvZiANCj4gPiA+dHJhbnNw b3J0aW5nIHBhcmFtZXRlcnMgdHJhbnNwYXJlbnRseSBlbmQtdG8tZW5kLCB0aGVuIGl0IGlzIE5P VCANCj4gPiA+bWVldGluZyB0aGUgZ29hbCBvZiB0aGUgY2hhcnRlciBkZWxpdmVyYWJsZS4NCj4g PiANCj4gPiANCj4gPiBUaGUgcHVycG9zZSBvZiBILUkgaXMgdG8gbWFrZSBzdXJlIHRoYXQgY2Vy dGFpbiBwYXJhbWV0ZXJzLCB3aGljaCANCj4gPiBtYXkgY2hhbmdlIGluIHRoZSBwYXRoLCBhcmUg dHJhbnNwb3J0ZWQgZW5kLXRvLWVuZC4NCj4gPiANCj4gPiBUaGF0IGlzIG5vdCB0aGUgc2FtZSBh cyB0cmFuc3BvcnRpbmcgdHJhbnNwYXJhbnQgcGFyYW1ldGVycyANCj4gPiBlbmQtdG8tZW5kLCBp biBteSBvcGluaW9uLg0KPiA+IA0KPiA+IA0KPiA+ID5EbyB3ZSwgb3IgZG8gd2Ugbm90LCBoYXZl IGNvbnNlbnN1cyBvbiB3aGV0aGVyIG9yIG5vdA0KPiA+IEhpc3RvcnktSW5mbyBpcyBhbiBhZGVx dWF0ZSBzb2x1dGlvbiB0byB0aGUgcHJvYmxlbT8NCj4gPiANCj4gPiBJIGNlcnRhaW5seSB0aGlu ayB0aGF0IHRoYXQgSGlzdG9yeS1JbmZvIGlzIGEgc29sdXRpb24gdG8gdGhlIA0KPiA+IGluaXRp YWwgZ29hbCBvZiBKb25hdGhhbidzIGRyYWZ0Lg0KPiA+IA0KPiA+IFNlbmRpbmcgdHJhbnNwYXJh bnQgcGFyYW1ldGVycyBlbmQtdG8tZW5kIGlzLCBpbiBteSBvcGluaW9uLCBhIA0KPiA+IGNvbXBs ZXRseSBzZXBhcmF0ZSBpc3N1ZS4NCj4gPiANCj4gPiBSZWdhcmRzLA0KPiA+IA0KPiA+IENocmlz dGVyDQo+ID4gDQo+ID4gIA0KPiA+IA0KPiA+ICANCj4gPiANCj4gPiANCj4gPiANCj4gPiAtLQ0K PiA+IERlYW4NCj4gPiANCj4gPiANCj4gPiANCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+ID4gc2lw Y29yZUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2lwY29yZQ0KPiA+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPiBzaXBjb3JlQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPiANCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUgbWFpbGlu ZyBsaXN0DQpzaXBjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NpcGNvcmUNCg== From mdolly@att.com Tue Aug 11 11:40:10 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD97B3A6A43 for ; Tue, 11 Aug 2009 11:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.355 X-Spam-Level: X-Spam-Status: No, score=-106.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DU8cOoK2wvCW for ; Tue, 11 Aug 2009 11:40:09 -0700 (PDT) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id 4BBE93A6783 for ; Tue, 11 Aug 2009 11:40:03 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-13.tower-129.messagelabs.com!1250015877!9135829!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 4140 invoked from network); 11 Aug 2009 18:37:57 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-13.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 Aug 2009 18:37:57 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n7BIbu4a016160 for ; Tue, 11 Aug 2009 14:37:56 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n7BIboIZ016123 for ; Tue, 11 Aug 2009 14:37:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Aug 2009 14:37:49 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA03F3D02A@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA02BD497B@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery thread-index: Acoalg06aC6gYBMzS+yjFD1f6pDNQwADCoB4AAQlgJA= References: <14C85D6CCBE92743AF33663BF5D24EBA02BD497B@gaalpa1msgusr7e.ugd.att.com> From: "DOLLY, MARTIN C, ATTLABS" To: "DOLLY, MARTIN C, ATTLABS" , , , , , Cc: sipcore@ietf.org, HKaplan@acmepacket.com Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 18:40:10 -0000 Sorry. We should NOT put UUI in H-I -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C, ATTLABS Sent: Tuesday, August 11, 2009 12:39 PM To: ian.elz@ericsson.com; john.elwell@siemens-enterprise.com; audet@nortel.com; christer.holmberg@ericsson.com; dean.willis@softarmor.com Cc: sipcore@ietf.org; HKaplan@acmepacket.com Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery We should put UUI in H-I.=20 ----- Original Message ----- From: sipcore-bounces@ietf.org To: Elwell, John ; Francois Audet ; Christer Holmberg ; Dean Willis Cc: SIPCORE ; Hadriel Kaplan Sent: Tue Aug 11 11:11:50 2009 Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery All, Sorry that I am a bit late in this thread but I am catching up. The UUI may only be applicable to B but there is no way of knowing if it may also be applicable to C following retargeting. This will depend upon the content of the UUI, its purpose and the capabilities of C. The key issue with trying to pass the UUI as a parameter in H-I is Privacy. If A sets Privacy to value 'header' then the H-I entry included by the retargeting to the registered terminal address will be removed and will not even be received by B let alone C as the H-I will be removed. You need to place the UUI in a separate header to ensure that it is not removed when the URI is protected by Privacy. Ian Elz -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: 05 August 2009 09:27 To: Francois Audet; Christer Holmberg; Dean Willis Cc: SIPCORE; Hadriel Kaplan Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery It think we need to ask the question whether, for a given class of information included by the UAC in the original request (e.g., UUI), that information should be preserved if the request is retargeted. Clearly most classes of information should be preserved when the Request-URI changes because of rerouting, but when retargeting occurs the answer might not be so clear. So taking UUI, if A sends a request with UUI to B and the request is retargeted to C, is the UUI relevant to C too, or only to B? If the UUI has implicit semantics, it is not at all clear to me that it is equally applicable to C. If the information is equally applicable to B and C, this would argue in favour of a separate header field for UUI. If the information is specifically targeted at B, this would argue for a URI parameter. In that case, although C might receive the information via H-I, it will at least know that the UUI was targeted at B and it can take it or leave it, depending on application. The problem with a separate header field in this case is that C would need to trawl through H-I to find out whether the UUI really was targeted at C, and if H-I is not available (e.g., because of privacy or lack of support) or somehow obfuscated, then C might interpret the UUI wrongly. Having said this, the cc-uui draft states: "REQ-4: The mechanism will allow UUI to be able to survive proxy retargeting." This seems to suggest that UUI should have semantics of being equally applicable to B and C, and this would indeed suggest a separate header field. However, I am not sure I have interpreted that requirement correctly or the motivation for that requirement. John > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Francois Audet > Sent: 04 August 2009 22:53 > To: Christer Holmberg; Dean Willis > Cc: SIPCORE; Hadriel Kaplan > Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter=20 > delivery >=20 > I completely agree with Christer on this point. >=20 > =20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > > Sent: Monday, August 03, 2009 13:13 > > To: Dean Willis > > Cc: SIPCORE; Hadriel Kaplan > > Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter > > delivery > >=20 > > Hi, > > =20 > > > As we know, the R-URI value is not end-to-end. It may > change in the > > > path, due to normal SIP procedures. That is the reason we have > > > History-Info: to record what has happened, for applications > > etc which > > > needs that information. > > > > > > But, in my opinion History-Info is not a generic mechanism of=20 > > > transporting parameters transparently end-to-end, however, > > and UUI is > > > a parameter which is supposed to be transported end-to-end.=20 > > Therefor I > > > think it would fit better in a separate header. > >=20 > >=20 > > >Once again: The reason I lobbied for and requested the > milestone for > > >end-to-end delivery of request URI AND parameters was SO THAT=20 > > >PARAMETERS COULD BE DELIVERED END TO END. That was also > the initial > > >goal of Jonathan's ua-loose-route draft, although in that > > process, we > > >discovered that the non-parameter part of the target URI was also=20 > > >needed for some applications. > >=20 > > The initial goal of Jonathan's draft was NOT to transport=20 > > transparent parameters end-to-end. > > =20 > > The initial goal was to make sure that the initial R-URI reaches the > > other end. > >=20 > > >If we don't think that History-Info is a generic mechanism of=20 > > >transporting parameters transparently end-to-end, then it is NOT=20 > > >meeting the goal of the charter deliverable. > >=20 > >=20 > > The purpose of H-I is to make sure that certain parameters, which=20 > > may change in the path, are transported end-to-end. > >=20 > > That is not the same as transporting transparant parameters=20 > > end-to-end, in my opinion. > >=20 > >=20 > > >Do we, or do we not, have consensus on whether or not > > History-Info is an adequate solution to the problem? > >=20 > > I certainly think that that History-Info is a solution to the=20 > > initial goal of Jonathan's draft. > >=20 > > Sending transparant parameters end-to-end is, in my opinion, a=20 > > completly separate issue. > >=20 > > Regards, > >=20 > > Christer > >=20 > > =20 > >=20 > > =20 > >=20 > >=20 > >=20 > > -- > > Dean > >=20 > >=20 > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From L.Liess@telekom.de Wed Aug 12 01:09:40 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EE363A695D for ; Wed, 12 Aug 2009 01:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.946 X-Spam-Level: X-Spam-Status: No, score=-2.946 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCNc61kCyWGh for ; Wed, 12 Aug 2009 01:09:39 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id D42923A68BE for ; Wed, 12 Aug 2009 01:09:05 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail81.telekom.de with ESMTP; 12 Aug 2009 09:55:06 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 09:55:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Aug 2009 09:55:06 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A00348106A@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA03F3D02A@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery Thread-Index: Acoalg06aC6gYBMzS+yjFD1f6pDNQwADCoB4AAQlgJAAGSkakA== References: <14C85D6CCBE92743AF33663BF5D24EBA02BD497B@gaalpa1msgusr7e.ugd.att.com> <14C85D6CCBE92743AF33663BF5D24EBA03F3D02A@gaalpa1msgusr7e.ugd.att.com> From: To: X-OriginalArrivalTime: 12 Aug 2009 07:55:06.0737 (UTC) FILETIME=[351C5E10:01CA1B22] Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 08:09:40 -0000 =20 H-I is frequently removed by B2BUAs at the network border so the UUI may not reach it's destination. For UUI, we need a new parameter which is not removed by intermediaries.=20 Kind regards Laura =20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C, ATTLABS Sent: Tuesday, August 11, 2009 8:38 PM To: DOLLY, MARTIN C, ATTLABS; ian.elz@ericsson.com; john.elwell@siemens-enterprise.com; audet@nortel.com; christer.holmberg@ericsson.com; dean.willis@softarmor.com Cc: sipcore@ietf.org; HKaplan@acmepacket.com Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery Sorry. We should NOT put UUI in H-I -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C, ATTLABS Sent: Tuesday, August 11, 2009 12:39 PM To: ian.elz@ericsson.com; john.elwell@siemens-enterprise.com; audet@nortel.com; christer.holmberg@ericsson.com; dean.willis@softarmor.com Cc: sipcore@ietf.org; HKaplan@acmepacket.com Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery We should put UUI in H-I.=20 ----- Original Message ----- From: sipcore-bounces@ietf.org To: Elwell, John ; Francois Audet ; Christer Holmberg ; Dean Willis Cc: SIPCORE ; Hadriel Kaplan Sent: Tue Aug 11 11:11:50 2009 Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery All, Sorry that I am a bit late in this thread but I am catching up. The UUI may only be applicable to B but there is no way of knowing if it may also be applicable to C following retargeting. This will depend upon the content of the UUI, its purpose and the capabilities of C. The key issue with trying to pass the UUI as a parameter in H-I is Privacy. If A sets Privacy to value 'header' then the H-I entry included by the retargeting to the registered terminal address will be removed and will not even be received by B let alone C as the H-I will be removed. You need to place the UUI in a separate header to ensure that it is not removed when the URI is protected by Privacy. Ian Elz -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: 05 August 2009 09:27 To: Francois Audet; Christer Holmberg; Dean Willis Cc: SIPCORE; Hadriel Kaplan Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery It think we need to ask the question whether, for a given class of information included by the UAC in the original request (e.g., UUI), that information should be preserved if the request is retargeted. Clearly most classes of information should be preserved when the Request-URI changes because of rerouting, but when retargeting occurs the answer might not be so clear. So taking UUI, if A sends a request with UUI to B and the request is retargeted to C, is the UUI relevant to C too, or only to B? If the UUI has implicit semantics, it is not at all clear to me that it is equally applicable to C. If the information is equally applicable to B and C, this would argue in favour of a separate header field for UUI. If the information is specifically targeted at B, this would argue for a URI parameter. In that case, although C might receive the information via H-I, it will at least know that the UUI was targeted at B and it can take it or leave it, depending on application. The problem with a separate header field in this case is that C would need to trawl through H-I to find out whether the UUI really was targeted at C, and if H-I is not available (e.g., because of privacy or lack of support) or somehow obfuscated, then C might interpret the UUI wrongly. Having said this, the cc-uui draft states: "REQ-4: The mechanism will allow UUI to be able to survive proxy retargeting." This seems to suggest that UUI should have semantics of being equally applicable to B and C, and this would indeed suggest a separate header field. However, I am not sure I have interpreted that requirement correctly or the motivation for that requirement. John > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Francois Audet > Sent: 04 August 2009 22:53 > To: Christer Holmberg; Dean Willis > Cc: SIPCORE; Hadriel Kaplan > Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter=20 > delivery >=20 > I completely agree with Christer on this point. >=20 > =20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > > Sent: Monday, August 03, 2009 13:13 > > To: Dean Willis > > Cc: SIPCORE; Hadriel Kaplan > > Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter > > delivery > >=20 > > Hi, > > =20 > > > As we know, the R-URI value is not end-to-end. It may > change in the > > > path, due to normal SIP procedures. That is the reason we have > > > History-Info: to record what has happened, for applications > > etc which > > > needs that information. > > > > > > But, in my opinion History-Info is not a generic mechanism of=20 > > > transporting parameters transparently end-to-end, however, > > and UUI is > > > a parameter which is supposed to be transported end-to-end.=20 > > Therefor I > > > think it would fit better in a separate header. > >=20 > >=20 > > >Once again: The reason I lobbied for and requested the > milestone for > > >end-to-end delivery of request URI AND parameters was SO THAT=20 > > >PARAMETERS COULD BE DELIVERED END TO END. That was also > the initial > > >goal of Jonathan's ua-loose-route draft, although in that > > process, we > > >discovered that the non-parameter part of the target URI was also=20 > > >needed for some applications. > >=20 > > The initial goal of Jonathan's draft was NOT to transport=20 > > transparent parameters end-to-end. > > =20 > > The initial goal was to make sure that the initial R-URI reaches the > > other end. > >=20 > > >If we don't think that History-Info is a generic mechanism of=20 > > >transporting parameters transparently end-to-end, then it is NOT=20 > > >meeting the goal of the charter deliverable. > >=20 > >=20 > > The purpose of H-I is to make sure that certain parameters, which=20 > > may change in the path, are transported end-to-end. > >=20 > > That is not the same as transporting transparant parameters=20 > > end-to-end, in my opinion. > >=20 > >=20 > > >Do we, or do we not, have consensus on whether or not > > History-Info is an adequate solution to the problem? > >=20 > > I certainly think that that History-Info is a solution to the=20 > > initial goal of Jonathan's draft. > >=20 > > Sending transparant parameters end-to-end is, in my opinion, a=20 > > completly separate issue. > >=20 > > Regards, > >=20 > > Christer > >=20 > > =20 > >=20 > > =20 > >=20 > >=20 > >=20 > > -- > > Dean > >=20 > >=20 > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Wed Aug 12 04:48:05 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECBAC3A69FF for ; Wed, 12 Aug 2009 04:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.548 X-Spam-Level: X-Spam-Status: No, score=-5.548 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VR9oUwLytap8 for ; Wed, 12 Aug 2009 04:48:01 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id D11C03A63EC for ; Wed, 12 Aug 2009 04:47:59 -0700 (PDT) X-AuditID: c1b4fb3c-b7bccae00000385d-54-4a82abb61357 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 42.E6.14429.6BBA28A4; Wed, 12 Aug 2009 13:47:02 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 13:46:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA1B42.89C045F4" Date: Wed, 12 Aug 2009 13:46:32 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Keep issue Thread-Index: AcobQomYUHTVGOV8T62VRreLv4KpBw== From: "Christer Holmberg" To: "SIPCORE" X-OriginalArrivalTime: 12 Aug 2009 11:46:33.0692 (UTC) FILETIME=[8A6189C0:01CA1B42] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Keep issue X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 11:48:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1B42.89C045F4 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, In Stockholm there was concensus to use the Contact/Path/Record-Route headers for negotiating keep-alive, instead of the Via header. There is a problem, however: Assume a UA sends an INVITE, and inserts "keep" in the Contact header. The UA will not get back that Contact header in any response (the response will contain the Contact of the remote user), so it will not see if the next hop has added "=3Dyes" to the parameter, indicating it wants the UA to send keep-alives towards it. The problem does not exist for Path and Record-Route, which will be used by proxies to indicate willingness to support keep-alive, since those headers always "come back" in the response. Now, going back to Via is probably not a good idea, because then we again end up with the problem which was the reason not to use Via. One alternative is to not add "=3Dyes" to the keep parameter inserted by the previous hop, but that the entity which wants to receive keep-alive indicates so in the header inserted by itself. Example: UAC P1 UAS ---- INVITE -----------------> Contact: UA; keep-s //indication that the UAC supports sending of keep-alives ---- INVITE -----------------> Contact: UAC; keep-s R-R: P1; keep-r, keep-s //indication that P1 supports receiving of keep-alives from the UAC, and that it supports sending of keep-alives =20 <--- 200 ----------------------- Contact: UAS R-R: P1; keep-r, keep-s //the UAS does not want to receive keep-alives from P1, so it does not insert an indication in its own Contact <--- 200 ----------------------- Contact: UAS R-R: P1; keep-r, keep-s //even if the UAC doesn't get back its own Contact, it can see from the R-R that P1 wants to receive keep-alives The advantage of this alternative is that an entity will not modify a parameter (by inserting the "=3Dyes" value) inserted by someone else. Regards, Christer =20 =20 ------_=_NextPart_001_01CA1B42.89C045F4 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Keep issue

Hi,

In Stockholm there was concensus to use = the Contact/Path/Record-Route headers for negotiating keep-alive, = instead of the Via header.

There is a problem, however:

Assume a UA sends an INVITE, and = inserts "keep" in the Contact header. The UA will not get back = that Contact header in any response (the response will contain the = Contact of the remote user), so it will not see if the next hop has = added "=3Dyes" to the parameter, indicating it wants the UA to = send keep-alives towards it.

The problem does not exist for Path and = Record-Route, which will be used by proxies to indicate willingness to = support keep-alive, since those headers always "come back" in = the response.

Now, going back to Via is probably not = a good idea, because then we again end up with the problem which was the = reason not to use Via.

One alternative is to not add = "=3Dyes" to the keep parameter inserted by the previous hop, = but that the entity which wants to receive keep-alive indicates so in = the header inserted by itself.

Example:

UAC         &= nbsp;           &n= bsp;    = P1            = ;            =    UAS

---- INVITE = ----------------->
     Contact: UA; = keep-s        =         =         =         =         //indication that the UAC = supports sending of keep-alives

         &nbs= p;            = ;            ---- = INVITE ----------------->
         &nbs= p;            = ;            = Contact: UAC; keep-s
         &nbs= p;            = ;            R-R: = P1; keep-r, keep-s       =         //indication that P1 supports = receiving of keep-alives from the UAC, and that it supports sending of = keep-alives

  
         &nbs= p;            = ;            = <--- 200 -----------------------
         &nbs= p;            = ;            = Contact: UAS
         &nbs= p;            = ;            R-R: = P1; keep-r, keep-s       =         //the UAS does not want to = receive keep-alives from P1, so it does not insert an indication in its = own Contact

<--- 200 = -----------------------
      = Contact: UAS
      R-R: = P1; keep-r, keep-s   =         =         =         //even if the UAC doesn't get = back its own Contact, it can see from the R-R that P1 wants to receive = keep-alives


The advantage of this alternative is = that an entity will not modify a parameter (by inserting the = "=3Dyes" value) inserted by someone else.

Regards,

Christer
         &nbs= p;            = ;          
  

------_=_NextPart_001_01CA1B42.89C045F4-- From pkyzivat@cisco.com Wed Aug 12 05:50:36 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74FF93A6A91 for ; Wed, 12 Aug 2009 05:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THn4cAM2iPTT for ; Wed, 12 Aug 2009 05:50:35 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 1BE353A6886 for ; Wed, 12 Aug 2009 05:50:35 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKNWgkqrR7MV/2dsb2JhbAC5BYgrkRMFhBk X-IronPort-AV: E=Sophos;i="4.43,367,1246838400"; d="scan'208";a="194793127" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 12 Aug 2009 12:47:00 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7CCl0N0016052; Wed, 12 Aug 2009 05:47:00 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7CCkx6P009931; Wed, 12 Aug 2009 12:47:00 GMT 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.3959); Wed, 12 Aug 2009 08:46:59 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 08:46:59 -0400 Message-ID: <4A82B9C2.9080409@cisco.com> Date: Wed, 12 Aug 2009 08:46:58 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: L.Liess@telekom.de References: <14C85D6CCBE92743AF33663BF5D24EBA02BD497B@gaalpa1msgusr7e.ugd.att.com> <14C85D6CCBE92743AF33663BF5D24EBA03F3D02A@gaalpa1msgusr7e.ugd.att.com> <40FB0FFB97588246A1BEFB05759DC8A00348106A@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A00348106A@S4DE9JSAANI.ost.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Aug 2009 12:46:59.0170 (UTC) FILETIME=[FB559420:01CA1B4A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8637; t=1250081220; x=1250945220; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20RFC=204244=20bis=20use=20ca ses=20and=20UAC->UAS=20parameter=20delivery |Sender:=20; bh=61DbsHWQsdrg8P3eUVBNXHne+TimdB94atBSOQKNvHw=; b=hAzjnWBnBj8RPh5sgA6mUFVmHJODpoSSz6KHUNOlBPnWMdJysEWpRsFTvQ I02K+Mp21gEPliKkvi9Fkz6icHiu7sp2bJf+XVwAUfDTWjXvKmSHBHqE50Dt TxAwin2KqEQjSEV/bOAPCkEOk8QF+I5k6grl4HM4zbDYaGh2YXaOg=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: sipcore@ietf.org Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 12:50:36 -0000 L.Liess@telekom.de wrote: > > > H-I is frequently removed by B2BUAs at the network border so the UUI may > not reach it's destination. For UUI, we need a new parameter which is > not removed by intermediaries. When talking about a new thing added to a message, you can have no guarantees of whether it will survive B2BUAs or not. If the B2BUA removes anything it doesn't understand then this new thing may will not survive. Or it might remove it even when it does understand it if it thinks this might contain sensitive information. Thanks, Paul > Kind regards > Laura > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of DOLLY, MARTIN C, ATTLABS > Sent: Tuesday, August 11, 2009 8:38 PM > To: DOLLY, MARTIN C, ATTLABS; ian.elz@ericsson.com; > john.elwell@siemens-enterprise.com; audet@nortel.com; > christer.holmberg@ericsson.com; dean.willis@softarmor.com > Cc: sipcore@ietf.org; HKaplan@acmepacket.com > Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter > delivery > > Sorry. We should NOT put UUI in H-I > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of DOLLY, MARTIN C, ATTLABS > Sent: Tuesday, August 11, 2009 12:39 PM > To: ian.elz@ericsson.com; john.elwell@siemens-enterprise.com; > audet@nortel.com; christer.holmberg@ericsson.com; > dean.willis@softarmor.com > Cc: sipcore@ietf.org; HKaplan@acmepacket.com > Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter > delivery > > We should put UUI in H-I. > > ----- Original Message ----- > From: sipcore-bounces@ietf.org > To: Elwell, John ; Francois Audet > ; Christer Holmberg ; > Dean Willis > Cc: SIPCORE ; Hadriel Kaplan > Sent: Tue Aug 11 11:11:50 2009 > Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter > delivery > > All, > > Sorry that I am a bit late in this thread but I am catching up. > > The UUI may only be applicable to B but there is no way of knowing if it > may also be applicable to C following retargeting. This will depend upon > the content of the UUI, its purpose and the capabilities of C. > > The key issue with trying to pass the UUI as a parameter in H-I is > Privacy. If A sets Privacy to value 'header' then the H-I entry included > by the retargeting to the registered terminal address will be removed > and will not even be received by B let alone C as the H-I will be > removed. > > You need to place the UUI in a separate header to ensure that it is not > removed when the URI is protected by Privacy. > > Ian Elz > > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: 05 August 2009 09:27 > To: Francois Audet; Christer Holmberg; Dean Willis > Cc: SIPCORE; Hadriel Kaplan > Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter > delivery > > It think we need to ask the question whether, for a given class of > information included by the UAC in the original request (e.g., UUI), > that information should be preserved if the request is retargeted. > Clearly most classes of information should be preserved when the > Request-URI changes because of rerouting, but when retargeting occurs > the answer might not be so clear. > > So taking UUI, if A sends a request with UUI to B and the request is > retargeted to C, is the UUI relevant to C too, or only to B? If the UUI > has implicit semantics, it is not at all clear to me that it is equally > applicable to C. > > If the information is equally applicable to B and C, this would argue in > favour of a separate header field for UUI. > > If the information is specifically targeted at B, this would argue for a > URI parameter. In that case, although C might receive the information > via H-I, it will at least know that the UUI was targeted at B and it can > take it or leave it, depending on application. The problem with a > separate header field in this case is that C would need to trawl through > H-I to find out whether the UUI really was targeted at C, and if H-I is > not available (e.g., because of privacy or lack of support) or somehow > obfuscated, then C might interpret the UUI wrongly. > > Having said this, the cc-uui draft states: > "REQ-4: The mechanism will allow UUI to be able to survive proxy > retargeting." > This seems to suggest that UUI should have semantics of being equally > applicable to B and C, and this would indeed suggest a separate header > field. However, I am not sure I have interpreted that requirement > correctly or the motivation for that requirement. > > John > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Francois Audet >> Sent: 04 August 2009 22:53 >> To: Christer Holmberg; Dean Willis >> Cc: SIPCORE; Hadriel Kaplan >> Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter >> delivery >> >> I completely agree with Christer on this point. >> >> >> >>> -----Original Message----- >>> From: sipcore-bounces@ietf.org >>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg >>> Sent: Monday, August 03, 2009 13:13 >>> To: Dean Willis >>> Cc: SIPCORE; Hadriel Kaplan >>> Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter > >>> delivery >>> >>> Hi, >>> >>>> As we know, the R-URI value is not end-to-end. It may >> change in the >>>> path, due to normal SIP procedures. That is the reason we have >>>> History-Info: to record what has happened, for applications >>> etc which >>>> needs that information. >>>> >>>> But, in my opinion History-Info is not a generic mechanism of >>>> transporting parameters transparently end-to-end, however, >>> and UUI is >>>> a parameter which is supposed to be transported end-to-end. >>> Therefor I >>>> think it would fit better in a separate header. >>> >>>> Once again: The reason I lobbied for and requested the >> milestone for >>>> end-to-end delivery of request URI AND parameters was SO THAT >>>> PARAMETERS COULD BE DELIVERED END TO END. That was also >> the initial >>>> goal of Jonathan's ua-loose-route draft, although in that >>> process, we >>>> discovered that the non-parameter part of the target URI was also >>>> needed for some applications. >>> The initial goal of Jonathan's draft was NOT to transport >>> transparent parameters end-to-end. >>> >>> The initial goal was to make sure that the initial R-URI reaches the > >>> other end. >>> >>>> If we don't think that History-Info is a generic mechanism of >>>> transporting parameters transparently end-to-end, then it is NOT >>>> meeting the goal of the charter deliverable. >>> >>> The purpose of H-I is to make sure that certain parameters, which >>> may change in the path, are transported end-to-end. >>> >>> That is not the same as transporting transparant parameters >>> end-to-end, in my opinion. >>> >>> >>>> Do we, or do we not, have consensus on whether or not >>> History-Info is an adequate solution to the problem? >>> >>> I certainly think that that History-Info is a solution to the >>> initial goal of Jonathan's draft. >>> >>> Sending transparant parameters end-to-end is, in my opinion, a >>> completly separate issue. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> >>> >>> >>> -- >>> Dean >>> >>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From spencer@wonderhamster.org Wed Aug 12 06:25:02 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1C003A6B37 for ; Wed, 12 Aug 2009 06:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4jstvKWTAvg for ; Wed, 12 Aug 2009 06:25:02 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id BFDFC3A6909 for ; Wed, 12 Aug 2009 06:25:01 -0700 (PDT) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1MbDXO3PuI-000ikJ; Wed, 12 Aug 2009 09:06:46 -0400 Message-ID: <55B605E03AB14EE4B194588466556755@china.huawei.com> From: "Spencer Dawkins" To: "Paul Kyzivat" References: <14C85D6CCBE92743AF33663BF5D24EBA02BD497B@gaalpa1msgusr7e.ugd.att.com> <14C85D6CCBE92743AF33663BF5D24EBA03F3D02A@gaalpa1msgusr7e.ugd.att.com><40FB0FFB97588246A1BEFB05759DC8A00348106A@S4DE9JSAANI.ost.t-com.de> <4A82B9C2.9080409@cisco.com> Date: Wed, 12 Aug 2009 08:06:34 -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.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX18SUArDtzU0QJ7smHQQxy5mQ0yXn2vrIzWX4YB sMwsiIKoVXtW4sdLXKU8CbJyqK0lZMo/DongD94nvmFaGwxdn7 xIPpvS8wb198gvSXs93ek09O8rI9Ay2mR2ThBfS/n8= Cc: sipcore@ietf.org, L.Liess@telekom.de Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 13:25:03 -0000 Hi, Paul, >> H-I is frequently removed by B2BUAs at the network border so the UUI may >> not reach it's destination. For UUI, we need a new parameter which is >> not removed by intermediaries. > > When talking about a new thing added to a message, you can have no > guarantees of whether it will survive B2BUAs or not. If the B2BUA removes > anything it doesn't understand then this new thing may will not survive. > Or it might remove it even when it does understand it if it thinks this > might contain sensitive information. > > Thanks, > Paul > >> Kind regards >> Laura If I understood Laura's concern, it's that people are already making the policy decision to drop H-I entries at network edges to do topology hiding. I agree with what you're saying ("no guarantees" about a new header field), but if a new header field is used, it would be possible for B2BUAs that remove anything they don't understand to stop removing the new header field. If History-Info is (re-)used, the B2BUA can't do topology hiding and still pass UUI, can it? (I'm not talking about whether topology hiding should happen - just trying to help with the discussion) Thanks, Spencer From christer.holmberg@ericsson.com Wed Aug 12 09:14:46 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CE683A6B94 for ; Wed, 12 Aug 2009 09:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.568 X-Spam-Level: X-Spam-Status: No, score=-5.568 tagged_above=-999 required=5 tests=[AWL=0.681, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLrZ1shiN7mp for ; Wed, 12 Aug 2009 09:14:44 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 234C93A6B97 for ; Wed, 12 Aug 2009 09:14:16 -0700 (PDT) X-AuditID: c1b4fb3c-b7bccae00000385d-2e-4a82e5417dc7 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id B9.46.14429.145E28A4; Wed, 12 Aug 2009 17:52:33 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 17:51:52 +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 Date: Wed, 12 Aug 2009 17:50:51 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery Thread-Index: AcobS4L9HxbwlyCeT2Gbqimquvq3sQAGShQq References: <14C85D6CCBE92743AF33663BF5D24EBA02BD497B@gaalpa1msgusr7e.ugd.att.com> <14C85D6CCBE92743AF33663BF5D24EBA03F3D02A@gaalpa1msgusr7e.ugd.att.com> <40FB0FFB97588246A1BEFB05759DC8A00348106A@S4DE9JSAANI.ost.t-com.de> <4A82B9C2.9080409@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , X-OriginalArrivalTime: 12 Aug 2009 15:51:52.0353 (UTC) FILETIME=[CF62F910:01CA1B64] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 16:14:46 -0000 Hi, =20 It is true that we don't know what a B2BUA may do. =20 However, for H-I we have specified privacy procedures, when something = will get removed. =20 Regards, =20 Christer ________________________________ From: sipcore-bounces@ietf.org on behalf of Paul Kyzivat Sent: Wed 12/08/2009 14:46 To: L.Liess@telekom.de Cc: sipcore@ietf.org Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter = delivery L.Liess@telekom.de wrote: >=20 > > H-I is frequently removed by B2BUAs at the network border so the UUI = may > not reach it's destination. For UUI, we need a new parameter which is > not removed by intermediaries. When talking about a new thing added to a message, you can have no guarantees of whether it will survive B2BUAs or not. If the B2BUA removes anything it doesn't understand then this new thing may will not survive. Or it might remove it even when it does understand it if it thinks this might contain sensitive information. Thanks, Paul > Kind regards > Laura =20 > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of DOLLY, MARTIN C, ATTLABS > Sent: Tuesday, August 11, 2009 8:38 PM > To: DOLLY, MARTIN C, ATTLABS; ian.elz@ericsson.com; > john.elwell@siemens-enterprise.com; audet@nortel.com; > christer.holmberg@ericsson.com; dean.willis@softarmor.com > Cc: sipcore@ietf.org; HKaplan@acmepacket.com > Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter > delivery > > Sorry. We should NOT put UUI in H-I > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of DOLLY, MARTIN C, ATTLABS > Sent: Tuesday, August 11, 2009 12:39 PM > To: ian.elz@ericsson.com; john.elwell@siemens-enterprise.com; > audet@nortel.com; christer.holmberg@ericsson.com; > dean.willis@softarmor.com > Cc: sipcore@ietf.org; HKaplan@acmepacket.com > Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter > delivery > > We should put UUI in H-I. > > ----- Original Message ----- > From: sipcore-bounces@ietf.org > To: Elwell, John ; Francois Audet > ; Christer Holmberg = ; > Dean Willis > Cc: SIPCORE ; Hadriel Kaplan = > Sent: Tue Aug 11 11:11:50 2009 > Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter > delivery > > All, > > Sorry that I am a bit late in this thread but I am catching up. > > The UUI may only be applicable to B but there is no way of knowing if = it > may also be applicable to C following retargeting. This will depend = upon > the content of the UUI, its purpose and the capabilities of C. > > The key issue with trying to pass the UUI as a parameter in H-I is > Privacy. If A sets Privacy to value 'header' then the H-I entry = included > by the retargeting to the registered terminal address will be removed > and will not even be received by B let alone C as the H-I will be > removed. > > You need to place the UUI in a separate header to ensure that it is = not > removed when the URI is protected by Privacy. > > Ian Elz > > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: 05 August 2009 09:27 > To: Francois Audet; Christer Holmberg; Dean Willis > Cc: SIPCORE; Hadriel Kaplan > Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter > delivery > > It think we need to ask the question whether, for a given class of > information included by the UAC in the original request (e.g., UUI), > that information should be preserved if the request is retargeted. > Clearly most classes of information should be preserved when the > Request-URI changes because of rerouting, but when retargeting occurs > the answer might not be so clear. > > So taking UUI, if A sends a request with UUI to B and the request is > retargeted to C, is the UUI relevant to C too, or only to B? If the = UUI > has implicit semantics, it is not at all clear to me that it is = equally > applicable to C. > > If the information is equally applicable to B and C, this would argue = in > favour of a separate header field for UUI. > > If the information is specifically targeted at B, this would argue for = a > URI parameter. In that case, although C might receive the information > via H-I, it will at least know that the UUI was targeted at B and it = can > take it or leave it, depending on application. The problem with a > separate header field in this case is that C would need to trawl = through > H-I to find out whether the UUI really was targeted at C, and if H-I = is > not available (e.g., because of privacy or lack of support) or somehow > obfuscated, then C might interpret the UUI wrongly. > > Having said this, the cc-uui draft states: > "REQ-4: The mechanism will allow UUI to be able to survive proxy > retargeting." > This seems to suggest that UUI should have semantics of being equally > applicable to B and C, and this would indeed suggest a separate header > field. However, I am not sure I have interpreted that requirement > correctly or the motivation for that requirement. > > John > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Francois Audet >> Sent: 04 August 2009 22:53 >> To: Christer Holmberg; Dean Willis >> Cc: SIPCORE; Hadriel Kaplan >> Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter >> delivery >> >> I completely agree with Christer on this point. >> >>=20 >> >>> -----Original Message----- >>> From: sipcore-bounces@ietf.org >>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg >>> Sent: Monday, August 03, 2009 13:13 >>> To: Dean Willis >>> Cc: SIPCORE; Hadriel Kaplan >>> Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter > >>> delivery >>> >>> Hi, >>>=20 >>>> As we know, the R-URI value is not end-to-end. It may >> change in the >>>> path, due to normal SIP procedures. That is the reason we have >>>> History-Info: to record what has happened, for applications >>> etc which >>>> needs that information. >>>> >>>> But, in my opinion History-Info is not a generic mechanism of >>>> transporting parameters transparently end-to-end, however, >>> and UUI is >>>> a parameter which is supposed to be transported end-to-end. >>> Therefor I >>>> think it would fit better in a separate header. >>> >>>> Once again: The reason I lobbied for and requested the >> milestone for >>>> end-to-end delivery of request URI AND parameters was SO THAT >>>> PARAMETERS COULD BE DELIVERED END TO END. That was also >> the initial >>>> goal of Jonathan's ua-loose-route draft, although in that >>> process, we >>>> discovered that the non-parameter part of the target URI was also >>>> needed for some applications. >>> The initial goal of Jonathan's draft was NOT to transport >>> transparent parameters end-to-end. >>>=20 >>> The initial goal was to make sure that the initial R-URI reaches the > >>> other end. >>> >>>> If we don't think that History-Info is a generic mechanism of >>>> transporting parameters transparently end-to-end, then it is NOT >>>> meeting the goal of the charter deliverable. >>> >>> The purpose of H-I is to make sure that certain parameters, which >>> may change in the path, are transported end-to-end. >>> >>> That is not the same as transporting transparant parameters >>> end-to-end, in my opinion. >>> >>> >>>> Do we, or do we not, have consensus on whether or not >>> History-Info is an adequate solution to the problem? >>> >>> I certainly think that that History-Info is a solution to the >>> initial goal of Jonathan's draft. >>> >>> Sending transparant parameters end-to-end is, in my opinion, a >>> completly separate issue. >>> >>> Regards, >>> >>> Christer >>> >>>=20 >>> >>>=20 >>> >>> >>> >>> -- >>> Dean >>> >>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From dean.willis@softarmor.com Wed Aug 12 09:31:41 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21C3D3A6AC0 for ; Wed, 12 Aug 2009 09:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SZlSoyboBRz for ; Wed, 12 Aug 2009 09:31:40 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 54A193A698E for ; Wed, 12 Aug 2009 09:31:40 -0700 (PDT) Received: from [192.168.2.104] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n7CGTc2M002554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Aug 2009 11:29:40 -0500 Message-ID: <4A82EDEC.1050200@softarmor.com> Date: Wed, 12 Aug 2009 11:29:32 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Ian Elz References: <4A72B495.80407@softarmor.com><4A72E6C5.5070905@cisco.com><1ECE0EB50388174790F9694F77522CCF1F50910C@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D002393AA6@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 16:31:41 -0000 Ian Elz wrote: > All, > > Sorry that I am a bit late in this thread but I am catching up. > > The UUI may only be applicable to B but there is no way of knowing if it > may also be applicable to C following retargeting. This will depend upon > the content of the UUI, its purpose and the capabilities of C. > > The key issue with trying to pass the UUI as a parameter in H-I is > Privacy. If A sets Privacy to value 'header' then the H-I entry included > by the retargeting to the registered terminal address will be removed > and will not even be received by B let alone C as the H-I will be > removed. > > You need to place the UUI in a separate header to ensure that it is not > removed when the URI is protected by Privacy. So if we assume that 4244bis is our mechanism for passing parameters from UAC to UAS, then we have to realize that this completely doesn't work in conjunction with Privacy. It seems evident to me that we might want to pass parameters from UAC to UAS even when we want identity privacy. This argues against 4244bis being an acceptable solution to the problem. -- Dean From dean.willis@softarmor.com Wed Aug 12 09:54:49 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FD813A69CE for ; Wed, 12 Aug 2009 09:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wb3KWkEt5PKt for ; Wed, 12 Aug 2009 09:54:48 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 6EDA83A6C46 for ; Wed, 12 Aug 2009 09:54:05 -0700 (PDT) Received: from [192.168.2.104] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n7CGVviU002563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Aug 2009 11:31:59 -0500 Message-ID: <4A82EE77.1030602@softarmor.com> Date: Wed, 12 Aug 2009 11:31:51 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: L.Liess@telekom.de References: <14C85D6CCBE92743AF33663BF5D24EBA02BD497B@gaalpa1msgusr7e.ugd.att.com> <14C85D6CCBE92743AF33663BF5D24EBA03F3D02A@gaalpa1msgusr7e.ugd.att.com> <40FB0FFB97588246A1BEFB05759DC8A003480FE0@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A003480FE0@S4DE9JSAANI.ost.t-com.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 12 Aug 2009 12:16:58 -0700 Cc: mdolly@att.com, sipcore@ietf.org, HKaplan@acmepacket.com, ian.elz@ericsson.com, R.Jesske@telekom.de Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 16:54:49 -0000 L.Liess@telekom.de wrote: > > > H-I is frequently removed by B2BUAs at the network border so the UUI may > not reach it's destination. For UUI, we need a new parameter which is > not removed by intermediaries. Again, this argues that we need some other mechanism for general parameter passing from UAC to UAS. RFC 4244bis just doesn't get this specific job done. Of course, no matter where we put it, some SBC is going to come along and remove it. That's what they do. -- dean From spencer@wonderhamster.org Wed Aug 12 13:09:55 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 025493A6A93 for ; Wed, 12 Aug 2009 13:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NswP+j1UI7qk for ; Wed, 12 Aug 2009 13:09:54 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 5C0263A6B8C for ; Wed, 12 Aug 2009 13:09:24 -0700 (PDT) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1MbK1733Xt-00014g; Wed, 12 Aug 2009 16:01:59 -0400 Message-ID: From: "Spencer Dawkins" To: "Dean Willis" , References: <14C85D6CCBE92743AF33663BF5D24EBA02BD497B@gaalpa1msgusr7e.ugd.att.com><14C85D6CCBE92743AF33663BF5D24EBA03F3D02A@gaalpa1msgusr7e.ugd.att.com><40FB0FFB97588246A1BEFB05759DC8A003480FE0@S4DE9JSAANI.ost.t-com.de> <4A82EE77.1030602@softarmor.com> Date: Wed, 12 Aug 2009 15:01:40 -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.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX19iY9uJoNYATg2ldKuIvY/axB1rMb58z2PNuwj M4PBvHBbkLjCoGdlj6hh/zqUhg0G98yEKV6d52nZ6Q5TXpY1M9 7q0REzFPCTWSK1W1VxVKtwIe3qps3lb2h64oruXKms= Cc: mdolly@att.com, ian.elz@ericsson.com, sipcore@ietf.org, R.Jesske@telekom.de, HKaplan@acmepacket.com Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 20:09:55 -0000 Hi, Dean, > L.Liess@telekom.de wrote: >> >> >> H-I is frequently removed by B2BUAs at the network border so the UUI may >> not reach it's destination. For UUI, we need a new parameter which is >> not removed by intermediaries. > > Again, this argues that we need some other mechanism for general > parameter passing from UAC to UAS. RFC 4244bis just doesn't get this > specific job done. > > Of course, no matter where we put it, some SBC is going to come along > and remove it. That's what they do. > > -- > dean Totally agree - I think your point argues that reusing a header field that's already removed for policy reasons in some situations is unwise. You can tell your own SBC to stop removing a single-purposed header field if that's what you think should happen, but you can't tell your own SBC to pass H-I for parameter passing from UAC to UAS AND remove H-I for privacy or topology hiding at the same time ... Thanks, Spencer From dean.willis@softarmor.com Wed Aug 12 20:49:42 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 624B13A6802 for ; Wed, 12 Aug 2009 20:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70XM3jLi3b8X for ; Wed, 12 Aug 2009 20:49:41 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 9F94F3A67B0 for ; Wed, 12 Aug 2009 20:49:41 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n7D3n06v007459 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 12 Aug 2009 22:49:02 -0500 From: Dean Willis To: Spencer Dawkins In-Reply-To: X-Priority: 3 References: <14C85D6CCBE92743AF33663BF5D24EBA02BD497B@gaalpa1msgusr7e.ugd.att.com><14C85D6CCBE92743AF33663BF5D24EBA03F3D02A@gaalpa1msgusr7e.ugd.att.com><40FB0FFB97588246A1BEFB05759DC8A003480FE0@S4DE9JSAANI.ost.t-com.de> <4A82EE77.1030602@softarmor.com> Message-Id: <82500797-1F2C-4716-B072-3F0921B487E7@softarmor.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 12 Aug 2009 22:48:55 -0500 X-Mailer: Apple Mail (2.936) Cc: mdolly@att.com, sipcore@ietf.org, R.Jesske@telekom.de, ian.elz@ericsson.com, HKaplan@acmepacket.com, L.Liess@telekom.de Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 03:49:42 -0000 On Aug 12, 2009, at 3:01 PM, Spencer Dawkins wrote: > Totally agree - I think your point argues that reusing a header > field that's already removed for policy reasons in some situations > is unwise. Right. > You can tell your own SBC to stop removing a single-purposed header > field if that's what you think should happen, but you can't tell > your own SBC to pass H-I for parameter passing from UAC to UAS AND > remove H-I for privacy or topology hiding at the same time ... Bingo -- conflicted requirements. -- Dean From L.Liess@telekom.de Thu Aug 13 04:04:24 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BEE23A67AC for ; Thu, 13 Aug 2009 04:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEG9JaTsfKPe for ; Thu, 13 Aug 2009 04:04:23 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id E4F8A3A67FF for ; Thu, 13 Aug 2009 04:04:10 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail81.telekom.de with ESMTP; 13 Aug 2009 11:00:45 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 11:00:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Aug 2009 11:00:44 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A0034BFBFC@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <55B605E03AB14EE4B194588466556755@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery Thread-Index: AcobTdWN65dudn5IQVi7nRBptMF+ugApZqHQ References: <14C85D6CCBE92743AF33663BF5D24EBA02BD497B@gaalpa1msgusr7e.ugd.att.com> <14C85D6CCBE92743AF33663BF5D24EBA03F3D02A@gaalpa1msgusr7e.ugd.att.com><40FB0FFB97588246A1BEFB05759DC8A00348106A@S4DE9JSAANI.ost.t-com.de> <4A82B9C2.9080409@cisco.com> <55B605E03AB14EE4B194588466556755@china.huawei.com> From: To: , X-OriginalArrivalTime: 13 Aug 2009 09:00:45.0084 (UTC) FILETIME=[8AF62DC0:01CA1BF4] Cc: sipcore@ietf.org Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 11:04:24 -0000 Paul, As Spencer already wrote, carriers do topology hiding at the network border. =20 They have done it with SS7 and will do it for SIP too. So, H-I is removed and we need another way to pass UUI.=20 Thanks a lot Laura -----Original Message----- From: Spencer Dawkins [mailto:spencer@wonderhamster.org]=20 Sent: Wednesday, August 12, 2009 3:07 PM To: Paul Kyzivat Cc: sipcore@ietf.org; Liess, Laura Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery Hi, Paul, >> H-I is frequently removed by B2BUAs at the network border so the UUI may >> not reach it's destination. For UUI, we need a new parameter which is >> not removed by intermediaries. > > When talking about a new thing added to a message, you can have no=20 > guarantees of whether it will survive B2BUAs or not. If the B2BUA removes=20 > anything it doesn't understand then this new thing may will not survive.=20 > Or it might remove it even when it does understand it if it thinks this=20 > might contain sensitive information. > > Thanks, > Paul > >> Kind regards >> Laura If I understood Laura's concern, it's that people are already making the policy decision to drop H-I entries at network edges to do topology hiding. I agree with what you're saying ("no guarantees" about a new header field),=20 but if a new header field is used, it would be possible for B2BUAs that=20 remove anything they don't understand to stop removing the new header field.=20 If History-Info is (re-)used, the B2BUA can't do topology hiding and still=20 pass UUI, can it? (I'm not talking about whether topology hiding should happen - just trying=20 to help with the discussion) Thanks, Spencer=20 From pkyzivat@cisco.com Thu Aug 13 06:23:22 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA79A3A6962 for ; Thu, 13 Aug 2009 06:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.533 X-Spam-Level: X-Spam-Status: No, score=-6.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WE0yxRNwBNgR for ; Thu, 13 Aug 2009 06:23:21 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 97BCD3A68B8 for ; Thu, 13 Aug 2009 06:23:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJOwg0pAZnmf/2dsb2JhbAC7TYgrkQYFgjKBZw X-IronPort-AV: E=Sophos;i="4.43,374,1246838400"; d="scan'208";a="53958382" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 13 Aug 2009 13:22:48 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7DDMm3b012122; Thu, 13 Aug 2009 09:22:48 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7DDMmr7007605; Thu, 13 Aug 2009 13:22:48 GMT 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.3959); Thu, 13 Aug 2009 09:22:48 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 09:22:47 -0400 Message-ID: <4A8413A6.8000703@cisco.com> Date: Thu, 13 Aug 2009 09:22:46 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: L.Liess@telekom.de References: <14C85D6CCBE92743AF33663BF5D24EBA02BD497B@gaalpa1msgusr7e.ugd.att.com> <14C85D6CCBE92743AF33663BF5D24EBA03F3D02A@gaalpa1msgusr7e.ugd.att.com><40FB0FFB97588246A1BEFB05759DC8A00348106A@S4DE9JSAANI.ost.t-com.de> <4A82B9C2.9080409@cisco.com> <55B605E03AB14EE4B194588466556755@china.huawei.com> <40FB0FFB97588246A1BEFB05759DC8A0034BFBFC@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A0034BFBFC@S4DE9JSAANI.ost.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Aug 2009 13:22:47.0756 (UTC) FILETIME=[266788C0:01CA1C19] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2462; t=1250169768; x=1251033768; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20RFC=204244=20bis=20use=20ca ses=20and=20UAC->UAS=20parameter=20delivery |Sender:=20 |To:=20L.Liess@telekom.de; bh=4epL/by787C0oSODODB+K6tjZD2coL8I+OahG0gzaIc=; b=bnYFb9+LJcOo8UcZGWoK6clSg2o1ux3q/SchuClE+D5VoLEqOb6hLATFJO ym0fzTB9emYASMJy/R4EaeM0bDxyRFcM1WXFy+lHJWMlhRles4Scp1xb3pW8 kjurKPstlD; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sipcore@ietf.org Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 13:23:22 -0000 L.Liess@telekom.de wrote: > Paul, > > As Spencer already wrote, carriers do topology hiding at the network > border. > They have done it with SS7 and will do it for SIP too. So, H-I is > removed and we need another way to pass UUI. I certainly know that and AFAIK didn't imply otherwise. Carriers try to find a way to hide lots of things. The question is: will there also be reasons for carriers to censor parameters as well? I suppose one could argue that if we were to provide the means to classify and identify parameters for particular purposes we would make it easier for middle boxes to make policy decisions about whether to let them pass or not. Personally I just want the providers to keep their hands off my data. I'm largely in agreement with what Dean and Spencer have been saying. Thanks, Paul > Thanks a lot > Laura > > > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > Sent: Wednesday, August 12, 2009 3:07 PM > To: Paul Kyzivat > Cc: sipcore@ietf.org; Liess, Laura > Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter > delivery > > Hi, Paul, > >>> H-I is frequently removed by B2BUAs at the network border so the UUI > may >>> not reach it's destination. For UUI, we need a new parameter which is >>> not removed by intermediaries. >> When talking about a new thing added to a message, you can have no >> guarantees of whether it will survive B2BUAs or not. If the B2BUA > removes >> anything it doesn't understand then this new thing may will not > survive. >> Or it might remove it even when it does understand it if it thinks > this >> might contain sensitive information. >> >> Thanks, >> Paul >> >>> Kind regards >>> Laura > > If I understood Laura's concern, it's that people are already making the > > policy decision to drop H-I entries at network edges to do topology > hiding. > > I agree with what you're saying ("no guarantees" about a new header > field), > but if a new header field is used, it would be possible for B2BUAs that > remove anything they don't understand to stop removing the new header > field. > If History-Info is (re-)used, the B2BUA can't do topology hiding and > still > pass UUI, can it? > > (I'm not talking about whether topology hiding should happen - just > trying > to help with the discussion) > > Thanks, > > Spencer > > From L.Liess@telekom.de Thu Aug 13 04:04:24 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 179773A67FF for ; Thu, 13 Aug 2009 04:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.007 X-Spam-Level: X-Spam-Status: No, score=-3.007 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjKuq3UtzQxa for ; Thu, 13 Aug 2009 04:04:23 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id D14C93A680D for ; Thu, 13 Aug 2009 04:04:11 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail81.telekom.de with ESMTP; 13 Aug 2009 11:18:02 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 11:18:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Aug 2009 11:18:01 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A0034BFC18@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <4A82EE77.1030602@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery Thread-Index: Acobary51NZVR16mTMylY1j3QvhD9AAij6Lw References: <14C85D6CCBE92743AF33663BF5D24EBA02BD497B@gaalpa1msgusr7e.ugd.att.com> <14C85D6CCBE92743AF33663BF5D24EBA03F3D02A@gaalpa1msgusr7e.ugd.att.com> <40FB0FFB97588246A1BEFB05759DC8A003480FE0@S4DE9JSAANI.ost.t-com.de> <4A82EE77.1030602@softarmor.com> From: To: X-OriginalArrivalTime: 13 Aug 2009 09:18:02.0656 (UTC) FILETIME=[F5671A00:01CA1BF6] X-Mailman-Approved-At: Thu, 13 Aug 2009 06:53:17 -0700 Cc: mdolly@att.com, sipcore@ietf.org, HKaplan@acmepacket.com, ian.elz@ericsson.com, R.Jesske@telekom.de Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 11:04:24 -0000 =20 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 L.Liess@telekom.de wrote: > =20 >=20 > H-I is frequently removed by B2BUAs at the network border so the UUI may > not reach it's destination. For UUI, we need a new parameter which is > not removed by intermediaries.=20 Again, this argues that we need some other mechanism for general parameter passing from UAC to UAS. RFC 4244bis just doesn't get this specific job done. I think we are now back to the discussion on Alan's UUI draft /WG-proposal.=20 Maybe we should wait Alan's new proposal? I am not sure, but my understanding was=20 that Alan agreed to look at this.=20 Of course, no matter where we put it, some SBC is going to come along and remove it. That's what they do. -- dean From L.Liess@telekom.de Fri Aug 14 05:39:49 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDE023A69DC for ; Fri, 14 Aug 2009 05:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.913 X-Spam-Level: X-Spam-Status: No, score=-2.913 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-GX-TekA+D9 for ; Fri, 14 Aug 2009 05:39:43 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 780BB3A6828 for ; Fri, 14 Aug 2009 05:39:42 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail51.telekom.de with ESMTP; 14 Aug 2009 14:35:25 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Aug 2009 14:35: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 Date: Fri, 14 Aug 2009 14:35:19 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A0034C0218@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <4A8413A6.8000703@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery Thread-Index: AcocGTdkK6Gyzx4SQqWAzw4QxciXfgAwAwfw References: <14C85D6CCBE92743AF33663BF5D24EBA02BD497B@gaalpa1msgusr7e.ugd.att.com> <14C85D6CCBE92743AF33663BF5D24EBA03F3D02A@gaalpa1msgusr7e.ugd.att.com><40FB0FFB97588246A1BEFB05759DC8A00348106A@S4DE9JSAANI.ost.t-com.de> <4A82B9C2.9080409@cisco.com> <55B605E03AB14EE4B194588466556755@china.huawei.com> <40FB0FFB97588246A1BEFB05759DC8A0034BFBFC@S4DE9JSAANI.ost.t-com.de> <4A8413A6.8000703@cisco.com> From: To: X-OriginalArrivalTime: 14 Aug 2009 12:35:25.0197 (UTC) FILETIME=[B28533D0:01CA1CDB] Cc: sipcore@ietf.org Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 12:39:49 -0000 Paul,=20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Thursday, August 13, 2009 3:23 PM To: Liess, Laura Cc: spencer@wonderhamster.org; sipcore@ietf.org Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery L.Liess@telekom.de wrote: > Paul, >=20 > As Spencer already wrote, carriers do topology hiding at the network > border. =20 > They have done it with SS7 and will do it for SIP too. So, H-I is > removed and we need another way to pass UUI.=20 I certainly know that and AFAIK didn't imply otherwise. Carriers try to find a way to hide lots of things. The question is: will there also be reasons for carriers to censor=20 parameters as well? B2BUAs in carrier networks already do it.=20 I think it is is OK when it is for hiding the own network infrastructure.=20 =20 Another example is the caller's IP-address. I learned from the security guys that carriers have to do this because they must be able to hide caller's data. And most of our customers seem to like it, they feel more secure.=20 We have regulatory requirements to be able to hide the caller phone number. IP-address hiding is in a way the same,=20 at least for VoIP. =20 There are realy ugly B2BUAs in the field which have white lists and drop everything they do not understand. =20 We had one of them in the past and asked the vendor to change it, but I am sure there are still a lot of them elsewere. =20 The B2BUAs at the network borders (the 3GPP IBCF) has a profile about which headers to pass and which=20 headers to drop towards networks which are considered untrusted. The H-I will not be passed towards untrusted networks. =20 A dedicated UUI-header will probably have good chances to cross the network borders.=20 And I am fine with a more general header which is used for other applications as well.=20 =20 Thanks a lot Laura =20 I suppose one could argue that if we were to provide the means to=20 classify and identify parameters for particular purposes we would make=20 it easier for middle boxes to make policy decisions about whether to let=20 them pass or not. Personally I just want the providers to keep their hands off my data. I'm largely in agreement with what Dean and Spencer have been saying. Thanks, Paul > Thanks a lot > Laura >=20 >=20 > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org]=20 > Sent: Wednesday, August 12, 2009 3:07 PM > To: Paul Kyzivat > Cc: sipcore@ietf.org; Liess, Laura > Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter > delivery >=20 > Hi, Paul, >=20 >>> H-I is frequently removed by B2BUAs at the network border so the UUI > may >>> not reach it's destination. For UUI, we need a new parameter which is >>> not removed by intermediaries. >> When talking about a new thing added to a message, you can have no=20 >> guarantees of whether it will survive B2BUAs or not. If the B2BUA > removes=20 >> anything it doesn't understand then this new thing may will not > survive.=20 >> Or it might remove it even when it does understand it if it thinks > this=20 >> might contain sensitive information. >> >> Thanks, >> Paul >> >>> Kind regards >>> Laura >=20 > If I understood Laura's concern, it's that people are already making the >=20 > policy decision to drop H-I entries at network edges to do topology > hiding. >=20 > I agree with what you're saying ("no guarantees" about a new header > field),=20 > but if a new header field is used, it would be possible for B2BUAs that=20 > remove anything they don't understand to stop removing the new header > field.=20 > If History-Info is (re-)used, the B2BUA can't do topology hiding and > still=20 > pass UUI, can it? >=20 > (I'm not talking about whether topology hiding should happen - just > trying=20 > to help with the discussion) >=20 > Thanks, >=20 > Spencer=20 >=20 >=20 From pkyzivat@cisco.com Fri Aug 14 06:04:55 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E4D83A699F for ; Fri, 14 Aug 2009 06:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoz3W9o0-iu4 for ; Fri, 14 Aug 2009 06:04:54 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 1EF293A689A for ; Fri, 14 Aug 2009 06:04:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGT9hEpAZnmf/2dsb2JhbAC5EogtkScFgjKBZw X-IronPort-AV: E=Sophos;i="4.43,380,1246838400"; d="scan'208";a="54078376" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 14 Aug 2009 13:03:26 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7ED3QsD017641; Fri, 14 Aug 2009 09:03:26 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7ED3QS6006122; Fri, 14 Aug 2009 13:03:26 GMT 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.3959); Fri, 14 Aug 2009 09:03:26 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Aug 2009 09:03:26 -0400 Message-ID: <4A85609E.90309@cisco.com> Date: Fri, 14 Aug 2009 09:03:26 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: L.Liess@telekom.de References: <14C85D6CCBE92743AF33663BF5D24EBA02BD497B@gaalpa1msgusr7e.ugd.att.com> <14C85D6CCBE92743AF33663BF5D24EBA03F3D02A@gaalpa1msgusr7e.ugd.att.com><40FB0FFB97588246A1BEFB05759DC8A00348106A@S4DE9JSAANI.ost.t-com.de> <4A82B9C2.9080409@cisco.com> <55B605E03AB14EE4B194588466556755@china.huawei.com> <40FB0FFB97588246A1BEFB05759DC8A0034BFBFC@S4DE9JSAANI.ost.t-com.de> <4A8413A6.8000703@cisco.com> <40FB0FFB97588246A1BEFB05759DC8A0034C0218@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A0034C0218@S4DE9JSAANI.ost.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Aug 2009 13:03:26.0048 (UTC) FILETIME=[9C62B600:01CA1CDF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5342; t=1250255006; x=1251119006; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20RFC=204244=20bis=20use=20ca ses=20and=20UAC->UAS=20parameter=20delivery |Sender:=20 |To:=20L.Liess@telekom.de; bh=Mtp26Eq4M70Xc8Oq/aXQ4LqKBBkHuQcREsBZSKCb6RY=; b=ZYTz7aHqgCUubAuCaBaaXCCLzhc2k1BTT0Db0H9xqlwmvHWsZF9r6ZLNsl JpOKDX0SI73izk9lQM4we4fnQzPe/vATmeqWelnz7MV6Ugft+N//Fd6BvfjK wvm7R1NDYo; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sipcore@ietf.org Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 13:04:55 -0000 Laura, As far as the intended subject of this thread, I think there is some convergence that putting parameters into the R-URI and getting them to the recipient via H-I is not workable, so we need a different solution than that. Another header seems to be the current thinking, and I'm ok with that, as long as it is general purpose. Beyond that we start to get into controversial territory regarding censoring of data by providers. I'm ok with providers censoring *their own* data as long as done in such a way that everyone knows how to make things work when that is going on. I'm even ok with providers censoring their customers' data as part of a terms-of-service agreement, as long as that part is *optional*, that a customer may opt in/out of. I'm *not* ok with providers censoring customer data that customers don't want censored. Thanks, Paul L.Liess@telekom.de wrote: > Paul, > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, August 13, 2009 3:23 PM > To: Liess, Laura > Cc: spencer@wonderhamster.org; sipcore@ietf.org > Subject: Re: [sipcore] RFC 4244 bis use cases and > UAC->UAS parameter delivery > > > > L.Liess@telekom.de wrote: > > Paul, > > > > As Spencer already wrote, carriers do topology hiding > at the network > > border. > > They have done it with SS7 and will do it for SIP too. > So, H-I is > > removed and we need another way to pass UUI. > > I certainly know that and AFAIK didn't imply otherwise. > Carriers try to find a way to hide lots of things. > The question is: will there also be reasons for carriers > to censor > parameters as well? > > B2BUAs in carrier networks already do it. > > I think it is is OK when it is for hiding the own network > infrastructure. > > Another example is the caller's IP-address. I learned from the security > guys that carriers have to do this because they must > be able to hide caller's data. And most of our customers seem to like > it, they feel more secure. > We have regulatory requirements to be able to hide the caller phone > number. IP-address hiding is in a way the same, > at least for VoIP. > > There are realy ugly B2BUAs in the field which have white lists and drop > everything they do not understand. > We had one of them in the past and asked the vendor to change it, but I > am sure there are still a lot of them elsewere. > > The B2BUAs at the network borders (the 3GPP IBCF) has a profile about > which headers to pass and which > headers to drop towards networks which are considered untrusted. The H-I > will not be passed towards untrusted networks. > > A dedicated UUI-header will probably have good chances to cross the > network borders. > > And I am fine with a more general header which is used for other > applications as well. > > > > Thanks a lot > Laura > > > > I suppose one could argue that if we were to provide the > means to > classify and identify parameters for particular purposes > we would make > it easier for middle boxes to make policy decisions > about whether to let > them pass or not. > > Personally I just want the providers to keep their hands > off my data. > > I'm largely in agreement with what Dean and Spencer have > been saying. > > Thanks, > Paul > > > Thanks a lot > > Laura > > > > > > -----Original Message----- > > From: Spencer Dawkins > [mailto:spencer@wonderhamster.org] > > Sent: Wednesday, August 12, 2009 3:07 PM > > To: Paul Kyzivat > > Cc: sipcore@ietf.org; Liess, Laura > > Subject: Re: [sipcore] RFC 4244 bis use cases and > UAC->UAS parameter > > delivery > > > > Hi, Paul, > > > >>> H-I is frequently removed by B2BUAs at the network > border so the UUI > > may > >>> not reach it's destination. For UUI, we need a new > parameter which is > >>> not removed by intermediaries. > >> When talking about a new thing added to a message, > you can have no > >> guarantees of whether it will survive B2BUAs or not. > If the B2BUA > > removes > >> anything it doesn't understand then this new thing > may will not > > survive. > >> Or it might remove it even when it does understand it > if it thinks > > this > >> might contain sensitive information. > >> > >> Thanks, > >> Paul > >> > >>> Kind regards > >>> Laura > > > > If I understood Laura's concern, it's that people are > already making the > > > > policy decision to drop H-I entries at network edges > to do topology > > hiding. > > > > I agree with what you're saying ("no guarantees" about > a new header > > field), > > but if a new header field is used, it would be > possible for B2BUAs that > > remove anything they don't understand to stop removing > the new header > > field. > > If History-Info is (re-)used, the B2BUA can't do > topology hiding and > > still > > pass UUI, can it? > > > > (I'm not talking about whether topology hiding should > happen - just > > trying > > to help with the discussion) > > > > Thanks, > > > > Spencer > > > > > From ian.elz@ericsson.com Fri Aug 14 06:38:01 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DB343A689A for ; Fri, 14 Aug 2009 06:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.915 X-Spam-Level: X-Spam-Status: No, score=-4.915 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DV1ZYDFFhIxC for ; Fri, 14 Aug 2009 06:38:00 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 09E0F3A67E7 for ; Fri, 14 Aug 2009 06:37:58 -0700 (PDT) X-AuditID: c1b4fb3e-b7b8dae000002a0a-f3-4a8564bc974e Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id CA.10.10762.CB4658A4; Fri, 14 Aug 2009 15:21:00 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Aug 2009 15:21:00 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA1CE2.10A68319" Date: Fri, 14 Aug 2009 15:20:59 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-roach-sipcore-rfc3265bis-00 Thread-Index: Acoc4hBTjmdJ2k9NQPW7f6n4eZqWqw== From: "Ian Elz" To: X-OriginalArrivalTime: 14 Aug 2009 13:21:00.0444 (UTC) FILETIME=[10DAC5C0:01CA1CE2] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: [sipcore] draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 13:38:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1CE2.10A68319 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adam, A few of comments on the draft. Sections 4.5 and 4.5.1 define how to target SUBSCRIBE to a device using gruu. Is it worth including in this section that to target a SUBSCRIBE to a dialog at the device you need to use the Target-Dialog header? The use of T-D would depend upon the event package but including it here would provide a reminder that event packages should consider this if necessary. Now a more complex issue: You are proposing that the first NOTIFY establishes the SUBSCRIBE dialog. What impact does this have on the establishment of the route set at the UAC as defined in RFC3261? Normal RFC3261 has the UAS route set taken from Record-Route in the initial request. The UAS then copies the Record-Route back into the 2xx response (or reliable provisional response) which is then used by the UAC to set its the route set. This ensures that the route sets in the UAC and UAS align. Section 4.3 of the draft proposes that the initial SUBSCRIBE has the normal Record-Route which establishes the UAS route set but that the NOTIFY also has Record-Route performed by proxies. This leaves the possibility that the route set at the UAC and UAS may not align. This proposal to establish route sets by separate Record-Route actions is in variance to the actions specified in RFC3261 and should be described in the draft. I also have a concern as to what will happen with the route set if the SUBSCRIBE Record-Route is returned in the 2xx and the NOTIFY also includes a Record-Route. Which one is used to establish the route set at the subscriber. Do we take the one which arrives first? Do we take the one which arrives second? There is no issue if they are the same but what if they differ? Should there be a requirement that proxies MUST include themselves in the NOTIFY Record-Route if they included themselves in the SUBSCRIBE Record-Route and to exclude themselves in the NOTUFY if they were not in the SUBSCRIBE Record-Route. If we are to use the Record-Route in the NOTIFY then the draft should explicitly state what should happen at the subscriber end. Should the 2xx response to the NOTIFY include a copy of the Record-Route taken from the NOTIFY? What does the notifier end do if it then receives this Record-Route? There is one more related issue: What happens if the 2xx to the SUBSCRIBE transaction is never received by the subscriber. Based upon the non-INVITE client transaction in RFC3261 the termination of the transaction upon expiry of Timer F will inform the TU. In normal cases the TU would terminate the transaction and drop the dialog In this case if the NOTIFY has been received before the 2xx then this should be treated as the 2xx from the transaction perspective. This almost goes as far as defining a separate client SUBSCRIBE transaction.=20 Ian Elz System Manager DUCI LDC UK (Lucid Duck) Office: + 44 118 9024948 ian.elz@ericsson.com ------_=_NextPart_001_01CA1CE2.10A68319 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-roach-sipcore-rfc3265bis-00

Adam,

A few of comments on the draft.

Sections 4.5 and 4.5.1 define how to = target SUBSCRIBE to a device using gruu. Is it worth including in this = section that to target a SUBSCRIBE to a dialog at the device you need to = use the Target-Dialog header? The use of T-D would depend upon the event = package but including it here would provide a reminder that event = packages should consider this if necessary.

Now a more complex issue:

You are proposing that the first NOTIFY = establishes the SUBSCRIBE dialog. What impact does this have on the = establishment of the route set at the UAC as defined in = RFC3261?

Normal RFC3261 has the UAS route set = taken from Record-Route in the initial request. The UAS then copies the = Record-Route back into the 2xx response (or reliable provisional = response) which is then used by the UAC to set its the route set. This = ensures that the route sets in the UAC and UAS align.

Section 4.3 of the draft proposes that = the initial SUBSCRIBE has the normal Record-Route which establishes the = UAS route set but that the NOTIFY also has Record-Route performed by = proxies. This leaves the possibility that the route set at the UAC and = UAS may not align.

This proposal to establish route sets = by separate Record-Route actions is in variance to the actions specified = in RFC3261 and should be described in the draft.

I also have a concern as to what will = happen with the route set if the SUBSCRIBE Record-Route is returned in = the 2xx and the NOTIFY also includes a Record-Route. Which one is used = to establish the route set at the subscriber. Do we take the one which = arrives first? Do we take the one which arrives second? There is no = issue if they are the same but what if they differ? Should there be a = requirement that proxies MUST include themselves in the NOTIFY = Record-Route if they included themselves in the SUBSCRIBE Record-Route = and to exclude themselves in the NOTUFY if they were not in the = SUBSCRIBE Record-Route.

If we are to use the Record-Route in = the NOTIFY then the draft should explicitly state what should happen at = the subscriber end. Should the 2xx response to the NOTIFY include a copy = of the Record-Route taken from the NOTIFY? What does the notifier end do = if it then receives this Record-Route?

There is one more related issue:

What happens if the 2xx to the = SUBSCRIBE transaction is never received by the subscriber. Based upon = the non-INVITE client transaction in RFC3261 the termination of the = transaction upon expiry of Timer F will inform the TU. In normal cases = the TU would terminate the transaction and drop the dialog In this case = if the NOTIFY has been received before the 2xx then this should be = treated as the 2xx from the transaction perspective. This almost goes as = far as defining a separate client SUBSCRIBE transaction.

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

Office: + 44 118 9024948
ian.elz@ericsson.com

------_=_NextPart_001_01CA1CE2.10A68319-- From L.Liess@telekom.de Fri Aug 14 07:11:24 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C94EC3A6961 for ; Fri, 14 Aug 2009 07:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.941 X-Spam-Level: X-Spam-Status: No, score=-2.941 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUGUkuXKk1jE for ; Fri, 14 Aug 2009 07:11:19 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 74CA13A694A for ; Fri, 14 Aug 2009 07:11:18 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail51.telekom.de with ESMTP; 14 Aug 2009 15:56:02 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Aug 2009 15:56:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Aug 2009 15:56:03 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A0034C029E@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <4A85609E.90309@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery Thread-Index: Acoc359HHZJK3zhER6OGXzysaxHj2wAAmKWw References: <14C85D6CCBE92743AF33663BF5D24EBA02BD497B@gaalpa1msgusr7e.ugd.att.com> <14C85D6CCBE92743AF33663BF5D24EBA03F3D02A@gaalpa1msgusr7e.ugd.att.com><40FB0FFB97588246A1BEFB05759DC8A00348106A@S4DE9JSAANI.ost.t-com.de> <4A82B9C2.9080409@cisco.com> <55B605E03AB14EE4B194588466556755@china.huawei.com> <40FB0FFB97588246A1BEFB05759DC8A0034BFBFC@S4DE9JSAANI.ost.t-com.de> <4A8413A6.8000703@cisco.com> <40FB0FFB97588246A1BEFB05759DC8A0034C0218@S4DE9JSAANI.ost.t-com.de> <4A85609E.90309@cisco.com> From: To: X-OriginalArrivalTime: 14 Aug 2009 13:56:02.0746 (UTC) FILETIME=[F5EC99A0:01CA1CE6] Cc: sipcore@ietf.org Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 14:11:24 -0000 Paul, I think we have full agreement, in both issues. =20 > Another header seems to be the current thinking,=20 > and I'm ok=20 > with that, as long as it is general purpose. I am fine with it. I also hope DT will be able to do more with SIP, not just reinventing PSTN. Then, a general header UUI may be very usefull.=20 > I'm *not*=20 > ok with providers censoring customer data that customers don't want=20 > censored. I agree.=20 Also if carriers would like to, it never worked on a long term.=20 I don't see any value in it. A better service is worth a lot more.=20 =20 Thanks a lot Laura =20 =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Friday, August 14, 2009 3:03 PM > To: Liess, Laura > Cc: spencer@wonderhamster.org; sipcore@ietf.org > Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS=20 > parameter delivery >=20 > Laura, >=20 > As far as the intended subject of this thread, I think there is some=20 > convergence that putting parameters into the R-URI and=20 > getting them to=20 > the recipient via H-I is not workable, so we need a different=20 > solution=20 > than that. Another header seems to be the current thinking,=20 > and I'm ok=20 > with that, as long as it is general purpose. >=20 > Beyond that we start to get into controversial territory regarding=20 > censoring of data by providers. I'm ok with providers=20 > censoring *their=20 > own* data as long as done in such a way that everyone knows=20 > how to make=20 > things work when that is going on. I'm even ok with providers=20 > censoring=20 > their customers' data as part of a terms-of-service=20 > agreement, as long=20 > as that part is *optional*, that a customer may opt in/out=20 > of. I'm *not*=20 > ok with providers censoring customer data that customers don't want=20 > censored. >=20 > Thanks, > Paul >=20 >=20 > L.Liess@telekom.de wrote: > > Paul,=20 > >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > > Sent: Thursday, August 13, 2009 3:23 PM > > To: Liess, Laura > > Cc: spencer@wonderhamster.org; sipcore@ietf.org > > Subject: Re: [sipcore] RFC 4244 bis use cases and > > UAC->UAS parameter delivery > >=20 > >=20 > >=20 > > L.Liess@telekom.de wrote: > > > Paul, > > >=20 > > > As Spencer already wrote, carriers do topology hiding > > at the network > > > border. =20 > > > They have done it with SS7 and will do it for SIP too. > > So, H-I is > > > removed and we need another way to pass UUI.=20 > >=20 > > I certainly know that and AFAIK didn't imply otherwise. > > Carriers try to find a way to hide lots of things. > > The question is: will there also be reasons for carriers > > to censor=20 > > parameters as well? > >=20 > > B2BUAs in carrier networks already do it.=20 > >=20 > > I think it is is OK when it is for hiding the own network > > infrastructure.=20 > > =20 > > Another example is the caller's IP-address. I learned from=20 > the security > > guys that carriers have to do this because they must > > be able to hide caller's data. And most of our customers=20 > seem to like > > it, they feel more secure.=20 > > We have regulatory requirements to be able to hide the caller phone > > number. IP-address hiding is in a way the same,=20 > > at least for VoIP. =20 > >=20 > > There are realy ugly B2BUAs in the field which have white=20 > lists and drop > > everything they do not understand. =20 > > We had one of them in the past and asked the vendor to=20 > change it, but I > > am sure there are still a lot of them elsewere. =20 > >=20 > > The B2BUAs at the network borders (the 3GPP IBCF) has a=20 > profile about > > which headers to pass and which=20 > > headers to drop towards networks which are considered=20 > untrusted. The H-I > > will not be passed towards untrusted networks. =20 > >=20 > > A dedicated UUI-header will probably have good chances to cross the > > network borders.=20 > >=20 > > And I am fine with a more general header which is used for other > > applications as well.=20 > > =20 > >=20 > >=20 > > Thanks a lot > > Laura > > =20 > >=20 > >=20 > > I suppose one could argue that if we were to provide the > > means to=20 > > classify and identify parameters for particular purposes > > we would make=20 > > it easier for middle boxes to make policy decisions > > about whether to let=20 > > them pass or not. > >=20 > > Personally I just want the providers to keep their hands > > off my data. > >=20 > > I'm largely in agreement with what Dean and Spencer have > > been saying. > >=20 > > Thanks, > > Paul > >=20 > > > Thanks a lot > > > Laura > > >=20 > > >=20 > > > -----Original Message----- > > > From: Spencer Dawkins > > [mailto:spencer@wonderhamster.org]=20 > > > Sent: Wednesday, August 12, 2009 3:07 PM > > > To: Paul Kyzivat > > > Cc: sipcore@ietf.org; Liess, Laura > > > Subject: Re: [sipcore] RFC 4244 bis use cases and > > UAC->UAS parameter > > > delivery > > >=20 > > > Hi, Paul, > > >=20 > > >>> H-I is frequently removed by B2BUAs at the network > > border so the UUI > > > may > > >>> not reach it's destination. For UUI, we need a new > > parameter which is > > >>> not removed by intermediaries. > > >> When talking about a new thing added to a message, > > you can have no=20 > > >> guarantees of whether it will survive B2BUAs or not. > > If the B2BUA > > > removes=20 > > >> anything it doesn't understand then this new thing > > may will not > > > survive.=20 > > >> Or it might remove it even when it does understand it > > if it thinks > > > this=20 > > >> might contain sensitive information. > > >> > > >> Thanks, > > >> Paul > > >> > > >>> Kind regards > > >>> Laura > > >=20 > > > If I understood Laura's concern, it's that people are > > already making the > > >=20 > > > policy decision to drop H-I entries at network edges > > to do topology > > > hiding. > > >=20 > > > I agree with what you're saying ("no guarantees" about > > a new header > > > field),=20 > > > but if a new header field is used, it would be > > possible for B2BUAs that=20 > > > remove anything they don't understand to stop removing > > the new header > > > field.=20 > > > If History-Info is (re-)used, the B2BUA can't do > > topology hiding and > > > still=20 > > > pass UUI, can it? > > >=20 > > > (I'm not talking about whether topology hiding should > > happen - just > > > trying=20 > > > to help with the discussion) > > >=20 > > > Thanks, > > >=20 > > > Spencer=20 > > >=20 > > >=20 > >=20 >=20 From hsinnrei@adobe.com Fri Aug 14 08:31:09 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D8BE28C141 for ; Fri, 14 Aug 2009 08:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.291 X-Spam-Level: X-Spam-Status: No, score=-6.291 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ux2HVGuxkJ8 for ; Fri, 14 Aug 2009 08:31:07 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by core3.amsl.com (Postfix) with ESMTP id 730173A6860 for ; Fri, 14 Aug 2009 08:31:06 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKSoWDO5iAT5r84dZvGU1Anbwx2lQJBZo6@postini.com; Fri, 14 Aug 2009 08:31:12 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n7EFV4WG008439; Fri, 14 Aug 2009 08:31:05 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n7EFV3iq007057; Fri, 14 Aug 2009 08:31:03 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Fri, 14 Aug 2009 08:31:03 -0700 From: Henry Sinnreich To: Paul Kyzivat , Laura Liess Date: Fri, 14 Aug 2009 08:31:00 -0700 Thread-Topic: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery Thread-Index: Acoc39Y89xgr258ETzalqiQwMiL1iQAFGOGF Message-ID: In-Reply-To: <4A85609E.90309@cisco.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C6AAED64565Bhsinnreiadobecom_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 14 Aug 2009 08:56:04 -0700 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 15:31:09 -0000 --_000_C6AAED64565Bhsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >I'm *not* ok with providers censoring customer data that customers don't w= ant >censored. Correct. I also believe it is illegal in many countries, such as in Germany= , the EU at large and in the US and Canada. Henry On 8/14/09 8:03 AM, "Paul Kyzivat" wrote: Laura, As far as the intended subject of this thread, I think there is some convergence that putting parameters into the R-URI and getting them to the recipient via H-I is not workable, so we need a different solution than that. Another header seems to be the current thinking, and I'm ok with that, as long as it is general purpose. Beyond that we start to get into controversial territory regarding censoring of data by providers. I'm ok with providers censoring *their own* data as long as done in such a way that everyone knows how to make things work when that is going on. I'm even ok with providers censoring their customers' data as part of a terms-of-service agreement, as long as that part is *optional*, that a customer may opt in/out of. I'm *not* ok with providers censoring customer data that customers don't want censored. Thanks, Paul L.Liess@telekom.de wrote: > Paul, > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, August 13, 2009 3:23 PM > To: Liess, Laura > Cc: spencer@wonderhamster.org; sipcore@ietf.org > Subject: Re: [sipcore] RFC 4244 bis use cases and > UAC->UAS parameter delivery > > > > L.Liess@telekom.de wrote: > > Paul, > > > > As Spencer already wrote, carriers do topology hiding > at the network > > border. > > They have done it with SS7 and will do it for SIP too. > So, H-I is > > removed and we need another way to pass UUI. > > I certainly know that and AFAIK didn't imply otherwise. > Carriers try to find a way to hide lots of things. > The question is: will there also be reasons for carriers > to censor > parameters as well? > > B2BUAs in carrier networks already do it. > > I think it is is OK when it is for hiding the own network > infrastructure. > > Another example is the caller's IP-address. I learned from the security > guys that carriers have to do this because they must > be able to hide caller's data. And most of our customers seem to like > it, they feel more secure. > We have regulatory requirements to be able to hide the caller phone > number. IP-address hiding is in a way the same, > at least for VoIP. > > There are realy ugly B2BUAs in the field which have white lists and drop > everything they do not understand. > We had one of them in the past and asked the vendor to change it, but I > am sure there are still a lot of them elsewere. > > The B2BUAs at the network borders (the 3GPP IBCF) has a profile about > which headers to pass and which > headers to drop towards networks which are considered untrusted. The H-I > will not be passed towards untrusted networks. > > A dedicated UUI-header will probably have good chances to cross the > network borders. > > And I am fine with a more general header which is used for other > applications as well. > > > > Thanks a lot > Laura > > > > I suppose one could argue that if we were to provide the > means to > classify and identify parameters for particular purposes > we would make > it easier for middle boxes to make policy decisions > about whether to let > them pass or not. > > Personally I just want the providers to keep their hands > off my data. > > I'm largely in agreement with what Dean and Spencer have > been saying. > > Thanks, > Paul > > > Thanks a lot > > Laura > > > > > > -----Original Message----- > > From: Spencer Dawkins > [mailto:spencer@wonderhamster.org] > > Sent: Wednesday, August 12, 2009 3:07 PM > > To: Paul Kyzivat > > Cc: sipcore@ietf.org; Liess, Laura > > Subject: Re: [sipcore] RFC 4244 bis use cases and > UAC->UAS parameter > > delivery > > > > Hi, Paul, > > > >>> H-I is frequently removed by B2BUAs at the network > border so the UUI > > may > >>> not reach it's destination. For UUI, we need a new > parameter which is > >>> not removed by intermediaries. > >> When talking about a new thing added to a message, > you can have no > >> guarantees of whether it will survive B2BUAs or not. > If the B2BUA > > removes > >> anything it doesn't understand then this new thing > may will not > > survive. > >> Or it might remove it even when it does understand it > if it thinks > > this > >> might contain sensitive information. > >> > >> Thanks, > >> Paul > >> > >>> Kind regards > >>> Laura > > > > If I understood Laura's concern, it's that people are > already making the > > > > policy decision to drop H-I entries at network edges > to do topology > > hiding. > > > > I agree with what you're saying ("no guarantees" about > a new header > > field), > > but if a new header field is used, it would be > possible for B2BUAs that > > remove anything they don't understand to stop removing > the new header > > field. > > If History-Info is (re-)used, the B2BUA can't do > topology hiding and > > still > > pass UUI, can it? > > > > (I'm not talking about whether topology hiding should > happen - just > > trying > > to help with the discussion) > > > > Thanks, > > > > Spencer > > > > > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_C6AAED64565Bhsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter deliv= ery >I'm *not* ok with providers censoring customer data that customer= s don't want
>censored.

Correct. I also believe it is illegal in many countries, such as in Germany= , the EU at large and in the US and Canada.

Henry

On 8/14/09 8:03 AM, "Paul Kyzivat" <pkyzivat@cisco.com> wrote:

Laura,

As far as the intended subject of this thread, I think there is some
convergence that putting parameters into the R-URI and getting them to
the recipient via H-I is not workable, so we need a different solution
than that. Another header seems to be the current thinking, and I'm ok
with that, as long as it is general purpose.

Beyond that we start to get into controversial territory regarding
censoring of data by providers. I'm ok with providers censoring *their
own* data as long as done in such a way that everyone knows how to make
things work when that is going on. I'm even ok with providers censoring
their customers' data as part of a terms-of-service agreement, as long
as that part is *optional*, that a customer may opt in/out of. I'm *not* ok with providers censoring customer data that customers don't want
censored.

        Thanks,
        Paul


L.Liess@telekom.de wrote:
> Paul,
>
>            &nbs= p;  -----Original Message-----
>            &nbs= p;  From: Paul Kyzivat [mai= lto:pkyzivat@cisco.com]
>            &nbs= p;  Sent: Thursday, August 13, 2009 3:23 PM
>            &nbs= p;  To: Liess, Laura
>            &nbs= p;  Cc: spencer@wonderhamst= er.org; sipcore@ietf.org
>            &nbs= p;  Subject: Re: [sipcore] RFC 4244 bis use cases and
> UAC->UAS parameter delivery
>
>
>
>            &nbs= p;  L.Liess@telekom.de wrote:<= BR> >            &nbs= p;  > Paul,
>            &nbs= p;  >
>            &nbs= p;  > As Spencer already wrote, carriers do topology hiding > at the network
>            &nbs= p;  > border.
>            &nbs= p;  > They have done it with SS7 and will do it for SIP too. > So, H-I is
>            &nbs= p;  > removed and we need another way to pass UUI.
>
>            &nbs= p;  I certainly know that and AFAIK didn't imply otherwise.
>            &nbs= p;  Carriers try to find a way to hide lots of things.
>            &nbs= p;  The question is: will there also be reasons for carriers
> to censor
>            &nbs= p;  parameters as well?
>
> B2BUAs in carrier networks already do it.
>
> I think it is is OK when it is for hiding the own network
> infrastructure.
>
> Another example is the caller's IP-address. I learned from the securit= y
> guys that carriers have to do this because they must
> be able to hide caller's data. And most of our customers seem to like<= BR> > it, they feel more secure.
> We have regulatory requirements to be able to hide the caller phone > number. IP-address hiding is in a way the same,
> at least for VoIP.    
>
> There are realy ugly B2BUAs in the field which have white lists and dr= op
> everything they do not understand.  
> We had one of them in the past and asked the vendor to change it, but = I
> am sure there are still a lot of them elsewere.
>
> The B2BUAs at the network borders (the 3GPP  IBCF) has a profile = about
> which headers to pass and which
> headers to drop towards networks which are considered untrusted. The H= -I
> will not be passed towards untrusted networks.     = ; 
>
> A dedicated UUI-header will probably have good chances to cross the > network borders.
>
> And I am fine with a more general header which is used for other
> applications as well.
>
>
>
> Thanks a lot
> Laura
>    
>
>
>            &nbs= p;  I suppose one could argue that if we were to provide the
> means to
>            &nbs= p;  classify and identify parameters for particular purposes
> we would make
>            &nbs= p;  it easier for middle boxes to make policy decisions
> about whether to let
>            &nbs= p;  them pass or not.
>
>            &nbs= p;  Personally I just want the providers to keep their hands
> off my data.
>
>            &nbs= p;  I'm largely in agreement with what Dean and Spencer have
> been saying.
>
>            &nbs= p;          Thanks,
>            &nbs= p;          Paul
>
>            &nbs= p;  > Thanks a lot
>            &nbs= p;  > Laura
>            &nbs= p;  >
>            &nbs= p;  >
>            &nbs= p;  > -----Original Message-----
>            &nbs= p;  > From: Spencer Dawkins
> [mailto:spencer@wonderham= ster.org]
>            &nbs= p;  > Sent: Wednesday, August 12, 2009 3:07 PM
>            &nbs= p;  > To: Paul Kyzivat
>            &nbs= p;  > Cc: sipcore@ietf.org; L= iess, Laura
>            &nbs= p;  > Subject: Re: [sipcore] RFC 4244 bis use cases and
> UAC->UAS parameter
>            &nbs= p;  > delivery
>            &nbs= p;  >
>            &nbs= p;  > Hi, Paul,
>            &nbs= p;  >
>            &nbs= p;  >>> H-I is frequently removed by B2BUAs at the netwo= rk
> border so the UUI
>            &nbs= p;  > may
>            &nbs= p;  >>> not reach it's destination. For UUI, we need a n= ew
> parameter which is
>            &nbs= p;  >>> not removed by intermediaries.
>            &nbs= p;  >> When talking about a new thing added to a message, > you can have no
>            &nbs= p;  >> guarantees of whether it will survive B2BUAs or not.=
> If the B2BUA
>            &nbs= p;  > removes
>            &nbs= p;  >> anything it doesn't understand then this new thing > may will not
>            &nbs= p;  > survive.
>            &nbs= p;  >> Or it might remove it even when it does understand i= t
> if it thinks
>            &nbs= p;  > this
>            &nbs= p;  >> might contain sensitive information.
>            &nbs= p;  >>
>            &nbs= p;  >> Thanks,
>            &nbs= p;  >> Paul
>            &nbs= p;  >>
>            &nbs= p;  >>> Kind regards
>            &nbs= p;  >>> Laura
>            &nbs= p;  >
>            &nbs= p;  > If I understood Laura's concern, it's that people are > already making the
>            &nbs= p;  >
>            &nbs= p;  > policy decision to drop H-I entries at network edges
> to do topology
>            &nbs= p;  > hiding.
>            &nbs= p;  >
>            &nbs= p;  > I agree with what you're saying ("no guarantees&quo= t; about
> a new header
>            &nbs= p;  > field),
>            &nbs= p;  > but if a new header field is used, it would be
> possible for B2BUAs that
>            &nbs= p;  > remove anything they don't understand to stop removing > the new header
>            &nbs= p;  > field.
>            &nbs= p;  > If History-Info is (re-)used, the B2BUA can't do
> topology hiding and
>            &nbs= p;  > still
>            &nbs= p;  > pass UUI, can it?
>            &nbs= p;  >
>            &nbs= p;  > (I'm not talking about whether topology hiding should > happen - just
>            &nbs= p;  > trying
>            &nbs= p;  > to help with the discussion)
>            &nbs= p;  >
>            &nbs= p;  > Thanks,
>            &nbs= p;  >
>            &nbs= p;  > Spencer
>            &nbs= p;  >
>            &nbs= p;  >
>
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.= org/mailman/listinfo/sipcore

--_000_C6AAED64565Bhsinnreiadobecom_-- From wwwrun@core3.amsl.com Fri Aug 14 12:41:11 2009 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 943683A69E8; Fri, 14 Aug 2009 12:41:11 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090814194111.943683A69E8@core3.amsl.com> Date: Fri, 14 Aug 2009 12:41:11 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] Last Call: draft-ietf-sipcore-presence-scaling-requirements (Scaling Requirements for Presence in SIP/SIMPLE) to Informational RFC X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 19:41:11 -0000 The IESG has received a request from the Session Initiation Protocol Core WG (sipcore) to consider the following document: - 'Scaling Requirements for Presence in SIP/SIMPLE ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-08-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sipcore-presence-scaling-requirements-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18507&rfc_flag=0 From pkyzivat@cisco.com Fri Aug 14 12:43:08 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47F573A6D27 for ; Fri, 14 Aug 2009 12:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ts-Di9WHPZQN for ; Fri, 14 Aug 2009 12:43:07 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C206D3A6B93 for ; Fri, 14 Aug 2009 12:43:06 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALVahUpAZnme/2dsb2JhbAC6PYgtkQUFgjKBZw X-IronPort-AV: E=Sophos;i="4.43,381,1246838400"; d="scan'208";a="54171559" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 14 Aug 2009 19:43:10 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7EJhAWv011019; Fri, 14 Aug 2009 15:43:10 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7EJhAQ8004303; Fri, 14 Aug 2009 19:43:10 GMT 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.3959); Fri, 14 Aug 2009 15:43:10 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Aug 2009 15:43:10 -0400 Message-ID: <4A85BE4D.9030201@cisco.com> Date: Fri, 14 Aug 2009 15:43:09 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Henry Sinnreich References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Aug 2009 19:43:10.0133 (UTC) FILETIME=[7403A650:01CA1D17] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8349; t=1250278990; x=1251142990; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20RFC=204244=20bis=20use=20ca ses=20and=20UAC->UAS=20parameter=20delivery |Sender:=20 |To:=20Henry=20Sinnreich=20; bh=eIpNCwe9d4DZrnqIFMWRyAWuJfgrQ1NMnowCLcApjX4=; b=n7/x8oSO/ddK4vF6eFSF/NuKELcyM1e/+0IrHz8qjTjO/XXaA3CbIK30md RSPQ2p7sWiIar+F2cCDm473SRblawrfw1BMGo+7O7hJ6a/IIPQMltyGQdNqJ o4meJqFJqh; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: "sipcore@ietf.org" , Laura Liess Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 19:43:08 -0000 Henry Sinnreich wrote: >>I'm *not* ok with providers censoring customer data that customers don't > want >>censored. > > Correct. I also believe it is illegal in many countries, such as in > Germany, the EU at large and in the US and Canada. Well, if I want to put something in the H-I of a request I send, and I don't want it removed, I expect some B2BUAs (and perhaps proxies) of intermediaries may well remove that based on policy of those operating the B2BUA, regardless of the customer's desire. But it will probably be argued that it *is* customer desire as expressed by agreement to some terms of service. Paul > Henry > > On 8/14/09 8:03 AM, "Paul Kyzivat" wrote: > > Laura, > > As far as the intended subject of this thread, I think there is some > convergence that putting parameters into the R-URI and getting them to > the recipient via H-I is not workable, so we need a different solution > than that. Another header seems to be the current thinking, and I'm ok > with that, as long as it is general purpose. > > Beyond that we start to get into controversial territory regarding > censoring of data by providers. I'm ok with providers censoring *their > own* data as long as done in such a way that everyone knows how to make > things work when that is going on. I'm even ok with providers censoring > their customers' data as part of a terms-of-service agreement, as long > as that part is *optional*, that a customer may opt in/out of. I'm *not* > ok with providers censoring customer data that customers don't want > censored. > > Thanks, > Paul > > > L.Liess@telekom.de wrote: > > Paul, > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Thursday, August 13, 2009 3:23 PM > > To: Liess, Laura > > Cc: spencer@wonderhamster.org; sipcore@ietf.org > > Subject: Re: [sipcore] RFC 4244 bis use cases and > > UAC->UAS parameter delivery > > > > > > > > L.Liess@telekom.de wrote: > > > Paul, > > > > > > As Spencer already wrote, carriers do topology hiding > > at the network > > > border. > > > They have done it with SS7 and will do it for SIP too. > > So, H-I is > > > removed and we need another way to pass UUI. > > > > I certainly know that and AFAIK didn't imply otherwise. > > Carriers try to find a way to hide lots of things. > > The question is: will there also be reasons for carriers > > to censor > > parameters as well? > > > > B2BUAs in carrier networks already do it. > > > > I think it is is OK when it is for hiding the own network > > infrastructure. > > > > Another example is the caller's IP-address. I learned from the > security > > guys that carriers have to do this because they must > > be able to hide caller's data. And most of our customers seem to like > > it, they feel more secure. > > We have regulatory requirements to be able to hide the caller phone > > number. IP-address hiding is in a way the same, > > at least for VoIP. > > > > There are realy ugly B2BUAs in the field which have white lists > and drop > > everything they do not understand. > > We had one of them in the past and asked the vendor to change it, > but I > > am sure there are still a lot of them elsewere. > > > > The B2BUAs at the network borders (the 3GPP IBCF) has a profile about > > which headers to pass and which > > headers to drop towards networks which are considered untrusted. > The H-I > > will not be passed towards untrusted networks. > > > > A dedicated UUI-header will probably have good chances to cross the > > network borders. > > > > And I am fine with a more general header which is used for other > > applications as well. > > > > > > > > Thanks a lot > > Laura > > > > > > > > I suppose one could argue that if we were to provide the > > means to > > classify and identify parameters for particular purposes > > we would make > > it easier for middle boxes to make policy decisions > > about whether to let > > them pass or not. > > > > Personally I just want the providers to keep their hands > > off my data. > > > > I'm largely in agreement with what Dean and Spencer have > > been saying. > > > > Thanks, > > Paul > > > > > Thanks a lot > > > Laura > > > > > > > > > -----Original Message----- > > > From: Spencer Dawkins > > [mailto:spencer@wonderhamster.org] > > > Sent: Wednesday, August 12, 2009 3:07 PM > > > To: Paul Kyzivat > > > Cc: sipcore@ietf.org; Liess, Laura > > > Subject: Re: [sipcore] RFC 4244 bis use cases and > > UAC->UAS parameter > > > delivery > > > > > > Hi, Paul, > > > > > >>> H-I is frequently removed by B2BUAs at the network > > border so the UUI > > > may > > >>> not reach it's destination. For UUI, we need a new > > parameter which is > > >>> not removed by intermediaries. > > >> When talking about a new thing added to a message, > > you can have no > > >> guarantees of whether it will survive B2BUAs or not. > > If the B2BUA > > > removes > > >> anything it doesn't understand then this new thing > > may will not > > > survive. > > >> Or it might remove it even when it does understand it > > if it thinks > > > this > > >> might contain sensitive information. > > >> > > >> Thanks, > > >> Paul > > >> > > >>> Kind regards > > >>> Laura > > > > > > If I understood Laura's concern, it's that people are > > already making the > > > > > > policy decision to drop H-I entries at network edges > > to do topology > > > hiding. > > > > > > I agree with what you're saying ("no guarantees" about > > a new header > > > field), > > > but if a new header field is used, it would be > > possible for B2BUAs that > > > remove anything they don't understand to stop removing > > the new header > > > field. > > > If History-Info is (re-)used, the B2BUA can't do > > topology hiding and > > > still > > > pass UUI, can it? > > > > > > (I'm not talking about whether topology hiding should > > happen - just > > > trying > > > to help with the discussion) > > > > > > Thanks, > > > > > > Spencer > > > > > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From adam@nostrum.com Fri Aug 14 12:57:18 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36EDE3A6BB0 for ; Fri, 14 Aug 2009 12:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrCJsT2505Om for ; Fri, 14 Aug 2009 12:57:17 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 7BA6C3A688D for ; Fri, 14 Aug 2009 12:57:16 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n7EJv9dH071266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Aug 2009 14:57:09 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A85C195.4060903@nostrum.com> Date: Fri, 14 Aug 2009 14:57:09 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Ian Elz References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 19:57:18 -0000 Ian Elz wrote: > > Sections 4.5 and 4.5.1 define how to target SUBSCRIBE to a device > using gruu. Is it worth including in this section that to target a > SUBSCRIBE to a dialog at the device you need to use the Target-Dialog > header? The use of T-D would depend upon the event package but > including it here would provide a reminder that event packages should > consider this if necessary. > I agree that this kind of guidance would indeed be useful. I've added some text to 4.5: This dialog-sharing technique has also historically been used as a means for targeting an event package at a dialog. This usage can be seen, for example, in certain applications of the REFER method [RFC3515]. With the removal of dialog re-use, an alternate (and more explicit) means of targeting dialogs needs to be used for this type of correlation. The appropriate means of such targeting is left up to the actual event packages. Candidates include the "Target-Dialog" header field [RFC4528], the "Join" header field [RFC3911], and the "Replaces" header field [RFC3891], depending on the semantics desired. Alternately, if the semantics of those header fields do not match the event package's purpose for correlation, event packages can devise their own means of identifying dialogs. For an example of this approach, see the Dialog Event Package [RFC4235]. > Now a more complex issue: > > You are proposing that the first NOTIFY establishes the SUBSCRIBE > dialog. What impact does this have on the establishment of the route > set at the UAC as defined in RFC3261? > From a practical perspective, it's the same as what we have in 3265 -- except that it's a little easier to implement at the subscriber. Keep in mind that 3265 describes dialogs being established by NOTIFY requests -- this is not new in the 3265bis draft. The only difference in dialog establishment is that we're removing the ability for a SUBSCRIBE 200 response to create a dialog. This is an extremely important point, so I'll repeat it: this change is not *ADDING* new behavior. It is *REMOVING* unnecessary behavior that has been shown to cause problems. > Normal RFC3261 has the UAS route set taken from Record-Route in the > initial request. The UAS then copies the Record-Route back into the > 2xx response (or reliable provisional response) which is then used by > the UAC to set its the route set. This ensures that the route sets in > the UAC and UAS align. > > Section 4.3 of the draft proposes that the initial SUBSCRIBE has the > normal Record-Route which establishes the UAS route set but that the > NOTIFY also has Record-Route performed by proxies. This leaves the > possibility that the route set at the UAC and UAS may not align. > Actually, it doesn't. As long as proxies follow the guidance in 4.3, then the route set in the SUBSCRIBE will be precisely identical to the route set established by the NOTIFY. Because of the Record-Route in the SUBSCRIBE, the NOTIFY will contain Route header fields that guarantee that the NOTIFY traverses the proxies that Record-Route the SUBSCRIBE. These proxies, by the normative requirement in 4.3, will then Record-Route the NOTIFY, which guarantees that the route set in the subscriber matches that of the notifier. If you think I'm confused about this in some way, please describe a concrete set of compliant proxy behaviors that can result in an asymmetrical route set, preferably using a sequence diagram. > I also have a concern as to what will happen with the route set if the > SUBSCRIBE Record-Route is returned in the 2xx and the NOTIFY also > includes a Record-Route. Which one is used to establish the route set > at the subscriber. Do we take the one which arrives first? Do we take > the one which arrives second? There is no issue if they are the same > but what if they differ? > As I mention above: In a compliant system, they can't differ. However, as we all know, systems don't always do the right thing. SBCs can tinker with Route/Record-Route in ways that create asymmetric route sets, even for normal INVITE/200/ACK transactions. With 3265, if there *were* a difference, your question is highly relevant: the answer to "but what if they differ?" was a resounding "I have no clue!" Which is one of the key reasons why we made this change. In 3265bis, the answer is straightforward: since the NOTIFY establishes the dialog, the NOTIFY is where the route set comes from. Really, the 200 response is kind of a throw-away message anyway. Even with legacy 3265 behavior, if I have a SUBSCRIBE fork, and it establishes two dialogs, I'm going to have to take the route set for at least one of the dialogs from the NOTIFY -- so I may as well always take it from the NOTIFY. > Should there be a requirement that proxies MUST include themselves in > the NOTIFY Record-Route if they included themselves in the SUBSCRIBE > Record-Route and to exclude themselves in the NOTUFY if they were not > in the SUBSCRIBE Record-Route. > That's certainly the intention of 4.3. It's a bit tortured to imagine that a proxy might be on the path of the NOTIFY without having Record-Routing the SUBSCRIBE. Nonetheless, I'm okay with prohibiting Record-Routing a NOTIFY unless you've also Record-Routed the associated SUBSCRIBE; I'll add: Proxies that did not add a Record-Route header field to the initial SUBSCRIBE request MUST NOT add a Record-Route header field to any of the associated NOTIFY requests. > If we are to use the Record-Route in the NOTIFY then the draft should > explicitly state what should happen at the subscriber end. Should the > 2xx response to the NOTIFY include a copy of the Record-Route taken > from the NOTIFY? > It doesn't matter. > What does the notifier end do if it then receives this Record-Route? > It ignores it. There is no way to change a dialog route set (other than the remote target) mid-dialog. > There is one more related issue: > > What happens if the 2xx to the SUBSCRIBE transaction is never received > by the subscriber. Based upon the non-INVITE client transaction in > RFC3261 the termination of the transaction upon expiry of Timer F will > inform the TU. In normal cases the TU would terminate the transaction > and drop the dialog In this case if the NOTIFY has been received > before the 2xx then this should be treated as the 2xx from the > transaction perspective. This almost goes as far as defining a > separate client SUBSCRIBE transaction. > Again, this behavior was present in 3265, and quite deliberately so. Keep in mind: for any network that has even a single proxy that doesn't Record-Route, the vast majority of SUBSCRIBE dialogs will be established by the NOTIFY, not the 200 (since the NOTIFY will follow a shorter path than the 200). And, with forking, all but one of the 200 responses will be discarded by the proxy anyway. You *really* don't want the system behavior to vary based on which 200 response wins the race to the proxy. /a From adam@nostrum.com Fri Aug 14 13:53:31 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 836993A6A79 for ; Fri, 14 Aug 2009 13:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ep6Y784Xc-DY for ; Fri, 14 Aug 2009 13:53:30 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 5644F3A6872 for ; Fri, 14 Aug 2009 13:53:29 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n7EKrWmD075548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 14 Aug 2009 15:53:33 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A85CECC.3020401@nostrum.com> Date: Fri, 14 Aug 2009 15:53:32 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] 3265bis Open Issue: Timer N and Resubscribes X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 20:53:31 -0000 One of the things we discussed in Stockholm was whether a Timer N expiration on resubscribe causes the subscription to be terminated. This was posed as a purely theoretical situation, with no concrete circumstances in mind under which it might occur. (As a refresher: Timer N is the timer run between sending a SUBSCRIBE and receiving a NOTIFY. For the initial SUBSCRIBE, the expiration of Timer N causes the subscription set up to fail. This was called Timer L in 3265bis-00, but is being renamed Timer N to avoid colliding with invite-fix). I've given a lot of thought to what set of circumstances would lead to conditions in which the SUBSCRIBE 200 response is arriving just fine, but the NOTIFY is being consistently lost (at least, consistently enough for Timer N to expire). The only plausible scenarios I've been able to construct involve some signaling intermediary changing an address association in the middle of a subscription. For example: imagine a client behind a NAT uses STUN to determine a viable public address/port combination. It then composes an initial SUBSCRIBE message and sends it off to the notifier. The initial NOTIFY arrives just fine. Later in the subscription, the NAT resets the association between the subscriber and the external NAT port. Because of the Via header field received and rport parameters, the 200 responses to SUBSCRIBE messages will continue to be routed back to the subscriber. However, because the address/port in the Contact no longer route back to the subscriber, the NOTIFY messages will never arrive. This behavior can also arrive if the local address for a machine changes -- say, due to a DHCP address assignment changing, or a PPP tunnel being re-established with a different IP address. In all of these cases, I think it's pretty obvious that there is no hope of the subscription ever recovering. Leaving it lying around until it expires has no benefits, and wastes resources at both the subscriber and the notifier. On top of that, it give the subscriber application the impression of being subscribed to state changes, when none will ever actually arrive. For these reasons, I would strongly recommend that the expiration of the new supervisory timer (Timer L in 3265bis-00, Timer N in the forthcoming 3265bis-01) during a re-subscribe result in the subscription being terminated. /a From ian.elz@ericsson.com Mon Aug 17 01:36:01 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0770E3A67A6 for ; Mon, 17 Aug 2009 01:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.249 X-Spam-Level: X-Spam-Status: No, score=-5.249 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVNKreaf9U1j for ; Mon, 17 Aug 2009 01:36:00 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 75DB03A67B6 for ; Mon, 17 Aug 2009 01:35:58 -0700 (PDT) X-AuditID: c1b4fb3c-b7c01ae000002aae-4e-4a89165dc781 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id E8.55.10926.D56198A4; Mon, 17 Aug 2009 10:35:41 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 10:35:34 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Aug 2009 10:35:33 +0200 Message-ID: In-Reply-To: <4A85C195.4060903@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-roach-sipcore-rfc3265bis-00 - Section 4.5 Thread-Index: AcodGW5238OFDawnQ6yeQz3Ul+/ywAB/BfOQ References: <4A85C195.4060903@nostrum.com> From: "Ian Elz" To: "Adam Roach" X-OriginalArrivalTime: 17 Aug 2009 08:35:34.0826 (UTC) FILETIME=[B06E18A0:01CA1F15] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 - Section 4.5 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 08:36:01 -0000 Adam, 1st of 2 responses Easy one first. This sounds fine - better than I would have expressed it. Ian -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: 14 August 2009 20:57 To: Ian Elz Cc: sipcore@ietf.org; Christer Holmberg Subject: Re: draft-roach-sipcore-rfc3265bis-00 Ian Elz wrote: > > Sections 4.5 and 4.5.1 define how to target SUBSCRIBE to a device=20 > using gruu. Is it worth including in this section that to target a=20 > SUBSCRIBE to a dialog at the device you need to use the Target-Dialog=20 > header? The use of T-D would depend upon the event package but=20 > including it here would provide a reminder that event packages should=20 > consider this if necessary. > I agree that this kind of guidance would indeed be useful. I've added some text to 4.5: This dialog-sharing technique has also historically been used as a means for targeting an event package at a dialog. This usage can be seen, for example, in certain applications of the REFER method [RFC3515]. With the removal of dialog re-use, an alternate (and more explicit) means of targeting dialogs needs to be used for this type of correlation. The appropriate means of such targeting is left up to the actual event packages. Candidates include the "Target-Dialog" header field [RFC4528], the "Join" header field [RFC3911], and the "Replaces" header field [RFC3891], depending on the semantics desired. Alternately, if the semantics of those header fields do not match the event package's purpose for correlation, event packages can devise their own means of identifying dialogs. For an example of this approach, see the Dialog Event Package [RFC4235]. From christer.holmberg@ericsson.com Mon Aug 17 03:19:40 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B7013A6EDD for ; Mon, 17 Aug 2009 03:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.587 X-Spam-Level: X-Spam-Status: No, score=-5.587 tagged_above=-999 required=5 tests=[AWL=0.662, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHAlXbQ5GjXC for ; Mon, 17 Aug 2009 03:19:39 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id ECF7F28C2A5 for ; Mon, 17 Aug 2009 03:19:16 -0700 (PDT) X-AuditID: c1b4fb3c-b7c01ae000002aae-8a-4a892ea84b1f Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id D2.7E.10926.8AE298A4; Mon, 17 Aug 2009 12:19:20 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 12:19: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 Date: Mon, 17 Aug 2009 12:19:11 +0200 Message-ID: In-Reply-To: <4A85C195.4060903@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-roach-sipcore-rfc3265bis-00 Thread-Index: AcodGW4n+3S/NSiORima/2vi8mr0YAB8az0A References: <4A85C195.4060903@nostrum.com> From: "Christer Holmberg" To: "Adam Roach" , "Ian Elz" X-OriginalArrivalTime: 17 Aug 2009 10:19:13.0284 (UTC) FILETIME=[2AEB7C40:01CA1F24] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 10:19:40 -0000 Hi, It's a while since I read the subscribe stuff, but I have some questions/comments. >>Now a more complex issue: >> >>You are proposing that the first NOTIFY establishes the SUBSCRIBE=20 >>dialog. What impact does this have on the establishment of=20 >>the route set at the UAC as defined in RFC3261? >>=20 >From a practical perspective, it's the same as what we have=20 >in 3265 -- except that it's a little easier to implement at=20 >the subscriber. >=20 >Keep in mind that 3265 describes dialogs being established by=20 >NOTIFY requests -- this is not new in the 3265bis draft. > >The only difference in dialog establishment is that we're=20 >removing the ability for a SUBSCRIBE 200 response to create a dialog. > >This is an extremely important point, so I'll repeat it: this=20 >change is not *ADDING* new behavior. It is *REMOVING*=20 >unnecessary behavior that has been shown to cause problems. Has it been considered that a forking proxy would forward multiple SUBSCRIBE 200 responses instead? Also, I know that 3261 says that only one final response is forwarded for non-INVITE requests. I just wonder whether it means non-dialog initiation requests. Because, what does a proxy do if it receives additional 200 responses? I can't find any text about that in 3261. >>Normal RFC3261 has the UAS route set taken from Record-Route in the=20 >>initial request. The UAS then copies the Record-Route back into the=20 >>2xx response (or reliable provisional response) which is then used by=20 >>the UAC to set its the route set. This ensures that the route sets in=20 >>the UAC and UAS align. >> >>Section 4.3 of the draft proposes that the initial SUBSCRIBE has the=20 >>normal Record-Route which establishes the UAS route set but=20 >>that the NOTIFY also has Record-Route performed by proxies. This leaves the=20 >>possibility that the route set at the UAC and UAS may not align. >>=20 >Actually, it doesn't. As long as proxies follow the guidance=20 >in 4.3, then the route set in the SUBSCRIBE will be precisely=20 >identical to the route set established by the NOTIFY. >Because of the Record-Route in the SUBSCRIBE, the NOTIFY will contain=20 >Route header fields that guarantee that the NOTIFY traverses=20 >the proxies that Record-Route the SUBSCRIBE.=20 >These proxies, by the normative requirement in 4.3, will then=20 >Record-Route the NOTIFY, which guarantees that the route set=20 >in the subscriber matches that of the notifier. > >If you think I'm confused about this in some way, please=20 >describe a concrete set of compliant proxy behaviors that can=20 >result in an asymmetrical route set, preferably using a=20 >sequence diagram. I guess the UAS could simply copy the Record-Route into the NOTIFY, as it does in the 200 response. That way the proxies would not need to add it. But, again, wouldn't the easiest way be to make sure that all 200/202 responses are forwarded to the UAC? I guess another option would be to send a 18x, in order to provide the Record-Route. =20 >>I also have a concern as to what will happen with the route set if the >>SUBSCRIBE Record-Route is returned in the 2xx and the NOTIFY also=20 >>includes a Record-Route. Which one is used to establish the route set=20 >>at the subscriber. Do we take the one which arrives first?=20 >Do we take the one which arrives second? There is no issue if they are=20 >the same but what if they differ? >=20 >As I mention above: In a compliant system, they can't differ.=20 >However, as we all know, systems don't always do the right=20 >thing. SBCs can tinker with Route/Record-Route in ways that=20 >create asymmetric route sets, even for normal INVITE/200/ACK=20 >transactions. I am not really sure what is meant by "compliant system". A system may be RFC3261 compliant, which means they may add Record-Route the SUBSCRIBE request, but they will not Record-Route the NOTIFY. >With 3265, if there *were* a difference, your question is highly >relevant: the answer to "but what if they differ?" was a=20 >resounding "I have no clue!" >=20 >Which is one of the key reasons why we made this change. >=20 >In 3265bis, the answer is straightforward: since the NOTIFY=20 >establishes the dialog, the NOTIFY is where the route set comes from. >=20 >Really, the 200 response is kind of a throw-away message=20 >anyway. Even with legacy 3265 behavior, if I have a SUBSCRIBE=20 >fork, and it establishes two dialogs, I'm going to have to=20 >take the route set for at least one of the dialogs from the=20 >NOTIFY -- so I may as well always take it from the NOTIFY. > >>Should there be a requirement that proxies MUST include=20 >>themselves in the NOTIFY Record-Route if they included themselves in the=20 >>SUBSCRIBE Record-Route and to exclude themselves in the NOTUFY if=20 >>they were not in the SUBSCRIBE Record-Route. >> >=20 >That's certainly the intention of 4.3. It's a bit tortured to=20 >imagine that a proxy might be on the path of the NOTIFY=20 >without having Record-Routing the SUBSCRIBE. Nonetheless, I'm=20 >okay with prohibiting Record-Routing a NOTIFY unless you've=20 >also Record-Routed the associated SUBSCRIBE; I'll add: >=20 > Proxies that did not add a Record-Route header field to the > initial SUBSCRIBE request MUST NOT add a Record-Route header > field to any of the associated NOTIFY requests. Don't you need a Proxy-Require option tag for that?=20 Again, a 3261 compliant proxy may Record-Route the SUBSCRIBE, but that doesn't mean it will Record-Route the NOTIFY. It may simply be configured to Record-Route all dialog initiation requests. Regards, Christer >>If we are to use the Record-Route in the NOTIFY then the draft should=20 >>explicitly state what should happen at the subscriber end. Should the=20 >>2xx response to the NOTIFY include a copy of the Record-Route taken=20 >>from the NOTIFY? >> >=20 >It doesn't matter. >=20 >>What does the notifier end do if it then receives this Record-Route? >> >=20 >It ignores it. There is no way to change a dialog route set (other than the remote target) mid-dialog. >=20 >=20 >>There is one more related issue: >> >>What happens if the 2xx to the SUBSCRIBE transaction is never received >>by the subscriber. Based upon the non-INVITE client transaction in=20 >>RFC3261 the termination of the transaction upon expiry of Timer F will >>inform the TU. In normal cases the TU would terminate the transaction=20 >>and drop the dialog In this case if the NOTIFY has been received=20 >>before the 2xx then this should be treated as the 2xx from the=20 >>transaction perspective. This almost goes as far as defining a=20 >>separate client SUBSCRIBE transaction. >>=20 >Again, this behavior was present in 3265, and quite deliberately so.=20 >Keep in mind: for any network that has even a single proxy=20 >that doesn't Record-Route, the vast majority of SUBSCRIBE dialogs will be=20 >established by the NOTIFY, not the 200 (since the NOTIFY will follow a=20 >shorter path than the 200). And, with forking, all but one of the 200=20 >responses will be discarded by the proxy anyway. You *really* don't want the system=20 >behavior to vary based on which 200 response wins the race to the proxy. From ian.elz@ericsson.com Mon Aug 17 03:40:31 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8C193A67B8 for ; Mon, 17 Aug 2009 03:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8gbpREBhHeK for ; Mon, 17 Aug 2009 03:40:26 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 78B323A6ECA for ; Mon, 17 Aug 2009 03:40:24 -0700 (PDT) X-AuditID: c1b4fb3e-b7b8dae000002a0a-08-4a89339bbb02 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 1D.F1.10762.B93398A4; Mon, 17 Aug 2009 12:40:27 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 12:40:27 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Aug 2009 12:40:26 +0200 Message-ID: In-Reply-To: <4A85C195.4060903@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-roach-sipcore-rfc3265bis-00 - Record-Route and tranaction state model. Thread-Index: AcodGW5238OFDawnQ6yeQz3Ul+/ywAB/EhbA References: <4A85C195.4060903@nostrum.com> From: "Ian Elz" To: "Adam Roach" X-OriginalArrivalTime: 17 Aug 2009 10:40:27.0636 (UTC) FILETIME=[227E2B40:01CA1F27] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 - Record-Route and tranaction state model. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 10:40:34 -0000 Adam. I understand that most of what I commented on was included in RFC3265. The problem with RFC3265 was that a lot of the detail was missing. The concept of the new draft is to correct those omissions and to simplify and clarify what was included in RFC3265. RFC3265 does not include anything about how the subscriber (I will use subscriber and notifier as UAC/UAS reverse for the SUBSCRIBE and NOTIFY.) obtains his route set. If the new RFC does not explicitly state that the subscriber route set is obtained from the Record-Route header contained in the NOTIFY then RFC3261 applies the subscriber route set is obtained form the 2xx to the SUBSCRIBE. This will make for an interesting dialog if the 2xx to the SUSCRIBE is never received. Specific responses in-line [ige]. Ian -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com] Sent: 14 August 2009 20:57 To: Ian Elz Cc: sipcore@ietf.org; Christer Holmberg Subject: Re: draft-roach-sipcore-rfc3265bis-00 Ian Elz wrote: > Now a more complex issue: > > You are proposing that the first NOTIFY establishes the SUBSCRIBE > dialog. What impact does this have on the establishment of the route > set at the UAC as defined in RFC3261? > From a practical perspective, it's the same as what we have in 3265 -- except that it's a little easier to implement at the subscriber. Keep in mind that 3265 describes dialogs being established by NOTIFY requests -- this is not new in the 3265bis draft. The only difference in dialog establishment is that we're removing the ability for a SUBSCRIBE 200 response to create a dialog. This is an extremely important point, so I'll repeat it: this change is not *ADDING* new behavior. It is *REMOVING* unnecessary behavior that has been shown to cause problems. [ige] I understand that you are not adding any functionality which is different from RFC3265. The problem is that what was in RFC3265 changed the actions specified in RFC3261 but did not state how they hade been changed. This is part of what caused the problems in RFC3265. The updated RFC MUST include this detail or we will end up with inconsistent implementations. > Normal RFC3261 has the UAS route set taken from Record-Route in the > initial request. The UAS then copies the Record-Route back into the > 2xx response (or reliable provisional response) which is then used by > the UAC to set its the route set. This ensures that the route sets in > the UAC and UAS align. > > Section 4.3 of the draft proposes that the initial SUBSCRIBE has the > normal Record-Route which establishes the UAS route set but that the > NOTIFY also has Record-Route performed by proxies. This leaves the > possibility that the route set at the UAC and UAS may not align. > Actually, it doesn't. As long as proxies follow the guidance in 4.3, then the route set in the SUBSCRIBE will be precisely identical to the route set established by the NOTIFY. Because of the Record-Route in the SUBSCRIBE, the NOTIFY will contain Route header fields that guarantee that the NOTIFY traverses the proxies that Record-Route the SUBSCRIBE. These proxies, by the normative requirement in 4.3, will then Record-Route the NOTIFY, which guarantees that the route set in the subscriber matches that of the notifier. If you think I'm confused about this in some way, please describe a concrete set of compliant proxy behaviors that can result in an asymmetrical route set, preferably using a sequence diagram. [ige] The problem we have is backward compatibility. If the subscriber and notifier support the proposed new functionality but an intermediate proxies does not then this may result in an asymmetric route sets. The SUBSCRIBE will be seen by the proxy as a dialog initiating request and will add itself to the Record-Route in the SUBSCRIBE. When the NOTIFY is handled however there is no requirement in RFC3261 to include itself in the Record-route as RFC3261 is explicit in the fact that any Record-route added to the NOTIFY will NOT update the route set. Thus asymmetric route sets will result. This will result in SUSCRIBE messages being passed via different proxies than the NOTIFY with the result that some proxies will see a subscription termination resulting from a SUBSCRIBE but not from a NOTIFY or as the result of a rejection of a NOTIFY. > I also have a concern as to what will happen with the route set if the > SUBSCRIBE Record-Route is returned in the 2xx and the NOTIFY also > includes a Record-Route. Which one is used to establish the route set > at the subscriber. Do we take the one which arrives first? Do we take > the one which arrives second? There is no issue if they are the same > but what if they differ? > As I mention above: In a compliant system, they can't differ. However, as we all know, systems don't always do the right thing. SBCs can tinker with Route/Record-Route in ways that create asymmetric route sets, even for normal INVITE/200/ACK transactions. With 3265, if there *were* a difference, your question is highly relevant: the answer to "but what if they differ?" was a resounding "I have no clue!" Which is one of the key reasons why we made this change. In 3265bis, the answer is straightforward: since the NOTIFY establishes the dialog, the NOTIFY is where the route set comes from. Really, the 200 response is kind of a throw-away message anyway. Even with legacy 3265 behavior, if I have a SUBSCRIBE fork, and it establishes two dialogs, I'm going to have to take the route set for at least one of the dialogs from the NOTIFY -- so I may as well always take it from the NOTIFY. [ige] Agree that with forking only a single 200 OK will mean that NOTIFY will be used to establish other SUBSCRIBE dialogs. This appears to be an issue with forking and RFC3261 where only a single 2xx response is returned. If I subscribe and multiple nodes accept the subscription e.g. I subscribe to the dialog-event mechanism for all dialogs for a user, why shouldn't multiple 2xx responses to the SUBSCRIBE be returned to establish multiple dialogs and to set up the route sets for each of those dialogs. > Should there be a requirement that proxies MUST include themselves in > the NOTIFY Record-Route if they included themselves in the SUBSCRIBE > Record-Route and to exclude themselves in the NOTUFY if they were not > in the SUBSCRIBE Record-Route. > That's certainly the intention of 4.3. It's a bit tortured to imagine that a proxy might be on the path of the NOTIFY without having Record-Routing the SUBSCRIBE. Nonetheless, I'm okay with prohibiting Record-Routing a NOTIFY unless you've also Record-Routed the associated SUBSCRIBE; I'll add: Proxies that did not add a Record-Route header field to the initial SUBSCRIBE request MUST NOT add a Record-Route header field to any of the associated NOTIFY requests. [ige] But there is nothing to indicate that proxies which did add themselves to the Record-Route in the SUBSCRIBE MUST add themselves to the Record-Route in subsequent NOTIFY requests for the same dialog (?). This does not remove the compatibility issue where the proxy does not support the updates included in the draft. > If we are to use the Record-Route in the NOTIFY then the draft should > explicitly state what should happen at the subscriber end. Should the > 2xx response to the NOTIFY include a copy of the Record-Route taken > from the NOTIFY? > It doesn't matter. [ige] If you don't include normative text which specifies that the route set is established from the Record-Route in the NOTIFY then RFC3261 applies and the route set at the subscriber is obtained from the 2xx to the SUBSCRIBE. > What does the notifier end do if it then receives this Record-Route? > It ignores it. There is no way to change a dialog route set (other than the remote target) mid-dialog. [ige] Is what you are saying is that for one dialog you may take the route set from the 2xx to the SUBSCRIBE, depending upon whether the NOTIFY or 2xx arrives first, and for other dialogs it is taken from the NOTIFY. In the forked case you may then end up with one symmetric route set and multiple asymmetric route sets; i.e. all the proxies may see subsequent SUBSCRIBE requests for one dialog but not for the others. I am not sure what this will do to the proxies handling of the dialogs if anything but we need to consider it to be sure. > There is one more related issue: > > What happens if the 2xx to the SUBSCRIBE transaction is never received > by the subscriber. Based upon the non-INVITE client transaction in > RFC3261 the termination of the transaction upon expiry of Timer F will > inform the TU. In normal cases the TU would terminate the transaction > and drop the dialog In this case if the NOTIFY has been received > before the 2xx then this should be treated as the 2xx from the > transaction perspective. This almost goes as far as defining a > separate client SUBSCRIBE transaction. > Again, this behavior was present in 3265, and quite deliberately so. Keep in mind: for any network that has even a single proxy that doesn't Record-Route, the vast majority of SUBSCRIBE dialogs will be established by the NOTIFY, not the 200 (since the NOTIFY will follow a shorter path than the 200). And, with forking, all but one of the 200 responses will be discarded by the proxy anyway. You *really* don't want the system behavior to vary based on which 200 response wins the race to the proxy. [ige] No we don't want the behaviour based upon whether the 2xx of the NOTIFY wins the race. This is why the draft needs to be explicit upon how the route set is determined at the subscriber end. /a From adam@nostrum.com Mon Aug 17 12:41:30 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B52628C322 for ; Mon, 17 Aug 2009 12:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.783 X-Spam-Level: X-Spam-Status: No, score=-2.783 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTlesHqdNT-K for ; Mon, 17 Aug 2009 12:41:27 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 6F0D028C2FE for ; Mon, 17 Aug 2009 12:41:25 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n7HJfOEX035364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Aug 2009 14:41:24 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A89B264.5060003@nostrum.com> Date: Mon, 17 Aug 2009 14:41:24 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Ian Elz References: <4A85C195.4060903@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 - Record-Route and tranaction state model. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 19:41:30 -0000 [I've elided some of the original message because it was based on a misunderstanding. Instead of citing RFC 3265 section 3.1.5 several times, I've cited it once and removed the other paragraphs that related to this misunderstanding] Ian Elz wrote: > RFC3265 does not include anything about how the subscriber (I will use > subscriber and notifier as UAC/UAS reverse for the SUBSCRIBE and > NOTIFY.) obtains his route set. If the new RFC does not explicitly state > that the subscriber route set is obtained from the Record-Route header > contained in the NOTIFY then RFC3261 applies the subscriber route set is > obtained form the 2xx to the SUBSCRIBE. This will make for an > interesting dialog if the 2xx to the SUSCRIBE is never received. > So what you'd really like to see is explicit language describing when and how the subscriber and notifier form their route sets. That seems useful to add. I'll try to get some language explicitly describing this in the next draft. > [ige] The problem we have is backward compatibility. If the subscriber > and notifier support the proposed new functionality but an intermediate > proxies does not then this may result in an asymmetric route sets. The > SUBSCRIBE will be seen by the proxy as a dialog initiating request and > will add itself to the Record-Route in the SUBSCRIBE. When the NOTIFY is > handled however there is no requirement in RFC3261 to include itself in > the Record-route as RFC3261 is explicit in the fact that any > Record-route added to the NOTIFY will NOT update the route set. Thus > asymmetric route sets will result. You've missed some important text in section 3.1.5 of 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. > [ige] Agree that with forking only a single 200 OK will mean that NOTIFY > will be used to establish other SUBSCRIBE dialogs. This appears to be an > issue with forking and RFC3261 where only a single 2xx response is > returned. If I subscribe and multiple nodes accept the subscription e.g. > I subscribe to the dialog-event mechanism for all dialogs for a user, > why shouldn't multiple 2xx responses to the SUBSCRIBE be returned to > establish multiple dialogs and to set up the route sets for each of > those dialogs. > Because 3261 forbids it. We really can't require proxies to treat extension methods as special cases: proxies treating SUBSCRIBE as an arbitrary non-INVITE message must do the right thing. > [ige] Is what you are saying is that for one dialog you may take the > route set from the 2xx to the SUBSCRIBE, depending upon whether the > NOTIFY or 2xx arrives first, and for other dialogs it is taken from the > NOTIFY. No. That's what 3265 said, and it proved too confusing. We're simplifying that. In 3265bis, the client never uses a SUBSCRIBE 200 to establish a dialog. Now it always uses the NOTIFY. /a From adam@nostrum.com Mon Aug 17 14:11:42 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A067E3A6CFD for ; Mon, 17 Aug 2009 14:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.769 X-Spam-Level: X-Spam-Status: No, score=-2.769 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2R0OMduw9I6 for ; Mon, 17 Aug 2009 14:11:41 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 507C53A6B10 for ; Mon, 17 Aug 2009 14:11:41 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n7HLBbfm074000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Aug 2009 16:11:37 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A89C789.20001@nostrum.com> Date: Mon, 17 Aug 2009 16:11:37 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Christer Holmberg References: <4A85C195.4060903@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Ian Elz , sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 21:11:42 -0000 Christer Holmberg wrote: > Has it been considered that a forking proxy would forward multiple > SUBSCRIBE 200 responses instead? > That ship sailed over a decade ago, when we published RFC 2543. We really can't require proxies to treat extension methods as special cases: proxies treating SUBSCRIBE as an arbitrary non-INVITE message must do the right thing. > Also, I know that 3261 says that only one final response is forwarded > for non-INVITE requests. I just wonder whether it means non-dialog > initiation requests. Because method names are one SIP's extension points, proxies don't inherently know which requests can form dialogs. For example, if a proxy forks a XYZZY request, how would it know whether to return a single 200 response or all of them? It has know way of knowing whether XYZZY is a dialog-forming request. > Because, what does a proxy do if it receives > additional 200 responses? I can't find any text about that in 3261. > It's going to drop them. See RFC 3261, section 16.7, step 5. > I guess the UAS could simply copy the Record-Route into the NOTIFY, as > it does in the 200 response. That way the proxies would not need to add > it. > That would make a mess -- currently deployed proxies that are aware of 3265 would add themselves a second time, resulting in a route set that passes through each proxy twice. That's really not what we want to happen. >> >> As I mention above: In a compliant system, they can't differ. >> However, as we all know, systems don't always do the right >> thing. SBCs can tinker with Route/Record-Route in ways that >> create asymmetric route sets, even for normal INVITE/200/ACK >> transactions. >> > > I am not really sure what is meant by "compliant system". A system may > be RFC3261 compliant, which means they may add Record-Route the > SUBSCRIBE request, but they will not Record-Route the NOTIFY. > See RFC 3265, section 3.1.5. >> That's certainly the intention of 4.3. It's a bit tortured to >> imagine that a proxy might be on the path of the NOTIFY >> without having Record-Routing the SUBSCRIBE. Nonetheless, I'm >> okay with prohibiting Record-Routing a NOTIFY unless you've >> also Record-Routed the associated SUBSCRIBE; I'll add: >> >> Proxies that did not add a Record-Route header field to the >> initial SUBSCRIBE request MUST NOT add a Record-Route header >> field to any of the associated NOTIFY requests. >> > > Don't you need a Proxy-Require option tag for that? > > Again, a 3261 compliant proxy may Record-Route the SUBSCRIBE, but that > doesn't mean it will Record-Route the NOTIFY. It may simply be > configured to Record-Route all dialog initiation requests. > For a proxy to have the first clue that SUBSCRIBE is a dialog initiation request, it has to be aware of the semantics of SUBSCRIBE. Otherwise, it doesn't know SUBSCRIBE from XYZZY. And if a proxy is blindly Record-Routing unknown methods, it will Record-Route the NOTIFY also. Either way, everything works. I've worked with enough implementors to know that there's never enough accounting for crazy, but the failure you're describing would require a certain amount of malice: enough understanding to know what SUBSCRIBE means, but a bewildering level of willful ignorance to then pretend not to understand NOTIFY. /a From jmpolk@cisco.com Mon Aug 17 14:49:39 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90E5C28C1C1 for ; Mon, 17 Aug 2009 14:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wz-F1tiYpGEn for ; Mon, 17 Aug 2009 14:49:38 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 5C4CB3A6D90 for ; Mon, 17 Aug 2009 14:49:38 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUGAO9siUqrR7PD/2dsb2JhbACIXbUliC0QjzAFhBk X-IronPort-AV: E=Sophos;i="4.43,398,1246838400"; d="scan'208";a="196248615" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 17 Aug 2009 21:49:43 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7HLnhFF024407; Mon, 17 Aug 2009 14:49:43 -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.13.8/8.14.3) with ESMTP id n7HLnhlX008787; Mon, 17 Aug 2009 21:49:43 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 14:49:43 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.12.190]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 14:49:42 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 17 Aug 2009 16:49:40 -0500 To: Adam Roach , SIPCORE From: "James M. Polk" In-Reply-To: <4A85CECC.3020401@nostrum.com> References: <4A85CECC.3020401@nostrum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 17 Aug 2009 21:49:42.0769 (UTC) FILETIME=[A0D13610:01CA1F84] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4102; t=1250545783; x=1251409783; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[sipcore]=203265bis=20Open=20Issue=3A=2 0Timer=20N=20and=20Resubscribes |Sender:=20; bh=A47dWAqyMqImNzUwCKhmRUAMXFEnhoN6eaUnCr2ulTc=; b=hV/5XPw334VSmkWSpnFhz0YEre5rngNM79VqtNfy43i1kdtuy83bx/pmAI 3HbPXhv3TQZCQRdp26ulAwfkuxhPZwwnt6XbK5TMt/+HsyI1HWsF7FbymUzy MRqR8kWasH; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [sipcore] 3265bis Open Issue: Timer N and Resubscribes X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 21:49:39 -0000 At 03:53 PM 8/14/2009, Adam Roach wrote: >One of the things we discussed in Stockholm was whether a Timer N >expiration on resubscribe causes the subscription to be terminated. >This was posed as a purely theoretical situation, with no concrete >circumstances in mind under which it might occur. > >(As a refresher: Timer N is the timer run between sending a >SUBSCRIBE and receiving a NOTIFY. For the initial SUBSCRIBE, the >expiration of Timer N causes the subscription set up to fail. This >was called Timer L in 3265bis-00, but is being renamed Timer N to >avoid colliding with invite-fix). > >I've given a lot of thought to what set of circumstances would lead >to conditions in which the SUBSCRIBE 200 response is arriving just >fine, but the NOTIFY is being consistently lost (at least, >consistently enough for Timer N to expire). The only plausible >scenarios I've been able to construct involve some signaling >intermediary changing an address association in the middle of a subscription. > >For example: imagine a client behind a NAT uses STUN to determine a >viable public address/port combination. It then composes an initial >SUBSCRIBE message and sends it off to the notifier. The initial >NOTIFY arrives just fine. > >Later in the subscription, the NAT resets the association between >the subscriber and the external NAT port. > >Because of the Via header field received and rport parameters, the >200 responses to SUBSCRIBE messages will continue to be routed back >to the subscriber. However, because the address/port in the Contact >no longer route back to the subscriber, the NOTIFY messages will never arrive. > >This behavior can also arrive if the local address for a machine >changes -- say, due to a DHCP address assignment changing, or a PPP >tunnel being re-established with a different IP address. I think you had me swayed until this comment (which gives your whole conclusion more context). Are you suggesting the actual time in which a SUB/200OK transaction take place, and the sending of the NOTIFY following that 200OK (most likely along the same message path, and may be consecutive datagrams from that entity) that a DHCP client (the subscribed to entity) changes its IP address, therefore the 200OK (i.e., the acceptance of the subscription) is either from a stale IP address or just plain invalid? I'm sorry, but I find this scenario to be way beyond most outlier scenarios for this document to have to worry about. I mean - we're talking about a reSUBSCRIBE here - where there is a valid subscription already; meaning if anything has changed - this should be apparent during the reSUBSCRIBE transaction, shouldn't it (otherwise, what's the point)? Therefore I counter-propose what I said at the mike in Stockholm, that if the 200OK is received, the subscription is considered good - regardless of receiving the NOTIFY. The subscribed-to entity accepted the subscription, and that should be it, especially if the 200OK is received by the UAC (subscribing entity). That said, it is obvious that the failure to receive a 200OK to a reSUBSCRIBE is cause for termination of the subscription - as is the current practice. BTW - how can't this scenario be true for new subscriptions? >In all of these cases, I think it's pretty obvious that there is no >hope of the subscription ever recovering. Leaving it lying around >until it expires has no benefits, and wastes resources at both the >subscriber and the notifier. On top of that, it give the subscriber >application the impression of being subscribed to state changes, >when none will ever actually arrive. > >For these reasons, I would strongly recommend that the expiration of >the new supervisory timer (Timer L in 3265bis-00, Timer N in the >forthcoming 3265bis-01) during a re-subscribe result in the >subscription being terminated. > >/a >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Mon Aug 17 14:50:22 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A0993A6DC8 for ; Mon, 17 Aug 2009 14:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.605 X-Spam-Level: X-Spam-Status: No, score=-5.605 tagged_above=-999 required=5 tests=[AWL=0.644, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooKUPbbnp7cG for ; Mon, 17 Aug 2009 14:50:21 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 233A53A6D5C for ; Mon, 17 Aug 2009 14:50:20 -0700 (PDT) X-AuditID: c1b4fb3e-b7b12ae00000599c-3b-4a89d099740a Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id F5.A9.22940.990D98A4; Mon, 17 Aug 2009 23:50:18 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 23:48:52 +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: Mon, 17 Aug 2009 23:48:51 +0200 Message-ID: In-Reply-To: <4A89C789.20001@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-roach-sipcore-rfc3265bis-00 Thread-Index: Acoff1ASFKkCZTFKQIin5mdsU7Z4aQAAmo/g References: <4A85C195.4060903@nostrum.com> <4A89C789.20001@nostrum.com> From: "Christer Holmberg" To: "Adam Roach" X-OriginalArrivalTime: 17 Aug 2009 21:48:52.0645 (UTC) FILETIME=[82F0E550:01CA1F84] X-Brightmail-Tracker: AAAAAA== Cc: Ian Elz , sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 21:50:22 -0000 Hi,=20 >>Because method names are one SIP's extension points, proxies don't inherently know which requests can form dialogs. For example, if a proxy forks a XYZZY request, how would it know whether to return a=20 >>single 200 response or all of them? It has know way of knowing whether XYZZY is a dialog-forming request. > >Because, what does a proxy do if it receives additional 200 responses? I can't find any text about that in 3261. > =20 > >It's going to drop them. See RFC 3261, section 16.7, step 5. Maybe I'm just too blind to find it, but could you copy the text which says that? :) In the beginning there is generic text which says that any 2xx response is forwarded. Further down there is INVITE specific text, which says that non-2xx responses are not immedialtly forwarded - instead the choose-the-best procedures are used. I see no text saying that additional 2xx responses for non-INVITEs are dropped.=20 ------ >>>>That's certainly the intention of 4.3. It's a bit tortured to imagine=20 >>>>that a proxy might be on the path of the NOTIFY without having=20 >>>>Record-Routing the SUBSCRIBE. Nonetheless, I'm okay with prohibiting >>>>Record-Routing a NOTIFY unless you've also Record-Routed the=20 >>>>associated SUBSCRIBE; I'll add: >>>> >>>> Proxies that did not add a Record-Route header field to the >>>> initial SUBSCRIBE request MUST NOT add a Record-Route header >>>> field to any of the associated NOTIFY requests. >>>> =20 >>>> >>>Don't you need a Proxy-Require option tag for that?=20 >>> >>>Again, a 3261 compliant proxy may Record-Route the SUBSCRIBE, but that=20 >>>doesn't mean it will Record-Route the NOTIFY. It may simply be=20 >>>configured to Record-Route all dialog initiation requests. >> =20 > >For a proxy to have the first clue that SUBSCRIBE is a dialog initiation request, it has to be aware of the semantics of SUBSCRIBE. Otherwise, it doesn't know SUBSCRIBE from XYZZY. > >And if a proxy is blindly Record-Routing unknown methods, it will Record-Route the NOTIFY also.=20 Doesn't the NOTIFY contain a To tag? The proxy would assume it is an in-dialog request, so it would not Record-Route it. What does a stateful proxy do with an in-dialog request it doesn't find state for, btw? ------ >I've worked with enough implementors to know that there's never enough accounting for crazy, but the failure you're describing would require a certain amount of malice: enough understanding to know what=20 >SUBSCRIBE means, but a bewildering level of willful ignorance to then pretend not to understand NOTIFY. I agree that if the proxy is SUBSCRIBE aware, there should be no problem. Regards, Christer From pkyzivat@cisco.com Mon Aug 17 15:54:55 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E2013A6DB0 for ; Mon, 17 Aug 2009 15:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aBHlqRwaSPd for ; Mon, 17 Aug 2009 15:54:54 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 755543A6DC8 for ; Mon, 17 Aug 2009 15:54:14 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGd8iUqrR7PE/2dsb2JhbAC9Yogtj00FhBk X-IronPort-AV: E=Sophos;i="4.43,398,1246838400"; d="scan'208";a="369188713" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 17 Aug 2009 22:54:15 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7HMsFfL028184; Mon, 17 Aug 2009 15:54:15 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n7HMsFbc009125; Mon, 17 Aug 2009 22:54:15 GMT 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.3959); Mon, 17 Aug 2009 18:54:14 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 18:54:14 -0400 Message-ID: <4A89DF9E.9010807@cisco.com> Date: Mon, 17 Aug 2009 18:54:22 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Ian Elz References: <4A85C195.4060903@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Aug 2009 22:54:14.0421 (UTC) FILETIME=[A4806C50:01CA1F8D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11278; t=1250549655; x=1251413655; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20draft-roach-sipcore-rfc3265 bis-00=20-=20Record-Route=20and=0A=20tranaction=20state=20mo del. |Sender:=20; bh=satmbZ2+nugKWEA2tz5NMzW7jJ3xjcg6ZXqLKNwHS/M=; b=sSgNnM06becxYFvpGVumizD2KsO+SH2z3BLxs0/uonkQp2a9w8ImOO5Jkp 36SauYMJT3jIMDm7sV4RzG3HEO0jez+iYV6Tf2Fa6efe8l2sWvUnBqvG+FEb eu01JPSwh5; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 - Record-Route and tranaction state model. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 22:54:55 -0000 Ian, 3265 wasn't very explicit about some of this, and the end result was that for several things there were two different mechanisms for obtaining information, and no clear rules about which took precedence. This typically isn't a problem *as long as both mechanisms yield the same result*. But whenever you "replicate" something there is always the possibility that the results aren't really replicas, and then questions about which is the *true* one. For instance, 1) suppose the first NOTIFY arrives before the 200 (SUBSCRIBE) does. and suppose the two contain different Contact URIs. After both have been received, which value is the remote target for the dialog? 2) Similar to (1), but for Record-Route. By eliminating one source of information for the dialog (the 200), there are a number of questions than then need not be either asked or answered. Thanks, Paul Ian Elz wrote: > Adam. > > I understand that most of what I commented on was included in RFC3265. > The problem with RFC3265 was that a lot of the detail was missing. The > concept of the new draft is to correct those omissions and to simplify > and clarify what was included in RFC3265. > > RFC3265 does not include anything about how the subscriber (I will use > subscriber and notifier as UAC/UAS reverse for the SUBSCRIBE and > NOTIFY.) obtains his route set. If the new RFC does not explicitly state > that the subscriber route set is obtained from the Record-Route header > contained in the NOTIFY then RFC3261 applies the subscriber route set is > obtained form the 2xx to the SUBSCRIBE. This will make for an > interesting dialog if the 2xx to the SUSCRIBE is never received. > > Specific responses in-line [ige]. > > Ian > > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: 14 August 2009 20:57 > To: Ian Elz > Cc: sipcore@ietf.org; Christer Holmberg > Subject: Re: draft-roach-sipcore-rfc3265bis-00 > > Ian Elz wrote: > >> Now a more complex issue: >> >> You are proposing that the first NOTIFY establishes the SUBSCRIBE >> dialog. What impact does this have on the establishment of the route >> set at the UAC as defined in RFC3261? >> > > From a practical perspective, it's the same as what we have in 3265 -- > except that it's a little easier to implement at the subscriber. > > Keep in mind that 3265 describes dialogs being established by NOTIFY > requests -- this is not new in the 3265bis draft. The only difference in > dialog establishment is that we're removing the ability for a SUBSCRIBE > 200 response to create a dialog. > > This is an extremely important point, so I'll repeat it: this change is > not *ADDING* new behavior. It is *REMOVING* unnecessary behavior that > has been shown to cause problems. > > [ige] I understand that you are not adding any functionality which is > different from RFC3265. The problem is that what was in RFC3265 changed > the actions specified in RFC3261 but did not state how they hade been > changed. This is part of what caused the problems in RFC3265. The > updated RFC MUST include this detail or we will end up with inconsistent > implementations. > >> Normal RFC3261 has the UAS route set taken from Record-Route in the >> initial request. The UAS then copies the Record-Route back into the >> 2xx response (or reliable provisional response) which is then used by >> the UAC to set its the route set. This ensures that the route sets in >> the UAC and UAS align. >> >> Section 4.3 of the draft proposes that the initial SUBSCRIBE has the >> normal Record-Route which establishes the UAS route set but that the >> NOTIFY also has Record-Route performed by proxies. This leaves the >> possibility that the route set at the UAC and UAS may not align. >> > > Actually, it doesn't. As long as proxies follow the guidance in 4.3, > then the route set in the SUBSCRIBE will be precisely identical to the > route set established by the NOTIFY. Because of the Record-Route in the > SUBSCRIBE, the NOTIFY will contain Route header fields that guarantee > that the NOTIFY traverses the proxies that Record-Route the SUBSCRIBE. > These proxies, by the normative requirement in 4.3, will then > Record-Route the NOTIFY, which guarantees that the route set in the > subscriber matches that of the notifier. > > If you think I'm confused about this in some way, please describe a > concrete set of compliant proxy behaviors that can result in an > asymmetrical route set, preferably using a sequence diagram. > > [ige] The problem we have is backward compatibility. If the subscriber > and notifier support the proposed new functionality but an intermediate > proxies does not then this may result in an asymmetric route sets. The > SUBSCRIBE will be seen by the proxy as a dialog initiating request and > will add itself to the Record-Route in the SUBSCRIBE. When the NOTIFY is > handled however there is no requirement in RFC3261 to include itself in > the Record-route as RFC3261 is explicit in the fact that any > Record-route added to the NOTIFY will NOT update the route set. Thus > asymmetric route sets will result. This will result in SUSCRIBE messages > being passed via different proxies than the NOTIFY with the result that > some proxies will see a subscription termination resulting from a > SUBSCRIBE but not from a NOTIFY or as the result of a rejection of a > NOTIFY. > > >> I also have a concern as to what will happen with the route set if the >> SUBSCRIBE Record-Route is returned in the 2xx and the NOTIFY also >> includes a Record-Route. Which one is used to establish the route set >> at the subscriber. Do we take the one which arrives first? Do we take >> the one which arrives second? There is no issue if they are the same >> but what if they differ? >> > > As I mention above: In a compliant system, they can't differ. However, > as we all know, systems don't always do the right thing. SBCs can tinker > with Route/Record-Route in ways that create asymmetric route sets, even > for normal INVITE/200/ACK transactions. > > With 3265, if there *were* a difference, your question is highly > relevant: the answer to "but what if they differ?" was a resounding "I > have no clue!" > > Which is one of the key reasons why we made this change. > > In 3265bis, the answer is straightforward: since the NOTIFY establishes > the dialog, the NOTIFY is where the route set comes from. > > Really, the 200 response is kind of a throw-away message anyway. Even > with legacy 3265 behavior, if I have a SUBSCRIBE fork, and it > establishes two dialogs, I'm going to have to take the route set for at > least one of the dialogs from the NOTIFY -- so I may as well always take > it from the NOTIFY. > > [ige] Agree that with forking only a single 200 OK will mean that NOTIFY > will be used to establish other SUBSCRIBE dialogs. This appears to be an > issue with forking and RFC3261 where only a single 2xx response is > returned. If I subscribe and multiple nodes accept the subscription e.g. > I subscribe to the dialog-event mechanism for all dialogs for a user, > why shouldn't multiple 2xx responses to the SUBSCRIBE be returned to > establish multiple dialogs and to set up the route sets for each of > those dialogs. > >> Should there be a requirement that proxies MUST include themselves in >> the NOTIFY Record-Route if they included themselves in the SUBSCRIBE >> Record-Route and to exclude themselves in the NOTUFY if they were not >> in the SUBSCRIBE Record-Route. >> > > That's certainly the intention of 4.3. It's a bit tortured to imagine > that a proxy might be on the path of the NOTIFY without having > Record-Routing the SUBSCRIBE. Nonetheless, I'm okay with prohibiting > Record-Routing a NOTIFY unless you've also Record-Routed the associated > SUBSCRIBE; I'll add: > > Proxies that did not add a Record-Route header field to the > initial SUBSCRIBE request MUST NOT add a Record-Route header > field to any of the associated NOTIFY requests. > > [ige] But there is nothing to indicate that proxies which did add > themselves to the Record-Route in the SUBSCRIBE MUST add themselves to > the Record-Route in subsequent NOTIFY requests for the same dialog (?). > This does not remove the compatibility issue where the proxy does not > support the updates included in the draft. > > >> If we are to use the Record-Route in the NOTIFY then the draft should >> explicitly state what should happen at the subscriber end. Should the >> 2xx response to the NOTIFY include a copy of the Record-Route taken >> from the NOTIFY? >> > > It doesn't matter. > > [ige] If you don't include normative text which specifies that the route > set is established from the Record-Route in the NOTIFY then RFC3261 > applies and the route set at the subscriber is obtained from the 2xx to > the SUBSCRIBE. > >> What does the notifier end do if it then receives this Record-Route? >> > > It ignores it. There is no way to change a dialog route set (other than > the remote target) mid-dialog. > > [ige] Is what you are saying is that for one dialog you may take the > route set from the 2xx to the SUBSCRIBE, depending upon whether the > NOTIFY or 2xx arrives first, and for other dialogs it is taken from the > NOTIFY. In the forked case you may then end up with one symmetric route > set and multiple asymmetric route sets; i.e. all the proxies may see > subsequent SUBSCRIBE requests for one dialog but not for the others. I > am not sure what this will do to the proxies handling of the dialogs if > anything but we need to consider it to be sure. > > >> There is one more related issue: >> >> What happens if the 2xx to the SUBSCRIBE transaction is never received >> by the subscriber. Based upon the non-INVITE client transaction in >> RFC3261 the termination of the transaction upon expiry of Timer F will >> inform the TU. In normal cases the TU would terminate the transaction >> and drop the dialog In this case if the NOTIFY has been received >> before the 2xx then this should be treated as the 2xx from the >> transaction perspective. This almost goes as far as defining a >> separate client SUBSCRIBE transaction. >> > > Again, this behavior was present in 3265, and quite deliberately so. > Keep in mind: for any network that has even a single proxy that doesn't > Record-Route, the vast majority of SUBSCRIBE dialogs will be established > by the NOTIFY, not the 200 (since the NOTIFY will follow a shorter path > than the 200). And, with forking, all but one of the 200 responses will > be discarded by the proxy anyway. You *really* don't want the system > behavior to vary based on which 200 response wins the race to the proxy. > > [ige] No we don't want the behaviour based upon whether the 2xx of the > NOTIFY wins the race. This is why the draft needs to be explicit upon > how the route set is determined at the subscriber end. > > /a > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From drage@alcatel-lucent.com Tue Aug 18 06:32:52 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2181D28C140 for ; Tue, 18 Aug 2009 06:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.46 X-Spam-Level: X-Spam-Status: No, score=-5.46 tagged_above=-999 required=5 tests=[AWL=0.789, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoiAN5M5zDk4 for ; Tue, 18 Aug 2009 06:32:50 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 6DA2528C19E for ; Tue, 18 Aug 2009 06:32:50 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n7IDOi0H007950 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 18 Aug 2009 15:24:44 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 18 Aug 2009 15:24:45 +0200 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , Adam Roach , Ian Elz Date: Tue, 18 Aug 2009 15:24:43 +0200 Thread-Topic: draft-roach-sipcore-rfc3265bis-00 Thread-Index: AcodGW4n+3S/NSiORima/2vi8mr0YAB8az0AAD2MzdA= Message-ID: References: <4A85C195.4060903@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 13:32:52 -0000 Christer wrote > Again, a 3261 compliant proxy may Record-Route the SUBSCRIBE,=20 > but that doesn't mean it will Record-Route the NOTIFY. It may=20 > simply be configured to Record-Route all dialog initiation requests. >=20 It can only do this if it understands that SUBSCRIBE is a dialog initiation= request, and it can only do this if it implements either RFC 3265 or 3265b= is.=20 As I understood it, the behaviour described by Adam is already in RFC 3265,= and therefore it is a non-conformant implementation of RFC 3265 if it does= something difference. regards Keith=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Monday, August 17, 2009 11:19 AM > To: Adam Roach; Ian Elz > Cc: sipcore@ietf.org > Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 >=20 >=20 > Hi, >=20 > It's a while since I read the subscribe stuff, but I have=20 > some questions/comments. >=20 > >>Now a more complex issue: > >> > >>You are proposing that the first NOTIFY establishes the SUBSCRIBE=20 > >>dialog. What impact does this have on the establishment of=20 > the route=20 > >>set at the UAC as defined in RFC3261? > >>=20 > >From a practical perspective, it's the same as what we have=20 > in 3265 --=20 > >except that it's a little easier to implement at the subscriber. > >=20 > >Keep in mind that 3265 describes dialogs being established by NOTIFY=20 > >requests -- this is not new in the 3265bis draft. > > > >The only difference in dialog establishment is that we're=20 > removing the=20 > >ability for a SUBSCRIBE 200 response to create a dialog. > > > >This is an extremely important point, so I'll repeat it:=20 > this change is=20 > >not *ADDING* new behavior. It is *REMOVING* unnecessary=20 > behavior that=20 > >has been shown to cause problems. >=20 > Has it been considered that a forking proxy would forward=20 > multiple SUBSCRIBE 200 responses instead? >=20 > Also, I know that 3261 says that only one final response is=20 > forwarded for non-INVITE requests. I just wonder whether it=20 > means non-dialog initiation requests. Because, what does a=20 > proxy do if it receives additional 200 responses? I can't=20 > find any text about that in 3261. >=20 > >>Normal RFC3261 has the UAS route set taken from Record-Route in the=20 > >>initial request. The UAS then copies the Record-Route back into the=20 > >>2xx response (or reliable provisional response) which is=20 > then used by=20 > >>the UAC to set its the route set. This ensures that the=20 > route sets in=20 > >>the UAC and UAS align. > >> > >>Section 4.3 of the draft proposes that the initial=20 > SUBSCRIBE has the=20 > >>normal Record-Route which establishes the UAS route set but=20 > that the=20 > >>NOTIFY also has Record-Route performed by proxies. This > leaves the=20 > >>possibility that the route set at the UAC and UAS may not align. > >>=20 > >Actually, it doesn't. As long as proxies follow the guidance in 4.3,=20 > >then the route set in the SUBSCRIBE will be precisely=20 > identical to the=20 > >route set established by the NOTIFY. > >Because of the Record-Route in the SUBSCRIBE, the NOTIFY=20 > will contain=20 > >Route header fields that guarantee that the NOTIFY traverses the=20 > >proxies that Record-Route the SUBSCRIBE. > >These proxies, by the normative requirement in 4.3, will then=20 > >Record-Route the NOTIFY, which guarantees that the route set in the=20 > >subscriber matches that of the notifier. > > > >If you think I'm confused about this in some way, please describe a=20 > >concrete set of compliant proxy behaviors that can result in an=20 > >asymmetrical route set, preferably using a sequence diagram. >=20 > I guess the UAS could simply copy the Record-Route into the=20 > NOTIFY, as it does in the 200 response. That way the proxies=20 > would not need to add it. >=20 > But, again, wouldn't the easiest way be to make sure that all=20 > 200/202 responses are forwarded to the UAC? >=20 > I guess another option would be to send a 18x, in order to=20 > provide the Record-Route. > =20 > >>I also have a concern as to what will happen with the route=20 > set if the >=20 > >>SUBSCRIBE Record-Route is returned in the 2xx and the NOTIFY also=20 > >>includes a Record-Route. Which one is used to establish the=20 > route set=20 > >>at the subscriber. Do we take the one which arrives first? > >Do we take the one which arrives second? There is no issue=20 > if they are=20 > >the same but what if they differ? > >=20 > >As I mention above: In a compliant system, they can't differ.=20 > >However, as we all know, systems don't always do the right=20 > thing. SBCs=20 > >can tinker with Route/Record-Route in ways that create=20 > asymmetric route=20 > >sets, even for normal INVITE/200/ACK transactions. >=20 > I am not really sure what is meant by "compliant system". A=20 > system may be RFC3261 compliant, which means they may add=20 > Record-Route the SUBSCRIBE request, but they will not=20 > Record-Route the NOTIFY. >=20 > >With 3265, if there *were* a difference, your question is highly > >relevant: the answer to "but what if they differ?" was a=20 > resounding "I=20 > >have no clue!" > >=20 > >Which is one of the key reasons why we made this change. > >=20 > >In 3265bis, the answer is straightforward: since the NOTIFY=20 > establishes=20 > >the dialog, the NOTIFY is where the route set comes from. > >=20 > >Really, the 200 response is kind of a throw-away message=20 > anyway. Even=20 > >with legacy 3265 behavior, if I have a SUBSCRIBE fork, and it=20 > >establishes two dialogs, I'm going to have to take the route=20 > set for at=20 > >least one of the dialogs from the NOTIFY -- so I may as well always=20 > >take it from the NOTIFY. > > > >>Should there be a requirement that proxies MUST include=20 > themselves in=20 > >>the NOTIFY Record-Route if they included themselves in > the=20 > >>SUBSCRIBE Record-Route and to exclude themselves in the=20 > NOTUFY if they=20 > >>were not in the SUBSCRIBE Record-Route. > >> > >=20 > >That's certainly the intention of 4.3. It's a bit tortured=20 > to imagine=20 > >that a proxy might be on the path of the NOTIFY without having=20 > >Record-Routing the SUBSCRIBE. Nonetheless, I'm okay with prohibiting=20 > >Record-Routing a NOTIFY unless you've also Record-Routed the=20 > associated=20 > >SUBSCRIBE; I'll add: > >=20 > > Proxies that did not add a Record-Route header field to the > > initial SUBSCRIBE request MUST NOT add a Record-Route header > > field to any of the associated NOTIFY requests. >=20 > Don't you need a Proxy-Require option tag for that?=20 >=20 > Again, a 3261 compliant proxy may Record-Route the SUBSCRIBE,=20 > but that doesn't mean it will Record-Route the NOTIFY. It may=20 > simply be configured to Record-Route all dialog initiation requests. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 > >>If we are to use the Record-Route in the NOTIFY then the=20 > draft should=20 > >>explicitly state what should happen at the subscriber end.=20 > Should the=20 > >>2xx response to the NOTIFY include a copy of the Record-Route taken=20 > >>from the NOTIFY? > >> > >=20 > >It doesn't matter. > >=20 > >>What does the notifier end do if it then receives this Record-Route? > >> > >=20 > >It ignores it. There is no way to change a dialog route set=20 > (other than > the remote target) mid-dialog. > >=20 > >=20 > >>There is one more related issue: > >> > >>What happens if the 2xx to the SUBSCRIBE transaction is=20 > never received >=20 > >>by the subscriber. Based upon the non-INVITE client transaction in > >>RFC3261 the termination of the transaction upon expiry of=20 > Timer F will >=20 > >>inform the TU. In normal cases the TU would terminate the=20 > transaction=20 > >>and drop the dialog In this case if the NOTIFY has been received=20 > >>before the 2xx then this should be treated as the 2xx from the=20 > >>transaction perspective. This almost goes as far as defining a=20 > >>separate client SUBSCRIBE transaction. > >>=20 > >Again, this behavior was present in 3265, and quite deliberately so.=20 > >Keep in mind: for any network that has even a single proxy=20 > that doesn't=20 > >Record-Route, the vast majority of SUBSCRIBE dialogs will > be=20 > >established by the NOTIFY, not the 200 (since the NOTIFY=20 > will follow a=20 > >shorter path than the 200). And, with forking, all but one=20 > of the 200=20 > >responses will be discarded by the proxy anyway. You *really* don't > want the system=20 > >behavior to vary based on which 200 response wins the race to the > proxy. >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From adam@nostrum.com Tue Aug 18 09:25:39 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 676A03A68C2 for ; Tue, 18 Aug 2009 09:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oewImPJJzZDZ for ; Tue, 18 Aug 2009 09:25:38 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id DC7063A683F for ; Tue, 18 Aug 2009 09:25:37 -0700 (PDT) Received: from 89.176.192.25.in-addr.arpa (ppp-70-249-149-101.dsl.rcsntx.swbell.net [70.249.149.101]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n7IGPRwI063487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Aug 2009 11:25:34 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A8AD5F7.9080608@nostrum.com> Date: Tue, 18 Aug 2009 11:25:27 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: "James M. Polk" References: <4A85CECC.3020401@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.149.101 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] 3265bis Open Issue: Timer N and Resubscribes X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 16:25:39 -0000 James M. Polk wrote: > At 03:53 PM 8/14/2009, Adam Roach wrote: >> One of the things we discussed in Stockholm was whether a Timer N >> expiration on resubscribe causes the subscription to be terminated. >> This was posed as a purely theoretical situation, with no concrete >> circumstances in mind under which it might occur. >> >> (As a refresher: Timer N is the timer run between sending a SUBSCRIBE >> and receiving a NOTIFY. For the initial SUBSCRIBE, the expiration of >> Timer N causes the subscription set up to fail. This was called Timer >> L in 3265bis-00, but is being renamed Timer N to avoid colliding with >> invite-fix). >> >> I've given a lot of thought to what set of circumstances would lead >> to conditions in which the SUBSCRIBE 200 response is arriving just >> fine, but the NOTIFY is being consistently lost (at least, >> consistently enough for Timer N to expire). The only plausible >> scenarios I've been able to construct involve some signaling >> intermediary changing an address association in the middle of a >> subscription. >> >> For example: imagine a client behind a NAT uses STUN to determine a >> viable public address/port combination. It then composes an initial >> SUBSCRIBE message and sends it off to the notifier. The initial >> NOTIFY arrives just fine. >> >> Later in the subscription, the NAT resets the association between the >> subscriber and the external NAT port. >> >> Because of the Via header field received and rport parameters, the >> 200 responses to SUBSCRIBE messages will continue to be routed back >> to the subscriber. However, because the address/port in the Contact >> no longer route back to the subscriber, the NOTIFY messages will >> never arrive. >> >> This behavior can also arrive if the local address for a machine >> changes -- say, due to a DHCP address assignment changing, or a PPP >> tunnel being re-established with a different IP address. > > I think you had me swayed until this comment (which gives your whole > conclusion more context). Are you suggesting the actual time in which > a SUB/200OK transaction take place, and the sending of the NOTIFY > following that 200OK (most likely along the same message path, and may > be consecutive datagrams from that entity) that a DHCP client (the > subscribed to entity) changes its IP address, therefore the 200OK > (i.e., the acceptance of the subscription) is either from a stale IP > address or just plain invalid? No. I'm talking about the client's transport address changing due to some event it may not notice -- such as a NAT binding change, a DHCP address change, or a PPP tunnel reestablishment -- after the initial subscribe, but before the resubscribe. Something like: Subscriber NAT Notifier STUN Server | | | | | | | | | | | | |Binding Request | | | |---------------------------------------------------------->| | | | | |New port binding is to 10.20.30.40:12345 | | | | | |Binding Response | | | |(10.20.30.40:12345)| | | |<----------------------------------------------------------| | | | | |SUBSCRIBE | | | |Contact: <10.20.30.40:12345> | | |-------------------------------------->| | | | | | | | | | |Via is tagged with "rport=12345" | | | | | | | | | | |200 | | | |(sent to 10.20.30.40:12345) | | |<--------------------------------------| | | | | | |NOTIFY | | | |(sent to 10.20.30.40:12345) | | |<--------------------------------------| | | | | | | | | | |200 | | | |-------------------------------------->| | | | | | | | | | |30 Minutes Pass | | | | | | | | | | | | | | | | |NAT Binding expires| | | | | | | | | | |SUBSCRIBE | | | |Contact: <10.20.30.40:12345> | | |-------------------------------------->| | | | | | |New port binding is to 10.20.30.40:9999| | | | | | | |Via is tagged with "rport=9999" | | | | | | | | | | |200 | | | |(sent to 10.20.30.40:9999) | | |<--------------------------------------| | | | | | | |NOTIFY | | | |(sent to 10.20.30.40:12345) | | X<------------------| | | | | | | | | | | |No binding, so NOTIFY is dropped | | | | | | | | | | |NOTIFY | | | |(sent to 10.20.30.40:12345) | | X<------------------| | | | | | | |NOTIFY | | | |(sent to 10.20.30.40:12345) | | X<------------------| | | | | | | |NOTIFY | | | |(sent to 10.20.30.40:12345) | | X<------------------| | | | | | | |NOTIFY | | | |(sent to 10.20.30.40:12345) | | X<------------------| | | | | | | |NOTIFY | | | |(sent to 10.20.30.40:12345) | | X<------------------| | | | | | | |NOTIFY | | | |(sent to 10.20.30.40:12345) | | X<------------------| | | | | | | |NOTIFY | | | |(sent to 10.20.30.40:12345) | | X<------------------| | | | | | | |NOTIFY | | | |(sent to 10.20.30.40:12345) | | |<------------------| | | | | | | |NOTIFY | | | |(sent to 10.20.30.40:12345) | | X<------------------| | | | | | | |NOTIFY | | | |(sent to 10.20.30.40:12345) | | X<------------------| | | | | | | | | | | | | | | | | | From christer.holmberg@ericsson.com Tue Aug 18 10:52:06 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B0CB28C351 for ; Tue, 18 Aug 2009 10:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.622 X-Spam-Level: X-Spam-Status: No, score=-5.622 tagged_above=-999 required=5 tests=[AWL=0.627, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4u69wMeHKph for ; Tue, 18 Aug 2009 10:52:05 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id C16093A6993 for ; Tue, 18 Aug 2009 10:52:03 -0700 (PDT) X-AuditID: c1b4fb3c-b7c01ae000002aae-39-4a8aea382b8a Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id DA.B5.10926.83AEA8A4; Tue, 18 Aug 2009 19:51:52 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 19:51:52 +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, 18 Aug 2009 19:51:51 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-roach-sipcore-rfc3265bis-00 Thread-Index: AcodGW4n+3S/NSiORima/2vi8mr0YAB8az0AAD2MzdAACldswA== References: <4A85C195.4060903@nostrum.com> From: "Christer Holmberg" To: "DRAGE, Keith (Keith)" , "Adam Roach" , "Ian Elz" X-OriginalArrivalTime: 18 Aug 2009 17:51:52.0139 (UTC) FILETIME=[9145A1B0:01CA202C] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 17:52:06 -0000 Hi,=20 >>Again, a 3261 compliant proxy may Record-Route the SUBSCRIBE, but that >>doesn't mean it will Record-Route the NOTIFY. It may simply be=20 >>configured to Record-Route all dialog initiation requests. >=20 > >It can only do this if it understands that SUBSCRIBE is a dialog initiation request, and it can only do this if it implements either RFC 3265 or 3265bis.=20 Yes, when thinking about it that is probably true. >As I understood it, the behaviour described by Adam is already in RFC 3265, and therefore it is a non-conformant implementation of RFC 3265 if it does something difference. I know it is already in 3265. I had some problems finding the text in 3261/16.7 which says that additional 2xx respones for non-INVITEs are dropped. But, the text says that additional 2xx responses for an INVITE are forwarded, so I guess that implicitly means that 2xx responses for other methods are dropped... Regards, Christer > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Monday, August 17, 2009 11:19 AM > To: Adam Roach; Ian Elz > Cc: sipcore@ietf.org > Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 >=20 >=20 > Hi, >=20 > It's a while since I read the subscribe stuff, but I have some=20 > questions/comments. >=20 > >>Now a more complex issue: > >> > >>You are proposing that the first NOTIFY establishes the SUBSCRIBE=20 > >>dialog. What impact does this have on the establishment of > the route > >>set at the UAC as defined in RFC3261? > >>=20 > >From a practical perspective, it's the same as what we have > in 3265 -- > >except that it's a little easier to implement at the subscriber. > >=20 > >Keep in mind that 3265 describes dialogs being established by NOTIFY=20 > >requests -- this is not new in the 3265bis draft. > > > >The only difference in dialog establishment is that we're > removing the > >ability for a SUBSCRIBE 200 response to create a dialog. > > > >This is an extremely important point, so I'll repeat it:=20 > this change is > >not *ADDING* new behavior. It is *REMOVING* unnecessary > behavior that > >has been shown to cause problems. >=20 > Has it been considered that a forking proxy would forward multiple=20 > SUBSCRIBE 200 responses instead? >=20 > Also, I know that 3261 says that only one final response is forwarded=20 > for non-INVITE requests. I just wonder whether it means non-dialog=20 > initiation requests. Because, what does a proxy do if it receives=20 > additional 200 responses? I can't find any text about that in 3261. >=20 > >>Normal RFC3261 has the UAS route set taken from Record-Route in the=20 > >>initial request. The UAS then copies the Record-Route back into the=20 > >>2xx response (or reliable provisional response) which is > then used by > >>the UAC to set its the route set. This ensures that the > route sets in > >>the UAC and UAS align. > >> > >>Section 4.3 of the draft proposes that the initial > SUBSCRIBE has the > >>normal Record-Route which establishes the UAS route set but > that the > >>NOTIFY also has Record-Route performed by proxies. This > leaves the > >>possibility that the route set at the UAC and UAS may not align. > >>=20 > >Actually, it doesn't. As long as proxies follow the guidance in 4.3,=20 > >then the route set in the SUBSCRIBE will be precisely > identical to the > >route set established by the NOTIFY. > >Because of the Record-Route in the SUBSCRIBE, the NOTIFY > will contain > >Route header fields that guarantee that the NOTIFY traverses the=20 > >proxies that Record-Route the SUBSCRIBE. > >These proxies, by the normative requirement in 4.3, will then=20 > >Record-Route the NOTIFY, which guarantees that the route set in the=20 > >subscriber matches that of the notifier. > > > >If you think I'm confused about this in some way, please describe a=20 > >concrete set of compliant proxy behaviors that can result in an=20 > >asymmetrical route set, preferably using a sequence diagram. >=20 > I guess the UAS could simply copy the Record-Route into the NOTIFY, as > it does in the 200 response. That way the proxies would not need to=20 > add it. >=20 > But, again, wouldn't the easiest way be to make sure that all > 200/202 responses are forwarded to the UAC? >=20 > I guess another option would be to send a 18x, in order to provide the > Record-Route. > =20 > >>I also have a concern as to what will happen with the route > set if the >=20 > >>SUBSCRIBE Record-Route is returned in the 2xx and the NOTIFY also=20 > >>includes a Record-Route. Which one is used to establish the > route set > >>at the subscriber. Do we take the one which arrives first? > >Do we take the one which arrives second? There is no issue > if they are > >the same but what if they differ? > >=20 > >As I mention above: In a compliant system, they can't differ.=20 > >However, as we all know, systems don't always do the right > thing. SBCs > >can tinker with Route/Record-Route in ways that create > asymmetric route > >sets, even for normal INVITE/200/ACK transactions. >=20 > I am not really sure what is meant by "compliant system". A system may > be RFC3261 compliant, which means they may add Record-Route the=20 > SUBSCRIBE request, but they will not Record-Route the NOTIFY. >=20 > >With 3265, if there *were* a difference, your question is highly > >relevant: the answer to "but what if they differ?" was a > resounding "I > >have no clue!" > >=20 > >Which is one of the key reasons why we made this change. > >=20 > >In 3265bis, the answer is straightforward: since the NOTIFY > establishes > >the dialog, the NOTIFY is where the route set comes from. > >=20 > >Really, the 200 response is kind of a throw-away message > anyway. Even > >with legacy 3265 behavior, if I have a SUBSCRIBE fork, and it=20 > >establishes two dialogs, I'm going to have to take the route > set for at > >least one of the dialogs from the NOTIFY -- so I may as well always=20 > >take it from the NOTIFY. > > > >>Should there be a requirement that proxies MUST include > themselves in > >>the NOTIFY Record-Route if they included themselves in > the > >>SUBSCRIBE Record-Route and to exclude themselves in the > NOTUFY if they > >>were not in the SUBSCRIBE Record-Route. > >> > >=20 > >That's certainly the intention of 4.3. It's a bit tortured > to imagine > >that a proxy might be on the path of the NOTIFY without having=20 > >Record-Routing the SUBSCRIBE. Nonetheless, I'm okay with prohibiting=20 > >Record-Routing a NOTIFY unless you've also Record-Routed the > associated > >SUBSCRIBE; I'll add: > >=20 > > Proxies that did not add a Record-Route header field to the > > initial SUBSCRIBE request MUST NOT add a Record-Route header > > field to any of the associated NOTIFY requests. >=20 > Don't you need a Proxy-Require option tag for that?=20 >=20 > Again, a 3261 compliant proxy may Record-Route the SUBSCRIBE, but that > doesn't mean it will Record-Route the NOTIFY. It may simply be=20 > configured to Record-Route all dialog initiation requests. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 > >>If we are to use the Record-Route in the NOTIFY then the > draft should > >>explicitly state what should happen at the subscriber end.=20 > Should the > >>2xx response to the NOTIFY include a copy of the Record-Route taken=20 > >>from the NOTIFY? > >> > >=20 > >It doesn't matter. > >=20 > >>What does the notifier end do if it then receives this Record-Route? > >> > >=20 > >It ignores it. There is no way to change a dialog route set > (other than > the remote target) mid-dialog. > >=20 > >=20 > >>There is one more related issue: > >> > >>What happens if the 2xx to the SUBSCRIBE transaction is > never received >=20 > >>by the subscriber. Based upon the non-INVITE client transaction in > >>RFC3261 the termination of the transaction upon expiry of > Timer F will >=20 > >>inform the TU. In normal cases the TU would terminate the > transaction > >>and drop the dialog In this case if the NOTIFY has been received=20 > >>before the 2xx then this should be treated as the 2xx from the=20 > >>transaction perspective. This almost goes as far as defining a=20 > >>separate client SUBSCRIBE transaction. > >>=20 > >Again, this behavior was present in 3265, and quite deliberately so.=20 > >Keep in mind: for any network that has even a single proxy > that doesn't > >Record-Route, the vast majority of SUBSCRIBE dialogs will > be > >established by the NOTIFY, not the 200 (since the NOTIFY > will follow a > >shorter path than the 200). And, with forking, all but one > of the 200 > >responses will be discarded by the proxy anyway. You *really* don't > want the system > >behavior to vary based on which 200 response wins the race to the > proxy. >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From jmpolk@cisco.com Tue Aug 18 10:59:39 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 107973A6E5F for ; Tue, 18 Aug 2009 10:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpFdzIdfGd93 for ; Tue, 18 Aug 2009 10:59:34 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 6296A3A6E85 for ; Tue, 18 Aug 2009 10:59:31 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoGAMOIikqrR7O6/2dsb2JhbACIXLgEiC2QRgWEGQ X-IronPort-AV: E=Sophos;i="4.43,403,1246838400"; d="scan'208";a="369863966" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 18 Aug 2009 17:59:35 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7IHxaeV022144; Tue, 18 Aug 2009 10:59:36 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7IHxaZg021695; Tue, 18 Aug 2009 17:59:36 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 10:59:36 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.12.118]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 10:59:35 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 18 Aug 2009 12:59:34 -0500 To: Adam Roach From: "James M. Polk" In-Reply-To: <4A8AD5F7.9080608@nostrum.com> References: <4A85CECC.3020401@nostrum.com> <4A8AD5F7.9080608@nostrum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 18 Aug 2009 17:59:36.0055 (UTC) FILETIME=[A5C99870:01CA202D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10940; t=1250618376; x=1251482376; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[sipcore]=203265bis=20Open=20Issue=3A=2 0Timer=20N=20and=20Resubscribes |Sender:=20; bh=iq5pV7RsXDgcJSCmnhDOmOQTIydG4BcXjdqwG2/G7m4=; b=2QK3Lp6qcFhh660a0IQHLmYCkjeyz/4VDqOlsEW5EwKcqQte5quAFDz+24 XkMFNMnm3R154BACyR7vAfRaKh72Appzh7+pV7zICcgfuVJfZ/RfdcvHMbFq 60DGJ5t38N; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: SIPCORE Subject: Re: [sipcore] 3265bis Open Issue: Timer N and Resubscribes X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 17:59:39 -0000 At 11:25 AM 8/18/2009, Adam Roach wrote: >James M. Polk wrote: >>At 03:53 PM 8/14/2009, Adam Roach wrote: >>>One of the things we discussed in Stockholm was whether a Timer N >>>expiration on resubscribe causes the subscription to be >>>terminated. This was posed as a purely theoretical situation, with >>>no concrete circumstances in mind under which it might occur. >>> >>>(As a refresher: Timer N is the timer run between sending a >>>SUBSCRIBE and receiving a NOTIFY. For the initial SUBSCRIBE, the >>>expiration of Timer N causes the subscription set up to fail. This >>>was called Timer L in 3265bis-00, but is being renamed Timer N to >>>avoid colliding with invite-fix). >>> >>>I've given a lot of thought to what set of circumstances would >>>lead to conditions in which the SUBSCRIBE 200 response is arriving >>>just fine, but the NOTIFY is being consistently lost (at least, >>>consistently enough for Timer N to expire). The only plausible >>>scenarios I've been able to construct involve some signaling >>>intermediary changing an address association in the middle of a subscription. >>> >>>For example: imagine a client behind a NAT uses STUN to determine >>>a viable public address/port combination. It then composes an >>>initial SUBSCRIBE message and sends it off to the notifier. The >>>initial NOTIFY arrives just fine. >>> >>>Later in the subscription, the NAT resets the association between >>>the subscriber and the external NAT port. >>> >>>Because of the Via header field received and rport parameters, the >>>200 responses to SUBSCRIBE messages will continue to be routed >>>back to the subscriber. However, because the address/port in the >>>Contact no longer route back to the subscriber, the NOTIFY >>>messages will never arrive. >>> >>>This behavior can also arrive if the local address for a machine >>>changes -- say, due to a DHCP address assignment changing, or a >>>PPP tunnel being re-established with a different IP address. >> >>I think you had me swayed until this comment (which gives your >>whole conclusion more context). Are you suggesting the actual time >>in which a SUB/200OK transaction take place, and the sending of the >>NOTIFY following that 200OK (most likely along the same message >>path, and may be consecutive datagrams from that entity) that a >>DHCP client (the subscribed to entity) changes its IP address, >>therefore the 200OK (i.e., the acceptance of the subscription) is >>either from a stale IP address or just plain invalid? > >No. I'm talking about the client's transport address changing due to >some event it may not notice -- such as a NAT binding change, a DHCP >address change, or a PPP tunnel reestablishment -- after the initial >subscribe, but before the resubscribe. nice flow chart... can't you merely mandate a new Binding Request before each SUBSCRIBE/reSUBSCRIBE? If that doesn't cut it, then when the binding times out (and without the reSUBSCRIBE), don't the original NOTIFYs also die at the NAT (thus making NATs evil -- oh yeah, they already are evil)? >Something like: > > Subscriber NAT Notifier STUN Server > | | | | > | | | | > | | | | > |Binding Request | | | > |---------------------------------------------------------->| > | | | | > |New port binding is to 10.20.30.40:12345 | > | | | | > |Binding Response | | | > |(10.20.30.40:12345)| | | > |<----------------------------------------------------------| > | | | | > |SUBSCRIBE | | | > |Contact: <10.20.30.40:12345> | | > |-------------------------------------->| | > | | | | > | | | | > |Via is tagged with "rport=12345" | | > | | | | > | | | | > |200 | | | > |(sent to 10.20.30.40:12345) | | > |<--------------------------------------| | > | | | | > |NOTIFY | | | > |(sent to 10.20.30.40:12345) | | > |<--------------------------------------| | > | | | | > | | | | > |200 | | | > |-------------------------------------->| | > | | | | > | | | | > |30 Minutes Pass | | | > | | | | > | | | | > | | | | > | |NAT Binding expires| | > | | | | > | | | | > |SUBSCRIBE | | | > |Contact: <10.20.30.40:12345> | | > |-------------------------------------->| | > | | | | > |New port binding is to 10.20.30.40:9999| >| | > | | | | > |Via is tagged with "rport=9999" | | > | | | | > | | | | > |200 | | | > |(sent to 10.20.30.40:9999) | | > |<--------------------------------------| | > | | | | > | |NOTIFY | | > | |(sent to 10.20.30.40:12345) | > | X<------------------| | > | | | | > | | | | > | |No binding, so NOTIFY is dropped | > | | | | > | | | | > | |NOTIFY | | > | |(sent to 10.20.30.40:12345) | > | X<------------------| | > | | | | > | |NOTIFY | | > | |(sent to 10.20.30.40:12345) | > | X<------------------| | > | | | | > | |NOTIFY | | > | |(sent to 10.20.30.40:12345) | > | X<------------------| | > | | | | > | |NOTIFY | | > | |(sent to 10.20.30.40:12345) | > | X<------------------| | > | | | | > | |NOTIFY | | > | |(sent to 10.20.30.40:12345) | > | X<------------------| | > | | | | > | |NOTIFY | | > | |(sent to 10.20.30.40:12345) | > | X<------------------| | > | | | | > | |NOTIFY | | > | |(sent to 10.20.30.40:12345) | > | X<------------------| | > | | | | > | |NOTIFY | | > | |(sent to 10.20.30.40:12345) | > | |<------------------| | > | | | | > | |NOTIFY | | > | |(sent to 10.20.30.40:12345) | > | X<------------------| | > | | | | > | |NOTIFY | | > | |(sent to 10.20.30.40:12345) | > | X<------------------| | > | | | | > | | | | > | | | | > | | | | > From christer.holmberg@ericsson.com Tue Aug 18 11:20:00 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B4553A6A0F for ; Tue, 18 Aug 2009 11:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.638 X-Spam-Level: X-Spam-Status: No, score=-3.638 tagged_above=-999 required=5 tests=[AWL=-1.389, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0O+jW2W1O0Ff for ; Tue, 18 Aug 2009 11:19:58 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 1A2593A684E for ; Tue, 18 Aug 2009 11:19:57 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-33-4a8af0d1feba Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 4C.4E.18827.1D0FA8A4; Tue, 18 Aug 2009 20:20:01 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 20:18:32 +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, 18 Aug 2009 20:18:31 +0200 Message-ID: In-Reply-To: <4A89DF9E.9010807@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-roach-sipcore-rfc3265bis-00 - Record-Route and tranaction state model. Thread-Index: AcofjcJ+OoxVRKDHQv+VbiyZglXX1gAn0+cA References: <4A85C195.4060903@nostrum.com> <4A89DF9E.9010807@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Ian Elz" X-OriginalArrivalTime: 18 Aug 2009 18:18:32.0878 (UTC) FILETIME=[4B6304E0:01CA2030] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 - Record-Route and tranaction state model. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 18:20:00 -0000 Hi, Do we need some guidance based on the problems in the record-route fix draft?=20 Since the 200 response is not used, there will be no possibility to do record-route re-write, and I guess there is no idea in doing double record-routing either. So, I guess it would be good to indicate that the proxy, when Record-Routing the SUBSCRIBE only needs to think about the notifier-to-subscriber route set. And, when the proxy Record-Routes the NOTIFY, it only needs to think about the subscriber-to-notifier route set. Maybe the above is obvious, but since record-routing has caused interop problems, and since the record-route fix draft doesn't talk about subscriptions, I don't think some more detailed text than just "the proxy shall Record-Route" would harm. ---- =20 Also, related to the text saying that adding a new R-R to the SUB cannot change the route set, and eventhough the text says that the SAME R-R must be added to all NOTIFY requests, it would probably be good to say that adding a new R-R to a NOT would not change the route set either. Regards, Christer =20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Tuesday, August 18, 2009 1:54 AM To: Ian Elz Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 - Record-Route and tranaction state model. Ian, 3265 wasn't very explicit about some of this, and the end result was that for several things there were two different mechanisms for obtaining information, and no clear rules about which took precedence. This typically isn't a problem *as long as both mechanisms yield the same result*. But whenever you "replicate" something there is always the possibility that the results aren't really replicas, and then questions about which is the *true* one. For instance, 1) suppose the first NOTIFY arrives before the 200 (SUBSCRIBE) does. and suppose the two contain different Contact URIs. After both have been received, which value is the remote target for the dialog? 2) Similar to (1), but for Record-Route. By eliminating one source of information for the dialog (the 200), there are a number of questions than then need not be either asked or answered. Thanks, Paul Ian Elz wrote: > Adam. >=20 > I understand that most of what I commented on was included in RFC3265. > The problem with RFC3265 was that a lot of the detail was missing. The > concept of the new draft is to correct those omissions and to simplify > and clarify what was included in RFC3265. >=20 > RFC3265 does not include anything about how the subscriber (I will use > subscriber and notifier as UAC/UAS reverse for the SUBSCRIBE and > NOTIFY.) obtains his route set. If the new RFC does not explicitly=20 > state that the subscriber route set is obtained from the Record-Route=20 > header contained in the NOTIFY then RFC3261 applies the subscriber=20 > route set is obtained form the 2xx to the SUBSCRIBE. This will make=20 > for an interesting dialog if the 2xx to the SUSCRIBE is never received. >=20 > Specific responses in-line [ige]. >=20 > Ian >=20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: 14 August 2009 20:57 > To: Ian Elz > Cc: sipcore@ietf.org; Christer Holmberg > Subject: Re: draft-roach-sipcore-rfc3265bis-00 >=20 > Ian Elz wrote: >=20 >> Now a more complex issue: >> >> You are proposing that the first NOTIFY establishes the SUBSCRIBE=20 >> dialog. What impact does this have on the establishment of the route=20 >> set at the UAC as defined in RFC3261? >> >=20 > From a practical perspective, it's the same as what we have in 3265=20 > -- except that it's a little easier to implement at the subscriber. >=20 > Keep in mind that 3265 describes dialogs being established by NOTIFY=20 > requests -- this is not new in the 3265bis draft. The only difference=20 > in dialog establishment is that we're removing the ability for a=20 > SUBSCRIBE 200 response to create a dialog. >=20 > This is an extremely important point, so I'll repeat it: this change=20 > is not *ADDING* new behavior. It is *REMOVING* unnecessary behavior=20 > that has been shown to cause problems. >=20 > [ige] I understand that you are not adding any functionality which is=20 > different from RFC3265. The problem is that what was in RFC3265=20 > changed the actions specified in RFC3261 but did not state how they=20 > hade been changed. This is part of what caused the problems in=20 > RFC3265. The updated RFC MUST include this detail or we will end up=20 > with inconsistent implementations. >=20 >> Normal RFC3261 has the UAS route set taken from Record-Route in the=20 >> initial request. The UAS then copies the Record-Route back into the=20 >> 2xx response (or reliable provisional response) which is then used by >> the UAC to set its the route set. This ensures that the route sets in >> the UAC and UAS align. >> >> Section 4.3 of the draft proposes that the initial SUBSCRIBE has the=20 >> normal Record-Route which establishes the UAS route set but that the=20 >> NOTIFY also has Record-Route performed by proxies. This leaves the=20 >> possibility that the route set at the UAC and UAS may not align. >> >=20 > Actually, it doesn't. As long as proxies follow the guidance in 4.3,=20 > then the route set in the SUBSCRIBE will be precisely identical to the > route set established by the NOTIFY. Because of the Record-Route in=20 > the SUBSCRIBE, the NOTIFY will contain Route header fields that=20 > guarantee that the NOTIFY traverses the proxies that Record-Route the SUBSCRIBE. > These proxies, by the normative requirement in 4.3, will then=20 > Record-Route the NOTIFY, which guarantees that the route set in the=20 > subscriber matches that of the notifier. >=20 > If you think I'm confused about this in some way, please describe a=20 > concrete set of compliant proxy behaviors that can result in an=20 > asymmetrical route set, preferably using a sequence diagram. >=20 > [ige] The problem we have is backward compatibility. If the subscriber > and notifier support the proposed new functionality but an=20 > intermediate proxies does not then this may result in an asymmetric=20 > route sets. The SUBSCRIBE will be seen by the proxy as a dialog=20 > initiating request and will add itself to the Record-Route in the=20 > SUBSCRIBE. When the NOTIFY is handled however there is no requirement=20 > in RFC3261 to include itself in the Record-route as RFC3261 is=20 > explicit in the fact that any Record-route added to the NOTIFY will=20 > NOT update the route set. Thus asymmetric route sets will result. This > will result in SUSCRIBE messages being passed via different proxies=20 > than the NOTIFY with the result that some proxies will see a=20 > subscription termination resulting from a SUBSCRIBE but not from a=20 > NOTIFY or as the result of a rejection of a NOTIFY. >=20 >=20 >> I also have a concern as to what will happen with the route set if=20 >> the SUBSCRIBE Record-Route is returned in the 2xx and the NOTIFY also >> includes a Record-Route. Which one is used to establish the route set >> at the subscriber. Do we take the one which arrives first? Do we take >> the one which arrives second? There is no issue if they are the same=20 >> but what if they differ? >> >=20 > As I mention above: In a compliant system, they can't differ. However, > as we all know, systems don't always do the right thing. SBCs can=20 > tinker with Route/Record-Route in ways that create asymmetric route=20 > sets, even for normal INVITE/200/ACK transactions. >=20 > With 3265, if there *were* a difference, your question is highly > relevant: the answer to "but what if they differ?" was a resounding "I > have no clue!" >=20 > Which is one of the key reasons why we made this change. >=20 > In 3265bis, the answer is straightforward: since the NOTIFY=20 > establishes the dialog, the NOTIFY is where the route set comes from. >=20 > Really, the 200 response is kind of a throw-away message anyway. Even=20 > with legacy 3265 behavior, if I have a SUBSCRIBE fork, and it=20 > establishes two dialogs, I'm going to have to take the route set for=20 > at least one of the dialogs from the NOTIFY -- so I may as well always > take it from the NOTIFY. >=20 > [ige] Agree that with forking only a single 200 OK will mean that=20 > NOTIFY will be used to establish other SUBSCRIBE dialogs. This appears > to be an issue with forking and RFC3261 where only a single 2xx=20 > response is returned. If I subscribe and multiple nodes accept the subscription e.g. > I subscribe to the dialog-event mechanism for all dialogs for a user,=20 > why shouldn't multiple 2xx responses to the SUBSCRIBE be returned to=20 > establish multiple dialogs and to set up the route sets for each of=20 > those dialogs. >=20 >> Should there be a requirement that proxies MUST include themselves in >> the NOTIFY Record-Route if they included themselves in the SUBSCRIBE=20 >> Record-Route and to exclude themselves in the NOTUFY if they were not >> in the SUBSCRIBE Record-Route. >> >=20 > That's certainly the intention of 4.3. It's a bit tortured to imagine=20 > that a proxy might be on the path of the NOTIFY without having=20 > Record-Routing the SUBSCRIBE. Nonetheless, I'm okay with prohibiting=20 > Record-Routing a NOTIFY unless you've also Record-Routed the=20 > associated SUBSCRIBE; I'll add: >=20 > Proxies that did not add a Record-Route header field to the > initial SUBSCRIBE request MUST NOT add a Record-Route header > field to any of the associated NOTIFY requests. >=20 > [ige] But there is nothing to indicate that proxies which did add=20 > themselves to the Record-Route in the SUBSCRIBE MUST add themselves to > the Record-Route in subsequent NOTIFY requests for the same dialog (?). > This does not remove the compatibility issue where the proxy does not=20 > support the updates included in the draft. >=20 >=20 >> If we are to use the Record-Route in the NOTIFY then the draft should >> explicitly state what should happen at the subscriber end. Should the >> 2xx response to the NOTIFY include a copy of the Record-Route taken=20 >> from the NOTIFY? >> >=20 > It doesn't matter. >=20 > [ige] If you don't include normative text which specifies that the=20 > route set is established from the Record-Route in the NOTIFY then=20 > RFC3261 applies and the route set at the subscriber is obtained from=20 > the 2xx to the SUBSCRIBE. >=20 >> What does the notifier end do if it then receives this Record-Route? >> >=20 > It ignores it. There is no way to change a dialog route set (other=20 > than the remote target) mid-dialog. >=20 > [ige] Is what you are saying is that for one dialog you may take the=20 > route set from the 2xx to the SUBSCRIBE, depending upon whether the=20 > NOTIFY or 2xx arrives first, and for other dialogs it is taken from=20 > the NOTIFY. In the forked case you may then end up with one symmetric=20 > route set and multiple asymmetric route sets; i.e. all the proxies may > see subsequent SUBSCRIBE requests for one dialog but not for the=20 > others. I am not sure what this will do to the proxies handling of the > dialogs if anything but we need to consider it to be sure. >=20 >=20 >> There is one more related issue: >> >> What happens if the 2xx to the SUBSCRIBE transaction is never=20 >> received by the subscriber. Based upon the non-INVITE client=20 >> transaction in >> RFC3261 the termination of the transaction upon expiry of Timer F=20 >> will inform the TU. In normal cases the TU would terminate the=20 >> transaction and drop the dialog In this case if the NOTIFY has been=20 >> received before the 2xx then this should be treated as the 2xx from=20 >> the transaction perspective. This almost goes as far as defining a=20 >> separate client SUBSCRIBE transaction. >> >=20 > Again, this behavior was present in 3265, and quite deliberately so. > Keep in mind: for any network that has even a single proxy that=20 > doesn't Record-Route, the vast majority of SUBSCRIBE dialogs will be=20 > established by the NOTIFY, not the 200 (since the NOTIFY will follow a > shorter path than the 200). And, with forking, all but one of the 200=20 > responses will be discarded by the proxy anyway. You *really* don't=20 > want the system behavior to vary based on which 200 response wins the race to the proxy. >=20 > [ige] No we don't want the behaviour based upon whether the 2xx of the > NOTIFY wins the race. This is why the draft needs to be explicit upon=20 > how the route set is determined at the subscriber end. >=20 > /a >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From adam@nostrum.com Tue Aug 18 12:24:49 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10A733A6E6C for ; Tue, 18 Aug 2009 12:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.757 X-Spam-Level: X-Spam-Status: No, score=-2.757 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZgrt0Ri+t9s for ; Tue, 18 Aug 2009 12:24:48 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id DAED63A6E53 for ; Tue, 18 Aug 2009 12:24:47 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n7IJOonK076512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Aug 2009 14:24:50 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A8B0001.8000909@nostrum.com> Date: Tue, 18 Aug 2009 14:24:49 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: "James M. Polk" References: <4A85CECC.3020401@nostrum.com> <4A8AD5F7.9080608@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] 3265bis Open Issue: Timer N and Resubscribes X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 19:24:49 -0000 James M. Polk wrote: > can't you merely mandate a new Binding Request before each > SUBSCRIBE/reSUBSCRIBE? There's a distinct rat hole in that direction that I don't think we want to go down in RFC 3265bis (do we also check for VPN liveness? Collect local IP addresses again? Verify the IPv6 tunnel? Ping the Teredo server? Contact the DHCP server again to make sure the address is still issued to us? The actions here are virtually boundless). It's much bigger than just SUBSCRIBE/NOTIFY -- it affects all dialogs. In theory, the proper solution is to use sip-outbound. In practice, architects, implementors, and deployers don't always make the optimal choice. More to the point: we haven't, in *any* SIP document, gone about normatively specifying anything about when or how a client determines which addresses belong to the local machine or then to acquire new information. > If that doesn't cut it, then when the binding times out (and without > the reSUBSCRIBE), don't the original NOTIFYs also die at the NAT (thus > making NATs evil -- oh yeah, they already are evil)? It does, and they are. We can't fix the evil here -- but I'm concerned about amplifying it, 11 messages at a time. Keep in mind that the scenario I described was an attempt to find a plausible set of circumstances in which the SUBSCRIBE 200 would reliably arrive at a subscriber, but in which the NOTIFY would consistently fail to do so. And, in this case, I would argue that the proper behavior is to drop the subscription (since it's never going to recover). Unless we can come up with some other plausible scenario that leads us to a different conclusion, I would think this is the correct answer in general. /a From ian.elz@ericsson.com Tue Aug 18 14:20:50 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9950E3A6938 for ; Tue, 18 Aug 2009 14:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.582 X-Spam-Level: X-Spam-Status: No, score=-5.582 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIta8Pb-63nS for ; Tue, 18 Aug 2009 14:20:49 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 238A73A6ADF for ; Tue, 18 Aug 2009 14:20:48 -0700 (PDT) X-AuditID: c1b4fb3c-b7c01ae000002aae-e5-4a8b1b34ea10 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id AB.B8.10926.43B1B8A4; Tue, 18 Aug 2009 23:20:52 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 23:20:20 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Aug 2009 23:20:19 +0200 Message-ID: In-Reply-To: <4A89B264.5060003@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-roach-sipcore-rfc3265bis-00 - Record-Route and tranaction state model. Thread-Index: AcofcrYq3bRncNJaScmaoCVAlAtU5wA030yw References: <4A85C195.4060903@nostrum.com> <4A89B264.5060003@nostrum.com> From: "Ian Elz" To: "Adam Roach" X-OriginalArrivalTime: 18 Aug 2009 21:20:20.0064 (UTC) FILETIME=[B0938600:01CA2049] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 - Record-Route and tranaction state model. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 21:20:50 -0000 Adam, I think that I understand what you are trying to simplify and why. I just think that we need to ensure that the new draft does not leave open the interpretations which are possible from RFC3265. "So what you'd really like to see is explicit language describing when and how the subscriber and notifier form their route sets. That seems useful to add. I'll try to get some language explicitly describing this in the next draft." [ige] Yes - I think that it is necessary to describe the differences from RFC 3261. "You've missed some important text in section 3.1.5 of 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." [ige] OK - any proxy which fails to do this does so at its own peril. The requirement to record-route subsequent SUBSCRIBE and NOTIFY is I assume for simplicity in implementation, so the proxy does not have to wok out which are for new dialogs and which for existing. Ian -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: 17 August 2009 20:41 To: Ian Elz Cc: sipcore@ietf.org; Christer Holmberg Subject: Re: draft-roach-sipcore-rfc3265bis-00 - Record-Route and tranaction state model. [I've elided some of the original message because it was based on a misunderstanding. Instead of citing RFC 3265 section 3.1.5 several times, I've cited it once and removed the other paragraphs that related to this misunderstanding] Ian Elz wrote: > RFC3265 does not include anything about how the subscriber (I will use > subscriber and notifier as UAC/UAS reverse for the SUBSCRIBE and > NOTIFY.) obtains his route set. If the new RFC does not explicitly=20 > state that the subscriber route set is obtained from the Record-Route=20 > header contained in the NOTIFY then RFC3261 applies the subscriber=20 > route set is obtained form the 2xx to the SUBSCRIBE. This will make=20 > for an interesting dialog if the 2xx to the SUSCRIBE is never received. > =20 So what you'd really like to see is explicit language describing when and how the subscriber and notifier form their route sets. That seems useful to add. I'll try to get some language explicitly describing this in the next draft. > [ige] The problem we have is backward compatibility. If the subscriber > and notifier support the proposed new functionality but an=20 > intermediate proxies does not then this may result in an asymmetric=20 > route sets. The SUBSCRIBE will be seen by the proxy as a dialog=20 > initiating request and will add itself to the Record-Route in the=20 > SUBSCRIBE. When the NOTIFY is handled however there is no requirement=20 > in RFC3261 to include itself in the Record-route as RFC3261 is=20 > explicit in the fact that any Record-route added to the NOTIFY will=20 > NOT update the route set. Thus asymmetric route sets will result. You've missed some important text in section 3.1.5 of 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. > [ige] Agree that with forking only a single 200 OK will mean that=20 > NOTIFY will be used to establish other SUBSCRIBE dialogs. This appears > to be an issue with forking and RFC3261 where only a single 2xx=20 > response is returned. If I subscribe and multiple nodes accept the subscription e.g. > I subscribe to the dialog-event mechanism for all dialogs for a user,=20 > why shouldn't multiple 2xx responses to the SUBSCRIBE be returned to=20 > establish multiple dialogs and to set up the route sets for each of=20 > those dialogs. > =20 Because 3261 forbids it. We really can't require proxies to treat extension methods as special cases: proxies treating SUBSCRIBE as an arbitrary non-INVITE message must do the right thing. > [ige] Is what you are saying is that for one dialog you may take the=20 > route set from the 2xx to the SUBSCRIBE, depending upon whether the=20 > NOTIFY or 2xx arrives first, and for other dialogs it is taken from=20 > the NOTIFY. No. That's what 3265 said, and it proved too confusing. We're simplifying that. In 3265bis, the client never uses a SUBSCRIBE 200 to establish a dialog. Now it always uses the NOTIFY. /a From ian.elz@ericsson.com Tue Aug 18 14:20:52 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3042128C235 for ; Tue, 18 Aug 2009 14:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.677 X-Spam-Level: X-Spam-Status: No, score=-5.677 tagged_above=-999 required=5 tests=[AWL=0.572, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9YD+vf2DNg6 for ; Tue, 18 Aug 2009 14:20:50 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 07A853A6B23 for ; Tue, 18 Aug 2009 14:20:49 -0700 (PDT) X-AuditID: c1b4fb3c-b7c01ae000002aae-e6-4a8b1b34f32d Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id DB.B8.10926.43B1B8A4; Tue, 18 Aug 2009 23:20:52 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 23:20:20 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Aug 2009 23:20:19 +0200 Message-ID: In-Reply-To: <4A89DF9E.9010807@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-roach-sipcore-rfc3265bis-00 - Record-Route and tranaction state model. Thread-Index: Acofjal85aYkCt/8R4m2vcc6ljTzNwAuiYiA References: <4A85C195.4060903@nostrum.com> <4A89DF9E.9010807@cisco.com> From: "Ian Elz" To: "Paul Kyzivat" X-OriginalArrivalTime: 18 Aug 2009 21:20:20.0282 (UTC) FILETIME=[B0B4C9A0:01CA2049] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 - Record-Route and tranaction state model. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 21:20:52 -0000 Paul, Agreed. Where the establishment of a SUBSCRIBE dialog is different from other dialog types I think that the draft should be explicit. E.g. It should indicate that all the UAS actions for the 200 Ok should be taken but the UAC will ignore this for establishing the dialog. That the NOTIFY headers will be used for establishing the dialog, record-route, contact etc. Ian =20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: 17 August 2009 23:54 To: Ian Elz Cc: Adam Roach; sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 - Record-Route and tranaction state model. Ian, 3265 wasn't very explicit about some of this, and the end result was that for several things there were two different mechanisms for obtaining information, and no clear rules about which took precedence. This typically isn't a problem *as long as both mechanisms yield the same result*. But whenever you "replicate" something there is always the possibility that the results aren't really replicas, and then questions about which is the *true* one. For instance, 1) suppose the first NOTIFY arrives before the 200 (SUBSCRIBE) does. and suppose the two contain different Contact URIs. After both have been received, which value is the remote target for the dialog? 2) Similar to (1), but for Record-Route. By eliminating one source of information for the dialog (the 200), there are a number of questions than then need not be either asked or answered. Thanks, Paul Ian Elz wrote: > Adam. >=20 > I understand that most of what I commented on was included in RFC3265. > The problem with RFC3265 was that a lot of the detail was missing. The > concept of the new draft is to correct those omissions and to simplify > and clarify what was included in RFC3265. >=20 > RFC3265 does not include anything about how the subscriber (I will use > subscriber and notifier as UAC/UAS reverse for the SUBSCRIBE and > NOTIFY.) obtains his route set. If the new RFC does not explicitly=20 > state that the subscriber route set is obtained from the Record-Route=20 > header contained in the NOTIFY then RFC3261 applies the subscriber=20 > route set is obtained form the 2xx to the SUBSCRIBE. This will make=20 > for an interesting dialog if the 2xx to the SUSCRIBE is never received. >=20 > Specific responses in-line [ige]. >=20 > Ian >=20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: 14 August 2009 20:57 > To: Ian Elz > Cc: sipcore@ietf.org; Christer Holmberg > Subject: Re: draft-roach-sipcore-rfc3265bis-00 >=20 > Ian Elz wrote: >=20 >> Now a more complex issue: >> >> You are proposing that the first NOTIFY establishes the SUBSCRIBE=20 >> dialog. What impact does this have on the establishment of the route=20 >> set at the UAC as defined in RFC3261? >> >=20 > From a practical perspective, it's the same as what we have in 3265=20 > -- except that it's a little easier to implement at the subscriber. >=20 > Keep in mind that 3265 describes dialogs being established by NOTIFY=20 > requests -- this is not new in the 3265bis draft. The only difference=20 > in dialog establishment is that we're removing the ability for a=20 > SUBSCRIBE 200 response to create a dialog. >=20 > This is an extremely important point, so I'll repeat it: this change=20 > is not *ADDING* new behavior. It is *REMOVING* unnecessary behavior=20 > that has been shown to cause problems. >=20 > [ige] I understand that you are not adding any functionality which is=20 > different from RFC3265. The problem is that what was in RFC3265=20 > changed the actions specified in RFC3261 but did not state how they=20 > hade been changed. This is part of what caused the problems in=20 > RFC3265. The updated RFC MUST include this detail or we will end up=20 > with inconsistent implementations. >=20 >> Normal RFC3261 has the UAS route set taken from Record-Route in the=20 >> initial request. The UAS then copies the Record-Route back into the=20 >> 2xx response (or reliable provisional response) which is then used by >> the UAC to set its the route set. This ensures that the route sets in >> the UAC and UAS align. >> >> Section 4.3 of the draft proposes that the initial SUBSCRIBE has the=20 >> normal Record-Route which establishes the UAS route set but that the=20 >> NOTIFY also has Record-Route performed by proxies. This leaves the=20 >> possibility that the route set at the UAC and UAS may not align. >> >=20 > Actually, it doesn't. As long as proxies follow the guidance in 4.3,=20 > then the route set in the SUBSCRIBE will be precisely identical to the > route set established by the NOTIFY. Because of the Record-Route in=20 > the SUBSCRIBE, the NOTIFY will contain Route header fields that=20 > guarantee that the NOTIFY traverses the proxies that Record-Route the SUBSCRIBE. > These proxies, by the normative requirement in 4.3, will then=20 > Record-Route the NOTIFY, which guarantees that the route set in the=20 > subscriber matches that of the notifier. >=20 > If you think I'm confused about this in some way, please describe a=20 > concrete set of compliant proxy behaviors that can result in an=20 > asymmetrical route set, preferably using a sequence diagram. >=20 > [ige] The problem we have is backward compatibility. If the subscriber > and notifier support the proposed new functionality but an=20 > intermediate proxies does not then this may result in an asymmetric=20 > route sets. The SUBSCRIBE will be seen by the proxy as a dialog=20 > initiating request and will add itself to the Record-Route in the=20 > SUBSCRIBE. When the NOTIFY is handled however there is no requirement=20 > in RFC3261 to include itself in the Record-route as RFC3261 is=20 > explicit in the fact that any Record-route added to the NOTIFY will=20 > NOT update the route set. Thus asymmetric route sets will result. This > will result in SUSCRIBE messages being passed via different proxies=20 > than the NOTIFY with the result that some proxies will see a=20 > subscription termination resulting from a SUBSCRIBE but not from a=20 > NOTIFY or as the result of a rejection of a NOTIFY. >=20 >=20 >> I also have a concern as to what will happen with the route set if=20 >> the SUBSCRIBE Record-Route is returned in the 2xx and the NOTIFY also >> includes a Record-Route. Which one is used to establish the route set >> at the subscriber. Do we take the one which arrives first? Do we take >> the one which arrives second? There is no issue if they are the same=20 >> but what if they differ? >> >=20 > As I mention above: In a compliant system, they can't differ. However, > as we all know, systems don't always do the right thing. SBCs can=20 > tinker with Route/Record-Route in ways that create asymmetric route=20 > sets, even for normal INVITE/200/ACK transactions. >=20 > With 3265, if there *were* a difference, your question is highly > relevant: the answer to "but what if they differ?" was a resounding "I > have no clue!" >=20 > Which is one of the key reasons why we made this change. >=20 > In 3265bis, the answer is straightforward: since the NOTIFY=20 > establishes the dialog, the NOTIFY is where the route set comes from. >=20 > Really, the 200 response is kind of a throw-away message anyway. Even=20 > with legacy 3265 behavior, if I have a SUBSCRIBE fork, and it=20 > establishes two dialogs, I'm going to have to take the route set for=20 > at least one of the dialogs from the NOTIFY -- so I may as well always > take it from the NOTIFY. >=20 > [ige] Agree that with forking only a single 200 OK will mean that=20 > NOTIFY will be used to establish other SUBSCRIBE dialogs. This appears > to be an issue with forking and RFC3261 where only a single 2xx=20 > response is returned. If I subscribe and multiple nodes accept the subscription e.g. > I subscribe to the dialog-event mechanism for all dialogs for a user,=20 > why shouldn't multiple 2xx responses to the SUBSCRIBE be returned to=20 > establish multiple dialogs and to set up the route sets for each of=20 > those dialogs. >=20 >> Should there be a requirement that proxies MUST include themselves in >> the NOTIFY Record-Route if they included themselves in the SUBSCRIBE=20 >> Record-Route and to exclude themselves in the NOTUFY if they were not >> in the SUBSCRIBE Record-Route. >> >=20 > That's certainly the intention of 4.3. It's a bit tortured to imagine=20 > that a proxy might be on the path of the NOTIFY without having=20 > Record-Routing the SUBSCRIBE. Nonetheless, I'm okay with prohibiting=20 > Record-Routing a NOTIFY unless you've also Record-Routed the=20 > associated SUBSCRIBE; I'll add: >=20 > Proxies that did not add a Record-Route header field to the > initial SUBSCRIBE request MUST NOT add a Record-Route header > field to any of the associated NOTIFY requests. >=20 > [ige] But there is nothing to indicate that proxies which did add=20 > themselves to the Record-Route in the SUBSCRIBE MUST add themselves to > the Record-Route in subsequent NOTIFY requests for the same dialog (?). > This does not remove the compatibility issue where the proxy does not=20 > support the updates included in the draft. >=20 >=20 >> If we are to use the Record-Route in the NOTIFY then the draft should >> explicitly state what should happen at the subscriber end. Should the >> 2xx response to the NOTIFY include a copy of the Record-Route taken=20 >> from the NOTIFY? >> >=20 > It doesn't matter. >=20 > [ige] If you don't include normative text which specifies that the=20 > route set is established from the Record-Route in the NOTIFY then=20 > RFC3261 applies and the route set at the subscriber is obtained from=20 > the 2xx to the SUBSCRIBE. >=20 >> What does the notifier end do if it then receives this Record-Route? >> >=20 > It ignores it. There is no way to change a dialog route set (other=20 > than the remote target) mid-dialog. >=20 > [ige] Is what you are saying is that for one dialog you may take the=20 > route set from the 2xx to the SUBSCRIBE, depending upon whether the=20 > NOTIFY or 2xx arrives first, and for other dialogs it is taken from=20 > the NOTIFY. In the forked case you may then end up with one symmetric=20 > route set and multiple asymmetric route sets; i.e. all the proxies may > see subsequent SUBSCRIBE requests for one dialog but not for the=20 > others. I am not sure what this will do to the proxies handling of the > dialogs if anything but we need to consider it to be sure. >=20 >=20 >> There is one more related issue: >> >> What happens if the 2xx to the SUBSCRIBE transaction is never=20 >> received by the subscriber. Based upon the non-INVITE client=20 >> transaction in >> RFC3261 the termination of the transaction upon expiry of Timer F=20 >> will inform the TU. In normal cases the TU would terminate the=20 >> transaction and drop the dialog In this case if the NOTIFY has been=20 >> received before the 2xx then this should be treated as the 2xx from=20 >> the transaction perspective. This almost goes as far as defining a=20 >> separate client SUBSCRIBE transaction. >> >=20 > Again, this behavior was present in 3265, and quite deliberately so. > Keep in mind: for any network that has even a single proxy that=20 > doesn't Record-Route, the vast majority of SUBSCRIBE dialogs will be=20 > established by the NOTIFY, not the 200 (since the NOTIFY will follow a > shorter path than the 200). And, with forking, all but one of the 200=20 > responses will be discarded by the proxy anyway. You *really* don't=20 > want the system behavior to vary based on which 200 response wins the race to the proxy. >=20 > [ige] No we don't want the behaviour based upon whether the 2xx of the > NOTIFY wins the race. This is why the draft needs to be explicit upon=20 > how the route set is determined at the subscriber end. >=20 > /a >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From pkyzivat@cisco.com Tue Aug 18 14:28:44 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F6A628C31D for ; Tue, 18 Aug 2009 14:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5ypLTWa1Rot for ; Tue, 18 Aug 2009 14:28:42 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id A763E3A6E17 for ; Tue, 18 Aug 2009 14:28:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPu5ikqrR7PE/2dsb2JhbAC/U4gtkGAFhBk X-IronPort-AV: E=Sophos;i="4.43,404,1246838400"; d="scan'208";a="90600704" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 18 Aug 2009 21:28:36 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7ILSaLS004693; Tue, 18 Aug 2009 14:28:36 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7ILS12S001660; Tue, 18 Aug 2009 21:28:36 GMT 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.3959); Tue, 18 Aug 2009 17:28:32 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 17:28:32 -0400 Message-ID: <4A8B1D01.7090403@cisco.com> Date: Tue, 18 Aug 2009 17:28:33 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Ian Elz References: <4A85C195.4060903@nostrum.com> <4A89DF9E.9010807@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Aug 2009 21:28:32.0761 (UTC) FILETIME=[D63F1E90:01CA204A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12657; t=1250630916; x=1251494916; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20draft-roach-sipcore-rfc3265 bis-00=20-=20Record-Route=20and=0A=20tranaction=20state=20mo del. |Sender:=20; bh=qjLF0hQ6SKR4PJ/5lkwRJcK/BFc0u7rKNG2h5rOSr+c=; b=gdtn0gfycTvsgzvC9j6ocBBxb/N6yCox5P9efEEVPQIR6DhepeuhUdwLY/ G0NiaQNfE5xroPyaIuiOHR+zHKY1gN+kdbPpzv8we92ZupVL+A2aQVmvqza3 4TFkZJhn+j; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 - Record-Route and tranaction state model. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 21:28:44 -0000 Ian Elz wrote: > Paul, > > Agreed. > > Where the establishment of a SUBSCRIBE dialog is different from other > dialog types I think that the draft should be explicit. E.g. It should > indicate that all the UAS actions for the 200 Ok should be taken but the > UAC will ignore this for establishing the dialog. That the NOTIFY > headers will be used for establishing the dialog, record-route, contact > etc. That is the one thing I don't like about this approach - that it makes entirely new rules for dialog establishment for SUBSCRIBE. But interestingly, this makes it more consistent with REFER. And it was already a special case because of the NOTIFY forking. Thanks, Paul > Ian > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 17 August 2009 23:54 > To: Ian Elz > Cc: Adam Roach; sipcore@ietf.org > Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 - Record-Route > and tranaction state model. > > Ian, > > 3265 wasn't very explicit about some of this, and the end result was > that for several things there were two different mechanisms for > obtaining information, and no clear rules about which took precedence. > This typically isn't a problem *as long as both mechanisms yield the > same result*. But whenever you "replicate" something there is always the > possibility that the results aren't really replicas, and then questions > about which is the *true* one. > > For instance, > > 1) suppose the first NOTIFY arrives before the 200 (SUBSCRIBE) does. > and suppose the two contain different Contact URIs. After both > have been received, which value is the remote target for the dialog? > > 2) Similar to (1), but for Record-Route. > > By eliminating one source of information for the dialog (the 200), there > are a number of questions than then need not be either asked or > answered. > > Thanks, > Paul > > Ian Elz wrote: >> Adam. >> >> I understand that most of what I commented on was included in RFC3265. >> The problem with RFC3265 was that a lot of the detail was missing. The > >> concept of the new draft is to correct those omissions and to simplify > >> and clarify what was included in RFC3265. >> >> RFC3265 does not include anything about how the subscriber (I will use > >> subscriber and notifier as UAC/UAS reverse for the SUBSCRIBE and >> NOTIFY.) obtains his route set. If the new RFC does not explicitly >> state that the subscriber route set is obtained from the Record-Route >> header contained in the NOTIFY then RFC3261 applies the subscriber >> route set is obtained form the 2xx to the SUBSCRIBE. This will make >> for an interesting dialog if the 2xx to the SUSCRIBE is never > received. >> Specific responses in-line [ige]. >> >> Ian >> >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: 14 August 2009 20:57 >> To: Ian Elz >> Cc: sipcore@ietf.org; Christer Holmberg >> Subject: Re: draft-roach-sipcore-rfc3265bis-00 >> >> Ian Elz wrote: >> >>> Now a more complex issue: >>> >>> You are proposing that the first NOTIFY establishes the SUBSCRIBE >>> dialog. What impact does this have on the establishment of the route >>> set at the UAC as defined in RFC3261? >>> >> From a practical perspective, it's the same as what we have in 3265 >> -- except that it's a little easier to implement at the subscriber. >> >> Keep in mind that 3265 describes dialogs being established by NOTIFY >> requests -- this is not new in the 3265bis draft. The only difference >> in dialog establishment is that we're removing the ability for a >> SUBSCRIBE 200 response to create a dialog. >> >> This is an extremely important point, so I'll repeat it: this change >> is not *ADDING* new behavior. It is *REMOVING* unnecessary behavior >> that has been shown to cause problems. >> >> [ige] I understand that you are not adding any functionality which is >> different from RFC3265. The problem is that what was in RFC3265 >> changed the actions specified in RFC3261 but did not state how they >> hade been changed. This is part of what caused the problems in >> RFC3265. The updated RFC MUST include this detail or we will end up >> with inconsistent implementations. >> >>> Normal RFC3261 has the UAS route set taken from Record-Route in the >>> initial request. The UAS then copies the Record-Route back into the >>> 2xx response (or reliable provisional response) which is then used by > >>> the UAC to set its the route set. This ensures that the route sets in > >>> the UAC and UAS align. >>> >>> Section 4.3 of the draft proposes that the initial SUBSCRIBE has the >>> normal Record-Route which establishes the UAS route set but that the >>> NOTIFY also has Record-Route performed by proxies. This leaves the >>> possibility that the route set at the UAC and UAS may not align. >>> >> Actually, it doesn't. As long as proxies follow the guidance in 4.3, >> then the route set in the SUBSCRIBE will be precisely identical to the > >> route set established by the NOTIFY. Because of the Record-Route in >> the SUBSCRIBE, the NOTIFY will contain Route header fields that >> guarantee that the NOTIFY traverses the proxies that Record-Route the > SUBSCRIBE. >> These proxies, by the normative requirement in 4.3, will then >> Record-Route the NOTIFY, which guarantees that the route set in the >> subscriber matches that of the notifier. >> >> If you think I'm confused about this in some way, please describe a >> concrete set of compliant proxy behaviors that can result in an >> asymmetrical route set, preferably using a sequence diagram. >> >> [ige] The problem we have is backward compatibility. If the subscriber > >> and notifier support the proposed new functionality but an >> intermediate proxies does not then this may result in an asymmetric >> route sets. The SUBSCRIBE will be seen by the proxy as a dialog >> initiating request and will add itself to the Record-Route in the >> SUBSCRIBE. When the NOTIFY is handled however there is no requirement >> in RFC3261 to include itself in the Record-route as RFC3261 is >> explicit in the fact that any Record-route added to the NOTIFY will >> NOT update the route set. Thus asymmetric route sets will result. This > >> will result in SUSCRIBE messages being passed via different proxies >> than the NOTIFY with the result that some proxies will see a >> subscription termination resulting from a SUBSCRIBE but not from a >> NOTIFY or as the result of a rejection of a NOTIFY. >> >> >>> I also have a concern as to what will happen with the route set if >>> the SUBSCRIBE Record-Route is returned in the 2xx and the NOTIFY also > >>> includes a Record-Route. Which one is used to establish the route set > >>> at the subscriber. Do we take the one which arrives first? Do we take > >>> the one which arrives second? There is no issue if they are the same >>> but what if they differ? >>> >> As I mention above: In a compliant system, they can't differ. However, > >> as we all know, systems don't always do the right thing. SBCs can >> tinker with Route/Record-Route in ways that create asymmetric route >> sets, even for normal INVITE/200/ACK transactions. >> >> With 3265, if there *were* a difference, your question is highly >> relevant: the answer to "but what if they differ?" was a resounding "I > >> have no clue!" >> >> Which is one of the key reasons why we made this change. >> >> In 3265bis, the answer is straightforward: since the NOTIFY >> establishes the dialog, the NOTIFY is where the route set comes from. >> >> Really, the 200 response is kind of a throw-away message anyway. Even >> with legacy 3265 behavior, if I have a SUBSCRIBE fork, and it >> establishes two dialogs, I'm going to have to take the route set for >> at least one of the dialogs from the NOTIFY -- so I may as well always > >> take it from the NOTIFY. >> >> [ige] Agree that with forking only a single 200 OK will mean that >> NOTIFY will be used to establish other SUBSCRIBE dialogs. This appears > >> to be an issue with forking and RFC3261 where only a single 2xx >> response is returned. If I subscribe and multiple nodes accept the > subscription e.g. >> I subscribe to the dialog-event mechanism for all dialogs for a user, >> why shouldn't multiple 2xx responses to the SUBSCRIBE be returned to >> establish multiple dialogs and to set up the route sets for each of >> those dialogs. >> >>> Should there be a requirement that proxies MUST include themselves in > >>> the NOTIFY Record-Route if they included themselves in the SUBSCRIBE >>> Record-Route and to exclude themselves in the NOTUFY if they were not > >>> in the SUBSCRIBE Record-Route. >>> >> That's certainly the intention of 4.3. It's a bit tortured to imagine >> that a proxy might be on the path of the NOTIFY without having >> Record-Routing the SUBSCRIBE. Nonetheless, I'm okay with prohibiting >> Record-Routing a NOTIFY unless you've also Record-Routed the >> associated SUBSCRIBE; I'll add: >> >> Proxies that did not add a Record-Route header field to the >> initial SUBSCRIBE request MUST NOT add a Record-Route header >> field to any of the associated NOTIFY requests. >> >> [ige] But there is nothing to indicate that proxies which did add >> themselves to the Record-Route in the SUBSCRIBE MUST add themselves to > >> the Record-Route in subsequent NOTIFY requests for the same dialog > (?). >> This does not remove the compatibility issue where the proxy does not >> support the updates included in the draft. >> >> >>> If we are to use the Record-Route in the NOTIFY then the draft should > >>> explicitly state what should happen at the subscriber end. Should the > >>> 2xx response to the NOTIFY include a copy of the Record-Route taken >>> from the NOTIFY? >>> >> It doesn't matter. >> >> [ige] If you don't include normative text which specifies that the >> route set is established from the Record-Route in the NOTIFY then >> RFC3261 applies and the route set at the subscriber is obtained from >> the 2xx to the SUBSCRIBE. >> >>> What does the notifier end do if it then receives this Record-Route? >>> >> It ignores it. There is no way to change a dialog route set (other >> than the remote target) mid-dialog. >> >> [ige] Is what you are saying is that for one dialog you may take the >> route set from the 2xx to the SUBSCRIBE, depending upon whether the >> NOTIFY or 2xx arrives first, and for other dialogs it is taken from >> the NOTIFY. In the forked case you may then end up with one symmetric >> route set and multiple asymmetric route sets; i.e. all the proxies may > >> see subsequent SUBSCRIBE requests for one dialog but not for the >> others. I am not sure what this will do to the proxies handling of the > >> dialogs if anything but we need to consider it to be sure. >> >> >>> There is one more related issue: >>> >>> What happens if the 2xx to the SUBSCRIBE transaction is never >>> received by the subscriber. Based upon the non-INVITE client >>> transaction in >>> RFC3261 the termination of the transaction upon expiry of Timer F >>> will inform the TU. In normal cases the TU would terminate the >>> transaction and drop the dialog In this case if the NOTIFY has been >>> received before the 2xx then this should be treated as the 2xx from >>> the transaction perspective. This almost goes as far as defining a >>> separate client SUBSCRIBE transaction. >>> >> Again, this behavior was present in 3265, and quite deliberately so. >> Keep in mind: for any network that has even a single proxy that >> doesn't Record-Route, the vast majority of SUBSCRIBE dialogs will be >> established by the NOTIFY, not the 200 (since the NOTIFY will follow a > >> shorter path than the 200). And, with forking, all but one of the 200 >> responses will be discarded by the proxy anyway. You *really* don't >> want the system behavior to vary based on which 200 response wins the > race to the proxy. >> [ige] No we don't want the behaviour based upon whether the 2xx of the > >> NOTIFY wins the race. This is why the draft needs to be explicit upon >> how the route set is determined at the subscriber end. >> >> /a >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > From ian.elz@ericsson.com Tue Aug 18 14:36:24 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F83928C395 for ; Tue, 18 Aug 2009 14:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHiNQYrUFOok for ; Tue, 18 Aug 2009 14:36:22 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id E4DE228C3AE for ; Tue, 18 Aug 2009 14:36:21 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-85-4a8b1e7261e6 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 51.01.18827.27E1B8A4; Tue, 18 Aug 2009 23:34:43 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 23:34: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 Date: Tue, 18 Aug 2009 23:34:16 +0200 Message-ID: In-Reply-To: <4A8B1D01.7090403@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-roach-sipcore-rfc3265bis-00 - Record-Route and tranaction state model. Thread-Index: AcogStrdr6QWBMB9SSegG2dBqwOTGQAACFXg References: <4A85C195.4060903@nostrum.com> <4A89DF9E.9010807@cisco.com> <4A8B1D01.7090403@cisco.com> From: "Ian Elz" To: "Paul Kyzivat" X-OriginalArrivalTime: 18 Aug 2009 21:34:17.0694 (UTC) FILETIME=[A3D7B7E0:01CA204B] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 - Record-Route and tranaction state model. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 21:36:24 -0000 Paul, REFER is an odd case. It is always described as creating an implicit subscription. I think this means that it is not a SUBSCRIBE. My view is that REFER creates an explicit subscription to a specific event package, "dialog progress". If REFER is not creating a subscription the 'norefersub' should be included. 3625bis does create an interesting case for REFER, REFER dialogs are created when the 202 Accepted is received. Is this going to be the case or should the NOTIFY be used? Do we also need to rewrite RFC3515? Ian=20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: 18 August 2009 22:29 To: Ian Elz Cc: Adam Roach; sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 - Record-Route and tranaction state model. Ian Elz wrote: > Paul, >=20 > Agreed. >=20 > Where the establishment of a SUBSCRIBE dialog is different from other=20 > dialog types I think that the draft should be explicit. E.g. It should > indicate that all the UAS actions for the 200 Ok should be taken but=20 > the UAC will ignore this for establishing the dialog. That the NOTIFY=20 > headers will be used for establishing the dialog, record-route,=20 > contact etc. That is the one thing I don't like about this approach - that it makes entirely new rules for dialog establishment for SUBSCRIBE. But interestingly, this makes it more consistent with REFER. And it was already a special case because of the NOTIFY forking. Thanks, Paul > Ian >=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 17 August 2009 23:54 > To: Ian Elz > Cc: Adam Roach; sipcore@ietf.org > Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 -=20 > Record-Route and tranaction state model. >=20 > Ian, >=20 > 3265 wasn't very explicit about some of this, and the end result was=20 > that for several things there were two different mechanisms for=20 > obtaining information, and no clear rules about which took precedence. > This typically isn't a problem *as long as both mechanisms yield the=20 > same result*. But whenever you "replicate" something there is always=20 > the possibility that the results aren't really replicas, and then=20 > questions about which is the *true* one. >=20 > For instance, >=20 > 1) suppose the first NOTIFY arrives before the 200 (SUBSCRIBE) does. > and suppose the two contain different Contact URIs. After both > have been received, which value is the remote target for the dialog? >=20 > 2) Similar to (1), but for Record-Route. >=20 > By eliminating one source of information for the dialog (the 200),=20 > there are a number of questions than then need not be either asked or=20 > answered. >=20 > Thanks, > Paul >=20 > Ian Elz wrote: >> Adam. >> >> I understand that most of what I commented on was included in RFC3265. >> The problem with RFC3265 was that a lot of the detail was missing.=20 >> The >=20 >> concept of the new draft is to correct those omissions and to=20 >> simplify >=20 >> and clarify what was included in RFC3265. >> >> RFC3265 does not include anything about how the subscriber (I will=20 >> use >=20 >> subscriber and notifier as UAC/UAS reverse for the SUBSCRIBE and >> NOTIFY.) obtains his route set. If the new RFC does not explicitly=20 >> state that the subscriber route set is obtained from the Record-Route >> header contained in the NOTIFY then RFC3261 applies the subscriber=20 >> route set is obtained form the 2xx to the SUBSCRIBE. This will make=20 >> for an interesting dialog if the 2xx to the SUSCRIBE is never > received. >> Specific responses in-line [ige]. >> >> Ian >> >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: 14 August 2009 20:57 >> To: Ian Elz >> Cc: sipcore@ietf.org; Christer Holmberg >> Subject: Re: draft-roach-sipcore-rfc3265bis-00 >> >> Ian Elz wrote: >> >>> Now a more complex issue: >>> >>> You are proposing that the first NOTIFY establishes the SUBSCRIBE=20 >>> dialog. What impact does this have on the establishment of the route >>> set at the UAC as defined in RFC3261? >>> >> From a practical perspective, it's the same as what we have in 3265 >> -- except that it's a little easier to implement at the subscriber. >> >> Keep in mind that 3265 describes dialogs being established by NOTIFY=20 >> requests -- this is not new in the 3265bis draft. The only difference >> in dialog establishment is that we're removing the ability for a=20 >> SUBSCRIBE 200 response to create a dialog. >> >> This is an extremely important point, so I'll repeat it: this change=20 >> is not *ADDING* new behavior. It is *REMOVING* unnecessary behavior=20 >> that has been shown to cause problems. >> >> [ige] I understand that you are not adding any functionality which is >> different from RFC3265. The problem is that what was in RFC3265=20 >> changed the actions specified in RFC3261 but did not state how they=20 >> hade been changed. This is part of what caused the problems in=20 >> RFC3265. The updated RFC MUST include this detail or we will end up=20 >> with inconsistent implementations. >> >>> Normal RFC3261 has the UAS route set taken from Record-Route in the=20 >>> initial request. The UAS then copies the Record-Route back into the=20 >>> 2xx response (or reliable provisional response) which is then used=20 >>> by >=20 >>> the UAC to set its the route set. This ensures that the route sets=20 >>> in >=20 >>> the UAC and UAS align. >>> >>> Section 4.3 of the draft proposes that the initial SUBSCRIBE has the >>> normal Record-Route which establishes the UAS route set but that the >>> NOTIFY also has Record-Route performed by proxies. This leaves the=20 >>> possibility that the route set at the UAC and UAS may not align. >>> >> Actually, it doesn't. As long as proxies follow the guidance in 4.3,=20 >> then the route set in the SUBSCRIBE will be precisely identical to=20 >> the >=20 >> route set established by the NOTIFY. Because of the Record-Route in=20 >> the SUBSCRIBE, the NOTIFY will contain Route header fields that=20 >> guarantee that the NOTIFY traverses the proxies that Record-Route the > SUBSCRIBE. >> These proxies, by the normative requirement in 4.3, will then=20 >> Record-Route the NOTIFY, which guarantees that the route set in the=20 >> subscriber matches that of the notifier. >> >> If you think I'm confused about this in some way, please describe a=20 >> concrete set of compliant proxy behaviors that can result in an=20 >> asymmetrical route set, preferably using a sequence diagram. >> >> [ige] The problem we have is backward compatibility. If the=20 >> subscriber >=20 >> and notifier support the proposed new functionality but an=20 >> intermediate proxies does not then this may result in an asymmetric=20 >> route sets. The SUBSCRIBE will be seen by the proxy as a dialog=20 >> initiating request and will add itself to the Record-Route in the=20 >> SUBSCRIBE. When the NOTIFY is handled however there is no requirement >> in RFC3261 to include itself in the Record-route as RFC3261 is=20 >> explicit in the fact that any Record-route added to the NOTIFY will=20 >> NOT update the route set. Thus asymmetric route sets will result.=20 >> This >=20 >> will result in SUSCRIBE messages being passed via different proxies=20 >> than the NOTIFY with the result that some proxies will see a=20 >> subscription termination resulting from a SUBSCRIBE but not from a=20 >> NOTIFY or as the result of a rejection of a NOTIFY. >> >> >>> I also have a concern as to what will happen with the route set if=20 >>> the SUBSCRIBE Record-Route is returned in the 2xx and the NOTIFY=20 >>> also >=20 >>> includes a Record-Route. Which one is used to establish the route=20 >>> set >=20 >>> at the subscriber. Do we take the one which arrives first? Do we=20 >>> take >=20 >>> the one which arrives second? There is no issue if they are the same >>> but what if they differ? >>> >> As I mention above: In a compliant system, they can't differ.=20 >> However, >=20 >> as we all know, systems don't always do the right thing. SBCs can=20 >> tinker with Route/Record-Route in ways that create asymmetric route=20 >> sets, even for normal INVITE/200/ACK transactions. >> >> With 3265, if there *were* a difference, your question is highly >> relevant: the answer to "but what if they differ?" was a resounding=20 >> "I >=20 >> have no clue!" >> >> Which is one of the key reasons why we made this change. >> >> In 3265bis, the answer is straightforward: since the NOTIFY=20 >> establishes the dialog, the NOTIFY is where the route set comes from. >> >> Really, the 200 response is kind of a throw-away message anyway. Even >> with legacy 3265 behavior, if I have a SUBSCRIBE fork, and it=20 >> establishes two dialogs, I'm going to have to take the route set for=20 >> at least one of the dialogs from the NOTIFY -- so I may as well=20 >> always >=20 >> take it from the NOTIFY. >> >> [ige] Agree that with forking only a single 200 OK will mean that=20 >> NOTIFY will be used to establish other SUBSCRIBE dialogs. This=20 >> appears >=20 >> to be an issue with forking and RFC3261 where only a single 2xx=20 >> response is returned. If I subscribe and multiple nodes accept the > subscription e.g. >> I subscribe to the dialog-event mechanism for all dialogs for a user, >> why shouldn't multiple 2xx responses to the SUBSCRIBE be returned to=20 >> establish multiple dialogs and to set up the route sets for each of=20 >> those dialogs. >> >>> Should there be a requirement that proxies MUST include themselves=20 >>> in >=20 >>> the NOTIFY Record-Route if they included themselves in the SUBSCRIBE >>> Record-Route and to exclude themselves in the NOTUFY if they were=20 >>> not >=20 >>> in the SUBSCRIBE Record-Route. >>> >> That's certainly the intention of 4.3. It's a bit tortured to imagine >> that a proxy might be on the path of the NOTIFY without having=20 >> Record-Routing the SUBSCRIBE. Nonetheless, I'm okay with prohibiting=20 >> Record-Routing a NOTIFY unless you've also Record-Routed the=20 >> associated SUBSCRIBE; I'll add: >> >> Proxies that did not add a Record-Route header field to the >> initial SUBSCRIBE request MUST NOT add a Record-Route header >> field to any of the associated NOTIFY requests. >> >> [ige] But there is nothing to indicate that proxies which did add=20 >> themselves to the Record-Route in the SUBSCRIBE MUST add themselves=20 >> to >=20 >> the Record-Route in subsequent NOTIFY requests for the same dialog > (?). >> This does not remove the compatibility issue where the proxy does not >> support the updates included in the draft. >> >> >>> If we are to use the Record-Route in the NOTIFY then the draft=20 >>> should >=20 >>> explicitly state what should happen at the subscriber end. Should=20 >>> the >=20 >>> 2xx response to the NOTIFY include a copy of the Record-Route taken=20 >>> from the NOTIFY? >>> >> It doesn't matter. >> >> [ige] If you don't include normative text which specifies that the=20 >> route set is established from the Record-Route in the NOTIFY then >> RFC3261 applies and the route set at the subscriber is obtained from=20 >> the 2xx to the SUBSCRIBE. >> >>> What does the notifier end do if it then receives this Record-Route? >>> >> It ignores it. There is no way to change a dialog route set (other=20 >> than the remote target) mid-dialog. >> >> [ige] Is what you are saying is that for one dialog you may take the=20 >> route set from the 2xx to the SUBSCRIBE, depending upon whether the=20 >> NOTIFY or 2xx arrives first, and for other dialogs it is taken from=20 >> the NOTIFY. In the forked case you may then end up with one symmetric >> route set and multiple asymmetric route sets; i.e. all the proxies=20 >> may >=20 >> see subsequent SUBSCRIBE requests for one dialog but not for the=20 >> others. I am not sure what this will do to the proxies handling of=20 >> the >=20 >> dialogs if anything but we need to consider it to be sure. >> >> >>> There is one more related issue: >>> >>> What happens if the 2xx to the SUBSCRIBE transaction is never=20 >>> received by the subscriber. Based upon the non-INVITE client=20 >>> transaction in >>> RFC3261 the termination of the transaction upon expiry of Timer F=20 >>> will inform the TU. In normal cases the TU would terminate the=20 >>> transaction and drop the dialog In this case if the NOTIFY has been=20 >>> received before the 2xx then this should be treated as the 2xx from=20 >>> the transaction perspective. This almost goes as far as defining a=20 >>> separate client SUBSCRIBE transaction. >>> >> Again, this behavior was present in 3265, and quite deliberately so. >> Keep in mind: for any network that has even a single proxy that=20 >> doesn't Record-Route, the vast majority of SUBSCRIBE dialogs will be=20 >> established by the NOTIFY, not the 200 (since the NOTIFY will follow=20 >> a >=20 >> shorter path than the 200). And, with forking, all but one of the 200 >> responses will be discarded by the proxy anyway. You *really* don't=20 >> want the system behavior to vary based on which 200 response wins the > race to the proxy. >> [ige] No we don't want the behaviour based upon whether the 2xx of=20 >> the >=20 >> NOTIFY wins the race. This is why the draft needs to be explicit upon >> how the route set is determined at the subscriber end. >> >> /a >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >=20 From jmpolk@cisco.com Tue Aug 18 14:46:59 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B760C3A6BBC for ; Tue, 18 Aug 2009 14:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.547 X-Spam-Level: X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ix1ilkrAARm5 for ; Tue, 18 Aug 2009 14:46:58 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id EDE253A6A70 for ; Tue, 18 Aug 2009 14:46:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoGAIm9ikqrR7MV/2dsb2JhbACIXLZsiC2QZQWCQIFZgVM X-IronPort-AV: E=Sophos;i="4.43,404,1246838400"; d="scan'208";a="370007485" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 18 Aug 2009 21:45:29 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7ILjTdZ008860; Tue, 18 Aug 2009 14:45:29 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7ILjT0o017185; Tue, 18 Aug 2009 21:45:29 GMT 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.3959); Tue, 18 Aug 2009 14:45:29 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.12.118]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 14:45:29 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 18 Aug 2009 16:45:28 -0500 To: Adam Roach From: "James M. Polk" In-Reply-To: <4A8B0001.8000909@nostrum.com> References: <4A85CECC.3020401@nostrum.com> <4A8AD5F7.9080608@nostrum.com> <4A8B0001.8000909@nostrum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 18 Aug 2009 21:45:29.0431 (UTC) FILETIME=[343AA670:01CA204D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2030; t=1250631929; x=1251495929; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[sipcore]=203265bis=20Open=20Issue=3A=2 0Timer=20N=20and=20Resubscribes |Sender:=20; bh=O5l+GXoI+JwWYrqFnoDEqA0n5c639RkCG9mv2kbaxjA=; b=fARrXPafS5ZXIHzdjmXfbiJEIa7TWemNxV3vd2TmbjfrlneCV0OHWlmOGy qTCvTYq6SliBXI+UOTLikcREA49O+sywpuVyidOXx4jHRYOgStRqpfXJ/84E ekA/BhNmDnJmWClIEUKeRERXKCfqTfBhUNaEIz3f2/uIHtwJSFptk=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: SIPCORE Subject: Re: [sipcore] 3265bis Open Issue: Timer N and Resubscribes X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 21:46:59 -0000 At 02:24 PM 8/18/2009, Adam Roach wrote: >James M. Polk wrote: >>can't you merely mandate a new Binding Request before each >>SUBSCRIBE/reSUBSCRIBE? > >There's a distinct rat hole in that direction that I don't think we >want to go down in RFC 3265bis (do we also check for VPN liveness? >Collect local IP addresses again? Verify the IPv6 tunnel? Ping the >Teredo server? Contact the DHCP server again to make sure the >address is still issued to us? The actions here are virtually boundless). > >It's much bigger than just SUBSCRIBE/NOTIFY -- it affects all >dialogs. In theory, the proper solution is to use sip-outbound. In >practice, architects, implementors, and deployers don't always make >the optimal choice. > >More to the point: we haven't, in *any* SIP document, gone about >normatively specifying anything about when or how a client >determines which addresses belong to the local machine or then to >acquire new information. > >>If that doesn't cut it, then when the binding times out (and >>without the reSUBSCRIBE), don't the original NOTIFYs also die at >>the NAT (thus making NATs evil -- oh yeah, they already are evil)? > >It does, and they are. We can't fix the evil here -- but I'm >concerned about amplifying it, 11 messages at a time. > >Keep in mind that the scenario I described was an attempt to find a >plausible set of circumstances in which the SUBSCRIBE 200 would >reliably arrive at a subscriber, but in which the NOTIFY would >consistently fail to do so. And, in this case, I would argue that >the proper behavior is to drop the subscription (since it's never >going to recover). ok - I'm not going to argue that logic Remind me what you have this timer default set to for allowing the SUBSCRIBE 200 to be received before determining the NOTIFY isn't coming (ever)? >Unless we can come up with some other plausible scenario that leads >us to a different conclusion, I would think this is the correct >answer in general. > >/a From adam@nostrum.com Tue Aug 18 15:44:26 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79A033A6828 for ; Tue, 18 Aug 2009 15:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.747 X-Spam-Level: X-Spam-Status: No, score=-2.747 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaWGZmFhG8fW for ; Tue, 18 Aug 2009 15:44:25 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 6AA9728C1F0 for ; Tue, 18 Aug 2009 15:44:14 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n7IMiFhs091393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Aug 2009 17:44:15 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A8B2EBF.7010704@nostrum.com> Date: Tue, 18 Aug 2009 17:44:15 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: "James M. Polk" References: <4A85CECC.3020401@nostrum.com> <4A8AD5F7.9080608@nostrum.com> <4A8B0001.8000909@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] 3265bis Open Issue: Timer N and Resubscribes X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 22:44:26 -0000 James M. Polk wrote: > At 02:24 PM 8/18/2009, Adam Roach wrote: >> James M. Polk wrote: >>> can't you merely mandate a new Binding Request before each >>> SUBSCRIBE/reSUBSCRIBE? >> >> There's a distinct rat hole in that direction that I don't think we >> want to go down in RFC 3265bis (do we also check for VPN liveness? >> Collect local IP addresses again? Verify the IPv6 tunnel? Ping the >> Teredo server? Contact the DHCP server again to make sure the address >> is still issued to us? The actions here are virtually boundless). >> >> It's much bigger than just SUBSCRIBE/NOTIFY -- it affects all >> dialogs. In theory, the proper solution is to use sip-outbound. In >> practice, architects, implementors, and deployers don't always make >> the optimal choice. >> >> More to the point: we haven't, in *any* SIP document, gone about >> normatively specifying anything about when or how a client determines >> which addresses belong to the local machine or then to acquire new >> information. >> >>> If that doesn't cut it, then when the binding times out (and without >>> the reSUBSCRIBE), don't the original NOTIFYs also die at the NAT >>> (thus making NATs evil -- oh yeah, they already are evil)? >> >> It does, and they are. We can't fix the evil here -- but I'm >> concerned about amplifying it, 11 messages at a time. >> >> Keep in mind that the scenario I described was an attempt to find a >> plausible set of circumstances in which the SUBSCRIBE 200 would >> reliably arrive at a subscriber, but in which the NOTIFY would >> consistently fail to do so. And, in this case, I would argue that the >> proper behavior is to drop the subscription (since it's never going >> to recover). > > ok - I'm not going to argue that logic > > Remind me what you have this timer default set to for allowing the > SUBSCRIBE 200 to be received before determining the NOTIFY isn't > coming (ever)? > It's defined as 64 * T1 -- which would be 32 seconds by default. /a From pkyzivat@cisco.com Tue Aug 18 16:22:29 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E9A228C38F for ; Tue, 18 Aug 2009 16:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhDlv8ybCPAm for ; Tue, 18 Aug 2009 16:22:27 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 5138A28C38C for ; Tue, 18 Aug 2009 16:22:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHfUikpAZnme/2dsb2JhbAC/EogtkHQFhBk X-IronPort-AV: E=Sophos;i="4.43,404,1246838400"; d="scan'208";a="54584991" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Aug 2009 23:22:31 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7INMVJm024066; Tue, 18 Aug 2009 19:22:31 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7INMVpq006636; Tue, 18 Aug 2009 23:22:31 GMT 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.3959); Tue, 18 Aug 2009 19:22:31 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 19:22:31 -0400 Message-ID: <4A8B37B6.20509@cisco.com> Date: Tue, 18 Aug 2009 19:22:30 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Ian Elz References: <4A85C195.4060903@nostrum.com> <4A89DF9E.9010807@cisco.com> <4A8B1D01.7090403@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Aug 2009 23:22:31.0035 (UTC) FILETIME=[C22CECB0:01CA205A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14288; t=1250637751; x=1251501751; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20draft-roach-sipcore-rfc3265 bis-00=20-=20Record-Route=20and=0A=20tranaction=20state=20mo del. |Sender:=20 |To:=20Ian=20Elz=20; bh=jOVkKpdOdQKdEhpkdH4cqoNaOSQY/WUZq+c71I8vV4U=; b=cKwvDckESDJl+Sf0qpAPwj2N9TS5UNMj64PkN8IEvyjmd+8Ns2zO54dcPt 8t7XgkMUIRPAnBM2lmGY8sw2VT4xJF0/4EQm8u4bgyIc7qWBAJe1Y0ESlxCA jW86a7mDMX; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 - Record-Route and tranaction state model. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 23:22:29 -0000 Ian Elz wrote: > Paul, > > REFER is an odd case. It is always described as creating an implicit > subscription. I think this means that it is not a SUBSCRIBE. My view is > that REFER creates an explicit subscription to a specific event package, > "dialog progress". If REFER is not creating a subscription the > 'norefersub' should be included. > > 3625bis does create an interesting case for REFER, REFER dialogs are > created when the 202 Accepted is received. Is this going to be the case > or should the NOTIFY be used? It makes at least as much sense in the REFER case as the SUBSCRIBE case. I worked on an impl of SUBSCRIBE and REFER, and definitely shared code between them. It will be bad enough to migrate an implementation from 3265 to 3265bis. It will be much worse if REFER creates a dialog but SUBSCRIBE does not. > Do we also need to rewrite RFC3515? I don't suppose it could be part of 3265bis? :-( Paul > Ian > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 18 August 2009 22:29 > To: Ian Elz > Cc: Adam Roach; sipcore@ietf.org > Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 - Record-Route > and tranaction state model. > > > > Ian Elz wrote: >> Paul, >> >> Agreed. >> >> Where the establishment of a SUBSCRIBE dialog is different from other >> dialog types I think that the draft should be explicit. E.g. It should > >> indicate that all the UAS actions for the 200 Ok should be taken but >> the UAC will ignore this for establishing the dialog. That the NOTIFY >> headers will be used for establishing the dialog, record-route, >> contact etc. > > That is the one thing I don't like about this approach - that it makes > entirely new rules for dialog establishment for SUBSCRIBE. But > interestingly, this makes it more consistent with REFER. And it was > already a special case because of the NOTIFY forking. > > Thanks, > Paul > >> Ian >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 17 August 2009 23:54 >> To: Ian Elz >> Cc: Adam Roach; sipcore@ietf.org >> Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 - >> Record-Route and tranaction state model. >> >> Ian, >> >> 3265 wasn't very explicit about some of this, and the end result was >> that for several things there were two different mechanisms for >> obtaining information, and no clear rules about which took precedence. >> This typically isn't a problem *as long as both mechanisms yield the >> same result*. But whenever you "replicate" something there is always >> the possibility that the results aren't really replicas, and then >> questions about which is the *true* one. >> >> For instance, >> >> 1) suppose the first NOTIFY arrives before the 200 (SUBSCRIBE) does. >> and suppose the two contain different Contact URIs. After both >> have been received, which value is the remote target for the > dialog? >> 2) Similar to (1), but for Record-Route. >> >> By eliminating one source of information for the dialog (the 200), >> there are a number of questions than then need not be either asked or >> answered. >> >> Thanks, >> Paul >> >> Ian Elz wrote: >>> Adam. >>> >>> I understand that most of what I commented on was included in > RFC3265. >>> The problem with RFC3265 was that a lot of the detail was missing. >>> The >>> concept of the new draft is to correct those omissions and to >>> simplify >>> and clarify what was included in RFC3265. >>> >>> RFC3265 does not include anything about how the subscriber (I will >>> use >>> subscriber and notifier as UAC/UAS reverse for the SUBSCRIBE and >>> NOTIFY.) obtains his route set. If the new RFC does not explicitly >>> state that the subscriber route set is obtained from the Record-Route > >>> header contained in the NOTIFY then RFC3261 applies the subscriber >>> route set is obtained form the 2xx to the SUBSCRIBE. This will make >>> for an interesting dialog if the 2xx to the SUSCRIBE is never >> received. >>> Specific responses in-line [ige]. >>> >>> Ian >>> >>> -----Original Message----- >>> From: Adam Roach [mailto:adam@nostrum.com] >>> Sent: 14 August 2009 20:57 >>> To: Ian Elz >>> Cc: sipcore@ietf.org; Christer Holmberg >>> Subject: Re: draft-roach-sipcore-rfc3265bis-00 >>> >>> Ian Elz wrote: >>> >>>> Now a more complex issue: >>>> >>>> You are proposing that the first NOTIFY establishes the SUBSCRIBE >>>> dialog. What impact does this have on the establishment of the route > >>>> set at the UAC as defined in RFC3261? >>>> >>> From a practical perspective, it's the same as what we have in 3265 >>> -- except that it's a little easier to implement at the subscriber. >>> >>> Keep in mind that 3265 describes dialogs being established by NOTIFY >>> requests -- this is not new in the 3265bis draft. The only difference > >>> in dialog establishment is that we're removing the ability for a >>> SUBSCRIBE 200 response to create a dialog. >>> >>> This is an extremely important point, so I'll repeat it: this change >>> is not *ADDING* new behavior. It is *REMOVING* unnecessary behavior >>> that has been shown to cause problems. >>> >>> [ige] I understand that you are not adding any functionality which is > >>> different from RFC3265. The problem is that what was in RFC3265 >>> changed the actions specified in RFC3261 but did not state how they >>> hade been changed. This is part of what caused the problems in >>> RFC3265. The updated RFC MUST include this detail or we will end up >>> with inconsistent implementations. >>> >>>> Normal RFC3261 has the UAS route set taken from Record-Route in the >>>> initial request. The UAS then copies the Record-Route back into the >>>> 2xx response (or reliable provisional response) which is then used >>>> by >>>> the UAC to set its the route set. This ensures that the route sets >>>> in >>>> the UAC and UAS align. >>>> >>>> Section 4.3 of the draft proposes that the initial SUBSCRIBE has the > >>>> normal Record-Route which establishes the UAS route set but that the > >>>> NOTIFY also has Record-Route performed by proxies. This leaves the >>>> possibility that the route set at the UAC and UAS may not align. >>>> >>> Actually, it doesn't. As long as proxies follow the guidance in 4.3, >>> then the route set in the SUBSCRIBE will be precisely identical to >>> the >>> route set established by the NOTIFY. Because of the Record-Route in >>> the SUBSCRIBE, the NOTIFY will contain Route header fields that >>> guarantee that the NOTIFY traverses the proxies that Record-Route the >> SUBSCRIBE. >>> These proxies, by the normative requirement in 4.3, will then >>> Record-Route the NOTIFY, which guarantees that the route set in the >>> subscriber matches that of the notifier. >>> >>> If you think I'm confused about this in some way, please describe a >>> concrete set of compliant proxy behaviors that can result in an >>> asymmetrical route set, preferably using a sequence diagram. >>> >>> [ige] The problem we have is backward compatibility. If the >>> subscriber >>> and notifier support the proposed new functionality but an >>> intermediate proxies does not then this may result in an asymmetric >>> route sets. The SUBSCRIBE will be seen by the proxy as a dialog >>> initiating request and will add itself to the Record-Route in the >>> SUBSCRIBE. When the NOTIFY is handled however there is no requirement > >>> in RFC3261 to include itself in the Record-route as RFC3261 is >>> explicit in the fact that any Record-route added to the NOTIFY will >>> NOT update the route set. Thus asymmetric route sets will result. >>> This >>> will result in SUSCRIBE messages being passed via different proxies >>> than the NOTIFY with the result that some proxies will see a >>> subscription termination resulting from a SUBSCRIBE but not from a >>> NOTIFY or as the result of a rejection of a NOTIFY. >>> >>> >>>> I also have a concern as to what will happen with the route set if >>>> the SUBSCRIBE Record-Route is returned in the 2xx and the NOTIFY >>>> also >>>> includes a Record-Route. Which one is used to establish the route >>>> set >>>> at the subscriber. Do we take the one which arrives first? Do we >>>> take >>>> the one which arrives second? There is no issue if they are the same > >>>> but what if they differ? >>>> >>> As I mention above: In a compliant system, they can't differ. >>> However, >>> as we all know, systems don't always do the right thing. SBCs can >>> tinker with Route/Record-Route in ways that create asymmetric route >>> sets, even for normal INVITE/200/ACK transactions. >>> >>> With 3265, if there *were* a difference, your question is highly >>> relevant: the answer to "but what if they differ?" was a resounding >>> "I >>> have no clue!" >>> >>> Which is one of the key reasons why we made this change. >>> >>> In 3265bis, the answer is straightforward: since the NOTIFY >>> establishes the dialog, the NOTIFY is where the route set comes from. >>> >>> Really, the 200 response is kind of a throw-away message anyway. Even > >>> with legacy 3265 behavior, if I have a SUBSCRIBE fork, and it >>> establishes two dialogs, I'm going to have to take the route set for >>> at least one of the dialogs from the NOTIFY -- so I may as well >>> always >>> take it from the NOTIFY. >>> >>> [ige] Agree that with forking only a single 200 OK will mean that >>> NOTIFY will be used to establish other SUBSCRIBE dialogs. This >>> appears >>> to be an issue with forking and RFC3261 where only a single 2xx >>> response is returned. If I subscribe and multiple nodes accept the >> subscription e.g. >>> I subscribe to the dialog-event mechanism for all dialogs for a user, > >>> why shouldn't multiple 2xx responses to the SUBSCRIBE be returned to >>> establish multiple dialogs and to set up the route sets for each of >>> those dialogs. >>> >>>> Should there be a requirement that proxies MUST include themselves >>>> in >>>> the NOTIFY Record-Route if they included themselves in the SUBSCRIBE > >>>> Record-Route and to exclude themselves in the NOTUFY if they were >>>> not >>>> in the SUBSCRIBE Record-Route. >>>> >>> That's certainly the intention of 4.3. It's a bit tortured to imagine > >>> that a proxy might be on the path of the NOTIFY without having >>> Record-Routing the SUBSCRIBE. Nonetheless, I'm okay with prohibiting >>> Record-Routing a NOTIFY unless you've also Record-Routed the >>> associated SUBSCRIBE; I'll add: >>> >>> Proxies that did not add a Record-Route header field to the >>> initial SUBSCRIBE request MUST NOT add a Record-Route header >>> field to any of the associated NOTIFY requests. >>> >>> [ige] But there is nothing to indicate that proxies which did add >>> themselves to the Record-Route in the SUBSCRIBE MUST add themselves >>> to >>> the Record-Route in subsequent NOTIFY requests for the same dialog >> (?). >>> This does not remove the compatibility issue where the proxy does not > >>> support the updates included in the draft. >>> >>> >>>> If we are to use the Record-Route in the NOTIFY then the draft >>>> should >>>> explicitly state what should happen at the subscriber end. Should >>>> the >>>> 2xx response to the NOTIFY include a copy of the Record-Route taken >>>> from the NOTIFY? >>>> >>> It doesn't matter. >>> >>> [ige] If you don't include normative text which specifies that the >>> route set is established from the Record-Route in the NOTIFY then >>> RFC3261 applies and the route set at the subscriber is obtained from >>> the 2xx to the SUBSCRIBE. >>> >>>> What does the notifier end do if it then receives this Record-Route? >>>> >>> It ignores it. There is no way to change a dialog route set (other >>> than the remote target) mid-dialog. >>> >>> [ige] Is what you are saying is that for one dialog you may take the >>> route set from the 2xx to the SUBSCRIBE, depending upon whether the >>> NOTIFY or 2xx arrives first, and for other dialogs it is taken from >>> the NOTIFY. In the forked case you may then end up with one symmetric > >>> route set and multiple asymmetric route sets; i.e. all the proxies >>> may >>> see subsequent SUBSCRIBE requests for one dialog but not for the >>> others. I am not sure what this will do to the proxies handling of >>> the >>> dialogs if anything but we need to consider it to be sure. >>> >>> >>>> There is one more related issue: >>>> >>>> What happens if the 2xx to the SUBSCRIBE transaction is never >>>> received by the subscriber. Based upon the non-INVITE client >>>> transaction in >>>> RFC3261 the termination of the transaction upon expiry of Timer F >>>> will inform the TU. In normal cases the TU would terminate the >>>> transaction and drop the dialog In this case if the NOTIFY has been >>>> received before the 2xx then this should be treated as the 2xx from >>>> the transaction perspective. This almost goes as far as defining a >>>> separate client SUBSCRIBE transaction. >>>> >>> Again, this behavior was present in 3265, and quite deliberately so. >>> Keep in mind: for any network that has even a single proxy that >>> doesn't Record-Route, the vast majority of SUBSCRIBE dialogs will be >>> established by the NOTIFY, not the 200 (since the NOTIFY will follow >>> a >>> shorter path than the 200). And, with forking, all but one of the 200 > >>> responses will be discarded by the proxy anyway. You *really* don't >>> want the system behavior to vary based on which 200 response wins the >> race to the proxy. >>> [ige] No we don't want the behaviour based upon whether the 2xx of >>> the >>> NOTIFY wins the race. This is why the draft needs to be explicit upon > >>> how the route set is determined at the subscriber end. >>> >>> /a >>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> > From christer.holmberg@ericsson.com Wed Aug 19 05:22:20 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6FED3A6E62 for ; Wed, 19 Aug 2009 05:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.615 X-Spam-Level: X-Spam-Status: No, score=-5.615 tagged_above=-999 required=5 tests=[AWL=0.634, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwI++JyLtBDI for ; Wed, 19 Aug 2009 05:22:19 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 2C4A53A6D66 for ; Wed, 19 Aug 2009 05:22:17 -0700 (PDT) X-AuditID: c1b4fb3c-b7c01ae000002aae-61-4a8bee7c4519 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 0D.05.10926.C7EEB8A4; Wed, 19 Aug 2009 14:22:20 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 14:20:10 +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, 19 Aug 2009 14:20:09 +0200 Message-ID: In-Reply-To: <4A8B37B6.20509@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-roach-sipcore-rfc3265bis-00 - Record-Route and tranaction state model. Thread-Index: AcogWshrlmfGeq51Q42jGBDXZN3PGgAaiFqw References: <4A85C195.4060903@nostrum.com><4A89DF9E.9010807@cisco.com><4A8B1D01.7090403@cisco.com> <4A8B37B6.20509@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Ian Elz" X-OriginalArrivalTime: 19 Aug 2009 12:20:10.0475 (UTC) FILETIME=[655E73B0:01CA20C7] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 - Record-Route and tranaction state model. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 12:22:20 -0000 Hi,=20 =20 >>REFER is an odd case. It is always described as creating an implicit=20 >>subscription. I think this means that it is not a SUBSCRIBE. My view=20 >>is that REFER creates an explicit subscription to a specific event=20 >>package, "dialog progress". If REFER is not creating a subscription=20 >>the 'norefersub' should be included. >>=20 >>3625bis does create an interesting case for REFER, REFER dialogs are=20 >>created when the 202 Accepted is received. Is this going to be the=20 >>case or should the NOTIFY be used? >=20 >It makes at least as much sense in the REFER case as the=20 >SUBSCRIBE case. >I worked on an impl of SUBSCRIBE and REFER, and definitely=20 >shared code between them. >=20 >It will be bad enough to migrate an implementation from 3265=20 >to 3265bis.=20 >It will be much worse if REFER creates a dialog but SUBSCRIBE=20 >does not. >=20 >>Do we also need to rewrite RFC3515? >=20 >I don't suppose it could be part of 3265bis? :-( Would we then also deprecate dialog re-use for REFER? Regards, Christer > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: 18 August 2009 22:29 > > To: Ian Elz > > Cc: Adam Roach; sipcore@ietf.org > > Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 -=20 > > Record-Route and tranaction state model. > >=20 > >=20 > >=20 > > Ian Elz wrote: > >> Paul, > >> > >> Agreed. > >> > >> Where the establishment of a SUBSCRIBE dialog is different=20 > from other=20 > >> dialog types I think that the draft should be explicit. E.g. It=20 > >> should > >=20 > >> indicate that all the UAS actions for the 200 Ok should be=20 > taken but=20 > >> the UAC will ignore this for establishing the dialog. That=20 > the NOTIFY=20 > >> headers will be used for establishing the dialog, record-route,=20 > >> contact etc. > >=20 > > That is the one thing I don't like about this approach -=20 > that it makes=20 > > entirely new rules for dialog establishment for SUBSCRIBE. But=20 > > interestingly, this makes it more consistent with REFER. And it was=20 > > already a special case because of the NOTIFY forking. > >=20 > > Thanks, > > Paul > >=20 > >> Ian > >> > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: 17 August 2009 23:54 > >> To: Ian Elz > >> Cc: Adam Roach; sipcore@ietf.org > >> Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 -=20 > >> Record-Route and tranaction state model. > >> > >> Ian, > >> > >> 3265 wasn't very explicit about some of this, and the end=20 > result was=20 > >> that for several things there were two different mechanisms for=20 > >> obtaining information, and no clear rules about which took=20 > precedence. > >> This typically isn't a problem *as long as both mechanisms=20 > yield the=20 > >> same result*. But whenever you "replicate" something there=20 > is always=20 > >> the possibility that the results aren't really replicas, and then=20 > >> questions about which is the *true* one. > >> > >> For instance, > >> > >> 1) suppose the first NOTIFY arrives before the 200=20 > (SUBSCRIBE) does. > >> and suppose the two contain different Contact URIs. After both > >> have been received, which value is the remote target for the > > dialog? > >> 2) Similar to (1), but for Record-Route. > >> > >> By eliminating one source of information for the dialog (the 200),=20 > >> there are a number of questions than then need not be=20 > either asked or=20 > >> answered. > >> > >> Thanks, > >> Paul > >> > >> Ian Elz wrote: > >>> Adam. > >>> > >>> I understand that most of what I commented on was included in > > RFC3265. > >>> The problem with RFC3265 was that a lot of the detail was=20 > missing.=20 > >>> The > >>> concept of the new draft is to correct those omissions and to=20 > >>> simplify and clarify what was included in RFC3265. > >>> > >>> RFC3265 does not include anything about how the=20 > subscriber (I will=20 > >>> use subscriber and notifier as UAC/UAS reverse for the=20 > SUBSCRIBE and > >>> NOTIFY.) obtains his route set. If the new RFC does not=20 > explicitly=20 > >>> state that the subscriber route set is obtained from the=20 > >>> Record-Route > >=20 > >>> header contained in the NOTIFY then RFC3261 applies the=20 > subscriber=20 > >>> route set is obtained form the 2xx to the SUBSCRIBE. This=20 > will make=20 > >>> for an interesting dialog if the 2xx to the SUSCRIBE is never > >> received. > >>> Specific responses in-line [ige]. > >>> > >>> Ian > >>> > >>> -----Original Message----- > >>> From: Adam Roach [mailto:adam@nostrum.com] > >>> Sent: 14 August 2009 20:57 > >>> To: Ian Elz > >>> Cc: sipcore@ietf.org; Christer Holmberg > >>> Subject: Re: draft-roach-sipcore-rfc3265bis-00 > >>> > >>> Ian Elz wrote: > >>> > >>>> Now a more complex issue: > >>>> > >>>> You are proposing that the first NOTIFY establishes the=20 > SUBSCRIBE=20 > >>>> dialog. What impact does this have on the establishment of the=20 > >>>> route > >=20 > >>>> set at the UAC as defined in RFC3261? > >>>> > >>> From a practical perspective, it's the same as what we=20 > have in 3265 > >>> -- except that it's a little easier to implement at the=20 > subscriber. > >>> > >>> Keep in mind that 3265 describes dialogs being=20 > established by NOTIFY=20 > >>> requests -- this is not new in the 3265bis draft. The only=20 > >>> difference > >=20 > >>> in dialog establishment is that we're removing the ability for a=20 > >>> SUBSCRIBE 200 response to create a dialog. > >>> > >>> This is an extremely important point, so I'll repeat it:=20 > this change=20 > >>> is not *ADDING* new behavior. It is *REMOVING*=20 > unnecessary behavior=20 > >>> that has been shown to cause problems. > >>> > >>> [ige] I understand that you are not adding any=20 > functionality which=20 > >>> is > >=20 > >>> different from RFC3265. The problem is that what was in RFC3265=20 > >>> changed the actions specified in RFC3261 but did not=20 > state how they=20 > >>> hade been changed. This is part of what caused the problems in=20 > >>> RFC3265. The updated RFC MUST include this detail or we=20 > will end up=20 > >>> with inconsistent implementations. > >>> > >>>> Normal RFC3261 has the UAS route set taken from=20 > Record-Route in the=20 > >>>> initial request. The UAS then copies the Record-Route=20 > back into the=20 > >>>> 2xx response (or reliable provisional response) which is=20 > then used=20 > >>>> by the UAC to set its the route set. This ensures that the route=20 > >>>> sets in the UAC and UAS align. > >>>> > >>>> Section 4.3 of the draft proposes that the initial SUBSCRIBE has=20 > >>>> the > >=20 > >>>> normal Record-Route which establishes the UAS route set but that=20 > >>>> the > >=20 > >>>> NOTIFY also has Record-Route performed by proxies. This=20 > leaves the=20 > >>>> possibility that the route set at the UAC and UAS may not align. > >>>> > >>> Actually, it doesn't. As long as proxies follow the=20 > guidance in 4.3,=20 > >>> then the route set in the SUBSCRIBE will be precisely=20 > identical to=20 > >>> the route set established by the NOTIFY. Because of the=20 > Record-Route=20 > >>> in the SUBSCRIBE, the NOTIFY will contain Route header=20 > fields that=20 > >>> guarantee that the NOTIFY traverses the proxies that Record-Route=20 > >>> the > >> SUBSCRIBE. > >>> These proxies, by the normative requirement in 4.3, will then=20 > >>> Record-Route the NOTIFY, which guarantees that the route=20 > set in the=20 > >>> subscriber matches that of the notifier. > >>> > >>> If you think I'm confused about this in some way, please=20 > describe a=20 > >>> concrete set of compliant proxy behaviors that can result in an=20 > >>> asymmetrical route set, preferably using a sequence diagram. > >>> > >>> [ige] The problem we have is backward compatibility. If the=20 > >>> subscriber and notifier support the proposed new=20 > functionality but=20 > >>> an intermediate proxies does not then this may result in an=20 > >>> asymmetric route sets. The SUBSCRIBE will be seen by the=20 > proxy as a=20 > >>> dialog initiating request and will add itself to the=20 > Record-Route in=20 > >>> the SUBSCRIBE. When the NOTIFY is handled however there is no=20 > >>> requirement > >=20 > >>> in RFC3261 to include itself in the Record-route as RFC3261 is=20 > >>> explicit in the fact that any Record-route added to the=20 > NOTIFY will=20 > >>> NOT update the route set. Thus asymmetric route sets will result. > >>> This > >>> will result in SUSCRIBE messages being passed via=20 > different proxies=20 > >>> than the NOTIFY with the result that some proxies will see a=20 > >>> subscription termination resulting from a SUBSCRIBE but=20 > not from a=20 > >>> NOTIFY or as the result of a rejection of a NOTIFY. > >>> > >>> > >>>> I also have a concern as to what will happen with the=20 > route set if=20 > >>>> the SUBSCRIBE Record-Route is returned in the 2xx and the NOTIFY=20 > >>>> also includes a Record-Route. Which one is used to establish the=20 > >>>> route set at the subscriber. Do we take the one which arrives=20 > >>>> first? Do we take the one which arrives second? There is=20 > no issue=20 > >>>> if they are the same > >=20 > >>>> but what if they differ? > >>>> > >>> As I mention above: In a compliant system, they can't differ.=20 > >>> However, > >>> as we all know, systems don't always do the right thing. SBCs can=20 > >>> tinker with Route/Record-Route in ways that create=20 > asymmetric route=20 > >>> sets, even for normal INVITE/200/ACK transactions. > >>> > >>> With 3265, if there *were* a difference, your question is highly > >>> relevant: the answer to "but what if they differ?" was a=20 > resounding=20 > >>> "I have no clue!" > >>> > >>> Which is one of the key reasons why we made this change. > >>> > >>> In 3265bis, the answer is straightforward: since the NOTIFY=20 > >>> establishes the dialog, the NOTIFY is where the route set=20 > comes from. > >>> > >>> Really, the 200 response is kind of a throw-away message anyway.=20 > >>> Even > >=20 > >>> with legacy 3265 behavior, if I have a SUBSCRIBE fork, and it=20 > >>> establishes two dialogs, I'm going to have to take the=20 > route set for=20 > >>> at least one of the dialogs from the NOTIFY -- so I may as well=20 > >>> always take it from the NOTIFY. > >>> > >>> [ige] Agree that with forking only a single 200 OK will mean that=20 > >>> NOTIFY will be used to establish other SUBSCRIBE dialogs. This=20 > >>> appears to be an issue with forking and RFC3261 where=20 > only a single=20 > >>> 2xx response is returned. If I subscribe and multiple=20 > nodes accept=20 > >>> the > >> subscription e.g. > >>> I subscribe to the dialog-event mechanism for all dialogs for a=20 > >>> user, > >=20 > >>> why shouldn't multiple 2xx responses to the SUBSCRIBE be=20 > returned to=20 > >>> establish multiple dialogs and to set up the route sets=20 > for each of=20 > >>> those dialogs. > >>> > >>>> Should there be a requirement that proxies MUST include=20 > themselves=20 > >>>> in the NOTIFY Record-Route if they included themselves in the=20 > >>>> SUBSCRIBE > >=20 > >>>> Record-Route and to exclude themselves in the NOTUFY if=20 > they were=20 > >>>> not in the SUBSCRIBE Record-Route. > >>>> > >>> That's certainly the intention of 4.3. It's a bit tortured to=20 > >>> imagine > >=20 > >>> that a proxy might be on the path of the NOTIFY without having=20 > >>> Record-Routing the SUBSCRIBE. Nonetheless, I'm okay with=20 > prohibiting=20 > >>> Record-Routing a NOTIFY unless you've also Record-Routed the=20 > >>> associated SUBSCRIBE; I'll add: > >>> > >>> Proxies that did not add a Record-Route header field to the > >>> initial SUBSCRIBE request MUST NOT add a Record-Route header > >>> field to any of the associated NOTIFY requests. > >>> > >>> [ige] But there is nothing to indicate that proxies which did add=20 > >>> themselves to the Record-Route in the SUBSCRIBE MUST add=20 > themselves=20 > >>> to the Record-Route in subsequent NOTIFY requests for the same=20 > >>> dialog > >> (?). > >>> This does not remove the compatibility issue where the proxy does=20 > >>> not > >=20 > >>> support the updates included in the draft. > >>> > >>> > >>>> If we are to use the Record-Route in the NOTIFY then the draft=20 > >>>> should explicitly state what should happen at the=20 > subscriber end.=20 > >>>> Should the 2xx response to the NOTIFY include a copy of the=20 > >>>> Record-Route taken from the NOTIFY? > >>>> > >>> It doesn't matter. > >>> > >>> [ige] If you don't include normative text which specifies=20 > that the=20 > >>> route set is established from the Record-Route in the NOTIFY then > >>> RFC3261 applies and the route set at the subscriber is=20 > obtained from=20 > >>> the 2xx to the SUBSCRIBE. > >>> > >>>> What does the notifier end do if it then receives this=20 > Record-Route? > >>>> > >>> It ignores it. There is no way to change a dialog route=20 > set (other=20 > >>> than the remote target) mid-dialog. > >>> > >>> [ige] Is what you are saying is that for one dialog you=20 > may take the=20 > >>> route set from the 2xx to the SUBSCRIBE, depending upon=20 > whether the=20 > >>> NOTIFY or 2xx arrives first, and for other dialogs it is=20 > taken from=20 > >>> the NOTIFY. In the forked case you may then end up with one=20 > >>> symmetric > >=20 > >>> route set and multiple asymmetric route sets; i.e. all=20 > the proxies=20 > >>> may see subsequent SUBSCRIBE requests for one dialog but=20 > not for the=20 > >>> others. I am not sure what this will do to the proxies=20 > handling of=20 > >>> the dialogs if anything but we need to consider it to be sure. > >>> > >>> > >>>> There is one more related issue: > >>>> > >>>> What happens if the 2xx to the SUBSCRIBE transaction is never=20 > >>>> received by the subscriber. Based upon the non-INVITE client=20 > >>>> transaction in > >>>> RFC3261 the termination of the transaction upon expiry=20 > of Timer F=20 > >>>> will inform the TU. In normal cases the TU would terminate the=20 > >>>> transaction and drop the dialog In this case if the=20 > NOTIFY has been=20 > >>>> received before the 2xx then this should be treated as=20 > the 2xx from=20 > >>>> the transaction perspective. This almost goes as far as=20 > defining a=20 > >>>> separate client SUBSCRIBE transaction. > >>>> > >>> Again, this behavior was present in 3265, and quite=20 > deliberately so. > >>> Keep in mind: for any network that has even a single proxy that=20 > >>> doesn't Record-Route, the vast majority of SUBSCRIBE=20 > dialogs will be=20 > >>> established by the NOTIFY, not the 200 (since the NOTIFY=20 > will follow=20 > >>> a shorter path than the 200). And, with forking, all but=20 > one of the=20 > >>> 200 > >=20 > >>> responses will be discarded by the proxy anyway. You=20 > *really* don't=20 > >>> want the system behavior to vary based on which 200 response wins=20 > >>> the > >> race to the proxy. > >>> [ige] No we don't want the behaviour based upon whether=20 > the 2xx of=20 > >>> the NOTIFY wins the race. This is why the draft needs to=20 > be explicit=20 > >>> upon > >=20 > >>> how the route set is determined at the subscriber end. > >>> > >>> /a > >>> > >>> > >>> _______________________________________________ > >>> sipcore mailing list > >>> sipcore@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sipcore > >>> > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From pkyzivat@cisco.com Wed Aug 19 05:59:26 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 251093A6AB2 for ; Wed, 19 Aug 2009 05:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6-Bi7qJm4ZN for ; Wed, 19 Aug 2009 05:59:25 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 6D4BE28C147 for ; Wed, 19 Aug 2009 05:59:06 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAC+Ui0qrR7PD/2dsb2JhbAC8eYgvkVMFhBo X-IronPort-AV: E=Sophos;i="4.43,408,1246838400"; d="scan'208";a="370504228" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 19 Aug 2009 12:59:11 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7JCxBFs029088; Wed, 19 Aug 2009 05:59:11 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7JCxBV4012264; Wed, 19 Aug 2009 12:59:11 GMT 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.3959); Wed, 19 Aug 2009 08:59:11 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 08:59:10 -0400 Message-ID: <4A8BF71D.6060105@cisco.com> Date: Wed, 19 Aug 2009 08:59:09 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Christer Holmberg References: <4A85C195.4060903@nostrum.com><4A89DF9E.9010807@cisco.com><4A8B1D01.7090403@cisco.com> <4A8B37B6.20509@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Aug 2009 12:59:10.0751 (UTC) FILETIME=[D8483AF0:01CA20CC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1224; t=1250686751; x=1251550751; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20draft-roach-sipcore-rfc3265 bis-00=20-=20Record-Route=20and=0A=20tranaction=20state=20mo del. |Sender:=20; bh=B8lq5/nzYjfOGy8AWTyWxwlbpc0e23NL0yYLRI6uLNk=; b=Jxd9Z0ddj8RUFlekVXjn2auViZdFcy5u7L4qhDoZL9oXNHc/0sGRi7jgYz cAchIYV5HnnkNzHAd1nFYuV2H2VRC9hc0sgx7He5xJxGZKaUNmI+BWKAFEox NcGYcFxgV6; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Ian Elz , sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 - Record-Route and tranaction state model. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 12:59:26 -0000 Christer Holmberg wrote: > Hi, > >>> REFER is an odd case. It is always described as creating an implicit >>> subscription. I think this means that it is not a SUBSCRIBE. My view >>> is that REFER creates an explicit subscription to a specific event >>> package, "dialog progress". If REFER is not creating a subscription >>> the 'norefersub' should be included. >>> >>> 3625bis does create an interesting case for REFER, REFER dialogs are >>> created when the 202 Accepted is received. Is this going to be the >>> case or should the NOTIFY be used? >> It makes at least as much sense in the REFER case as the >> SUBSCRIBE case. >> I worked on an impl of SUBSCRIBE and REFER, and definitely >> shared code between them. >> >> It will be bad enough to migrate an implementation from 3265 >> to 3265bis. >> It will be much worse if REFER creates a dialog but SUBSCRIBE >> does not. >> >>> Do we also need to rewrite RFC3515? >> I don't suppose it could be part of 3265bis? :-( > > Would we then also deprecate dialog re-use for REFER? I don't know. I think dialog reuse for REFER is quite institutionalized, so it would be very difficult to remove it now. Thanks, Paul From christer.holmberg@ericsson.com Wed Aug 19 06:34:41 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6CE13A6ACC for ; Wed, 19 Aug 2009 06:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.282 X-Spam-Level: X-Spam-Status: No, score=-4.282 tagged_above=-999 required=5 tests=[AWL=-0.730, BAYES_00=-2.599, FRT_POSSIBLE=2.697, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhUsdKZFY9lm for ; Wed, 19 Aug 2009 06:34:40 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 6F5153A6AFB for ; Wed, 19 Aug 2009 06:34:40 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf2ae000007ae0-5a-4a8bff733f9d Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id DA.B8.31456.37FFB8A4; Wed, 19 Aug 2009 15:34:43 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 15:33:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Aug 2009 15:33:33 +0200 Message-ID: In-Reply-To: <4A8BF71D.6060105@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-roach-sipcore-rfc3265bis-00 - Record-Route and tranaction state model. Thread-Index: AcogzNqNma6IWXvNTVOOwQcFr45d0AABCA7w References: <4A85C195.4060903@nostrum.com><4A89DF9E.9010807@cisco.com><4A8B1D01.7090403@cisco.com> <4A8B37B6.20509@cisco.com> <4A8BF71D.6060105@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 19 Aug 2009 13:33:34.0744 (UTC) FILETIME=[A6849180:01CA20D1] X-Brightmail-Tracker: AAAAAA== Cc: Ian Elz , sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 - Record-Route and tranaction state model. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 13:34:41 -0000 Hi,=20 =20 >>>>REFER is an odd case. It is always described as creating an implicit >>>>subscription. I think this means that it is not a SUBSCRIBE. My view >>>>is that REFER creates an explicit subscription to a specific event=20 >>>>package, "dialog progress". If REFER is not creating a subscription=20 >>>>the 'norefersub' should be included. >>>> >>>>3625bis does create an interesting case for REFER, REFER=20 >>>>dialogs are created when the 202 Accepted is received. Is this going=20 >>>>to be the case or should the NOTIFY be used? >>>It makes at least as much sense in the REFER case as the SUBSCRIBE case. >>>I worked on an impl of SUBSCRIBE and REFER, and definitely shared=20 >>>code between them. >>> >>>It will be bad enough to migrate an implementation from 3265 to 3265bis. >>>It will be much worse if REFER creates a dialog but SUBSCRIBE does not. >>> >>>>Do we also need to rewrite RFC3515? >>>I don't suppose it could be part of 3265bis? :-( >>=20 >>Would we then also deprecate dialog re-use for REFER? >=20 >I don't know. I think dialog reuse for REFER is quite=20 >institutionalized, so it would be very difficult to remove it now. I agree.=20 But, that means that dialog re-use for subscriptions are still possilble, even if invovled entities otherwise are 3265bis compliant. Maybe that should be mentioned in 3265bis. Regards, Christer From michael@voip.co.uk Wed Aug 19 06:47:56 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C1C73A6F88 for ; Wed, 19 Aug 2009 06:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVqYKmppRyAh for ; Wed, 19 Aug 2009 06:47:55 -0700 (PDT) Received: from na3sys009aog112.obsmtp.com (na3sys009aog112.obsmtp.com [74.125.149.207]) by core3.amsl.com (Postfix) with SMTP id 3A9BF3A6EA4 for ; Wed, 19 Aug 2009 06:47:55 -0700 (PDT) Received: from source ([209.85.219.214]) by na3sys009aob112.postini.com ([74.125.148.12]) with SMTP ID DSNKSowCiGI/bcxtF/biQoPQVKwp+f9YpYCz@postini.com; Wed, 19 Aug 2009 06:48:01 PDT Received: by ewy10 with SMTP id 10so6921926ewy.13 for ; Wed, 19 Aug 2009 06:47:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.87.12 with SMTP id x12mr1584787wee.48.1250689671479; Wed, 19 Aug 2009 06:47:51 -0700 (PDT) In-Reply-To: <4A8B0001.8000909@nostrum.com> References: <4A85CECC.3020401@nostrum.com> <4A8AD5F7.9080608@nostrum.com> <4A8B0001.8000909@nostrum.com> Date: Wed, 19 Aug 2009 14:47:51 +0100 Message-ID: From: Michael Procter To: Adam Roach Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] 3265bis Open Issue: Timer N and Resubscribes X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 13:47:56 -0000 2009/8/18 Adam Roach : > Keep in mind that the scenario I described was an attempt to find a > plausible set of circumstances in which the SUBSCRIBE 200 would reliably > arrive at a subscriber, but in which the NOTIFY would consistently fail to > do so. And, in this case, I would argue that the proper behavior is to drop > the subscription (since it's never going to recover). > > Unless we can come up with some other plausible scenario that leads us to a > different conclusion, I would think this is the correct answer in general. Doesn't this lead to an unfortunate interaction with draft-ietf-sipcore-subnot-etags-02, in particular section 6.3 (Suppressing NOTIFY Requests)? Michael From adam@nostrum.com Wed Aug 19 07:32:32 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD19F3A6A82 for ; Wed, 19 Aug 2009 07:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOjh-9Fy2BtC for ; Wed, 19 Aug 2009 07:32:32 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id C5BE43A6908 for ; Wed, 19 Aug 2009 07:32:31 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-149-101.dsl.rcsntx.swbell.net [70.249.149.101]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n7JEWSa1063033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Aug 2009 09:32:33 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A8C0CFC.8090102@nostrum.com> Date: Wed, 19 Aug 2009 09:32:28 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Michael Procter References: <4A85CECC.3020401@nostrum.com> <4A8AD5F7.9080608@nostrum.com> <4A8B0001.8000909@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.149.101 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] 3265bis Open Issue: Timer N and Resubscribes X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 14:32:32 -0000 Michael Procter wrote: > 2009/8/18 Adam Roach : > >> Keep in mind that the scenario I described was an attempt to find a >> plausible set of circumstances in which the SUBSCRIBE 200 would reliably >> arrive at a subscriber, but in which the NOTIFY would consistently fail to >> do so. And, in this case, I would argue that the proper behavior is to drop >> the subscription (since it's never going to recover). >> >> Unless we can come up with some other plausible scenario that leads us to a >> different conclusion, I would think this is the correct answer in general. >> > > Doesn't this lead to an unfortunate interaction with > draft-ietf-sipcore-subnot-etags-02, in particular section 6.3 > (Suppressing NOTIFY Requests)? > > We should definitely include text that indicates that the subscriber doesn't run Timer N when it doesn't expect a NOTIFY -- such as when they receive a 204 response to an in-dialog SUBSCRIBE. /a From AUDET@nortel.com Wed Aug 19 15:55:22 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05A093A6ECD for ; Wed, 19 Aug 2009 15:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.43 X-Spam-Level: X-Spam-Status: No, score=-6.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3p-ey-qyiIAf for ; Wed, 19 Aug 2009 15:55:21 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 05A643A6DEE for ; Wed, 19 Aug 2009 15:55:20 -0700 (PDT) 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 n7JMtM123635; Wed, 19 Aug 2009 22:55:22 GMT 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 Date: Wed, 19 Aug 2009 17:54:16 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F8CE54F@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A82EDEC.1050200@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery Thread-Index: AcobamN2HojOuxx8RveCZjU9IdchCgFtU3xg References: <4A72B495.80407@softarmor.com><4A72E6C5.5070905@cisco.com><1ECE0EB50388174790F9694F77522CCF1F50910C@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D002393AA6@GBNTHT12009MSX.gb002.siemens.net> <4A82EDEC.1050200@softarmor.com> From: "Francois Audet" To: "Dean Willis" , "Ian Elz" Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 22:55:22 -0000 The RFC 4244bis does not allow for "removing" entries for achieving = privacy. Instead, it uses anonymizing (like RFC 3323). The parameters should = therefore not be removed. I guess, one could decide to remove them, just like one could decide to = remove the new field that we could be defining. In other words, I think this is a red herring.=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Wednesday, August 12, 2009 09:30 > To: Ian Elz > Cc: Elwell, John; Audet, Francois (SC100:3055); Christer=20 > Holmberg; SIPCORE; Hadriel Kaplan > Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS=20 > parameter delivery >=20 > Ian Elz wrote: > > All, > >=20 > > Sorry that I am a bit late in this thread but I am catching up. > >=20 > > The UUI may only be applicable to B but there is no way of=20 > knowing if=20 > > it may also be applicable to C following retargeting. This=20 > will depend=20 > > upon the content of the UUI, its purpose and the capabilities of C. > >=20 > > The key issue with trying to pass the UUI as a parameter in H-I is=20 > > Privacy. If A sets Privacy to value 'header' then the H-I entry=20 > > included by the retargeting to the registered terminal=20 > address will be=20 > > removed and will not even be received by B let alone C as=20 > the H-I will=20 > > be removed. > >=20 > > You need to place the UUI in a separate header to ensure that it is=20 > > not removed when the URI is protected by Privacy. >=20 >=20 > So if we assume that 4244bis is our mechanism for passing=20 > parameters from UAC to UAS, then we have to realize that this=20 > completely doesn't work in conjunction with Privacy. >=20 > It seems evident to me that we might want to pass parameters=20 > from UAC to UAS even when we want identity privacy. This=20 > argues against 4244bis being an acceptable solution to the problem. >=20 > -- > Dean >=20 From gao.yang2@zte.com.cn Wed Aug 19 18:47:42 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9229E3A6CBF for ; Wed, 19 Aug 2009 18:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.082 X-Spam-Level: X-Spam-Status: No, score=-98.082 tagged_above=-999 required=5 tests=[AWL=3.756, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrWVGo0AjTpe for ; Wed, 19 Aug 2009 18:47:41 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 287213A6A76 for ; Wed, 19 Aug 2009 18:47:40 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 91101727820181; Thu, 20 Aug 2009 09:31:56 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.100] with StormMail ESMTP id 5479.6396279943; Thu, 20 Aug 2009 09:39:00 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n7K1iZad034816; Thu, 20 Aug 2009 09:44:36 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4A6DA26F.7060205@ericsson.com> To: SIPCORE MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 20 Aug 2009 09:42:57 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-08-20 09:44:34, Serialize complete at 2009-08-20 09:44:34 Content-Type: multipart/alternative; boundary="=_alternative 000983C648257618_=" X-MAIL: mse2.zte.com.cn n7K1iZad034816 Cc: wang.libo@zte.com.cn Subject: [sipcore] Suspending and Resuming modification of session or stream? //New revision of the re-INVITE handling draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 01:47:42 -0000 This is a multipart message in MIME format. --=_alternative 000983C648257618_= Content-Type: text/plain; charset="US-ASCII" Considering a use case, A and B has a audio only session. Then A send a Re-INVITE for adding vedio stream( with precondition) and changing codec or address for audio stream( without preconditon). If suspending is effective for whole session, then streams without precondition should use old parameters while in suspending state. For the use case, A and B should not use new codec or address for audio before vedio's preconditon is met. If suspending is effective for streams with precondition, the then streams without preconditio can use new parameters after first O/A during the Re-INVITE. For the use case, A and B can use new codec or address for audio before vedio's preconditon is met. I prefer the first one, as; 1. To delay using of new parameters for stream without precondition may arose media clip problem. 2. Behavior of streams without precondition should be independent of existence of other streams( with precondition). =================================== Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =================================== -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 000983C648257618_= Content-Type: text/html; charset="US-ASCII"
Considering a use case, A and B has a audio only session. Then A send a Re-INVITE for adding vedio stream( with precondition) and changing codec or address for audio stream( without preconditon).

If suspending is effective for whole session, then streams without precondition should use old parameters while in suspending state.
For the use case, A and B should not use new codec or address for audio before vedio's preconditon is met.

If suspending is effective for streams with precondition, the then streams without preconditio can use new parameters after first O/A during the Re-INVITE.
For the use case, A and B can use new codec or address for audio before vedio's preconditon is met.


I prefer the first one, as;
1. To delay using of new parameters for stream without precondition may arose media clip problem.
2. Behavior of streams without precondition should be independent of existence of other streams( with precondition).

===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
===================================
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 000983C648257618_=-- From dean.willis@softarmor.com Wed Aug 19 21:43:40 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE9EF3A6B8D for ; Wed, 19 Aug 2009 21:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQmsMtSXiFPg for ; Wed, 19 Aug 2009 21:43:40 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id F26A53A69D0 for ; Wed, 19 Aug 2009 21:43:39 -0700 (PDT) Received: from www.softarmor.com (www-data@localhost [127.0.0.1]) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n7K4hIxb017809; Wed, 19 Aug 2009 23:43:18 -0500 Received: from 65.65.155.30 (SquirrelMail authenticated user sipdean) by www.softarmor.com with HTTP; Thu, 20 Aug 2009 04:43:19 -0000 (UTC) Message-ID: In-Reply-To: <4A8B0001.8000909@nostrum.com> References: <4A85CECC.3020401@nostrum.com> <4A8AD5F7.9080608@nostrum.com> <4A8B0001.8000909@nostrum.com> Date: Thu, 20 Aug 2009 04:43:19 -0000 (UTC) From: "Dean Willis" To: "Adam Roach" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: SIPCORE Subject: Re: [sipcore] 3265bis Open Issue: Timer N and Resubscribes X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 04:43:40 -0000 On Tue, August 18, 2009 7:24 pm, Adam Roach wrote: > More to the point: we haven't, in *any* SIP document, gone about > normatively specifying anything about when or how a client determines > which addresses belong to the local machine or then to acquire new > information. > ... > > Keep in mind that the scenario I described was an attempt to find a > plausible set of circumstances in which the SUBSCRIBE 200 would reliably > arrive at a subscriber, but in which the NOTIFY would consistently fail > to do so. And, in this case, I would argue that the proper behavior is > to drop the subscription (since it's never going to recover). > > Unless we can come up with some other plausible scenario that leads us > to a different conclusion, I would think this is the correct answer in > general. What you have here is Yet Another Argument for layering and having a session-level protocol that detects liveness, upon which we would then provide a transactional layer with a fixed set of transaction types, which could then be used for an infinite set of applications. Given that SIP isn't built that way, dropping the subscription on NOTIFY failure seems to be about the best we can do. -- Dean From dean.willis@softarmor.com Wed Aug 19 21:49:50 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A3813A6B5E for ; Wed, 19 Aug 2009 21:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5gmBQy+4PlG for ; Wed, 19 Aug 2009 21:49:45 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id A6DC13A6403 for ; Wed, 19 Aug 2009 21:49:32 -0700 (PDT) Received: from www.softarmor.com (www-data@localhost [127.0.0.1]) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n7K4nNA7017934; Wed, 19 Aug 2009 23:49:25 -0500 Received: from 65.65.155.30 (SquirrelMail authenticated user sipdean) by www.softarmor.com with HTTP; Thu, 20 Aug 2009 04:49:30 -0000 (UTC) Message-ID: <102c59d4c6a59630cb6dd0e49ba42fe0.squirrel@www.softarmor.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F8CE54F@zrc2hxm0.corp.nortel.com> References: <4A72B495.80407@softarmor.com><4A72E6C5.5070905@cisco.com><1ECE0EB50388174790F9694F77522CCF1F50910C@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D002393AA6@GBNTHT12009MSX.gb002.siemens.net> <4A82EDEC.1050200@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1F8CE54F@zrc2hxm0.corp.nortel.com> Date: Thu, 20 Aug 2009 04:49:30 -0000 (UTC) From: "Dean Willis" To: "Francois Audet" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: SIPCORE , Ian Elz Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 04:49:50 -0000 On Wed, August 19, 2009 10:54 pm, Francois Audet wrote: > The RFC 4244bis does not allow for "removing" entries for achieving > privacy. > Instead, it uses anonymizing (like RFC 3323). The parameters should > therefore not > be removed. Are "anonymized" parameters useful? -- Dean From pkyzivat@cisco.com Thu Aug 20 06:01:01 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 498653A635F for ; Thu, 20 Aug 2009 06:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4AkUuFUhqqm for ; Thu, 20 Aug 2009 06:01:00 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 05BDC3A684D for ; Thu, 20 Aug 2009 06:00:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACfmjEpAZnme/2dsb2JhbAC8bYgvkTwFhBiBVA X-IronPort-AV: E=Sophos;i="4.43,414,1246838400"; d="scan'208";a="54837146" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 20 Aug 2009 13:01:03 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7KD126A013642; Thu, 20 Aug 2009 09:01:03 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7KD12R5014924; Thu, 20 Aug 2009 13:01:02 GMT 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.3959); Thu, 20 Aug 2009 09:01:02 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Aug 2009 09:01:02 -0400 Message-ID: <4A8D490D.50600@cisco.com> Date: Thu, 20 Aug 2009 09:01:01 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: gao.yang2@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Aug 2009 13:01:02.0357 (UTC) FILETIME=[4537B450:01CA2196] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2636; t=1250773263; x=1251637263; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20Suspending=20and=20Resuming=20modificat ion=20of=20session=20or=20stream?=20=20=0A=20//New=20revisio n=20of=20the=20re-INVITE=20handling=20draft |Sender:=20 |To:=20gao.yang2@zte.com.cn; bh=tBE9HpBE+Eio9SzE+DkGJqn9H+4vDL1B6YrXZ4gAmdo=; b=MSSJDwkVDHwRZrc942dOXopc0hkqM34WBeDr+BJzGIp+qdzpA7AbGtfUAP Nyi3tyFFFNMgf3zB1S0+reytr6CjMapzgdB2u0DCTftdsoLJnZat9IbGjqf/ 8swElw2y1M; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: SIPCORE , wang.libo@zte.com.cn Subject: Re: [sipcore] Suspending and Resuming modification of session or stream? //New revision of the re-INVITE handling draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 13:01:01 -0000 gao.yang2@zte.com.cn wrote: > > Considering a use case, A and B has a audio only session. Then A send a > Re-INVITE for adding vedio stream( with precondition) and changing codec > or address for audio stream( without preconditon). > > If suspending is effective for whole session, then streams without > precondition should use old parameters while in suspending state. > For the use case, A and B should not use new codec or address for audio > before vedio's preconditon is met. > > If suspending is effective for streams with precondition, the then > streams without preconditio can use new parameters after first O/A > during the Re-INVITE. > For the use case, A and B can use new codec or address for audio before > vedio's preconditon is met. > > > I prefer the first one, as; You mean that you prefer suspension being for the whole session (*all* streams)??? > 1. To delay using of new parameters for stream without precondition may > arose media clip problem. > 2. Behavior of streams without precondition should be independent of > existence of other streams( with precondition). It seems you are arguing in favor of suspension being per-stream. IMO the suspension behavior is defined on a per-stream basis and so needs to be implemented that way. Another reason for this is that it is possible the various streams are not controlled by the same entity, so that coordination of when they take effect could be problematic. If someone wants the changes to multiple streams to take effect together they are free to put preconditions on them all and synchronize the resolution of those preconditions. Thanks, Paul > =================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > =================================== > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > From ian.elz@ericsson.com Thu Aug 20 09:34:58 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04DFD3A6D57 for ; Thu, 20 Aug 2009 09:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0yrFZfdplxo for ; Thu, 20 Aug 2009 09:34:57 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id ECE573A68CD for ; Thu, 20 Aug 2009 09:34:54 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-60-4a8d7b333cb9 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 2A.1B.18827.33B7D8A4; Thu, 20 Aug 2009 18:34:59 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Aug 2009 18:34: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: Thu, 20 Aug 2009 18:34:55 +0200 Message-ID: In-Reply-To: <102c59d4c6a59630cb6dd0e49ba42fe0.squirrel@www.softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery Thread-Index: AcohUZ9c3DbsFF2mSE2TKtgYWTgm/QAYbFeg References: <4A72B495.80407@softarmor.com><4A72E6C5.5070905@cisco.com><1ECE0EB50388174790F9694F77522CCF1F50910C@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D002393AA6@GBNTHT12009MSX.gb002.siemens.net> <4A82EDEC.1050200@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1F8CE54F@zrc2hxm0.corp.nortel.com> <102c59d4c6a59630cb6dd0e49ba42fe0.squirrel@www.softarmor.com> From: "Ian Elz" To: "Dean Willis" , "Francois Audet" X-OriginalArrivalTime: 20 Aug 2009 16:34:57.0126 (UTC) FILETIME=[27560860:01CA21B4] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 16:34:58 -0000 If the parameters are associated with a URI and the URI is anonymize the as Dean stated are the remaining parameters useful? If the parameters are not associated with the specific URI then why are they URI parameters?=20 Is there somewhere which defines anomymizing as just changing the URI and not the associated URI parameters? Is there a possibility that leaving a URI parameter when anonymizing could reveal user information? Ian -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: 20 August 2009 05:50 To: Francois Audet Cc: Dean Willis; Ian Elz; Elwell, John; Christer Holmberg; SIPCORE; Hadriel Kaplan Subject: RE: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery On Wed, August 19, 2009 10:54 pm, Francois Audet wrote: > The RFC 4244bis does not allow for "removing" entries for achieving=20 > privacy. > Instead, it uses anonymizing (like RFC 3323). The parameters should=20 > therefore not be removed. Are "anonymized" parameters useful? -- Dean From gao.yang2@zte.com.cn Thu Aug 20 09:43:19 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7F443A6E28 for ; Thu, 20 Aug 2009 09:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.18 X-Spam-Level: X-Spam-Status: No, score=-94.18 tagged_above=-999 required=5 tests=[AWL=-1.989, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPmS3t1Tl-sK for ; Thu, 20 Aug 2009 09:43:07 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 1E9083A69F6 for ; Thu, 20 Aug 2009 09:43:01 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 111641727820181; Fri, 21 Aug 2009 00:22:33 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.99] with StormMail ESMTP id 49910.6396279943; Fri, 21 Aug 2009 00:33:36 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n7KGhJxE048730; Fri, 21 Aug 2009 00:43:19 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4A8D490D.50600@cisco.com> To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 21 Aug 2009 00:41:53 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-08-21 00:43:01, Serialize complete at 2009-08-21 00:43:01 Content-Type: multipart/alternative; boundary="=_alternative 005BD25448257618_=" X-MAIL: mse1.zte.com.cn n7KGhJxE048730 Cc: SIPCORE , wang.libo@zte.com.cn Subject: [sipcore] =?gb2312?b?tPC4tDogUmU6IFN1c3BlbmRpbmcgYW5kIFJlc3VtaW5n?= =?gb2312?b?IG1vZGlmaWNhdGlvbiBvZiBzZXNzaW9uIG9yIHN0cmVhbT8gICAvL05ldyBy?= =?gb2312?b?ZXZpc2lvbiBvZiB0aGUgcmUtSU5WSVRFIGhhbmRsaW5nIGRyYWZ0?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 16:43:19 -0000 This is a multipart message in MIME format. --=_alternative 005BD25448257618_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgUGF1bCwNCg0KQXMgeW91IGNhbiBzZWUgdGhhdCBpIGFtIGFyZ3VpbmcgaW4gZmF2b3Igb2Yg c3VzcGVuc2lvbiBiZWluZyBwZXItc3RyZWFtIA0KOikuDQpJdCBpcyBhIGNsZXJpY2FsIGVycm9y LiBJIHByZWZlciAic3VzcGVuZGluZyBpcyBlZmZlY3RpdmUgZm9yIHN0cmVhbXMgd2l0aCANCnBy ZWNvbmRpdGlvbiIsIHRoZSAyc3Qgb25lLg0KDQpCdXQgUkZDIDMzMTIgJiA0MDMyIGhhcyBzdWNo IGRlc2NyaXB0aW9uOg0KV2hpbGUgc2Vzc2lvbiBlc3RhYmxpc2htZW50IGlzIHN1c3BlbmRlZChm b3IgUW9TIHR5cGUgcHJlY29uZGl0aW9uKSwgdXNlciANCmFnZW50cyBTSE9VTEQgbm90IHNlbmQg YW55IGRhdGEgb3ZlciBhbnkgbWVkaWEgc3RyZWFtLiAgSW4gdGhlIGNhc2Ugb2YgDQpSVFAsIG5l aXRoZXIgUlRQIG5vciBSVENQIHBhY2tldHMgYXJlIHNlbnQuDQoNClNvLCBkbyB3ZSBuZWVkIGNv cnJlY3Rpb24gZm9yIHRoaXM/DQoNClRoYW5rcy4NCg0KR2FvDQoNCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09DQogWmlwICAgIDogMjEwMDEyDQogVGVsICAgIDogODcyMTENCiBU ZWwyICAgOigrODYpLTAyNS01Mjg3NzIxMQ0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNu DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQoNCg0KUGF1bCBLeXppdmF0 IDxwa3l6aXZhdEBjaXNjby5jb20+IA0KMjAwOS0wOC0yMCAyMTowMQ0KDQrK1bz+yMsNCmdhby55 YW5nMkB6dGUuY29tLmNuDQqzrcvNDQpTSVBDT1JFIDxzaXBjb3JlQGlldGYub3JnPiwgR29uemFs byBDYW1hcmlsbG8gDQo8R29uemFsby5DYW1hcmlsbG9AZXJpY3Nzb24uY29tPiwgQ2hyaXN0ZXIg SG9sbWJlcmcgDQo8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiwgd2FuZy5saWJvQHp0 ZS5jb20uY24NCtb3zOINClJlOiBTdXNwZW5kaW5nIGFuZCBSZXN1bWluZyBtb2RpZmljYXRpb24g b2Ygc2Vzc2lvbiBvciBzdHJlYW0/ICAgLy9OZXcgDQpyZXZpc2lvbiBvZiB0aGUgcmUtSU5WSVRF IGhhbmRsaW5nIGRyYWZ0DQoNCg0KDQoNCg0KDQoNCg0KZ2FvLnlhbmcyQHp0ZS5jb20uY24gd3Jv dGU6DQo+IA0KPiBDb25zaWRlcmluZyBhIHVzZSBjYXNlLCBBIGFuZCBCIGhhcyBhIGF1ZGlvIG9u bHkgc2Vzc2lvbi4gVGhlbiBBIHNlbmQgYSANCj4gUmUtSU5WSVRFIGZvciBhZGRpbmcgdmVkaW8g c3RyZWFtKCB3aXRoIHByZWNvbmRpdGlvbikgYW5kIGNoYW5naW5nIGNvZGVjIA0KDQo+IG9yIGFk ZHJlc3MgZm9yIGF1ZGlvIHN0cmVhbSggd2l0aG91dCBwcmVjb25kaXRvbikuDQo+IA0KPiBJZiBz dXNwZW5kaW5nIGlzIGVmZmVjdGl2ZSBmb3Igd2hvbGUgc2Vzc2lvbiwgdGhlbiBzdHJlYW1zIHdp dGhvdXQgDQo+IHByZWNvbmRpdGlvbiBzaG91bGQgdXNlIG9sZCBwYXJhbWV0ZXJzIHdoaWxlIGlu IHN1c3BlbmRpbmcgc3RhdGUuDQo+IEZvciB0aGUgdXNlIGNhc2UsIEEgYW5kIEIgc2hvdWxkIG5v dCB1c2UgbmV3IGNvZGVjIG9yIGFkZHJlc3MgZm9yIGF1ZGlvIA0KPiBiZWZvcmUgdmVkaW8ncyBw cmVjb25kaXRvbiBpcyBtZXQuDQo+IA0KPiBJZiBzdXNwZW5kaW5nIGlzIGVmZmVjdGl2ZSBmb3Ig c3RyZWFtcyB3aXRoIHByZWNvbmRpdGlvbiwgdGhlIHRoZW4gDQo+IHN0cmVhbXMgd2l0aG91dCBw cmVjb25kaXRpbyBjYW4gdXNlIG5ldyBwYXJhbWV0ZXJzIGFmdGVyIGZpcnN0IE8vQSANCj4gZHVy aW5nIHRoZSBSZS1JTlZJVEUuDQo+IEZvciB0aGUgdXNlIGNhc2UsIEEgYW5kIEIgY2FuIHVzZSBu ZXcgY29kZWMgb3IgYWRkcmVzcyBmb3IgYXVkaW8gYmVmb3JlIA0KPiB2ZWRpbydzIHByZWNvbmRp dG9uIGlzIG1ldC4NCj4gDQo+IA0KPiBJIHByZWZlciB0aGUgZmlyc3Qgb25lLCBhczsNCg0KWW91 IG1lYW4gdGhhdCB5b3UgcHJlZmVyIHN1c3BlbnNpb24gYmVpbmcgZm9yIHRoZSB3aG9sZSBzZXNz aW9uICgqYWxsKiANCnN0cmVhbXMpPz8/DQoNCj4gMS4gVG8gZGVsYXkgdXNpbmcgb2YgbmV3IHBh cmFtZXRlcnMgZm9yIHN0cmVhbSB3aXRob3V0IHByZWNvbmRpdGlvbiBtYXkgDQo+IGFyb3NlIG1l ZGlhIGNsaXAgcHJvYmxlbS4NCj4gMi4gQmVoYXZpb3Igb2Ygc3RyZWFtcyB3aXRob3V0IHByZWNv bmRpdGlvbiBzaG91bGQgYmUgaW5kZXBlbmRlbnQgb2YgDQo+IGV4aXN0ZW5jZSBvZiBvdGhlciBz dHJlYW1zKCB3aXRoIHByZWNvbmRpdGlvbikuDQoNCkl0IHNlZW1zIHlvdSBhcmUgYXJndWluZyBp biBmYXZvciBvZiBzdXNwZW5zaW9uIGJlaW5nIHBlci1zdHJlYW0uDQoNCklNTyB0aGUgc3VzcGVu c2lvbiBiZWhhdmlvciBpcyBkZWZpbmVkIG9uIGEgcGVyLXN0cmVhbSBiYXNpcyBhbmQgc28gDQpu ZWVkcyB0byBiZSBpbXBsZW1lbnRlZCB0aGF0IHdheS4NCg0KQW5vdGhlciByZWFzb24gZm9yIHRo aXMgaXMgdGhhdCBpdCBpcyBwb3NzaWJsZSB0aGUgdmFyaW91cyBzdHJlYW1zIGFyZSANCm5vdCBj b250cm9sbGVkIGJ5IHRoZSBzYW1lIGVudGl0eSwgc28gdGhhdCBjb29yZGluYXRpb24gb2Ygd2hl biB0aGV5IA0KdGFrZSBlZmZlY3QgY291bGQgYmUgcHJvYmxlbWF0aWMuDQoNCklmIHNvbWVvbmUg d2FudHMgdGhlIGNoYW5nZXMgdG8gbXVsdGlwbGUgc3RyZWFtcyB0byB0YWtlIGVmZmVjdCB0b2dl dGhlciANCnRoZXkgYXJlIGZyZWUgdG8gcHV0IHByZWNvbmRpdGlvbnMgb24gdGhlbSBhbGwgYW5k IHN5bmNocm9uaXplIHRoZSANCnJlc29sdXRpb24gb2YgdGhvc2UgcHJlY29uZGl0aW9ucy4NCg0K ICAgICAgICAgICAgICAgICBUaGFua3MsDQogICAgICAgICAgICAgICAgIFBhdWwNCg0KPiA9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPiBaaXAgICAgOiAyMTAwMTINCj4gVGVs ICAgIDogODcyMTENCj4gVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCj4gZV9tYWlsIDogZ2Fv LnlhbmcyQHp0ZS5jb20uY24NCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N Cj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaW4gdGhpcyBtYWlsIA0KaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5k ZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIA0KaXMgY29uZmlkZW50 aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2Vj cmVjeSANCmFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2Yg dGhpcyBjb21tdW5pY2F0aW9uIHRvIA0Kb3RoZXJzLg0KPiBUaGlzIGVtYWlsIGFuZCBhbnkgZmls ZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCANCmludGVuZGVkIHNv bGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5 IGFyZSANCmFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv ciBwbGVhc2Ugbm90aWZ5IHRoZSANCm9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3 cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSANCm9mIHRoZSBpbmRpdmlkdWFs IHNlbmRlci4NCj4gVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5k IFNwYW0gYnkgWlRFIEFudGktU3BhbSANCnN5c3RlbS4NCj4gDQoNCg0KDQoNCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZv cm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhp cyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBU aGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQg YWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1p dHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90 aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBj b25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZp ZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBv ZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRo b3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2Fu bmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 005BD25448257618_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFBhdWwsPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5BcyB5b3UgY2FuIHNlZSB0aGF0 IDwvZm9udD48Zm9udCBzaXplPTI+PHR0PmkNCmFtIGFyZ3VpbmcgaW4gZmF2b3Igb2Ygc3VzcGVu c2lvbiBiZWluZyBwZXItc3RyZWFtIDopLjwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5JdCBpcyBhIGNsZXJpY2FsIGVycm9yLiBJIHByZWZlciAmcXVvdDs8 L2ZvbnQ+PGZvbnQgc2l6ZT0yPjx0dD5zdXNwZW5kaW5nDQppcyBlZmZlY3RpdmUgZm9yIHN0cmVh bXMgd2l0aCBwcmVjb25kaXRpb248L3R0PjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+JnF1b3Q7LA0KdGhlIDJzdCBvbmUuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 Mj48dHQ+QnV0IFJGQyAzMzEyICZhbXA7IDQwMzIgaGFzIHN1Y2ggZGVzY3JpcHRpb246PC90dD48 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5XaGlsZSBzZXNzaW9u IGVzdGFibGlzaG1lbnQgaXMgc3VzcGVuZGVkKGZvcg0KUW9TIHR5cGUgcHJlY29uZGl0aW9uKSwg dXNlciBhZ2VudHMgU0hPVUxEIG5vdCBzZW5kIGFueSBkYXRhIG92ZXIgPGI+YW55DQptZWRpYSBz dHJlYW08L2I+LiAmbmJzcDtJbiB0aGUgY2FzZSBvZiBSVFAsIG5laXRoZXIgUlRQIG5vciBSVENQ IHBhY2tldHMNCmFyZSBzZW50LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i Q291cmllciBOZXciPlNvLCBkbyB3ZSBuZWVkIGNvcnJlY3Rpb24gZm9yIHRoaXM/PC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+VGhhbmtzLjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPkdhbzwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT08YnI+DQogWmlwICZuYnNwOyAmbmJzcDs6IDIxMDAxMjxicj4NCiBU ZWwgJm5ic3A7ICZuYnNwOzogODcyMTE8YnI+DQogVGVsMiAmbmJzcDsgOigrODYpLTAyNS01Mjg3 NzIxMTxicj4NCiBlX21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbjxicj4NCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxl IHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0yNiU+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPjxiPlBhdWwgS3l6aXZhdCAmbHQ7cGt5eml2YXRAY2lzY28uY29t Jmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDA5 LTA4LTIwIDIxOjAxPC9mb250Pg0KPHRkIHdpZHRoPTczJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0K PHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPmdhby55YW5nMkB6dGUuY29tLmNuPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6z rcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5TSVBD T1JFICZsdDtzaXBjb3JlQGlldGYub3JnJmd0OywgR29uemFsbw0KQ2FtYXJpbGxvICZsdDtHb256 YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5jb20mZ3Q7LCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7Y2hy aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0OywNCndhbmcubGlib0B6dGUuY29tLmNuPC9m b250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj5SZTogU3VzcGVuZGluZyBhbmQgUmVzdW1pbmcgbW9kaWZpY2F0aW9u DQpvZiBzZXNzaW9uIG9yIHN0cmVhbT8gJm5ic3A7IC8vTmV3IHJldmlzaW9uIG9mIHRoZSByZS1J TlZJVEUgaGFuZGxpbmcgZHJhZnQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4N Cjxicj48Zm9udCBzaXplPTI+PHR0Pjxicj4NCjxicj4NCmdhby55YW5nMkB6dGUuY29tLmNuIHdy b3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyBDb25zaWRlcmluZyBhIHVzZSBjYXNlLCBBIGFuZCBC IGhhcyBhIGF1ZGlvIG9ubHkgc2Vzc2lvbi4gVGhlbiBBIHNlbmQNCmEgPGJyPg0KJmd0OyBSZS1J TlZJVEUgZm9yIGFkZGluZyB2ZWRpbyBzdHJlYW0oIHdpdGggcHJlY29uZGl0aW9uKSBhbmQgY2hh bmdpbmcNCmNvZGVjIDxicj4NCiZndDsgb3IgYWRkcmVzcyBmb3IgYXVkaW8gc3RyZWFtKCB3aXRo b3V0IHByZWNvbmRpdG9uKS48YnI+DQomZ3Q7IDxicj4NCiZndDsgSWYgc3VzcGVuZGluZyBpcyBl ZmZlY3RpdmUgZm9yIHdob2xlIHNlc3Npb24sIHRoZW4gc3RyZWFtcyB3aXRob3V0DQo8YnI+DQom Z3Q7IHByZWNvbmRpdGlvbiBzaG91bGQgdXNlIG9sZCBwYXJhbWV0ZXJzIHdoaWxlIGluIHN1c3Bl bmRpbmcgc3RhdGUuPGJyPg0KJmd0OyBGb3IgdGhlIHVzZSBjYXNlLCBBIGFuZCBCIHNob3VsZCBu b3QgdXNlIG5ldyBjb2RlYyBvciBhZGRyZXNzIGZvcg0KYXVkaW8gPGJyPg0KJmd0OyBiZWZvcmUg dmVkaW8ncyBwcmVjb25kaXRvbiBpcyBtZXQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IElmIHN1c3Bl bmRpbmcgaXMgZWZmZWN0aXZlIGZvciBzdHJlYW1zIHdpdGggcHJlY29uZGl0aW9uLCB0aGUgdGhl bg0KPGJyPg0KJmd0OyBzdHJlYW1zIHdpdGhvdXQgcHJlY29uZGl0aW8gY2FuIHVzZSBuZXcgcGFy YW1ldGVycyBhZnRlciBmaXJzdCBPL0ENCjxicj4NCiZndDsgZHVyaW5nIHRoZSBSZS1JTlZJVEUu PGJyPg0KJmd0OyBGb3IgdGhlIHVzZSBjYXNlLCBBIGFuZCBCIGNhbiB1c2UgbmV3IGNvZGVjIG9y IGFkZHJlc3MgZm9yIGF1ZGlvIGJlZm9yZQ0KPGJyPg0KJmd0OyB2ZWRpbydzIHByZWNvbmRpdG9u IGlzIG1ldC48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBJIHByZWZlciB0aGUgZmly c3Qgb25lLCBhczs8YnI+DQo8YnI+DQpZb3UgbWVhbiB0aGF0IHlvdSBwcmVmZXIgc3VzcGVuc2lv biBiZWluZyBmb3IgdGhlIHdob2xlIHNlc3Npb24gKCphbGwqDQo8YnI+DQpzdHJlYW1zKT8/Pzxi cj4NCjxicj4NCiZndDsgMS4gVG8gZGVsYXkgdXNpbmcgb2YgbmV3IHBhcmFtZXRlcnMgZm9yIHN0 cmVhbSB3aXRob3V0IHByZWNvbmRpdGlvbg0KbWF5IDxicj4NCiZndDsgYXJvc2UgbWVkaWEgY2xp cCBwcm9ibGVtLjxicj4NCiZndDsgMi4gQmVoYXZpb3Igb2Ygc3RyZWFtcyB3aXRob3V0IHByZWNv bmRpdGlvbiBzaG91bGQgYmUgaW5kZXBlbmRlbnQNCm9mIDxicj4NCiZndDsgZXhpc3RlbmNlIG9m IG90aGVyIHN0cmVhbXMoIHdpdGggcHJlY29uZGl0aW9uKS48YnI+DQo8YnI+DQpJdCBzZWVtcyB5 b3UgYXJlIGFyZ3VpbmcgaW4gZmF2b3Igb2Ygc3VzcGVuc2lvbiBiZWluZyBwZXItc3RyZWFtLjxi cj4NCjxicj4NCklNTyB0aGUgc3VzcGVuc2lvbiBiZWhhdmlvciBpcyBkZWZpbmVkIG9uIGEgcGVy LXN0cmVhbSBiYXNpcyBhbmQgc28gPGJyPg0KbmVlZHMgdG8gYmUgaW1wbGVtZW50ZWQgdGhhdCB3 YXkuPGJyPg0KPGJyPg0KQW5vdGhlciByZWFzb24gZm9yIHRoaXMgaXMgdGhhdCBpdCBpcyBwb3Nz aWJsZSB0aGUgdmFyaW91cyBzdHJlYW1zIGFyZQ0KPGJyPg0Kbm90IGNvbnRyb2xsZWQgYnkgdGhl IHNhbWUgZW50aXR5LCBzbyB0aGF0IGNvb3JkaW5hdGlvbiBvZiB3aGVuIHRoZXkgPGJyPg0KdGFr ZSBlZmZlY3QgY291bGQgYmUgcHJvYmxlbWF0aWMuPGJyPg0KPGJyPg0KSWYgc29tZW9uZSB3YW50 cyB0aGUgY2hhbmdlcyB0byBtdWx0aXBsZSBzdHJlYW1zIHRvIHRha2UgZWZmZWN0IHRvZ2V0aGVy DQo8YnI+DQp0aGV5IGFyZSBmcmVlIHRvIHB1dCBwcmVjb25kaXRpb25zIG9uIHRoZW0gYWxsIGFu ZCBzeW5jaHJvbml6ZSB0aGUgPGJyPg0KcmVzb2x1dGlvbiBvZiB0aG9zZSBwcmVjb25kaXRpb25z Ljxicj4NCjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQpUaGFua3MsPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNClBhdWw8YnI+DQo8YnI+DQomZ3Q7ID09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KJmd0OyBaaXAgJm5ic3A7ICZuYnNwOzog MjEwMDEyPGJyPg0KJmd0OyBUZWwgJm5ic3A7ICZuYnNwOzogODcyMTE8YnI+DQomZ3Q7IFRlbDIg Jm5ic3A7IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+DQomZ3Q7IGVfbWFpbCA6IGdhby55YW5nMkB6 dGUuY29tLmNuPGJyPg0KJmd0OyA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxi cj4NCiZndDsgPGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5v dGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzDQptYWlsIGlzIHNvbGVseSBw cm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNh dGlvbg0KaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0 ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeQ0KYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3Nl IHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8NCm90aGVycy48YnI+DQomZ3Q7 IFRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRl bnRpYWwgYW5kDQppbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwg b3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUNCmFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yDQpvZiB0 aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3Nl IG9mIHRoZSBpbmRpdmlkdWFsDQpzZW5kZXIuPGJyPg0KJmd0OyBUaGlzIG1lc3NhZ2UgaGFzIGJl ZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtDQpzeXN0ZW0u PGJyPg0KJmd0OyA8YnI+DQo8YnI+DQo8L3R0PjwvZm9udD4NCjxicj4NCjxicj48cHJlPg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpU RSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5i c3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWls Jm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7 c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21t dW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNw O25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21h aW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1p dHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29m Jm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMm bmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQm bmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJz cDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29m Jm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJz cDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lv dSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5i c3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9y Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7 ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Ro b3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZu YnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNw O3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNw YW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 005BD25448257618_=-- From jmpolk@cisco.com Thu Aug 20 09:47:37 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B49423A6B46 for ; Thu, 20 Aug 2009 09:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5J5Lm-uojn-G for ; Thu, 20 Aug 2009 09:47:36 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id DB05F3A6B8E for ; Thu, 20 Aug 2009 09:47:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsMFAJcbjUqrR7O6/2dsb2JhbACIX7ZUiC+RIAWEGA X-IronPort-AV: E=Sophos;i="4.43,415,1246838400"; d="scan'208";a="371550021" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 20 Aug 2009 16:47:42 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7KGlguu012840; Thu, 20 Aug 2009 09:47:42 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7KGlg4x008907; Thu, 20 Aug 2009 16:47:42 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Aug 2009 09:47:42 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.8.70]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Aug 2009 09:47:41 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 20 Aug 2009 11:47:39 -0500 To: "Dean Willis" , "Adam Roach" From: "James M. Polk" In-Reply-To: References: <4A85CECC.3020401@nostrum.com> <4A8AD5F7.9080608@nostrum.com> <4A8B0001.8000909@nostrum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 20 Aug 2009 16:47:41.0853 (UTC) FILETIME=[EF261CD0:01CA21B5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1639; t=1250786862; x=1251650862; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[sipcore]=203265bis=20Open=20Issue=3A=2 0Timer=20N=20and=20Resubscribes |Sender:=20; bh=jPoTvPTRuzN8CFtUgpYN4Sht+7oOiF0OkBWKWxknQ7I=; b=W6LOFEeCIZYrjqR7kJfDoy9TX357Bmgd3/W78dRjUtoHXqk4bjOoqsQrbE ATPcsTDQgoTI3fo8dw9gHP/ZYx/x9HFLdsPrdkPerBjSycEp3mY3xsYXrLjD c8TKGH1M4r; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: SIPCORE Subject: Re: [sipcore] 3265bis Open Issue: Timer N and Resubscribes X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 16:47:37 -0000 At 11:43 PM 8/19/2009, Dean Willis wrote: >On Tue, August 18, 2009 7:24 pm, Adam Roach wrote: > > > More to the point: we haven't, in *any* SIP document, gone about > > normatively specifying anything about when or how a client determines > > which addresses belong to the local machine or then to acquire new > > information. > > >... > > > > Keep in mind that the scenario I described was an attempt to find a > > plausible set of circumstances in which the SUBSCRIBE 200 would reliably > > arrive at a subscriber, but in which the NOTIFY would consistently fail > > to do so. And, in this case, I would argue that the proper behavior is > > to drop the subscription (since it's never going to recover). > > > > Unless we can come up with some other plausible scenario that leads us > > to a different conclusion, I would think this is the correct answer in > > general. > >What you have here is Yet Another Argument for layering and having a >session-level protocol that detects liveness, upon which we would then >provide a transactional layer with a fixed set of transaction types, which >could then be used for an infinite set of applications. > >Given that SIP isn't built that way, dropping the subscription on NOTIFY >failure seems to be about the best we can do. I'm curious how often anyone thinks this scenario will (not can) occur? i.e., are there any complaints by vendors saying effectively "we code to the spec, yet this scenario still occurs (X often) and we need it fixed"... (presumably the operators would be complaining to their vendors for bad user experiences) >-- >Dean From AUDET@nortel.com Thu Aug 20 09:49:27 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E0683A6A4D for ; Thu, 20 Aug 2009 09:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.436 X-Spam-Level: X-Spam-Status: No, score=-6.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7KAlLg0s2Oh for ; Thu, 20 Aug 2009 09:49:26 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 92A553A6D57 for ; Thu, 20 Aug 2009 09:49:05 -0700 (PDT) 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 n7KGl1g19755; Thu, 20 Aug 2009 16:47:02 GMT 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 Date: Thu, 20 Aug 2009 11:48:49 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F8CEE61@zrc2hxm0.corp.nortel.com> In-Reply-To: <102c59d4c6a59630cb6dd0e49ba42fe0.squirrel@www.softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery Thread-Index: AcohUaE22CBewPrqTyWR1aJvnjgT5gAY1/Dw References: <4A72B495.80407@softarmor.com><4A72E6C5.5070905@cisco.com><1ECE0EB50388174790F9694F77522CCF1F50910C@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D002393AA6@GBNTHT12009MSX.gb002.siemens.net> <4A82EDEC.1050200@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1F8CE54F@zrc2hxm0.corp.nortel.com> <102c59d4c6a59630cb6dd0e49ba42fe0.squirrel@www.softarmor.com> From: "Francois Audet" To: "Dean Willis" Cc: Ian Elz , SIPCORE Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 16:49:27 -0000 They may or may not. In this particular case, they should be useful because of the semantics = of UUI (i.e., not associated with URI in any way shape or form). However, since SIP introduces things like forking and lots of = redirection for routing, the parameters may not be understandable by the far end. = IMHO, UUI has a very narrow window of usefulness, i.e., for retrofitting = legacy=20 applications in very controlled environsment. When normal SIP forking = and=20 routing applies, with "normal" SIP endpoints, it won't work. The beauty of all the possible mechanisms considered for UUI is that while there = will be more and more cases where "it won't work" (i.e., the UUI will not be = useful), none of them break anything (at least in theory). In the case of using URI = parameters (we shouldn't call it RFC 4244bis since that's not what it is: it's = really=20 using URI parameters), the parameters are ingnored.=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Wednesday, August 19, 2009 21:50 > To: Audet, Francois (SC100:3055) > Cc: Dean Willis; Ian Elz; Elwell, John; Christer Holmberg;=20 > SIPCORE; Hadriel Kaplan > Subject: RE: [sipcore] RFC 4244 bis use cases and UAC->UAS=20 > parameter delivery >=20 > On Wed, August 19, 2009 10:54 pm, Francois Audet wrote: > > The RFC 4244bis does not allow for "removing" entries for achieving=20 > > privacy. > > Instead, it uses anonymizing (like RFC 3323). The parameters should=20 > > therefore not be removed. >=20 > Are "anonymized" parameters useful? >=20 > -- > Dean >=20 >=20 >=20 From pkyzivat@cisco.com Thu Aug 20 11:59:55 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FC433A6781 for ; Thu, 20 Aug 2009 11:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-3.895, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_93=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z73LuK+dm408 for ; Thu, 20 Aug 2009 11:59:54 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 456A83A6BA0 for ; Thu, 20 Aug 2009 11:59:38 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAA86jUqrR7PD/2dsb2JhbAC/N4ZngUiRDwWBLoELgRhHgVRT X-IronPort-AV: E=Sophos;i="4.43,415,1246838400"; d="scan'208";a="371647383" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 20 Aug 2009 18:59:43 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7KIxh74007363; Thu, 20 Aug 2009 11:59:43 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7KIxhge024662; Thu, 20 Aug 2009 18:59:43 GMT 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.3959); Thu, 20 Aug 2009 14:59:32 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Aug 2009 14:59:31 -0400 Message-ID: <4A8D9D14.3010904@cisco.com> Date: Thu, 20 Aug 2009 14:59:32 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: gao.yang2@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 20 Aug 2009 18:59:31.0803 (UTC) FILETIME=[59D8B2B0:01CA21C8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5158; t=1250794783; x=1251658783; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20=3D?GB2312?B?tPC4tDogUmU6IFN1c3BlbmRpbm cgYW5kIFJlc3VtaW5nIG1vZA=3D=3D?=3D=0A=20=3D?GB2312?B?aWZpY2F 0aW9uIG9mIHNlc3Npb24gb3Igc3RyZWFtPyAgIC8vTmV3IHJldmlzaQ=3D=3 D?=3D=0A=20=3D?GB2312?B?b24gb2YgdGhlIHJlLUlOVklURSBoYW5kbGlu ZyBkcmFmdA=3D=3D?=3D |Sender:=20; bh=HEKA6xgSHjYuf5FQ686rhIcM9LoWh1SJTxi0rHxaPE8=; b=USRj1dF993SFWPX8nG7FY2ukzrS76y34so6FvRDbuzxVrWoZr+siHt2gA9 zByvTonKspKGeCbqsOOtqPfQ2t1jxqxfpR0TvPU4l3ce3bL8b55PP+K2UySk 9kMrY0eJ6r; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: SIPCORE , wang.libo@zte.com.cn Subject: Re: [sipcore] =?gb2312?b?tPC4tDogUmU6IFN1c3BlbmRpbmcgYW5kIFJlc3VtaW5n?= =?gb2312?b?IG1vZGlmaWNhdGlvbiBvZiBzZXNzaW9uIG9yIHN0cmVhbT8gICAvL05ldyBy?= =?gb2312?b?ZXZpc2lvbiBvZiB0aGUgcmUtSU5WSVRFIGhhbmRsaW5nIGRyYWZ0?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 18:59:55 -0000 gao.yang2@zte.com.cn wrote: > > Hi Paul, > > As you can see that i am arguing in favor of suspension being per-stream > :). > It is a clerical error. I prefer "suspending is effective for streams > with precondition", the 2st one. > > But RFC 3312 & 4032 has such description: > While session establishment is suspended(for QoS type precondition), > user agents SHOULD not send any data over *any media stream*. In the > case of RTP, neither RTP nor RTCP packets are sent. > > So, do we need correction for this? I haven't thought about it a lot, but my immediate reaction is *yes*, this doesn't seem right. I would like to hear what Gonzalo thinks. In the writing of 4032, I think the focus here was on narrowing the scope of this limitation, so that it applied only to QoS and not other precondition types. I don't think ay consideration was given to Thanks, Paul > Thanks. > > Gao > > =================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > =================================== > > > *Paul Kyzivat * > > 2009-08-20 21:01 > > > 收件人 > gao.yang2@zte.com.cn > 抄送 > SIPCORE , Gonzalo Camarillo > , Christer Holmberg > , wang.libo@zte.com.cn > 主题 > Re: Suspending and Resuming modification of session or stream? //New > revision of the re-INVITE handling draft > > > > > > > > > > > gao.yang2@zte.com.cn wrote: > > > > Considering a use case, A and B has a audio only session. Then A send a > > Re-INVITE for adding vedio stream( with precondition) and changing codec > > or address for audio stream( without preconditon). > > > > If suspending is effective for whole session, then streams without > > precondition should use old parameters while in suspending state. > > For the use case, A and B should not use new codec or address for audio > > before vedio's preconditon is met. > > > > If suspending is effective for streams with precondition, the then > > streams without preconditio can use new parameters after first O/A > > during the Re-INVITE. > > For the use case, A and B can use new codec or address for audio before > > vedio's preconditon is met. > > > > > > I prefer the first one, as; > > You mean that you prefer suspension being for the whole session (*all* > streams)??? > > > 1. To delay using of new parameters for stream without precondition may > > arose media clip problem. > > 2. Behavior of streams without precondition should be independent of > > existence of other streams( with precondition). > > It seems you are arguing in favor of suspension being per-stream. > > IMO the suspension behavior is defined on a per-stream basis and so > needs to be implemented that way. > > Another reason for this is that it is possible the various streams are > not controlled by the same entity, so that coordination of when they > take effect could be problematic. > > If someone wants the changes to multiple streams to take effect together > they are free to put preconditions on them all and synchronize the > resolution of those preconditions. > > Thanks, > Paul > > > =================================== > > Zip : 210012 > > Tel : 87211 > > Tel2 :(+86)-025-52877211 > > e_mail : gao.yang2@zte.com.cn > > =================================== > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this > mail is solely property of the sender's organization. This mail > communication is confidential. Recipients named above are obligated to > maintain secrecy and are not permitted to disclose the contents of this > communication to others. > > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they are > addressed. If you have received this email in error please notify the > originator of the message. Any views expressed in this message are those > of the individual sender. > > This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. > > > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. From AUDET@nortel.com Thu Aug 20 16:37:36 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27AE73A6C16 for ; Thu, 20 Aug 2009 16:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.441 X-Spam-Level: X-Spam-Status: No, score=-6.441 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95FzAo2KL+Tr for ; Thu, 20 Aug 2009 16:37:35 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 1584A3A6B95 for ; Thu, 20 Aug 2009 16:37:34 -0700 (PDT) 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 n7KNbXu15818; Thu, 20 Aug 2009 23:37:34 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA21EF.19015425" Date: Thu, 20 Aug 2009 18:36:52 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F917C0B@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Outbound and simultaneous registration transactions Thread-Index: AcoY5svUG52kXhW9S7m0XzwvAdgeRAJCEdaQ References: From: "Francois Audet" To: "Christer Holmberg" , "SIPCORE" Subject: Re: [sipcore] Outbound and simultaneous registration transactions X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 23:37:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA21EF.19015425 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I believe you are correct. ________________________________ From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Sunday, August 09, 2009 04:45 To: SIPCORE Cc: Audet, Francois (SC100:3055) Subject: Outbound and simultaneous registration transactions =09 =09 Hi outbound lovers,=20 Section 10.2 of RFC 3261 says:=20 "UAs MUST NOT send a new registration (that is, containing new Contact=20 header field values, as opposed to a retransmission) until they have=20 received a final response from the registrar for the previous one or=20 the previous REGISTER request has timed out."=20 Q1: I don't find any text in the outbound spec which would allow = sending new registrations for the SAME Contact header value until a = response has been received from the previous register (or the prevoius = has timed out). So, my assumption is that the = only-one-register-transaction-at-a-time rule also applies to outbound, = or? Section 6 of outbound says:=20 "The registrar MUST be prepared to receive, simultaneously for the same = AOR, some registrations that use instance-id and reg-id and some = registrations that do not." I assume "simultaneously" doesn't refer to simultaneous registration = transactions, but simultaneus valid registrations.=20 Regards,=20 Christer=20 ------_=_NextPart_001_01CA21EF.19015425 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Outbound and simultaneous registration = transactions
I=20 believe you are correct.

From: Christer Holmberg=20 [mailto:christer.holmberg@ericsson.com]
Sent: Sunday, = August 09,=20 2009 04:45
To: SIPCORE
Cc: Audet, Francois=20 (SC100:3055)
Subject: Outbound and simultaneous registration = transactions


Hi outbound lovers,

Section 10.2 of RFC 3261 says: =

"UAs MUST NOT send a new registration = (that is,=20 containing new Contact
header = field values,=20 as opposed to a retransmission) until they have
received a final response from the registrar for the previous = one=20 or
the previous REGISTER = request has timed=20 out."


Q1: I don't find any text in the = outbound spec=20 which would allow sending new registrations for the SAME Contact = header value=20 until a response has been received from the previous register (or the = prevoius=20 has timed out). So, my assumption is that the=20 only-one-register-transaction-at-a-time rule also applies to outbound, = or?


Section 6 of outbound says:

"The registrar MUST be prepared to = receive,=20 simultaneously for the same AOR, some registrations that use = instance-id and=20 reg-id and some registrations that do not."

I assume "simultaneously" doesn't refer = to=20 simultaneous registration transactions, but simultaneus valid = registrations.=20

Regards,

Christer =

------_=_NextPart_001_01CA21EF.19015425-- From gao.yang2@zte.com.cn Thu Aug 20 17:09:25 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C8563A677E for ; Thu, 20 Aug 2009 17:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.884 X-Spam-Level: X-Spam-Status: No, score=-93.884 tagged_above=-999 required=5 tests=[AWL=-1.694, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvFEujnCGLf2 for ; Thu, 20 Aug 2009 17:09:24 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 785AB3A6969 for ; Thu, 20 Aug 2009 17:08:56 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 91101727820181; Fri, 21 Aug 2009 07:53:30 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.99] with StormMail ESMTP id 49910.6396279943; Fri, 21 Aug 2009 07:59:32 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n7L08sH4096954; Fri, 21 Aug 2009 08:08:54 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4A8D9D14.3010904@cisco.com> To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 21 Aug 2009 08:07:45 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-08-21 08:08:53, Serialize complete at 2009-08-21 08:08:53 Content-Type: multipart/alternative; boundary="=_alternative 0000CE5848257619_=" X-MAIL: mse2.zte.com.cn n7L08sH4096954 Cc: SIPCORE , wang.libo@zte.com.cn Subject: [sipcore] =?gb2312?b?tPC4tDogUmU6ILTwuLQ6IFJlOiBTdXNwZW5kaW5nIGFu?= =?gb2312?b?ZCBSZXN1bWluZyBtb2RpZmljYXRpb24gb2Ygc2Vzc2lvbiBvciBzdHJlYW0/?= =?gb2312?b?ICAgLy9OZXcgcmV2aXNpb24gb2YgdGhlIHJlLUlOVklURSBoYW5kbGluZyBk?= =?gb2312?b?cmFmdA==?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 00:09:25 -0000 This is a multipart message in MIME format. --=_alternative 0000CE5848257619_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 UGF1bCBLeXppdmF0IDxwa3l6aXZhdEBjaXNjby5jb20+INC009ogMjAwOS0wOC0yMSAwMjo1OToz MjoNCg0KPiANCj4gDQo+IGdhby55YW5nMkB6dGUuY29tLmNuIHdyb3RlOg0KPiA+IA0KPiA+IEhp IFBhdWwsDQo+ID4gDQo+ID4gQXMgeW91IGNhbiBzZWUgdGhhdCBpIGFtIGFyZ3VpbmcgaW4gZmF2 b3Igb2Ygc3VzcGVuc2lvbiBiZWluZyANCnBlci1zdHJlYW0gDQo+ID4gOikuDQo+ID4gSXQgaXMg YSBjbGVyaWNhbCBlcnJvci4gSSBwcmVmZXIgInN1c3BlbmRpbmcgaXMgZWZmZWN0aXZlIGZvciBz dHJlYW1zIA0KPiA+IHdpdGggcHJlY29uZGl0aW9uIiwgdGhlIDJzdCBvbmUuDQo+ID4gDQo+ID4g QnV0IFJGQyAzMzEyICYgNDAzMiBoYXMgc3VjaCBkZXNjcmlwdGlvbjoNCj4gPiBXaGlsZSBzZXNz aW9uIGVzdGFibGlzaG1lbnQgaXMgc3VzcGVuZGVkKGZvciBRb1MgdHlwZSBwcmVjb25kaXRpb24p LCANCj4gPiB1c2VyIGFnZW50cyBTSE9VTEQgbm90IHNlbmQgYW55IGRhdGEgb3ZlciAqYW55IG1l ZGlhIHN0cmVhbSouICBJbiB0aGUgDQo+ID4gY2FzZSBvZiBSVFAsIG5laXRoZXIgUlRQIG5vciBS VENQIHBhY2tldHMgYXJlIHNlbnQuDQo+ID4gDQo+ID4gU28sIGRvIHdlIG5lZWQgY29ycmVjdGlv biBmb3IgdGhpcz8NCj4gDQo+IEkgaGF2ZW4ndCB0aG91Z2h0IGFib3V0IGl0IGEgbG90LCBidXQg bXkgaW1tZWRpYXRlIHJlYWN0aW9uIGlzICp5ZXMqLA0KPiB0aGlzIGRvZXNuJ3Qgc2VlbSByaWdo dC4gSSB3b3VsZCBsaWtlIHRvIGhlYXIgd2hhdCBHb256YWxvIHRoaW5rcy4NCj4gDQoNCkknZCBs aWtlIHRvIGhlYXIgR29uemFsbydzIHBvaW50cyB0b28uIEJ1dCBJIHJlbWVtYmVyIHRoYXQgaGUg c2FpZCB0aGF0IGhlIA0Kd2lsbCBnZXQgYmFjayB0byBvZmZpY2Ugb24gU2VwdGVtYmVyIDFzdC4N ClBlcmhhcHMgaGUgY2FuIG9ubHkgc2hvdyBoaXMgaWRlYSB0aGVuLg0KDQo+IEluIHRoZSB3cml0 aW5nIG9mIDQwMzIsIEkgdGhpbmsgdGhlIGZvY3VzIGhlcmUgd2FzIG9uIG5hcnJvd2luZyB0aGUN Cj4gc2NvcGUgb2YgdGhpcyBsaW1pdGF0aW9uLCBzbyB0aGF0IGl0IGFwcGxpZWQgb25seSB0byBR b1MgYW5kIG5vdCBvdGhlcg0KPiBwcmVjb25kaXRpb24gdHlwZXMuIA0KDQpZZXMsIGl0IGlzIG5l ZWRmdWwgdG8gbmFycm93IHRoZSBzY29wZSBvZiB0aGlzIGxpbWl0YXRpb24gZm9yIG90aGVyIA0K cHJlY29uZGl0aW9uIHR5cGUgYmV5b25kIFFvUyB0eXBlLg0KDQo+IEkgZG9uJ3QgdGhpbmsgYXkg Y29uc2lkZXJhdGlvbiB3YXMgZ2l2ZW4gdG8NCg0KSSBjYW4ndCBjYXRjaCB0aGlzIHNlbnRlbmNl LiBXaGF0J3MgdGhlIG1lYW5pbmcgb2YgImF5IGNvbnNpZGVyYXRpb24iPw0KDQoNCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQogWmlwICAgIDogMjEwMDEyDQogVGVsICAgIDog ODcyMTENCiBUZWwyICAgOigrODYpLTAyNS01Mjg3NzIxMQ0KIGVfbWFpbCA6IGdhby55YW5nMkB6 dGUuY29tLmNuDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUg SW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlu IHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlv bi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5h bWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBw ZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0 byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBh cmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGlu ZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0 b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFy ZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4g c2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 0000CE5848257619_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5QYXVsIEt5eml2YXQgJmx0O3BreXppdmF0QGNp c2NvLmNvbSZndDsg0LTT2iAyMDA5LTA4LTIxDQowMjo1OTozMjo8YnI+DQo8YnI+DQomZ3Q7IDxi cj4NCiZndDsgPGJyPg0KJmd0OyBnYW8ueWFuZzJAenRlLmNvbS5jbiB3cm90ZTo8YnI+DQomZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEhpIFBhdWwsPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyBBcyB5b3UgY2FuIHNlZSB0aGF0IGkgYW0gYXJndWluZyBpbiBmYXZvciBvZiBzdXNwZW5z aW9uIGJlaW5nDQpwZXItc3RyZWFtIDxicj4NCiZndDsgJmd0OyA6KS48YnI+DQomZ3Q7ICZndDsg SXQgaXMgYSBjbGVyaWNhbCBlcnJvci4gSSBwcmVmZXIgJnF1b3Q7c3VzcGVuZGluZyBpcyBlZmZl Y3RpdmUNCmZvciBzdHJlYW1zIDxicj4NCiZndDsgJmd0OyB3aXRoIHByZWNvbmRpdGlvbiZxdW90 OywgdGhlIDJzdCBvbmUuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBCdXQgUkZDIDMz MTIgJmFtcDsgNDAzMiBoYXMgc3VjaCBkZXNjcmlwdGlvbjo8YnI+DQomZ3Q7ICZndDsgV2hpbGUg c2Vzc2lvbiBlc3RhYmxpc2htZW50IGlzIHN1c3BlbmRlZChmb3IgUW9TIHR5cGUgcHJlY29uZGl0 aW9uKSwNCjxicj4NCiZndDsgJmd0OyB1c2VyIGFnZW50cyBTSE9VTEQgbm90IHNlbmQgYW55IGRh dGEgb3ZlciAqYW55IG1lZGlhIHN0cmVhbSouDQombmJzcDtJbiB0aGUgPGJyPg0KJmd0OyAmZ3Q7 IGNhc2Ugb2YgUlRQLCBuZWl0aGVyIFJUUCBub3IgUlRDUCBwYWNrZXRzIGFyZSBzZW50Ljxicj4N CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgU28sIGRvIHdlIG5lZWQgY29ycmVjdGlvbiBmb3Ig dGhpcz88YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBoYXZlbid0IHRob3VnaHQgYWJvdXQgaXQgYSBs b3QsIGJ1dCBteSBpbW1lZGlhdGUgcmVhY3Rpb24gaXMgKnllcyosPGJyPg0KJmd0OyB0aGlzIGRv ZXNuJ3Qgc2VlbSByaWdodC4gSSB3b3VsZCBsaWtlIHRvIGhlYXIgd2hhdCBHb256YWxvIHRoaW5r cy48YnI+DQomZ3Q7IDwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+SSdk IGxpa2UgdG8gaGVhciBHb256YWxvJ3MgcG9pbnRzIHRvby4gQnV0IEkgcmVtZW1iZXINCnRoYXQg aGUgc2FpZCB0aGF0IGhlIHdpbGwgZ2V0IGJhY2sgdG8gb2ZmaWNlIG9uIFNlcHRlbWJlciAxc3Qu PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5QZXJoYXBzIGhlIGNhbiBvbmx5IHNo b3cgaGlzIGlkZWEgdGhlbi48L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0Pjxicj4N CiZndDsgSW4gdGhlIHdyaXRpbmcgb2YgNDAzMiwgSSB0aGluayB0aGUgZm9jdXMgaGVyZSB3YXMg b24gbmFycm93aW5nIHRoZTxicj4NCiZndDsgc2NvcGUgb2YgdGhpcyBsaW1pdGF0aW9uLCBzbyB0 aGF0IGl0IGFwcGxpZWQgb25seSB0byBRb1MgYW5kIG5vdCBvdGhlcjxicj4NCiZndDsgcHJlY29u ZGl0aW9uIHR5cGVzLiA8L3R0PjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0Plll cywgaXQgaXMgbmVlZGZ1bCB0byBuYXJyb3cgdGhlIHNjb3BlIG9mIHRoaXMgbGltaXRhdGlvbg0K Zm9yIG90aGVyIHByZWNvbmRpdGlvbiB0eXBlIGJleW9uZCBRb1MgdHlwZS48L3R0PjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgSSBkb24ndCB0aGluayBheSBjb25zaWRl cmF0aW9uIHdhcyBnaXZlbiB0bzwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48 dHQ+SSBjYW4ndCBjYXRjaCB0aGlzIHNlbnRlbmNlLiBXaGF0J3MgdGhlIG1lYW5pbmcgb2YNCiZx dW90O2F5IGNvbnNpZGVyYXRpb24mcXVvdDs/PC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PGJyPg0KIFppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQogVGVsICZuYnNw OyAmbmJzcDs6IDg3MjExPGJyPg0KIFRlbDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+ DQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PTwvZm9udD4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9u Jm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJz cDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xl bHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdh bml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMm bmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUm bmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVj eSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7 ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2Nv bW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2Fu ZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQm bmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3Nv bGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5k aXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZu YnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDty ZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVh c2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUm bmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4m bmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0 aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDto YXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQm bmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8 L3ByZT4= --=_alternative 0000CE5848257619_=-- From pkyzivat@cisco.com Thu Aug 20 17:34:33 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDA273A6A4D for ; Thu, 20 Aug 2009 17:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=-3.800, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_93=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckKFIahH5Nov for ; Thu, 20 Aug 2009 17:34:32 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id CAB533A68B0 for ; Thu, 20 Aug 2009 17:34:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABuIjUqrR7O6/2dsb2JhbAC+JYZngUiQeAWBLoELgRhHgVRT X-IronPort-AV: E=Sophos;i="4.44,247,1249257600"; d="scan'208";a="230928365" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 21 Aug 2009 00:34:38 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7L0YcGn024482; Thu, 20 Aug 2009 17:34:38 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7L0YcRb007783; Fri, 21 Aug 2009 00:34:38 GMT 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.3959); Thu, 20 Aug 2009 20:34:37 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Aug 2009 20:34:37 -0400 Message-ID: <4A8DEB9D.4020400@cisco.com> Date: Thu, 20 Aug 2009 20:34:37 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: gao.yang2@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 21 Aug 2009 00:34:37.0479 (UTC) FILETIME=[29C36370:01CA21F7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2610; t=1250814878; x=1251678878; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20=3D?GB2312?B?tPC4tDogUmU6ILTwuLQ6IFJlOi BTdXNwZW5kaW5nIGFuZCBSZQ=3D=3D?=3D=0A=20=3D?GB2312?B?c3VtaW5 nIG1vZGlmaWNhdGlvbiBvZiBzZXNzaW9uIG9yIHN0cmVhbT8gICAvLw=3D=3 D?=3D=0A=20=3D?GB2312?B?TmV3IHJldmlzaW9uIG9mIHRoZSByZS1JTlZJ VEUgaGFuZGxpbmcgZHJhZnQ=3D?=3D |Sender:=20; bh=nJRvD1OYQb0bjM7w4lFsfR4UpuFmKW5axtkDbjvhl+A=; b=uMfKMIydYgRluSwTKA/picx0kEPOZXsw1xzwyTui7YEaHn8Lgqz9ZjjTam NEDgom39SWNdflFbCyz7E3YGcY+qc81HVH5FD7H/49AIziCqF5FeRbm2+p/y eyZPYLDr3r; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: SIPCORE , wang.libo@zte.com.cn Subject: Re: [sipcore] =?gb2312?b?tPC4tDogUmU6ILTwuLQ6IFJlOiBTdXNwZW5kaW5nIGFu?= =?gb2312?b?ZCBSZXN1bWluZyBtb2RpZmljYXRpb24gb2Ygc2Vzc2lvbiBvciBzdHJlYW0/?= =?gb2312?b?ICAgLy9OZXcgcmV2aXNpb24gb2YgdGhlIHJlLUlOVklURSBoYW5kbGluZyBk?= =?gb2312?b?cmFmdA==?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 00:34:34 -0000 gao.yang2@zte.com.cn wrote: > > > Paul Kyzivat 写于 2009-08-21 02:59:32: > > > > > > > gao.yang2@zte.com.cn wrote: > > > > > > Hi Paul, > > > > > > As you can see that i am arguing in favor of suspension being > per-stream > > > :). > > > It is a clerical error. I prefer "suspending is effective for streams > > > with precondition", the 2st one. > > > > > > But RFC 3312 & 4032 has such description: > > > While session establishment is suspended(for QoS type precondition), > > > user agents SHOULD not send any data over *any media stream*. In the > > > case of RTP, neither RTP nor RTCP packets are sent. > > > > > > So, do we need correction for this? > > > > I haven't thought about it a lot, but my immediate reaction is *yes*, > > this doesn't seem right. I would like to hear what Gonzalo thinks. > > > > I'd like to hear Gonzalo's points too. But I remember that he said that > he will get back to office on September 1st. > Perhaps he can only show his idea then. > > > In the writing of 4032, I think the focus here was on narrowing the > > scope of this limitation, so that it applied only to QoS and not other > > precondition types. > > Yes, it is needful to narrow the scope of this limitation for other > precondition type beyond QoS type. > > > I don't think ay consideration was given to Sorry, I guess I sent before I was done. I meant to say that I don't think any consideration was given the point you are now raising. It just never came up. Thanks, Paul > I can't catch this sentence. What's the meaning of "ay consideration"? > > > =================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > =================================== > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. From gao.yang2@zte.com.cn Thu Aug 20 17:49:28 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F11A3A6A4D for ; Thu, 20 Aug 2009 17:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.642 X-Spam-Level: X-Spam-Status: No, score=-93.642 tagged_above=-999 required=5 tests=[AWL=-1.452, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKkW6tPAkyW6 for ; Thu, 20 Aug 2009 17:49:27 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id C7A183A6ED6 for ; Thu, 20 Aug 2009 17:49:16 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 91101727820181; Fri, 21 Aug 2009 08:33:50 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.99] with StormMail ESMTP id 49910.6396279943; Fri, 21 Aug 2009 08:39:52 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n7L0nI1Z009863; Fri, 21 Aug 2009 08:49:18 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4A8DEB9D.4020400@cisco.com> To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 21 Aug 2009 08:48:09 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-08-21 08:49:16, Serialize complete at 2009-08-21 08:49:16 Content-Type: multipart/alternative; boundary="=_alternative 0004810948257619_=" X-MAIL: mse2.zte.com.cn n7L0nI1Z009863 Cc: SIPCORE , wang.libo@zte.com.cn Subject: [sipcore] =?gb2312?b?tPC4tDogUmU6ILTwuLQ6IFJlOiC08Li0OiBSZTogU3Vz?= =?gb2312?b?cGVuZGluZyBhbmQgUmVzdW1pbmcgbW9kaWZpY2F0aW9uIG9mIHNlc3Npb24g?= =?gb2312?b?b3Igc3RyZWFtPyAgIC8vTmV3IHJldmlzaW9uIG9mIHRoZSByZS1JTlZJVEUg?= =?gb2312?b?aGFuZGxpbmcgZHJhZnQ=?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 00:49:28 -0000 This is a multipart message in MIME format. --=_alternative 0004810948257619_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 T0suIFRoYW5rcyBmb3IgeW91ciBleHBsYW5hdGlvbi4NCg0KQW5kIGFkZGluZyB5b3VyIGFyZ3Vp bmcgcG9pbnRzLCB3ZSBoYXZlIHRocmVlIG9uZXMgZm9yICJpbiBmYXZvciBvZiANCnN1c3BlbnNp b24gYmVpbmcgcGVyLXN0cmVhbSI6DQoNCjEuIFRvIGRlbGF5IHVzaW5nIG9mIG5ldyBwYXJhbWV0 ZXJzIGZvciBzdHJlYW0gd2l0aG91dCBwcmVjb25kaXRpb24gbWF5IA0KYXJvc2UgbWVkaWEgY2xp cCBwcm9ibGVtLg0KMi4gQmVoYXZpb3Igb2Ygc3RyZWFtcyB3aXRob3V0IHByZWNvbmRpdGlvbiBz aG91bGQgYmUgaW5kZXBlbmRlbnQgb2YgDQpleGlzdGVuY2Ugb2Ygb3RoZXIgc3RyZWFtcyggd2l0 aCBwcmVjb25kaXRpb24pLg0KMy4gVmFyaW91cyBzdHJlYW1zIGFyZSBub3QgY29udHJvbGxlZCBi eSB0aGUgc2FtZSBlbnRpdHksIHNvIHRoYXQgDQpjb29yZGluYXRpb24gb2Ygd2hlbiB0aGV5IHRh a2UgZWZmZWN0IGNvdWxkIGJlIHByb2JsZW1hdGljDQoNCkFuZCB3ZSBjYW4gdGFsayBpdCBmdXJ0 aGVyIHRvZ2V0aGVyIHdoZW4gR29uemFsbyBnZXQgYmFjay4NCg0KPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0NCiBaaXAgICAgOiAyMTAwMTINCiBUZWwgICAgOiA4NzIxMQ0KIFRl bDIgICA6KCs4NiktMDI1LTUyODc3MjExDQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY24N Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCg0KDQpQYXVsIEt5eml2YXQg PHBreXppdmF0QGNpc2NvLmNvbT4gDQoyMDA5LTA4LTIxIDA4OjM0DQoNCsrVvP7Iyw0KZ2FvLnlh bmcyQHp0ZS5jb20uY24NCrOty80NCkNocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20+LCBHb256YWxvIENhbWFyaWxsbyANCjxHb256YWxvLkNhbWFyaWxsb0Bl cmljc3Nvbi5jb20+LCBTSVBDT1JFIDxzaXBjb3JlQGlldGYub3JnPiwgDQp3YW5nLmxpYm9AenRl LmNvbS5jbg0K1vfM4g0KUmU6ILTwuLQ6IFJlOiC08Li0OiBSZTogU3VzcGVuZGluZyBhbmQgUmVz dW1pbmcgbW9kaWZpY2F0aW9uIG9mIHNlc3Npb24gb3IgDQpzdHJlYW0/ICAgLy9OZXcgcmV2aXNp b24gb2YgdGhlIHJlLUlOVklURSBoYW5kbGluZyBkcmFmdA0KDQoNCg0KDQoNCg0KDQoNCmdhby55 YW5nMkB6dGUuY29tLmNuIHdyb3RlOg0KPiANCj4gDQo+IFBhdWwgS3l6aXZhdCA8cGt5eml2YXRA Y2lzY28uY29tPiDQtNPaIDIwMDktMDgtMjEgMDI6NTk6MzI6DQo+IA0KPiAgPg0KPiAgPg0KPiAg PiBnYW8ueWFuZzJAenRlLmNvbS5jbiB3cm90ZToNCj4gID4gPg0KPiAgPiA+IEhpIFBhdWwsDQo+ ICA+ID4NCj4gID4gPiBBcyB5b3UgY2FuIHNlZSB0aGF0IGkgYW0gYXJndWluZyBpbiBmYXZvciBv ZiBzdXNwZW5zaW9uIGJlaW5nIA0KPiBwZXItc3RyZWFtDQo+ICA+ID4gOikuDQo+ICA+ID4gSXQg aXMgYSBjbGVyaWNhbCBlcnJvci4gSSBwcmVmZXIgInN1c3BlbmRpbmcgaXMgZWZmZWN0aXZlIGZv ciANCnN0cmVhbXMNCj4gID4gPiB3aXRoIHByZWNvbmRpdGlvbiIsIHRoZSAyc3Qgb25lLg0KPiAg PiA+DQo+ICA+ID4gQnV0IFJGQyAzMzEyICYgNDAzMiBoYXMgc3VjaCBkZXNjcmlwdGlvbjoNCj4g ID4gPiBXaGlsZSBzZXNzaW9uIGVzdGFibGlzaG1lbnQgaXMgc3VzcGVuZGVkKGZvciBRb1MgdHlw ZSANCnByZWNvbmRpdGlvbiksDQo+ICA+ID4gdXNlciBhZ2VudHMgU0hPVUxEIG5vdCBzZW5kIGFu eSBkYXRhIG92ZXIgKmFueSBtZWRpYSBzdHJlYW0qLiAgSW4gDQp0aGUNCj4gID4gPiBjYXNlIG9m IFJUUCwgbmVpdGhlciBSVFAgbm9yIFJUQ1AgcGFja2V0cyBhcmUgc2VudC4NCj4gID4gPg0KPiAg PiA+IFNvLCBkbyB3ZSBuZWVkIGNvcnJlY3Rpb24gZm9yIHRoaXM/DQo+ICA+DQo+ICA+IEkgaGF2 ZW4ndCB0aG91Z2h0IGFib3V0IGl0IGEgbG90LCBidXQgbXkgaW1tZWRpYXRlIHJlYWN0aW9uIGlz ICp5ZXMqLA0KPiAgPiB0aGlzIGRvZXNuJ3Qgc2VlbSByaWdodC4gSSB3b3VsZCBsaWtlIHRvIGhl YXIgd2hhdCBHb256YWxvIHRoaW5rcy4NCj4gID4NCj4gDQo+IEknZCBsaWtlIHRvIGhlYXIgR29u emFsbydzIHBvaW50cyB0b28uIEJ1dCBJIHJlbWVtYmVyIHRoYXQgaGUgc2FpZCB0aGF0IA0KPiBo ZSB3aWxsIGdldCBiYWNrIHRvIG9mZmljZSBvbiBTZXB0ZW1iZXIgMXN0Lg0KPiBQZXJoYXBzIGhl IGNhbiBvbmx5IHNob3cgaGlzIGlkZWEgdGhlbi4NCj4gDQo+ICA+IEluIHRoZSB3cml0aW5nIG9m IDQwMzIsIEkgdGhpbmsgdGhlIGZvY3VzIGhlcmUgd2FzIG9uIG5hcnJvd2luZyB0aGUNCj4gID4g c2NvcGUgb2YgdGhpcyBsaW1pdGF0aW9uLCBzbyB0aGF0IGl0IGFwcGxpZWQgb25seSB0byBRb1Mg YW5kIG5vdCANCm90aGVyDQo+ICA+IHByZWNvbmRpdGlvbiB0eXBlcy4NCj4gDQo+IFllcywgaXQg aXMgbmVlZGZ1bCB0byBuYXJyb3cgdGhlIHNjb3BlIG9mIHRoaXMgbGltaXRhdGlvbiBmb3Igb3Ro ZXIgDQo+IHByZWNvbmRpdGlvbiB0eXBlIGJleW9uZCBRb1MgdHlwZS4NCj4gDQo+ICA+IEkgZG9u J3QgdGhpbmsgYXkgY29uc2lkZXJhdGlvbiB3YXMgZ2l2ZW4gdG8NCg0KU29ycnksIEkgZ3Vlc3Mg SSBzZW50IGJlZm9yZSBJIHdhcyBkb25lLg0KDQpJIG1lYW50IHRvIHNheSB0aGF0IEkgZG9uJ3Qg dGhpbmsgYW55IGNvbnNpZGVyYXRpb24gd2FzIGdpdmVuIHRoZSBwb2ludA0KeW91IGFyZSBub3cg cmFpc2luZy4gSXQganVzdCBuZXZlciBjYW1lIHVwLg0KDQogICAgICAgICAgICAgICAgIFRoYW5r cywNCiAgICAgICAgICAgICAgICAgUGF1bA0KDQo+IEkgY2FuJ3QgY2F0Y2ggdGhpcyBzZW50ZW5j ZS4gV2hhdCdzIHRoZSBtZWFuaW5nIG9mICJheSBjb25zaWRlcmF0aW9uIj8NCj4gDQo+IA0KPiA9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPiBaaXAgICAgOiAyMTAwMTINCj4g VGVsICAgIDogODcyMTENCj4gVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCj4gZV9tYWlsIDog Z2FvLnlhbmcyQHp0ZS5jb20uY24NCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0NCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIA0KaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBz ZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIA0KaXMgY29uZmlk ZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4g c2VjcmVjeSANCmFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMg b2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIA0Kb3RoZXJzLg0KPiBUaGlzIGVtYWlsIGFuZCBhbnkg ZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCANCmludGVuZGVk IHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0 aGV5IGFyZSANCmFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciBwbGVhc2Ugbm90aWZ5IHRoZSANCm9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2 aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSANCm9mIHRoZSBpbmRpdmlk dWFsIHNlbmRlci4NCj4gVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMg YW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSANCnN5c3RlbS4NCg0KDQoNCg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9y bWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlz IG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRo aXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBh Ym92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0 dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3Ro ZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNv bmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlk dWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9m IHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhv c2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5u ZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 0004810948257619_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk9LLiBUaGFua3MgZm9yIHlvdXIg ZXhwbGFuYXRpb24uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5BbmQgYWRkaW5nIHlvdXIgYXJndWluZyBwb2ludHMsIHdlIGhhdmUNCnRocmVlIG9uZXMg Zm9yICZxdW90OzwvZm9udD48Zm9udCBzaXplPTI+PHR0PmluIGZhdm9yIG9mIHN1c3BlbnNpb24g YmVpbmcNCnBlci1zdHJlYW08L3R0PjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+JnF1b3Q7OjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0PjEuIFRvIGRlbGF5 IHVzaW5nIG9mIG5ldyBwYXJhbWV0ZXJzIGZvciBzdHJlYW0gd2l0aG91dA0KcHJlY29uZGl0aW9u IG1heSBhcm9zZSBtZWRpYSBjbGlwIHByb2JsZW0uPGJyPg0KMi4gQmVoYXZpb3Igb2Ygc3RyZWFt cyB3aXRob3V0IHByZWNvbmRpdGlvbiBzaG91bGQgYmUgaW5kZXBlbmRlbnQgb2YgZXhpc3RlbmNl DQpvZiBvdGhlciBzdHJlYW1zKCB3aXRoIHByZWNvbmRpdGlvbikuPC90dD48L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yPjx0dD4zLiBWYXJpb3VzIHN0cmVhbXMgYXJlIG5vdCBjb250cm9sbGVkIGJ5 IHRoZSBzYW1lDQplbnRpdHksIHNvIHRoYXQgY29vcmRpbmF0aW9uIG9mIHdoZW4gdGhleSB0YWtl IGVmZmVjdCBjb3VsZCBiZSBwcm9ibGVtYXRpYzxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5BbmQgd2UgY2FuIHRhbGsgaXQgZnVydGhlciB0b2dl dGhlcg0Kd2hlbiBHb256YWxvIGdldCBiYWNrLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08 YnI+DQogWmlwICZuYnNwOyAmbmJzcDs6IDIxMDAxMjxicj4NCiBUZWwgJm5ic3A7ICZuYnNwOzog ODcyMTE8YnI+DQogVGVsMiAmbmJzcDsgOigrODYpLTAyNS01Mjg3NzIxMTxicj4NCiBlX21haWwg OiBnYW8ueWFuZzJAenRlLmNvbS5jbjxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0yNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PjxiPlBhdWwgS3l6aXZhdCAmbHQ7cGt5eml2YXRAY2lzY28uY29tJmd0OzwvYj4NCjwvZm9udD4N CjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDA5LTA4LTIxIDA4OjM0PC9mb250 Pg0KPHRkIHdpZHRoPTczJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+ yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmdhby55 YW5nMkB6dGUuY29tLmNuPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWdu PXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0K PHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5DaHJpc3RlciBIb2xtYmVyZyAmbHQ7 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0OywNCkdvbnphbG8gQ2FtYXJpbGxvICZs dDtHb256YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5jb20mZ3Q7LCBTSVBDT1JFICZsdDtzaXBjb3Jl QGlldGYub3JnJmd0OywNCndhbmcubGlib0B6dGUuY29tLmNuPC9mb250Pg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5S ZTogtPC4tDogUmU6ILTwuLQ6IFJlOiBTdXNwZW5kaW5nDQphbmQgUmVzdW1pbmcgbW9kaWZpY2F0 aW9uIG9mIHNlc3Npb24gb3Igc3RyZWFtPyAmbmJzcDsgLy9OZXcgcmV2aXNpb24gb2YNCnRoZSBy ZS1JTlZJVEUgaGFuZGxpbmcgZHJhZnQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxi cj4NCjxicj48Zm9udCBzaXplPTI+PHR0Pjxicj4NCjxicj4NCmdhby55YW5nMkB6dGUuY29tLmNu IHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFBhdWwgS3l6aXZhdCAmbHQ7 cGt5eml2YXRAY2lzY28uY29tJmd0OyDQtNPaIDIwMDktMDgtMjEgMDI6NTk6MzI6PGJyPg0KJmd0 OyA8YnI+DQomZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZu YnNwOyZndDsgZ2FvLnlhbmcyQHp0ZS5jb20uY24gd3JvdGU6PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsgJmd0OyBIaSBQYXVsLDxicj4NCiZndDsgJm5ic3A7 Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7ICZndDsgQXMgeW91IGNhbiBzZWUgdGhhdCBp IGFtIGFyZ3VpbmcgaW4gZmF2b3Igb2Ygc3VzcGVuc2lvbg0KYmVpbmcgPGJyPg0KJmd0OyBwZXIt c3RyZWFtPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7ICZndDsgOikuPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7 ICZndDsgSXQgaXMgYSBjbGVyaWNhbCBlcnJvci4gSSBwcmVmZXIgJnF1b3Q7c3VzcGVuZGluZw0K aXMgZWZmZWN0aXZlIGZvciBzdHJlYW1zPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7ICZndDsgd2l0aCBw cmVjb25kaXRpb24mcXVvdDssIHRoZSAyc3Qgb25lLjxicj4NCiZndDsgJm5ic3A7Jmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7ICZndDsgQnV0IFJGQyAzMzEyICZhbXA7IDQwMzIgaGFzIHN1 Y2ggZGVzY3JpcHRpb246PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7ICZndDsgV2hpbGUgc2Vzc2lvbiBl c3RhYmxpc2htZW50IGlzIHN1c3BlbmRlZChmb3IgUW9TIHR5cGUNCnByZWNvbmRpdGlvbiksPGJy Pg0KJmd0OyAmbmJzcDsmZ3Q7ICZndDsgdXNlciBhZ2VudHMgU0hPVUxEIG5vdCBzZW5kIGFueSBk YXRhIG92ZXIgKmFueSBtZWRpYQ0Kc3RyZWFtKi4gJm5ic3A7SW4gdGhlPGJyPg0KJmd0OyAmbmJz cDsmZ3Q7ICZndDsgY2FzZSBvZiBSVFAsIG5laXRoZXIgUlRQIG5vciBSVENQIHBhY2tldHMgYXJl IHNlbnQuPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsgJmd0 OyBTbywgZG8gd2UgbmVlZCBjb3JyZWN0aW9uIGZvciB0aGlzPzxicj4NCiZndDsgJm5ic3A7Jmd0 Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyBJIGhhdmVuJ3QgdGhvdWdodCBhYm91dCBpdCBhIGxvdCwg YnV0IG15IGltbWVkaWF0ZSByZWFjdGlvbg0KaXMgKnllcyosPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7 IHRoaXMgZG9lc24ndCBzZWVtIHJpZ2h0LiBJIHdvdWxkIGxpa2UgdG8gaGVhciB3aGF0IEdvbnph bG8NCnRoaW5rcy48YnI+DQomZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSdk IGxpa2UgdG8gaGVhciBHb256YWxvJ3MgcG9pbnRzIHRvby4gQnV0IEkgcmVtZW1iZXIgdGhhdCBo ZSBzYWlkDQp0aGF0IDxicj4NCiZndDsgaGUgd2lsbCBnZXQgYmFjayB0byBvZmZpY2Ugb24gU2Vw dGVtYmVyIDFzdC48YnI+DQomZ3Q7IFBlcmhhcHMgaGUgY2FuIG9ubHkgc2hvdyBoaXMgaWRlYSB0 aGVuLjxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IEluIHRoZSB3cml0aW5nIG9mIDQw MzIsIEkgdGhpbmsgdGhlIGZvY3VzIGhlcmUgd2FzIG9uIG5hcnJvd2luZw0KdGhlPGJyPg0KJmd0 OyAmbmJzcDsmZ3Q7IHNjb3BlIG9mIHRoaXMgbGltaXRhdGlvbiwgc28gdGhhdCBpdCBhcHBsaWVk IG9ubHkgdG8gUW9TDQphbmQgbm90IG90aGVyPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IHByZWNvbmRp dGlvbiB0eXBlcy48YnI+DQomZ3Q7IDxicj4NCiZndDsgWWVzLCBpdCBpcyBuZWVkZnVsIHRvIG5h cnJvdyB0aGUgc2NvcGUgb2YgdGhpcyBsaW1pdGF0aW9uIGZvciBvdGhlcg0KPGJyPg0KJmd0OyBw cmVjb25kaXRpb24gdHlwZSBiZXlvbmQgUW9TIHR5cGUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZu YnNwOyZndDsgSSBkb24ndCB0aGluayBheSBjb25zaWRlcmF0aW9uIHdhcyBnaXZlbiB0bzxicj4N Cjxicj4NClNvcnJ5LCBJIGd1ZXNzIEkgc2VudCBiZWZvcmUgSSB3YXMgZG9uZS48YnI+DQo8YnI+ DQpJIG1lYW50IHRvIHNheSB0aGF0IEkgZG9uJ3QgdGhpbmsgYW55IGNvbnNpZGVyYXRpb24gd2Fz IGdpdmVuIHRoZSBwb2ludDxicj4NCnlvdSBhcmUgbm93IHJhaXNpbmcuIEl0IGp1c3QgbmV2ZXIg Y2FtZSB1cC48YnI+DQo8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KVGhhbmtzLDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpQYXVsPGJyPg0KPGJyPg0KJmd0OyBJ IGNhbid0IGNhdGNoIHRoaXMgc2VudGVuY2UuIFdoYXQncyB0aGUgbWVhbmluZyBvZiAmcXVvdDth eSBjb25zaWRlcmF0aW9uJnF1b3Q7Pzxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ID09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KJmd0OyBaaXAgJm5ic3A7ICZu YnNwOzogMjEwMDEyPGJyPg0KJmd0OyBUZWwgJm5ic3A7ICZuYnNwOzogODcyMTE8YnI+DQomZ3Q7 IFRlbDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+DQomZ3Q7IGVfbWFpbCA6IGdhby55 YW5nMkB6dGUuY29tLmNuPGJyPg0KJmd0OyA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PTxicj4NCiZndDsgPGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgWlRFIEluZm9ybWF0aW9uIFNlY3Vy aXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzDQptYWlsIGlzIHNv bGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29t bXVuaWNhdGlvbg0KaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBv YmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeQ0KYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRp c2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8NCm90aGVycy48YnI+ DQomZ3Q7IFRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBj b25maWRlbnRpYWwgYW5kDQppbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2 aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUNCmFkZHJlc3NlZC4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9y DQpvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJl IHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsDQpzZW5kZXIuPGJyPg0KJmd0OyBUaGlzIG1lc3NhZ2Ug aGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtDQpz eXN0ZW0uPGJyPg0KPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJz cDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2lu Zm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNw O2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRl cidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNh dGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1l ZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFp biZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQm bmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNw O3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7 ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7 d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50 ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNw O3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hv bSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJz cDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vy cm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNw O29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJl c3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZu YnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDtt ZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1 c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5i c3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 0004810948257619_=-- From christer.holmberg@ericsson.com Thu Aug 20 22:25:08 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD1783A69D2 for ; Thu, 20 Aug 2009 22:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.613 X-Spam-Level: X-Spam-Status: No, score=-5.613 tagged_above=-999 required=5 tests=[AWL=0.635, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GW0-YkrvIzwm for ; Thu, 20 Aug 2009 22:25:07 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id ADFD63A6D22 for ; Thu, 20 Aug 2009 22:25:06 -0700 (PDT) X-AuditID: c1b4fb3c-b7c01ae000002aae-46-4a8e2fb59cae Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id CA.6F.10926.5BF2E8A4; Fri, 21 Aug 2009 07:25:10 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 07:25:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA221F.BFEA858F" Date: Fri, 21 Aug 2009 07:25:09 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F917C0B@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Outbound and simultaneous registration transactions Thread-Index: AcoY5svUG52kXhW9S7m0XzwvAdgeRAJCEdaQAAwqR/A= References: <1ECE0EB50388174790F9694F77522CCF1F917C0B@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Francois Audet" , "SIPCORE" X-OriginalArrivalTime: 21 Aug 2009 05:25:09.0842 (UTC) FILETIME=[C042E320:01CA221F] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Outbound and simultaneous registration transactions X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 05:25:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA221F.BFEA858F Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Some clarification needed? ________________________________ From: Francois Audet [mailto:audet@nortel.com]=20 Sent: 21. elokuuta 2009 2:37 To: Christer Holmberg; SIPCORE Subject: RE: Outbound and simultaneous registration transactions =09 =09 I believe you are correct. ________________________________ From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Sunday, August 09, 2009 04:45 To: SIPCORE Cc: Audet, Francois (SC100:3055) Subject: Outbound and simultaneous registration transactions =09 =09 Hi outbound lovers,=20 Section 10.2 of RFC 3261 says:=20 "UAs MUST NOT send a new registration (that is, containing new Contact=20 header field values, as opposed to a retransmission) until they have=20 received a final response from the registrar for the previous one or=20 the previous REGISTER request has timed out."=20 Q1: I don't find any text in the outbound spec which would allow sending new registrations for the SAME Contact header value until a response has been received from the previous register (or the prevoius has timed out). So, my assumption is that the only-one-register-transaction-at-a-time rule also applies to outbound, or? Section 6 of outbound says:=20 "The registrar MUST be prepared to receive, simultaneously for the same AOR, some registrations that use instance-id and reg-id and some registrations that do not." I assume "simultaneously" doesn't refer to simultaneous registration transactions, but simultaneus valid registrations.=20 Regards,=20 Christer=20 ------_=_NextPart_001_01CA221F.BFEA858F Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Outbound and simultaneous registration = transactions
Some clarification = needed?

From: Francois Audet = [mailto:audet@nortel.com]=20
Sent: 21. elokuuta 2009 2:37
To: Christer = Holmberg;=20 SIPCORE
Subject: RE: Outbound and simultaneous registration=20 transactions

I=20 believe you are correct.

From: Christer Holmberg=20 [mailto:christer.holmberg@ericsson.com]
Sent: Sunday, = August 09,=20 2009 04:45
To: SIPCORE
Cc: Audet, Francois=20 (SC100:3055)
Subject: Outbound and simultaneous = registration=20 transactions


Hi outbound lovers,

Section 10.2 of RFC 3261 says: =

"UAs MUST NOT send a new registration = (that is,=20 containing new Contact
header = field=20 values, as opposed to a retransmission) until they have =
received a final response from the registrar = for the=20 previous one or
the previous = REGISTER=20 request has timed out."


Q1: I don't find any text in the = outbound spec=20 which would allow sending new registrations for the SAME Contact = header=20 value until a response has been received from the previous register = (or the=20 prevoius has timed out). So, my assumption is that the=20 only-one-register-transaction-at-a-time rule also applies to = outbound,=20 or?


Section 6 of outbound says: =

"The registrar MUST be prepared to = receive,=20 simultaneously for the same AOR, some registrations that use = instance-id and=20 reg-id and some registrations that do not."

I assume "simultaneously" doesn't = refer to=20 simultaneous registration transactions, but simultaneus valid = registrations.=20

Regards,

Christer=20

------_=_NextPart_001_01CA221F.BFEA858F-- From christer.holmberg@ericsson.com Fri Aug 21 03:46:52 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0CC228C152 for ; Fri, 21 Aug 2009 03:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[AWL=-3.326, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_SE=0.35, J_CHICKENPOX_93=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awA6tOHTDv12 for ; Fri, 21 Aug 2009 03:46:51 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id D595E28C146 for ; Fri, 21 Aug 2009 03:46:50 -0700 (PDT) X-AuditID: c1b4fb3c-b7c01ae000002aae-e8-4a8e7b05a0fc Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id C6.C8.10926.50B7E8A4; Fri, 21 Aug 2009 12:46:29 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 12:46:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Aug 2009 12:46:28 +0200 Message-ID: In-Reply-To: <4A8D9D14.3010904@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?gb2312?B?tPC4tDogUmU6IFN1c3BlbmRpbmcgYW5kIFJlc3VtaW5nIG1vZGlmaQ==?= =?gb2312?B?Y2F0aW9uIG9mIHNlc3Npb24gb3Igc3RyZWFtPyAgIC8vTmV3IHJldg==?= =?gb2312?B?aXNpb24gb2YgdGhlIHJlLUlOVklURSBoYW5kbGluZyBkcmFmdA==?= Thread-Index: AcohyGK+yP4ocO2SSaW9QJu5O8bpwwAgnvQA References: <4A8D9D14.3010904@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , X-OriginalArrivalTime: 21 Aug 2009 10:46:29.0441 (UTC) FILETIME=[A3CC3B10:01CA224C] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , wang.libo@zte.com.cn, Gonzalo Camarillo Subject: Re: [sipcore] =?gb2312?b?tPC4tDogUmU6IFN1c3BlbmRpbmcgYW5kIFJlc3VtaW5n?= =?gb2312?b?IG1vZGlmaWNhdGlvbiBvZiBzZXNzaW9uIG9yIHN0cmVhbT8gICAv?= =?gb2312?b?L05ldyByZXZpc2lvbiBvZiB0aGUgcmUtSU5WSVRFIGhhbmRsaW5n?= =?gb2312?b?IGRyYWZ0?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 10:46:52 -0000 Hi, I think you are asking for problems if you start combining preconditions = and non-preconditions in a re-INVITE.=20 It is already difficult enough to be sure on when the new media = parameters will be taken in use, and when the old ones cannot be used = anymore, so if different parameters are to be taken into use at = different times I think it will create a mess... So, why not do the audio change and the video change in separate = transactions? But, I need to do some more thinking before answering your question. In = principle I guess it would be good to keep each media stream as separate = as possible, but the way SIP, SDP and the media descriptions are = boundled together there may be some limitations. We also need to keep in mind that the precondition modification can = fail, and what happens to the non-precondition change in that case. Regards, Christer =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 20. elokuuta 2009 22:00 > To: gao.yang2@zte.com.cn > Cc: Christer Holmberg; Gonzalo Camarillo; SIPCORE;=20 > wang.libo@zte.com.cn > Subject: Re: =B4=F0=B8=B4: Re: Suspending and Resuming modification of = > session or stream? //New revision of the re-INVITE handling draft >=20 >=20 >=20 > gao.yang2@zte.com.cn wrote: > >=20 > > Hi Paul, > >=20 > > As you can see that i am arguing in favor of suspension being=20 > > per-stream :). > > It is a clerical error. I prefer "suspending is effective=20 > for streams=20 > > with precondition", the 2st one. > >=20 > > But RFC 3312 & 4032 has such description: > > While session establishment is suspended(for QoS type=20 > precondition),=20 > > user agents SHOULD not send any data over *any media=20 > stream*. In the=20 > > case of RTP, neither RTP nor RTCP packets are sent. > >=20 > > So, do we need correction for this? >=20 > I haven't thought about it a lot, but my immediate reaction=20 > is *yes*, this doesn't seem right. I would like to hear what=20 > Gonzalo thinks. >=20 > In the writing of 4032, I think the focus here was on=20 > narrowing the scope of this limitation, so that it applied=20 > only to QoS and not other precondition types. I don't think=20 > ay consideration was given to >=20 > Thanks, > Paul >=20 > > Thanks. > >=20 > > Gao > >=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Zip : 210012 > > Tel : 87211 > > Tel2 :(+86)-025-52877211 > > e_mail : gao.yang2@zte.com.cn > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > >=20 > > *Paul Kyzivat * > >=20 > > 2009-08-20 21:01 > >=20 > > =09 > > =CA=D5=BC=FE=C8=CB > > gao.yang2@zte.com.cn > > =B3=AD=CB=CD > > SIPCORE , Gonzalo Camarillo=20 > > , Christer Holmberg=20 > > , wang.libo@zte.com.cn > > =D6=F7=CC=E2 > > Re: Suspending and Resuming modification of session or=20 > stream? //New=20 > > revision of the re-INVITE handling draft > >=20 > >=20 > > =09 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > gao.yang2@zte.com.cn wrote: > > > > > > Considering a use case, A and B has a audio only session. Then A=20 > > send a > Re-INVITE for adding vedio stream( with precondition) and=20 > > changing codec > or address for audio stream( without preconditon). > > > > > > If suspending is effective for whole session, then=20 > streams without =20 > > > precondition should use old parameters while in suspending state. > > > For the use case, A and B should not use new codec or=20 > address for=20 > > audio > before vedio's preconditon is met. > > > > > > If suspending is effective for streams with=20 > precondition, the then =20 > > > streams without preconditio can use new parameters after=20 > first O/A =20 > > > during the Re-INVITE. > > > For the use case, A and B can use new codec or address for audio=20 > > before > vedio's preconditon is met. > > > > > > > > > I prefer the first one, as; > >=20 > > You mean that you prefer suspension being for the whole=20 > session (*all*=20 > > streams)??? > >=20 > > > 1. To delay using of new parameters for stream without=20 > precondition=20 > > may > arose media clip problem. > > > 2. Behavior of streams without precondition should be=20 > independent=20 > > of > existence of other streams( with precondition). > >=20 > > It seems you are arguing in favor of suspension being per-stream. > >=20 > > IMO the suspension behavior is defined on a per-stream basis and so=20 > > needs to be implemented that way. > >=20 > > Another reason for this is that it is possible the various=20 > streams are=20 > > not controlled by the same entity, so that coordination of=20 > when they=20 > > take effect could be problematic. > >=20 > > If someone wants the changes to multiple streams to take effect=20 > > together they are free to put preconditions on them all and=20 > > synchronize the resolution of those preconditions. > >=20 > > Thanks, > > Paul > >=20 > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > Zip : 210012 > > > Tel : 87211 > > > Tel2 :(+86)-025-52877211 > > > e_mail : gao.yang2@zte.com.cn > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > -------------------------------------------------------- > > > ZTE Information Security Notice: The information=20 > contained in this=20 > > mail is solely property of the sender's organization. This mail=20 > > communication is confidential. Recipients named above are=20 > obligated to=20 > > maintain secrecy and are not permitted to disclose the contents of=20 > > this communication to others. > > > This email and any files transmitted with it are=20 > confidential and=20 > > intended solely for the use of the individual or entity to=20 > whom they=20 > > are addressed. If you have received this email in error=20 > please notify=20 > > the originator of the message. Any views expressed in this=20 > message are=20 > > those of the individual sender. > > > This message has been scanned for viruses and Spam by=20 > ZTE Anti-Spam=20 > > system. > > > > >=20 > >=20 > >=20 > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained=20 > in this mail is solely property of the sender's organization.=20 > This mail communication is confidential. Recipients named=20 > above are obligated to maintain secrecy and are not permitted=20 > to disclose the contents of this communication to others. > > This email and any files transmitted with it are=20 > confidential and intended solely for the use of the=20 > individual or entity to whom they are addressed. If you have=20 > received this email in error please notify the originator of=20 > the message. Any views expressed in this message are those of=20 > the individual sender. > > This message has been scanned for viruses and Spam by ZTE=20 > Anti-Spam system. >=20 From gao.yang2@zte.com.cn Fri Aug 21 04:44:58 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E63E3A6DF4 for ; Fri, 21 Aug 2009 04:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.031 X-Spam-Level: X-Spam-Status: No, score=-93.031 tagged_above=-999 required=5 tests=[AWL=-2.641, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_93=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMlTVEdQVFE4 for ; Fri, 21 Aug 2009 04:44:56 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 4B4C528C13B for ; Fri, 21 Aug 2009 04:44:35 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 111641727820181; Fri, 21 Aug 2009 19:24:03 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.99] with StormMail ESMTP id 49910.6396279943; Fri, 21 Aug 2009 19:35:08 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n7LBiiGr080780; Fri, 21 Aug 2009 19:44:45 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: "Christer Holmberg" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 21 Aug 2009 19:43:24 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-08-21 19:44:31, Serialize complete at 2009-08-21 19:44:31 Content-Type: multipart/alternative; boundary="=_alternative 00407EA648257619_=" X-MAIL: mse1.zte.com.cn n7LBiiGr080780 Cc: SIPCORE , wang.libo@zte.com.cn, Gonzalo Camarillo Subject: [sipcore] =?gb2312?b?tPC4tDogUkU6ILTwuLQ6IFJlOiBTdXNwZW5kaW5nIGFu?= =?gb2312?b?ZCBSZXN1bWluZyBtb2RpZmljYXRpb24gb2Ygc2Vzc2lvbiBvciBzdHJlYW0/?= =?gb2312?b?ICAgLy9OZXcgcmV2aXNpb24gb2YgdGhlIHJlLUlOVklURSBoYW5kbGluZyBk?= =?gb2312?b?cmFmdA==?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 11:44:58 -0000 This is a multipart message in MIME format. --=_alternative 00407EA648257619_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 IkNocmlzdGVyIEhvbG1iZXJnIiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiDQtNPa IDIwMDktMDgtMjEgDQoxODo0NjoyODoNCg0KPiANCj4gSGksDQo+IA0KPiBJIHRoaW5rIHlvdSBh cmUgYXNraW5nIGZvciBwcm9ibGVtcyBpZiB5b3Ugc3RhcnQgY29tYmluaW5nIA0KPiBwcmVjb25k aXRpb25zIGFuZCBub24tcHJlY29uZGl0aW9ucyBpbiBhIHJlLUlOVklURS4gDQo+IA0KPiBJdCBp cyBhbHJlYWR5IGRpZmZpY3VsdCBlbm91Z2ggdG8gYmUgc3VyZSBvbiB3aGVuIHRoZSBuZXcgbWVk aWEgDQo+IHBhcmFtZXRlcnMgd2lsbCBiZSB0YWtlbiBpbiB1c2UsIGFuZCB3aGVuIHRoZSBvbGQg b25lcyBjYW5ub3QgYmUgDQo+IHVzZWQgYW55bW9yZSwgc28gaWYgZGlmZmVyZW50IHBhcmFtZXRl cnMgYXJlIHRvIGJlIHRha2VuIGludG8gdXNlIGF0DQo+IGRpZmZlcmVudCB0aW1lcyBJIHRoaW5r IGl0IHdpbGwgY3JlYXRlIGEgbWVzcy4uLg0KPiANCg0KV2hlbiB0byBzd2l0Y2ggZnJvbSBvbGQg dG8gbmV3IHBhcmFtZXRlcnMgc2hvdWxkIG9iZXkgUkZDMzI2NC4gQW5kIA0Kc3VzcGVuZGluZyBz ZW1hbnRpYyBmb3Igc2Vzc2lvbiBvciBzdHJlYW0gaXMgUkZDMzMxMiAmIDQwMzIuDQpUaGUgdHdv IHByb2JsZW1zIGhhdmUgcmVsYXRpb25zaGlwLCBidXQgdGhleSBoYXZlIHNlcGFyYXRlIHNvdXJj ZXMgb2YgDQpkZWZpbnRpb24uDQoNCkFuZCBpZiB3ZSBjaG9vc2UgdGhlIHdheSBvZiAqc3VzcGVu ZGluZyBzZW1hbnRpYyBmb3Igd2hvbGUgc2Vzc2lvbiosIHRoZW4gDQphcyBQYXVsIHNhaWQgdGhh dCBjb29yZGluYXRpb24gb2Ygd2hlbiB0aGV5IHRha2UgZWZmZWN0IGNvdWxkIGJlIA0KcHJvYmxl bWF0aWMuIEl0IGNhbiBjcmVhdGUgYSBiaWdnZXIgbWVzcy4gOikNCg0KPiBTbywgd2h5IG5vdCBk byB0aGUgYXVkaW8gY2hhbmdlIGFuZCB0aGUgdmlkZW8gY2hhbmdlIGluIHNlcGFyYXRlIA0KdHJh bnNhY3Rpb25zPw0KPiANCg0KSSBhZ3JlZSB3aXRoIHlvdS4gQnV0IEkgY2FuIG5vdCBzdG9wIHBl b3BsZSBmcm9tIGRvaW5nIHNvLg0KQW5kIHdlIHJlYWxseSBoYXZlIGVxdWlwbWVudCBhcyAqdmFy aW91cyBzdHJlYW1zIGFyZSBub3QgY29udHJvbGxlZCBieSB0aGUgDQpzYW1lIGVudGl0eSooIElu IGZhY3QsIFpURSBoYXMgYSBlcXVpcG1lbnQgaW4gdGhpcyB3YXkpLiBBbmQgaXQgaXMgcmVhbGx5 IA0KaGFyZCB0byB3cmFwIHZhcmlvdXMgc3RyZWFtcyBoYXMgdGhlIHNhbWUgYWJpbGl0eSwgc3Vj aCBhcyBwcmVjb25kaXRpb24uDQoNCj4gQnV0LCBJIG5lZWQgdG8gZG8gc29tZSBtb3JlIHRoaW5r aW5nIGJlZm9yZSBhbnN3ZXJpbmcgeW91ciBxdWVzdGlvbi4NCj4gSW4gcHJpbmNpcGxlIEkgZ3Vl c3MgaXQgd291bGQgYmUgZ29vZCB0byBrZWVwIGVhY2ggbWVkaWEgc3RyZWFtIGFzIA0KPiBzZXBh cmF0ZSBhcyBwb3NzaWJsZSwgYnV0IHRoZSB3YXkgU0lQLCBTRFAgYW5kIHRoZSBtZWRpYSANCj4g ZGVzY3JpcHRpb25zIGFyZSBib3VuZGxlZCB0b2dldGhlciB0aGVyZSBtYXkgYmUgc29tZSBsaW1p dGF0aW9ucy4NCj4gDQoNClllcy4gSSBhbHNvIHRoaW5rIGl0IGlzIGJldHRlciB0byAqa2VlcCBl YWNoIG1lZGlhIHN0cmVhbSBhcyBzZXBhcmF0ZSBhcyANCnBvc3NpYmxlKi4gU28sIEkgcHJlZmVy IHRoZSB3YXkgb2YgKnN1c3BlbmRpbmcgc2VtYW50aWMgZm9yIHN0cmVhbXMgd2l0aCANCnByZWNv bmRpdGlvbiouDQpBbmQgSSB0aGluayBpdCBpcyBiZXR0ZXIgdG8gbWFrZSBhIGRldGFpbGVkIHJl YXNvbmluZyBmb3IgdGhlIHR3byANCmFwcHJvYWNocy4NCg0KPiBXZSBhbHNvIG5lZWQgdG8ga2Vl cCBpbiBtaW5kIHRoYXQgdGhlIHByZWNvbmRpdGlvbiBtb2RpZmljYXRpb24gY2FuIA0KPiBmYWls LCBhbmQgd2hhdCBoYXBwZW5zIHRvIHRoZSBub24tcHJlY29uZGl0aW9uIGNoYW5nZSBpbiB0aGF0 IGNhc2UuDQo+IA0KDQpZZXMsIHRoZSBwcmVjb25kaXRpb24gY2FuIGZhaWwuDQpCeSB0aGUgd2F5 IGluIHRoZSBkcmFmdDoNCkFuZCBhcyBpdCh0aGUgcHJlY29uZGl0aW9uIHN0cmVhbSkgaXMgbm90 IHVzZWQsIGFuZCB0aGUgbm9uLXByZWNvbmRpdGlvbiANCmlzIHVzZWQoaW4gY2FzZSBvZiBoYXZp bmcgZG9uZSB0aGUgZmlyc3QgTy9BKSwgVUEgY2FuIHNlbmQgYSBVUERBVEUgd2l0aCANCm5vbi1w cmVjb25kaXRpb24gc3RyZWFtKGJ5IFJGQzMyNjQsIHRoZSBwcmVjb25kaXRvbiBzdHJlYW0gc2hv dWxkIGJlIHNldCANCmFzIHBvcnQ9MCkgdG8gc2hvdyB0aGUgcm9sbGJhY2sgc3RhdGUgb2Ygc2Vz c2lvbi4NCg0KPiBSZWdhcmRzLA0KPiANCj4gQ2hyaXN0ZXINCj4gDQo+IA0KPiANCj4gDQo+ID4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBQYXVsIEt5eml2YXQgW21haWx0 bzpwa3l6aXZhdEBjaXNjby5jb21dIA0KPiA+IFNlbnQ6IDIwLiBlbG9rdXV0YSAyMDA5IDIyOjAw DQo+ID4gVG86IGdhby55YW5nMkB6dGUuY29tLmNuDQo+ID4gQ2M6IENocmlzdGVyIEhvbG1iZXJn OyBHb256YWxvIENhbWFyaWxsbzsgU0lQQ09SRTsgDQo+ID4gd2FuZy5saWJvQHp0ZS5jb20uY24N Cj4gPiBTdWJqZWN0OiBSZTogtPC4tDogUmU6IFN1c3BlbmRpbmcgYW5kIFJlc3VtaW5nIG1vZGlm aWNhdGlvbiBvZiANCj4gPiBzZXNzaW9uIG9yIHN0cmVhbT8gLy9OZXcgcmV2aXNpb24gb2YgdGhl IHJlLUlOVklURSBoYW5kbGluZyBkcmFmdA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IGdhby55YW5n MkB6dGUuY29tLmNuIHdyb3RlOg0KPiA+ID4gDQo+ID4gPiBIaSBQYXVsLA0KPiA+ID4gDQo+ID4g PiBBcyB5b3UgY2FuIHNlZSB0aGF0IGkgYW0gYXJndWluZyBpbiBmYXZvciBvZiBzdXNwZW5zaW9u IGJlaW5nIA0KPiA+ID4gcGVyLXN0cmVhbSA6KS4NCj4gPiA+IEl0IGlzIGEgY2xlcmljYWwgZXJy b3IuIEkgcHJlZmVyICJzdXNwZW5kaW5nIGlzIGVmZmVjdGl2ZSANCj4gPiBmb3Igc3RyZWFtcyAN Cj4gPiA+IHdpdGggcHJlY29uZGl0aW9uIiwgdGhlIDJzdCBvbmUuDQo+ID4gPiANCj4gPiA+IEJ1 dCBSRkMgMzMxMiAmIDQwMzIgaGFzIHN1Y2ggZGVzY3JpcHRpb246DQo+ID4gPiBXaGlsZSBzZXNz aW9uIGVzdGFibGlzaG1lbnQgaXMgc3VzcGVuZGVkKGZvciBRb1MgdHlwZSANCj4gPiBwcmVjb25k aXRpb24pLCANCj4gPiA+IHVzZXIgYWdlbnRzIFNIT1VMRCBub3Qgc2VuZCBhbnkgZGF0YSBvdmVy ICphbnkgbWVkaWEgDQo+ID4gc3RyZWFtKi4gIEluIHRoZSANCj4gPiA+IGNhc2Ugb2YgUlRQLCBu ZWl0aGVyIFJUUCBub3IgUlRDUCBwYWNrZXRzIGFyZSBzZW50Lg0KPiA+ID4gDQo+ID4gPiBTbywg ZG8gd2UgbmVlZCBjb3JyZWN0aW9uIGZvciB0aGlzPw0KPiA+IA0KPiA+IEkgaGF2ZW4ndCB0aG91 Z2h0IGFib3V0IGl0IGEgbG90LCBidXQgbXkgaW1tZWRpYXRlIHJlYWN0aW9uIA0KPiA+IGlzICp5 ZXMqLCB0aGlzIGRvZXNuJ3Qgc2VlbSByaWdodC4gSSB3b3VsZCBsaWtlIHRvIGhlYXIgd2hhdCAN Cj4gPiBHb256YWxvIHRoaW5rcy4NCj4gPiANCj4gPiBJbiB0aGUgd3JpdGluZyBvZiA0MDMyLCBJ IHRoaW5rIHRoZSBmb2N1cyBoZXJlIHdhcyBvbiANCj4gPiBuYXJyb3dpbmcgdGhlIHNjb3BlIG9m IHRoaXMgbGltaXRhdGlvbiwgc28gdGhhdCBpdCBhcHBsaWVkIA0KPiA+IG9ubHkgdG8gUW9TIGFu ZCBub3Qgb3RoZXIgcHJlY29uZGl0aW9uIHR5cGVzLiBJIGRvbid0IHRoaW5rIA0KPiA+IGF5IGNv bnNpZGVyYXRpb24gd2FzIGdpdmVuIHRvDQo+ID4gDQo+ID4gICAgVGhhbmtzLA0KPiA+ICAgIFBh dWwNCj4gPiANCj4gPiA+IFRoYW5rcy4NCj4gPiA+IA0KPiA+ID4gR2FvDQo+ID4gPiANCj4gPiA+ ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+ID4gPiBaaXAgICAgOiAyMTAw MTINCj4gPiA+IFRlbCAgICA6IDg3MjExDQo+ID4gPiBUZWwyICAgOigrODYpLTAyNS01Mjg3NzIx MQ0KPiA+ID4gZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj4gPiA+ID09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gKlBhdWwgS3l6 aXZhdCA8cGt5eml2YXRAY2lzY28uY29tPioNCj4gPiA+IA0KPiA+ID4gMjAwOS0wOC0yMCAyMTow MQ0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IMrVvP7Iyw0KPiA+ID4gICAgZ2FvLnlhbmcyQHp0ZS5j b20uY24NCj4gPiA+ILOty80NCj4gPiA+ICAgIFNJUENPUkUgPHNpcGNvcmVAaWV0Zi5vcmc+LCBH b256YWxvIENhbWFyaWxsbyANCj4gPiA+IDxHb256YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5jb20+ LCBDaHJpc3RlciBIb2xtYmVyZyANCj4gPiA+IDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j b20+LCB3YW5nLmxpYm9AenRlLmNvbS5jbg0KPiA+ID4g1vfM4g0KPiA+ID4gICAgUmU6IFN1c3Bl bmRpbmcgYW5kIFJlc3VtaW5nIG1vZGlmaWNhdGlvbiBvZiBzZXNzaW9uIG9yIA0KPiA+IHN0cmVh bT8gICAvL05ldyANCj4gPiA+IHJldmlzaW9uIG9mIHRoZSByZS1JTlZJVEUgaGFuZGxpbmcgZHJh ZnQNCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+ IA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gZ2FvLnlhbmcyQHp0ZS5jb20uY24gd3Jv dGU6DQo+ID4gPiAgPg0KPiA+ID4gID4gQ29uc2lkZXJpbmcgYSB1c2UgY2FzZSwgQSBhbmQgQiBo YXMgYSBhdWRpbyBvbmx5IHNlc3Npb24uIFRoZW4gQSANCj4gPiA+IHNlbmQgYSAgPiBSZS1JTlZJ VEUgZm9yIGFkZGluZyB2ZWRpbyBzdHJlYW0oIHdpdGggcHJlY29uZGl0aW9uKSBhbmQgDQo+ID4g PiBjaGFuZ2luZyBjb2RlYyAgPiBvciBhZGRyZXNzIGZvciBhdWRpbyBzdHJlYW0oIHdpdGhvdXQg cHJlY29uZGl0b24pLg0KPiA+ID4gID4NCj4gPiA+ICA+IElmIHN1c3BlbmRpbmcgaXMgZWZmZWN0 aXZlIGZvciB3aG9sZSBzZXNzaW9uLCB0aGVuIA0KPiA+IHN0cmVhbXMgd2l0aG91dCANCj4gPiA+ ID4gcHJlY29uZGl0aW9uIHNob3VsZCB1c2Ugb2xkIHBhcmFtZXRlcnMgd2hpbGUgaW4gc3VzcGVu ZGluZyBzdGF0ZS4NCj4gPiA+ICA+IEZvciB0aGUgdXNlIGNhc2UsIEEgYW5kIEIgc2hvdWxkIG5v dCB1c2UgbmV3IGNvZGVjIG9yIA0KPiA+IGFkZHJlc3MgZm9yIA0KPiA+ID4gYXVkaW8gID4gYmVm b3JlIHZlZGlvJ3MgcHJlY29uZGl0b24gaXMgbWV0Lg0KPiA+ID4gID4NCj4gPiA+ICA+IElmIHN1 c3BlbmRpbmcgaXMgZWZmZWN0aXZlIGZvciBzdHJlYW1zIHdpdGggDQo+ID4gcHJlY29uZGl0aW9u LCB0aGUgdGhlbiANCj4gPiA+ID4gc3RyZWFtcyB3aXRob3V0IHByZWNvbmRpdGlvIGNhbiB1c2Ug bmV3IHBhcmFtZXRlcnMgYWZ0ZXIgDQo+ID4gZmlyc3QgTy9BIA0KPiA+ID4gPiBkdXJpbmcgdGhl IFJlLUlOVklURS4NCj4gPiA+ICA+IEZvciB0aGUgdXNlIGNhc2UsIEEgYW5kIEIgY2FuIHVzZSBu ZXcgY29kZWMgb3IgYWRkcmVzcyBmb3IgYXVkaW8gDQo+ID4gPiBiZWZvcmUgID4gdmVkaW8ncyBw cmVjb25kaXRvbiBpcyBtZXQuDQo+ID4gPiAgPg0KPiA+ID4gID4NCj4gPiA+ICA+IEkgcHJlZmVy IHRoZSBmaXJzdCBvbmUsIGFzOw0KPiA+ID4gDQo+ID4gPiBZb3UgbWVhbiB0aGF0IHlvdSBwcmVm ZXIgc3VzcGVuc2lvbiBiZWluZyBmb3IgdGhlIHdob2xlIA0KPiA+IHNlc3Npb24gKCphbGwqIA0K PiA+ID4gc3RyZWFtcyk/Pz8NCj4gPiA+IA0KPiA+ID4gID4gMS4gVG8gZGVsYXkgdXNpbmcgb2Yg bmV3IHBhcmFtZXRlcnMgZm9yIHN0cmVhbSB3aXRob3V0IA0KPiA+IHByZWNvbmRpdGlvbiANCj4g PiA+IG1heSAgPiBhcm9zZSBtZWRpYSBjbGlwIHByb2JsZW0uDQo+ID4gPiAgPiAyLiBCZWhhdmlv ciBvZiBzdHJlYW1zIHdpdGhvdXQgcHJlY29uZGl0aW9uIHNob3VsZCBiZSANCj4gPiBpbmRlcGVu ZGVudCANCj4gPiA+IG9mICA+IGV4aXN0ZW5jZSBvZiBvdGhlciBzdHJlYW1zKCB3aXRoIHByZWNv bmRpdGlvbikuDQo+ID4gPiANCj4gPiA+IEl0IHNlZW1zIHlvdSBhcmUgYXJndWluZyBpbiBmYXZv ciBvZiBzdXNwZW5zaW9uIGJlaW5nIHBlci1zdHJlYW0uDQo+ID4gPiANCj4gPiA+IElNTyB0aGUg c3VzcGVuc2lvbiBiZWhhdmlvciBpcyBkZWZpbmVkIG9uIGEgcGVyLXN0cmVhbSBiYXNpcyBhbmQg c28gDQo+ID4gPiBuZWVkcyB0byBiZSBpbXBsZW1lbnRlZCB0aGF0IHdheS4NCj4gPiA+IA0KPiA+ ID4gQW5vdGhlciByZWFzb24gZm9yIHRoaXMgaXMgdGhhdCBpdCBpcyBwb3NzaWJsZSB0aGUgdmFy aW91cyANCj4gPiBzdHJlYW1zIGFyZSANCj4gPiA+IG5vdCBjb250cm9sbGVkIGJ5IHRoZSBzYW1l IGVudGl0eSwgc28gdGhhdCBjb29yZGluYXRpb24gb2YgDQo+ID4gd2hlbiB0aGV5IA0KPiA+ID4g dGFrZSBlZmZlY3QgY291bGQgYmUgcHJvYmxlbWF0aWMuDQo+ID4gPiANCj4gPiA+IElmIHNvbWVv bmUgd2FudHMgdGhlIGNoYW5nZXMgdG8gbXVsdGlwbGUgc3RyZWFtcyB0byB0YWtlIGVmZmVjdCAN Cj4gPiA+IHRvZ2V0aGVyIHRoZXkgYXJlIGZyZWUgdG8gcHV0IHByZWNvbmRpdGlvbnMgb24gdGhl bSBhbGwgYW5kIA0KPiA+ID4gc3luY2hyb25pemUgdGhlIHJlc29sdXRpb24gb2YgdGhvc2UgcHJl Y29uZGl0aW9ucy4NCj4gPiA+IA0KPiA+ID4gICAgICAgICAgICAgICAgIFRoYW5rcywNCj4gPiA+ ICAgICAgICAgICAgICAgICBQYXVsDQo+ID4gPiANCj4gPiA+ICA+ID09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09DQo+ID4gPiAgPiBaaXAgICAgOiAyMTAwMTINCj4gPiA+ICA+IFRl bCAgICA6IDg3MjExDQo+ID4gPiAgPiBUZWwyICAgOigrODYpLTAyNS01Mjg3NzIxMQ0KPiA+ID4g ID4gZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj4gPiA+ICA+ID09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09DQo+ID4gPiAgPg0KPiA+ID4gID4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+ICA+IFpURSBJ bmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiANCj4gPiBjb250YWlu ZWQgaW4gdGhpcyANCj4gPiA+IG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIn cyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCANCj4gPiA+IGNvbW11bmljYXRpb24gaXMgY29uZmlk ZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSANCj4gPiBvYmxpZ2F0ZWQgdG8gDQo+ ID4gPiBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0 aGUgY29udGVudHMgb2YgDQo+ID4gPiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KPiA+ ID4gID4gVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIA0K PiA+IGNvbmZpZGVudGlhbCBhbmQgDQo+ID4gPiBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ug b2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIA0KPiA+IHdob20gdGhleSANCj4gPiA+IGFy ZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgDQo+ ID4gcGxlYXNlIG5vdGlmeSANCj4gPiA+IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBB bnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgDQo+ID4gbWVzc2FnZSBhcmUgDQo+ID4gPiB0aG9z ZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQo+ID4gPiAgPiBUaGlzIG1lc3NhZ2UgaGFzIGJl ZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSANCj4gPiBaVEUgQW50aS1TcGFtIA0K PiA+ID4gc3lzdGVtLg0KPiA+ID4gID4NCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ ID4gPiBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIA0KPiA+IGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRl cidzIG9yZ2FuaXphdGlvbi4gDQo+ID4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlk ZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIA0KPiA+IGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFp bnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgDQo+ID4gdG8gZGlzY2xvc2UgdGhl IGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQo+ID4gPiBUaGlzIGVt YWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgDQo+ID4gY29uZmlkZW50 aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIA0KPiA+IGluZGl2aWR1 YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSANCj4g PiByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0 b3Igb2YgDQo+ID4gdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNz YWdlIGFyZSB0aG9zZSBvZiANCj4gPiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQo+ID4gPiBUaGlz IG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgDQo+ ID4gQW50aS1TcGFtIHN5c3RlbS4NCj4gPiANCj4gDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNl Y3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMg c29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBj b21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUg b2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRp c2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhp cyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlh bCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVu dGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNz YWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhl IGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZp cnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 00407EA648257619_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mcXVvdDtDaHJpc3RlciBIb2xtYmVyZyZxdW90 OyAmbHQ7Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0Ow0K0LTT2iAyMDA5LTA4LTIx IDE4OjQ2OjI4Ojxicj4NCjxicj4NCjwvdHQ+PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMDA4 MDgwPjx0dD4mZ3Q7IDxicj4NCiZndDsgSGksPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgdGhpbmsg eW91IGFyZSBhc2tpbmcgZm9yIHByb2JsZW1zIGlmIHlvdSBzdGFydCBjb21iaW5pbmcgPGJyPg0K Jmd0OyBwcmVjb25kaXRpb25zIGFuZCBub24tcHJlY29uZGl0aW9ucyBpbiBhIHJlLUlOVklURS4g PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEl0IGlzIGFscmVhZHkgZGlmZmljdWx0IGVub3VnaCB0byBi ZSBzdXJlIG9uIHdoZW4gdGhlIG5ldyBtZWRpYSA8YnI+DQomZ3Q7IHBhcmFtZXRlcnMgd2lsbCBi ZSB0YWtlbiBpbiB1c2UsIGFuZCB3aGVuIHRoZSBvbGQgb25lcyBjYW5ub3QgYmUgPGJyPg0KJmd0 OyB1c2VkIGFueW1vcmUsIHNvIGlmIGRpZmZlcmVudCBwYXJhbWV0ZXJzIGFyZSB0byBiZSB0YWtl biBpbnRvIHVzZQ0KYXQ8YnI+DQomZ3Q7IGRpZmZlcmVudCB0aW1lcyBJIHRoaW5rIGl0IHdpbGwg Y3JlYXRlIGEgbWVzcy4uLjxicj4NCiZndDsgPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yPjx0dD5XaGVuIHRvIHN3aXRjaCBmcm9tIG9sZCB0byBuZXcgcGFyYW1ldGVycyBzaG91 bGQgb2JleQ0KUkZDMzI2NC4gQW5kIHN1c3BlbmRpbmcgc2VtYW50aWMgZm9yIHNlc3Npb24gb3Ig c3RyZWFtIGlzIFJGQzMzMTIgJmFtcDsNCjQwMzIuPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yPjx0dD5UaGUgdHdvIHByb2JsZW1zIGhhdmUgcmVsYXRpb25zaGlwLCBidXQgdGhleSBoYXZl DQpzZXBhcmF0ZSBzb3VyY2VzIG9mIGRlZmludGlvbi48L3R0PjwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTI+PHR0PkFuZCBpZiB3ZSBjaG9vc2UgdGhlIHdheSBvZiAqc3VzcGVuZGluZyBz ZW1hbnRpYyBmb3INCndob2xlIHNlc3Npb24qLCB0aGVuIGFzIFBhdWwgc2FpZCB0aGF0IGNvb3Jk aW5hdGlvbiBvZiB3aGVuIHRoZXkgdGFrZSBlZmZlY3QNCmNvdWxkIGJlIHByb2JsZW1hdGljLiBJ dCBjYW4gY3JlYXRlIGEgYmlnZ2VyIG1lc3MuIDopPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yPjx0dD48YnI+DQo8L3R0PjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzAwODA4MD48dHQ+ Jmd0OyBTbywgd2h5IG5vdCBkbyB0aGUgYXVkaW8NCmNoYW5nZSBhbmQgdGhlIHZpZGVvIGNoYW5n ZSBpbiBzZXBhcmF0ZSB0cmFuc2FjdGlvbnM/PGJyPg0KJmd0OyA8L3R0PjwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTI+PHR0PkkgYWdyZWUgd2l0aCB5b3UuIEJ1dCBJIGNhbiBub3Qgc3Rv cCBwZW9wbGUgZnJvbSBkb2luZw0Kc28uPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0 dD5BbmQgd2UgcmVhbGx5IGhhdmUgZXF1aXBtZW50IGFzICp2YXJpb3VzIHN0cmVhbXMgYXJlDQpu b3QgY29udHJvbGxlZCBieSB0aGUgc2FtZSBlbnRpdHkqKCBJbiBmYWN0LCBaVEUgaGFzIGEgZXF1 aXBtZW50IGluIHRoaXMNCndheSkuIEFuZCBpdCBpcyByZWFsbHkgaGFyZCB0byB3cmFwIHZhcmlv dXMgc3RyZWFtcyBoYXMgdGhlIHNhbWUgYWJpbGl0eSwNCnN1Y2ggYXMgcHJlY29uZGl0aW9uLjwv dHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+PGJyPg0KPC90dD48L2ZvbnQ+PGZvbnQg c2l6ZT0yIGNvbG9yPSMwMDgwODA+PHR0PiZndDsgQnV0LCBJIG5lZWQgdG8gZG8gc29tZQ0KbW9y ZSB0aGlua2luZyBiZWZvcmUgYW5zd2VyaW5nIHlvdXIgcXVlc3Rpb24uPGJyPg0KJmd0OyBJbiBw cmluY2lwbGUgSSBndWVzcyBpdCB3b3VsZCBiZSBnb29kIHRvIGtlZXAgZWFjaCBtZWRpYSBzdHJl YW0gYXMNCjxicj4NCiZndDsgc2VwYXJhdGUgYXMgcG9zc2libGUsIGJ1dCB0aGUgd2F5IFNJUCwg U0RQIGFuZCB0aGUgbWVkaWEgPGJyPg0KJmd0OyBkZXNjcmlwdGlvbnMgYXJlIGJvdW5kbGVkIHRv Z2V0aGVyIHRoZXJlIG1heSBiZSBzb21lIGxpbWl0YXRpb25zLjxicj4NCiZndDsgPC90dD48L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5ZZXMuIEkgYWxzbyB0aGluayBpdCBpcyBi ZXR0ZXIgdG8gKmtlZXAgZWFjaCBtZWRpYQ0Kc3RyZWFtIGFzIHNlcGFyYXRlIGFzIHBvc3NpYmxl Ki4gU28sIEkgcHJlZmVyIHRoZSB3YXkgb2YgKnN1c3BlbmRpbmcgc2VtYW50aWMNCmZvciBzdHJl YW1zIHdpdGggcHJlY29uZGl0aW9uKi48L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0 PkFuZCBJIHRoaW5rIGl0IGlzIGJldHRlciB0byBtYWtlIGEgZGV0YWlsZWQgcmVhc29uaW5nDQpm b3IgdGhlIHR3byBhcHByb2FjaHMuPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD48 YnI+DQo8L3R0PjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzAwODA4MD48dHQ+Jmd0OyBXZSBh bHNvIG5lZWQgdG8ga2VlcCBpbg0KbWluZCB0aGF0IHRoZSBwcmVjb25kaXRpb24gbW9kaWZpY2F0 aW9uIGNhbiA8YnI+DQomZ3Q7IGZhaWwsIGFuZCB3aGF0IGhhcHBlbnMgdG8gdGhlIG5vbi1wcmVj b25kaXRpb24gY2hhbmdlIGluIHRoYXQgY2FzZS48YnI+DQomZ3Q7PC90dD48L2ZvbnQ+PGZvbnQg c2l6ZT0yPjx0dD4gPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5ZZXMs IHRoZSBwcmVjb25kaXRpb24gY2FuIGZhaWwuPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y Pjx0dD5CeSB0aGUgd2F5IGluIHRoZSBkcmFmdDo8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTI+PHR0PkFuZCBhcyBpdCh0aGUgcHJlY29uZGl0aW9uIHN0cmVhbSkgaXMgbm90IHVzZWQsIGFu ZA0KdGhlIG5vbi1wcmVjb25kaXRpb24gaXMgdXNlZChpbiBjYXNlIG9mIGhhdmluZyBkb25lIHRo ZSBmaXJzdCBPL0EpLCBVQQ0KY2FuIHNlbmQgYSBVUERBVEUgd2l0aCBub24tcHJlY29uZGl0aW9u IHN0cmVhbShieSBSRkMzMjY0LCB0aGUgcHJlY29uZGl0b24NCnN0cmVhbSBzaG91bGQgYmUgc2V0 IGFzIHBvcnQ9MCkgdG8gc2hvdyB0aGUgcm9sbGJhY2sgc3RhdGUgb2Ygc2Vzc2lvbi48L3R0Pjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0Pjxicj4NCiZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7 IDxicj4NCiZndDsgQ2hyaXN0ZXI8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJz cDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxi cj4NCiZndDsgJmd0OyBGcm9tOiBQYXVsIEt5eml2YXQgW21haWx0bzpwa3l6aXZhdEBjaXNjby5j b21dIDxicj4NCiZndDsgJmd0OyBTZW50OiAyMC4gZWxva3V1dGEgMjAwOSAyMjowMDxicj4NCiZn dDsgJmd0OyBUbzogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQomZ3Q7ICZndDsgQ2M6IENocmlz dGVyIEhvbG1iZXJnOyBHb256YWxvIENhbWFyaWxsbzsgU0lQQ09SRTsgPGJyPg0KJmd0OyAmZ3Q7 IHdhbmcubGlib0B6dGUuY29tLmNuPGJyPg0KJmd0OyAmZ3Q7IFN1YmplY3Q6IFJlOiC08Li0OiBS ZTogU3VzcGVuZGluZyBhbmQgUmVzdW1pbmcgbW9kaWZpY2F0aW9uDQpvZiA8YnI+DQomZ3Q7ICZn dDsgc2Vzc2lvbiBvciBzdHJlYW0/IC8vTmV3IHJldmlzaW9uIG9mIHRoZSByZS1JTlZJVEUgaGFu ZGxpbmcgZHJhZnQ8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgZ2FvLnlhbmcyQHp0ZS5jb20uY24gd3JvdGU6PGJyPg0KJmd0OyAm Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgSGkgUGF1bCw8YnI+DQomZ3Q7ICZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBBcyB5b3UgY2FuIHNlZSB0aGF0IGkgYW0gYXJndWluZyBp biBmYXZvciBvZiBzdXNwZW5zaW9uDQpiZWluZyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBwZXItc3Ry ZWFtIDopLjxicj4NCiZndDsgJmd0OyAmZ3Q7IEl0IGlzIGEgY2xlcmljYWwgZXJyb3IuIEkgcHJl ZmVyICZxdW90O3N1c3BlbmRpbmcgaXMgZWZmZWN0aXZlDQo8YnI+DQomZ3Q7ICZndDsgZm9yIHN0 cmVhbXMgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgd2l0aCBwcmVjb25kaXRpb24mcXVvdDssIHRoZSAy c3Qgb25lLjxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEJ1dCBSRkMg MzMxMiAmYW1wOyA0MDMyIGhhcyBzdWNoIGRlc2NyaXB0aW9uOjxicj4NCiZndDsgJmd0OyAmZ3Q7 IFdoaWxlIHNlc3Npb24gZXN0YWJsaXNobWVudCBpcyBzdXNwZW5kZWQoZm9yIFFvUyB0eXBlIDxi cj4NCiZndDsgJmd0OyBwcmVjb25kaXRpb24pLCA8YnI+DQomZ3Q7ICZndDsgJmd0OyB1c2VyIGFn ZW50cyBTSE9VTEQgbm90IHNlbmQgYW55IGRhdGEgb3ZlciAqYW55IG1lZGlhIDxicj4NCiZndDsg Jmd0OyBzdHJlYW0qLiAmbmJzcDtJbiB0aGUgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgY2FzZSBvZiBS VFAsIG5laXRoZXIgUlRQIG5vciBSVENQIHBhY2tldHMgYXJlIHNlbnQuPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgU28sIGRvIHdlIG5lZWQgY29ycmVjdGlvbiBmb3Ig dGhpcz88YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEkgaGF2ZW4ndCB0aG91Z2h0IGFi b3V0IGl0IGEgbG90LCBidXQgbXkgaW1tZWRpYXRlIHJlYWN0aW9uIDxicj4NCiZndDsgJmd0OyBp cyAqeWVzKiwgdGhpcyBkb2Vzbid0IHNlZW0gcmlnaHQuIEkgd291bGQgbGlrZSB0byBoZWFyIHdo YXQNCjxicj4NCiZndDsgJmd0OyBHb256YWxvIHRoaW5rcy48YnI+DQomZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7IEluIHRoZSB3cml0aW5nIG9mIDQwMzIsIEkgdGhpbmsgdGhlIGZvY3VzIGhlcmUg d2FzIG9uIDxicj4NCiZndDsgJmd0OyBuYXJyb3dpbmcgdGhlIHNjb3BlIG9mIHRoaXMgbGltaXRh dGlvbiwgc28gdGhhdCBpdCBhcHBsaWVkIDxicj4NCiZndDsgJmd0OyBvbmx5IHRvIFFvUyBhbmQg bm90IG90aGVyIHByZWNvbmRpdGlvbiB0eXBlcy4gSSBkb24ndCB0aGluayA8YnI+DQomZ3Q7ICZn dDsgYXkgY29uc2lkZXJhdGlvbiB3YXMgZ2l2ZW4gdG88YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0 OyAmZ3Q7ICZuYnNwOyAmbmJzcDtUaGFua3MsPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtQ YXVsPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IFRoYW5rcy48YnI+DQomZ3Q7 ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBHYW88YnI+DQomZ3Q7ICZndDsgJmd0OyA8 YnI+DQomZ3Q7ICZndDsgJmd0OyA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxi cj4NCiZndDsgJmd0OyAmZ3Q7IFppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQomZ3Q7ICZn dDsgJmd0OyBUZWwgJm5ic3A7ICZuYnNwOzogODcyMTE8YnI+DQomZ3Q7ICZndDsgJmd0OyBUZWwy ICZuYnNwOyA6KCs4NiktMDI1LTUyODc3MjExPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZV9tYWlsIDog Z2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQomZ3Q7ICZndDsgJmd0OyA9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PTxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICpQYXVsIEt5eml2YXQgJmx0O3BreXppdmF0QGNpc2Nv LmNvbSZndDsqPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgMjAwOS0w OC0yMCAyMTowMTxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNw OyAmbmJzcDs8YnI+DQomZ3Q7ICZndDsgJmd0OyDK1bz+yMs8YnI+DQomZ3Q7ICZndDsgJmd0OyAm bmJzcDsgJm5ic3A7Z2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQomZ3Q7ICZndDsgJmd0OyCzrcvN PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO1NJUENPUkUgJmx0O3NpcGNvcmVAaWV0 Zi5vcmcmZ3Q7LCBHb256YWxvIENhbWFyaWxsbw0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmx0O0dv bnphbG8uQ2FtYXJpbGxvQGVyaWNzc29uLmNvbSZndDssIENocmlzdGVyIEhvbG1iZXJnDQo8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmbHQ7Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0Oywg d2FuZy5saWJvQHp0ZS5jb20uY248YnI+DQomZ3Q7ICZndDsgJmd0OyDW98ziPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJm5ic3A7ICZuYnNwO1JlOiBTdXNwZW5kaW5nIGFuZCBSZXN1bWluZyBtb2RpZmlj YXRpb24gb2YNCnNlc3Npb24gb3IgPGJyPg0KJmd0OyAmZ3Q7IHN0cmVhbT8gJm5ic3A7IC8vTmV3 IDxicj4NCiZndDsgJmd0OyAmZ3Q7IHJldmlzaW9uIG9mIHRoZSByZS1JTlZJVEUgaGFuZGxpbmcg ZHJhZnQ8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7ICZndDsgZ2FvLnlhbmcyQHp0ZS5jb20uY24gd3JvdGU6PGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyZndDsgQ29u c2lkZXJpbmcgYSB1c2UgY2FzZSwgQSBhbmQgQiBoYXMgYSBhdWRpbyBvbmx5DQpzZXNzaW9uLiBU aGVuIEEgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgc2VuZCBhICZuYnNwOyZndDsgUmUtSU5WSVRFIGZv ciBhZGRpbmcgdmVkaW8gc3RyZWFtKCB3aXRoDQpwcmVjb25kaXRpb24pIGFuZCA8YnI+DQomZ3Q7 ICZndDsgJmd0OyBjaGFuZ2luZyBjb2RlYyAmbmJzcDsmZ3Q7IG9yIGFkZHJlc3MgZm9yIGF1ZGlv IHN0cmVhbSggd2l0aG91dA0KcHJlY29uZGl0b24pLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNw OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsmZ3Q7IElmIHN1c3BlbmRpbmcgaXMgZWZm ZWN0aXZlIGZvciB3aG9sZSBzZXNzaW9uLA0KdGhlbiA8YnI+DQomZ3Q7ICZndDsgc3RyZWFtcyB3 aXRob3V0ICZuYnNwOzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgcHJlY29uZGl0aW9uIHNob3Vs ZCB1c2Ugb2xkIHBhcmFtZXRlcnMgd2hpbGUgaW4gc3VzcGVuZGluZw0Kc3RhdGUuPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJm5ic3A7Jmd0OyBGb3IgdGhlIHVzZSBjYXNlLCBBIGFuZCBCIHNob3VsZCBu b3QgdXNlIG5ldw0KY29kZWMgb3IgPGJyPg0KJmd0OyAmZ3Q7IGFkZHJlc3MgZm9yIDxicj4NCiZn dDsgJmd0OyAmZ3Q7IGF1ZGlvICZuYnNwOyZndDsgYmVmb3JlIHZlZGlvJ3MgcHJlY29uZGl0b24g aXMgbWV0Ljxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmbmJzcDsmZ3Q7IElmIHN1c3BlbmRpbmcgaXMgZWZmZWN0aXZlIGZvciBzdHJlYW1zIHdpdGgg PGJyPg0KJmd0OyAmZ3Q7IHByZWNvbmRpdGlvbiwgdGhlIHRoZW4gJm5ic3A7PGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyBzdHJlYW1zIHdpdGhvdXQgcHJlY29uZGl0aW8gY2FuIHVzZSBuZXcgcGFy YW1ldGVycw0KYWZ0ZXIgPGJyPg0KJmd0OyAmZ3Q7IGZpcnN0IE8vQSAmbmJzcDs8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7IGR1cmluZyB0aGUgUmUtSU5WSVRFLjxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZuYnNwOyZndDsgRm9yIHRoZSB1c2UgY2FzZSwgQSBhbmQgQiBjYW4gdXNlIG5ldyBjb2RlYyBv cg0KYWRkcmVzcyBmb3IgYXVkaW8gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgYmVmb3JlICZuYnNwOyZn dDsgdmVkaW8ncyBwcmVjb25kaXRvbiBpcyBtZXQuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7 Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAm bmJzcDsmZ3Q7IEkgcHJlZmVyIHRoZSBmaXJzdCBvbmUsIGFzOzxicj4NCiZndDsgJmd0OyAmZ3Q7 IDxicj4NCiZndDsgJmd0OyAmZ3Q7IFlvdSBtZWFuIHRoYXQgeW91IHByZWZlciBzdXNwZW5zaW9u IGJlaW5nIGZvciB0aGUgd2hvbGUNCjxicj4NCiZndDsgJmd0OyBzZXNzaW9uICgqYWxsKiA8YnI+ DQomZ3Q7ICZndDsgJmd0OyBzdHJlYW1zKT8/Pzxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZuYnNwOyZndDsgMS4gVG8gZGVsYXkgdXNpbmcgb2YgbmV3IHBhcmFtZXRl cnMgZm9yIHN0cmVhbQ0Kd2l0aG91dCA8YnI+DQomZ3Q7ICZndDsgcHJlY29uZGl0aW9uIDxicj4N CiZndDsgJmd0OyAmZ3Q7IG1heSAmbmJzcDsmZ3Q7IGFyb3NlIG1lZGlhIGNsaXAgcHJvYmxlbS48 YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsmZ3Q7IDIuIEJlaGF2aW9yIG9mIHN0cmVhbXMgd2l0 aG91dCBwcmVjb25kaXRpb24gc2hvdWxkDQpiZSA8YnI+DQomZ3Q7ICZndDsgaW5kZXBlbmRlbnQg PGJyPg0KJmd0OyAmZ3Q7ICZndDsgb2YgJm5ic3A7Jmd0OyBleGlzdGVuY2Ugb2Ygb3RoZXIgc3Ry ZWFtcyggd2l0aCBwcmVjb25kaXRpb24pLjxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyAmZ3Q7IEl0IHNlZW1zIHlvdSBhcmUgYXJndWluZyBpbiBmYXZvciBvZiBzdXNwZW5zaW9u IGJlaW5nIHBlci1zdHJlYW0uPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgSU1PIHRoZSBzdXNwZW5zaW9uIGJlaGF2aW9yIGlzIGRlZmluZWQgb24gYSBwZXItc3RyZWFt IGJhc2lzDQphbmQgc28gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgbmVlZHMgdG8gYmUgaW1wbGVtZW50 ZWQgdGhhdCB3YXkuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQW5v dGhlciByZWFzb24gZm9yIHRoaXMgaXMgdGhhdCBpdCBpcyBwb3NzaWJsZSB0aGUgdmFyaW91cw0K PGJyPg0KJmd0OyAmZ3Q7IHN0cmVhbXMgYXJlIDxicj4NCiZndDsgJmd0OyAmZ3Q7IG5vdCBjb250 cm9sbGVkIGJ5IHRoZSBzYW1lIGVudGl0eSwgc28gdGhhdCBjb29yZGluYXRpb24NCm9mIDxicj4N CiZndDsgJmd0OyB3aGVuIHRoZXkgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdGFrZSBlZmZlY3QgY291 bGQgYmUgcHJvYmxlbWF0aWMuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgSWYgc29tZW9uZSB3YW50cyB0aGUgY2hhbmdlcyB0byBtdWx0aXBsZSBzdHJlYW1zIHRvIHRh a2UNCmVmZmVjdCA8YnI+DQomZ3Q7ICZndDsgJmd0OyB0b2dldGhlciB0aGV5IGFyZSBmcmVlIHRv IHB1dCBwcmVjb25kaXRpb25zIG9uIHRoZW0gYWxsDQphbmQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg c3luY2hyb25pemUgdGhlIHJlc29sdXRpb24gb2YgdGhvc2UgcHJlY29uZGl0aW9ucy48YnI+DQom Z3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpUaGFua3MsPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOw0KUGF1bDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNw OyZndDsgPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQomZ3Q7ICZndDsg Jmd0OyAmbmJzcDsmZ3Q7IFppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmbmJzcDsmZ3Q7IFRlbCAmbmJzcDsgJm5ic3A7OiA4NzIxMTxicj4NCiZndDsgJmd0OyAm Z3Q7ICZuYnNwOyZndDsgVGVsMiAmbmJzcDsgOigrODYpLTAyNS01Mjg3NzIxMTxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZuYnNwOyZndDsgZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQom Z3Q7ICZndDsgJmd0OyAmbmJzcDsmZ3Q7ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZu YnNwOyZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsmZ3Q7IFpURSBJbmZvcm1hdGlvbiBT ZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbg0KPGJyPg0KJmd0OyAmZ3Q7IGNvbnRhaW5l ZCBpbiB0aGlzIDxicj4NCiZndDsgJmd0OyAmZ3Q7IG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9m IHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMNCm1haWwgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUg YXJlDQo8YnI+DQomZ3Q7ICZndDsgb2JsaWdhdGVkIHRvIDxicj4NCiZndDsgJmd0OyAmZ3Q7IG1h aW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250 ZW50cw0Kb2YgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVy cy48YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsmZ3Q7IFRoaXMgZW1haWwgYW5kIGFueSBmaWxl cyB0cmFuc21pdHRlZCB3aXRoIGl0DQphcmUgPGJyPg0KJmd0OyAmZ3Q7IGNvbmZpZGVudGlhbCBh bmQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRo ZSBpbmRpdmlkdWFsIG9yIGVudGl0eQ0KdG8gPGJyPg0KJmd0OyAmZ3Q7IHdob20gdGhleSA8YnI+ DQomZ3Q7ICZndDsgJmd0OyBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yDQo8YnI+DQomZ3Q7ICZndDsgcGxlYXNlIG5vdGlmeSA8YnI+DQomZ3Q7 ICZndDsgJmd0OyB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJl c3NlZCBpbiB0aGlzDQo8YnI+DQomZ3Q7ICZndDsgbWVzc2FnZSBhcmUgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLjxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZuYnNwOyZndDsgVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5k DQpTcGFtIGJ5IDxicj4NCiZndDsgJmd0OyBaVEUgQW50aS1TcGFtIDxicj4NCiZndDsgJmd0OyAm Z3Q7IHN5c3RlbS48YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08YnI+DQomZ3Q7ICZndDsgJmd0OyBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkg Tm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkDQo8YnI+DQomZ3Q7ICZndDsgaW4gdGhp cyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLg0K PGJyPg0KJmd0OyAmZ3Q7IFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4g UmVjaXBpZW50cyBuYW1lZCA8YnI+DQomZ3Q7ICZndDsgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBt YWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZA0KPGJyPg0KJmd0OyAmZ3Q7IHRv IGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLjxi cj4NCiZndDsgJmd0OyAmZ3Q7IFRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3 aXRoIGl0IGFyZSA8YnI+DQomZ3Q7ICZndDsgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xl bHkgZm9yIHRoZSB1c2Ugb2YgdGhlIDxicj4NCiZndDsgJmd0OyBpbmRpdmlkdWFsIG9yIGVudGl0 eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUNCjxicj4NCiZndDsgJmd0 OyByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0 b3Igb2YNCjxicj4NCiZndDsgJmd0OyB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBp biB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mDQo8YnI+DQomZ3Q7ICZndDsgdGhlIGluZGl2aWR1 YWwgc2VuZGVyLjxicj4NCiZndDsgJmd0OyAmZ3Q7IFRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2Fu bmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURQ0KPGJyPg0KJmd0OyAmZ3Q7IEFudGktU3Bh bSBzeXN0ZW0uPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgPGJyPg0KPC90dD48L2ZvbnQ+DQo8 YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNl OiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0 aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZu YnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDtt YWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1Jl Y2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5i c3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtu b3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29u dGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtv dGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNw O3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFs Jm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJz cDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0 eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5i c3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1h aWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5i c3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJz cDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJz cDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3Nl bmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQm bmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRF Jm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 00407EA648257619_=-- From pkyzivat@cisco.com Fri Aug 21 06:08:07 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E4E03A6845 for ; Fri, 21 Aug 2009 06:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=-3.710, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_93=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHLwK+weNI+y for ; Fri, 21 Aug 2009 06:08:06 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B80183A6D2D for ; Fri, 21 Aug 2009 06:08:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABA5jkpAZnmf/2dsb2JhbAC8ZoZngUiQfwWBLoELgRhHgVRT X-IronPort-AV: E=Sophos;i="4.44,250,1249257600"; d="scan'208";a="54979281" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 21 Aug 2009 13:08:09 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7LD89Hj011618; Fri, 21 Aug 2009 09:08:09 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7LD8933022593; Fri, 21 Aug 2009 13:08:09 GMT 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.3959); Fri, 21 Aug 2009 09:08:09 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 09:08:09 -0400 Message-ID: <4A8E9C34.8060507@cisco.com> Date: Fri, 21 Aug 2009 09:08:04 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4A8D9D14.3010904@cisco.com> In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 21 Aug 2009 13:08:09.0296 (UTC) FILETIME=[6E1B2D00:01CA2260] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7557; t=1250860089; x=1251724089; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20=3D?GB2312?B?tPC4tDogUmU6IFN1c3BlbmRpbm cgYW5kIFJlc3VtaW5nIG1vZA=3D=3D?=3D=0A=20=3D?GB2312?B?aWZpY2F 0aW9uIG9mIHNlc3Npb24gb3Igc3RyZWFtPyAgIC8vTmV3IHJldmlzaQ=3D=3 D?=3D=0A=20=3D?GB2312?B?b24gb2YgdGhlIHJlLUlOVklURSBoYW5kbGlu ZyBkcmFmdA=3D=3D?=3D |Sender:=20 |To:=20Christer=20Holmberg=20; bh=VPehI8FjcMcZo5jl+nR2NLvLBlPcLqkQv1usp8SixhY=; b=YCu/iflHK0mY4CT3a1nrxRpkC4FTMJflGfGp97YMJyK5jyVA0U/DWctEfK mG24LY2sx3fYrwomRnJ4p6eP1n3fln2nBWLIjCJRI/2QomecgAHxyswrwV3v PZ2QTZ4eRn; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: gao.yang2@zte.com.cn, SIPCORE , wang.libo@zte.com.cn, Gonzalo Camarillo Subject: Re: [sipcore] =?gb2312?b?tPC4tDogUmU6IFN1c3BlbmRpbmcgYW5kIFJlc3VtaW5n?= =?gb2312?b?IG1vZGlmaWNhdGlvbiBvZiBzZXNzaW9uIG9yIHN0cmVhbT8gICAvL05ldyBy?= =?gb2312?b?ZXZpc2lvbiBvZiB0aGUgcmUtSU5WSVRFIGhhbmRsaW5nIGRyYWZ0?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 13:08:07 -0000 Christer Holmberg wrote: > Hi, > > I think you are asking for problems if you start combining preconditions and non-preconditions in a re-INVITE. Well, do you have a choice? Suppose you have a regular audio session without preconditions. Then you want to add video, but know you must have preconditions in order to have a successful video session. Do you put new preconditions on the audio stream just to be consistent? > It is already difficult enough to be sure on when the new media parameters will be taken in use, and when the old ones cannot be used anymore, so if different parameters are to be taken into use at different times I think it will create a mess... Like most things, its confusing until somebody thinks through the details. Perhaps a use cases draft would be helpful here. Gao? > So, why not do the audio change and the video change in separate transactions? That is a possibility, unless you *need* a matching audio change to go with the video. (Perhaps something has to be changed to assure lip sync.) > But, I need to do some more thinking before answering your question. In principle I guess it would be good to keep each media stream as separate as possible, but the way SIP, SDP and the media descriptions are boundled together there may be some limitations. I think that principle is important. > We also need to keep in mind that the precondition modification can fail, and what happens to the non-precondition change in that case. Gonzalo's draft addresses that part. Thanks, Paul > Regards, > > Christer > > > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 20. elokuuta 2009 22:00 >> To: gao.yang2@zte.com.cn >> Cc: Christer Holmberg; Gonzalo Camarillo; SIPCORE; >> wang.libo@zte.com.cn >> Subject: Re: 答复: Re: Suspending and Resuming modification of >> session or stream? //New revision of the re-INVITE handling draft >> >> >> >> gao.yang2@zte.com.cn wrote: >>> Hi Paul, >>> >>> As you can see that i am arguing in favor of suspension being >>> per-stream :). >>> It is a clerical error. I prefer "suspending is effective >> for streams >>> with precondition", the 2st one. >>> >>> But RFC 3312 & 4032 has such description: >>> While session establishment is suspended(for QoS type >> precondition), >>> user agents SHOULD not send any data over *any media >> stream*. In the >>> case of RTP, neither RTP nor RTCP packets are sent. >>> >>> So, do we need correction for this? >> I haven't thought about it a lot, but my immediate reaction >> is *yes*, this doesn't seem right. I would like to hear what >> Gonzalo thinks. >> >> In the writing of 4032, I think the focus here was on >> narrowing the scope of this limitation, so that it applied >> only to QoS and not other precondition types. I don't think >> ay consideration was given to >> >> Thanks, >> Paul >> >>> Thanks. >>> >>> Gao >>> >>> =================================== >>> Zip : 210012 >>> Tel : 87211 >>> Tel2 :(+86)-025-52877211 >>> e_mail : gao.yang2@zte.com.cn >>> =================================== >>> >>> >>> *Paul Kyzivat * >>> >>> 2009-08-20 21:01 >>> >>> >>> 收件人 >>> gao.yang2@zte.com.cn >>> 抄送 >>> SIPCORE , Gonzalo Camarillo >>> , Christer Holmberg >>> , wang.libo@zte.com.cn >>> 主题 >>> Re: Suspending and Resuming modification of session or >> stream? //New >>> revision of the re-INVITE handling draft >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> gao.yang2@zte.com.cn wrote: >>> > >>> > Considering a use case, A and B has a audio only session. Then A >>> send a > Re-INVITE for adding vedio stream( with precondition) and >>> changing codec > or address for audio stream( without preconditon). >>> > >>> > If suspending is effective for whole session, then >> streams without >>>> precondition should use old parameters while in suspending state. >>> > For the use case, A and B should not use new codec or >> address for >>> audio > before vedio's preconditon is met. >>> > >>> > If suspending is effective for streams with >> precondition, the then >>>> streams without preconditio can use new parameters after >> first O/A >>>> during the Re-INVITE. >>> > For the use case, A and B can use new codec or address for audio >>> before > vedio's preconditon is met. >>> > >>> > >>> > I prefer the first one, as; >>> >>> You mean that you prefer suspension being for the whole >> session (*all* >>> streams)??? >>> >>> > 1. To delay using of new parameters for stream without >> precondition >>> may > arose media clip problem. >>> > 2. Behavior of streams without precondition should be >> independent >>> of > existence of other streams( with precondition). >>> >>> It seems you are arguing in favor of suspension being per-stream. >>> >>> IMO the suspension behavior is defined on a per-stream basis and so >>> needs to be implemented that way. >>> >>> Another reason for this is that it is possible the various >> streams are >>> not controlled by the same entity, so that coordination of >> when they >>> take effect could be problematic. >>> >>> If someone wants the changes to multiple streams to take effect >>> together they are free to put preconditions on them all and >>> synchronize the resolution of those preconditions. >>> >>> Thanks, >>> Paul >>> >>> > =================================== >>> > Zip : 210012 >>> > Tel : 87211 >>> > Tel2 :(+86)-025-52877211 >>> > e_mail : gao.yang2@zte.com.cn >>> > =================================== >>> > >>> > -------------------------------------------------------- >>> > ZTE Information Security Notice: The information >> contained in this >>> mail is solely property of the sender's organization. This mail >>> communication is confidential. Recipients named above are >> obligated to >>> maintain secrecy and are not permitted to disclose the contents of >>> this communication to others. >>> > This email and any files transmitted with it are >> confidential and >>> intended solely for the use of the individual or entity to >> whom they >>> are addressed. If you have received this email in error >> please notify >>> the originator of the message. Any views expressed in this >> message are >>> those of the individual sender. >>> > This message has been scanned for viruses and Spam by >> ZTE Anti-Spam >>> system. >>> > >>> >>> >>> >>> -------------------------------------------------------- >>> ZTE Information Security Notice: The information contained >> in this mail is solely property of the sender's organization. >> This mail communication is confidential. Recipients named >> above are obligated to maintain secrecy and are not permitted >> to disclose the contents of this communication to others. >>> This email and any files transmitted with it are >> confidential and intended solely for the use of the >> individual or entity to whom they are addressed. If you have >> received this email in error please notify the originator of >> the message. Any views expressed in this message are those of >> the individual sender. >>> This message has been scanned for viruses and Spam by ZTE >> Anti-Spam system. >> > From dean.willis@softarmor.com Fri Aug 21 07:45:51 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 611663A6AB4 for ; Fri, 21 Aug 2009 07:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YX-kuupZVIWz for ; Fri, 21 Aug 2009 07:45:50 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 843903A68DB for ; Fri, 21 Aug 2009 07:45:50 -0700 (PDT) Received: from www.softarmor.com (www-data@localhost [127.0.0.1]) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n7LEjqdc001552; Fri, 21 Aug 2009 09:45:52 -0500 Received: from 65.65.155.30 (SquirrelMail authenticated user sipdean) by www.softarmor.com with HTTP; Fri, 21 Aug 2009 14:45:53 -0000 (UTC) Message-ID: In-Reply-To: References: <1ECE0EB50388174790F9694F77522CCF1F917C0B@zrc2hxm0.corp.nortel.com> Date: Fri, 21 Aug 2009 14:45:53 -0000 (UTC) From: "Dean Willis" To: "Christer Holmberg" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: SIPCORE Subject: Re: [sipcore] Outbound and simultaneous registration transactions X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 14:45:51 -0000 On Fri, August 21, 2009 5:25 am, Christer Holmberg wrote: > Some clarification needed? > > > ________________________________ > > From: Francois Audet [mailto:audet@nortel.com] > Sent: 21. elokuuta 2009 2:37 > To: Christer Holmberg; SIPCORE > Subject: RE: Outbound and simultaneous registration transactions > > > I believe you are correct. > > > ________________________________ > > From: Christer Holmberg > [mailto:christer.holmberg@ericsson.com] > Sent: Sunday, August 09, 2009 04:45 > To: SIPCORE > Cc: Audet, Francois (SC100:3055) > Subject: Outbound and simultaneous registration > transactions > > > > > Hi outbound lovers, > > Section 10.2 of RFC 3261 says: > > "UAs MUST NOT send a new registration (that is, > containing new Contact > header field values, as opposed to a retransmission) > until they have > received a final response from the registrar for the > previous one or > the previous REGISTER request has timed out." > > > Q1: I don't find any text in the outbound spec which > would allow sending new registrations for the SAME Contact header value > until a response has been received from the previous register (or the > prevoius has timed out). So, my assumption is that the > only-one-register-transaction-at-a-time rule also applies to outbound, > or? > The intent of the 3261 rule as I understand it is only one registration per contact/registrar pair at the same time, otherwise the registrar is hard-pressed to keep the registrations straight. That is, we get a race condition that makes it hard to determine which of the two overlapped registrations is "right", as the general assumption is that one registration is replacing another. In outbound, we have two effectively different registrations occurring, generally via disjoint paths. This eliminates the race condition, so the restriction is not needed. > > Section 6 of outbound says: > > "The registrar MUST be prepared to receive, > simultaneously for the same AOR, some registrations that use instance-id > and reg-id and some registrations that do not." > > I assume "simultaneously" doesn't refer to simultaneous > registration transactions, but simultaneus valid registrations. > That's reasonable. One could certainly have two different UACs executing REGISTER transactions simultaneously. Outbound effectively makes one UAC look like two UACs to the registrar. -- Dean From gao.yang2@zte.com.cn Fri Aug 21 08:40:24 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48C623A6E1B for ; Fri, 21 Aug 2009 08:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.039 X-Spam-Level: X-Spam-Status: No, score=-96.039 tagged_above=-999 required=5 tests=[AWL=0.954, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAYDnOP3to7S for ; Fri, 21 Aug 2009 08:40:23 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id A217D3A6C2D for ; Fri, 21 Aug 2009 08:40:21 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111641727820181; Fri, 21 Aug 2009 23:19:49 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.100] with StormMail ESMTP id 5479.6396279943; Fri, 21 Aug 2009 23:31:37 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n7LFee7J098461; Fri, 21 Aug 2009 23:40:40 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4A8E9C34.8060507@cisco.com> To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 21 Aug 2009 23:39:12 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-08-21 23:40:19, Serialize complete at 2009-08-21 23:40:19 Content-Type: multipart/alternative; boundary="=_alternative 0056152248257619_=" X-MAIL: mse2.zte.com.cn n7LFee7J098461 Cc: SIPCORE , wang.libo@zte.com.cn, Gonzalo Camarillo Subject: [sipcore] =?gb2312?b?tPC4tDogUmU6ILTwuLQ6IFJlOiBTdXNwZW5kaW5nIGFu?= =?gb2312?b?ZCBSZXN1bWluZyBtb2RpZmljYXRpb24gb2Ygc2Vzc2lvbiBvciBzdHJlYW0/?= =?gb2312?b?ICAgLy9OZXcgcmV2aXNpb24gb2YgdGhlIHJlLUlOVklURSBoYW5kbGluZyBk?= =?gb2312?b?cmFmdA==?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 15:40:24 -0000 This is a multipart message in MIME format. --=_alternative 0056152248257619_= Content-Type: text/plain; charset="US-ASCII" > > Like most things, its confusing until somebody thinks through the > details. Perhaps a use cases draft would be helpful here. Gao? OK. I will do it next week. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0056152248257619_= Content-Type: text/html; charset="US-ASCII"

>
> Like most things, its confusing until somebody thinks through the
> details. Perhaps a use cases draft would be helpful here. Gao?

OK. I will do it next week.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0056152248257619_=-- From christer.holmberg@ericsson.com Fri Aug 21 14:17:13 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D28B3A6BB7 for ; Fri, 21 Aug 2009 14:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.254 X-Spam-Level: X-Spam-Status: No, score=-3.254 tagged_above=-999 required=5 tests=[AWL=-1.605, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNnnjui4wa1O for ; Fri, 21 Aug 2009 14:17:12 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 4E3663A6B94 for ; Fri, 21 Aug 2009 14:17:11 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-76-4a8f0edbb2d2 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 26.D5.18827.BDE0F8A4; Fri, 21 Aug 2009 23:17:15 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 23:16:24 +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 Date: Fri, 21 Aug 2009 23:16:23 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ??: Re: Suspending and Resuming modification of session or stream? //New revision of the re-INVITE handling draft Thread-Index: AcoiYHD84fwG++cDRyaNhELp5CNGyQAQwfjm References: <4A8D9D14.3010904@cisco.com> <4A8E9C34.8060507@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 21 Aug 2009 21:16:24.0161 (UTC) FILETIME=[A334D510:01CA22A4] X-Brightmail-Tracker: AAAAAA== Cc: gao.yang2@zte.com.cn, SIPCORE , wang.libo@zte.com.cn, Gonzalo Camarillo Subject: Re: [sipcore] ??: Re: Suspending and Resuming modification of session or stream? //New revision of the re-INVITE handling draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 21:17:13 -0000 Hi, =20 >>I think you are asking for problems if you start combining = preconditions and non-preconditions in a re-INVITE. > >Well, do you have a choice? >Suppose you have a regular audio session without preconditions. >Then you want to add video, but know you must have preconditions in >order to have a successful video session. >Do you put new preconditions on the audio stream just to be consistent? Well, you could do that. That way you would ensure that the changes are = "activated" at the same time, which may be useful for the lip synch case = you describe further down. >>So, why not do the audio change and the video change in separate = transactions? > >That is a possibility, unless you *need* a matching audio change to go = with the video. (Perhaps something has to be changed to assure lip = sync.) That would assume that the non-precondition audio media change isn't = "activated" until the precondition media does, right? But, in that case you could use preconditions also for the audio media, = as mentioned earlier. =20 AND, things get even more fun when you start adding CapNeg stuff, and = you may need additional offer/answers just for that :) >>But, I need to do some more thinking before answering your question. = In principle I guess it would be good to keep each media stream as = separate as possible, but the way SIP, SDP and the media descriptions = are boundled together there may be some limitations. > >I think that principle is important. > >>We also need to keep in mind that the precondition modification can = fail, and what happens to the non-precondition change in that case. > >Gonzalo's draft addresses that part. Yes, I know. I was just thinking whether it would somehow have an impact = on which of Gao's alternatives would make more sense. Regards, Christer =20 =20 =20 >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 20. elokuuta 2009 22:00 >> To: gao.yang2@zte.com.cn >> Cc: Christer Holmberg; Gonzalo Camarillo; SIPCORE; >> wang.libo@zte.com.cn >> Subject: Re: ??: Re: Suspending and Resuming modification of >> session or stream? //New revision of the re-INVITE handling draft >> >> >> >> gao.yang2@zte.com.cn wrote: >>> Hi Paul, >>> >>> As you can see that i am arguing in favor of suspension being >>> per-stream :). >>> It is a clerical error. I prefer "suspending is effective >> for streams >>> with precondition", the 2st one. >>> >>> But RFC 3312 & 4032 has such description: >>> While session establishment is suspended(for QoS type >> precondition), >>> user agents SHOULD not send any data over *any media >> stream*. In the >>> case of RTP, neither RTP nor RTCP packets are sent. >>> >>> So, do we need correction for this? >> I haven't thought about it a lot, but my immediate reaction >> is *yes*, this doesn't seem right. I would like to hear what >> Gonzalo thinks. >> >> In the writing of 4032, I think the focus here was on >> narrowing the scope of this limitation, so that it applied >> only to QoS and not other precondition types. I don't think >> ay consideration was given to >> >> Thanks, >> Paul >> >>> Thanks. >>> >>> Gao >>> >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> Zip : 210012 >>> Tel : 87211 >>> Tel2 :(+86)-025-52877211 >>> e_mail : gao.yang2@zte.com.cn >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> >>> *Paul Kyzivat * >>> >>> 2009-08-20 21:01 >>> >>> =20 >>> ??? >>> gao.yang2@zte.com.cn >>> ?? >>> SIPCORE , Gonzalo Camarillo >>> , Christer Holmberg >>> , wang.libo@zte.com.cn >>> ?? >>> Re: Suspending and Resuming modification of session or >> stream? //New >>> revision of the re-INVITE handling draft >>> >>> >>> =20 >>> >>> >>> >>> >>> >>> >>> >>> gao.yang2@zte.com.cn wrote: >>> > >>> > Considering a use case, A and B has a audio only session. Then A >>> send a > Re-INVITE for adding vedio stream( with precondition) and >>> changing codec > or address for audio stream( without preconditon). >>> > >>> > If suspending is effective for whole session, then >> streams without=20 >>>> precondition should use old parameters while in suspending state. >>> > For the use case, A and B should not use new codec or >> address for >>> audio > before vedio's preconditon is met. >>> > >>> > If suspending is effective for streams with >> precondition, the then=20 >>>> streams without preconditio can use new parameters after >> first O/A=20 >>>> during the Re-INVITE. >>> > For the use case, A and B can use new codec or address for audio >>> before > vedio's preconditon is met. >>> > >>> > >>> > I prefer the first one, as; >>> >>> You mean that you prefer suspension being for the whole >> session (*all* >>> streams)??? >>> >>> > 1. To delay using of new parameters for stream without >> precondition >>> may > arose media clip problem. >>> > 2. Behavior of streams without precondition should be >> independent >>> of > existence of other streams( with precondition). >>> >>> It seems you are arguing in favor of suspension being per-stream. >>> >>> IMO the suspension behavior is defined on a per-stream basis and so >>> needs to be implemented that way. >>> >>> Another reason for this is that it is possible the various >> streams are >>> not controlled by the same entity, so that coordination of >> when they >>> take effect could be problematic. >>> >>> If someone wants the changes to multiple streams to take effect >>> together they are free to put preconditions on them all and >>> synchronize the resolution of those preconditions. >>> >>> Thanks, >>> Paul >>> >>> > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> > Zip : 210012 >>> > Tel : 87211 >>> > Tel2 :(+86)-025-52877211 >>> > e_mail : gao.yang2@zte.com.cn >>> > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> > >>> > -------------------------------------------------------- >>> > ZTE Information Security Notice: The information >> contained in this >>> mail is solely property of the sender's organization. This mail >>> communication is confidential. Recipients named above are >> obligated to >>> maintain secrecy and are not permitted to disclose the contents of >>> this communication to others. >>> > This email and any files transmitted with it are >> confidential and >>> intended solely for the use of the individual or entity to >> whom they >>> are addressed. If you have received this email in error >> please notify >>> the originator of the message. Any views expressed in this >> message are >>> those of the individual sender. >>> > This message has been scanned for viruses and Spam by >> ZTE Anti-Spam >>> system. >>> > >>> >>> >>> >>> -------------------------------------------------------- >>> ZTE Information Security Notice: The information contained >> in this mail is solely property of the sender's organization. >> This mail communication is confidential. Recipients named >> above are obligated to maintain secrecy and are not permitted >> to disclose the contents of this communication to others. >>> This email and any files transmitted with it are >> confidential and intended solely for the use of the >> individual or entity to whom they are addressed. If you have >> received this email in error please notify the originator of >> the message. Any views expressed in this message are those of >> the individual sender. >>> This message has been scanned for viruses and Spam by ZTE >> Anti-Spam system. >> > From lylavoie@iol.unh.edu Mon Aug 24 13:30:31 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5A1428C291 for ; Mon, 24 Aug 2009 13:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5vxW2OPKR40 for ; Mon, 24 Aug 2009 13:30:30 -0700 (PDT) Received: from postal.iol.unh.edu (postal.iol.unh.edu [132.177.123.84]) by core3.amsl.com (Postfix) with ESMTP id C00A43A6AA3 for ; Mon, 24 Aug 2009 13:30:30 -0700 (PDT) Received: from [132.177.124.164] (d124164.iol.unh.edu [132.177.124.164]) (authenticated bits=0) by postal.iol.unh.edu (8.14.0/8.14.0) with ESMTP id n7OKUYaY003195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 24 Aug 2009 16:30:34 -0400 Message-ID: <4A92F86A.7000504@iol.unh.edu> Date: Mon, 24 Aug 2009 16:30:34 -0400 From: "Lincoln Y. Lavoie" Organization: UNH-IOL User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: sipcore@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94/9732/Mon Aug 24 09:56:29 2009 on postal.iol.unh.edu X-Virus-Status: Clean X-Mailman-Approved-At: Mon, 24 Aug 2009 13:50:17 -0700 Subject: [sipcore] SIPit25 registration is still open X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lylavoie@iol.unh.edu List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 20:32:20 -0000 Hello All, Registration for the SIPit25 test event is still open until September 4. The event will be hosted at the UNH-IOL, in Durham, NH, USA, September 14-18. If you are planning to attend, please register as soon as possible, as space is limited. More information is available at . Cheers, Lincoln -- ********************************************************************** Lincoln Lavoie Senior Engineer UNH InterOperability Laboratory 121 Technology Drive, Suite 2, Durham, NH 03824 +1-603-862-4809 Email: lylavoie@iol.unh.edu AIM: LincolnAtIOL Ars sine scientia nihil est! -- Art without science is nothing. Scientia sine ars est vacua! -- Science without art is empty. ********************************************************************** From Mike.Szilagyi@inin.com Wed Aug 26 14:10:59 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74E353A69AA; Wed, 26 Aug 2009 14:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ifIo9tlESch; Wed, 26 Aug 2009 14:10:56 -0700 (PDT) Received: from inin.com (smtpgw.inin.com [209.43.1.24]) by core3.amsl.com (Postfix) with ESMTP id 0B6623A6781; Wed, 26 Aug 2009 14:10:55 -0700 (PDT) Received: from ININHUB1 [172.16.1.156] by smtpgw.inin.com - Websense Email Security (6.1.1); Wed, 26 Aug 2009 17:10:38 -0400 Received: from ININMAIL.i3domain.inin.com ([172.16.1.186]) by ininhub1.i3domain.inin.com ([172.16.1.156]) with mapi; Wed, 26 Aug 2009 17:10:38 -0400 From: "Szilagyi, Mike" To: "dispatch@ietf.org" , "sipcore@ietf.org" , "sip-implementors@lists.cs.columbia.edu" Date: Wed, 26 Aug 2009 17:10:37 -0400 Thread-Topic: Requests sent within early dialog -- CSeq mgmt Thread-Index: AcomkajKMgdjBvXLTS2rxOaQL/onMQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B043FD61A001424599674F50FC89C2D754F659184DININMAILi3dom_" MIME-Version: 1.0 X-SEF-7853D99-ADF1-478E-8894-213D316B8FFA: 1 X-SEF-ZeroHour-RefID: fgs=4 X-SEF-Processed: 6_1_1_105__2009_08_26_17_10_38 Subject: [sipcore] Requests sent within early dialog -- CSeq mgmt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 21:10:59 -0000 --_000_B043FD61A001424599674F50FC89C2D754F659184DININMAILi3dom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've not been able to find definitive text regarding this issue so I'm hopi= ng someone can provide clarification. If a request (INFO or UPDATE) is sen= t on a dialog in the early state, how are the CSeq numbers managed by the U= AS. Here's an example to demonstrate my confusion: UAC UAS INVITE CSeq 1 ---------> <----- 100 Trying Remote CSeq =3D 1 UPDATE CSeq 2 ---------> <-- 200 OK (UPDATE) Remote CSeq =3D 2 CANCEL CSeq 1 ---------> Rejected CSeq < 2 is there text that describes the handling of CSeq numbers for requests sent= within another request for the same dialog? Thanks in advance. Mike --_000_B043FD61A001424599674F50FC89C2D754F659184DININMAILi3dom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve not been able to find definitive text regar= ding this issue so I’m hoping someone can provide clarification.  If = a request (INFO or UPDATE) is sent on a dialog in the early state, how are th= e CSeq numbers managed by the UAS.  Here’s an example to demonstra= te my confusion:

 

UAC  &n= bsp;          UAS

 INVITE=

 CSeq 1= --------->  

 <= /o:p>

 <--= --- 100 Trying   Remote CSeq =3D 1

 <= /o:p>

 UPDATE=

 CSeq 2 --------->  

 <= /o:p>

 <--= 200 OK (UPDATE) Remote CSeq =3D 2

 <= /o:p>

 <= /o:p>

 CANCEL=

 CSeq 1 --------->   Rejected CSeq < 2

 

 

is there text that describes the handling of CSeq numb= ers for requests sent within another request for the same dialog?

 

Thanks in advance.

 

Mike

--_000_B043FD61A001424599674F50FC89C2D754F659184DININMAILi3dom_-- From Bala_Neelakantan@Quintum.com Wed Aug 26 14:45:41 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 044803A70DA; Wed, 26 Aug 2009 14:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKp7w75fCxSH; Wed, 26 Aug 2009 14:45:39 -0700 (PDT) Received: from mx01.net.com (mx01.net.com [134.56.3.131]) by core3.amsl.com (Postfix) with ESMTP id E23B13A6F11; Wed, 26 Aug 2009 14:45:39 -0700 (PDT) Received: from mx01-int.net.com (mx01-int.net.com [134.56.112.13]) by mx01.net.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id n7QLjVTl020242; Wed, 26 Aug 2009 14:45:32 -0700 (PDT) Received: from fmt-ex01.net.com (fmt-exchange [134.56.112.251]) by mx01-int.net.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id n7QLa8cH029989; Wed, 26 Aug 2009 14:36:08 -0700 (PDT) Received: from fmt-ex07.net.com ([134.56.113.16]) by fmt-ex01.net.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 26 Aug 2009 14:54:43 -0700 Received: from fmt-qex01.quintum.com (134.56.116.12) by fmt-ex07.net.com (134.56.113.16) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 26 Aug 2009 14:45:26 -0700 Received: from fmt-qex01.quintum.com ([134.56.116.12]) by fmt-qex01.quintum.com ([134.56.116.12]) with mapi; Wed, 26 Aug 2009 14:45:25 -0700 From: Neel Balasubramanian To: "Szilagyi, Mike" , "dispatch@ietf.org" , "sipcore@ietf.org" , "sip-implementors@lists.cs.columbia.edu" Date: Wed, 26 Aug 2009 14:45:22 -0700 Thread-Topic: Requests sent within early dialog -- CSeq mgmt Thread-Index: AcomkajKMgdjBvXLTS2rxOaQL/onMQABH9QA Message-ID: <87278613D061664392F2161B99567B870EF2D248C9@fmt-qex01.quintum.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Aug 2009 21:54:43.0013 (UTC) FILETIME=[D17E8F50:01CA2697] X-Mailman-Approved-At: Wed, 26 Aug 2009 22:43:32 -0700 Subject: Re: [sipcore] Requests sent within early dialog -- CSeq mgmt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 21:45:41 -0000 See below. Thanks, Neel. > -----Original Message----- > From: sip-implementors-bounces@lists.cs.columbia.edu [mailto:sip- > implementors-bounces@lists.cs.columbia.edu] On Behalf Of Szilagyi, Mike > Sent: Wednesday, August 26, 2009 4:11 PM > To: dispatch@ietf.org; sipcore@ietf.org; sip- > implementors@lists.cs.columbia.edu > Subject: [Sip-implementors] Requests sent within early dialog -- CSeq > mgmt > > I've not been able to find definitive text regarding this issue so I'm > hoping someone can provide clarification. If a request (INFO or > UPDATE) is sent on a dialog in the early state, how are the CSeq > numbers managed by the UAS. Here's an example to demonstrate my > confusion: > > UAC UAS > INVITE > CSeq 1 ---------> > > <----- 100 Trying Remote CSeq =3D 1 > > UPDATE > CSeq 2 ---------> > > <-- 200 OK (UPDATE) Remote CSeq =3D 2 > > > CANCEL > CSeq 1 ---------> Rejected CSeq < 2 > [Neel] For CANCEL processing, the CSeq should be same as that of the INVITE. See RFC 3261 section 9.1 The following procedures are used to construct a CANCEL request. The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request MUST be identical to those in the request being cancelled, including tags. So in this case, the UAS is not behaving correctly. > > is there text that describes the handling of CSeq numbers for requests > sent within another request for the same dialog? > > Thanks in advance. > > Mike > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors From Mike.Szilagyi@inin.com Thu Aug 27 08:06:14 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11E1E3A68E8; Thu, 27 Aug 2009 08:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHnjvvzGVl1G; Thu, 27 Aug 2009 08:06:13 -0700 (PDT) Received: from inin.com (smtpgw.inin.com [209.43.1.24]) by core3.amsl.com (Postfix) with ESMTP id E38663A6969; Thu, 27 Aug 2009 08:06:12 -0700 (PDT) Received: from ININHUB2 [172.16.1.157] by smtpgw.inin.com - Websense Email Security (6.1.1); Thu, 27 Aug 2009 11:06:19 -0400 Received: from ININMAIL.i3domain.inin.com ([172.16.1.186]) by ininhub2.i3domain.inin.com ([172.16.1.157]) with mapi; Thu, 27 Aug 2009 11:06:19 -0400 From: "Szilagyi, Mike" To: Neel Balasubramanian , "dispatch@ietf.org" , "sipcore@ietf.org" , "sip-implementors@lists.cs.columbia.edu" Date: Thu, 27 Aug 2009 11:06:18 -0400 Thread-Topic: Requests sent within early dialog -- CSeq mgmt Thread-Index: AcomkajKMgdjBvXLTS2rxOaQL/onMQABH9QAACRYQYA= Message-ID: References: <87278613D061664392F2161B99567B870EF2D248C9@fmt-qex01.quintum.com> In-Reply-To: <87278613D061664392F2161B99567B870EF2D248C9@fmt-qex01.quintum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SEF-7853D99-ADF1-478E-8894-213D316B8FFA: 1 X-SEF-ZeroHour-RefID: fgs=353098832 X-SEF-Processed: 6_1_1_105__2009_08_27_11_06_19 Subject: Re: [sipcore] Requests sent within early dialog -- CSeq mgmt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 15:06:14 -0000 But, Section 12.2.2 says this: 12.2.2 UAS Behavior . . If the remote sequence number is empty, it MUST be set to the value of the sequence number in the CSeq header field value in the request. If the remote sequence number was not empty, but the sequence number of the request is lower than the remote sequence number, the request is out of order and MUST be rejected with a 500 (Server Internal Error) response. If the remote sequence number was not empty, and the sequence number of the request is greater than the remote sequence number, the request is in order. . . Should the UAS ignore the CSeq number if it's a CANCEL? Is there text anyw= here, in any RFC (UPDATE/INFO/SIP) that describes this behavior? I can't f= ind it. Regards. -----Original Message----- From: Neel Balasubramanian [mailto:Bala_Neelakantan@Quintum.com]=20 Sent: Wednesday, August 26, 2009 5:45 PM To: Szilagyi, Mike; dispatch@ietf.org; sipcore@ietf.org; sip-implementors@l= ists.cs.columbia.edu Subject: RE: Requests sent within early dialog -- CSeq mgmt See below. Thanks, Neel. > -----Original Message----- > From: sip-implementors-bounces@lists.cs.columbia.edu [mailto:sip- > implementors-bounces@lists.cs.columbia.edu] On Behalf Of Szilagyi, Mike > Sent: Wednesday, August 26, 2009 4:11 PM > To: dispatch@ietf.org; sipcore@ietf.org; sip- > implementors@lists.cs.columbia.edu > Subject: [Sip-implementors] Requests sent within early dialog -- CSeq > mgmt > > I've not been able to find definitive text regarding this issue so I'm > hoping someone can provide clarification. If a request (INFO or > UPDATE) is sent on a dialog in the early state, how are the CSeq > numbers managed by the UAS. Here's an example to demonstrate my > confusion: > > UAC UAS > INVITE > CSeq 1 ---------> > > <----- 100 Trying Remote CSeq =3D 1 > > UPDATE > CSeq 2 ---------> > > <-- 200 OK (UPDATE) Remote CSeq =3D 2 > > > CANCEL > CSeq 1 ---------> Rejected CSeq < 2 > [Neel] For CANCEL processing, the CSeq should be same as that of the INVITE. See RFC 3261 section 9.1 The following procedures are used to construct a CANCEL request. The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request MUST be identical to those in the request being cancelled, including tags. So in this case, the UAS is not behaving correctly. > > is there text that describes the handling of CSeq numbers for requests > sent within another request for the same dialog? > > Thanks in advance. > > Mike > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors